Make sure you keep a focus on Non-functional requirements. Perhaps discuss them in your daily stand-ups, show and tells or requirements reviews. Make sure the product owner is aware of them. As a product owner make sure they are discussed, make sure they are considered when accepting user stories and are included in the definition of done. Make sure they are specified and are tested along with the functional requirements.
Associated non-functional requirements.
These are non-functional requirements that are associated to specific functional requirements.
Taking capacity in an order processing system as an example, we may have a non-functional requirement specifying the total number of records we need to capture. However it may be useful to know how many of these are customer records and how many are stock records. Staying with capacity, we may want to specify the number of simultaneous users, but this may different for users capturing stock details and users capturing customer details.
So, in this example, as we specify the functional requirement for Capture Customer Details we should associate it to the number we expect to capture and the number of simultaneous users. We would also want to associate to other non-functional requirements such as access: what users have the rights to be able to use this functionality.
To ensure the quality of your requirements you must review each functional requirement and this review should include a review of the associated non-functional requirements.
Typical Non Functional Requirements
The following should be specified and considered in requirement reviews:
Response Time: the speed at which the system should process transaction or respond to queries. Is affected by capacity.
Capacity/volumes: Such as the number records to be captured and stored, the number of simultaneous user or transactions. Affects response time.
Access: The users who have the rights to use certain functions depending on security and business need
Security: The security policies the system has to comply with. This will affect who can access what function
Back up: The frequency and security of back-ups. This should also consider how to restore from back up
Delete/Retain: The criteria, often time period, for retaining, archiving and deleting records.
Availability: The time period the system is available and on line for use. Not all systems need to be available 24/7
Usability: Criteria for users to be able to use the system effectively, considers such things as training or hours needed to become conversant with the system
Continuity: Criteria for recovering from disaster, considers business need and contributes to disaster planning.
Reliability/robustness: Often included in a Service Level Agreement, considers acceptable levels of non routine downtime. Often referred to as Mean Time Between Failure
Maintainability: Criteria for maintaining the system, can include Mean Time To Repair
Accessibility: Considers the need for the system to be accessed by people with disabilities
As organisations focus on the functionality required by user stories and the features in a minimum viable product it is all too easy to lose sight of non-functional requirements.
But getting non-functional requirements wrong can lead to loss of income from disgruntled customers or loss of productivity from users who can't access vital business functions.
Copyright © 2025 Necitas Business Analysis Enablement - All Rights Reserved.