||JAI SRI GURUDEV||

Sri AdichunchanagiriShikshana Trust ®

SJB INSTITUTE OF TECHNOLOGY

( A Constituent Institution of BGS & SJBIT Group of Institution & Hospitals)

Department of Computer Science & Engineering

Study Material- Notes: Module-2

Course Name: SE &PM

Course Code: 23CSI-502
Semester : 5th B & C

By

Faculty Name: Dr. Shantha Kumar H C

Asso. Professor
Department of CSE

Aca. Year: Odd Semester / 2025-2026

Module-2 Dr. Shantha Kumar H C Dept of CSE

TOPIC: UNDERSTANDING REQUIREMENTS

Requirement is a necessary task before beginning of any work. Similarly in

software development collecting requirement is the fundamental and primary stage
which gives clear idea about what is to be developed.
In general requirements are descriptions of the services that a software system
must provide and the constraints under which it must operate.
Software requirements can be broadly seen in 2 categories:

 Functional Requirements

 Nonfunctional Requirements

Functional requirements describe that, what the software system must do. They
specify the functionalities or features that user expects form the system.
Nonfunctional requirements describe how the software system should performs a
task rather than what it should do. They define the quality attributes, performance
criteria, and constraints.
Example: Efficiency, Accuracy, Usability, Reliability, Safety, Security, Flexibility,
Portability, Adaptability, Maintainability etc…

Requirement Engineering :
Requirement engineering is the process to gather the software which are essential,
from customer, analyze and document them in a systematic approach.
The goal of requirement engineering is to develop and maintain sophisticated and
descriptive SRS (Software Requirements Specification) document. Software
engineers, Analysts, Managers, Customers and End users are group of persons
responsible for this process.
In general requirement engineering process varies with respect to domain,
application, organization and people involved. Similar software process model
here also there are numerous activities to be considered, but most common or
important stages in requirement engineering process are:

2
Module-2 Dr. Shantha Kumar H C Dept of CSE

 Feasibility study
 Requirement Elicitation
 Requirement Specification
 Requirement Validation
 Requirement management

Feasibility study: The output of this stage is to develop a suitable study report that
should contain adequate comments and recommendations for management about
whether or not the project should be undertaken.
This study is focused on complete analysis on whether the software product can be
practically developed in terms of implementation, contribution of project to
organization, cost, schedule and other constraints.
Overall, it explores Technical, Operational and Economic constraints related to the
system to be developed.

Feasibility study report should focus on getting answer to the following:

• Whether development process is worth carrying, with respect to customer

demand, market need and organization.

• How the system is intended to support consistently with respect to the

identified functionalities.

• Can system be implemented within given time and cost.

• Can it be integrated with other systems, which are already in place.

Requirement Elicitation: Once the requirements are collected from various

stakeholders, next process is requirement elicitation, this includes the practice of
clear and comprehensive understanding of the customer’s needs and requirements,
it is a form of researching refinement of the collected requirements against the
proposed model or particular application domain in achieving good performance.

3
Module-2 Dr. Shantha Kumar H C Dept of CSE

Customer may express their views with their simple or limited knowledge, but it is
the responsibility of requirement engineers with vast experience in the same
domain, to understand whether they are up to the mark against defined constraints.
The output of the requirements elicitation process is a set of clear, concise, and
well-defined requirements that serve as the basis for the design and development
of the software system.

Requirement Specification: Requirement specification takes different meaning

with different people. It is a document created by system analyst. It also describes
the functionality of the product needs to fulfill stakeholders’ expectations.
As the name suggests, is a complete 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.
• It can be a formal graphical model.
• It can be a formal mathematical model.
• It can include usage scenarios also.

“A written document combining natural language descriptions and graphical

models may the best approach.

Requirement Validation: Requirement validation is the technical review that

validates the gathered requirements, analyzed and specified in the prior stages.

