While requirements walk-throughs can be a useful technique to get sign-off on requirements, they are not always appropriate.
Before exploring some alternative approaches, let’s take a step back and think about what problem we’re trying to solve with requirements reviews.
- Reviews seek to align stakeholders around scope, either of an entire project or a subset of a project that directly impacts them.
- We want stakeholders to understand what is changing and how this change will impact them.
- We want to reduce (or even eliminate) unnecessary rework by validating our assumptions, getting meaningful feedback, and working through options before we invest valuable development time in building the solution.
And I’d contend these objectives can be met using multiple different business analyst techniques. Walk-throughs are sometimes the best technique. But there are other ways to consider too.
Factor these into your approach to requirements reviews.
Who Are Your Stakeholders?
Do your stakeholders know how to read requirements? Seriously. Do they? Many of your most important stakeholders won’t give a lick about your beloved requirements and it’s self-centered of us to think they can and should. It’s easy to lay blame when these individuals don’t provide the feedback we’re looking for.
It’s our job to get meaningful feedback despite whatever short-comings our stakeholders might have.
- If they need pictures, draw pictures.
- If they are good at reading lists, create them.
- If they want a story, tell it.
It’s our job to keep all the various ways of communicating requirements in sync. It’s their job to meet you half way and provide meaningful feedback.
Here are just a few ideas for communicating scope across your organization:
- Create high-level documents, even slide decks for engaging presentations, for executive-level stakeholders.
- Consider one-on-one meetings for your most important stakeholders, such as the CEO, who hold the funds but probably don’t want the details.
- Compartmentalize the details that are important to each individual or functional group. Schedule separate meetings, unless their concerns overlap and you need to facilitate collaboration.
- Visuals speak louder than words, especially words that encompass requirements lists. Use diagrams to talk through complex processes and wireframes to simulate new software experiences.
- Save the details for the people who care and have something to say about them.
What Input Are You Looking For?
Before scheduling a requirements review meeting, take some time to consider your desired outcome.
- What do you want to achieve?
- What do you want to learn?
- What input do you need make the project more successful?
Here are some useful tips for getting the feedback you are looking for in requirements discussions:
- If your purpose is discovery, list out your unknowns in a list of discussion points for the meeting aka a meeting agenda). Organize them in a logical manner than aligns with a visual you can talk through.
- If your purpose is to validate and flesh out hidden assumptions, have a list of talking points to ensure the attendees are “thinking through” the process in the same level of detail you are. Maybe this can be accomplished through a use case review, but maybe you are just as well off talking through a diagram and keeping the use case to yourself.
- If your purpose is to facilitate collaboration where there is conflict, have a preliminary understanding of each individual’s point of view and some ideas for resolving the issue.
- What are the uncertain parts of the process you want to validate? Would a process walk-through be appropriate?
- What pieces do you know you know and can be skirted over or avoided in a review altogether?
None of this above should be read to say that requirements don’t matter or that the deliverables are unnecessary. I’ve analyzed many a problem by writing a use case that no one ever saw except the developer–the content of the use case was fully validated while the “use case” itself was not.
So yes, requirements matter for many, many reasons…but when it comes to reviews, consider separating how you document your requirements and how you communicate your requirements for the sake of getting meaningful, targeted feedback that will make your software projects more successful.
Get Better Input from Your Stakeholders
In Tested Stakeholder Interviewing Methods for Business Analysts, Adriana Beal walks you through how to conduct more effective stakeholder interviews so you don’t overlook critical requirements.