Project Management

Disciplined Agile

by , , , , , , , , ,
This blog contains details about various aspects of PMI's Disciplined Agile (DA) tool kit, including new and upcoming topics.

About this Blog


View Posts By:

Scott Ambler
Glen Little
Mark Lines
Valentin Mocanu
Daniel Gagnon
Joshua Barnes
Michael Richardson
Klaus Boedker
Kashmir Birk
Mike Griffiths

Recent Posts

Disciplined Agile: An Executive's Starting Point

Using Lean Agile Procurement (LAP) in complex procurement situations

Vendor Management in the Disciplined Agile Enterprise

Asset Management: What Types of Assets Might You Manage?

PMI and Disciplined Agile at Agile20Reflect

Strategies for Capturing Quality Requirements

Agile modeling

Quality requirements, also known as non-functional requirements (NFRs), quality of service (QoS) or technical requirements, address issues such as reliability, availability, security, privacy, and many other quality issues.  The following diagram, which overviews architectural views and concerns, provides a great source of quality requirement types (the list of concerns).  Good sources for quality requirements include your enterprise architects and operations staff, although any stakeholder is a potential source for them.

Figure 1. Architectural views and concerns.

Architecture Views and Concerns


Why Are Quality Requirements Important?

Stakeholders will describe quality requirements at any time, but it’s particularly important to focus on them during your initial scoping efforts during Inception as you can see in the goal diagram below for Explore Initial Scope.  Considering quality requirements early in the lifecycle is important because:

  1. Quality requirements drive important architecture decisions. When you are identifying your architecture strategy you will often find that it is the NFRs that will be the primary drivers of your architecture.
  2. Quality requirements will drive some aspects of your test strategy. Because they tend to be cross-cutting, and because they tend to drive important aspects of your architecture, they tend to drive important aspects of your test strategy.  For example, security requirements will drive the need to support security testing, performance requirements will drive the need for stress and load testing, and so on. These testing needs in turn may drive aspects of your test environments and your testing tool choices.
  3. Quality requirements will drive acceptance criteria for functional requirements (such as stories).  Quality 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 fulfills its overall quality goals, including applicable quality requirements.  This is particularly true with life-critical and mission-critical solutions.

Capturing Quality Requirements

Figure 2 depicts the goal diagram for Explore Scope.  As you can see, there are several strategies for exploring and potentially capturing quality requirements.

Figure 2. The goal diagram for Explore Scope (click to enlarge).

Explore Scope process goal


Let’s explore the three strategies, which can be combined, for capturing quality requirements:

  1. Technical stories.  A technical story is a documentation strategy where the quality requirement  is captured as a separate entity that is meant to be addressed in a single iteration.  Technical stories are in effect the quality requirement equivalent of a user story. For example “The system will be unavailable to end users no more than 30 seconds a week” and “Only the employee, their direct manager, and manager-level human resource people have access to salary information about said employee” are both examples of technical stories.
  2. Acceptance criteria for individual functional requirements.  Part of the strategy of ensuring that a work item is done at the end of an iteration is to verify that it meets all of its acceptance criteria.  Many of these acceptance criterions will reflect quality requirements specific to an individual usage requirement, such as “Salary information read-only accessible by the employee,”, “Salary information read-only accessible by their direct manager”, “Salary information read/write accessible by HR managers”, and “Salary information is not accessible to anyone without specific access rights”.  So in effect quality requirements are implemented because they become part of your “done” criteria.
  3. Explicit list.  Capture quality requirements separately from your work item list in a separate artifact.  This provides you with a reminder for the issues to consider when formulating acceptance criteria for your functional requirements.  In the Unified Process this artifact was called a supplementary specification.

Of course a fourth option would be to not capture quality requirements at all.  In theory this would work in very simple situations but it clearly runs a significant risk of the team building a solution that doesn’t meet the operational needs of the stakeholders.  This is often a symptom of a teams only working with a small subset of their stakeholder types (e.g. only working with end users but not operations staff, senior managers, and so on).

Related Resources

Posted by Scott Ambler on: January 23, 2018 01:17 PM | Permalink | Comments (0)

Strategies for Verifying Quality/Non-Functional Requirements

Early in the lifecycle, during the Inception phase, disciplined agile teams will invest some time in initial requirements envisioning and initial architecture envisioning. One of the issues to be considered as part of requirements envisioning is to identify non-functional requirement (NFRs), also called quality of service (QoS) or simply quality requirements. The NFRs will drive many of your technical decisions that you make when envisioning your initial architectural strategy. These NFRs should be captured someone and implemented during Construction. It isn’t sufficient to simply implement the NFRs, you must also validate that you have done so appropriately. In this blog posting I overview a collection of agile strategies that you can apply to validate NFRs.

