A few months ago I posted about how requirements walk-throughs are a necessity in any good requirements development process. I’m here today to tell you I’ve changed my opinion. It’s not that walk-throughs lack value. They definitely do. But the timing, scope, and methods of these reviews might need to be reconsidered. A structured requirements walk-through is not always appropriate.
So let’s take a step back and think about what problem we’re trying to solve with requirements reviews. In my opinion, reviews seek to align stakeholders around scope, either of an entire project or a subset of a project that directly impacts them. We want them 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. Why would we assume that walking through a document is the best way to achieve these objectives?
I don’t know. But I did and so do many other business analysts out there. I’m here today to say I’ve jumped off of this particular Ivory Tower and landed on a plush cushion full of contextual insights about how to achieve these objectives. By eliminating a “best practice” and replacing it with an open-minded acknowledgment that there are multiple paths toward achieving alignment, I feel confident my work on future projects will result in more meaningful approvals and scope sign-offs.
Instead of developing a new best practice to replace an out-dated one, consider some characteristics of your stakeholders and be clear about what you are trying to achieve. 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. I say that 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 feedback 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. 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?
- 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 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.
I’m new at this. Jumping off an ivory tower of a “perfect process” is never easy, but it’s almost always rewarding. What are some interesting ways you’ve used to get the input you need?
Related posts:




.jpg)
{ 10 comments… read them below or add one }
Visuals do speak louder than words, so rather than just static use of diagrams make use of interactive *visualizations*
See article linked above, for more info…
Cheers for sharing. I added a few techniques I have used Here.
Thanks for the information on reviews. I have to agree that less is more and focusing in on what is important to the various audiences is a great way to align stateholders.
I couldn’t agree more. In over 10 projects I’ve participated in recently, all with formal requirements review, I would say only one benefited from the structured review (a very complex system with a cohesive team used to long walkthroughs to discuss the changes from multiple perspectives).
One method I find very useful to engage senior management in requirements review is using comics, in a way similar to this: http://www.boxesandarrows.com/view/comics-not-just-for
(Even for more serious audiences in the financial industry, in my experience it tends to be a highly effective technique.)
Thanks for the article Laura. I couldn’t agree more with your article and comments.
However, I would be interested in people’s opinions about when IT IS necessary to have a requirements walkthrough.
There is a point when you need commitment or signoff from stakeholders. This is necessary when estimates are provided and requirements need to be frozen (not talking Agile here, obviously!).
In this instance, the requirements document is more of a contract and the walkthrough of the requirements is necessary to flush out any more issues and achieve consensus and signoff across a group of stakeholders.
It doesn’t make for a ‘fun’ event but I haven’t found any better way of achieving this goal.
Does anyone have a different experience or alternative suggestions?
Laura
Thanks for letting me know about the bad link.
My further comments are at Better Projects here
Hi Adriana and Alex….thanks for the great comments.
Adriana, I love the comic strip idea. I had not run across that one. I can definitely see where that would be a useful validation process!
Alex, if getting the contract signed “in blood”, so to speak, is the goal, then a formal requirements walk-through might just be necessary. But I’d venture to guess there are larger issues of distrust and missed commitments when that is indeed the goal and I wonder if there aren’t other ways of dealing with that issue head on.
When dealing with large amounts of requirements and huge volumes of documentation, an alternative may be to check all the high priority requirments with them, and then a random subset of lower priority reqs as a sample set. Additionally, if a prototype is part of the requirements delivery, it can serve to visually congeal the delivery for the customers, if it was created from the same requirements documentation that the eventual end product was.
I’m a wee bit disturbed at loosing the ideas/things remembered-feed-off-others in the meeting.
We removing the stakeholders from each other in separate meetings aren’t you going to loose too much of this?
Hi Chris,
Thanks for your comment. There are definitely times when it is helpful to have multiple stakeholders in a room together.
If your desired outcome is to generate a bunch of feedback, have everyone hear what everyone else has to say, and move relatively quickly toward alignment, this is probably a good way to move forward. But you have to realize that it might take more of each stakeholder’s time to go through all the requirements together and if too much of the meeting is irrelevant to particular people, you might loose their interest and fail to achieve your objectives anyway.
In general, it has seemed to work best to keep most of the stakeholders together at a high-level, then work through the more detailed requirements with specific groups. But you are right, you can lose some valuable cross-generation of ideas with this approach.
Laura