Hiểu biết về yêu cầu mô hình hóa doc

Understanding
Requirements
Modeling
Chapter 3
Before defining any system you should analyze and
understand the problem, identify the stakeholders need,
and document all the requirements. This will help in better
understanding of the current system and the goals that
need to be achieved by the new software system. UML
provides modeling techniques for analyzing and
documenting the requirements of a software system.
This chapter includes the process of analyzing a problem
by using business and system modeling. In addition, it
explains the creation of use case diagrams for system
modeling.
In this chapter, you will learn to:
 Analyze a problem by using business and system
modeling
 Create use case diagrams for system modeling
Objectives

¤NIIT Understanding Requirements Modeling 3.3
You should not commission a software project until you have all the requirements of the
project available for preliminary planning. Lack of clarity in understanding the
requirements of the existing process leads to rework in the designing of the new software
system. Defining a new software system consists of the following phases:
 Analyzing a problem
 Identifying stakeholders
 Identifying, gathering, organizing, and documenting the requirements
The problem analysis phase of a software project involves preparing a concise problem
statement that specifies the problem in the existing software system or the workflow of

the organization and the constraints that exist for the proposed solution.
A problem statement should include the description of the existing processes and the
goals that need to be achieved by the new software system. In addition, you should define
a problem statement in the terminology understood by the customer instead of the
software jargon. This ensures that the proposed software system will conform to the
customer requirements.
You can analyze the existing process or software system to create a problem statement by
using the following modeling techniques:
 Business modeling
 System modeling
Business Modeling
Business modeling is a visual modeling technique that describes the working of the
existing process of an organization and the role that each person plays in the process. In
other words, business modeling provides a comprehensive overview of the working of the
business. The technique enables the development team to focus on the areas that can be
automated to improve the efficiency of the business. It also helps identify the changes and
enhancements required to implement a new system.
After the business requirements for a software project are understood a business case is
developed. A business case is a document that contains the cost benefit justification for
the project. This information enables a manager to decide whether to support the project
before significant resources are committed to its development.
Defining the System
A
nalyzing a Problem
3.4 Understanding Requirements Modeling ¤NIIT
The overall intent and purpose of the proposed system is documented in a vision
document. The vision document is created for the software development team so that they
are clear on the purpose and scope of the project. The document provides an overview of
the software being developed. It provides a macro-level view of software requirements.
The vision document captures the structure of the proposed system to communicate its

intent. Broadly speaking, it lists a statement of the problem, key stakeholders, user needs,
a list of the features of a system, and use cases. The vision document also specifies the
key stakeholders, key features, and the constraints of the software.
Using UML for Business Modeling
UML provides various notations for the constructs that enable you to create a business
model of the existing software system or process. The following table shows the business
modeling constructs and their corresponding UML notations.
Name UML Notation Function
Business actor
Represents an external entity that
interacts with the business process. The
external entity can be a human or a
non-human entity including an event or
another process. The business actor
initiates or triggers a process in the
system.
Business workers
Represents a role involved in the
existing business process. A business
worker can be a human or another
process. In addition, a business worker
can interact with other business workers
to manipulate data.
Business entity
Represents the data or documents that
flow from one sub process to another.
Business use case
Represents the functions of a particular
sub process in the existing business
process.

Collaboration
Shows how the particular function
described in the use case is
implemented.
¤NIIT Understanding Requirements Modeling 3.5
N
ote
Name UML Notation Function
Organizational unit
Represents a collection of business units
and business entities.
UML Notation for Business Modeling
The examples of non-human actors are:
 Other systems: When a system or a process interacts with the system, it should be
represented as an actor.
 Date or time: When a use case is initiated by the events, such as date or time, then the
events should be modeled as an actor. For example, a software system attached with an
appliance needs to start at 6:00 P.M. and should stop at 6:15 P.M. In this case, time
initiates the working of the software system and, therefore, becomes an actor for the
system.
 Triggers: When a trigger, such as temperature, initiates a use case then it should also
be represented as an actor. For example, a software system to maintain a particular
range of the temperature is initiated when the temperature goes below its lower limit
.
Business modeling provides the following two models to analyze the existing system:
 Business use case model: Represents the functions of the existing process by using
