Assuming that the analyst has the basic abilities required to gather the necessary requirements for the system being created or modified, what can be done to insure that users actually understand what will be delivered? This is the question of the age!
Let’s cut to the chase and say this about communicating requirements: If you can’t give users a visual idea of how they will be able to complete basic tasks they’ll need to perform with the system, you don’t have ice cube’s chance in Death Valley of getting buy-in without re-working (repeatedly) tons of material.
With the ever-shortening attention spans of users it is imperative to find ways to help them "experience" the system early and often. The only way to accomplish this is with some sort of visual prototyping. Visual prototyping can be anything, including the following tools:
- Firefox Pencil
- et al
These tools give the analyst the opportunity to validate the requirements model behind the mock-ups. When the users can "see" how they will perform their roles in the new system, it puts "the system shall" listing into context they can understand. Expecting users to rely solely on static Word documents to validate the requirements is obsolete. With the proliferation of mock-up tools, there is no reason to avoid using them. And the price points are so low anymore, that avoiding them doesn’t make an economic sense to the project.. The cascading problems of dealing with "that’s what I asked for, but it’s not what I want", can no longer be tolerated.
I’ve used a combination of mock-ups done in Visio and animated with PowerPoint to create a remarkably inexpensive interactive experience for the users. One client, who was viewing an animated storyboard presentation exclaimed, "That’s it! How’d they get that built so quickly?" Her staff had to break the news to her that there was no code, but only animations. The point is, PowerPoint animation is very easy to use and can be applied to your package of storyboards in just minutes per mock-up. If you don’t have an animation tool, you can get started with PowerPoint with very little effort. You must put your hard-earned requirements capital into visualizations your users can experience early and often.
Let’s go back to the purpose of this blog, which is communicating requirements. We’ve talked about the tools to help the "how", now let’s talk about the "who". It is the analyst’s responsibility to manage the contributors and SME’s on the project to insure their direct involvement in reviewing and critiquing the requirements at every step along the way. The analyst must learn the work styles of each contributor and interact with them individually to insure their buy-in. If you don’t do this and just assume you know where they are, you’ll inevitably be left high and dry when it comes time to get sign-off. I know it sounds like a tremendous amount of effort, and it is. But at the end of the day, on every project, it is about managing relationships.
There is no one right answer, but there is one truth: The most successful analysts are those that develop an personal understanding of the project constituency, and do everything to insure that requirements communication is a group discovery process.