Requirement validation ensures that all software requirements which are sated are
unambiguous, consistent, verifiable and achievable. “So that work product is
confirmed to the standards”.
Out come of requirements validation is to ensure that whether the right
requirements have been specified with all possibilities. It also list errors and agreed
actions of detected problems.

4
Module-2 Dr. Shantha Kumar H C Dept of CSE

Requirement management: Requirements of any system looks for change over

the time. Requirements management is a set of activities that help the project team
to identify, control, and track requirements and changes to requirements at any
time as the project proceeds.
Requirement management focuses on delivering the expectations of the
stakeholders.

Developing Use Cases : use cases in software engineering is part of

requirements analysis and helps to describe how a system will be used by its
actors. Only static behavior is not sufficient to model a system, instead the
dynamic behavior is more important for better understanding.

In UML (Unified Modeling Language) there are many diagrams available to model
dynamic nature and use case diagram is one of them.
(Use case diagram, Sequence diagram, Activity diagram, Class diagram,
Component diagram and etc.)
Use cases are the fundamental units of modeling language, in which functionalities
are distinctly presented. They describe how user interact with system to achieve
the desired goal.
5
Module-2 Dr. Shantha Kumar H C Dept of CSE

Major elements in use cases:

 Actor → person, organization, or external entity that interacts with the

system.
 System → the software or product being developed.
 Use cases → a sequence of steps that describe how the system provides
value to the actor.

Steps for developing use cases:

 Identify Actors: Determine who will use the system.

 Examples: Customer, Admin, Bank System, Delivery Service.
 Identify Goals / Use Cases: Define what each actor wants to achieve with
the system.
 Examples: Login, debit money, withdraw, check balance.
 Draw / Write Use Cases: Draw use case diagram and write use description.

A well defined use case diagram focuses on the following factors:

 Functional requirements can be captured clearly.

 Easy to understand for both technical and non-technical stakeholders.
 Serve as a bridge between requirements and design.
 Help in creating test cases at later stage.

6
Module-2 Dr. Shantha Kumar H C Dept of CSE

Typical use case diagram for ATM can be seen with following dynamic
sequences. Here we notice 2 actors one is primary actor (Customer) and the other
is secondary actor (bank), varuious activites related to ATM are establishing
connection, transactions. Transactons inturn consists of set of other activities in
sequence.

7
Module-2 Dr. Shantha Kumar H C Dept of CSE

Example-2:

From the above 2 examples, it is clear that dynamic behavior of the system can be
clearly explained with use case scenario representing each action in sequence.
Hence UML diagrams are serves best in explaining dynamic behavior of the
system.

Building Requirement Model:

A requirement model is a set of diagrams, documents, and structured descriptions
that represent the necessary requisites of a system in a clear and easy
understandable way. It is created by software engineer / software analyst.
While building a model with description of the required information (both
functional and nonfunctional), the model changes dynamically as we learn more
about the system to be built. So that stake holders understand more about what
they really require.
As the requirement model evolves certain elements may become relatively stable
and other elements of the model may be more volatile.

8
Module-2 Dr. Shantha Kumar H C Dept of CSE

A requirement model consists of several stages, that each examines the same
problem from a different perspective. These stages include: scenario-based
modeling, data modeling, flow-oriented modeling, class-based modeling, and
behavioral modeling.
The common types that make up a requirement model are use case, class diagram,
state diagram, activity diagram, flow diagram, and sequence diagram.
Following are the elements of requirement model, based on the common type:
 Scenario based elements
 Class based elements
 Behavioral elements
 Flow oriented elements

Scenario-based elements: : In this type system is described from user’s point of

view. For example, basic use cases and their corresponding use-case diagrams.
Typical flow diagram including scenario-based elements is as shown in the
following figure with three levels.

9
Module-2 Dr. Shantha Kumar H C Dept of CSE

Block Diagram showing scenario-based elements

