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:
- Cohesive
- Complete
- Consistent
- Correct
- Feasible
- Modifiable
- Unambiguous
- Testable
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.
I most frequently validate the requirements with the functional analyst prior to presenting them to the business stakeholders. I have found over the years that presenting in person is much preferred to emailing out with voting buttons. This can happen after the review.
Reviewing requirements is a static testing technique, I am a tester and have found inconsistencies and helped clarifying requirements.
Are there disadvantages in having the QA person to review the requirements?
Hi Belen,
I think there are more advantages than disadvantages as a QA review leads to a higher quality requirements document. One of the potential challenges or disadvantages might be level of detail – I’ve found that sometimes a QA review will be looking for a level of detail that might need to come from a lower level document, such as a design document provided by a developer. So without proper expectations in place, QA can drive too much detail into the requirements doc.
What has your experience been?
I am in the same position as Bob. However, I have always validated my documentation by checking that both my customer and my developer
a) understand
b) can see no conflicts/inconsistencies/gaps in what they are asking for/ being asked to do
A peer review may also be carried out by:
a subject matter expert to ensure that it makes sense, and by a completely independent person, who will ask a number of questions that in the asking and answering will question any internal assumptions made.
There are a lot of good points raised in this article, but I’ll focus on the notion of “peer review”. I instituted a peer review step in BA processes at my last job. There was only one other BA, and she was inexperienced in comparison to me, so it was a bit one way (kind of like the mentee example you provided) although I always asked for, as well as gave peer reviews.
An important part (especially in this situation, but true in general) of peer reviews is to provide the reviewer some guidelines on what they might be looking for. In other words, don’t just say, “look at this,” say, “check this for these kinds of problems”. A vague set of guidelines is the list of 8 characteristics you cite from the BABOK. A more detailed list is much more useful. Example: Every Data Flow on a DFD should have a source, a sink, a name, and be represented in the Data Dictionary with a list of data elements. (This is like a more detailed version of “Complete”). With good guidelines, the reviewer isn’t just “looking at it”, they are checking for violations of the guidelines. This obviously helps a lot with junior BAs, but it keeps even experienced BAs focussed on the task, instead of doing a free-form critique (or an eye-glazed “yeah, that looks fine”).
Hi Bob,
That’s a great point. There can indeed be some rigor put to peer reviews and when working with mentees I often ask them to let me know where they think they need the most help and how I can provide feedback that’s going to help them the most. Of course, I have my own internal checklists I use too so that I’m catching things they might not be thinking of.
In our peer reviews, we were all relatively new to the rigor of requirements analysis and so we discovered those kinds of guidelines as we discussed each others’ feedback and realized how differently we were all doing relatively similar work. It was really quite an enlightening process.
I think ‘peer review’ of your analysis is no different to ‘peer review’ of an article you submit to an academic journal.
At the end of the day, your ability as a BA will be judged by the quality of your documentation (and also your requirements management abilities).
There’s an apt phrase I keep in mind when writing my specs: ‘be prepared to eat your own dog food’ – don’t publish something that you wouldn’t be happy to receive from someone else.
Mike