Requirement

Engineering and
Design Engineering

Module 2
 IEEE Definition of Software Requirement

"A software requirement is a condition or capability that

must be met or possessed by a system or system
component to satisfy a contract, standard, specification, or
other formally imposed documents."
● Software Requirements are the features, functions, and constraints that
describe what the software should do and how it should perform.

● Software Requirements Engineering (SRE) is the systematic process of

collecting, analyzing, documenting, validating, and managing the
requirements of a software system to ensure that the developed software
satisfies customer needs.

Software Requirements Engineering (SRE)

Once requirements are identified, they go through four major activities.

1. Requirement Elicitation

2. Requirement Analysis

3. Requirement Specification

4. Requirement Validation
Software Requirements Engineering (SRE)

Requireme
Requireme
Requirement Requireme nt
nt
Elicitation nt Analysis Specificatio
Validation
n (SRS)

What does the Are the Write the Did we capture

customer requirements requirements the right
need? correct and clearly. requirements?
feasible?
(Collect) (Document in (Verify)
(Refine)
SRS)
Requirement
Modeling is
performed
during the
Requirement
Analysis phase.
Why is Software Requirements Engineering Important?

Requirements are the foundation of any software project.

If requirements are incorrect or incomplete:
● The software may not satisfy customer needs.
● Development cost increases.
● More time is required to fix errors.
● Customer satisfaction decreases.
● The project may fail.
Objectives of Software Requirements Engineering

● Understand customer needs.

● Define the scope of the software.
● Reduce misunderstandings between customer and
developer.
● Minimize development risks.
● Improve software quality.
● Reduce development cost and time.
● Serve as a reference for design, coding, and testing.
Software Requirements Engineering (SRE)

1. Requirement Elicitation

2. Requirement Analysis

3. Requirement Specification

4. Requirement Validation
 Requirements Gathering

• Requirements gathering activity is also popularly known as

Requirements Elicitation.
• The primary objective of the requirement gathering task is to collect
the requirements from the stakeholders.
 Methods of requirements gathering

1. Studying Existing Documentation:

● The analyst reviews available documents (like the
Statement of Purpose) before meeting the customer.

● These documents help understand the context,

purpose, stakeholders, and required features of the
software.
2. Interview:
● Analysts identify different user categories, as each has
unique software needs.

Example: In library automation software, users can be

library members, librarians, and accountants—each with
distinct requirements.
● The Delphi technique is used to refine these

requirements:
○ The analyst drafts requirements and shares them

with users.
○ Users give feedback.

○ The analyst revises the document repeatedly until

consensus is reached.
3. Task Analysis:
● Users view software as a set of services (tasks).
● The analyst identifies the tasks users want the software
to perform.
● Each task is broken into detailed steps with user input

Example, issuing a book involves steps like user

authentication, checking book limits, verifying
reservations, updating records, and printing slips.

● Purpose:
● Helps the analyst understand user activities in detail and
organize them into a hierarchy of subtasks.
4. Scenario Analysis:
● A task can behave differently under various conditions
(scenarios).
● Each scenario represents a different situation in which a task is
performed.