In Level-1 meetings are conducted with stake holder to collect requirements of the
proposed system, and these requirements are validated with respect to various
constraints. The clear and unambiguous requirements undergo prioritization
process in Level-2. Prioritization is the process of determining the different
requirements to be best used with limited resources. Result of level-2 will give
(QFD) Quality Function Deployment.
QFD focuses on translating customer requirements into design specifications for
software engineering projects. Later stage use cases are developed for these QFD’s
in Level-3, using actors and actions.

Class based elements: In software engineering class is a visual representation of a

system structure. Class diagram consists of things that have similar attributes and
common behaviors i.e., objects and their related operations. For example, a UML
case diagram can be used to depict a sensor class for the Safe Home Security
function. (Class Diagram) is shown below.

Class Name

Attributes

Operations

General structure of Class SHS model showing Class based elements

10
Module-2 Dr. Shantha Kumar H C Dept of CSE

In the above diagram of Safe Home Security system model, class-based elements
are showed with class diagram for Sensor class. Name, Type, Location, Area are
the attributes of the sensor, and Identify( ), Enable( ), Disable( ), Reconfigure() are
the operations, represented with member functions, showing each dynamic actions
of the system in step by step.

Behavioral elements: Effect of behavior of a computer-based system can have

profound effect on the design and implementation approach that is that is chosen
and applied. Modeling of these elements depicts behavior (actions and events) that
cause system to change its state from one state to other state.
Behavioral elements generally include response to the events or actions like what
after logging in to ATM System, its status, enter card, wait for action etc. shown in
the following figure.

State Name

State variables

State activities

UML State Diagram showing Behavioral activities

11
Module-2 Dr. Shantha Kumar H C Dept of CSE

In the above diagram Reading Commands indicate the state name, system status
and display message indicate state variables, and user input panel, read user input
indicate state activities.
Following is the UML behavior model for Hotel Room Booking:

Flow Oriented Elements: Following diagram lists attributes of Safe Home

Security system represented in the form of flow-oriented elements (DFD) Data
Flow Diagram.

The Safe Home Security function enables the house owner with the security
system when it is installed, monitors all sensors connected to the security system
and interacts with the owner through internet or a control panel.

12
Module-2 Dr. Shantha Kumar H C Dept of CSE

Control panel can be programmed with user id and password, along with set of
numbers indicating the required events/actions from 0-9.

In case of panic situations hose owner receives security information via an

interface (Control panel or PC or Mobile), in the form of prompting messages
based on that necessary action can be taken.

Negotiating Requirements:

Since requirements come from multiple sources (customers, end-users, managers,

developers, regulatory bodies), conflicts are very common. Requirement
negotiation is the process of resolving conflicts among stakeholders when they
have different needs, priorities, or expectations for the system.

Process of inception, elicitation, and elaboration tasks in an ideal requirement

engineering stage, determine customer requirements in sufficient depth to proceed
to subsequent stages.
The main goal of negotiation is to develop a project plan that meets stake holders
needs reflecting to real world constraints like time, budget, people and etc.
Successful negotiations aim for a “win-win” outcome. That is, stakeholders benefit
from a system or product that meets the majority of their needs, while you benefit
from working within realistic and reasonable budgets and schedules.
Steps in Requirement Negotiation:
 Identify Conflicts
 Prioritize those
 Discuss Trade-offs
 Explore Alternatives
 Reach Agreement with formal approve

13
Module-2 Dr. Shantha Kumar H C Dept of CSE

“ Negotiation prioritizes most valuables by compromising with the less critical ”

Following are the activities to be carried out by communication with the stake
holders during negotiation process:

Validating Requirements:

Validating requirements in software engineering is the process of checking

whether the “documented requirements” truly reflect the needs and expectations
of the stakeholders.

The process of checking the requirements specified for development.,the aspect of

the requirements model is checked for consistency, omissions, and ambiguity as it
is developed. The model’s requirements are prioritized by stakeholders and
bundled into requirements packages that will be implemented as software
increments.

Validating requirements helps to ensure that the specifications accurately reflect

the needs and expectations of stakeholders.

Following are the general questions to be addressed:

