Module 2 : Software Requirements Analysis and Modeling

Requirement Engineering?

Before we start to develop our software, it becomes quite essential for us to understand and document the
exact requirement of the customer.

Requirement Engineering is a systematic process of finding out, analyzing, documenting, and

managing the requirements for a software system.

Experienced members of the development team carry out this job. They are called as system analysts.

 The analyst starts requirements gathering and analysis activity by collecting all information from the
customer which could be used to develop the requirements of the system.
 He then analyzes the collected information to obtain a clear and thorough understanding of the
product to be developed, with a view to remove all ambiguities and inconsistencies from the initial
customer perception of the problem.
The following basic questions pertaining to the project should be clearly understood by the analyst in order to
obtain a good grasp of the problem:

• What is the problem?

• Why is it important to solve the problem?
• What are the possible solutions to the problem?
• What exactly are the data input to the system and what exactly are the data output by the system?
• What are the likely complexities that might arise while solving the problem?
• If there are external software or hardware with which the developed software has to interface, then
what exactly would the data interchange formats with the external system be?

After the analyst has understood the exact customer requirements, he proceeds to identify and resolve the
various requirements problems.

The most important requirements problems that the analyst has to identify and eliminate are the problems of
anomalies, inconsistencies, and incompleteness. When the analyst detects any inconsistencies, anomalies or
incompleteness in the gathered requirements, he resolves them by carrying out further discussions with the
end users and the customers.

Phases of Requirement Engineering :

Requirement Engineering generally includes 5 key activities:

1.Feasibility Study

 This is the first step before starting a software project. The aim is to decide whether the project should
be taken up or not.
Aspects checked : eg. Notes sharing system

 Technical Feasibility: Do we have the technology, tools, and skills to build the system?
 Economic Feasibility: Is it cost-effective? Will the benefits outweigh the costs?
 Legal Feasibility: Are there any legal issues? e.g., copyright for study materials, data privacy laws.
 Operational Feasibility: Will users accept and use the system?

 Example: Can we build an online notes sharing platform with our budget and time?
 Once a Feasibility Report is prepared, which helps management decide whether to continue or not.

2.Requirement Elicitation (Gathering)

 The process of collecting requirements from all stakeholders (people who will use or be affected by
the system).
 Talk to stakeholders: users, clients, managers, etc.
 Use interviews, surveys, questionnaires, observation.
 Example: Ask students how they want to upload and access notes, Interview students to know what
features they want: upload, download, search, comment, rate notes.
 A list of raw user requirements is created.

3.Requirement Analysis :

 After gathering, the requirements must be studied in depth to identify conflicts, duplicates, or missing
details.
 Activities performed :

1. Identify conflicts (e.g., one stakeholder wants open access, another wants login for security).
2. Remove ambiguities (unclear terms like „fast‟, „easy‟ — define them properly).
3. Categorize requirements: Functional (what system should do) and Non-functional (performance,
usability).
4. Prioritize: Which features are must-haves, nice-to-haves, or can be added later.
 Eg. Should guests be able to view notes? Or only registered users? Should there be a plagiarism
checker?What file formats are allowed? PDF, PPT, DOC?
 A clear, conflict-free set of requirements ready to be documented.

4.Requirement Specification :

 The analyzed requirements are documented in a structured way, usually in a Software Requirements
Specification (SRS) document.
 Write clear, precise, documented requirements.
 Example: The system shall allow registered users to upload PDF notes up to 50 MB,Only
authenticated users can comment on notes
 The SRS serves as a contract between developers and clients.

5.Requirement Validation :

 Ensures that the documented requirements truly represent the user‟s needs and are feasible to
implement.
 Make sure requirements are complete, correct, realistic.
 Review SRS with stakeholders to confirm it matches their expectations
  Activities performed :

1. Review meetings with stakeholders.

