Unit 2

and
Modelling

By Prof. Prerna Solanke

 REQUIREMENT ENGINEERING
● Requirements engineering (RE) refers to the process of defining,
documenting, and maintaining requirements in the engineering
design process.
● It focuses on assessing if the system is useful to the business
(feasibility study), discovering requirements (elicitation and
analysis), converting these requirements into some standard
format (specification), and checking that the requirements define
the system that the customer wants (validation) and
management.
REQUIREMENT ENGINEERING PROCESS
 REQUIREMENT ENGINEERING PROCESS
● Feasibility study: Identify whether the system is worth implementing and
can be implemented under the current budget, technical skills, schedule etc.
● Requirement Elicitation and Analysis: In this, requirements are identified
with the help of customers and existing systems processes, if available.
● Software requirement specification: It is a kind of document which is
created by a software analyst after the requirements collected from the
various sources.
● Software Requirement Validation: After requirement specifications, the
requirements discussed in this document are validated. The user might
demand illegal, impossible solution or experts may misinterpret the needs.
 REQUIREMENT ENGINEERING TASKS
The software requirements engineering process includes the following
steps of activities:
1. Inception
2. Elicitation
3. Elaboration
4. Negotiation
5. Specification
6. Validation
7. Requirements Management
 REQUIREMENT ENGINEERING TASKS

● Inception: It gives an outline of how to get started on a project.

● Elicitation: It focuses on gathering the requirements from the
stakeholders.
● Elaboration: It takes the requirements and refines them.
● Negotiation: It emphasizes discussion and exchanging
conversation between the developer and the customer on what is
needed and what is to be eliminated.
 REQUIREMENT ENGINEERING TASKS

● Specification: In this, the requirements engineer gathers all the

requirements and develops a working model.
● Validation: It focuses on checking for errors and debugging. In this
phase, the developer scans the specification document.
● Requirements Management: In this, the entire team takes part in
identifying, controlling, tracking, and establishing the requirements
for the successful and smooth implementation of the project.
“Tree swing project”
“Tree swing project”
1. The customer doesn’t know
what he needs.
2. The customer did not
communicate his needs very
well.
3. The Project Manager did not
spend enough time
collecting requirements and
verifying an understanding of
the customer’s needs.
TYPES OF REQUIREMENT
 1. FUNCTIONAL REQUIREMENT
Definition: Functional requirements describe what the software should
do. It define the functions or features that the system must have.
Examples:
● User Authentication: The system must allow users to login using a
username and password.
● Search Functionality: The software should enable users to search for
products by name or category.
● Report Generation: The system should be able to generate sales
reports for a specified date range.
Explanation: Functional requirements specify the actions that the
software needs to perform. These are the basic features and
functionalities that users expect from the software.
 2. NON-FUNCTIONAL REQUIREMENT
Definition: It describe how the software performs a task rather than what it
should do. They ensure that the system operates effectively and efficiently.
Examples:
● Performance: The system should process 1,000 transactions per second.
● Usability: The software should be easy to use and have a user-friendly
interface.
● Reliability: The system must have 99.9% uptime.
● Security: Data must be encrypted during transmission and storage.
Explanation: Non-functional requirements ensure that the software meets
certain standards of performance, usability, reliability, and security.
 3. DOMAIN REQUIREMENT
Definition: It is specific to the domain or industry in which the software
operates. It include terminology, rules, and standards relevant to that
particular domain.
Examples:
● Healthcare: The software must comply with HIPAA regulations for
handling patient data.
● Finance: The system should adhere to GAAP standards for financial
reporting.
● E-commerce: The software should support various payment gateways
like PayPal, Stripe, and credit cards.
Explanation: It ensures that the software is relevant and compliant with
industry-specific regulations and standards.
SOFTWARE REQUIREMENT SPECIFICATION (SRS)

● SRS is a complete specification and description of requirements of

the software that need to be fulfilled for the successful
development of the software system.
● These requirements can be functional as well as non-functional
depending upon the type of requirement.
● SRS is developed based the agreement between customer and
contractors/supplier.
SOFTWARE REQUIREMENT SPECIFICATION (SRS)

● First, the SRS could be written by the client of a system in which

they define the needs and expectation.
● Second, the SRS could be written by a developer of the system.
● SRS is written for various purposes and serves as a contract
document between customer and developer.
● The two methods create entirely various situations and establish
different purposes for the document altogether.
Characteristics of SRS Document
SRS DOCUMENT FORMAT
 UML – UNIFIED MODELLING LANGUAGE

