Use Cases and Customer-Developer Relationship

It has been mentioned earlier on; excellent software products are the result of a well-
executed design based on excellent requirements and high quality requirements result
from effective communication and coordination between developers and customers. That
is, good customer-developer relationship and effective communication between these two
entities is a must for a successful software project. In order to build this relationship and
capture the requirements properly, it is essential for the requirement engineer to learn
about the business that is to be automated.

It is important to recognize that a software engineer is typically not hired to solve a

computer science problem – most often than not, the problem lies in a different domain
than computer science and the software engineer must understand it before it can be
solved. In order to improve the communication level between the vendor and the client,
the software engineer should learn the domain related terminology and use that
terminology in documenting the requirements. Document should be structured and
written in a way that the customer finds it easy to read and understand so that there are no
ambiguities and false assumption.

One tool used to organize and structure the requirements is such a fashion is called use
case modeling.

It is modeling technique developed by Ivar Jacobson to describe what a new system

should do or what an existing system already does. It is now part of a standard software
modeling language known as the Unified Modeling Language (UML). It captures a
discussion process between the system developer and the customer. It is widely used
because it is comparatively easy to understand intuitively – even without knowing the
notation. Because of its intuitive nature, it can be easily discussed with the customer who
may not be familiar with UML, resulting in a requirement specification on which all
agree.

Use Case Model Components

A use case model has two components, use cases and actors.

In a use case model, boundaries of the system are defined by functionality that is handled
by the system. Each use case specifies a complete functionality from its initiation by an
actor until it has performed the requested functionality. An actor is an entity that has an
interest in interacting with the system. An actor can be a human or some other device or
system.

A use case model represents a use case view of the system – how the system is going to
be used. In this case system is treated as a black box and it only depicts the external
interface of the system. From an end-user’s perspective it and describes the functional
requirements of the system. To a developer, it gives a clear and consistent description of
what the system should do. This model is used and elaborated throughout the
development process. As an aid to the tester, it provides a basis for performing system
tests to verify the system. It also provides the ability to trace functional requirements into
actual classes and operations in the system and hence helps in identifying any gaps.

Use Diagram for a Library System

As an example, consider the following use case diagram for a library management
system. In this diagram, there are four actors namely Book Borrower, Librarian, Browser,
and Journal Borrower. In addition to these actors, there are 8 use cases. These use cases
are represented by ovals and are enclosed within the system boundary, which is
represented by a rectangle. It is important to note that every use case must always deliver
some value to the actor.

With the help of this diagram, it can be clearly seen that a Book Borrower can reserve a
book, borrow a book, return a book, or extend loan of a book. Similarly, functions
performed by other users can also be examined easily.
Creating a Use Case Model
Creating a use case model is an iterative activity. The iteration starts with the
identification of actors. In the next step, use cases for each actor are determined which
define the system. After that, relationships among use cases are defined. It must be
understood that these are not strictly sequential steps and it is not necessary that all actors
must be identified before defining their use cases. These activities are sort of parallel and
concurrent and a use case model will evolve slowly from these activities. This activity
stops when no new use cases or actors are discovered. At the end, the model is validated.

Relationship among Use Cases

The UML allows us to extend and reuse already defined use cases by defining the
relationship among them. Use cases can be reused and extended in two different fashions:
extends and uses. In the cases of “uses” relationship, we define that one use case invokes
the steps defined in another use case during the course of its own execution. Hence this
defines a relationship that is similar to a relationship between two functions where one
makes a call to the other function. The “extends” relationship is kind of a generalization-
specialization relationship. In this case a special instance of an already existing use case
is created. The new use case inherits all the properties of the existing use case, including
its actors.
Let is try to understand these two concepts with the help of the following diagrams. In the
case of the first diagram, the Delete Information use case is using two already existing
use cases namely Record Transaction and Cancel Transaction. The direction of the arrow
determines which one is the user and which use case is being used.
The second diagram demonstrates the concept of reuse by extending already existing use
cases. In this case Place Conference Call use case is a specialization of Place Phone Call
use case. Similarly, Receive Additional Call is defined by extending Receive Phone Call.
It may be noted here that, in this case, the arrow goes from the new use case that is being
created (derived use case) towards the use case that is being extended (the base use case).

This diagram also demonstrates that many different actors can use one use case.
Additionally, the actors defined for the base use case are also defined by default for the
derived use case.
The concept of reusability can also be used in the case of actors. In this case, new classes
of actors may be created by inheriting from the old classes of actors.

Credit Card
Validation System
Perform Card
Transaction

Customer Process Retail