business actors and use cases. The business use-case model uses business use case
diagrams and abstract activity diagrams to outline the activities for the existing
system.
 Business object model: Represents extensive interaction between business workers

and business entities. For example, a business object model can show the procedure
of acceptance of quotations by a department. The quotations are represented as
entities, the department that accepts the quotation is an actor because it initiates the
quotation process, and the departments that send the quotations are business workers.
A business object model uses the following diagrams for an extensive representation
of the workflow of the existing processes or the existing software system of an
organization:
z Class diagram: Shows the static or internal structure of the business in the form
of relationships among various classes for the existing system. The classes in
the class diagram represent either a business worker or a business entity. These
diagrams also show the collaborations between the business workers and
business processes in the existing system.
3.6 Understanding Requirements Modeling ¤NIIT
z Activity diagram: Represents the flow of activities of the existing system. The
diagram represents the dynamic nature of the system and enables you to identify
the parallel activities as well as the alternate paths for these activities. It also
represents the roles and responsibilities of each business object in the existing
system.
z Interaction diagram: Represents the interaction between business workers and
business objects to perform a business function. Interaction diagrams are of four
types, communication, sequence, interaction overview, and timing.
Analyzing a Hospital Administration System
Consider a problem statement of a hospital administration system. A patient needs to take
an appointment for a doctor from the receptionist in the hospital. The receptionist checks
the schedule of the doctor and gives the appointment accordingly. The hospital has
categorized patients into two age groups: up to 14 and above 14. The receptionist ensures
that patients up to 14 years are given an appointment only with a child specialist. The
cashier accepts the fees from the patient after each visit. This fee varies according to the
doctor attending the patients.
During the first visit of the patient, the doctor enters the relevant personal information

about the patient in a computer, for future reference. The doctor also enters the health
history of the patients, the reports of the tests, if any, and the medicines prescribed to the
patients. The doctor can also print the prescription slip and give it to the patient.
When the patient goes to the store, the storekeeper accepts the payment, and gives the
prescribed medicine to the patient. To ensure that there is uninterrupted supply of
medicines, the storekeeper orders new stock when the quantity of a medicine reaches the
reorder level. The storekeeper can also order new medicines.
The hospital administration system needs to be automated. The proposed software system
of the hospital administration system should be able to offer the following functions:
 Provide an automated voice response system over the phone that receives the phone
calls of the patient and schedules an appointment. The automated voice response
system should also enable a patient to cancel the existing appointment.
 Provide an automated system that sends a requisition request for medicines whenever
the quantity of medicines reaches the reorder level.
 Automate the payment procedure from the patient for the services of the doctor and
the purchase of medicines.
 Automate the schedule modification process. The doctor should be notified about the
cancellation of any appointments due to the change in schedule. If the doctor still
wants to change the schedule, then all the affected appointments should be cancelled
and the patients should be informed accordingly.
¤NIIT Understanding Requirements Modeling 3.7
Let us identify business use cases, business workers, and business actors to analyze the
existing process of the hospital administration system.
The business use cases identified for the existing hospital administration system are:
 Take Appointment: Describes how the receptionist gives an appointment to the
patients based on the schedule of the doctor and the category of the patient. This
business use case is initiated on the patient’s request or when the doctor wants to
schedule a new appointment.
 Deliver Medicine: Describes how the storekeeper delivers medicines to the patient.
This business use case is initiated when a patient buys the medicine.

 Accept Fee: Describes how the cashier accepts the fee from the patient. This
business use case is initiated when the patient pays for the services of the doctor.
 Print Slip: Describes the procedure of printing the slip on the doctor’s computer.
This business use case is initiated when a doctor creates the prescription and gives a
print command for the same.
 Accept Payment: Describes how the cashier accepts payment from the patient for
the medicines purchased from the store. This business use case is initiated when the
patient buys medicines from the store.
 Reorder Medicine: Describes how the storekeeper orders the medicines. This
business process is initiated when the quantity of the medicine falls below the
reordering level or the storekeeper wants to buy new medicines.
 Modify Schedule: Describes how the doctor modifies the schedule. This process is