2. Walkthroughs of the SRS.
3. Inspections and peer reviews.
4. Prototyping (sometimes, build a small mock-up to check understanding).

 Example: Show the SRS to students & faculty — get their approval, If students want guest access, but
faculty wants restricted access — resolve this before coding starts.

Tools support for requirement engineering:

1.Observation reports(User Observation)

 Helps discover requirements that users may not be able to articulate.

 Reveals actual workflows, exceptions, and pain points.

2. Questionnaires (interview,surveys and polls)

3.Use cases

4.User stories

5.Requirement workshop

-A structured meeting with stakeholders (users, developers, clients) to gather, refine, and prioritize
requirements collaboratively.

6.Mind mapping

[Online Library System]

-------------------------------------------------

| | | |

[User] [Books] [Payments] [Notifications]

| | | |

[Login] [Search Books] [Pay Fines] [Email Alerts]

[Profile] [Borrow Book] [Membership] [SMS Alerts]

7.Role-Playing
8.Prototyping

The main deliverable is the SRS Document — it becomes the contract between the customer and the
development team.

Validation = Are we building the RIGHT system?

Verification (later during testing) = Did we build the system RIGHT?

SRS (Software Requirement Specification):

 SRS is a description of a software system to be developed

 It lays out functional and non-functional requirements
 IEEE 830 → Software Requirements Specification (SRS) Standard
Defines how to write clear, complete, and verifiable requirements documents.

SRS should address the following :

The basic issues that the SRS shall address are the following:

a) Functionality. What is the software supposed to do?

b) External interfaces. How does the software interact with people, the system„s hardware, other hardware,
and other software?
c) Performance. What is the speed, availability, response time, recovery time of various software functions,
etc.?
d) Attributes. What are the portability, correctness, maintainability, security, etc. considerations?
e) Design constraints imposed on an implementation. Are there any required standards in effect,
implementation language, policies for database integrity, resource limits, operating environment(s) etc.

Chracteristics of a good SRS :

A well-prepared SRS should have the following qualities:

a) Correct

The SRS must accurately describe the system to be built, without errors.

b) Unambiguous

Every requirement must have only one clear meaning. There should be no double meanings or vague terms.

c) Complete

The SRS should include all significant requirements — functional, non-functional, constraints, and
interfaces.

d) Consistent

No requirement should contradict another. Terminology and references must be uniform throughout.

e) Stability

Requirements should be prioritized to show which are essential, which are desirable, and which may change.
f) Verifiable

Each requirement must be testable — it should be possible to check whether it has been implemented
correctly.

g) Modifiable

The SRS should be structured in a way that makes it easy to update and revise as requirements evolve.

h) Traceable

Each requirement should be uniquely identified and traceable throughout the software development lifecycle
— from design to testing.

Preparation of software requirement specification (SRS) document in IEEE format:

The IEEE 830 standard defines a structure for writing a clear and complete Software Requirements
Specification.

1. Introduction

 1.1 Purpose
What is this document for? What will the software do?
 1.2 Scope
What is the software‟s overall goal? What problem does it solve?
 1.3 Definitions, Acronyms, Abbreviations
Explain special terms.
 1.4 References
Books, standards, links, etc.
 1.5 Overview
What‟s in the rest of the document?

2.Overall Description

 2.1 Product Perspective

Is it part of a bigger system? How does it fit?
 2.2 Product Functions
High-level features/functions.
 2.3 User Characteristics
Who will use it? Skills needed?
 2.4 Constraints
Limits — technology, laws, standards.
 2.5 Assumptions & Dependencies
Things assumed to be true (e.g., stable internet).
3.Specific Requirements

 3.1 Detailed functional requirements(Working criteria):

What the system must do: features, inputs, outputs.
 3.2 Non-functional requirements(Other than working):
Performance, storage, configuration, performance, cost, security,
usability,Interoperatability,flexibility,Disaster recovery.
 3.3 Interfaces:
User interface, hardware, software, communication interfaces.

4.Appendices

 Supporting information — tables, figures, diagrams, glossary.

Requirement Modeling :

Requirement Modelling is the process of representing user requirements in a structured, visual, or formal way
— so they are clear, complete, and can be easily understood by both stakeholders and developers.

It helps answer:

 What does the system need to do?

 How will data flow?
 What are the main activities, actors, inputs, outputs?

Why do we use Requirement Modelling?

 To visualize the system‟s functionality.

 To clarify requirements for all stakeholders.
 To find missing requirements early.
 To form the basis for design

Types of Requirement Models

There are two broad categories:

1.Functional Modelling

Shows what the system will do — its functions, features, and interactions.

Examples:

 Use Case Diagrams (who does what)

 Context Diagrams
 Data Flow Diagrams (DFD) (how data moves)

2.Behavioural & Data Modelling

Shows how the system behaves and how data is organized.

Examples:

 Entity-Relationship Diagrams (ERD) — how data entities relate.

 State Diagrams — how the system or an object changes states.
 Class Diagrams (in object-oriented analysis).

A.Use case diagram :

A Use Case Diagram shows what the system should do — it captures the functional requirements of a
system and how different users (actors) interact with it.Use case diagram gives us high level view of the
system without going into implementation details.

Roles:

1.Actors : Who will use the system. nyone or anything that interacts with the system (user, another system,
device). Drawn as a stick figure.

2.Use Cases: What actions they can perform. A task or function the system performs in response to an actor.
Drawn as an oval.

3.Relationships : How these actions relate to each other. Lines connecting actors to use cases, or use cases to
other use cases (like include or extend).

4.System Boundary : A box that defines what is inside (system) and outside (actors).It denotes with
Rectangle.

Relationships in Use Case Diagrams

1. Association:

 Solid line — connects actor and use case.

 Shows an actor uses or initiates that functionality.

2. Include («include»):

 One use case always uses another use case.

 Common steps reused in multiple places.
 E.g., Login might be included in Upload Notes and Download Notes.

3. Extend («extend»):

 Optional or conditional behavior.

 The extended use case may occur sometimes.
 E.g., Add Comments might extend View Notes.

4. Generalization:

 Inheritance between actors or use cases.

 E.g., Registered User → Premium User (inherits all behavior but adds more).
How to Draw a Use Case Diagram :

1. Identify Actors: Who interacts with the system?

2. Identify Use Cases: What functions will the system perform for the actor?
3. Draw System Boundary: Use a rectangle to show what‟s inside your system.
4. Place Use Cases: Inside the system boundary as ovals.
5. Connect Actors & Use Cases: Use association lines.
6. Add Relationships: If needed, show «include», «extend», or generalization.

DFD (Data Flow Diagram) :

A Data Flow Diagram (DFD) is a graphical tool used to represent how data moves through a system —
what data enters, what is done to it, and where it goes.

The data flow diagram enables you to develop models of the information domain and functional domain. As
the DFD is refined into greater levels of detail, you perform an implicit functional decomposition of the
system. At the same time, the DFD refine ment results in a corresponding refinement of data as it moves
through the processes that embody the application

 A few simple guidelines can aid immeasurably during the derivation of a data flow diagram:
 The level 0 data flow diagram should depict the software/system as a single bubble
 Primary input and output should be carefully noted
 Refinement should begin by isolating candidate processes, data objects, and data stores to be
represented at the next level
 All arrows and bubbles should be labeled with meaningful names
 Information flow continuity must be maintained from level to level
 one bubble at a time should be refined
The primary external entities (boxes) produce information for use by the system and consume information
generated by the system. The labeled arrows rep resent data objects or data object hierarchies. The level 0
DFD must now be expanded into a level 1 data flow model.

 It shows the flow of information, but not the flow of control (so it doesn‟t show loops or sequence
like flowcharts do).
 It‟s widely used in Requirement Engineering and System Analysis to visualize a system‟s
