UNIT-II

REQUIREMENTS
ANALYSIS
1
Requirements Engineering Process - Requirement
Elicitation - Developing Use Cases - Building the
Analysis Model – Negotiation - Validation.

Requirement Analysis – Approaches - Data

Modelling Concepts - OO Analysis - Scenario-
based Modelling - Flow Oriented Modelling -
Class-based Modelling - Behavioural Modelling
2
Requirements Engineering Process
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.
...
3
Requirements Engineering Process…

… 4
Requirements Engineering Process…
[Link] Study
Technical Feasibility
Operational Feasibility
Economic Feasibility
Legal Feasibility
Schedule Feasibility

5
 Feasibility Study
Technical Feasibility
•Assess availability of hardware, software, and technology
•Evaluate development team's technical skills
•Determine if current technology can be reused
•Check ease of maintenance and upgrades
•Analyze system compatibility and scalability

6
Operational Feasibility

•Determines how well proposed solution meets user

needs
•Analyzes ease of operation post-deployment
•Evaluates product usability and maintainability
•Checks if the suggested solution is acceptable to
stakeholders
•Identifies operational risks and mitigation

7
Economic Feasibility

•Detailed cost-benefit analysis of the project

•Includes development, operational, and
maintenance costs
•Estimates potential financial benefits or ROI
•Determines if the project is financially viable
•Helps justify the investment

8
Legal Feasibility

•Ensures compliance with relevant laws and

regulations
•Reviews contracts and existing legal obligations
•Evaluates impact of licenses, copyrights, and
patents
•Identifies legal risks and liabilities
•Ensures data protection and privacy standards
are met
9
Schedule Feasibility
•Evaluates if the project timeline is realistic
•Identifies key milestones and deadlines
•Assesses availability of required resources on time
•Considers external and internal time constraints
•Ensures timely delivery and planning success

10
Requirements Elicitation

Requirements elicitation is the process of gathering

information about the needs and expectations of
stakeholders for a software system.

This is the first step in the requirements engineering

process and it is critical to the success of the software
development project. The goal of this step is to
understand the problem that the software system is
intended to solve and the needs and expectations of the
stakeholders who will use the system. 11
12
1. Interviews
•One-on-one conversations with stakeholders
•Collects detailed and specific requirements
•Allows follow-up questions for clarification
2. Surveys
•Structured questionnaires distributed to users
•Efficient for collecting data from a large group
•Useful for both quantitative and qualitative inputs
3. Focus Groups
•Small group discussions with stakeholders
•Encourages idea sharing and diverse viewpoints
•Helps identify common needs and conflicts 13
4. Observation
•Directly observe users in their work environment
•Understand real workflows and hidden needs
•Identifies gaps between expected and actual
practices
5. Prototyping
•Build a working model or mock-up of the system
•Gather feedback on features and interface
•Helps validate and refine requirements early

14
15
Requirements Specification
Requirements specification is the process of
documenting the requirements identified in the analysis
step in a clear, consistent, and unambiguous manner.
This step also involves prioritizing and grouping
the requirements into manageable chunks.
The goal of this step is to create a clear and
comprehensive document that describes the
requirements for the software system. This document
should be understandable by both the development
team and the stakeholders.
16
Functional Requirements
•Define what the system should do
•Include features like input validation, data processing, storage,
and UI behavior
🔹 Non-Functional Requirements
•Define how well the system should perform
•Include performance, usability, reliability, security, etc.
🔹 Constraints
•Limitations or restrictions on development
•Examples: specific technologies, legal regulations, budget limits
🔹 Acceptance Criteria
•Conditions to be met for system acceptance
•Define when a feature or system is considered “complete” and
17
ready for release
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 18
Requirements Verification & Validation (V&V)
🔹 Definition:
•V&V ensures software requirements are complete,
accurate, consistent, and meet stakeholder needs.
•Aims for quality, timeliness, and budget adherence.
🔹 Verification – “Are we building the product right?”
•Reviews requirements for clarity, correctness,
consistency
•Ensures requirements are testable and free of errors
•Techniques: Reviews, inspections, walkthroughs

19
🔹 Validation – “Are we building the right
product?”
•Checks if requirements match stakeholder
expectations
•Ensures the software will fulfill real-world needs
•Techniques: Prototypes, simulations, stakeholder
testing

