What is a non-functional requirement?
Non-functional requirements (NFRs) capture conditions that do not directly relate to the behaviour or functionality of the solution, but rather describe environmental conditions under which the solution must remain effective or qualities that the system must have.
A functional requirement specifies a function that a system or system component must be able to perform. Therefore, another way to explain ‘non-functional’ requirements is that they specify all the remaining requirements not covered by the functional requirements.
Non-functional requirements specify the system’s ‘quality characteristics’ or ‘quality attributes’. Two products could have the same functions, but their attributes can make then entirely different products.
For example, a BMW has more or less the same functionality as a Mini, but it has many different attributes.
The following categories are the main areas of attention for non-functional requirements.
- Reliability and recoverability
- Data Migration
Categories of non-functional requirments
This relates to the speed of transactions for peak and expected growth of business volumes. e.g. throughput, response times.
- What is the acceptable time taken to load (render) the full screen (with all images and buttons) of the application after clicking the icon, link or button?
- What is the acceptable time the GUI can take to respond to action performed by user, e.g. click button to go to next screen?
- What are the hours of operation for the system?
- What are the peak hours of operation for the system when most people will be using it?
- What is the total number of system users?
- What is the number of users likely to use the system at any one time?
- What is the total number of concurrent system users during peak hours?
- How does this vary day to day? i.e. are there more users at the end of the week/month?
- What is the number of users in each geographical location that the system is used?
- What is an acceptable response time to perform an action? (to be edited per application where applicable). For example, login, query, update, upload.
- What is the impact of not meeting this requirement?
- What is the likelihood of the increase in volume of transactions in: 6 months, 1 year, and 5 years?
- What is the likely increase of the number of users in: 6 months, 1 year, and 5 years?
- Under normal business conditions, when is the start of day and end of day?
- What is the current database data volume?
- How is this expected to grow over the next: 1 year? 5 years?
- What is the user load mix? i.e. users/roles and the main actions they perform.
- What is the impact if the data presented on screen is out of date or inaccurate?
- What are the business processes and user journeys that are most critical (and should therefore be emulated in the tests)?
- Are there any user journeys that are particularly complicated from a technical perspective i.e. making external calls, complex/multiple queries, or high volumes?
- Can you provide any architectural diagrams?
Reliability and recoverability
How reliable is the system and can it recover if it fails in any way? How correct/accurate is the data?
- Could unavailability of information or system result in directly attributable loss of business?
- Could unavailability of information or system result in additional costs being incurred?
- Could unavailability of information or system cause a backlog of processing which could not be handled either manually or when the system recovers?
- Could unavailability of information or system adversely affect key management decision making?
- If the system fails, what is the importance of being able to recover information?
- Are there any beginning or end of day/week/month/year processing cycle / batch jobs that occur?
- If yes, is there a deadline for when that job must complete and what is that time?
- If yes, what is the earliest that the job can start?
- What is the impact if the job does not complete by this time?
- Does the processing cycle differ on any particular dates? e.g. end of month, end of quarter, end of year.
The prevention of unauthorised access to programs and data.
- Could unauthorised changes to, or errors in information, adversely affect key business decision making?
- Could unauthorised addition, deletion or modification of information result in fraudulent diversion of goods or funds?
- Could unauthorised changes to or errors in information result in disruption to the operation of the business?
- Could unauthorised changes to or errors in information result in additional costs being incurred?
- Could unauthorised changes to or errors in information breach legal, regulatory or contractual requirements?
- Could any damage be caused by co-worker viewing information they are not supposed to have access to?
- Could any damage be caused by unauthorised person/public viewing information they are not supposed to have access to?
- Does the system contain business critical information?
- Does the system contain data that could be used maliciously or sold by a third party?
How easy it is for a person to learn, use or interface with the system.
- Should the system have the same look and feel as existing applications?
- Are user manuals required?
- Are help facilities required?
- How is the system to be supported?
- Do you require all tables and rows in the data model to have detailed descriptions?
- Should a corporate database definition policy be adhered to (e.g. standards for table names and column names, primary keys etc?
The ability for the system to run in different operating environments and with different components.
- On what devices should the system be able to run on?
- What web browsers should the system be able to run on?
- What operating systems should the system be able to run on?
- What infrastructure should the system be able to run on? For example, physical or virtual.
Transferring data from the legacy/incumbent system(s) to the new system.
- Is data required to be migrated to the new system?
- What data elements need to be migrated?
- What is the timeframe in which cutover needs to be executed?
- What is the impact if cutover fails/misses the deadline?
- What is the impact if migrated data is duplicated, missing or inaccurate?
What if the solution being procured is hosted off-premise or is a cloud service?
If the solution is hosted off-premise or is a cloud service, then the following questions relating to security assurance, defined release model, change control, vulnerability management, and incident management may be applicable. Note that these are the main questions I have seen in my experience.
- Can the service provider(s) provide independent security assurance of the entire supply chain?
- Can the service provider(s) provide details of applicable certifications and assurance audit reports for each service layer?
- Can the service provider(s) provide a defined release model and frequency, including version control of software releases?
- Can the service provider(s) maintain robust change control with the customer and notify the customer of any underlying infrastructure changes without expected end-user impact?
- Can the service provider(s) periodically and at least annually vulnerability assess or penetration test (respectively) their service and remediate vulnerabilities in a timely manner?
- Can the service provider(s) maintain an effective incident response plans and provide timely notification of suspected cyber security incidents to the customer?
What if the solution being developed is a SaaS?
I recommend that you read these two articles:
How much detail should I produce?
The above questions for each category produces a lot of information for a solution. Therefore, it is important the objectives and required outputs of your technology initiative.
- What will your requirements support?
- Is it for identifying a possible solution for procurement?
- Will the requirements be used in a request for information or request for quotation?
- Does the solution require multiple vendors or technologies?
- Is it COTS or custom developed?
- Will it SaaS or internally hosted?
- Are you testing the market or have you already identified your technology approach?
If you are writing NFRs as part of testing the market then you should keep the requirements at a high level specification. This is so you can encourage responses from vendors and not inadvertently lock them out due to an overly specified requirement.
Therefore, the use of architectural principles may be a good option in addition NFRs or on their own.
The relevant guiding principles for the solution may look like this:
- Avoid customisation – adopt COTS solutions without customisation and change business practices / processes to match the solution where possible.
- Platform integration – solution options will be evaluated against the long term vision of implementing an integrated platform.
- Business process automation – automate business processes where possible without solution customisation.
- Ease of use – the solution should feel familiar and be intuitive to the user.
- Adopt best practice – the solution should adopt industry best practice where possible.
- Optimise and automate systems management.
- Office productivity applications must not be used for corporate solutions
- Mobile applications – design for user first, device second
- For core and critical functionality more stable and mature products should be used. However for differentiating or emerging functions newer and less proven solutions may be considered to achieve innovation/optimisation outcomes.
- Reduce cost and complexity by utilising ‘out of the box/vanilla capability of Commercial off the Shelf (COTS) IT solutions and adapt underpinning work practices and processes.
- The organisation should adapt to IT systems and services that are cost effective, efficient and agile.
- The organisation should secure our data and systems aligned to Federal and State requirements (or according to legislation for the relevant region).
- Minimise legacy dependency.
How do I elicit non-functional requirements?
1. Stakeholder goals, values, and concerns
- What is important to the stakeholders (including the users)?
- What qualities are must have in order to achieve stated business and organisational goals?
- What are the stakeholders worried about? What are their concerns?
2. Legacy system and/or existing platform constraints
- What are the constraints dictated by the environment into which the new system must fit?
- What are the existing systems with which it must integrate, and the technical platform(s) it must use?
3. Competitive analysis of system qualities
- What additional non-functional requirements can be discovered by analysing the qualities of competing systems?
4. Industry and market trends
- What is the direction the industry or vertical market is taking and identify key trends?
5. Standard non-functional requirements templates and categories
- Are there any standard templates and categories in order to focus on and ask questions about each type of non-functional requirement? See the above categories and questions for guidance.
6. Survey data and reports
- Are there reports that can provide valuable data for estimating current user behaviour and potential growth?
Who should I talk to when eliciting non-functional requirements?
Not just one person will have all of the answers to your questions. A good approach to eliciting and validation non-functional requirements is to conduct a workshop with all relevant technical stakeholders and possibly an SME from the business.
Possible stakeholders for consultation are:
- Business SME – given that they can follow enough of the technical discussions to confirm questions relating to business requirements when asked.
- ITS manager
- Cyber security consultant
- Infrastructure, network, mid range consultant
- Business applications consultant
- Solutions architect
- IT systems tester
- Enterprise information consultant
Cyber security, and privacy and protection of information is very very important. The experts that deal with these aspects absolutely must be involved in developing the non-functional requirements.