Prepping Your Requirements For Primetime: Verifying Requirements

In part one of this three-part series on readying requirements, I proposed that they must pass through three gates defined in the IIBA BABOK. These gates ensure the requirements are ready to be used by the rest of the project team, or as I like to put it, ready for primetime. In part one, I talked about the first gate – confirming elicitation results. Through this process we normalize the raw information we gathered, ensuring it is accurate, consistent between stakeholders and completely describes the dimensions of the problem or opportunity we are solving for.

The second gate is requirements verification, which is covered in Chapter 7 of the BABOK. After we develop a formal list of requirements and prioritize them based on our confirmed elicitation results, we need to ensure they are detailed and high-enough quality that stakeholders (especially technical stakeholders) can act on them. It enables the project team to correctly execute on each requirement to solve the business need.

The verification gate is the most detailed of the three, because we have to examine the requirements in a whopping nine different ways, and ideally, they should pass muster in all of them. More on that in a minute. I like to think of these as “nonfunctional requirements” for requirements, because like nonfunctional requirements they are a performance check for how well we have told a story. The nine characteristics described by the BABOK are:

• Atomic: self-contained and capable of being understood independently of other requirements or designs.
• Complete: enough to guide further work and at the appropriate level of detail for work to continue. The level of completeness required differs based on perspective or methodology, as well as the point in the life cycle where the requirement is being examined or represented.
• Consistent: aligned with the identified needs of the stakeholders and not conflicting with other requirements.
• Concise: contains no extraneous and unnecessary content.
• Feasible: reasonable and possible within the agreed-upon risk, schedule, and budget, or considered feasible enough to investigate further through experiments or prototypes.
• Unambiguous: the requirement must be clearly stated in such a way to make it clear whether a solution does or does not meet the associated need.
• Testable: able to verify that the requirement or design has been fulfilled. Acceptable levels of verifying fulfillment depend on the level of abstraction of the requirement or design.
• Prioritized: ranked, grouped, or negotiated in terms of importance and value against all other requirements.
• Understandable: represented using common terminology of the audience.

Why so many criteria? No matter who the audience is, or when they read the requirement they should be able to understand the business objective addressed. A requirement from today’s project could become relevant again in future projects, either as source material or as a reusable requirement.

When it is atomic, concise, and understandable, the reader can understand the story without the benefit of additional context provided by other material. It can stand alone and still convey what we want to achieve by it. There are no extra adjectives or fluffy words, only the minimum necessary to convey the full intent. When a requirement is complete, prioritized and testable, the reader has enough information to plan their work, build a solution and demonstrate how it satisfies the requirement. When it is unambiguous, consistent and feasible, the reader clearly understands how the requirement addresses the business need, how it works in concert with other requirements to solve the challenge, and that it is realistically achievable, given influences like risk, budget, and potential value.

Requirements verification doesn’t end with a document. Rather, it’s a mental checklist for evaluating the quality of your work. If I am writing a user story, and I feel compelled to include a lot of supplemental context, it’s probably not “unambiguous.” It definitely isn’t “concise.” If I cannot describe what the requirement will do to support the need, I probably haven’t thought through it’s testability.

We never get requirements perfect. Instead, verification is about balancing the characteristics of well-articulated requirements against our work environment and writing them well enough to move forward. This is especially true for those of us who work in DevOps or Agile shops. So, instead of holding yourself rigidly to this standard, consider what is most important within the context of your situation, and adjust accordingly.

Learn more in part one and three of this blog series!