Chapter 2.

1
Unit II

Software Requirement Analysis and Specification

Software Requirements
In software engineering, software requirements are descriptions of the functionalities and constraints of
a software system. They represent the needs that the software must fulfill to solve a particular problem
or to achieve specific objectives. Software requirements serve as a foundation for software design,
development, testing, and maintenance processes. Here are some key aspects of software requirements:

1. Functional Requirements: These describe the specific functionalities or features that the
software system must provide. Functional requirements outline what the software should do in
terms of input, processing, and output. They typically include use cases, user stories, and
functional specifications.

2. Non-functional Requirements: Also known as quality attributes or non-functional characteristics,

these requirements specify the qualities that the software system must exhibit. This includes
attributes such as performance, reliability, scalability, usability, security, maintainability, and
compatibility.

3. User Requirements: User requirements capture the needs and expectations of the stakeholders
who will interact with the software system. These stakeholders may include end-users,
administrators, managers, and other relevant parties. User requirements are often expressed in
natural language and may be supplemented with mockups, prototypes, or user interface designs.

4. System Requirements: System requirements define the capabilities and constraints of the entire
software system, including hardware, software, network, and other infrastructure components.
System requirements may include specifications for compatibility with other systems, integration
with existing infrastructure, and performance characteristics.

5. Business Requirements: Business requirements describe the objectives and constraints of the
organization or business that is commissioning the software project. These requirements help
align the software development efforts with the strategic goals of the organization. Business
requirements may include factors such as cost, schedule, regulatory compliance, and market
demands.

6. Constraints: Constraints are limitations or restrictions that impact the design and
implementation of the software system. Constraints may include technical constraints (e.g.,
compatibility with legacy systems), budgetary constraints, time constraints, regulatory
constraints, and resource constraints.
 7. Traceability: Traceability refers to the ability to trace requirements throughout the software
development lifecycle. This involves linking requirements to design elements, code modules, test
cases, and other artifacts to ensure that each requirement is adequately addressed and
validated.

8. Prioritization: Prioritization involves ranking requirements based on their importance, urgency,

and impact on the software system. Prioritization helps focus development efforts on the most
critical and valuable requirements, especially in situations where resources are limited.

9. Validation and Verification: Validation ensures that the software system meets the intended
needs and expectations of the stakeholders, while verification confirms that the software system
adheres to its specified requirements. Validation and verification activities include reviews,
inspections, walkthroughs, testing, and acceptance criteria.

Functional and Non-Functional Requirements

Functional and non-functional requirements are two fundamental categories of software requirements
that serve different purposes in defining the behavior and characteristics of a software system:

1. Functional Requirements:

a. What the system should do: Functional requirements define the specific behaviors or
functions that the software system must perform to meet the needs of its users.

b. Actions and Inputs: They typically describe the interactions between the system and its
users or other systems, including inputs, processing, and outputs.

c. Use Cases and User Stories: Functional requirements are often expressed in the form of
use cases or user stories, which describe specific interactions or scenarios involving the
system.

d. Example: For a social media platform, functional requirements might include features
such as user registration, posting updates, commenting on posts, and sending messages.

2. Non-Functional Requirements:

a. How the system should perform: Non-functional requirements specify the quality
attributes or characteristics of the software system, such as performance, reliability,
usability, security, and scalability.

b. Quality Attributes: They focus on aspects of the system beyond its specific
functionalities and address qualities that affect the overall user experience and system
behavior.

c. Constraints and Limits: Non-functional requirements may also include constraints and
limitations, such as compatibility with certain platforms or adherence to regulatory
standards.
 d. Example: Non-functional requirements for a banking application might include
requirements for response time (e.g., transactions must be processed within 3 seconds),
security (e.g., encryption of sensitive data), and availability (e.g., system uptime of
99.99%).

Here's a breakdown of some key differences between functional and non-functional requirements:

• Focus: Functional requirements focus on what the system should do, while non-functional
requirements focus on how the system should perform.

• Tangibility: Functional requirements are often more tangible and concrete, describing specific
features and behaviors, while non-functional requirements are more abstract and describe
qualities or attributes of the system.

• Measurability: Functional requirements are typically easier to measure and validate directly
through testing, while non-functional requirements may require more specialized testing and
evaluation techniques to assess qualities such as performance and security.

• Interdependency: Functional and non-functional requirements are often interdependent, as the

implementation of functional features may impact non-functional qualities and vice versa. For
example, adding encryption to enhance security may impact system performance.

Requirement elicitation and Analysis

