Categories: agile, Architecture, architecture, Construction phase, Non-Functional Requirements, non-functional requirements, requirements, Scrum
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:
- 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.
- 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).
- 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
- Strategies for Capturing Quality Requirements
- Strategies for Verifying Quality Requirements
- Develop Initial Test Strategy
