Requirements Visualization, V1

Charles Field, Thursday, March 30, 2006 @ 9:48 am

At Pathfinder, we have developed some responses born of our collective experiences to the problem of huge requirements documents.

The problem is that on a complex project, a network of interdependent decisions is constructed, then shoehorned into an essentially linear document. While this functions as a form to analyze these problems, it's very [linear] nature makes it... well, boring! Even developers and designers are human!

The functional result is that it ends up as a doorstop somewhere in the office, or finds a quiet angle of repose near a bookshelf and no one ever reads it. These typically represent months of work by large, passionate teams and great expenditures. Not an ideal outcome.

What can prevent this? With all our focus on our favorite personas, and the scenarios we construct to walk them through, it is easy to forget that the person who was just handed 150 pages of your careful work is arguably your most important audience.

Take a moment and review that the order of the parts feels obvious. Make sure that the document has a clear and accessible structure. This means a contents page with content areas that have immediately understandable names. Even though it may seem unnecessary to you, having spent the last 4 months on it, a general overview that orients a first time reader is appreciated. This sets them up for the detailed decisions that follow. Starting someone in the middle of these processes, as I too often see, tends to make people glaze over and just make it up as they go.

Comprehension is more important than brevity here - at PFA, we find that annotated pictures are far more specific & engaging than trying to describe with only text things that can be easily shown. If that adds pages to the document, it is a small price if it gets read and understood. These visualizations do not need to be elaborate. In fact, we are facile at understanding abstracted representations - look at the drawing languages of cartoons. The messages are clear, despite the fact that Mickey has only three fingers or Charlie Brown has a single squiggle that stands for hair.

In sum, showing what you intend is powerful, yet doesn't need to be elaborate in production. The other side of the coin is to spend endless amounts of time illustrating a solution at the expense of more iterations, but that's another blog.

Related posts:

1. Writing Agile Requirements
2. Wireframing with incomplete requirements
3. We Don’t Need No Stinkin’ Requirements
4. Another Way to Pair Program: Generating Requirements
5. Requirements Set in Stone and Software Made of Concrete

Comments (0)

User Experience Design

Comments

• Leave a comment
• Comment feed for this post
• TrackBack URL

None so far.

Leave a comment