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:
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.
November 5, 2020, 8:30 a.m. to 6 p.m. EDT | November 6, 2020 – February 7, 2021, On-Demand | Online Conference