use_cases
Source:
<![CDATA[
Software Development March issue 1997
"Listening to the Customer's Voice" by Karl Wiegers
Object-Oriented Software Engineering: A Use Case Driven Approach
(Addison Wesley, 1992)
]]>
Use Case analysis allows a group of meeting between users and code
developers to answer a fundamental question:
<![CDATA[
"What do you need to accomplish with this system?"
]]>
In specific:
<![CDATA[
"Identify tasks to be done with this system"
"Identify reasons why they need to use this system"
]]>
These answers are expressed in terms of the user. Often, each task
or reason becomes a ``use case'' ... a point of action for the user.
For each action, there should be a response. Group actions together
by function to reduce the use case load. These actions share a
common goal or purpose and can be measured for frequency of usage.
Below is a simple example given in the March 1997 Software Development
article by Karl Wiegers where he discusses gathering use cases from
user workshops:
<![CDATA[
User Classes: All
Purpose: Let the user view a stored order
Frequency: 5 orders viewed per user per day
User Actions System Responses
User enters order number Order is displayed in
to view an order. detail.
User enters order number Error displayed: No
but it doesn't exist. such order exists.
]]>
Karl Wiegers uses adhesive notes so that actions and responses may be
easily shifted, put in priority order, added to and still maintain the
complete assembly of use cases.
<![CDATA[
o Use case
- User classes
- Purpose/Goal
- Frequency
- table of user actions / system responses
]]>
The table of actions and responses is often developed with a flip chart
using adhesive notes that can be moved easily to reflect changes,
priorities and other refinements in the process.
Each entry in the table correstponds to a scenario.
Doing a use case workshops allows a software analyst to derive complete
software requirements from the users familiar with the application. The
documents described below should still express the application in
user terms. These documents include:
<![CDATA[
o Functional Requirements
This contains all functions needed in this application as defined by
the list of use cases. This should delineate classes of users so
their role is documented.
o Dialog Maps
This contains all views of the application as the user will
see it.
o Business Rules
In the process of describing the applications, the user will
state business rules which help drive the application logic.
Some designers will express rules within scenarios for hard
to understand situations.
o Test Cases
This contains a test for each use case within an application.
This step allows the application to be verified by both the
user and designer perspective.
]]>
Verification means a walk through to check off each case to look
for missing cases, mis-information and other errors. One example
is to look at each test case while checking off all user cases
and dialog map function points. The application developer can
use the test case as a test of the core functionality of the
application.
The first workshop shakes out preliminary use cases. The draft
documents can then be created. Users then need to review draft
specification and participate in a walk through.
The walk through of each individual use case allows the team
to get to fundamental user needs. Each case can be explored to
reveal exceptions and decisions the system would have to handle.
A following workshop shakes out dialog maps and refines the user
view of the application. It further refines business logic.
Other business logic which drives application decision should
be kept under business rules. These are documented separately
so that conflicts between user business rules can be caught
and resolved early. Another review should check business
logic with the users.
A final review walks through each test case and determines
that all use cases for a particular implementation will be
covered.
Remember to Keep asking:
``What do you need to accomplish with this system?''
<![CDATA[
o Assign a program champions to do the following:
- represent the user program development
- put together user workshop team
- review requirements
- refine requirements
- find any missing cases
- resolve issues with other program champions
This person is a knowledgeable user.
o Assign a moderator to walk through each case to do:
- serve as a moderator during the review
- identify new use cases
- identify new business rules
- verify each use case given in the requirements
- verify each dialog map given in the requirements
- verify each business rule given in the requirements
- verify each test case given in the requirements
This person knows object analysis
o Assign a designer who owns final specifications:
- write up use cases
- write up functional requirements
- map out a software strategy with priorities
- write up dialog maps
- write up business rules
- write up test cases
- distribute any specification several days before a review
This person owns the project
]]>
The designer takes each use case and generates functional requirements,
dialog maps, business rules and test cases on each user function.
These documents are reviewed by the workshop team.
User priorities allow the designer to map out a software strategy which
encourages stepwise refinement of the application. The test cases
enable the application to be tested by user function. The frequency
of use case estimations allow benchmarking along the lines of intended
application usage.
The next phase is the various walk throughs for use case analysis to
verify the design. This includes a use case review, a dialog map review,
a business rules review and a test case review.
Management issues and management reporting do not belong in walk
through sessions. The user team should not feel uneasy about
looking openly at the user issues. If statistics are gathered from
session to session, they should be gathered as a collective group
over a period of time.
Organizations report:
<![CDATA[
Use cases per hour should be tracked
Optimal time to be 1-2 hours
Exposure to the overview benefits the group
This identifies software that reflects a "real life" model
Use case interfaces can be exercised and tested within a model
]]>