UNIT-II-Requirements Engineering modeling

2.1 Functional and non-Functional requirements

Functional Requirements: These are the requirements that the end user specifically demands as basic facilities
that the system should offer. All these functionalities need to be necessarily incorporated into the system as a
part of the contract. These are represented or stated in the form of input to be given to the system, the operation
performed and the output expected. They are basically the requirements stated by the user which one can see
directly in the final product, unlike the nonfunctional requirements.
Non-functional requirements: These are basically the quality constraints that the system must satisfy
according to the project contract. The priority or extent to which these factors are implemented varies from
one project to other. They are also called non-behavioral requirements.
They basically deal with issues like:

Portability
Security
Maintainability
Reliability
Scalability
Performance
Reusability
Flexibility
Table: 2.1Differences between functional and non functional requirements

2.2 The software requirements document

Documentation ensures that the software development team or other stakeholders are on the same page
regarding what needs to be built and are fully aware of the goal, scope, functional requirements, challenges,
and budget regarding the software. However, as much as creating software is exciting, documenting its
requirements can be boring and tiresome.
Introduction :
(i) Purpose of this Document –
At first, main aim of why this document is necessary and what’s purpose of document is explained and
described.
(ii) Scope of this document –
In this, overall working and main objective of document and what value it will provide to customer is
described and explained. It also includes a description of development cost and time required.
(iii) Overview –
In this, description of product is explained. It’s simply summary or overall review of product.
General description :
In this, general functions of product which includes objective of user, a user characteristic, features, benefits,
about why its importance is mentioned. It also describes features of user community.

Functional Requirements :
In this, possible outcome of software system which includes effects due to operation of program is fully
explained. All functional requirements which may include calculations, data processing, etc. are placed in a
ranked order.

Interface Requirements :
In this, software interfaces which mean how software program communicates with each other or users either
in form of any language, code, or message are fully described and explained. Examples can be shared memory,
data streams, etc.

Performance Requirements :
In this, how a software system performs desired functions under specific condition is explained. It also
explains required time, required memory, maximum error rate, etc.

Design Constraints :
In this, constraints which simply means limitation or restriction are specified and explained for design team.
Examples may include use of a particular algorithm, hardware and software limitations, etc.

Non-Functional Attributes :
In this, non-functional attributes are explained that are required by software system for better performance.
An example may include Security, Portability, Reliability, Reusability, Application compatibility, Data
integrity, Scalability capacity, etc.

2.3 Requirements specification

The production of the requirements stage of the software development process is Software Requirements
Specifications (SRS) (also called a requirements document). This report lays a foundation for software
engineering activities and is constructing when entire requirements are elicited and analyzed. SRS is a formal
report, which acts as a representation of software that enables the customers to review whether it (SRS) is
according to their requirements. Also, it comprises user requirements for a system as well as detailed
specifications of the system requirements.

The SRS is a specification for a specific software product, program, or set of applications that perform
particular functions in a specific environment. It serves several goals depending on who is writing it. First,
the SRS could be written by the client of a system. Second, the SRS could be written by a developer of the
system. The two methods create entirely various situations and establish different purposes for the document
altogether. The first case, SRS, is used to define the needs and expectation of the users. The second case, SRS,
is written for various purposes and serves as a contract document between customer and developer.

Following are the features of a good SRS document:

1. Correctness: User review is used to provide the accuracy of requirements stated in the SRS.
SRS is said to be perfect if it covers all the needs that are truly expected from the system.

2. Completeness: The SRS is complete if, and only if, it includes the following elements:

(1). All essential requirements, whether relating to functionality, performance, design, constraints,
attributes, or external interfaces.

(2). Definition of their responses of the software to all realizable classes of input data in all available
categories of situations.

Note: It is essential to specify the responses to both valid and invalid values.
(3). Full labels and references to all figures, tables, and diagrams in the SRS and definitions of all
terms and units of measure.

3. Consistency: The SRS is consistent if, and only if, no subset of individual requirements
described in its conflict. There are three types of possible conflict in the SRS:

(1). The specified characteristics of real-world objects may conflicts. For example,

(a) The format of an output report may be described in one requirement as tabular but in another
as textual.
 (b) One condition may state that all lights shall be green while another states that all lights shall
be blue.

(2). There may be a reasonable or temporal conflict between the two specified actions. For example,

(a) One requirement may determine that the program will add two inputs, and another may
determine that the program will multiply them.