initiated when the doctor wants to enter new information or modify the existing
information in the schedule.
The business actors for the hospital administration system are:
 Patient: Initiates the Take Appointment, Accept Fee, Accept Payment, and
Deliver Medicine use cases and is external to the system.
 Doctor: Initiates the Print Slip and Modify Schedule use cases and is external to
the existing process.
 Reorder Level: Acts as a trigger to initiate the Reordering Medicine use case and
is external to the system.
Business workers are involved in carrying out a business use case or a business process. A
person or an entity can act as a business actor for one process and a business worker for
another process. For example, if Treatment is considered as a use case, then the doctor
who is an actor for other processes becomes the business worker for the Treatment
process.
3.8 Understanding Requirements Modeling ¤NIIT
The business workers of the existing hospital administration system are:
 Receptionist: Attends the patient’s phone calls and, therefore, is involved in the
Take Appointment use case.

 Storekeeper: Delivers medicine to the patients and orders new medicine. The
storekeeper is involved in the
Reordering Medicine and Deliver Medicine
business use cases.
 Cashier: Accepts fees and payment from the patient and, therefore, is involved in the
Accept Fee and Accept Payment business use cases.
A business use case diagram for the hospital administration system shows the interaction
between the business use cases and the business actors. The following figure shows the
business use case diagram for the existing hospital administration system.
The Business Use Case Diagram for the Hospital Administration System
System Modeling
Business modeling enables you to understand the existing process and gather the
requirements for the new software system. On the other hand, system modeling gives a
proposed solution to fulfill the gathered requirements.
System modeling provides a System Context Diagram (SCD) to depict the flow of
information between the proposed software system and its environment at the different
levels of the hierarchy. The subsystems for the proposed software system are modeled as
¤NIIT Understanding Requirements Modeling 3.9
use cases. After the use cases are identified, you can derive other UML diagrams, such as
the class, object, and activity diagrams, from these use cases.
You can derive the use cases for the proposed software system from a business model.
The following are the business modeling constructs that you can derive and use for
system modeling:
 Business use cases: Enable you to identify the sub processes that constitute the
proposed solution.
 Business actors: Map to the actors in the system model.
 Behaviors of business workers: Enable you to find system use cases and define the
features for the new system model.
 Business entities: Help find the entity classes when you create the class diagrams.
System Modeling for the Hospital Administration System

You can use the identified business use cases to derive the system use cases for the
hospital administration system. The use cases for the automated hospital administration
system are:
 Modify Schedule: Enables the doctor to enter new information or modify the
existing information in the schedule.
 Give Appointment: Gives an appointment to a patient by using the automated voice
response system.
 Accept Fee: Accepts the payment from the patient for the services of the doctor.
 Reordering Medicines: Orders medicines whenever the stock of the particular
medicines reaches the reorder level.
 Print Slip: Prints the slip on the doctor’s computer.
 Accept Payment: Accepts payment from the patient for the purchased medicines.
The new software system needs to interact with the existing software system. For
example, the process of entering the information about the patient does not change, and
the new software system should be able to use this information from the existing software
system itself. As a result, a new use case, Communication with Existing System, is
required to create a link between the existing software system and the new software
system.
3.10 Understanding Requirements Modeling ¤NIIT
N
ote
You need to include the Communication with Existing System use case in the SCD. The
following figure shows the SCD at the first level of the automated hospital administration
system.
SCD for the Hospital Administration System
You will learn more about how to create a use case diagram for system modeling in the
next section, Creating Use Case Diagrams for System Modeling.
¤NIIT Understanding Requirements Modeling 3.11
Just a minute:
Which of the following diagrams of Business Object Model shows the static or internal

structure of the business in the form of relationships among various classes for the
existing system?
1. Class diagram
2. Use-case diagram
3. Activity diagram
4. Interaction diagram
Answer:
1. Class diagram
The success of a project depends upon the satisfaction of the stakeholders. Therefore, it is
necessary to identify the stakeholders before you develop the product.
Identifying the needs of stakeholders enables a software team to make better decisions in
the definition and implementation phases of the development process. You can define the
need of a stakeholder as any business, personal, or operational problem that should be
solved to justify the existence of the new software system.
You should interview the stakeholders to obtain the requirements of the new software
system. The responses of the stakeholders are useful for system scope management and
the requirement negotiation process. A few guidelines that you should follow when you
interview the stakeholders are:
 Ask direct questions that enable you to identify how the new software system will
