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

RDCP 250x200Interested 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

Free Training - Quick Start to Success

(Stop the frustration and earn the respect
you deserve as a business analyst.)

Click here to learn more

By signing up, you agree to our Privacy Policy.

Comments

  1. Laura, do you know of any free material to practice CBAP questions?

  2. Laura your posts on validating and verifying have really helped me think more carefully about the differences between the two tasks. It’s never a straight path through the requirements development process in my experience! I end up with at least one iteration of verifying quality (and completeness), finding missing requirements (or splitting up ambiguous requirements into more tightly defined requirements) and the re-validating the new requirements.

    I use similar techniques for nimble requirements validation (models/graphics, expressing requirements in agile user stories etc). I’ve also found breaking a large list of requirements down into smaller logical chunks (by feature, process or even process step) helps too. Eyes glaze over if we go more than 1 hour in our business 🙂 I create a contextual diagram showing the bigger picture and how the smaller pieces fit in and refer to this each time we start a new session of smaller chunks. This helps ground people.

    • Thanks for sharing Caroline. Yes, I would say verification and validation is often an iterative process for me as well, except for on the very smallest of projects. Love the idea of mixing a context diagram with textual requirements to be reviewed in subsets. That makes so much sense!

Before you go, would you like to receive our absolutely FREE training?

(No formal experience required.)

21689
21690

Quick Start to Success
as a Business Analyst

By signing up, you agree to our Privacy Policy.