They fall broadly into three categories:
- Functional — Something the software must do. e.g. “The software will send an email when an order is placed”
- Non-functional — A property or quality the product must have, such as performance, usability, security, or reliability. e.g. “The software must run on a 1024×768 monitor”
- Constraints — Global issues that shape all other requirements e.g., “The software will run on Windows” or “No internet access available”
Why requirements matter
“The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is so difficult as establishing the detailed technical requirements, including all the interfaces to people, to machines and to other software systems. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later.”
Frederick Brooks, The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition), Addison Wesley Professional, Boston, 1995.
Gathering accurate requirements ensures that we:
- Build the software right.
- Build the right software.
Taking the time to work out requirements before development begins will lead to fewer changes later in the development cycle. It usually leads to higher customer satisfaction with the software.
What makes a good requirement?
A good requirement should be:
- Testable
- Clear and unambiguous
- Correct and consistent
- Atomic or self-contained
- Independent of other requirements
Examples
Discovering functional requirements
If you ask the customer what they want, you will usually get a broad requirement.
“The software should allow the user to enter an order.”
With further discussion, break this down into smaller requirements:
“The software should allow the user to select a customer.” “The software should allow the user to select a product.” “After placing an order, the software should send the customer an email.”
Continue to break these requirements down until they meet the criteria for good requirements.
Non-functional requirements
Requirements of this type relate to qualities of the software and will typically fall into categories such as these:
- Performance
- Scalability
- Portability
- Usability
- Compatibility
- Localisation
- Reliability
- Security
- Maintainability
- Availability
Non-functional requirements can be hard to specify or discover. For example, for a performance requirement you will most likely get told something like “the system should be fast”. Of course this is not testable and we cannot ensure we have met that requirement once we have built the software. Ask questions to elicit these requirements: Which process? How long does the process currently take? What is an acceptable length of time?
Usability requirements can be particularly hard to discover as often a user cannot see or tell you about these requirements. A good way to discover these is to watch someone using the software.
- How quickly can users achieve what they want to do?
- How often do they make mistakes?
- Are the switching from keyboard to mouse frequently?
- Is the information they require readily available?
Assumptions
Assumptions in software development can lead to further problems and these should be kept to a minimum. If you find you are making assumptions when gathering requirements, check them with the customer. Document any assumptions you make for future reference.
Conclusion
- Accurate requirements are essential for software development
- Requirements can be hard to find
- Talk to the customer
- If necessary, demonstrate prototypes to the customer
- Observe users operating the software
- Be wary of making assumptions
