How to Validate Requirements (BABOK 6.6)

Did you know that requirements can be perfectly well documented and verified, but completely useless? This is why business analysts not only verify requirements, but also validation them.

In the BABOK Guide, the purpose of Requirements Validation is defined as follows:

Ensure that all requirements support the delivery of value to the business, fulfill its goals and objectives, and meet a stakeholder need.

It’s Easy to Conflate Validation and Verification

Many BAs, myself included, conflate requirements verification and validation. (Here’s a challenge: Read the comments on the Requirements Verification post and see if you can find evidence of validation instead. And be nice. We’re all learning here.)

It wasn’t until I was deep in my preparation for the CBAP exam that the difference finally sunk in. And still, in reality, the activities of validation and verification are often done together. We might hold a requirements review and in the process discover ambiguous requirements (verification) and unneeded ones (validation).

In fact, very often I’ve found that an ambiguous requirement is ambiguous because the business value is unclear. We might start debating the semantics of a term and discover we’re solving the wrong problem and end up throwing out the requirement completely.

In my early days as a business analyst, my requirements verification and validation activities happened together, in a big room or an over-crowded small room with business and technical stakeholders walking through a draft of the requirements specification…

r e q u i r e m e n t

…….

by

……..

r e q u i r e m e n t.

But as I reflect more deeply on my requirements validation experience, walk-throughs, while the obvious candidates, don’t make up the half of it.

If You Are Doing It Right, Validation Happens Early, And It Happens Often

Before we even had a draft specification, I was meeting with the primary business stakeholder to iterate through potential requirements, understand the business value and fit them together in a logical way. I was clearly, but unknowingly, doing validation. The BABOK recognizes this too. It says:

Requirements validation is an ongoing process to ensure that stakeholder, solution, and transition requirements align to the business requirements.

So in those early meetings with the sponsor, I was ensuring the alignment of stakeholder requirements and business requirements. In the detailed meetings with the entire stakeholder team, I was ensuring alignment of solution requirements and business requirements.

But since those early days, most of which involved big thick requirements documents and (yes, and) detailed use case specifications (oh, my, the documentation to validate and verify!), I’ve developed some much more nimble requirements validation practices.

Here Are Some Nimble Ways to Approach Requirements Validation

• With one particular client, I used a series of click-through wireframes to walk my stakeholders step-by-step through the requirements.  I subsequently documented the textual requirements in user story format for the technical stakeholders. This required a lot of ownership – I was primarily responsible for ensuring the stated requirements specifications reflected the business needs and requirements – but it worked amazingly well for this stakeholder group. And that’s requirements validation.

• Another nimble example goes into the way back machine… way back before I was a BA. As a QA engineer, I was responsible for pulling together bug reports and a recommended priority of addressing each fix. What I was really doing was aligning all of these “change requests” to the original business case for the project and sorting them by the value that fixing them would have to the end user.  And that’s requirements validation.

• While new to an agile software environment and creating a product backlog, I immediately saw the value of the “value” statement that gets embedded right into the user story syntax: “As a {user}, I want do {do something} so that {perceived benefit}. Right there in that third part? That’s the business value. Instead of manually tracing functional requirements to business requirements and potentially overlooking the actual contextual connection, the syntax forces you to contextualize the business value into each and every requirement you write. And that’s requirements validation.

Requirements validation is a critical activity. And while sign-off is often thought of as the tried-and-true way to validate requirements, the reality is that every question you ask to ensure the completeness of your requirements and their link back to the business need is part of requirements validation.

This post is one installment in our Journey Through the BABOK with BA Stories series.

>>Learn How to Ask the Right Questions During Validation

Interested in receiving a comprehensive set of questions you can ask in almost any project context? Want to feel more confident asking questions in a new domain? The Requirements Discovery Checklist Pack includes over 700 questions, categorized and cross-referenced so you can prepare for your next elicitation session with a sense of ease and confidence.

Click here to learn more about the Requirements Discovery Checklist Pack