When performing requirements validation activities, you need to know:
- That the requirements you’ve documented are accurate.
- That the requirements you’ve documented are complete.
Only your stakeholders can help you be sure of this. Circulating a 100-page document, asking for their feedback, and then waiting for the helpful responses to flood in is not an effective strategy.
Over the years, I’ve lost count of how many times I’ve laboured away producing, polishing, and publishing requirements documentation, only to end up feeling that nobody actually read it. As all BA’s know, requirements validation is a key component of requirements engineering, and yet often stumble at this crucial step. During development and implementation, new requirements keep surfacing, while the ones you had captured already churn and change chaotically. You can tell by the developers’ facial expressions and body language that they aren’t convinced you’ve nailed it.
In one moment of despair following some particularly painful projects, I inserted the line “if anyone reads this, I’ll eat my hat” into my Great Big Enormous Requirements Document. As it turned out, my (sympathetic) boss did spot it, but none of the stakeholders whose validation I was pursuing found it. This was not their fault!
Too often, requirements validation is seen as simply “sign-off” – a gateway to get through, and an opportunity to assign ownership. To obtain value from the exercise, validation needs to include meaningful scrutiny, feedback, and refinement.
Your stakeholders and subject matter experts are people with busy day-jobs, so time is critical factor. It doesn’t matter if you’re defining all your requirements up-front on a waterfall project or doing this iteratively in an Agile framework; to get meaningful validation and feedback, you need to make your requirements documentation as accessible as possible, and help your stakeholders engage with it effectively. This means removing some obstacles.
Don’t sacrifice accessibility just to adhere to a template
If you’re in a large organisation with formal change practices in place, chances are there is a requirements template. It might be a document template, a spreadsheet, a requirements management system, or an Agile development tool (such as Jira or Azure DevOps). All of these are supposed to provide a consistent way of capturing requirements, preferably in a way that supports the technical work that follows.
What these repositories are not geared around it is helping you make sure you’ve got all of the requirements, and that they’re correct.
If the format isn’t supporting you to present this information to your stakeholders and get meaningful feedback, find other ways. User stories are only meant to be a placeholder for a conversation. Use cases may be correct, but can you stakeholders understand them?
Nobody will remember that you filed everything nicely in Jira, but they won’t forget the project that failed to deliver on its promises.
Mix-up your presentation
Employing a healthy mix of presentation formats in your requirements documentation makes it more accessible for your stakeholders. Not everyone absorbs or processes information in the same way. Combining descriptive text, images, tables and models – particularly when dealing with complex or abstract ideas – can make it easier for stakeholders to make sense of things.
Making use of visual formats – use case diagrams, entity relationship diagrams, charts, grids – can really help visual thinkers rapidly absorb and understand information. They’ll soon spot what’s missing or incorrect in your images. Creating visual materials also forces you to think about simplicity and order, refining and condensing information down.
Some stakeholders may be sticklers for detail, wanting to be sure that you’ve captured the nitty gritty rules and logic. Much of this information can be kept in appendices or accompanying documents – don’t let it crowd out your core story.
Tell the story clearly from different angles
There are multiple dimensions to any set of requirements – functional requirements describing how a system will be used; non-functional requirements detailing quality needs; information and data structures provide a logical view; entities and artefacts transition between states.
As business analysts, we can find ourselves trying to tell the “requirements story” from every angle at once. This can make it very hard to see if anything is missing.
Give yourself space in your requirements documentation to present these different dimensions effectively. Some of these perspectives can get pretty abstract and nerdy, so be as clear as possible about what you’re trying to show.
Make sure to differentiate between analysis tools and expressions of the desired future state. A clever diagram you used in your analysis to uncover new insights may not be helpful in communicating requirements to stakeholders or developers!
Include contextual information about the business situation. This demonstrates you understand how this initiative fits within the wider business landscape, and can reveal where you’ve made assumptions or misunderstood fundamental ideas (and then defined detailed requirements on top of this).
Talk them through the requirements
If your stakeholders are really busy, you will get more “bang for your buck” conducting a requirements validation meeting than relying on them spending the time reading a document. It improves the chances of them actually securing the time, and you can help focus their attention where you need it (see below).
This is made easier with online collaboration tools like Miro or Mural, where you can lay information out visually and your stakeholders can interact with the content. I like to copy key information (especially graphics!) from the requirements documentation onto a Miro board and use this as the starting point for the conversation.
In Agile development, you’ll be far more reliant on conversations that documentation, so finding effective ways to play back the requirements you’ve defined to your stakeholders becomes even more crucial. Rather than one “big bang” requirements validation exercise, this work will be an ongoing cycle. Take advantage of that to build on each conversation, tailoring ways of working to get the most from stakeholder engagement.
Direct their time and efforts to where it will help you most
You need to maximise the value from your stakeholders’ time and engagement. You can do this by helping them understand where they can best apply their efforts:
Tell them which things you’re most concerned about getting wrong. Nobody expects you to get everything right first time, and it’s worth acknowledging that your stakeholders are the experts here. Showing some humility and being honest about those areas that might be less-than-watertight will reap dividends!
Highlight the things you still don’t know or that haven’t been decided. There are inevitably gaps in all requirements documentation. You may be waiting on a policy decision to finalise business rules, or you might have identified some edge-case scenarios where the process isn’t clear. Flag these clearly so that your stakeholders can fill in the blanks for you.
Signpost what matters most to different groups of stakeholders. Not everyone will be interested in the same things. Front-line workers may want to be sure the system will support their tasks. Managers may want to know a dashboard will give them the information they want. Directing different groups of stakeholders to the requirements that matter to them will save them time and increase the quality of feedback you get.
In conclusion
Many projects fail to deliver their expected value because of failures or errors in requirements definition. Agile practices can help mitigate this, as you have fewer eggs in your basket at any one time, but the principles still apply. On waterfall projects (for example where a solution will be purchased), where you’re expected to define all the requirements up-front, it’s even more important to reduce the risk of errors and omissions.
Applying some creative thinking to your requirements validation activities can help manage this, improving the quality of your requirements, and enhancing the value of delivered solutions.