The Fairy Tale

The Fairy Tale

AKA Just Give it to me Straight AKA What’s the Bottom Line?

Problem

How should a use case description be structured?

Context

The requirements team are writing use case descriptions as part of the requirements capture process.

Forces

Stake Holder Needs

• The stake holder needs a clear understanding of what the development team will deliver. The stake holder needs to see this concepts expressed from the users point of view and with sufficient context

Business Setting

• Legacy methods. The team is comfortable with familiar methods (itemized requirements)
• No buy in from development team. Use cases have been mandated by management, but no one is sure why they are needed or how they are useful.

Team Composition

• Requirements writers unfamiliar with what use cases are all about.

Resources

• It is expensive to write good use cases

Solution

Structure the use case description as a fairly tale with an initiating event (Once upon a time there was an actor who wanted….), a sequence of events describing the interaction of the actors with the story (and then the big bad actor…) that describes how the goal is reached ( and they all lived happily ever after).

Resulting Context

The use case is structured as a story with an clearly specified initiating event, a sequence of actions between the actors and the system, and final the a goal.

Writing requirements as a story from the actors point of view helps the stake holders understand the services the system will offer.

This pattern helps the software development team understands their responsibility toward the stake holders that the use case is more than a functional requirement.

Rationale

The benefit of using use cases to capture requirements is that use cases capture the complete story of how an actor actually uses the system and does that from the actor’s point of view. A use case is a story that describes how an actor uses the system.

As a story, a use case needs to describe the actors, a goal, and the sequence of actions that brings the actor towards that goal. An improperly structured use case can deteriorate into a collection of related requirements rather than a description of how a system provides service to an actor.

Time pressure on a project may force use case authors to seek an easy way out of preparing use cases by simply reformat existing requirements documents. This can be observed in legacy re-engineering projects where use case writers may create what they believe are use cases by simply associating an actor with each legacy requirement.

See also UserStory