Customer Requirements
At the start of the project, you will typically meet with the client to discuss what they require. There will inevitably be a long list of requirements – that is, after all, the point of the meeting.
The requirements are separated into two categories: functional requirements, and non-functional requirements.
Functional Requirements
A functional requirement is a function that the software is expected to provide. For example, a system which allows a travel-agent to look for holidays available in a selected country must allow a country to be input, and must show all available holidays in that country. It does not discuss anything about how it should happen.
Put simply, functional requirements are what a system is expected to do.
Some further examples are (obviously it is impossible to give a full list of functional requirements as they are dependent on the system):
- User can create an account
- Password can be reset
Non-functional Requirements
Everything else. Anything that a client says the system should do/have is ultimately a requirement. However, unless that requirement is one of the things that it should do (a functional requirement), it is a non-functional requirement. Non-functional requirements deal with the how factor. Using the example from above, we have a functional requirement for the travel agent. However, it would be reasonable to expect that the client would also specify a time limit: perhaps a response must be received by the user within 5 seconds of the request being made.
Here is a list of requirement-types that are all non-functional:
- Accessibility
- Capacity, current and forecast
- Compliance
- Documentation
- Disaster recovery
- Efficiency
- Effectiveness
- Extensibility
- Fault tolerance
- Interoperability
- Maintainability
- Privacy
- Portability
- Quality
- Reliability
- Resilience
- Response time
- Robustness
- Scalability
- Security
- Stability
- Supportability
- Testability