It is really important that non-functional requirements are gathered early on and aren’t missed out. They are potentially more important than functional requirements.
A non-functional requirement is a quality, constraint or behaviour that the system being built must meet.
The consequences of missing these out are that the system being developed may not be adequate, has cost more than needed or leads to a much higher cost than budgeted for.
The following are just some of the examples of the problems which could occur:
- The kit that needs purchasing is not suitable, thus leading to increases in costs of buying more than planned
- The new system isn’t compatible with the companys existing environment so cannot be used
- The right licenses haven’t been purchased leading to additional costs
- Incorrect access has been granted or isn’t available to the right users which could cause a security breach or make the system unusable
- Backups and disaster recovery is inadequate leading to loss of data
- The system isn’t scaleable enough leading to the new system quickly becoming too slow and unusable
- The system isn’t available at the right times or when it is most needed
This is part 1 of a set of 2 articles. Part 2 will focus on the questions to ask to ensure non-functional requirements are gathered and who to involve.
Thoughts? Questions? Please share in the comments.
If you have found this article useful then you might like my book – The Business Analysis Handbook – Techniques and Questions for better Business Outcomes. The book is available from www.koganpage.com and all major print and e-book retailers.
A “behavior” that the system must meet is normally considered to be in the realm of functional requirements, not non-functional. In fact, a synonym for FR is “behavioral requirement” (per Alan Davis, who I’ve always considered to be the father of requirements engineering)..
Thanks for your feedback. I was thinking of behavior in terms of system performance and response which are non-functional.