Example (for a library's book issue task):

○ Book is successfully issued.
○ Book is reserved and cannot be issued.
○ Member has reached the borrowing limit.

The analyst identifies all possible scenarios for each task and defines:
● System behavior in each case.
● Conditions that trigger the scenario.
● Required system responses.

All details are finalized in consultation with users.

5. Form Analysis:
● Used when automating an existing manual system.
● Analysts study existing manual forms filled by users
and notifications they receive.

● The goal is to identify:

○ What input data the system receives from forms.
○ What output data the system produces.

● Helps understand how input data should be processed

to generate the desired output, based on user feedback.
 Example CASE STUDY of Requirement Elicitation

Requirements gathering for office automation at the CSE department

Objective:
To automate routine administrative and academic tasks in the CSE
department, improving efficiency, reducing manual workload, and enabling
digital tracking.
1. Studying Existing Documentation:

• Review current procedures and documents used (manual logs, approval

formats, circulars).
• Analyze existing forms like:
– Leave applications
– Lab booking sheets
– Faculty workload reports
– Circular distribution records
2. Interviews (Stakeholder Identification):

• Conduct interviews with:

– Faculty members (for workload management, leave approvals, circulars)
– Office staff (for data entry, notices, admin coordination)
– Students (for submitting requests like course registration, document verification)
– Head of Department (HoD) (for approval workflows, reports)
3. Task Analysis (Examples):

Identify tasks and subtasks performed:

• Leave Management:
– Faculty submits request → HoD approves → Notification sent
• Lab Booking:
– Faculty selects lab → Checks availability → Confirms booking
• Document Request (students):
– Student submits request → Clerk verifies → Document prepared → Approval by
faculty/HOD → Issued
4. Scenario Analysis (for each task):

For Leave Management:

• Leave is approved and notification is sent.
• Leave is rejected due to unavailability or clash.
• Leave request pending beyond a certain period.
For Lab Booking:
• Lab is available and booked successfully.
• Lab is already booked at the desired time.
5. Form Analysis:
Analyze existing paper forms and templates:
• Leave application form
• Lab booking register
• Student request form
• Faculty workload template
• Circular format
Determine:
• Input fields required (Name, ID, Date, Purpose)
• Output/notifications expected
• Data validation rules
 Type of Requirements

● Business Requirements

○ High-level objectives of the customer or organization (e.g., "Increase user engagement by 25%").

● Customer Requirements

○ Statements of what the system should provide, described from the user’s point of view.

○ This includes both:

■ Functional Requirements (what the system must do)

■ Non-Functional Requirements (quality and performance aspects)

● Technical Requirements

○ More detailed and often system-oriented; include design constraints, technologies, etc.
 Categories of Customer Requirements

● Functional Requirements :

○ These define what the system should do—its functionality.

○ Example : The system shall allow users to log in using a username and password.

● Non-functional Requirements:

○ These describe how the system performs certain tasks.

○ Example : The system should respond to user inputs within 2 seconds.

 Functional Requirements
● Describe what the system should do.

● Define specific behavior or functions of the system (e.g., calculations,

data processing, user interactions).

● Expressed as services, tasks, or functions.

● Examples:

○ The system shall allow users to log in with a username and password.

○ The software shall generate a monthly sales report.

 Functional requirements
functionalities that are available for invocation can be organized as follows.

1. Operation mode 1

1. Functional requirement 1.1

2. Functional requirement 1.2

2. Operation mode 2

1. Functional requirement 2.1

2. Functional requirement 2.2

Example: Search book availability in
library
 Non-Functional Requirements
● Describe how the system performs its functions.

● Often referred to as quality attributes of the system.

○ Performance: Response time, throughput

○ Usability: Ease of use

○ Reliability: Mean time between failures

○ Security: Authentication, authorization

○ Maintainability: Ease of updates

○ Scalability, Portability, etc.

● Example:

○ The system shall respond to user input within 2 seconds under normal load.
Example: Search book availability in
library
 Functional vs Non-Functional
Requirements
Non-Functional
Aspect Functional Requirement
Requirement
Describes what the Describes how the
Definition system should do system performs (quality
(functions, features) attributes)
Performance, reliability,
Focus Behavior of the system
usability, etc.
- Login feature - Generate - System should load
Examples reports - Payment within 2 seconds - Should
process support 1000 users
Measured via
Easily testable with inputs
Testability performance, usability
and outputs
tests
Developers, testers,
Mostly developers,
Stakeholder Interest architects, users,
testers
managers
 Requirements Analysis
• After collecting requirements, the analyst carefully examines them to
understand the exact needs of the customer.
• The gathered data may contain:
– Contradictions
– Ambiguities
– Incomplete information
• This happens because stakeholders usually have only a partial view of the
system.
• The analyst must identify and resolve all issues by conducting further
discussions with the stakeholders.
● Requirement Analysis is the process of
understanding, refining, and modeling user and
system requirements after they have been elicited.

● Requirement analysis involves several structured

activities:
○ Requirements Modeling

○ Feasibility and Risk Analysis

 Goals of Requirement Analysis

● Understand the user’s needs clearly and completely

● Resolve ambiguities, inconsistencies, and incompleteness

● Establish system boundaries

● Transform user requirements into well-defined system requirements

● Prepare for system modeling and design

 Requirement Analysis Principles

key principles to be followed during analysis:

Principle Explanation

Understand the problem Before jumping into solution design

Involve users actively They are the source of truth

Use scenarios and prototypes To refine understanding

Record requirements clearly Use models and documentation

Validate with stakeholders Constant feedback loops

Manage changing requirements Be ready for evolution

 Requirements Modeling

● Transform user needs into:

○ Functional models (what the system should do)

○ Behavioral models (how the system will react)

○ Data models (what information the system uses)

● Modeling tools:

○ Use Case diagrams

○ Data Flow Diagrams (DFD)

○ Entity-Relationship Diagrams (ERD)

○ State diagrams

○ UML models
 Requirements Modeling

● Creating the Analysis Model

● The Analysis Model is the central output of this phase. It includes:

○ Functional Modeling: Use cases, functions, external interactions

○ Behavioral Modeling: State changes, sequences, control flow

○ Data Modeling: Class diagrams, ERD, data dictionaries

● This model forms the blueprint for the design phase.

 Requirement Specification

● Requirement specification is the process of documenting

the analyzed requirements in a formal Software
Requirements Specification (SRS) document.
● Objectives
○ Clearly document all requirements.
○ Serve as a contract between customer and developer.
○ Provide the basis for design, coding, and testing.
SOFTWARE REQUIREMENTS
SPECIFICATION (SRS)
• After cleaning the requirements of inconsistencies and gaps, the analyst
organizes them into a Software Requirements Specification (SRS)
document.

• The SRS contains all user requirements in a structured but informal format.

• It is one of the most important and difficult documents in the software

development life cycle.

• The difficulty lies in addressing the needs of a diverse audience who will
use the document differently.
 Users of SRS Document
• Users, customers, and marketing personnel
• Software developers
• Test engineers
• User documentation writers
• Project managers
• Maintenance engineers
 Importance of SRS
• Forms an agreement between the customers and the developers
• Reduces future reworks
• Provides a basis for estimating costs and schedules
• Provides a baseline for validation and verification
• Facilitates future extensions
 Characteristics of a Good SRS
Document
• Concise
• Implementation-independent
• Traceable
• Modifiable
• Identification of response to undesired events
• Verifiable
 Structure of SRS (Software
Requirements Specification)
1. Introduction 3. System Features &
○ 1.1 Purpose Requirements
○ 1.2 Intended Audience – 3.1 Functional
○ 1.3 Scope Requirements
○ 1.4 Definition – 3.2 Use Cases / Sequence
○ 1.5 References Diagrams
2. Overall Description – 3.3 External Interface
○ 2.1 User Interface
Requirements
○ 2.2 System Interface – 3.4 Database
Requirements
○ 2.3 Software & Hardware
Requirements – 3.5 Non-Functional
Requirements
○ 2.4 Constraints
4. Deliver for Approval
○ 2.5 User Characteristics
 Requirement Validation

Requirement validation is the process of checking whether the

documented requirements correctly represent the customer's
needs.
Objectives
● Ensure the right requirements have been documented.
● Detect errors before development begins.
● Confirm stakeholder agreement.
Validation Techniques
● Requirement Reviews
● Walkthroughs
● Inspections
● Prototyping
● Test Case Generation
 Design Principles

Software design is the process of transforming software

requirements into a blueprint for constructing the software
system.
A good software design ensures that the system is
efficient, maintainable, scalable, reliable, and easy to
understand.
Design principles provide guidelines for creating
high-quality software, while software architecture defines
the overall structure and organization of the system.
 Design Principles

● Modularity: Divides a software system into smaller,

independent modules, each performing a specific
function.
● Abstraction: Hides unnecessary implementation details
and exposes only the essential features of the system.
● Coupling: Measures the degree of dependency
between modules. Low coupling is desirable because
it makes the system easier to maintain and modify.
● Cohesion: Measures how closely related the
responsibilities within a module are. High cohesion is
desirable because each module performs a single,
well-defined task.
 Modularity
Modularity is the principle of dividing a large software system into smaller,
manageable, and independent units called modules.
Each module performs a specific function and communicates with other modules
through well-defined interfaces.
Instead of building the entire software as a single program, developers break it into
separate modules, making the system easier to develop, test, and maintain.

Real-Life Example
An Online Shopping System can be divided into:
● User Management Module
● Product Management Module
● Shopping Cart Module
● Payment Module
● Order Management Module
Each module performs its own task independently while collaborating to complete the
shopping process.
 Abstraction

Abstraction is the process of hiding unnecessary implementation details and exposing

only the essential features of a system.

It focuses on what the system does rather than how it does it.

Purpose

● Reduce system complexity.

● Improve understanding of software.
● Protect implementation details.
● Allow developers to focus on functionality.

Real-Life Example

An ATM Machine allows customers to withdraw cash without exposing the internal
banking processes.
Types of Abstraction

1. Data Abstraction

Hides the internal representation of data.

Example
A BankAccount class provides methods like:

● Deposit()
● Withdraw()
● CheckBalance()

The user need not know how the balance is stored internally.

2. Procedural Abstraction

Hides the implementation of operations.

Example
Calling the function:

PrintReport()

The user does not need to know how the report is generated.
Coupling and Cohesion

● Coupling
○ Coupling refers to the degree of interdependence between software modules.
○ High coupling means that modules are closely connected and changes in one module may
affect other modules.

○ Low coupling means that modules are independent, and changes in one module have little
impact on other modules.

● Cohesion
○ Cohesion refers to the degree to which elements within a module work together to fulfill a
single, well-defined purpose.

○ High cohesion means that elements are closely related and focused on a single purpose,
while low cohesion means that elements are loosely related and serve multiple purposes.
● Both coupling and cohesion are important factors in determining the
maintainability, scalability, and reliability of a software system.

● High coupling and low cohesion can make a system difficult to change and
test, while low coupling and high cohesion make a system easier to maintain
and improve.
 Types of Coupling

Type of Coupling Brief Description Example

1. Data Coupling Modules communicate by passing only the required Customer Billing System
data as parameters. This is the best and most passing customer ID and bill
desirable form of coupling. amount.

2. Stamp Coupling A complete data structure is passed even though Passing an entire
(Data-Structured only part of it is needed, leading to unnecessary Employee object when only
Coupling) dependency. the employee ID is required.

3. Control Coupling One module passes control information (flags or A sorting function receiving
commands) that determines the behavior of another a flag to sort in ascending or
module. descending order.

4. External Coupling Modules depend on external systems, devices, file Reading data from an
formats, communication protocols, or hardware. external database or printer.

5. Common Coupling Multiple modules share the same global data or Several modules accessing
global variables. Changes to shared data affect all the same global
dependent modules. configuration variable.
 Type of Coupling Brief Description Example

6. Content Coupling One module directly accesses or modifies the A module directly modifying
internal data or logic of another module. This is the another module's private
worst form of coupling and should be avoided. variables.

7. Temporal Modules depend on the order or timing of execution. A database connection must
Coupling One module must execute before another. be established before
executing SQL queries.

8. Sequential The output of one module becomes the input of Output of a data validation
Coupling another, creating a sequence of dependencies. module passed to a report
generation module.

9. Communicational Modules communicate through a shared Two applications

Coupling communication mechanism such as a database, exchanging data through a
shared file, or message queue. common database.

10. Functional One module depends on the functionality of another Payment module calling the
Coupling by calling its methods or functions. If excessive, it Tax Calculation module.
leads to tight dependency.
 Type of Coupling Brief Description Example

12. Interaction Methods of one class invoke methods of another Order class calling methods
Coupling class. Lower interaction through well-defined of the Payment class.
interfaces is preferred.

13. Component One class depends on another by using it as an Student class containing an
Coupling object, method parameter, or local variable. object of the Course class.
Common in object-oriented programming.
 Types of Cohesion

Type of Cohesion Brief Description Example

1. Functional Cohesion All elements of a module contribute to A Login module that only
one well-defined task. This is the best authenticates users.
and most desirable type of cohesion.

2. Sequential Cohesion The output of one part of a module Read data → Validate data →
becomes the input of the next part, Process data.
creating a sequence of operations.

3. Communicational Elements work on the same input data Updating a student record and
Cohesion or produce the same output data. printing the updated record.

4. Procedural Cohesion Elements are grouped because they Calculate GPA → Print Result →
follow a specific sequence of execution, Update Record.
even though they may perform different
tasks.

5. Temporal Cohesion Elements are grouped because they are System startup module that initializes
executed at the same time or during the memory, loads configuration, and
same phase. establishes database connections.
 Type of Cohesion Brief Description Example

1. Functional All elements of a module contribute to one A Login module that only
Cohesion well-defined task. This is the best and most authenticates users.
desirable type of cohesion.

6. Logical Cohesion Elements perform similar kinds of A single input module that reads data
operations, but the specific operation is from keyboard, file, or network based
selected using a control flag or parameter. on a user option.

7. Coincidental Unrelated tasks are grouped together in one A module that prints reports,
Cohesion module without any meaningful relationship. calculates salary, and sends emails.
This is the worst form of cohesion.

8. Informational A module contains multiple operations that A BankAccount class with methods
Cohesion work on the same data structure or object, like deposit(), withdraw(), and
each with its own entry point. Common in checkBalance().
object-oriented systems.

9. Layer Cohesion Elements are grouped according to their A Presentation layer handling only
responsibility within a specific architectural user interface functions.
layer.
 Layered Architecture

Layered Architecture is a software architecture style in which the system is

organized into multiple layers, where each layer performs a specific
responsibility. Each layer provides services to the layer above it and uses
services from the layer below it.

It is one of the most widely used architecture styles because it promotes

modularity, maintainability, scalability, and separation of concerns.

Typical Layers

1. Presentation Layer (User Interface Layer)

2. Business Logic Layer (Application Layer)

3. Data Access Layer (DAL)

 Characteristics of Layered Architecture

● Divides the system into logical layers.

● Each layer has a specific responsibility.
● A layer communicates only with its adjacent layers.
● Changes in one layer have minimal impact on other layers.
● Supports modular and reusable software development.
 ● Presentation Layer (UI) : This is where the user interacts with the
application. It handles user input and displays information.

● Application Layer (Business Logic) : This layer contains the core

logic of the application, such as processing user requests and
managing business rules.

● Data Access Layer (Database) :Data is retrieved and stored. It

interacts with the database, ensuring separation of data concerns.

For Example: In an online e-commerce application, the presentation layer

handles user interaction, the business logic layer processes orders and
payments, and the data access layer manages database interactions. This
separation allows for clear responsibilities and easier maintenance.
1. Presentation Layer (User Interface Layer)
Responsibilities

● Provides the user interface.

● Accepts user input.
● Displays output to users.
● Sends user requests to the Business Layer.

Examples

● Login page
● Registration page
● Dashboard
● Mobile app screens
2. Business Logic Layer (Application Layer)
Responsibilities

● Implements business rules and application logic.

● Processes user requests.
● Validates input.
● Coordinates between the Presentation Layer and Data Access Layer.

Examples

● Calculate total bill

● Verify user credentials
● Process online payment
● Apply discounts
3. Data Access Layer (DAL)

Responsibilities

● Communicates with the database.

● Performs database operations such as Create, Read, Update, and Delete (CRUD).
● Hides database implementation details from the Business Layer.
● Stores application data permanently.
● Executes SQL queries.
● Maintains data integrity and consistency.

Examples

● MySQL
● Oracle
● PostgreSQL
● SQL Server
 Working of Layered Architecture

● The user interacts with the Presentation Layer.

● The Presentation Layer forwards the request to the Business
Logic Layer.
● The Business Logic Layer validates the request and processes
the business rules.
● The Business Logic Layer sends the request to the Data Access
Layer.
● The Data Access Layer performs database operations by
communicating with the Database Layer.
● The Database Layer returns the requested data.
● The response travels back through the Data Access Layer and
Business Logic Layer to the Presentation Layer.
● The Presentation Layer displays the result to the user.
 MVC Architecture
Model-View-Controller (MVC) is a software architecture style that divides an application
into three independent components: Model, View, and Controller. This separation of
concerns makes the application easier to develop, maintain, test, and extend.

MVC is widely used in web applications, desktop applications, and mobile

applications.

This separation of concerns improves code organization, maintainability, and scalability.

● Model: Manages application data, business logic, and interactions with the
database.
● View: Handles the presentation layer and displays data to users through the user
interface.
● Controller: Acts as an intermediary between the Model and View, processing user
requests and controlling application flow.

Example: In an e-commerce application, the Model manages product data, the View
displays product information to users, and the Controller handles actions such as
searching products or placing orders.
 Components of MVC

1. Model
The Model represents the data and business logic of the application.

Responsibilities

● Stores and manages application data.

● Performs business logic and calculations.
● Interacts with the database.
● Notifies the View when data changes.

Example

In an Online Shopping System:

● Product details
● Customer information
● Order records
● Inventory data
2. View
The View is the user interface (UI) of the application.

Responsibilities

● Displays data received from the Model.

● Presents information to the user.
● Accepts user input.
● Does not contain business logic.

Example

● Login page
● Product catalog page
● Shopping cart page
● Order summary page
3. Controller
The Controller acts as an intermediary between the Model and the View.

Responsibilities

● Receives user requests.

● Processes user input.
● Calls the appropriate Model methods.
● Selects the View to display the results.

Example

When the user clicks "Add to Cart":

● Controller receives the request.

● Updates the shopping cart through the Model.
● Returns the updated cart View.
 Working of MVC

1. User interacts with the View.

2. The View sends the request to the Controller.
3. The Controller processes the request.
4. The Controller updates or retrieves data from the Model.
5. The Model performs the required operations and returns the
result.
6. The Controller selects the appropriate View.
7. The View displays the updated information to the user.
 Client-Server Architecture

Client-Server Architecture is a software architecture style in which the system is divided into
two main components: the Client, which requests services, and the Server, which processes
those requests and provides the required services or resources.

The client and server communicate over a network using communication protocols such as
HTTP, HTTPS, FTP, or TCP/IP.
 Components of Client–Server Architecture

1. Client

The Client is the front-end application or device used by the user to request
services from the server.

Responsibilities

● Provides the user interface.

● Accepts user input.
● Sends requests to the server.
● Receives and displays the server's response.

Examples

● Web browser (Chrome, Firefox, Edge)

● Mobile application
● Desktop application
● ATM terminal
2. Server

The Server is a computer or application that receives client requests,

processes them, and sends back the appropriate response.

Responsibilities

● Processes client requests.

● Executes business logic.
● Communicates with the database.
● Stores and manages data.
● Provides security and authentication.

Examples

● Web Server
● Database Server
● File Server
● Mail Server