UNIT II

REQUIRMENTS ENGINEERING AND

ANALYSIS

By
Prof. Shubhangi Chatnale
 Requirement Engineering:
Requirements Engineering is the process of identifying, eliciting, analysing,
specifying, validating, and managing the needs and expectations of stakeholders for
a software system.
A systematic and strict approach to the definition, creation, and verification of
requirements for a software system is known as requirements engineering.
To guarantee the effective creation of a software product, the requirements
engineering process entails several tasks that help in understanding, recording, and
managing the demands of stakeholders.
Requirements Engineering Process

1. Feasibility Study
a) Technical Feasibility

b) Operational Feasibility

c) Economic Feasibility

d) Legal Feasibility

e) Schedule Feasibility

2. Requirements elicitation

3. Requirements specification

4. Requirements for verification and validation

5. Requirements management
Types of requirements:
• User requirement
• System requirement
• Functional Requirement
• Non-functional requirement
• Organizational requirement
• Product requirement
• External requirement
Unified Modeling Language
(UML)
• Unified Modeling Language (UML) is a general-
purpose modeling language. The main aim of UML is to
define a standard way to visualize the way a system
has been designed. It is quite similar to blueprints used
in other fields of engineering. UML is not a
programming language , it is rather a visual
language.
1.Data Flow Diagram
• A data flow diagram is a graphical view of how data is
processed in a system in terms of input and output.
The Data flow diagram (DFD) contains some symbol for
drawing the data flow diagram.
• The context level data flow diagram (dfd) is describe the whole system. The (o) level dfd
describe the all user module who operate the system. Below data flow diagram of online
shopping site shows the two user can operate the system Admin and Member user.
1st Level Admin Side DFD
• The Admin side DFD describe
the functionality of Admin,
Admin is a owner of the
website.
• Admin can first add category of
item and then add items by
category wise. and admin can
manage order and payment
detail.
• The user is all people who operate or visit our website. User
is a customer of a website. User can first select product for
buy, user must have to register in our system for purchase
any item from our website. after register he can login to
site and buy item by making online payment through any
bank debit card or credit card.
2. Use case Diagram
• A Use Case Diagram is a type of Unified Modelling Language (UML) diagram that represents the interaction
between actors (users or external systems) and a system under consideration to accomplish specific goals.
• It provides a high-level view of the system’s functionality by illustrating the various ways users can interact
with it.
Use Case Diagram Notations
1. Actors
• Actors are external entities that interact with the system. These can include users, other systems, or hardware
devices.
• In the context of a Use Case Diagram, actors initiate use cases and receive the outcomes. Proper identification and
understanding of actors are crucial for accurately modelling system behaviour.

2.Use Cases
• Use cases are like scenes in the play. They represent specific things your system can do.
3.System Boundary
• The system boundary is a visual representation of the scope or limits of the system you are modeling.
• It defines what is inside the system and what is outside.
• The boundary helps to establish a clear distinction between the elements that are part of the system and those
that are external to it.
• The system boundary is typically represented by a rectangular box that surrounds all the use cases of the system.
• Use Case Diagram Relationships
Association Relationship
represents a communication or interaction between an actor and a use case
• Example: Online Banking System

 Actor: Customer

 Use Case: Transfer Funds

 Association: A line connecting the “Customer” actor to the “Transfer Funds” use case, indicating the customer’s
involvement in the funds transfer process.
• Include Relationship
• use case includes the functionality of another use case. It is denoted by a dashed arrow pointing from the
including use case to the included use case. This relationship promotes modular and reusable design
• Example: Social Media Posting

 Use Cases: Compose Post, Add Image

 Include Relationship: The “Compose Post” use case includes the functionality of “Add Image.” Therefore,
composing a post includes the action of adding an image.
• Extend Relationship
• The Extend Relationship illustrates that a use case can be extended by another use case under specific conditions.
It is represented by a dashed arrow with the keyword “extend.” This relationship is useful for handling optional or
exceptional behavior.
• Example: Flight Booking System

 Use Cases: Book Flight, Select Seat

 Extend Relationship: The “Select Seat” use case may extend the “Book Flight” use case when the user wants to