(b) One condition may state that "A" must always follow "B," while other requires that "A and
B" co-occurs.

(3). Two or more requirements may define the same real-world object but use different terms for that
object. For example, a program's request for user input may be called a "prompt" in one requirement's
and a "cue" in another. The use of standard terminology and descriptions promotes consistency.

4. Unambiguousness: SRS is unambiguous when every fixed requirement has only one interpretation.
This suggests that each element is uniquely interpreted. In case there is a method used with multiple
definitions, the requirements report should determine the implications in the SRS so that it is clear
and simple to understand.

Ranking for importance and stability: The SRS is ranked for importance and stability if each requirement
in it has an identifier to indicate either the significance or stability of that particular requirement.

Typically, all requirements are not equally important. Some prerequisites may be essential, especially for life-
critical applications, while others may be desirable. Each element should be identified to make these
differences clear and explicit. Another way to rank requirements is to distinguish classes of items as essential,
conditional, and optional.

6. Modifiability: SRS should be made as modifiable as likely and should be capable of quickly obtain
changes to the system to some extent. Modifications should be perfectly indexed and cross-referenced.

7. Verifiability: SRS is correct when the specified requirements can be verified with a cost-effective
system to check whether the final software meets those requirements. The requirements are verified with the
help of reviews.

8. Traceability: The SRS is traceable if the origin of each of the requirements is clear and if it facilitates
the referencing of each condition in future development or enhancement documentation.
2.4 Requirement engineering process
Requirement Engineering is the process of defining, documenting and maintaining the requirements. It is a
process of gathering and defining service provided by the system. Requirements Engineering Process consists
of the following main activities:

Requirements elicitation
Requirements specification
Requirements verification and validation
Requirements management
Requirements Elicitation:
It is related to the various ways used to gain knowledge about the project domain and requirements. The
various sources of domain knowledge include customers, business manuals, the existing software of same
type, standards and other stakeholders of the project.
The techniques used for requirements elicitation include interviews, brainstorming, task analysis, Delphi
technique, prototyping, etc. Some of these are discussed here. Elicitation does not produce formal models of
the requirements understood. Instead, it widens the domain knowledge of the analyst and thus helps in
providing input to the next stage.

Requirements specification:
This activity is used to produce formal software requirement models. All the requirements including the
functional as well as the non-functional requirements and the constraints are specified by these models in
totality. During specification, more knowledge about the problem may be required which can again trigger
the elicitation process.
The models used at this stage include ER diagrams, data flow diagrams(DFDs), function decomposition
diagrams(FDDs), data dictionaries, etc.

Requirements verification and validation:

Verification: It refers to the set of tasks that ensures that the software correctly implements a specific function.
Validation: It refers to a different set of tasks that ensures that the software that has been built is traceable to
customer requirements.
If requirements are not validated, errors in the requirement definitions would propagate to the successive
stages resulting in a lot of modification and rework.
The main steps for this process include:

The requirements should be consistent with all the other requirements i.e no two requirements should conflict
with each other.
The requirements should be complete in every sense.
The requirements should be practically achievable.
Reviews, buddy checks, making test cases, etc. are some of the methods used for this.

Requirements management:
Requirement management is the process of analyzing, documenting, tracking, prioritizing and agreeing on the
requirement and controlling the communication to relevant stakeholders. This stage takes care of the changing
nature of requirements. It should be ensured that the SRS is as modifiable as possible so as to incorporate
changes in requirements specified by the end users at later stages too. Being able to modify the software as
per requirements in a systematic and controlled manner is an extremely important part of the requirements
engineering process.
2.5 Requirements elicitation and analysis
Requirements elicitation is perhaps the most difficult, most error-prone and most communication intensive
software development. It can be successful only through an effective customer-developer partnership. It is
needed to know what the users really need.

Requirements elicitation Activities:

Requirements elicitation includes the subsequent activities. Few of them are listed below –

Knowledge of the overall area where the systems is applied.

The details of the precise customer problem where the system are going to be applied must be understood.
Interaction of system with external requirements.
Detailed investigation of user needs.
Define the constraints for system development.
Requirements elicitation Methods:
There are a number of requirements elicitation methods. Few of them are listed below –