14
Module-2 Dr. Shantha Kumar H C Dept of CSE

• Is each requirement aligned with the overall system/product objectives?

• Were all requirements expressed at the appropriate level of abstraction?
• Is the requirement truly necessary, or is it an optional feature that may or
may not be critical to the system’s goal?
• Is each requirement well defined and unambiguous?
• Is there a source noted for each requirement?
• Are there any requirements that conflict with others?
• Is each requirement attainable in the technical environment in which the
system or product will be housed?
• Is each requirement, once implemented, can be testable?
• Do the requirements models accurately represent the information,
functionality, and behavior of the system to be built?
Above are the questions should be asked and answered to ensure that the
requirement mode is an accurate reflection of stakeholder needs and it provides a
solid foundation for product design.

Requirement Analysis:
Requirements analysis is a critical part in software development. The purpose of
requirements analysis is to be sure about all product requirements needed for the
proposed system.
Requirement Analysis is the process of understanding, gathering, and analyzing
with respect to the needs and expectations of stakeholders for optimal results.
Requirement analysis should focus on following important factors:
 Document
 Unambiguous
 Complete
 Consistent
 Correct
 Feasible
 Verifiable
15
Module-2 Dr. Shantha Kumar H C Dept of CSE

All the above factors finally focus on validating that they represent the intent of
the desired goal.

Requirements analysis results in the specification of software’s operational

characteristics, indicates software interface with other system elements and
establishes constraints that software must meet.
Requirements analysis allows us to elaborate on basic requirements established
during the inception, elicitation and negotiation tasks that are part of requirement
engineering process.

The requirement analysis action results in one of the following types of models
discussed earlier:
 Scenario-based models
 Class-oriented models
 Flow-oriented models
 Behavioral models

Scenario-based models of requirements are used to describe detailed story or

usage that depicts how a user (actor) interacts with the system to achieve a goal.
Class-oriented models represent object-oriented classes (attributes and operations)
and the manner in which classes collaborate to achieve system requirements.
Flow-oriented models represent the functional elements of the system and how
they transform data as it moves through the system.
Behavioral models depict how the software behaves as a consequence of external
“events”. These models provide a software designer with information that can be
translated to architectures, interfaces and component level designs.

Elements of requirements analysis approach can be best viewed with the

following figure.

The specific content of each element may vary by project, and the software team.
16
Module-2 Dr. Shantha Kumar H C Dept of CSE

Figure: Elements of requirements analysis

The requirements model must achieve three primary objectives:

 To describe what the customer requires
 To establish a basis for the creation of a software design
 To define a set of requirements that can be validated

Once the software is built. The analysis model bridges the gap between a system-
level description that describes overall system or business functionalities and
design model, as it is achieved by applying software, hardware, data, human, and
other system elements and a software design.
17
Module-2 Dr. Shantha Kumar H C Dept of CSE

UML Models that supplement the Use Case:

In some situations, where a text-based model like a use case may not convey
information clearly, UML graphical models, such as activity diagrams, offer a
visual representation of interaction flow within a scenario. Activity diagrams are
similar to flowcharts, depict system functions, flow of interaction, decision
points, and parallel activities, providing additional detail not explicitly stated in
the use case.
Developing an Activity Diagram (Safe Home Security System):

18
Module-2: SE &PM Dr. Shantha Kumar H C Dept of CSE

Swimlane Diagrams:

Swimlane diagrams the variations of activity diagrams, allocate responsibilities

to actors vertically. In the context of a specific use case, activities associated
with different analysis classes or actors are depicted within respective
swimlanes. This visual representation aids in understanding the flow of
activities and responsibilities among different entities involved in the use case.

Figure: Swimlane diagram for Access camera surveillance via the Internet.
In above Figure, activities associated with analysis classes are placed within
respective swimlanes, such as the Interface class , managing prompts for re-
entry and another view. However, arrows indicate homeowner actions within
19
Module-2: SE &PM Dr. Shantha Kumar H C Dept of CSE