20
Requirements Management
🔹 Definition:
•Ongoing process of analyzing, documenting, tracking,
prioritizing, and managing requirements
•Ensures requirements remain valid, relevant, and
aligned with stakeholder needs
🔹 Key Objectives:
•Deliver a system that meets stakeholder expectations
•Develop software on time, within budget, and with
desired quality
•Manage requirement changes systematically
21
🔹 Core Activities:
•Tracking & Change Control: Monitor and manage requirement
changes
•Version Control: Maintain history of requirement versions
•Traceability: Link requirements to design, code, test, and
validation
•Communication: Ensure clear communication across teams
•Monitoring & Reporting: Track status and progress of
requirement implementation
🔹 Importance:
•Prevents scope creep
•Aligns requirements with project goals
•Supports adaptability and continuous improvement 22
Stages in Requirements Engineering Process
1. Elicitation
•Gather requirements from stakeholders (users,
customers, domain experts)
•Identify system features, functions, and constraints
2. Analysis
•Examine requirements for feasibility, consistency,
and completeness
•Resolve conflicts and ambiguities
3. Specification
•Document requirements clearly and unambiguously
•Create Software Requirements Specification (SRS) 23
4. Validation
•Review requirements to ensure they meet stakeholder
needs
•Check for accuracy, completeness, and correctness
5. Management
•Track, update, and control requirements throughout
development
•Ensure proper communication and version control

24
Developing Use Cases

Use Case 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 include
three major things - Actor, use cases, and use
case diagram. 25
Developing Use Cases
[Link]: It is the external agent that lies outside
the system but interacts with it in some way. An
actor may be a person, machine, etc. It is
represented as a stick figure. Actors can be
primary actors or secondary actors.
[Link] actors: It requires assistance from
the system to achieve a goal.
[Link] actor: It is an actor from which
the system needs assistance. 26
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.

27
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. 28
Use cases are used to answer following questions:
• Who is the primary actor, the secondary actor(s)?
• What are the actor’s goals?
• What preconditions should exist before the story
begins?
• What main tasks or functions are performed by the
actor?
• What exceptions might be considered as the story is
described?
• What variations in the actor’s interaction are
possible?
29
• What system information will the actor acquire,
produce, or change?
• Will the actor have to inform the system about
changes in the external environment?
• What information does the actor desire from the
system?
• Does the actor wish to be informed about
unexpected changes?

30
31
Building the Analysis Model
 Analysis Model is a technical representation of the
system.
 It acts as a link between the system description and
the design model.
 In Analysis Modelling, information, behavior, and
functions of the system are defined and translated
into the architecture, component, and interface level
design in the design modeling.

32
Objectives of Analysis
Modelling
•Understanding Needs: Understanding and
extraction of user needs for the software
system.
•Communication: Facilitate communication
between users, clients, developers, and
testers, among other stakeholders.
•Clarifying Ambiguities: Assist in resolving
requirements disputes and providing 33
Objectives of Analysis
•Finding the Data Requirements: Assists in
Modelling
determining the relationships, entities, and
qualities of the data that the system needs.
•Defining Behavior: Aids in the definition of the
system's dynamic behavior, including workflows,
processes, and inter-component interactions.
•System Boundary Identification: It is made
easier by analysis modelling, which helps in
defining the parameters of the software system
and its interactions with users, other systems, 34
Elements of Analysis
Modelling

35
Data Dictionary
•Central repository of all data used/produced
by the software
•Describes data objects, attributes,
relationships, and formats
•Crucial for analysis modeling and requirement
specification
•Supports consistent data usage across the
software
•Assists in communication between
stakeholders 36
Data Object Description
•Detailed documentation of each data object
•Includes attributes, type, format, and relationships
•Supports ERD and Data Dictionary
•Helps maintain data consistency across models
•Crucial for complete understanding of the data
domain

37
Entity Relationship Diagram (ERD)
•Graphical representation of entities and their
relationships
•Used for logical data modeling
•Defines data objects and their attributes
•Helps design databases and object models
•Provides foundation for data structure design

38
Process Specification (PSPEC)
•Describes internal logic of DFD processes
•Specifies input, processing steps (algorithm), and
output
•Includes performance constraints and layout rules
•Provides a blueprint for coding each process
•Essential for transforming DFDs into design-level
detail

39
Data Flow Diagram (DFD)
•Shows the flow of data between processes, data
stores, and external entities
•Visualizes transformation of input to output
•Used for functional modeling and analysis
•Helps in understanding system processes
•Supports development of functional and data
models simultaneously

40
Control Specification (CSPEC)
•Describes control logic and event-response behavior
•Defines which events trigger specific processes
•Represents control flow using decision tables or
diagrams
•Complements process specification (PSPEC)
•Helps in modeling system reactions to events

41
State Transition Diagram
•Represents different states of the system
•Shows transitions triggered by events
•Models system behavior over time
•Useful for real-time and event-driven systems
•Describes actions taken during state transitions