fulfill the requirements of the stakeholder.
 Probe stakeholders to define the conflicting requirements in detail.
 Document the input gathered from interviews in a universally accepted language,
such as English.
The input provided by stakeholders during the interview is documented as the required
features of the software system. A feature can also be defined as a service that the
software system provides to fulfill one or more stakeholder needs. You need to provide
additional information in the form of feature attributes when you document features.
Identifying Stakeholders
3.12 Understanding Requirements Modeling ¤NIIT
This ensures that the features are communicated adequately to the rest of the team. The

attributes of the features that you should document are:
 Status: Indicates whether the feature is proposed for the next version, approved for
the next version, or already incorporated in the previous versions.
 Rank: Indicates the level of priority of the feature. The ranking could be high,
medium, or low depending on the stakeholder’s need. This ranking helps manage the
scope and determine the priority of the features.
 Effort: Indicates the effort in terms of the work hours required to incorporate a
feature in the proposed software system. It is useful in estimating the number of
work months and lines of code. You can assign the following three values to this
attribute: low, medium, and high.
 Uncertainty: Indicates the probability of the feature causing undesirable events,
such as cost overruns, schedule delays, or cancellation of the project. You can assign
a high, medium, or low value to this attribute.
 Stability: Indicates the probability of a change in the feature. You can assign a high,
medium, or low value to this attribute.
 Target release: Records the intended product release or iteration in which the
feature will first be incorporated.
 Assigned to: Indicates who will be responsible to incorporate the feature in the
product. It could be one person or the complete development team.
 Source: Tracks the source of the requested feature. It could be a reference to a page
of the product specification document.
You can use attributes to track, prioritize, and manage the features proposed for
implementation. For example, the attribute, target release, records the software version in
which you intend to incorporate the feature.
Requirements define the features that the software system should deliver. Requirements
form the basis on which the system is built. Non-conformance to requirements can lead to
the failure of the software system. Therefore, requirements identification and management
is a very critical process in the life cycle of a project. Any software development project
should follow a formal Requirements Management process that helps identify, document,
organize and track the requirements.

Requirement management is a continuous process that continues throughout the life cycle
of the project. However, most of the activities pertaining to requirement identification,
gathering, analysis and negotiation are performed in the requirements analysis phase. In
terms of RUP phases, most of these activities will be performed in the inception and
elaboration phases.
Identifying and Managing Requirements
¤NIIT Understanding Requirements Modeling 3.13
As the project moves to design phase, these requirements are specified in terms of
technical requirements and design concepts developed to fulfill these requirements. At
this stage requirements may further be refined and some of them dropped. For example,
requirements that are less important may be dropped to reduce the development time. In
terms of RUP phases, most of these activities happen in the elaboration and construction
phases.
During designing and construction, these requirements may be validated to ensure that the
design would be able to meet the stated requirements. At this stage, you may also need to
fine-tune the design, refine the requirements, or change the priority of requirements. In
terms of RUP phases, these activities are done during elaboration and construction phases
and peak when any iteration is starting.
The various phases in requirement management are:
 Requirements gathering
 Requirements analysis and negotiation
 Requirements specification
 Requirements validation
Requirement Gathering
Without gathering requirements, you cannot build a complete functional system. The
factors that make requirements gathering difficult are:
 Scope: The scope is usually not well-defined because the stakeholders usually do not
specify the requirements completely.
 Requirements understanding: Requirements are usually not understood
completely. This is because stakeholders are not sure of the functions that should be

included in the software system. As a result, requirements keep on changing
throughout the development process.
 Volatility: The requirements are volatile. This means that requirements keep on
changing and new requirement keep on adding during the development process.
You need to follow a systematic approach to gather requirements. The various activities
involved in gathering requirements are:
 Assess the economic, technical, and operational feasibility for the proposed software