Customer Bill Institution

Reconcile
Transactions

Individual Corporate
Manage
Customer Customer Sponsoring
Customer Acct
Financial
Institution
Extended User
In this case two new classes, Individual Customer and Corporate Customer, are being
created by extending Customer. In this case, all the use cases available to Customer
would also be available to these two new actors.
Elaborated Use Cases

After the derivation of the use case model, each use is elaborated by adding detail of
interaction between the user and the software system. An elaborated use case has the
following components:

• Use Case Name

• Implementation Priority: the relative implementation priority of the use case.
• Actors: names of the actors that use this use case.
• Summary: a brief description of the use case.
• Precondition: the condition that must be met before the use case can be invoked.
• Post-Condition: the state of the system after completion of the use case.
• Extend: the use case it extends, if any.
• Uses: the use case it uses, if any.
• Normal Course of Events: sequence of actions in the case of normal use.
• Alternative Path: deviations from the normal course.
• Exception: course of action in the case of some exceptional condition.
• Assumption: all the assumptions that have been taken for this use case.

As an example, the Delete Information use case is elaborated as follows:

s >> Record
u se Transaction
<<
Delete
Information
<<
us e
User s>
> Cancel
Transaction

Use Case Name: Delete Information

Priority: 3

Actors: User

Summary: Deleting information allows the user to permanently remove information from
the system. Deleting information is only possible when the information has not been used
in the system.
Preconditions: Information was previously saved to the system and a user needs to
permanently delete the information.

Post-Conditions: The information is no longer available anywhere in the system.

Uses: Record Transactions, Cancel Action

Extends: None

Normal Course of Events:

1. The use case starts when the user wants to delete an entire set of information such as
a user, commission plan, or group.
2. The user selects the set of information that he/she would like to delete and directs the
system to delete the information. - Exception 1, 2
3. The system responds by asking the user to confirm deleting the information.
4. The user confirms deletion.
5. Alternative Path: Cancel Action
6. A system responds by deleting the information and notifying the user that the
information was deleted from the system.
7. Uses: Record Transaction
8. This use case ends.

Alternative Path - The user does not confirm Deletion

1. If the user does not confirm deletion, the information does not delete.
2. Uses: Cancel Action

Exceptions:
1. The system will not allow a user to delete information that is being used in the
system.
2. The system will not allow a user to delete another user that has subordinates.

Assumptions:
1. Deleting information covers a permanent deletion of an entire set of data such as a
commission plan, user, group etc. Deleting a portion of an entire set constitutes
modifying the set of data.
2. Deleted information is not retained in the system.
3. A user can only delete information that has not been used in the system.
Alternative Ways of Documenting the Use Case

Many people and organizations prefer to document the steps of interaction between the
use and the system in two separate columns as shown below.

User Action System Reaction

1. The use case starts when the user wants
to delete an entire set of information
such as a user, commission plan, or
group.
2. The user selects the set of information 3. The system responds by asking the user
that he/she would like to delete and to confirm deleting the information.
directs the system to delete the
information. - Exception 1, 2
4. The user confirms deletion. 5. A system responds by deleting the
information and notifying the user that
the information was deleted from the
system.

It is a matter of personal and organizational preference. The important thing is to write

the use case in proper detail.
Template for Usage Scenario:

Use Case Title Write Title Here (must match use case title in use
case diagram)
Abbreviated Title
Use Case Id
Requirement Id
Description:

Pre Conditions:
Task Sequence Exceptions
1.
2.
3.
.
.
Post Conditions:
Unresolved issues:
Authority:
Modification history:

Author:

Description:
Limitations of Use Cases

Use cases alone are not sufficient. There are kinds of requirements (mostly non-
functional) that need to be understood. Since use cases provide a user’s perspective, they
describe the system as a black box and hide the internal details from the users. Hence, in
a use case, domain (business) rules as well as legal issues are not documented.

The non-functional requirements are also not documented in the use cases. As examples
of those, consider the following requirements.

• Usability
o Color blind people should not have any difficulty in using the system – color
coding should take care of common forms of color blindness.
• Reliability
o The system needs to support 7 x 24 operation
• Performance
o Authorization should be completed within 1 minute 90% of the time.
o Average authorization confirmation time should not exceed 30 seconds.
• Portability
o The system should run on Windows 98 and above as well as Sun Solaris 7.0
and above.
• Access
o System should be accessible over the internet – hidden requirement – security

Because of this shortcoming, use cases must be augmented by additional information.

References:
Handouts CS504 (SOFTWARE ENGINEERING – I)