We know how to deal with functional requirements. We know they are important – we can walk the dependency chain from goals to use cases to functional requirements. But how do we get to the non-functional requirements? James Leatherman points out the elephant in the room – non-functional requirements don’t get enough attention when it comes to testing. Let’s look into it some more…
Structured Non-Functional Requirements
[Update Aug 2009: I realized the previous version of the following sentances could imply that this is "his" model - it is my interpretation of his model.] My interpretation of Karl Wiegers’ structured requirements model (explained here) is show below.
- Goals are achieved by enabling use cases.
- Use cases are enabled by implementing functional requirements.
- Functional requirements must have the characteristics defined in non-functional requirements.
- Functional requirements drive design decisions that are restricted by constraints.
- Design choices guide implementation
- Implementation is product
James realized that non-functional requirements are not getting enough attention. His solution approach is to deny that there is such a thing as non-functional requirements, thereby forcing people to deal with those requirements. By eliminating the stigma, I suspect he hopes to remove the second-class citizen status that non-functional requirements seem to have.
Here is my issue – there is no such thing as a “non-functional” requirement. In the IBM Rational world, there are Functional Requirements, encompassing business use cases, needs and features, UI specs and so forth – and whatever is left over (security, error recovery, etc.) gets heaped into “non-functional” requirements. Not only is this improper classification and a total misnomer, but it almost always gets overlooked by the project team. Bad idea, considering that, from my experience, 80% of the risk is in these neglected areas.
There is value in maintaining the classification of non-functional requirements. Requirements that represent different aspects of what shall be done should be separated, but they should also be treated with equal importance.
- Functional requirements define what the system must be able to do, without defining how this is to be accomplished. The system shall store contact information. The system shall apply shipping and tax charges when billing customers.
- Non-functional requirements define measurable, characterizing aspects of what the system must be able to do. The system shall return search results in under ten seconds. The system shall process at least 10,000 orders per minute.
Equal Rights for Non-Functional Requirements
As James pointed out, much if not most of the risk of delivery is in failure to meet these characterizing requirements. What we need to do is make sure that non-functional requirements get as much attention as functional requirements. We’ve reworked our structured requirements diagram to better reflect the importance of these requirements.
- Goals are achieved by enabling use cases.
- Goals drive non-functional requirements.
- Use cases are enabled by implementing functional requirements.
- Use cases influence non-functional requirements.
- Non-Functional Requirements define the characteristics of functional requirements.
- Functional requirements drive design decisions
- Design choices are restricted by constraints
- Design choices guide implementation
- Implementation is product
We’ve made four distinct changes to the diagram
- Non-functional requirements define characteristics because they are needed for the goals. When a characteristic is irrelevant, it should not be documented. This explicit traceability to the underlying goal helps us keep our eyes on the ball and not lose sight of the importance of these non-functional requirements.
- Use cases influence which non-functional requirements need to be defined. The use cases embody the interactions that users will have with the system. Some non-functional requirements are independent of the specific interactions, so we used a dashed line. The dashed line serves to remind us that this relationship can exist but might not.
- We’ve re-ordered the statement of the relationship between non-functional requirements and functional requirements to highlight the significance of the non-functional requirements.
- Constraints represent limitations on how a solution must be implemented (database, supported hardware, etc). We’ve moved the relationship to properly show that constraints influence design decisions, not requirements decisions.
Conclusion
Non-functional requirements are critically important. They are distinct in their structure and content. That distinction should remain, if for no other reason than to help people focus on writing good requirements.
Latest Articles
Comments on all Articles
