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
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.
Executive Summary
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
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
Introduction
Background
This definition of use cases is taken from http://www.bredemeyer.com/use_cases.htm
1
May 2004
Page 4
ATLInnovations.com
Section
3
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):
The Method
ACTORS
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
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…). 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. A throw away prototype is developed to further refine the requirements and determine the feasibility of the project. A complete review of the system is conducted to decide if the project should proceed.
The Next Step
2.
3. 4.
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
The use case method should increase productivity when analyzing system requirements. It is an approach that is non-technical and accessible to everyone.
Conclusion
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