functional aspects.

Why do we create DFDs?

1. To understand and document how data moves in a system.

2. To identify inputs, outputs, storage, and processing points.
3. To help developers, users, and stakeholders get a clear picture — everyone speaks the same “visual
language.”
4. To break down complex systems into simpler parts (using levels).

DFD Levels — Why Levels Are Used

Level Description
Level 0 (Context The highest-level DFD. Shows the whole system as one single process with its
Diagram) external entities and data flows.
Level 1 Breaks the main process into major subprocesses. Shows main functional areas.
Level 2 Breaks Level 1 processes into more detailed sub-processes.
You can go deeper (Level 3, 4, etc.) until the processes are simple enough to
Level n
understand.
  Top-down refinement: Start with the big picture → add detail progressively.

 Avoids clutter in diagrams.

 Makes it easy for both technical and non-technical stakeholders to follow.

DFD Components & Notations :

Component Meaning Notation

Process An activity that transforms data Circle or rounded rectangle
Data Flow Movement of data Arrow
Open-ended rectangle (like two parallel
Data Store Where data is stored
lines)
External Source or destination of data (outside the system
Square or rectangle
Entity boundary)

How Data Flows :

Allowed:
Entity → Process
Process → Entity
Process → Data Store
Data Store → Process
Process → Process

Not allowed:
Entity → Entity (must flow through a process)
Data Store → Data Store (must flow through a process)
Entity → Data Store (must go through a process)

 DFD = What happens to the data, not how code works.

 Levels = Clarity through decomposition.
 Processes = The bridge between data sources, storage, and outputs.

Scenario-Based Modelling
Scenario-Based Modelling is a requirements modeling technique where you describe how users will interact
with a system through specific, real-world scenarios.

It focuses on use cases, scenarios, and user stories — describing what happens step-by-step when a user
performs a task with the system.

Why do we use it?

 To capture functional requirements from the user‟s perspective.

 To understand how the system should behave in different situations.
  To reveal alternative paths, exceptions, and edge cases.
 To help developers, testers, and stakeholders visualize what the system will do.

Key elements :

1. Scenario:
A narrative description of a specific interaction.

Example: “A student logs into the portal, checks their exam results, and logs out.

2.Use Case:
A generalized description of interactions — multiple scenarios make up a use case.

Example: “View Exam Results” use case includes normal scenario, failed login scenario, etc.

3.Actor:
A user or external system that interacts with the system.

Example: Student, Admin, Payment Gateway.

Types of Scenarios :

 Main / Basic Flow: The normal, expected path.

E.g., Successful login and result display.
 Alternative Flow: Variations from the main path.
E.g., Forgotten password, incorrect credentials.
 Exception Flow: What happens when there‟s an error or failure.
E.g., System is down, user account is locked.

How is it represented?

1.Narrative Text: Describes step-by-step what happens.

2.Use Case Diagrams (UML): Visual representation showing actors, use cases, and relationships.
3.Activity Diagrams: Flow of activities in a scenario.
4.Sequence Diagrams: Order of messages between objects for a scenario.

Example

Scenario: “Withdraw Cash at ATM”

 Actor: Customer
 Basic Flow:
1. Customer inserts card.
2. System asks for PIN.
3. Customer enters PIN.
4. System validates PIN.
5. Customer selects withdrawal.
6. Customer enters amount.
7. System checks balance.
8. System dispenses cash.
 9. Customer takes card and receipt.
 Alternative Flow:

 Wrong PIN → Try again.

 Exceed daily limit → Deny request.

Benefits :

 Simple to understand.
 Helps uncover hidden requirements.
 Improves communication with non-technical stakeholders.
 Provides a basis for test cases.

Limitations :

 May not fully describe non-functional requirements (like performance).

 Focuses more on normal user tasks
 Needs regular updates if requirements change.