Strategies for Implementing Non-Functional Requirements

Non-functional requirements, also known as quality of service (QoS) or technical requirements, are typically system-wide thus they apply to many, and sometimes all of your functional requirements.  Part of ensuring that your solution is potentially consumable each iteration is ensuring that it fulfill its overall quality goals, including applicable NFRs.  This is particularly true with life-critical and mission-critical solutions.  Good sources for NFRs include your enterprise architects and operations staff, although any stakeholder is a potential source for NFRs.

As your stakeholders tell you about functional requirements they will also describe non-functional requirements (NFRs).  These NFRs may describe security access rights, availability requirements, performance concerns, or a host of other issues as saw in my blog regarding initial architecture envisioning.  There are three basic strategies, which can be combined, for capturing NFRs: technical stories; acceptance criteria for individual functional requirement (such as stories); and an explicit list.


So what are the implications for implementing NFRs given the three previous capture strategies?    Although in the DAD book we make this sort of comparison via a table to improve consumability, in this blog posting I will use prose due to width constraints.  Let’s consider each one:

  1. Technical stories.  The advantages of this approach are that it is a simple strategy for capturing NFRs and that it works well for solutions with a few NFRs or simple NFRs.  But, the vast majority of NFRs are cross-cutting aspects to several functional stories and as a result cannot be implemented within a single iteration.  This strategy also runs the risk of teams leaving NFRs to the end of the construction phase, thereby pushing technical risk to the end of the lifecycle where it is most difficult and expensive to address.
  2. Acceptance criteria. This is a quality focused approach which makes the complexity of an individual functional requirement apparent, working well with test driven approaches to development.  NFR details are typically identified on a just in time (JIT) basis during construction, fitting in well with a disciplined agile approach.  But, because many NFRs are cross cutting the same NFR will be captured for many functional requirements.  It requires the team to remember and consider all potential NFR issues (see Figure in my previous posting) for each functional requirement.  You will still need to consider NFRs as part of your initial architecture efforts otherwise you risk a major rework effort during the Construction phase because you missed a critical cross-cutting concern).
  3. Explicit list.  This strategy enables you to explore NFRs early in the lifecycle and then address them in your architecture.  The list can be used to drive identification of acceptance criteria on a JIT basis.  But, NFR documents can become long for complex systems (due to the large number of NFRs).  This can be particularly problematic when you have a lot of NFRs that are specific to a small number of functional requirements.  Teams lacking in discipline may not write down the non-functional requirements and trust that they will remember to address them when they’re identifying acceptance criteria for individual stories.

In most situations you should maintain an explicit list and then use that to drive identification of acceptance criteria as we’ve found that it’s more efficient and lower risk in the long run.  Of course capturing NFRs is only one part of the overall process of addressing them.  You will also need to implement and validate them during construction, as well as address them in your architecture.

An important issue which goes to NFRs such as consumability, supportability, and operability, is that of deliverable documentation.  At the start of the project is the best time to identify the required documentation that must be created as part of the overall solution.  This potentially includes operations manuals, support manuals, training materials, system overview materials (such as an architecture handbook), and help manuals to name a few.  These deliverable documents will be developed and kept up to date via the continuous documentation practice.


Related Posts

8 thoughts on “Strategies for Implementing Non-Functional Requirements

  1. Nigel H

    I like the concept, but I’m not sure of your examples being ‘NFRs’. Both of the examples that you use I believe are functional requirements. I would suggest that something along the lines of architectural limits or for a web based service moving from one OS to another are better examples and are probably better referred as where the user sees no difference to the product and it apparently is working the same before and after the change.

  2. Shiv K Singh

    I concur with Scott and the examples are clearly NFR. What additional thing I would recommend is “establishing relationship between these requirements and functional requirements”. Many a times, a NFR applies to the whole system/ solution and in that case, it doesn’t make sense to show the relationship of the NFR to all FRs, however there are many NFRs which can be tied to some FRs only and in that case establishing the relationship would help — Developers, testers and users — do their task better. For example the NFR related to Employee Salary should be tied to the FR describing this functionality. That would help Developers, testers and users during development, testing and using the system.

  3. Pingback: Strategies for Verifying Non-Functional Requirements « Disciplined Agile Delivery

  4. Pingback: Disciplined Agilists Take a Goal-Driven Approach « Disciplined Agile Delivery

  5. Soheil

    Nice article,
    I think also we have to go back to the old-fashion 3C principle and use the back side of the story cards to keep it short and SMART 😉


Leave a Reply

Your email address will not be published. Required fields are marked *