|
|
|
|
| Writing Effective Use Cases, Part I |
|
Developing use cases is both a simple and structured way to define requirements for a
software application.
- Ed Carroll, Sales Executive, Agilis Solutions
August 2, 2006
|
|
| Introduction |
|
In the early 1990s, the Object Modeling Group (OMG) came up with its Unified Modeling Language
(UML) by consolidating competing object analysis and design methods (desiring to unify – rather
than compete). In the process, the group recognized the need for a simple way to begin – a simple
way to gather the “what” that the new system was supposed to do. The obvious answer was to collect
statements from the users – in other words, use cases. In their most basic form, use cases capture
the functions of the “application to be” in an easy and straightforward textual context, from the perspective
of the domain expert. Information gathered is structured in such a way that the system developers will eventually
(after additional analyses) end up with the information they need to build the new application, but start the process
by capturing requirements in the language of the domain expert.
This is an important first step for many reasons. The domain experts are, of course, more comfortable
with their own language; however, what is more important is that the use cases become an effective tool
to draw the domain experts into the larger development process because they feel that their ideas have been
heard. As their ideas evolve and morph through the various analyses, object models, prototypes and into design
notation, the domain expert should be able to see their ideas taking form, and thus remain engaged.
|
| Start with a template |
Gathering simple unstructured text from domain experts will seldom lead to the type of information or the
information detail needed to develop a software application. Therefore, structure the information to be gathered
from domain experts by using a template. Some examples of topics that belong in a good template include:
- A context diagram – illustrating what actors will interact with the system
- Description of actor(s) – the persons, positions or other applications that will act upon (interface with) the new application.
- Successful preconditions
- Successful post-conditions
- Goals
- Triggers
- The primary scenario – a description of tasks in narrative form describing user actions and expected system response.
- Alternative scenario(s)
- Business rules
- Data requirements (high-level entities only)
- Assumptions
- Open issues
- Non-functional requirements – those directly relevant to the specific use case
A good way to get the domain experts started is to have them delineate a simple task list, followed by a good
"why" question-and-answer session that fleshes out the subtleties of why a task is performed, and why it has the
priority it has, and why the tasks are performed in the order they are performed in. The answers to the "why" questions
can provide the inspiration that leads to breakthrough automation. Too many software products simply automate manual processes
(that were created for an entirely different set of conditions), and do not take into consideration the massive advantages that
automation can sometimes provide. Be sure to capture as many specific examples, particularly mathematical algorithms, when defining
a use case of any complexity.
Domain experts who are not experienced at defining use cases for software applications will need a thorough
explanation of the terms commonly used in software development – including the terms listed in the use case
template.
Since one of the objectives of use case analysis is to help the domain experts feel as though their ideas
have been heard, it is important to use good active listening techniques to make the interview process personally
rewarding to the domain expert. After all, if they are true domain experts, then their active involvement is needed
throughout the software development lifecycle, and that happens only if they feel their contribution is appreciated.
|
| Management tips |
|
Developing use cases is an iterative process, often working from brainstorming sessions (domain experts
love brainstorming sessions). Start with a broad brush approach that captures the initial list of use cases
by name, primary actor(s) and description, then iterate through the list capturing subsequent detail. Through
a basic description of each use case (the set of tasks for each), make a preliminary determination of the complexity
(simple, average, complex) – basing the complexity on the number of transactions.
From this point, an initial timeframe for the duration of the analysis effort can be estimated. Experience
developing use cases will provide a rule of thumb for determining how much time it will take to flesh out all
use cases, based on their complexity.
After the first or second iteration through the use case list, it is important to step back a bit and
re-examine priorities and organization. An initial object model created from the list of use cases will
help determine re-organization of the use cases into modules, releases, etc. Many project managers omit
this step, instead plowing through the entire list of use cases to the lowest detail. There is a tendency
to assume that all initial decisions are always valid and must be held in lapidary form in perpetuity – and
it seems that the larger the project, the more prevalent is this tendency. As use cases are developed, it is
very common for them to be combined or split from the original list, other subject matter experts identified
and their knowledge leveraged. It is important to maintain a flexible attitude throughout this evolutionary process;
change happens – be prepared to adapt.
Successful projects have a typical pattern – for one, the project team is able to work multiple aspects of an
analysis in parallel. As an example, reviewing domain experts and developers should review use cases together –
interacting with each other’s interpretation of the details. In another example, as developers gain understanding
of the use cases, the developers should create prototypes of what they learn – working iteratively – progressively
refining both detail and concept – being ever-mindful of what is possible (over the manual way).
|
| Conclusion |
|
Developing use cases is both a simple and yet still structured way to define requirements for a
software application. The process allows domain experts to express their need in their own language,
yet act as an effective launch pad for complex software product development. Tailor the template for
use case definitions to your own needs to provide effective project documentation. Just be sure to understand
that use cases are only the starting point for analysis and understanding of complex software applications. |
| About the Developer |
Ed Carroll
Sales Executive, Agilis Solutions
Ed has been building software products for more than 20 years, with
particular expertise in automating economic analyses, decision support and
supply-chain management processes. He is currently a sales executive with Agilis
Solutions and has provided strategic technology leadership in roles such as the vice
president of engineering for Egghead.com, director of technology at Nike and director
of software engineering at Boeing.
Contact the author.
|
|
|
|
