There is some dispute regarding the use of the term non functional requirements and whether it is the correct term. However, it is in common use and serves a recognised purpose. In this article it is used to describe general characteristics and properties that are required. They are non-functional in the sense that they don’t describe any sort of behaviour.
The business have a tendency to miss them altogether which means the business analyst needs to help the business in identifying these. There are some obvious ones that are identified quickly and easily such as system availability, acceptable response times and there may be cost and time constraints.
The remainder are often overlooked. It is very important to devote the effort extracting these as they can be critical to the project success and a significant contributor to cost which will increase if they are identified later in the project (for more information on costs attributed to late identification of requirements, see Requirements Engineering – an Introduction)
The only way to really identify these requirements is with a deep understanding of the business, it’s processes and strategy and the specific objectives of the project. The business analyst ofetn doesn’t have this knowledge, in which case, there are many ways to identify non-functional requirements which include:
- examining functional requirements to deternmine possible non-functional requirements
- walking through the business process or a prototype of the system
- observing a user a work
- interviewing a user
Armed with this knowledge, it is more likely that the business analyst will be able to direct the stakeholders towards the requirements they never thought they had. 
The following is taken from Wikipedia from the acronymn FURPS and provides some triggers for the categories of non-functional requirements that may have been overlooked:
- Functionality - Feature set, Capabilities, Generality, Security
- Usability - Human factors, Aesthetics, Consistency, Documentation
- Reliability - Frequency/severity of failure, Recoverability, Predictability, Accuracy, Mean time to failure
- Performance - Speed, Efficiency, Resource consumption, Throughput, Response time
- Supportability - Testability, Extensibility, Adaptability, Maintainability, Compatibility, Configurability, Serviceability, Installability, Localizability, Portability
Other Links
Non-functional requirements from Wikipedia - a huge variety of categories for non-functional requirements are suggested and described here
Volere requirements template and non-functional requirements – another view provided by Suzanne and James Robertson which is very useful
Related books
Mastering the Requirements Process
Thank you for reading this article, please make comments if you have questions, disagree or wsh to discuss further
657 Responses to “Non-functional requirements”
Read below or add a comment...
Trackbacks