ANSWER

Non-functional requirements (NFRs) are typically defined as backlog constraints on an Agile project, and are managed as part of both product backlog and scrum backlog. They are revisited as part of the ‘Definition of Done’ for each iteration or sprint. If the system does not meet any given NFR, that NFR may spawn new backlog items such as refactors or performance enhancements.

Well-defined NFRs should meet the following criteria:

• Bounded: Each NFR should describe the scope of the system to which it apples (its ‘boundary’). Many NFRs apply to the entire system (such as extensibility or portability); however others may be bounded to specific components for feasibility and/or cost-control reasons. Critical functions or components may have stricter non-functional requirements for availability or performance for example, while others (such as administrative functions) may have less stringent needs for these particular NFRs.

• Independent: non-functional requirements should be independent of each other, so they can be evaluated and tested without consideration or impact on other system attributes.

• Negotiable: Like functional requirements, NFRs return a quantifiable business value in return for a definable cost. The cost of an NFR should not exceed its expected value, and may need to be negotiated to align both cost and benefit.

• Testable: If you can’t test it, you can’t deliver it. NFRs should be stated with objective, measurable and testable criteria just like functional requirements.

Prior to Agile, NFRs used to be captured in an FRD (Functional Requirements Document) - in Agile no such document exists so organizations would need to determine when to capture the non-functional requirements.  Some options might be: epic definition documents, user stories, etc.

--
Sandy Lambert
Business Architect
LinkedIn Profile