Interviews
Brainstorming Sessions
Facilitated Application Specification Technique (FAST)
Quality Function Deployment (QFD)
Use Case Approach
The success of an elicitation technique used depends on the maturity of the analyst, developers, users, and the
customer involved.
1. Interviews:
Objective of conducting an interview is to understand the customer’s expectations from the software.
It is impossible to interview every stakeholder hence representatives from groups are selected based on their
expertise and credibility.

Interviews maybe be open-ended or structured.

In open-ended interviews there is no pre-set agenda. Context free questions may be asked to understand the
problem.
In structured interview, agenda of fairly open questions is prepared. Sometimes a proper questionnaire is
designed for the interview.
2. Brainstorming Sessions:

It is a group technique
It is intended to generate lots of new ideas hence providing a platform to share views
A highly trained facilitator is required to handle group bias and group conflicts.
Every idea is documented so that everyone can see it.
Finally, a document is prepared which consists of the list of requirements and their priority if possible.
3. Facilitated Application Specification Technique:
It’s objective is to bridge the expectation gap – difference between what the developers think they are
supposed to build and what customers think they are going to get.

A team oriented approach is developed for requirements gathering. Each attendee is asked to
make a list of objects that are-

Part of the environment that surrounds the system

Produced by the system
Used by the system
Each participant prepares his/her list, different lists are then combined, redundant entries are eliminated, team
is divided into smaller sub-teams to develop minispecifications and finally a draft of specifications is written
down using all the inputs from the meeting.
4. Quality Function Deployment:
In this technique customer satisfaction is of prime concern, hence it emphasizes on the requirements which
are valuable to the customer.
3 types of requirements are identified –

Normal requirements –
In this the objective and goals of the proposed software are discussed with the customer. Example – normal
requirements for a result management system may be entry of marks, calculation of results, etc
Expected requirements –
These requirements are so obvious that the customer need not explicitly state them. Example – protection
from unauthorized access.
Exciting requirements –
It includes features that are beyond customer’s expectations and prove to be very satisfying when present.
Example – when unauthorized access is detected, it should backup and shutdown all processes.
The major steps involved in this procedure are –

Identify all the stakeholders, eg. Users, developers, customers etc

List out all requirements from customer.
A value indicating degree of importance is assigned to each requirement.
In the end the final list of requirements is categorized as –
It is possible to achieve
It should be deferred and the reason for it
It is impossible to achieve and should be dropped off
5. Use Case Approach:
This technique combines text and pictures to provide a better understanding of the requirements.
The use cases describe the ‘what’, of a system and not ‘how’. Hence, they only give a functional view of the
system.
The components of the use case design includes three major things – Actor, Use cases, use case diagram.

Actor –
It is the external agent that lies outside the system but interacts with it in some way. An actor maybe a person,
machine etc. It is represented as a stick figure. Actors can be primary actors or secondary actors.
Primary actors – It requires assistance from the system to achieve a goal.
Secondary actor – It is an actor from which the system needs assistance.
Use cases –
They describe the sequence of interactions between actors and the system. They capture who(actors) do
what(interaction) with the system. A complete set of use cases specifies all possible ways to use the system.
Use case diagram –
A use case diagram graphically represents what happens when an actor interacts with a system. It captures the
functional aspect of the system.
A stick figure is used to represent an actor.
An oval is used to represent a use case.
A line is used to represent a relationship between an actor and a use case.
2.6 Requirement validation
Requirements validation is the process of checking that requirements defined for development, define the
system that the customer really wants. To check issues related to requirements, we perform requirements
validation. We usually use requirements validation to check error at the initial phase of development as the
error may increase excessive rework when detected later in the development process.

In the requirements validation process, we perform a different type of test to check the requirements
mentioned in the Software Requirements Specification (SRS), these checks include:

Completeness checks
Consistency checks
Validity checks
Realism checks
Ambiguity checks
Verifiability
The output of requirements validation is the list of problems and agreed on actions of detected problems. The
lists of problems indicate the problem detected during the process of requirement validation. The list of agreed
action states the corrective action that should be taken to fix the detected problem.

There are several techniques which are used either individually or in conjunction with other techniques to
check to check entire or part of the system:

Test case generation:

Requirement mentioned in SRS document should be testable, the conducted tests reveal the error present in
the requirement. It is generally believed that if the test is difficult or impossible to design than, this usually
means that requirement will be difficult to implement and it should be reconsidered.
Prototyping:
In this validation techniques the prototype of the system is presented before the end-user or customer, they
experiment with the presented model and check if it meets their need. This type of model is generally used to
collect feedback about the requirement of the user.
Requirements Reviews:
In this approach, the SRS is carefully reviewed by a group of people including people from both the contractor
organisations and the client side, the reviewer systematically analyses the document to check error and
ambiguity.
Automated Consistency Analysis:
This approach is used for automatic detection of an error, such as nondeterminism, missing cases, a type error,
and circular definitions, in requirements specifications.
First, the requirement is structured in formal notation then CASE tool is used to check in-consistency of the
system, The report of all inconsistencies is identified and corrective actions are taken.

Walk-through:
A walkthrough does not have a formally defined procedure and does not require a differentiated role
assignment.
Checking early whether the idea is feasible or not.
Obtaining the opinions and suggestion of other people.
Checking the approval of others and reaching an agreement.
2.7 Requirement management
Requirements management is important because it empowers everyone to clearly understand stakeholder
expectations and confidently deliver a product that has been verified to meet the requirements and validated
to meet the needs.

Requirements management is a sophisticated process that includes many moving parts and diverse groups of
people. Typically, the product management department, specifically the product manager, is responsible for
the requirements management process. They work with the stakeholders, including business teams,
customers, users, developers, testers, regulators, and quality assurance.

Additionally, a product may have only 100 requirements, or it may have several thousand. This number will
depend on the product’s complexity and level of regulation. With all these elements at play, success hinges
on the ability to get everyone on the same page, working toward the same goal.
Therefore, the business value of managing requirements is huge, as successful requirements management is
key to project success. Benefits of requirements management include:

Enhance understanding of stakeholder needs, requirements, and expectations and the problem or opportunity
the product means to address
Gain clarity on scope, budget, and schedule
Minimize costly, time-consuming rework
Increase product quality
Mitigate risk
Improve likelihood of delivering the right product, within budget and schedule with the required quality.
2.8 Requirement analysis
Requirement analysis is significant and essential activity after elicitation. We analyze, refine, and scrutinize
the gathered requirements to make consistent and unambiguous requirements. This activity reviews all
requirements and may provide a graphical view of the entire system. After the completion of the analysis, it
is expected that the understandability of the project may improve significantly. Here, we may also use the
interaction with the customer to clarify points of confusion and to understand which requirements are more
important than others.
The various steps of requirement analysis are shown in fig:
Requirements Analysis
(i) Draw the context diagram: The context diagram is a simple model that defines the boundaries and
interfaces of the proposed systems with the external world. It identifies the entities outside the proposed
system that interact with the system. The context diagram of student result management system is given
below:

Requirements Analysis
(ii) Development of a Prototype (optional): One effective way to find out what the customer wants is to
construct a prototype, something that looks and preferably acts as part of the system they say they want.

We can use their feedback to modify the prototype until the customer is satisfied continuously. Hence, the
prototype helps the client to visualize the proposed system and increase the understanding of the requirements.
When developers and users are not sure about some of the elements, a prototype may help both the parties to
take a final decision.
Some projects are developed for the general market. In such cases, the prototype should be shown to some
representative sample of the population of potential purchasers. Even though a person who tries out a
prototype may not buy the final system, but their feedback may allow us to make the product more attractive
to others.

The prototype should be built quickly and at a relatively low cost. Hence it will always have limitations and
would not be acceptable in the final system. This is an optional activity.

(iii) Model the requirements: This process usually consists of various graphical representations of the
functions, data entities, external entities, and the relationships between them. The graphical view may help to
find incorrect, inconsistent, missing, and superfluous requirements. Such models include the Data Flow
diagram, Entity-Relationship diagram, Data Dictionaries, State-transition diagrams, etc.

(iv) Finalise the requirements: After modeling the requirements, we will have a better understanding of
the system behavior. The inconsistencies and ambiguities have been identified and corrected. The flow of
data amongst various modules has been analyzed. Elicitation and analyze activities have provided better
insight into the system. Now we finalize the analyzed requirements, and the next step is to document these
requirements in a prescribed format.
2.9 Data modeling concepts

It is the process of creating a data model for the data to be stored in a database. This

data model is a conceptual representation of Data objects, the associations between

different data objects, and the rules.

Data modeling helps in the visual representation of data and enforces business rules,

regulatory compliances, and government policies on the data. Data

Models in DBMS
The Data Model is defined as an abstract model that organizes data description, data
semantics, and consistency constraints of data. The data model emphasizes on what
data is needed and how it should be organized instead of what operations will be
performed on data. Data Model is like an architect’s building plan, which helps to build
conceptual models and set a relationship between data items.
The two types of Data Modeling Techniques are

