Requirements verification ensures the intrinsic quality of the requirements. Although it would be a significant waste of time outside academic circles, I could verify requirements for a solution that had zero business value and that my organization had no intention of funding. They’d be verified but not validated.
The purpose of Verify Requirements is to:
“Ensure that requirements specifications and models meet the necessary standard of quality to allow them to be used effectively to guide further work.” (114)
The BABOK lists 8 characteristics of requirements quality:
There are three types of requirements verification I’ve performed as a business analyst.
- Verified my own requirements.
- Verified others’ requirements (on a shared project).
- Verified requirements for a mentee or coaching client.
Let’s take a quick look at each type of work.
Verifying My Own Requirements
I’ve never sent out a document I haven’t gut-checked against the quality standards I knew about at the time. And, really, producing verified requirements is the baseline of skill required to be a good business analyst. If your requirements are full of inconsistencies and ambiguities, it doesn’t matter how good you are at using elicitation techniques or communicating about the requirements.
For me, this kind of verification means I read and re-read my requirements, looking for items that don’t match up, terms that are used inconsistently, or requirements that will not be clearly understood. It also means that I’ve done some analysis, looking for holes that would indicate the requirements are incomplete.
For example, if I’ve included a requirement to edit a set of information, do I have a requirement to create that information? Do I need a requirement to delete it as well?
Regardless, I’ve had stakeholders, especially testers (we love them, don’t we!) find new holes, inconsistencies and ambiguities. I’m not as perfect as I’d like to be! 🙂
Verifying Other’s Requirements
In my very first BA role, I initiated a BA team meeting where we each took turns presenting our requirements to the other BAs on the team. We were a young and relatively immature team in the sense that we were all applying slightly different standards of quality to our requirements documentation. We also didn’t have any specific bar for what “quality requirements” meant. So by reviewing each others’ specs we gradually aligned our practices and became more consistent across projects.
But even before I became a BA, I participated in requirements verification. One of the quality characteristics is “testable” and as a QA engineer I would review requirements to ensure I had the information I needed to test them appropriately and ensure the requirements were met. Often this feedback was provided during document review sessions or collaborative design sessions.
Verifying Requirements for a Mentee or Coaching Client
Finally, I’ve verified a mentee’s requirements specifications. From a BA career perspective, this was a watershed moment for me, when I realized that I could assess the quality of a requirements specification without having much context for the business domain or the project. It’s actually quite amazing what you can find. Inconsistencies stick out like a sore thumb when you don’t understand the business language and I am finding more ambiguities because of my outsiders’ perspective. This is also a feature of our virtual, instructor-led courses, which all include documentation reviews.
This post is one installment in our Journey Through the BABOK with BA Stories series.