USE CASES SPECIFICATION

NIST TRAINING & CONSULTANCY SERVICES
(A division of National Institute of Science & Technology)

HOME >> FOCUS AREA >> S/W ENGINEERING >> METHODOLOGY >> USE CASE SPECIFICATION

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"]

HOME >> FOCUS AREA >> S/W ENGINEERING >> METHODOLOGY >> USE CASE SPECIFICATION