1. Entity Relationship (E-R) Model

 2. UML (Unified Modelling Language)

Types of Data Models in DBMS

Types of Data Models: There are mainly three different types of data models:
conceptual data models, logical data models, and physical data models, and each one
has a specific purpose. The data models are used to represent the data and how it is
stored in the database and to set the relationship between data items.

Conceptual Data Model: This Data Model defines WHAT the system contains. This
model is typically created by Business stakeholders and Data Architects. The purpose is
to organize, scope and define business concepts and rules.
Logical Data Model: Defines HOW the system should be implemented regardless of the
DBMS. This model is typically created by Data Architects and Business Analysts.
The purpose is to developed technical map of rules and data structures.
Physical Data Model: This Data Model describes HOW the system will be implemented
using a specific DBMS system. This model is typically created by DBA and developers.
The purpose is actual implementation of the database.
 Fig: Types of data model

Conceptual Data Model

A Conceptual Data Model is an organized view of database concepts and their relationships. The purpose of
creating a conceptual data model is to establish entities, their attributes, and relationships. In this data
modeling level, there is hardly any detail available on the actual database structure. Business stakeholders
and data architects typically create a conceptual data model.

The 3 basic tenants of Conceptual Data Model are

• Entity: A real-world thing

• Attribute: Characteristics or properties of an entity
• Relationship: Dependency or association between two entities

Data model example:

• Customer and Product are two entities. Customer number and name are attributes of the Customer
entity
• Product name and price are attributes of product entity
• Sale is the relationship between the customer and product

Fig: Conceptual Data Model

Characteristics of a conceptual data model

• Offers Organisation-wide coverage of the business concepts.

• This type of Data Models are designed and developed for a business audience.
• The conceptual model is developed independently of hardware specifications like data storage
capacity, location or software specifications like DBMS vendor and technology. The focus is to
represent data as a user will see it in the “real world.”

Conceptual data models known as Domain models create a common vocabulary for all stakeholders by
establishing basic concepts and scope.

Logical Data Model

The Logical Data Model is used to define the structure of data elements and to set relationships between
them. The logical data model adds further information to the conceptual data model elements. The
advantage of using a Logical data model is to provide a foundation to form the base for the Physical model.
However, the modeling structure remains generic.

Logical Data Model

At this Data Modeling level, no primary or secondary key is defined. At this Data modeling level, you need
to verify and adjust the connector details that were set earlier for relationships.
Characteristics of a Logical data model

• Describes data needs for a single project but could integrate with other logical data models based on
the scope of the project.
• Designed and developed independently from the DBMS.
• Data attributes will have datatypes with exact precisions and length.
• Normalization processes to the model is applied typically till 3NF.

Physical Data Model

A Physical Data Model describes a database-specific implementation of the data model. It offers database
abstraction and helps generate the schema. This is because of the richness of meta-data offered by a Physical
Data Model. The physical data model also helps in visualizing database structure by replicating database
column keys, constraints, indexes, triggers, and other RDBMS features.

Fig:Physical Data Model

Characteristics of a physical data model:

 • The physical data model describes data need for a single project or application though it maybe
integrated with other physical data models based on project scope.
• Data Model contains relationships between tables that which addresses cardinality and nullability of
the relationships.
• Developed for a specific version of a DBMS, location, data storage or technology to be used in the
project.
• Columns should have exact datatypes, lengths assigned and default values.
• Primary and Foreign keys, views, indexes, access profiles, and authorizations, etc. are defined.
Advantages and Disadvantages of Data Model:
Advantages of Data model:

• The main goal of a designing data model is to make certain that data objects offered by the functional
team are represented accurately.
• The data model should be detailed enough to be used for building the physical database.
• The information in the data model can be used for defining the relationship between tables, primary
and foreign keys, and stored procedures.
• Data Model helps business to communicate the within and across organizations.
• Data model helps to documents data mappings in ETL process
• Help to recognize correct sources of data to populate the model

Disadvantages of Data model:

• To develop Data model one should know physical data stored characteristics.
• This is a navigational system produces complex application development, management. Thus, it
requires a knowledge of the biographical truth.
• Even smaller change made in structure require modification in the entire application.
• There is no set data manipulation language in DBMS.

2.10 Flow oriented modeling

