A component must meet all applicable NFRs prior to being released.
- NFRs define system attributes and constraints, which include:
Non-functional elements of security (e.g. use of encryption, SSL)
Non-functional elements of compliance
Reliability (fault tolerance, failure prevention, etc.)
Availability/Recovery
Scalability/Performance (response time, throughput, data freshness, etc.)
What is a well-defined NFR
Bounded – When they lack bounded context, some NFRs are irrelevant (or even harmful). For example, performance considerations can be critical for the main application but unnecessary or too expensive for administration and support applications.
Independent – NFRs should be independent of each other so that they can be evaluated and tested without consideration of or impact from other system qualities.
Viable/Achievable – Each NFR comes at a cost and must be right-sized to be achievable for the organization.
Testable – NFRs must be stated with objective, measurable, and testable criteria because if you can’t test it, you can’t ship it.
| Category | NFR verification | Notes/explanation |
|---|---|---|