A mainstay of agile validation is the philosophy of whole team testing. The basic idea is that the team itself is responsible for validating its own work, they don’t simply write some code and then throw it over the wall to testers to validate. For organizations new to agile this means that testers sit side-by-side with developers, working together and learning from one another in a collaborative manner. Eventually people become generalizing specialists, T-skilled people, who have sufficient testing skills (and other skills).

Minimally your developers should be performing regression testing to the best of their ability, adopting a continuous integration (CI) strategy in which the regression test suite(s) are run automatically many times a day.  Advanced agile teams will take a test-driven development (TDD) approach where a single test is written just before sufficient production code which fulfills that test.  Regardless of when tests are written by the development team, either before or after the writing of the production code, some tests will validate functional requirements and some will validate non-functional requirements.

Whole team testing is great in theory, and it is strategy that I wholeheartedly recommend, but in some situations it proves insufficient.  It is wonderful to strive to have teams with sufficient skills to get the job done, but sometimes the situation is too complex to allow that.  There are some types of NFRs which require significant expertise to address properly: NFRs pertaining to security, usability, and reliability for example.  To validate these types of requirements, worse yet even to identify them, requires skill and sometimes even specialized (read expensive) tooling.  It would be a stretch to assume that all of your delivery teams will have this expertise and access to these tools.

Recognizing that whole team testing may not sufficiently address validating NFRs many organizations will supplement their whole team testing efforts with parallel independent testing  .  With this approach a delivery team makes their working builds available to a test team on a regular basis, minimally at the end of each iteration, and the testers perform the types of testing on it that the delivery team is either unable or unlikely to perform.  Knowing that some classes of NFRs may be missed by the team, independent test teams will look for those types of defects.  They will also perform pre-production system integration testing and exploratory testing to name a few.  Parallel independent testing is also common in regulatory compliance environments.

From a verification point of view some agile teams will perform either formal or informal reviews.  Experienced agilists prefer to avoid reviews due to their inherently long feedback cycle, which increases the average cost of addressing found defects, in favor of non-solo development strategies such as pair programming and modeling with others.  The challenge with non-solo strategies is that managers unfamiliar with agile techniques, or perhaps the real problem is that they’re still overly influenced by disproved traditional theories of yesteryear, believe that non-solo strategies reduce team productivity.  When done right non-solo strategies increase overall productivity, but the political battle required to convince management to allow your team to succeed often isn’t worth the trouble.

Another strategy for validating NFRs code analysis, both dynamic and static.  There is a range of analysis tools available to you that can address NFR types such as security, performance, and more.  These tools will not only identify potential problems with your code many of them will also provide summaries of what they found, metrics that you can leverage in your automated project dashboards.   This strategy of leveraging tool-generated metrics such as this is a technique which IBM calls Development Intelligence and is highly suggested as an enabler of agile governance in DAD. Disciplined agile teams will include invocation of code analysis tools from you CI scripts to support continuous validation throughout the lifecycle.

Your least effective validation option is end-of-lifecycle testing, in the traditional development world this would be referred to as a testing phase.  The problem with this strategy is that you in effect push significant risk, and significant costs, to the end of the lifecycle.  It has been known for several decades know that the average cost of fixing defects rises the longer it takes you to identify them, motivating you to adopt the more agile forms of testing that I described earlier.  Having said that I still run into organizations in the process of adopting agile techniques that haven’t really made embraced agile, as a result still leave most of their testing effort to the least effective time to do such work.  If you find yourself in that situation you will need to validate NFRs in addition to functional requirements.

To summarize, you have many options for validating NFRs on agile delivery teams.  The secret is to pick the right one(s) for the situation that you find yourself in.  The DA toolkit helps to guide you through these important process decisions, describing your options and the trade-offs associated with each one.

Related Resources


Posted by Scott Ambler on: October 23, 2012 07:49 AM | Permalink | Comments (0)

Strategies for Implementing Quality/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

Posted by Scott Ambler on: October 14, 2012 10:39 AM | Permalink | Comments (0)

"Ambition is like a frog sitting on a Venus Flytrap. The flytrap can bite and bite, but it won't bother the frog because it only has little tiny plant teeth. But some other stuff could happen and it could be like ambition."

- Jack Handey