REQUIREMENTS CAPTURE
WITH USE CASES
ATL Innovations, Inc.
ATLInnovations.com
By Elmer Thomas
CEO ATL Innovations, Inc.
elmer@thinkingserious.com
May 2004
Contents
Executive Summary............................................................................................................... 3
Expected Results.............................................................................................................. 3
Introduction ........................................................................................................................... 4
Background ...................................................................................................................... 4
The Method ............................................................................................................................ 5
ACTORS........................................................................................................................... 5
USE CASES ...................................................................................................................... 5
The Next Step ........................................................................................................................ 7
Conclusion ............................................................................................................................. 8
May 2004 Page 2 ATLInnovations.com
Section 1
Executive Summary
The most difficult part of a project is arguably requirements definition and
analysis. This paper focuses on solving this problem using techniques from
Software Engineering; in particular, the use case technique.
Expected Results
With the knowledge gained from this white paper, you will be able to employ an
organized strategic method for discovering your projects’ requirements.
May 2004 Page 3 ATLInnovations.com
Section 2
Introduction
Background
A use case defines a goal-oriented set of interactions between external actors and
the system under consideration. Actors are parties outside the system that
interact with the system (UML 1999, pp. 2.113- 2.123). An actor may be a class of
users, roles users can play, or other systems.
A use case is initiated by a user with a particular goal in mind, and completes
successfully when that goal is satisfied. It describes the sequence of interactions
between actors and the system necessary to deliver the service that satisfies the
goal. It also includes possible variants of this sequence, e.g., alternative
sequences that may also satisfy the goal, as well as sequences that may lead to
failure to complete the service because of exceptional behavior, error handling,
etc. The system is treated as a "black box", and the interactions with the system,
including system responses, are as perceived from outside the system.
Thus, use cases capture who (actor) does what (interaction) with the system, for
what purpose (goal), without dealing with system internals. A complete set of use
cases specifies all the different ways to use the system, and therefore defines all
behavior required of the system, bounding the scope of the system.. 1
1This definition of use cases is taken from
http://www.bredemeyer.com/use_cases.htm
May 2004 Page 4 ATLInnovations.com
Section 3
The Method
ACTORS
The first objective (assuming the project goals are well defined) is to enact an
actor brainstorm. This activity is best performed in a group whom is familiar with
the overall goals of the project, as well as future system users. The goal is a
comprehensive definition of all users of the system.
EXAMPLE
Mr. Doe stands at a white board with a marker and asks the group to think of all
of the different users of the system (The meeting secretary should also record
everything on paper). Mr. Thomas suggests that current and prospective
students, staff, faculty, donators and alumni are typical actors. The actors are
drawn by Mr. Doe (and the secretary) using UML (Unified Modeling Language)
notation (Note: great artistic talent is not required):
Current Students
Alumni
Prospective Students
Staff
Donators
Faculty
USE CASES
For each actor a use case brainstorm is enacted. As in the case for the actor
brainstorm, this activity is a group activity. Preferably you would use a
representative sample from each of your defined actor groups.
May 2004 Page 5 ATLInnovations.com
EXAMPLE
The project committee decides to start with the Faculty actor for the first use case
brainstorm. A memo is sent out inviting faculty to a one-hour informal meeting
for the purpose of gaining insight to their needs in relation with the project. The
secretary at this meeting shall write the name of the actor at the top of a sheet of
paper and write down all of the use cases pertaining to that actor on the paper.
Mr. Doe goes to the white board and asks the Faculty; what would you like to be
able to do with the system? Don’t worry about any implementation details; we
just want to get a general idea. Professor Thomas says, “I would like to be able to
distribute class grades and easily find the phone numbers of other professors”.
Later another Faculty suggests a method to easily email other professors. The
diagram Mr. Doe has drawn thus far looks as follows:
Email
Other Faculty
Phone
Faculty
Grades Students
May 2004 Page 6 ATLInnovations.com
Section 4
The Next Step
At this point you now have a complete view of the system scope and boundaries.
The steps that follow occur at the boundary of system design. The early stages of
system design should be performed with experienced consultants in the area of
software engineering and/or design processes.
Following is a brief summary of the steps that follow:
1. Short use case descriptions are developed that include a short textual
description, actor relations, relationships to other use cases and rank (i.e.
risky, major, optional, quick win, etc…).
2. Conceptual definitions that are needed to define the system are created.
Each concept (i.e. physical places, transactions, external systems, events,
rules and policies, etc…) is defined and given attributes. After all of the
concepts are defined we find the associations and cardinality with the
other system concepts.
3. A throw away prototype is developed to further refine the requirements
and determine the feasibility of the project.
4. A complete review of the system is conducted to decide if the project
should proceed.
After these steps are completed the project proceeds in a cyclic process
summarized as follows:
Construction of the system begins by implementing a few use cases at a time
(this can be done in parallel). After each implementation, the project is tested by
both the programmers and beta testers (a potential user base). Feedback is
collected and the use cases are modified as required.
We then go back to the requirements to make sure the final product is indeed
meeting those requirements. Risk is re-evaluated (particularly for new
requirements) and new use cases are chosen for the next round of
implementation or previously designed use cases are modified as needed.
Using this iterative approach ensures that the final product is what is expected
by the stakeholders.
May 2004 Page 7 ATLInnovations.com
Section 7
Conclusion
The use case method should increase productivity when analyzing system
requirements. It is an approach that is non-technical and accessible to everyone.
THIS WHITE PAPER IS FOR INFORMATIONAL PURPOSES ONLY, AND MAY CONTAIN TYPOGRAPHICAL
ERRORS AND TECHNICAL INACCURACIES. THE CONTENT IS PROVIDED AS IS, WITHOUT EXPRESS OR
IMPLIED WARRANTIES OF ANY KIND.
©Copyright 2005 ATL Innovations Inc. All rights reserved. Reproduction in any manner whatsoever without the express
written permission of ATL Innovations Inc. is strictly forbidden. For more information, contact ATL Innovations Inc.
Information in this document is subject to change without notice.
May 2004 Page 8 ATLInnovations.com