42
Key Principles of Analysis Modelling
•Abstraction: Focus on essential elements, ignore
unnecessary details
•Modularity: Break system into manageable
components
•Consistency: Maintain uniformity across all artifacts
•Traceability: Link requirements to design and
implementation
•Precision: Use clear and exact representations
•Separation of Concerns: Model different aspects
(e.g., behavior, data) separately 43
Negotiation

In software engineering, negotiation refers to

the process of reaching agreements among
stakeholders about software requirements,
design decisions, timelines, resources, or any
other aspects of a project. It is a collaborative
effort to align differing goals, priorities, and
expectations to ensure the project's success.

44
Requirement Analysis-Approaches
Three major approaches to
requirement analysis:
Structured Analysis,
Object-Oriented Analysis,
Agile Analysis.

45
Structured Analysis
Creation of four models: data, functional, information-
flow and Behavioral.
Data model: Entity Relationship Diagram (ERD)
•Shows Data objects, their attributes, and relationships between
these objects
Functional and Information-Flow models: Data Flow
Diagram (DFD)
•How data objects are transformed as they flow in the system
•The functions that perform the transformation
Behavioral model: State Transition Diagram (STD)
•How system changes state in response to events 46
Data model: Entity Relationship Diagram (ERD)
 Entity Relationship Diagram (ERD) is used to model data
objects and their relationships.
 The purpose of data modeling is to specify data
objects consumed and produced by the system as
well as the relationships between these objects.

47
Data model: Entity Relationship Diagram (ERD)

•Represents meaningful information within a system

•Acts as a real-world entity in data modeling
•Example:
•Customer, Ticket in a Ticket Reservation System

48
49
 Attributes of a Data Object
•Data objects consist of attributes (properties)
•Attributes define the object’s characteristics
•Example (Customer):
•Age,Gender
• Total Miles
Behavior vs. Data
•Data Object: Contains only data (attributes)
•Object (OOP): Contains data + operations
(methods)
•📌 Data objects do not define operations!
•🔑 Primary distinction from Object-Oriented concepts 50
Relationships Between Data Objects
•Data objects are interconnected
•Represent system interactions
•Example:
•Customer purchases a Ticket
Summary
Data object = Entity + Attributes
No operations or methods
Participate in relationships with other data objects
Crucial for system understanding and modeling

51
Information Flow and Functional Modeling

52
DFD serves two purposes:
•Shows how data objects flow through the system
(Information-flow model)
•Shows transformation applied on these objects by
various functions (Functional model)

53
54
Behavioral Modeling
Behavioral models show how systems change state in
response to events.
State Transition Diagram (STD) models system’s
behavior by showing:
•the System states
•State changes in response to events
•Action to be taken as result of a specific event

55
Consider the Ticket Reservation system
Customers can initiate a reservation process and
continue it later
A Notification sub-system monitors the number of
seats left
Notification sub-system changes its state to:
plenty, running out, or filled
Plenty, running out, and filled are states that
indicate system behavior

56
57
A State Transition Diagram (STD) moves how the
system moves from one of these states to the other.
Labels up part indicates “events that cause State
change” bottom part “System response in change”.

Control Flow Diagram (CFD) shows control flow

instead of data flow (DFD)
•CFDs show how events (not data) flow in/out
processes
•Events entering causes activation/deactivation of
processes
58
Object-Oriented Analysis
•Identify system requirements
•Recognize classes and relationships
•Techniques used in Object-Oriented Analysis
(OOA):
• Object Modeling
• Dynamic Modeling
• Functional Modeling

59
Object Modeling
•Focus: Static structure of the system
•Steps:
• Identify objects and group into classes
• Identify relationships among classes
• Create user object model diagram
• Define attributes and operations
• Review glossary

60
Dynamic Modeling
•Focus: Behavior over time and response to events
•Describes:
• State changes of objects
• Internal & external events
•Steps:
• Identify states and events
• Construct state transition diagrams
• Express states using object attributes
• Validate diagrams
61
Functional Modeling
•Focus: Processes and data transformations
•Represents internal functionality of objects
•Steps:
• Identify inputs and outputs
• Build data flow diagrams (DFDs)
• Define functions and constraints
• Specify optimization criteria

62
OOA – Advantages & Disadvantages
Advantages:
•Focus on data (not procedures)
•Supports encapsulation and data hiding
•Good modularity and complexity management
•Easy to scale from small to large systems
Disadvantages:
•Restricted functionality in procedural systems
•Hard to find optimal object design
•Poor representation of inter-object communication
•All interfaces not shown in one diagram
63