● UML is a standard language for specifying, visualizing, constructing,

and documenting the artifacts of software systems.

● UML is not a programming language but tools can be used to

generate code in various languages using UML diagrams.

● UML diagrams are not only made for developers but also for
business users, common people, and anybody interested to
understand the system.
 FEATURES OF UML
• It is a generalized modeling language.

• It is distinct from other programming languages like C++,

Python, etc.

• It is interrelated to object-oriented analysis and design.

• It is used to visualize the workflow of the system.

• It is a pictorial language, used to generate powerful modeling

artifacts.
 UML CATEGORIES

There are two broad categories of diagrams and they are

again divided into subcategories −
○ Structural Diagrams
○ Behavioral Diagrams
 1. STRUCTURAL DIAGRAMS

It Capture static aspects or structure of a system.

Structural Diagrams include:
1. Class diagram
2. Object diagram
3. Component diagram
4. Deployment diagram
 2. BEHAVIORAL DIAGRAMS

It Capture dynamic aspects or behavior of the system.

Behavior diagrams include:
5. Use case diagram
6. Sequence diagram
7. Collaboration diagram
8. State chart diagram
9. Activity diagram
 1. CLASS DIAGRAM
● It is generally used for development purpose.
● This is the most widely used diagram at the time of system
construction.
● Class diagrams can be used for the following purposes:
1. To describe the static view of a system.
2. To show the collaboration among every instance in the static
view.
3. To describe the functionalities performed by the system.
4. To construct the software application using object-oriented
languages.
1. CLASS DIAGRAM- Example
 1. CLASS DIAGRAM
It describes the structure of a system by showing the system’s classes,
it’s attributes, operations (or methods) and relationships among
objects.
 1. CLASS DIAGRAM
● Class attributes can be listed in the form of:
attributeName : Type
● Attributes can be :
○ Public : denoted by “ + ”
○ Protected : denoted by “ # ”
○ Private : denoted by “ - ”
○ Derived : denoted by “ / ”
 1. CLASS DIAGRAM- Relationship Between Classes
A class may be involved in one or more relationships with other classes.
1. CLASS DIAGRAM- Relationship Between Classes
● Association: It represents static
relationships between classes A
and B. For example; the
relationship between student
and college is shown which is
studies.

● Inheritance: It represent parent

child relationship. Teacher and
Student both are people.
 1. CLASS DIAGRAM- Relationship Between Classes
● Realization: It shows that one
class represent the interface of
the other class.
For example, we have a class Person
is a blueprint that can be made into
an object that represents a specific
person like a Student or a Salesman.
Our Student class can study and go
to school, and our Salesman class
can go to work and sell stuff, but
they are people, so they will have
Age and Name attributes.
 1. CLASS DIAGRAM- Relationship Between Classes
● Dependency: Dependency indicates that one class depends on another.
For example, Student has a dependency on College.
1. CLASS DIAGRAM- Relationship Between Classes
● Aggregation: If an association conveys information that one object is
part of another object, but their lifetimes are independent (they could
exist independently), then this relationship is called aggregation.
For example, a university owns various departments and each
department has a number of professors. If the university closes, the
departments will no longer exist, but the professors in those
departments will continue to exist. In addition, a Professor could work in
more than one department, but a department could not be part of more
than one university.
1. CLASS DIAGRAM- Relationship Between Classes
● Composition: It denotes strong ownership between two classes when
one class is a part of another class.
For example, if college is composed of classes student. The college could
contain many students, while each student belongs to only one college.
So, if college is not functioning all the students also removed.
1. CLASS DIAGRAM- Example
 2. OBJECT DIAGRAM
● Object diagrams are dependent on the class diagram as they are
derived from the class diagram.
● It can be used for analysis purpose.
● It represents an instance of a class diagram.
● Notation:
2. OBJECT DIAGRAM- Example
2. OBJECT DIAGRAM- Example
 2. OBJECT DIAGRAM

The application areas where the object diagrams can be

used.
1. To build a prototype of a system.
2. To model complex data structures.
3. To perceive the system from a practical perspective.
 3. COMPONENT DIAGRAM
● A component diagram is used to break down a large
object-oriented system into the smaller components, so as to
make them more manageable.
● Notation:

● It portrays the components of a system at the runtime.

● It is helpful in testing a system.
 3. COMPONENT DIAGRAM

The component diagram can be used for the followings:

1. To model the components of the system.
2. To model the schemas of a database.
3. To model the applications of an application.
4. To model the system's source code.
3. COMPONENT DIAGRAM- Example
3. COMPONENT DIAGRAM- Relationship
 4. DEPLOYMENT DIAGRAM