Flow Oriented Modeling

It shows how data objects are transformed by processing the function.

The Flow oriented elements are:

i. Data flow model

• It is a graphical technique. It is used to represent information flow.

• The data objects are flowing within the software and transformed by processing the elements.
• The data objects are represented by labeled arrows. Transformation are represented by circles called
as bubbles.
 • DFD shown in a hierarchical fashion. The DFD is split into different levels. It also called as 'context
level diagram'.
ii. Control flow model
• Large class applications require a control flow modeling.
• The application creates control information instated of reports or displays.
• The applications process the information in specified time.
• An event is implemented as a boolean value.
For example, the boolean values are true or false, on or off, 1 or 0.
iii. Control Specification

• A short term for control specification is CSPEC.

• It represents the behaviour of the system.
• The state diagram in CSPEC is a sequential specification of the behaviour.
• The state diagram includes states, transitions, events and activities.
• State diagram shows the transition from one state to another state if a particular event has occurred.
iv. Process Specification

• A short term for process specification is PSPEC.

• The process specification is used to describe all flow model processes.
• The content of process specification consists narrative text, Program Design Language(PDL) of the
process algorithm, mathematical equations, tables or
UML activity diagram.

2.11 scenario based modeling

Requirements for a computer-based system can be seen in many different ways. Some software people argue
that it’s worth using a number of different modes of representation while others believe that it’s best to select
one mode of representation.

The specific elements of the requirements model are dedicated to the analysis modeling method that is to be
used.

Scenario-based elements :
Using a scenario-based approach, system is described from user’s point of view. For example, basic use cases
and their corresponding use-case diagrams evolve into more elaborate template-based use cases. Figure 1(a)
depicts a UML activity diagram for eliciting requirements and representing them using use cases. There are
three levels of elaboration.
Class-based elements :
A collection of things that have similar attributes and common behaviors i.e., objects are categorized into
classes. For example, a UML case diagram can be used to depict a Sensor class for the SafeHome security
function. Note that diagram lists attributes of sensors and operations that can be applied to modify these
attributes. In addition to class diagrams, other analysis modeling elements depict manner in which classes
collaborate with one another and relationships and interactions between classes.
Behavioral elements :
Effect of behavior of computer-based system can be seen on design that is chosen and implementation
approach that is applied. Modeling elements that depict behavior must be provided by requirements model.
2.12 UML modeling
In UML, use-case diagrams model the behavior of a system and help to capture the requirements of the system.
Use-case diagrams describe the high-level functions and scope of a system. These diagrams also identify the
interactions between the system and its actors. The use cases and actors in use-case diagrams describe what
the system does and how the actors use it, but not how the system operates internally.

Use-case diagrams illustrate and define the context and requirements of either an entire system or the
important parts of the system. You can model a complex system with a single use-case diagram, or create
many use-case diagrams to model the components of the system. You would typically develop use-case
diagrams in the early phases of a project and refer to them throughout the development process.

Use-case diagrams are helpful in the following situations:

Before starting a project, you can create use-case diagrams to model a business so that all participants in the
project share an understanding of the workers, customers, and activities of the business.
While gathering requirements, you can create use-case diagrams to capture the system requirements and to
present to others what the system should do.
During the analysis and design phases, you can use the use cases and actors from your use-case diagrams to
identify the classes that the system requires.
During the testing phase, you can use use-case diagrams to identify tests for the system.
The following topics describe model elements in use-case diagrams:

Use cases
A use case describes a function that a system performs to achieve the user’s goal. A use case must yield an
observable result that is of value to the user of the system.
Actors
An actor represents a role of a user that interacts with the system that you are modeling. The user can be a
human user, an organization, a machine, or another external system.
Subsystems
In UML models, subsystems are a type of stereotyped component that represent independent, behavioral units
in a system. Subsystems are used in class, component, and use-case diagrams to represent large-scale
components in the system that you are modeling.
Relationships in use-case diagrams
In UML, a relationship is a connection between model elements. A UML relationship is a type of model
element that adds semantics to a model by defining the structure and behavior between the model elements.

2.13 case study

Use case diagram is a behavioral UML diagram type and frequently used to analyze various systems. They
enable you to visualize the different types of roles in a system and how those roles interact with the system.
This use case diagram tutorial will cover the following topics and help you create use cases better.

• Importance of use case diagrams

