A Non-Functional Requirement (NFR) specifies the system’s ‘quality characteristics’ to determine how the system should behave based on Responsiveness, Accessibility, Portability, Security and other non-functional standards.
Below we explore the different types of non-functional requirements you can have and test against
- Accessibility Requirements – This requires the software to be accessible by all its intended users. An example can be as simple as making sure that boxes are up and reachable from all parts of the network or ensuring that all user front ends comply with disability regulations.
- Audit & Control Requirements – It is important to be able to audit who has been using the system, what transactions were running at any given time and what parts of the system were available. An example could be user activity or logs that are kept on the server for up to 90 days. It also may be necessary to control the usage and state of the system at run time.
- Availability Requirements – The system needs to have defined periods when it will be accessible to its intended users. For example, Mon-Fri 08:00 – 18:00, Sat 08:00 – 12:00 or it could be operational 24/7. One must also consider acceptable durations of outage and maintenance.
- Backup Requirements – It is important to define the data that needs to be stored in a back-up process. Things to consider are the type of backup processes (disk or tape etc.) backup frequency (hourly, daily or weekly) and backup duration (how long to keep the backup for.) One must also consider how long it would take to restore the stored data back to the production/live system.
- Brand Consistency Requirements – This is primarily around the parts of the system that are exposed to the client/consumer. For example, documents, internet pages, etc.
- Batch Requirements – Many projects are dependent on batch processes or scheduled events. These need to be defined and the impact on other tests should be considered. We advise running batch processes during performance testing.
- Compliance Requirements – Every business is now subject to several internal and external compliance issues: e.g. FSA – Financial Services Authority, DPA – Data Protection Act, Sarbanes-Oxley Act (SOX.)
- Capacity Requirements – The future of a business may be dependent on the ability of the project to scale. Early consideration of the capacity requirements for the system can be hugely beneficial. This should consider all system resources. For example, networks, storage, processing, memory, number of hardware servers, web servers, application servers and database servers, LDAP, Active Directory, load balancing, proxies.
- Data Integrity Requirements – This is relevant for systems where data is moving around a great deal, or when data is replicated in a number of locations. It is important that synchronisation times are considered and factors such as where the master data is held. A simple example could be around where the system time is obtained.
- Documentation Requirements – Documentation is in all aspects of system development and should be defined. Documents that are required for each quality gate should be specified. This can also be broken down into internal documentation – e.g. training/user guides and external documentation– e.g. customer-generated letters.
- Event Management Requirements – There are several system events that can be managed. Heartbeats, information, errors, warnings and alerts. The mechanism for handling these events should be considered during normal working hours as well as out of hours.
- Fault Tolerance Requirements – Each part of a system will either depend on or provide functionality to another part of the system. Fault tolerance must consider the impact of the failure of each individual component. For example, if the main database node fails, does this mean that the operations are frozen until it is back up or are there any parts of the system that could operate?
- Installation Requirements – The system should have clearly documented procedures for installation on each system, whether that is development, test or production. This also needs to cover the process for patching, maintenance releases, and hotfixes.
- Interoperability Requirements – Systems are rarely isolated in terms of infrastructure and supporting environments like storage area networks. Systems interact directly with other systems. These requirements need to consider the needs of all systems in the domain. For example SANs are designed for concurrent usage but high usage from one system can impact other systems.
- Load Requirements – The requirements need to dictate the bounds of the system and are closely related to the volumetric and availability requirements. In addition, some expression of the level of risk should be considered. You should ask the question; can the system cater for twice the expected volume?
- Maintainability Requirements – Maintainability comes in two areas. Firstly, the underlying code and configuration should be maintainable. For instance, low amounts of duplicate code and suitable configuration tools. Secondly the system will ideally have a defined process for updating each component.
- MI/Alerting Requirements – Management information needs to be collected from systems. The frequency and indices need to be defined. Alerts need to contain relevant information and need to be triggered early enough to allow remedial action.
- Operability Requirements – This defines the procedures that take place at regular events – database procedures, log rotations, archiving, general housekeeping and procedures.
- Performance Requirements – The users of the system will have expectations about the response times for each business process. These should be broken down to represent the acceptable distribution of response times. Ideally these should also be broken down for each sub-component that contributes to the overall response time.
- Portability Requirements – Many systems are required to operate in different environments a couple of examples are, hosted or client deployments. In all cases the use of development, test and production environments should consider the changes in the deployment that are required.
- Recovery Requirements – Some systems have inbuilt redundancy. For all systems the mechanisms for returning the system to a normal operating state need to be defined. All failures from a single component, to multiple failures and site failures, should be considered.
- Reliability Requirements – This is largely covered by the functional tests but also needs to consider extremes in environmental conditions or what happens when system resources are not available – does the system continue to operate as expected? Or is the normal operation of the system denied? Where clustering is used in the event of a failure of the primary node, processing must automatically resume on the secondary node.
- Scalability Requirements – The usage of a system is likely to grow over time. The system will be expanded to facilitate this process. The process by which this occurs needs to be defined.
- Security Requirements – The majority of businesses have security requirements. How these affect the project and the sub-components of the system need to be considered. An example of this could be to check that data backups are secure, locked away and off-site and password protected.
- Service Level Agreements (SLA) Requirements – The services that make up the system need to have agreed SLAs. These should be for operation and for maintenance or upgrade. An example could be the development team and the Service Level Agreements around defect fixes.
- Service-Oriented Architecture (SOA) Governance Requirements – The services need to have defined contracts and SLA’s in place and they need to exist in registries. The versions need to be controlled and they need to be started and stopped.
- Usability Requirements – This is dependent on the nature of the system. For example, a system that is used regularly by expert users may need to have short cut keys or macroing capabilities. In addition, it may have to operate in a variety of web browsers or through multiple channels such as PC, mobile phone and web.
- Usage Requirements – The normal pattern of usage needs to be defined. An example could be the total number of users with access, or the different types of users that will use the system and how will their usage be different.
- User / Admin Requirements – The access rights for all types of users at all phases of the system lifecycle need to be defined. This needs to cover the policies for adding, removing and updating accounts. For instance, an ‘Admin’ role can access all parts of the system, a ‘Viewer’ role can only look at data.
- Volumetric Requirements – The expected number of users for the system and what they are doing while they are on the system. This is important for the peak load of the system but should also define the normal usage.
In conclusion, this is not an exhaustive list, but it covers the main types of non-functional requirements you may have and may have to test against.
