All kidding aside, software requirements review sessions are anything but fun. The prospect of walking through page after page of documents, dissecting paragraphs and terms for hours on end trying to verify for completeness, accuracy, clarity, and fulfillment of business needs is very daunting.
As difficult as these sessions can be, they're often made even worse by the fact that people regularly don't read the documents ahead of time, come to the meeting without all relevant materials, are distracted by "urgent" issues on their mobile device, or drift off pondering an upcoming dinner with the in-laws. Simply stated, these requirements walkthroughs are not very effective and end up getting repeated multiple times. Even then, people sign off not so much because they have confidence in the result, but because of schedule pressure and reduced risk of personal impact ("I'm not the only one who signed," "There's enough wiggle-room," "We can just blame it on the developers or testers" …). My personal favorite was, "Your absence from the meeting will be interpreted as acceptance of the requirements."
It doesn't have to be this way
What if software requirements review sessions could actually be fun? If people actually requested to be on the invite list? If attendees could feel confident about what they are signing their name to? As the world of business analysis matures rapidly, so does the requirements walkthrough.
When the communication of requirements via "legal-style" documents begins to break down, think about how people communicate. They become animated, talking with their hands, drawing on a whiteboard. The existing application may be started up, and they point to the areas to be changed. Block diagrams or workflow pictures start to emerge. They may even dedicate some time to build a small prototype. This is great stuff. It can be very expressive and a great way to get an idea across.
But these g...
To continue reading for free, register below or login
To read more you must become a member of SearchSoftwareQuality.com
reat techniques often fall down. Why?
- The techniques are inconsistent across people. Some are good at it, and some aren't.
- It's difficult to impossible to ensure quality (completeness, consistency, integrity, etc.).
- It's virtually impossible to maintain integrity of this information as things change.
- It's inflexible in that you can't easily "drill down" to the details, or abstract up to the big picture when needed.
- Typically there's an array of tools used to support the various techniques and they're not integrated.
So how do we get the benefit without all the bad stuff?
The goal of any requirements walkthrough is to let your team be expressive without sacrificing the manageability of the information. Look for solutions that allow you to ensure the ongoing integrity of the information you're dealing with, while at the same time letting you communicate it in a variety of ways to suit the message and audience.
Ideally you want a solution that enables you to both create a requirements model and simulate that model. The model provides the "nuts and bolts" of the solution. It lets you ensure everything fits together, that there are no overlaps or inconsistencies. It lets you drill down to the details or up to the big picture, and gives you a framework to maintain the information as things change.
Simulation is the ability to bring the requirements to life similar to a prototype that you can execute and interact with. Simulation lets you be highly expressive when it comes to communicating with stakeholders -- it's sort of like watching the movie instead of reading the book. Ideally, you also want "multi-aspect" simulation. This is like letting each stakeholder independently control their own camera angle when watching the movie. Future end users can view the simulation from a user-experience perspective, interacting with functioning screen mockups of the user interface, and the designers and developers can view the simulation from a workflow perspective, considering business rules and monitoring how data will be used and acted upon.
Seeing the requirements from these different angles lets everyone truly understand the envisioned application. Feedback is informed and far more valuable. The number of review cycles, as you might imagine, drops.
So what does one of these requirements walkthroughs look like?
One of the first issues is that it's difficult to schedule a software requirements review with all the people you need. There are four approaches to solve or at least mitigate this one: 1) Attempt to coerce the person to join in a number of ways (e.g., have their boss make them attend). 2) Have them review the requirements on their own and submit feedback. 3) Make them want to come to the session. 4) If the reason they can't attend is primarily due to geography -- they're not at your location at that time -- reviewing remotely via Web meeting technology is certainly a viable option.
Coercion is likely the least effective option since, even if you do manage to get them to attend, you haven't set the stage for a cooperative, collaborative environment. Having those involved review the requirements on their own generally isn't as good as reviewing them together in person, since things can be misinterpreted which can take more cycles to resolve. Having people actually want to attend the session is the ultimate goal. Accomplishing this basically means two things -- make it valuable to them, and remove the pain. Using new requirements communication technologies like the simulation described above can achieve this. Let's walk through a scenario of preparing and conducting such a session.
Know your audience: Provide the right advance material to the right people
In advance of a session, you need to consider whether it would be more or less effective to provide documentation. On one hand, it gives people an opportunity to pre-read so their input is potentially more valuable, and they can take notes during the session. On the other hand, you could be giving them a distraction. The goal is to have everyone on the same page during the session, and having documents can be an invitation to wonder. In this example, Jay weighed the alternatives and supplied specific documentation to certain individuals. The point is that you need to think this through and make the call.
Lead through simulation
Performing a review using simulation is a new approach for most stakeholders. First impressions are key. Make sure you plan out how you're going to introduce people to this new approach and technology and get them comfortable with it so their focus of attention is on the content during the review.
The layout of your simulator is also very important. Different configurations are often available depending on what aspect you're trying to see. You need to try the various configurations beforehand and decide on one that is optimal for communicating with your constituents. For example, if you only want to communicate the effects on data at certain times, this information should be hidden at all other times so as not to clutter the experience.
Start with the "prime capabilities"
Even moderate projects have enough requirements to be overwhelming. The manner and sequence in which they're presented is important if you're going to communicate effectively. I recommend starting the walkthrough with main scenarios, or "prime capabilities" as some call them. Only after these are reviewed and agreed upon should you begin to tackle the various alternate and exception cases.
Apply basic facilitation rules
I've seen this happen several times, and just this quickly and dramatically. Some basic facilitation rules apply here -- ensure you keep the session on track. Record comments, make everyone feel included by prompting the quiet ones when appropriate, use the "parking lot" when conversations stray in order to record items to be dealt with later, and keep to your scenario plan in spite of people wanting you to go down alternate and exception paths. Before each scenario, state the path you're going to go down and do not stray.
Team up: Scribe + Facilitator = Success
These sessions often provide a significant amount of feedback, and it's helpful to have a colleague run the first session with you -- one plays the role of scribe while the other facilitates. You can exchange roles if the session is long, or maybe if you switch sets of requirements.
Do a dry run together beforehand
It is highly recommended that you dry-run a portion of the session beforehand. There's no better way to expose shortcomings and identify where you need to focus attention.
In summary
This isn't your father's software requirements review session. The unthinkable has happened. People from the business, end users, architects, designers, developers and testers are all engaged -- collaborating, exposing and solving issues, and doing so early in the development cycle. Not only that, they're actually enjoying themselves! The effect of discovering issues quickly becomes noticeable at the project level, as project durations shorten and fewer crises occur. This isn't a dream. It's actually happening at a growing number of companies today. Requirements walkthroughs have become fun and the trip to the dentist has returned to its rightful status as the most loathed appointment on the calendar.
About the author: Tony Higgins is vice president of products at Blueprint Software Systems Inc. He can be reached at tony.higgins@blueprintsys.com.
