“It was always assumed that…”

Coding on laptop

Top (sometimes unspecified) functional considerations for software developments

For the second part of our blog on the functional and non-functional requirements for custom software (you can read the first part here), we’re going to concentrate on those functional requirements which are often assumed but all too rarely stated explicitly. This is particularly true of a traditional OLTP web application, which is often compared (perhaps unfairly, often unfavourably) to other applications available on the public internet.

Obviously, each application is different and will require its own very specific set of functional requirements, but there are a good number that are fairly consistent across most, if not all, applications. Some of the most common ‘functionals’ that we find are often overlooked are:

  • Responsive Design – pages should be designed in a responsive manner, to adapt to the device display;
  • UX – the user should be presented with a consistent user experience throughout their journey, e.g. consistent typeface, colours, buttons etc.;
  • Security – most web applications require a change of password on first login, password expiry and strong password rules. It is also reasonable to expect 2-factor authentication, and email confirmation for a change of password;
  • URLs – URL structures should follow REST conventions and allow a user to bookmark a page, e.g. /users, /another/page/2;
  • Browser Navigation – in general, it should be possible for users to use the browser’s forward/back buttons as an alternative to the buttons provided within the application;
  • Re-Directs – if, when accessing a page, the user is required to re-authenticate, the user should be redirected to the chosen page after logging in;
  • Search – should not be forgotten about. In general, users expect some form of search function, even if there is no obvious need for one at the outset;
  • Paging – lists should always be presented in a pageable format, and the number of pages per screen should be configurable;
  • Column Sorting – whenever lists are presented with columns, those columns should be sortable by clicking on column headings;
  • Deletion – it is usually preferable to implement a soft (logical) delete as opposed to actually deleting data;
  • Audit Trail – some form of an audit trail of changes to core data is expected;
  • Management Information – some form of MI or data reporting is expected. Even if there is already a reporting solution in situ, users will expect the application data to be easily consumable by this solution;
  • Data Export – some means of extracting the application’s data is usually required (e.g. export to CSV);
  • Multi-Tenancy – a frequent cause of consternation with custom builds is the assumption that an application will support multi-tenancy i.e. the ability to handle, but keep segregated, data from multiple organisations or organisational units;
  • Error Messages – customers expect to see branded, application-specific error messages on screen – no stack traces!

We hope you’re now a little more aware of the functional and non-functional requirements of software that can often be overlooked by developers. If you require further assistance with your software development projects we have a whole blog dedicated to just that. For Red Hat-specific enquiries, you may wish to get in touch with the Tier 2 Consulting team.