● A deployment diagram is shows the execution architecture of a
system, including nodes such as hardware or software execution
environments, and the middleware connecting them.
● It determines how the software is deployed on the underlying
hardware.
● Notation:
 4. DEPLOYMENT DIAGRAM

● Deployment diagrams are mostly used by system

administrators, network engineers, etc.
● These diagrams are used with the sole purpose of
describing how software is deployed into the hardware
system.
● It visualizes how software interacts with the hardware to
execute the complete functionality.
4. DEPLOYMENT DIAGRAM - Example

There can be nested

node also, within
which we can include
artifact.
4. DEPLOYMENT DIAGRAM - Example
4. DEPLOYMENT DIAGRAM - Example
 II. BEHAVIORAL DIAGRAMS
It Capture dynamic aspects or behavior of the system.
Behavior diagrams include:
5. Use case diagram
6. Sequence diagram
7. Collaboration diagram
8. State chart diagram
9. Activity diagram
 5. USE CASES DIAGRAM

● A use case describes how a user uses a system to accomplish

a particular goal.
● The actor can be a human, an external system, or time.
● It would help us to understand the role of various actors in
our project. It helps to organize and plan out things.
● Use case diagrams specify the events of a system and their
flows. But it never describes how they are implemented.
 5. USE CASE DIAGRAM - Example
Student
management
system

Note: It is not
necessary that
each actor should
interact with all
the use cases, but
it can happen.
 5. USE CASE DIAGRAM - Purpose
Use case diagrams are typically develop in early stage of development
and people often apply use case modeling for the following purposes:
▪ Specify the context of a system
▪ Capture the requirements of a system
▪ Validate a systems architecture
▪ Drive implementation and generate test cases
▪ Developed by analysts together with domain experts
SAMPLE
USE CASE
DIAGRAM
 5. USE CASE DIAGRAM - Notations
1. Actor: The actor can be a human or other external system i.e.,
someone who interact with use case.

2. Use case: Each Actor must be linked to a use case, while some
use cases may not be linked to actors.

Use Case
 5. USE CASE DIAGRAM - Notations
3. Communication link: The participation of an actor in a use
case is shown by connecting an actor to a use case by a solid link.

4. Boundary of system: The system boundary is potentially the

entire system as defined in the requirements document.

System
 5. USE CASE DIAGRAM - Relationships
Association Link: A Use Case diagram illustrates a set of use cases
for a system, i.e. the actors and the relationships between the
actors and use cases.
 5. USE CASE DIAGRAM - Relationships
Include Relationship: The include relationship adds additional
functionality not specified in the base use case. It is used to include
common behavior from an included use case into a base use case in
order to support the reuse of common behavior.
 5. USE CASE DIAGRAM - Relationships
Extend Relationship: The extend relationships are important
because they show optional functionality or system behavior. It is
used to include optional behavior from an extending use case in an
extended use case.
 5. USE CASE DIAGRAM - Relationships
Generalization Relationship: It means that a child use case inherits the
behavior and meaning of the parent use case. The child may add or
override the behavior of the parent.
 HOW TO DRAW A USE CASE DIAGRAM?
1. Identify the Actors (role of users) of the system.
2. For each category of users, identify all roles played by the users.
3. Identify what are the users required the system to be performed
to achieve these goals.
4. Create use cases for every goal.
5. Structure the use cases.
6. Prioritize, review, estimate and validate the users.
 5. USE CASE DIAGRAM - Benefits
● It is a powerful technique for the elicitation and
documentation of black-box functional requirements.
● It provides an excellent way for communicating with
customers and users as they are written in natural language.
● It can help manage the complexity of large projects by
partitioning the problem into major user features (i.e., use
cases) and by specifying applications from the users’
perspective.
 6. SEQUENCE DIAGRAM
● Sequence Diagrams are interaction diagrams that detail how
operations are carried out.
● It captures high-level interactions between an user and the system,
between the system and other systems, or between subsystems.
● It show elements as they interact over time and they are organized
according to object (horizontally) and time (vertically):
● Object Dimension: The horizontal axis shows the elements that
are involved in the interaction.
● Time Dimension: The vertical axis represents time proceedings
(or progressing) down the page.
6. SEQUENCE DIAGRAM-Relationships
6. SEQUENCE DIAGRAM-Relationships
6. SEQUENCE DIAGRAM - Example
6. SEQUENCE DIAGRAM - Example
 6. SEQUENCE DIAGRAM - Example