system:
z Economic feasibility: Signifies the economic value that the proposed software
system will add to the existing process.
z Technical feasibility: Indicates whether or not it is possible to develop the
proposed software system.
z Operational feasibility: Indicates whether it is feasible to install the new
software system in the operational environment of the existing process.
3.14 Understanding Requirements Modeling ¤NIIT

Identify the stakeholders and end users who specify the requirements and jargon that
appear in the existing process.
 Identify the domain constraints that limit the working of the proposed software
system.
 Identify the methods for requirement elicitation, such as the activities to interview
stakeholders and hold team meetings between the development team and the
stakeholders.
 Identify the ambiguous requirements that can be made clear using prototypes.
 Identify the expected requirements, which are the trivial requirements that
stakeholders do not specify. Such requirements are also called implicit requirements.
For example, the user-friendly interface of a Graphical User Interface (GUI)
application is an implicit expectation of most stakeholders.
The output of the requirements gathering phase is in the form of various documents, such
as:

 Statement of need and feasibility
 Bounded statement of scope for the product
 List of all the participants and stakeholders involved in the requirements gathering
activity
 Statement that describes the environment in which the software system will operate
 List of all the requirements of the proposed software system and the constraints
imposed on the proposed software system
 Statement that contains the prototypes identified to remove ambiguity from the
requirements
Requirement Analysis and Negotiation
Requirement analysis is the process to categorize and organize requirements based on the
documents produced in the requirements gathering activity. You can classify requirements
into functional and non-functional requirements.
Requirement analysis enables you to define and represent the behavior of the software.
The process enables you to segregate information and behavior in a way that uncovers
detail in a hierarchical structure.
Functional Requirements
Functional requirements are derived from the need of the stakeholders and include the
functions and features of the software system. You can use the business use cases of the
existing software system to identify the functional requirements of the proposed software
¤NIIT Understanding Requirements Modeling 3.15
system. For example, in the automated hospital administration system, the functional
requirements could be to:
 Accept telephone calls from patients to give new appointments and cancel the
existing appointments
 Generate reports of patients based on their name, age, or prescription slip
 Generate a report of all the patients who visit a particular doctor on a particular day
 Use the reorder level to order new medicines
Non-Functional Requirements
Non-functional requirements are qualities that a software system should possess other

than those concerning its functionality. Examples of non-functional requirements are
security, performance, reliability, maintainability, and scalability.
Requirements Specification
Requirement specification is an activity that involves converting the requirements
analyzed in the analysis phase into technical requirements that can be implemented. The
documented requirements need to unambiguous. The Software Requirements
Specification (SRS) is a document produced at the culmination of the analysis task. This
document provides the detailed description of the information domain and each function
that needs to be performed by the software. It also provides information about the
behavioral description of the software system. The SRS document should be:
 Consistent
 Concise
 Complete
 Flexible
You can use various formats to create an SRS. An SRS must provide the following
information:
 Definition of the software system
 Purpose of the SRS document
 Scope of the software system
 Functional requirements
 Non-functional requirements
 Conditions under which the proposed software system operates
3.16 Understanding Requirements Modeling ¤NIIT
N
ote
Requirement specification is not specific to software engineering. It is also used in
hardware and database engineering.
Requirement Validation
Requirement validation is an activity that involves validating all the requirements after
they are specified. Normally, the quality department performs requirement validation to

ensure that each requirement is clearly understood and is measurable. A checklist is used
to ensure that a particular customer requirement is practical and properly understood by
the developers. The objectives of the checklist are:
 Identifying all the ambiguous requirements
 Identifying the source of each requirement
 Stating the requirements quantitatively
 Identifying the dependence among the requirements
 Verifying if the requirements are concise, testable, and traceable
 Verifying that no requirement conflicts with the constraints imposed on the software
system
It is important to capture the correct requirements for a software system. To gather
requirements effectively, you need to follow a predefined approach. Using multiple
techniques for gathering requirements helps in effective requirements gathering. The
commonly used requirement gathering techniques are:
 Interview stakeholders.
 Conduct brainstorming sessions among stakeholders.
 Prepare questionnaires.
 Observe the existing processes of the organization.
 Appoint a domain expert.
