Many business analysts use Unified Modeling Language use case diagrams to identify the actors and their high-level actions in a system. These diagrams help an analysis team clarify and understand the project domain and high-level functions. Unfortunately, UML use cases fail to tell us much about the details of a system. They define “who” and “what” pretty well, but don’t tell us “when,” “where,” “why,” and “how.” Learn how to transform high-level requirements into a set of story titles that can be applied toward functional requirements.

This blog post is also available in PDF form in a TechRepublic download.

Importance of stories

Recognizing the importance of UML to a business analyst, you may wonder why stories are also important. In a broad sense, stories help us make sense of ourselves, each other, and our world. Think about the last movie you saw, or a book you read. If the story was told well, there is a good chance you can retell it. You probably remember when a critical event occurred, along with the sequence of events, and who was involved. Through the story, you also understood a participant’s motivations, perspectives, and behaviors.

It may not be a surprise to hear that story writing is a very powerful tool for the business analyst. In this article, we learn how to transform high-level requirements into a set of story titles. Future articles in this series will describe how to evolve these titles into clear, succinct, and comprehensive narratives about a business process. Written in a language both functional staff and technical staff can understand, each detail-level use case narrative is a story that answers the “who, “”what,” “when,” “where,” “why,” and “how” of a business process. Collectively, these narratives speak volumes about a system and its functional requirements.

Starting from a foundation

We began the process of writing use case narratives by helping the analysis team define high-level system requirements. If you followed that process, you have a good foundation for defining the system’s functional requirements. Whether you have 50 or 500 high-level requirements, you can now help the team organize them into manageable chunks.

As a product of your work with the team, let’s assume you now have a rough set of high-level requirements in an electronic document. Before meeting with the team, give members an opportunity to review the high-level requirements and fill some holes. It will simplify communication during the meeting if you number each high-level requirement in the electronic document before sending it to the team. Ask each person to come to the next meeting prepared to improve on the requirements. Send along an agenda for that meeting containing two work tasks: “Clarify Requirements” and “Organize Requirements.”

Before the meeting, copy the requirements text into a new document and arrange three or four requirements on each printed page. Increase the font size to allow easy reading from about four feet. Print the document and cut up the pages so each requirement appears on its own piece of paper. You should end up with a set of readable 8-1/2 by roughly 3 inch strips of paper, each one with a requirement on it.

Let’s call these slips of paper the “requirement notes.” It is a good idea to make a second set of these notes as a duplicate. To complete your preparations, also bring to the meeting the usual materials: a flip chart pad, masking tape, and several narrow-tip marking pens. Bring along some half-sheets of letter-size paper on which to write new high-level requirements. Just before the meeting begins, hang flip chart pages side by side on a wall. You’ll need enough flip chart pages to hold the high-level requirement notes comfortably — figure roughly eight notes per flip chart.

Clarify the requirements

Start the meeting by introducing the team to what they will be doing. Briefly explain the purpose of the flip chart pages on the wall and talk about the set of requirement notes. Begin work on this first agenda item by spreading the requirement notes out on a large table. Give team members time to stand up and review their previous work. Encourage members to take a marker and amend the requirement notes. Ask them to use the half-sheets of blank paper to record any new requirements they discover.

The team’s first activity shouldn’t take more than 10 minutes or so. You can measure the completeness of their work by checking for inactivity among the group. Be silent as they work. An ancient proverb comes to mind — “A word is worth one gold coin; silence is worth two.” Leave the group standing for a minute and let them survey the set of requirements one more time.

Organize the requirements

Now you may introduce the second agenda item to the group. Explain that you would like them to arrange the requirement notes on the wall. Have plenty of strips of masking tape ready for affixing the notes to the flip chart pages you hung earlier. Ask them to group the requirement notes that seem to fit with one another onto the same flip chart page. Tell them that there is a duplicate set of the requirement notes available if someone finds a requirement that belongs on two pages. Encourage them to talk as they work, and to rearrange the notes as they see fit. Again, be patient. Give people time to organize their thoughts.

When the work seems done, have them take a short break and ask that they return in five minutes. While they are away, read the flip chart pages. When team members return and are ready to begin, ask them to reevaluate the requirement notes posted on the flip chart pages. Assign one or two volunteers to a single flip chart page. Ask each sub-team to evaluate its assigned page. Do the requirement notes seem well organized? Do all of the notes seem appropriate for the page? Should a new requirement be added to the page?

Give the sub-teams about 10 minutes to complete their work. When the whole team seems ready, have each sub-team summarize its flip chart page to the whole group. Team members are likely to hear a well organized feature set for the system categorized by sub-system. As a final exercise, have the team spend a few minutes examining the whole set of flip chart pages and adjust or add notes as they see fit.

This meeting will probably require about two hours. At the end, spend a few minutes describing how you will use their work. Indicate you will group the requirement notes and develop use case titles for them. Explain that a use case title describes an actor in the system doing something. A title is a simple declarative statement in the form “actor-verb-object.” If I were describing my commute to work as use case titles, I would include “driver starts the car,” “driver picks up carpool rider,” and “driver drives to work.” Based upon your own review during the team’s break, you can probably suggest meaningful titles to the group.

Next steps

The deliverable for this meeting is something I’ll call a use case catalog. Create an electronic document that contains a table with two columns. In the left-hand column, write a use case title that describes a group of requirement notes from a flip chart page. In the adjacent right-hand column, copy and paste the electronic requirement notes that fit under the title’s umbrella. (Since tracing the origin of a requirement is important, carry along the number assigned to the requirement as well.)

For example, if the requirement notes described the features of a new accounting system, we might have use case titles such as “Clerk sets up a new account” and “Supervisor overrides an accounts payable exception.” As you develop this document, you will notice that some of the requirements seem like process-oriented steps. Others seem like business rules or constraints. Some requirements may not fit at all. If you can’t find a home for a requirement, be honest about it. Place it in a row in which the use case title is simply “Unknown.”

Lesson learned

Following a core principle makes this whole process successful. Remember that while you own the process that the team is using, they own the requirements. While a home may be found for the orphan requirement, the team is best suited to find it. They may decide it is not really a requirement, or they may add another half-dozen requirements they hadn’t considered. You must show them the path to producing good requirements, encourage them to explore what they require of the system, and advise them to make good decisions along the way. Let the tension inherent in early, fuzzy requirements drive them to create clarity. Despite imperfections, or because of them, send the newly drafted use case catalog to the team.

The next article will describe how the team will revise the use case catalog document and how to start writing use case narratives from it.