• Use case diagram objects
• Use case diagram guidelines
• Relationships in use case diagrams
• How to create use case diagrams ( with example ) o Identifying actors o Identifying use cases o When
to use “Include” o How to use generalization o When to use “Extend”
• Use case diagram templates of common scenarios

Importance of Use Case Diagrams

As mentioned before use case diagrams are used to gather a usage requirement of a system. Depending on
your requirement you can use that data in different ways. Below are few ways to use them.

• To identify functions and how roles interact with them – The primary purpose of use case diagrams.
• For a high-level view of the system – Especially useful when presenting to managers or stakeholders.
You can highlight the roles that interact with the system and the functionality provided by the system
without going deep into inner workings of the system.
• To identify internal and external factors – This might sound simple but in large complex projects a
system can be identified as an external role in another use case.

Use Case Diagram objects

Use case diagrams consist of 4 objects.

• Actor
• Use case
• System
• Package

The objects are further explained below.

Actor

Actor in a use case diagram is any entity that performs a role in one given system. This could be a person,
organization or an external system and usually drawn like skeleton shown below.
Use Case

A use case represents a function or an action within the system. It’s drawn as an oval and named with the
function.

System

The system is used to define the scope of the use case and drawn as a rectangle. This an optional element but
useful when you’re visualizing large systems. For example, you can create all the use cases and then use the
system object to define the scope covered by your project. Or you can even use it to show the different areas
covered in different releases.

Package
The package is another optional element that is extremely useful in complex diagrams. Similar to class
diagrams, packages are used to group together use cases. They are drawn like the image shown below.

Use Case Diagram Guidelines

Although use case diagrams can be used for various purposes there are some common guidelines you need to
follow when drawing use cases.

These include naming standards, directions of arrows, the placing of use cases, usage of system boxes and
also proper usage of relationships.

We’ve covered these guidelines in detail in a separate blog post. So go ahead and check out use case diagram
guidelines.

Relationships in Use Case Diagrams

There are five types of relationships in a use case diagram. They are

• Association between an actor and a use case

• Generalization of an actor
• Extend relationship between two use cases
• Include relationship between two use cases
• Generalization of a use case

We have covered all these relationships in a separate blog post that has examples with images. We will not
go into detail in this post but you can check out relationships in use case diagrams.

How to Create a Use Case Diagram

Up to now, you’ve learned about objects, relationships and guidelines that are critical when drawing use case
diagrams. I’ll explain the various processes using a banking system as an example.

Identifying Actors

Actors are external entities that interact with your system. It can be a person, another system or an
organization. In a banking system, the most obvious actor is the customer. Other actors can be bank employee
or cashier depending on the role you’re trying to show in the use case.
An example of an external organization can be the tax authority or the central bank. The loan processor is a
good example of an external system associated as an actor.
Identifying Use Cases

Now it’s time to identify the use cases. A good way to do this is to identify what the actors need from the
system. In a banking system, a customer will need to open accounts, deposit and withdraw funds, request
check books and similar functions. So all of these can be considered as use cases.

Top level use cases should always provide a complete function required by an actor. You can extend or include
use cases depending on the complexity of the system.

Once you identify the actors and the top level use case you have a basic idea of the system. Now you can fine
tune it and add extra layers of detail to it.

Look for Common Functionality to use Include

Look for common functionality that can be reused across the system. If you find two or more use cases that
share common functionality you can extract the common functions and add it to a separate use case. Then
you can connect it via the include relationship to show that it’s always called when the original use case is
executed. ( see the diagram for an example ).

Is it Possible to Generalize Actors and Use Cases

There may be instances where actors are associated with similar use cases while triggering a few use cases
unique only to them. In such instances, you can generalize the actor to show the inheritance of functions. You
can do a similar thing for use case as well.

One of the best examples of this is “Make Payment” use case in a payment system. You can further generalize
it to “Pay by Credit Card”, “Pay by Cash”, “Pay by Check” etc. All of them have the attributes and the
functionality of payment with special scenarios unique to them.

Optional Functions or Additional Functions

There are some functions that are triggered optionally. In such cases, you can use the extend relationship and
attach an extension rule to it. In the below banking system example “Calculate Bonus” is optional and only
triggers when a certain condition is matched.

Extend doesn’t always mean it’s optional. Sometimes the use case connected by extending can supplement
the base use case. The thing to remember is that the base use case should be able to perform a function on its
own even if the extending use case is not called.
Use Case Diagram Templates