Interview Stakeholders
You need to interview customers to understand the software system requirements in detail
and develop a clear understanding about the expectations of the customer from the
proposed software system. Interviewing involves a context-free discussion, which enables
you to ask questions to the customer to obtain unbiased input. The questions asked during
the interviewing session should be short and should emphasize on understanding the
Requirement Gathering Techniques
¤NIIT Understanding Requirements Modeling 3.17
software system requirements clearly. The context-free questions that you can ask during
the interview are:
 Who would use the system?

 What should be the output of a particular function?
A member of the technical team can use a structured interview template to conduct the
customer interview. You need to perform the following activities to conduct a
far-reaching customer interview:
 Identify the people who will be interviewed.
 Review the questions to be asked in the interview.
 Re-examine the background of the company and the stakeholder to be interviewed.
 Ask relevant questions by using the template.
 Record the answers during the interview.
Conduct Brainstorming Sessions
In brainstorming sessions, the stakeholders suggest the possible system requirements and
discard insignificant and redundant ideas. Brainstorming helps the stakeholders to identify
new features and resolve ambiguities in the requirements, if any. Brainstorming involves
the following activities:
 Idea generation: Focuses on the task to generate new ideas. The goal is to outline as
many ideas as possible.
 Idea reduction: Focuses on the task to reduce the ideas already generated. This
activity also involves the task to prune, organize, eliminate, group, and refine ideas
to obtain concrete ideas to develop the system.
Before a brainstorming session, the rules and objectives for the session are clearly
defined. The facilitator asks the participants to share their ideas aloud. The various
features of a brainstorming session are to:
 Encourage participation by all the stakeholders.
 Allow the participants to criticize as well as appreciate additional ideas.
 Generate multiple ideas in a short span of time.
 Arrive at solutions in case of overlapping system requirements.
Prepare Questionnaires
Gathering requirements through questionnaires is a technique that involves the task to ask
questions to gather information. The questions can be about the expected software system
behavior, the time required to complete the project, or the required output of a particular

process.
3.18 Understanding Requirements Modeling ¤NIIT
Normally, the questionnaire round is conducted before interviewing the customer. This
round prepares the customer for the interview as a questionnaire is sent to all the
stakeholders. The customer needs to answer the questionnaire keeping the perspective of
the software system requirements in mind.
Observe the Existing Process
The observation technique requires you to visit the customer site to understand how the
existing process works and to identify the people involved in a process. For example, to
automate the account keeping process of a bank, the system analyst visits the bank. The
system analyst needs to identify the flow of information from one department to another.
The analyst observes the documents and the bank employees involved in the information
flow. The analyst also identifies how each transaction is recorded in separate books of
accounts. This enhances the understanding of the requirements of the software system to
be developed. In addition, the analyst identifies how to integrate the processes of the
existing software system with the proposed software system.
Appoint a Domain Expert
It is important to obtain input about the technicalities of a particular system before you
gather and document requirements. For example, you may need to develop an account
keeping system that involves various technicalities, such as when to debit a transaction. In
such a situation, you need to consult a domain expert who has expertise about the
technicalities of the account keeping process. Consulting a domain expert will enable you
to understand all the bank transactions, which, in turn, will help you to develop a robust
software solution.
The requirements communicated by the customer may not be stated clearly. You may
need to interpret the requirements and create an outline for the software system that needs
to be developed. This outline should be presented to the customer for approval.
Storyboarding is a technique that involves the task to design a series of user interfaces on
paper before you develop the software system. The user interface storyboards match the
definitions of the use case paths described in the basic course of events and provide the

graphic presentations of various processes. Storyboarding enables you to obtain customer
feedback on how the system should work at a very early stage.
Identify Story Boarding Techniques
¤NIIT Understanding Requirements Modeling 3.19
Storyboards include large cardboard wall charts with pictures that depict the sequence of
each process. The objective of storyboarding is to:
 Understand data visualization.
 Define and understand business rules.
 Model algorithms and other mathematical constructs.
 Demonstrate reports.
