Use Case Specifications
Use Case Diagram
[This section shows all the actors (users) and the
use cases (actions) of the system in a diagrammatic form]
[[[
A Use Case is the highest unit of specification in
UML. The system is considered to be a black box interacting with external Actors. An actor
is someone or something, external to the system but which interact with the system. An
Actor or User might be a person, another information system or a hardware device. The Use
Cases specify what the end user will use the system for. It is a construct for showing how
a system looks to a user or in other words it is a way to use the system. A Use Case is a
pattern of behaviors the system exhibits. The collection of Use Cases specify all the ways
of using the system. There are Use Case diagrams, which shows relation between actors and
use cases in the system. They must be written from the viewpoint of the user of the
system and not from the developer’s viewpoint. The following examples for the Use
Cases of Pharmacy software illustrates this:
Maintain Drug list
Order Drugs
Receive Drugs
Sell Drugs
Accept Returned Drugs
Process Expired Drugs
Process Damaged Drugs
Each Use Case is represented by a "verb
clause" or "action clause". Now, it is possible that a particular Use Case
may be achieved in different ways. These are identified in the next stage of elaboration
as Scenarios. So scenario can be thought of as an instance of the Use Case. A scenario may
be normal or abnormal. It is very important for the System Analyst to study and identify
the abnormal scenarios because they occur rarely but could require major changes in code
at a later date. For example, what happens when a physical stock verification in the
Pharmacy shows that the actual stock differs from what the system is showing.
Under each scenario, a detailed set of steps must be
given. These must reflect the Business Procedures of the organization. Note that in a
given scenario, only a single set of steps must be given. There is no scope for an OR
clause, i.e., a step like "Purchases of new drugs can be made against a purchase
order or it can be an ad hoc purchase" is not acceptable. It indicates that we are
unnecessarily trying to combine two different scenarios into one. The steps must be
written considering the system as a black box with the desired features. Remember –
the steps must be written from the viewpoint of the user.
Identifying the actors is a major problem, which
need to be tackled properly. It is easy to identify the human actors but to identify
non-human actors it is quite difficult. It is also necessary to determine the roles to be
played by the different actors in the system and its effect on the whole system.
Actors are basically of three types. These are as
follows:
Human actors: Any human who interacts with the
system, i.e., potential human users of the system. In order to develop a use case model
one need to identify the different roles that the human beings play, remembering that one
person may play different roles at different times. For example: The librarian may himself
be a user for the library system.
Non-human actors: It is quite difficult to identify
non-human actors than to identify human actors. A non human actor for a library system can
be another library which wants to refer some books of the library or a keyboard through
which data is entered. It is not appropriate to consider keyboard to be an actor because
some human being must be operating it and he may be considered as actor.
Time: Time itself can be a trigger in many Use
Cases, particularly real-time systems. Suppose we want that the interest rate will be
changed on April 2, 2001. Then the new interest rate will be triggered by the Time Actor.
Some think that actors can only be human beings, but
really actor is anyone or anything that interacts with the system.
]]]
Use Case #[Number] [NAME]
Module
#/Name |
[NUMBER] / [NAME] |
Custodian
Dept. |
[Department responsible
for the use case] |
Actors |
[List of actors,
indicating who initiated the use case] |
Purpose |
[Intention of the use
case] |
Overview |
[Summary of the use
case] |
Type |
[Primary/Secondary/Optional] |
Cross
reference |
[Related system
functions] |
Business
Rules |
[Rules and exceptions
of the use case] |
Contact
Persons |
[Persons of the
organization with whom details of the use case were discussed] |
Documents
Referred |
[Previous forms,
reports and documents referred] |
Response
Time |
[Time to be taken by
the system for execution of the use case] |
[[[
Use Case Types
| Primary |
Represents major common processes |
| Secondary |
Represents minor or rare processes |
| Optional |
Represents processes that may not be
tackled |
]]]
Scenario #[Number] [(Type)] [Scenario Name]
Use case #[Number]/[NAME]
[[[
Scenario Type
Normal |
The scenarios that are
feasible, which normally occur and/or are quite frequent, e.g., Travelling from Berhampur
to Hyderabad by train (for a Use Case of Travel from Berhampur to Hyderabad). |
Abnormal |
The scenarios which
occur very rarely and sounds infeasible, e.g., Travelling from Berhampur to Hyderabad by
walking (for a Use Case of Travel from Berhampur to Hyderabad). |
]]]
Typical Course of Action
[This section describes in detail the conversation
of interaction between the actors and the system. It describes the most common or typical,
sequence of events - the average story of activities and the successful completion of a
process.]
Actor
Action |
System
Response |
# |
[Numbered action of
the actor] |
# |
[Numbered
description of the system responses] |
3. |
Customer enters name
for search. |
4. |
System displays
matching entries. |
Alternate Course:
[Line Number] : [Description of the exception]
[The "alternate" course, describes
important alternative or exceptions that may arise with respect to the "typical
course of action"]
|