their swimlane, illustrating the flow of interaction. Use cases, along with
activity and swimlane diagrams, focus on procedural aspects, depicting how
actors invoke specific functions to fulfil system requirements.
from the discussion it is clear that the dynamic behaviors of any software
process model which are not showed explicitly using use case diagram can be
better depicted using activity diagram or swimlane diagram which serves as
supplement to UML use cases.

Data modeling Concepts:

What is Data ?
In general data is collection of facts and figures
ex. 69 , 8009 , Red, Yellow, Oval

Structured Data?
Which is organized into standard format, fits neatly into data tables so that can be
used for effective analysis.
ex. Numbers and short text.
Student database: Roll No, Name, Course, Marks.

Unstructured Data?
Which are not organized in standard format, does not fits into data tables so that
difficult for storing and effective analysis.
ex. Large PDF doc, email, and audio video,

Semi structured Data?

Lies between above two, Is an organized collection of large data (structured)
typically stored in computer memory, is not in fixed rows and columns, but still
has some structure or labels, controlled by DBMS. Ex. JSON, XML
20
Module-2: SE &PM Dr. Shantha Kumar H C Dept of CSE

Data Modeling is the process of defining and organizing data elements and their
relationships so that they can be effectively used by a software system.
It helps to transform real-world data requirements into a structured framework
that can be implemented in databases and software applications

Data modeling in software engineering is about creating a structured

representation of data to ensure software systems are accurate, consistent,
efficient, and maintainable
Data modeling is the process of diagramming data flows within the system
when creating a new or alternate database structure. The designer starts with a
diagram of how data will flow into and out of the database.
• Data is important requirement in any design process.
• We collect data from consumers / customers and later we transform them
to system designer.
• Collected data many not be in structured form, not suitable for
programmatic operations , and may not follow syntactic and semantic
aspect.
“Data modeling is the answer for the above points”

Where data is stored in appropriate format in the data base, and initiates data
flow into or out of system efficiently as and when it is required .

For software requirements involving database creation, extension, or

interfacing, a data model may be incorporated into overall requirements
modelling. This model, typically represented by an entity-relationship diagram
(ERD), defines data objects, their relationships, and relevant information for
processing within the system. The ERD encompasses all data objects entered,
stored, transformed, and produced by the application.

21
Module-2: SE &PM Dr. Shantha Kumar H C Dept of CSE

Data Objects: A data object is a structure for describing a data entity representing
its composite information with set of related attributes, such as dimensions
incorporating height, width, and depth. For instance, a person or a car can be seen
as a data object with attributes defining them, and can be represented as tables
with attributes (columns) as headings and specific instances in the body.

Following table shows simple example of data object CUSTOMER with multiple
attributes, Name, Phone Number, E-mail and Area.
First Name

Last Name

Phone Number

E-mail

Area

Following table shows simple example of data object CAR with its multiple
attributes which are belonging to the same object like Make, Model, Color,
body type, and Id etc.

Make Model Color Body type ID#

BMW ES200 Blue SEDAN XZ789

FORD Endeavor White SUV Q12A4
TATA Harrier Black Sports AT789
MAHINDRA XUV700 White SUV XT456
MARUTHI Swift Red Hatch Back AB123

22
Module-2: SE &PM Dr. Shantha Kumar H C Dept of CSE

 Data attributes of an object represent characteristics or properties that

define an object or belong to one object.
 One or more of the attributes must be defined as an identifier that is the
attribute becomes a “ KEY ”, which is used to find and instance of the data
object.
 Referring to the car object ID Number might be a reasonable identifier.
 Set of attributes for a given data object is determined through an
understanding of the problem context.
 Attributes defined for Car object might serve well for an application that
would be used by a motor vehicle showroom, but these attributes would be
useless for an automobile company that needs manufacturing control
software.

Relationships: Relationship refers to how different objects interact each other or