An analogy for storyboarding is creating sketches for an advertisement project. To create
an advertisement, the creative team normally draws or sketches the idea of the
advertisement on paper. This enables the creative team to communicate their thoughts to
the customer and obtain an approval from the customer before the team creates actual
advertisement. Similarly, storyboarding enables you to obtain an early response from the
stakeholders for the unclear requirements.
Storyboarding not only enables you to obtain feedback from the customer on user
interfaces. It also enables you to demonstrate how the various sequence of actions will be
performed using the software application.
You can apply different types of storyboards in one project. The various types of
storyboards are:
 Passive storyboard: Consists of sketches, pictures, screen shots, presentations, or
sample application outputs. In a passive storyboard, the analyst gives the description
of each result generated by performing a particular operation.
 Active storyboards: Consists of animations or an animation tool, and a recorded
computer script or simulation. Active storyboards provide an automated description
of the software system behavior in an operational scenario.
 Interactive storyboard: Consists of the simulations or prototypes. This storyboard
requires an interaction with the end user and is useful to capture the requirements
about which the stakeholders are not clear.

3.20 Understanding Requirements Modeling ¤NIIT
A use case diagram for system modeling describes the interaction between the use cases
and actors of the proposed software system. In addition, a use case diagram outlines the
various relationships, such as association and generalization, which exist between use
cases and actors.
The use cases identified for system modeling are text descriptions of the interaction
between outside entities and the software system. Use cases can model both functional
and non-functional requirements. In addition, you use use cases in the design,
implementation, and testing phases of software development. The use cases for the
proposed software system should contain the following characteristics:
 Provide value to actors: Each interaction shown using a use case diagram should
either provide an output to the external entity or affect the output provided to an
external entity that does not participate in the interaction. For example, a use case
such as Management Information System (MIS) may not provide value to the data
entry operator who enters data. Therefore, the data entry operator is simply a
business worker. The manager who will use the data is the actor for the use case. The
data contributes indirectly to the manager because the manager uses the data to make
business decisions. Although the manager does not directly interact with the data
entry part of the system, the system provides value to the manager.
 Provide a brief description of the desired functionality: The use case diagram
should contain a brief description of the proposed process at the first level. Detailed
information should be provided in the subsequent steps. A use case should explain all
the business and technical requirements that the sub-process needs to implement. The
information that a use case should contain includes:
z Name: Indicates a unique identification of the use case. For example, you can
name a use case as Give Appointment.
z Summary: Indicates the functions provided by the use case.
z Basic course of events: Indicates the steps of interaction that occur between the
actor and the software system to achieve the functions described in the use case.
For example, the actor initiates the process and then the system responds.

z Alternative paths: Describe the situations in which an uncommon condition
occurs.
z Exception paths: Describe the interactions that occur between a use case and an
actor when an error occurs.
z Triggers: List the conditions that must occur to make an actor initiate a use
case. Triggers describe a business need, time-related event, or the output of
another use case.
Identifying Use Cases
Creating Use Case Diagrams for System Modeling
¤NIIT Understanding Requirements Modeling 3.21
z Assumptions: Specify the conditions that should be true to make the system
work. You make these assumptions to make the design of the system relatively
simpler.
z Preconditions: List the conditions that must occur before the interaction
between the use case and an external entity begins. Preconditions are outside the
scope of the use case and the software system.
z Post conditions: List the conditions that are satisfied when the use case is
completed. Post conditions are a part of the contract between this use case and
the outside world.
z Business rules: List the business rules that relate to the requirements presented
in the use case.
z Non-functional requirements: List the non-functional requirements that the
use case must meet.
z Author: Specify the name of the author.
z Date: Contains the date on which the use case was originally written with
references to when it was changed.
Consider the example of the Give Appointment use case of the automated hospital
administration system. The Give Appointment use case should specify the following
information:
 Name: Give Appointment

 Summary: Give appointments to the patients based on the schedule of the doctor
and the category of the patient. A doctor can also give appointments to the patients
during treatment.
 Actors: Patient and Doctor
 Assumptions: The doctor has updated the schedule.
 Basic course of events:
z The patient makes a call for an appointment.
z The software system asks for the age of the patient.
z The patient enters the age.
z The software system checks the schedule of the doctor and gives the
appointment accordingly.
 Preconditions: The doctor’s schedule should be valid.
 Post conditions: The software system records the new appointment time and updates
the schedule of the doctor.
 Non-functional requirements: The patient should not be required to wait for more