Requirement elicitation and analysis are critical phases in the software development lifecycle where the
needs, expectations, and constraints of the stakeholders are identified and analyzed to define the
requirements of the software system. Here's an overview of these processes:

1. Requirement Elicitation:

a. Definition: Requirement elicitation is the process of gathering, discovering, and

understanding the needs and expectations of the stakeholders who will interact with the
software system.

b. Stakeholder Identification: Identify and engage with stakeholders who have a vested
interest in the software project, including end-users, customers, managers, domain
experts, and other relevant parties.

c. Techniques: Employ various techniques to elicit requirements, such as interviews,

surveys, workshops, focus groups, observations, document analysis, and brainstorming
sessions.

d. Documentation: Document the gathered requirements in a clear and concise manner,

ensuring that they accurately reflect the needs and preferences of the stakeholders.

e. Validation: Validate the elicited requirements with stakeholders to ensure that they are
complete, consistent, and relevant to the objectives of the software project.
 f. Iterative Process: Requirement elicitation is often an iterative process, involving multiple
rounds of gathering, refining, and validating requirements to achieve a comprehensive
understanding of the stakeholders' needs.

2. Requirement Analysis:

a. Definition: Requirement analysis is the process of analyzing and organizing the elicited
requirements to understand their implications, dependencies, and priorities.

b. Requirement Modeling: Model the requirements using appropriate techniques and

notations, such as use cases, user stories, data flow diagrams, entity-relationship
diagrams, or formal specification languages.

c. Prioritization: Prioritize requirements based on their importance, urgency, and impact

on the software system and its stakeholders. This helps focus development efforts on
the most critical and valuable features.

d. Conflict Resolution: Resolve conflicts and inconsistencies among requirements to ensure

that they are coherent and compatible with each other.

e. Traceability: Establish traceability relationships between requirements and other

artifacts, such as design documents, test cases, and code, to ensure that each
requirement is adequately addressed and validated throughout the software
development lifecycle.

f. Feasibility Assessment: Assess the feasibility of implementing the requirements within

the constraints of the project, including technical feasibility, resource availability,
budgetary constraints, and time constraints.

SRS document
A Software Requirements Specification (SRS) document is a comprehensive description of the intended
behavior and functionality of a software system. It serves as a formal agreement between the
stakeholders (such as customers, users, and developers) regarding what the software product should do.
The SRS document acts as a blueprint for the development team and provides a basis for estimating
costs, planning schedules, and performing system validation and verification.

It serves as a formal agreement between the stakeholders (such as customers, users, and developers)
regarding what the software product should do.

Here's an outline of the typical sections found in an SRS document:

1. Introduction:

a. Overview of the document

 b. Purpose and scope of the software system

c. Definitions, acronyms, and abbreviations

d. References to related documents

2. Overall Description:

a. Product perspective: Describes how the software fits into the larger system or
environment, including interfaces with other systems.

b. Product functions: Provides a high-level description of the main functions and features
of the software system.

c. User characteristics: Describes the intended users of the software and their
characteristics.

d. Constraints: Specifies any constraints that may impact the development or use of the
software, such as hardware limitations, regulatory requirements, or organizational
policies.

3. Specific Requirements:

a. Functional requirements: Detailed descriptions of the specific functions and capabilities

of the software system, often organized by use cases or user stories.

b. Non-functional requirements: Specifies the quality attributes and constraints of the

software system, such as performance, reliability, usability, and security requirements.

c. External interface requirements: Describes the interfaces between the software system
and external entities, such as users, hardware devices, or other software systems.

d. System features: Provides a detailed breakdown of the features and components of the
software system, often accompanied by diagrams or other visual aids.

e. Data requirements: Describes the data inputs, outputs, storage, and processing
requirements of the software system.

f. Operational requirements: Specifies the operational characteristics and requirements of

the software system, such as installation, deployment, and maintenance procedures.

g. Security requirements: Describes the security features, controls, and mechanisms to

protect the software system and its data from unauthorized access or malicious attacks.

h. Performance requirements: Specifies the performance characteristics and constraints of

the software system, such as response times, throughput, and scalability requirements.

i. Safety requirements: Describes any safety-critical functions or requirements of the

software system, particularly relevant for systems with potential safety implications.

j. Documentation requirements: Specifies the documentation deliverables required for the

software system, such as user manuals, technical specifications, and training materials.
 k. Legal and regulatory requirements: Describes any legal or regulatory requirements that
the software system must comply with, such as privacy laws or industry standards.

4. Appendices:

a. Additional information, such as glossary of terms, diagrams, or supplementary

documents.