connected with each other within a software program. Objects are instances of the
classes and classes define the structure and behaviors of the objects. The way
objects relate to each other is a fundamental concept and plays an important role in
designing and modeling software systems.
For example, we can take two objects CAR and PERSON, where a connection can
be established between Car and Person which are related each other. Before
establishing connection, we should understand the role of Person and Car with in
the context of the software to be built.

PERSON CAR

a) Basic Connection between Person and a Car

Owns CAR
PERSON
Insured
b) Relationship between data objects Person and Car

23
Module-2: SE &PM Dr. Shantha Kumar H C Dept of CSE

In the previous diagram figure (a) represents just a basic connection between two
objects, figure (b) illustrates relationship that a person owns a car, and a person is
insured to drive the car with two pair of arrow lines, hence reducing the ambiguity
of misinterpretation.

Class Based Modelling: Class based modelling represents the objects that the
system will manipulate the operations, that will be applied to the objects to affect
the manipulation, relationships between the objects and collaborations that occur
between the classes that are defined.
Elements of class-based modelling includes classes and objects, attributes
operations, class responsibilities, collaborations and packages.
Following are the informal guidelines that will assist in their identification and
representation.
1. Identifying Analysis Classes: Identifying analysis classes involves examining
usage scenarios and performing a "grammatical parse" on use cases to underline
and record nouns. These nouns are then categorized as part of the solution space if
they're required to implement a solution, or part of the problem space if they're
necessary only to describe a solution. This process helps in understanding the
objects and classes relevant to the software application, which can be challenging
compared to identifying physical objects in a room.
Analysis classes manifest themselves in one of the following ways:
 External entities (other systems, devices, people) that produce or consume
information to be used by a computer-based system.
 Things (e.g., reports, displays, letters, signals) that are part of the
information domain for the problem.
 Occurrences or events (e.g., a property transfer or the completion of a
series of robot movements) that occur within the context of system
operation.
 Roles (e.g., manager, engineer, salesperson) played by people who
24
Module-2: SE &PM Dr. Shantha Kumar H C Dept of CSE

interact with the system

 Organizational units (e.g., division, group, team) that are relevant to an
application.
 Places (e.g., manufacturing floor or loading dock) that establish the
context of the problem and the overall function of the system.
 Structures (e.g., sensors, four-wheeled vehicles, or computers) that define
a class of objects or related classes of objects.

2. Specifying Attributes: Attributes, integral to a class within the problem

context, provide a detailed definition of the class. They vary depending on the
specific application; for instance, attributes for a class like "Player" differ
between a baseball statistics tracking system and a professional baseball pension
system. To establish meaningful attributes for an analysis class, each use case
should be examined to determine what elements are relevant. For example, in the
Safe Home System.
Class, attributes encompass sensor information, alarm response details,
activation/deactivation data, and identification information. Sensor objects,
although part of the Safe Home System, are not listed as attributes because they
are already defined as a separate class and multiple instances may be associated
with the System class.

Operations define object behavior and typically manipulate data, perform

computations, inquire about object state, or monitor events. Derived from
studying processing narratives or use cases, operations are identified by isolating
verbs, such as "assign" for the Sensor class or "program" for the System class in
the Safe Home Security system. Operations may involve suboperations for
detailed configuration tasks, like specifying phone numbers or setting system
25
Module-2: SE &PM Dr. Shantha Kumar H C Dept of CSE

characteristics.

3. Associations and Dependencies: Associations in UML represent relationships between

analysis classes, such as the connections between Floor Plan, Camera, and Wall in a
surveillance system. These associations can be further defined with multiplicity constraints to
indicate the number of objects involved. Dependencies, often depicted with stereotypes,
represent client-server relationships where one class relies on another. For instance, a Camera
object providing video to a Display Window object establishes a dependency association,
crucial for system functionality. Stereotypes like <<access>> can denote special conditions,
such as requiring a password for accessing camera output, ensuring secure system operations.

-------------------------------- GOOD LUCK ----------------------------------------.

26