A lot of rework still happens in projects applying UML techniques because of conflicts and omissions in requirements. To reduce rework, interactive storyboarding is effective, but it seems that projects using the technique are limited because of the few tools available.

To improve this situation, this article introduces the J-CASE open source Tag Library that lets us describe storyboards on JSPs based on use cases, and explains how to generate documents and UML diagrams from the JSPs.

To reduce the rework and improve quality of the requirements, we should carefully realize the use cases in the design stage. There are two approaches to realize (see Figure 1):

• Class definitions: Find classes and define object interactions. They’re represented in class and sequence diagrams, etc.
• Storyboarding: Describe detail scenarios based on use case descriptions, and add user interface information and system processes to be executed.

Ideally both activities are necessary. However, we tend to neglect the storyboarding in software analysis and design. Use cases only capture core functional requirements; they’re not enough for stakeholders to fully understand how the system will work. They don’t know what they really want to do with the system until they see the actual system we develop.

Storyboarding visualizes the use cases and shows stakeholders what the screens look like and what happens on each screen. It helps them get a better understanding and we can get more feedback before moving to implementation. Although storyboarding has lots of benefits, why isn’t it more popular? One reason is that there are few storyboard tools available. In storyboards, the scenarios defined in use cases are detailed, and abstract screens and process logic are also added. So the flows typically become complex and we can’t easily maintain them without tools.

The following features are required in storyboard tools:

• Interactive Storyboarding: The storyboards described should be able to execute on a simulator or Web site so that stakeholders can experience the story on screens.
• Easy Maintenance: The requirements represented on the storyboards are often changed. The data we need to modify has to be minimized. Tools should automatically generate supplemental documents and diagrams.
• Use Case Description Style: Since we’ve already captured requirements in use case descriptions, it’s better to describe storyboards using the same format so we can describe them by extending existing descriptions.

The tools available today fall into two groups. One is “storyboard tools” (tools for writing storyboards), and the other is “tools for drawing diagrams” like Visio, the UML tool, and PowerPoint.

Some storyboard tools are available to generate HTML for interactive storyboarding from screen and flow definitions, but these are commercial products and not cheap.