This sequence diagram has three objects: (User, Device, Database).

 7. COLLABORATION DIAGRAM
● Collaboration diagrams (known as Communication Diagram) are
used to show how objects interact to perform the behavior of a
particular use case, or a part of a use case.
● Along with sequence diagrams, collaboration are used by designers
to define and clarify the roles of the objects that perform a
particular flow of events of a use case.
● In this, the method call sequence is indicated by some numbering
technique. The number indicates how the methods are called one
after another.
7. COLLABORATION DIAGRAM- Components
 7. COLLABORATION DIAGRAM
● Method calls are similar to that of a sequence diagram. However,
difference being the sequence diagram does not describe the
object organization, whereas the collaboration diagram shows
the object organization.
● To choose between these two diagrams, emphasis is placed on
the type of requirement. If the time sequence is important, then
the sequence diagram is used. If object organization is required,
then collaboration diagram is used.
7. COLLABORATION DIAGRAM- Example
 8. STATE DIAGRAM
● State diagram is used to model the dynamic nature of a system.
● A state diagram is used to represent the condition of the system or
part of the system at finite instances of time.
● It is also referred to as State machines and State-chart Diagrams
● Before drawing a Statechart diagram we should clarify the following
points −
○ Identify the objects
○ Identify the states
○ Identify the events
8. STATECHART DIAGRAM- How To Draw?
8. STATE DIAGRAM- Example
8. STATE DIAGRAM- Example
8. STATE DIAGRAM- Example
 8. STATECHART DIAGRAM- Basic Components
● Initial state – We use a black filled circle represent the initial state of
a System or a class.

● Transition – We use a solid arrow to represent the transition or

change of control from one state to another. The arrow is labelled
with the event which causes the change in state.
 8. STATECHART DIAGRAM- Basic Components
● State – We use a rounded rectangle to represent a state.

● Join – We use the join notation when two or more states concurrently
converge into one on the occurrence of an event or events.
 8. STATECHART DIAGRAM- Basic Components
● Fork – We use the fork notation to represent a state splitting into two or
more concurrent states.

● Self transition – We use self transitions to represent when the state of the
object does not change upon the occurrence of an event.
 8. STATECHART DIAGRAM- Basic Components
● Final state – We use a filled circle within a circle notation to represent
the final state in a state machine diagram.

● Choice state - The choice state is represented as a diamond with one

arrow arriving and multiple arrows leaving the state. It shows a
decision point in the system
 9. ACTIVITY DIAGRAM

● Activity Diagram is basically a flowchart to represent the flow

from one activity to another activity.
● The activity can be described as an operation of the system.
● The basic purpose of activity diagrams is to capture the
dynamic behavior of the system.
● An activity diagram is used by developers to understand the
flow of programs on a high level.
 9. ACTIVITY DIAGRAM - Notations
Decision node and Branching – When we need to make a decision
before deciding the flow of control, we use the decision node.
 9. ACTIVITY DIAGRAM - Notations
Merge Event – It arise when Time Event- This refers to an event
activities which are not being that stops the flow for a time; an
executed concurrently have to be hourglass depicts it.
merged.
 9. ACTIVITY DIAGRAM - Notations
Fork Node - Split behavior into a set Join Node- Bring back together a set
of parallel or concurrent flows of of parallel or concurrent flows of
activities (or actions). activities (or actions).
9. ACTIVITY DIAGRAM – steps to draw
9. ACTIVITY DIAGRAM – Example
9. ACTIVITY DIAGRAM – Example
 9. ACTIVITY DIAGRAM – Uses
● Dynamic modelling of the system or a process.
● Illustrate the various steps involved in a UML.
● Model software elements like methods, operations and
functions.
● We can use Activity diagrams to depict concurrent
activities easily.
● Show the constraints, conditions and logic behind
algorithms.
REQUIREMENT MODEL
 REQUIREMENT MODEL- Objectives

1. to describe what the customer requires,

2. to establish a basis for the creation of a software design,
and
3. to define a set of requirements that can be validated once
the software is built
 REQUIREMENT MODEL
1. Scenario based element
○ This type of element represents the system user point of view.
○ Scenario based elements are use case diagram, user stories.
2. Class based elements
○ The object of this type of element manipulated by the system.
○ It defines the object,attributes and relationship.
○ The collaboration is occurring between the classes.
○ Class based elements are the class diagram, collaboration diagram.
3. Behavioral elements
○ Behavioral elements represent state of the system and how it is
changed by the external events.
○ The behavioral elements are sequenced diagram, state diagram.