than a minute to obtain an appointment.
 Author: Bill Jones
 Date: 02/07/07
3.22 Understanding Requirements Modeling ¤NIIT
N
ote
N
ote
In case of an automated hospital administration system, the business use case, Take
Appointment, will change to Give Appointment. Notice that the functions of the use case
remain the same. This is because in system modeling, you need to view the software
system from the perspective of the automated system that gives the appointment to the
patients. The other use cases of the automated hospital administration system will
remain the same. However, this might not be the case in all the business scenarios.
Like business actors, system actors are external entities that interact with the software

system and affect the system functions. An actor could represent a person, another
system, or some triggers depending upon the scenario.
The system actors can be classified as:
 Primary actors: Directly affect the system and initiate the use case. For example, a
data entry operator for the MIS directly interacts with the system and, therefore,
should be represented as a primary actor in the use case diagram.
 Secondary actors: Do not directly interact with the system but can initiate the
interaction of a primary actor with the system. For example, when a supplier
provides an invoice to a data entry operator, the supplier should be shown as a
secondary actor in the use case diagram.
You should depict secondary actors in the use case diagrams only when the actions of
these actors affect the responses or output of the system.
The actors of the hospital administration system are external entities that initiate any use
case of the automated hospital administration system. The actors for the automated
hospital administration system are as follows:
 Doctor
 Patient
 Reordering level
In case of the hospital administration system, the actors will be identical to the business
actors. However, this might not be the case in all the business scenarios.
Identifying Actors
¤NIIT Understanding Requirements Modeling 3.23
Relationships
Relationships depict the interaction of actors with each other and with use cases. The
various types of relationships that exist are:
 Generalization
 Association
Generalization
The generalization relationship exists among the actors that have similar behavior and
properties. Two actors are said to have a generalization relationship when the

characteristics of one actor can be derived from the other abstract actor.
The actor from which another actor is derived is known as the super actor and the derived
actor is known as the sub actor. For example, the actor, Patient, represents a general
behavior and, therefore, is called a super actor. The Upto 14 actor is derived from the
Patient actor to show special characteristics and, therefore, the Upto 14 actor is a sub
actor. The following figure shows a super actor and two sub actors of the automated
hospital administration system.
Generalization Relationship among Patients
Association
The association relationship shows the communication path between a use case and an
actor. An association is represented using an arrow or a simple line. The arrow shows the
direction of communication, and the line indicates that the communication is occurring in
Patient
Above 14 Upto 14
3.24 Understanding Requirements Modeling ¤NIIT
both the directions. The following figure shows the association relationship between the
Patient actor and the Take Appointment use case.
Association Relationship between Actor and Use Case
¤NIIT Understanding Requirements Modeling 3.25
Problem Statement
The InfoSuper bank is a leading financial institution having its clientele across the globe.
The bank offers the following services to customers:
 Corporate banking
 Personal banking
 Mutual funds
 Financer
 Home loans
The InfoSuper bank earns 45 percent of its total revenue from the personal banking
service. As a result, the bank wants to improve the customer satisfaction level and make
efforts to retain and gain customer loyalty.

The bank conducts a survey to find the customer requirements in terms of process time,
satisfaction level, and resource requirement for personal banking. The result of the survey
highlights that on an average a customer visits the bank 10 to 15 times each month for
transactions, such as cash withdrawal, check deposit, and acquiring the transaction
summary.
The bank needs to have a software system that can reduce customer visits and improve
customer service through improved facilities. The representatives of the InfoSuper bank
presented the requirements for the software system to Janes Technologies. After
analyzing the requirement document, the project manager, Jennifer, of Janes Technologies
suggested that the bank should incorporate an Automatic Teller Machine (ATM) system
with the following features:
 Cash withdrawal
 Cash deposit
 Transaction summary
 PIN change
 Fund transfer within the same bank
 Information about various other services provided by the bank
The place where the ATM system will be deployed should also provide boxes where
customers can drop the checks and request for checkbooks.
Jennifer needs to design the ATM system highlighting the system advantages and
constituents.
Activity: Identifying Requirements and Creating a
Use Case Diagram for the InfoSuper Bank