choose a specific seat, but it is an optional step.
• Generalization Relationship
• The Generalization Relationship establishes an “is-a” connection between two use cases, indicating that one use
case is a specialized version of another. It is represented by an arrow pointing from the specialized use case to the
general use case.

• Example: Vehicle Rental System

 Use Cases: Rent Car, Rent Bike

 Generalization Relationship: Both “Rent Car” and “Rent Bike” are specialized versions of the general use case
“Rent Vehicle.”
• How to draw a Use Case diagram in UML?

• Step 1: Identify Actors

• Step 2: Identify Use Cases

• Step 3: Connect Actors and Use Cases

• Step 4: Add System Boundary

• Step 5: Define Relationships

• Step 6: Review and Refine

• Step 7: Validate
 Activity Diagrams | Unified Modeling Language (UML)
• Activity Diagrams are used to illustrate the flow of control in a system and refer to the steps involved in the
execution of a use case.
• It is a type of behavioural diagram and we can depict both sequential processing and concurrent processing
of activities using an activity diagram ie an activity diagram focuses on the condition of flow and the sequence
in which it happens.
Activity Diagram Notations
1. Initial State
A process can have only one initial state unless we are depicting nested activities. We use a black filled circle to depict
the initial state of a system.
2. Action or Activity State
An activity represents execution of an action on objects or by objects. We represent an activity using a rectangle with
rounded corners. Basically any action or event that takes place is represented using an activity.

• 3. Action Flow or Control flows

• Action flows or Control flows are also referred to as paths and edges. They are used to show the transition
from one activity state to another activity state
4. Decision node and Branching
When we need to make a decision before deciding the flow of control, we use the decision node. The outgoing
arrows from the decision node can be labelled with conditions or guard expressions. It always includes two or more
output arrows.

5. Guard
A Guard refers to a statement written next to a decision node on an arrow sometimes within square brackets.
6. Fork
Fork nodes are used to support concurrent activities. When we use a fork node when both the activities get executed
concurrently i.e. no decision is made before splitting the activity into two parts.
7. Join
Join nodes are used to support concurrent activities converging into one.
When both activities i.e. steaming the milk and adding coffee get completed, we converge them into one final
activity.
8. Merge or Merge Event
Scenarios arise when activities which are not being executed concurrently have to be merged.
We use the merge notation for such scenarios.
We can merge two or more activities into one if the control proceeds onto the next activity irrespective of the path
chosen.
• For example:

• In the diagram below: we can’t have both sides executing concurrently, but they finally merge into one. A number
can’t be both odd and even at the same time
• Swimlanes
• We use Swimlanes for grouping related activities in one column. Swimlanes group related activities into one
column or one row. Swimlanes can be vertical and horizontal. Swimlanes are used to add modularity to the
activity diagram. It is not mandatory to use Swimlanes. They usually give more clarity to the activity diagram.
It’s similar to creating a function in a program. It’s not mandatory to do so, but, it is a recommended
practice.
• Here different set of activities are executed based on if the number is odd or even. These activities are
grouped into a swimlane.
• Time Event
• This refers to an event that stops the flow for a time; an hourglass depicts it. We can have a scenario where
an event takes some time to completed.
• Let us assume that the processing of an image takes a lot of time. Then it can be represented as shown
below.
• Final State or End State
• The state which the system reaches when a particular process or activity ends is known as a Final State or End
State. We use a filled circle within a circle notation to represent the final state in a state machine diagram. A
system or a process can have multiple final states.
 Requirements Traceability Matrix
RTM maps all the requirements with the test cases.
By using this document one can verify test cases cover all
functionality of the application as per the requirements of the
customer.
•Requirements: Requirements of a particular project from the
client.
•Traceability: The ability to trace the tests.
•Matrix: The data which can be stored in rows and columns form.

• The main purpose of the requirement traceability matrix is to

verify that the all requirements of clients are covered in the test
cases designed by the testers.
• In simple words, one can say it is a pen and pencil approach
i.e., to analyze the two data information but here we are using
an Excel sheet to verify the data in a requirement traceability
matrix.