UNIT -II

Software Requirements

1.Functional and Non Functional Requirements:

In software engineering, requirements define what a system must do (functional requirements) and
how it must perform (non-functional requirements). Both are crucial for delivering a
product that is high-quality, reliable, and meets user expectations
Functional requirements
Functional requirements specify the system's behavior and features. They
describe the specific actions and capabilities that a user expects the
system to perform.

Characteristics

 Focus: What the system does. These are the core features and
functionalities.

 User-facing: They are often directly visible to the end-user and are
tied to a business goal.

 Tangible: Developers can easily define them. Quality Assurance (QA)

testers can directly test them by verifying a specific output or result.

 Documentation: Often captured in user stories, use cases, or

functional specifications.

 Testable: Verified through functional testing, including unit,

integration, and acceptance tests.

Examples
For an e-commerce website, functional requirements include:

 The system must allow users to register and log in to their accounts.

 The system must allow users to add products to a shopping cart.

 The system must process payments from a third-party payment

gateway.

 The system must generate and send an order confirmation email to

the user.

 The system must allow administrators to manage the product

inventory.

Non-functional requirements
Non-functional requirements (NFRs), also known as "quality attributes" or
"system properties," define the criteria for how the system should perform
its functions. They impose constraints on the system's design and
implementation, shaping the overall user experience and system
efficiency.

Characteristics

 Focus: How the system performs its functions. This includes its
quality and characteristics.

 Indirect impact: They are not directly visible as features but

influence the user experience through performance, speed, and
usability.

 Less tangible: Often more abstract and harder to measure than

functional requirements, requiring specific benchmarks or metrics.

 Documentation: Captured in technical specifications, performance

criteria, or design constraints.

 Testable: Verified through non-functional testing, such as

performance, security, and usability testing.

Examples
For the same e-commerce website, non-functional requirements include:

 Performance: The website's homepage must load within 3 seconds

for 95% of users.

 Scalability: The system must support up to 50,000 concurrent users

during peak sales events without performance degradation.

 Security: The system must encrypt all financial transaction data

using industry-standard protocols.

 Usability: The user interface should be intuitive, allowing a new user

to complete a purchase with a maximum of three clicks.

 Availability: The system must have a 99.9% uptime, excluding

planned maintenance windows.
  Maintainability: Any critical bug should be fixable and redeployed
within 2 hours.

Key differences summarized

Aspect Functional Requirements Non-Functional Requirements

Definition What the system does. How the system performs its functions.

Focus System features and behavior. System quality attributes (e.g., speed, security).

User Directly visible to the end- Shapes the user experience through efficiency and
perspective user. usability.

Measurement Easily measured and tested Difficult to measure, requiring metrics and benchmarks.
through specific actions.

Impact Influences the core design and Affects the system architecture and user satisfaction.
functionality.

Consequence If not met, the system will be If not met, the system may function but could have poor
s unusable or incomplete. performance, security risks, or low user satisfaction.

The importance of balancing both

A balanced approach that considers both functional and non-functional
requirements from the beginning is vital for a successful project.

 Focusing only on functional requirements can result in a product

that works but is slow, insecure, and unreliable, ultimately leading
to a poor user experience and failure.

 Considering non-functional requirements early influences key

architectural decisions and prevents costly rework later in the
development cycle.
 2.User Requirments:

User requirements are the needs, expectations, and desired capabilities of the end-
users of a software system. They define the system's purpose and are typically
written in plain, non-technical language to be easily understood by all
stakeholders, including clients, managers, and end-users. These high-level
statements form the foundation for all subsequent, more technical
specifications, such as functional and system requirements.

Characteristics of a good user requirement

Characteristics of a good user requirement
To be effective, user requirements should follow the SMART criteria:

 Specific: Clearly and precisely describe what is needed. For

example, instead of "The system should be fast," a specific
requirement would be "The search results page must load in less
than two seconds".

 Measurable: Define the requirement in a way that its fulfillment can

be objectively verified. This avoids subjective interpretations like
"easy to use".
  Achievable: Ensure the requirement is realistic and can be
implemented within the project's constraints, including technical
feasibility and available resources.

 Relevant: Align with the project's overall business goals and

objectives. If a requirement doesn't add value, it may not be
necessary.

 Time-bound: Associate a deadline or timeframe with the

requirement, providing a clear timeline for its completion.

The user requirements specification (URS)

The User Requirements Specification (URS) is the document that formally
outlines the user requirements. It is typically created early in the project
by business analysts in collaboration with end-users and other
stakeholders.

A URS usually includes:

 Introduction: Provides a high-level overview of the system's purpose

and scope.

 User Profiles: Describes the different types of users who will interact
with the system.

 Functional Needs: Explains the features and functions users expect

from the system. For instance, "The customer must be able to track
their order status".

 Quality Attributes: Outlines non-functional aspects that affect the

user experience, such as usability, performance, and security.

 Constraints: Details any limitations or conditions the system must

comply with, such as budget, technical environment, or regulatory
standards.

The process of gathering user requirements

This crucial process, known as requirement elicitation, involves systematic
and direct communication with stakeholders to uncover their needs,
desires, and pain points. Key techniques include:
  Interviews: One-on-one conversations with stakeholders allow for in-
depth exploration of needs and clarification of requirements.

 Workshops: Facilitated sessions with a cross-section of stakeholders

promote collaboration and help resolve conflicting requirements
directly.

 Surveys and Questionnaires: Efficiently gather input from a large

number of users, which is especially useful for quantitatively
measuring perceptions or needs.

 Observation: Observing users in their natural work environment can

reveal unspoken or hidden needs that users may not think to
mention in an interview.

 Prototyping: Creating a working model or mock-up allows users to

interact with a tangible representation of the system and provide
immediate feedback.

Importance of user requirements in software engineering

Accurately defining user requirements is essential for project success.

 Reduces risk: Poorly defined or misunderstood requirements are a

leading cause of project failure and costly rework. Engaging users
early mitigates this risk by ensuring the team builds the right
product.

 Ensures customer satisfaction: By focusing on what the end-user

truly needs and values, the final product is more likely to be
accepted and successful in the market.

 Informs design and development: User requirements act as a

blueprint for the design and technical development, guiding
architects and developers toward a solution that effectively solves
the user's problem.

 Supports testing and validation: Clearly defined user requirements

provide the basis for acceptance testing, which verifies that the
delivered system meets user expectations.
  Manages scope: A clear URS helps to define project boundaries,
preventing "scope creep" and ensuring the project remains on
track.

3.System Requirments

System requirements detail what a system must do and how it must

perform to satisfy stakeholder needs. They translate the high-level,
business-oriented user requirements into a technical format that can be
used by developers, testers, and other technical stakeholders. A formal
document that captures system requirements is called the System
Requirements Specification (SRS).

System requirements are broadly divided into functional and non-

functional requirements.

1. Functional requirements
These describe the specific behaviors and features that a system must
have to meet its business and user needs. They are the "what" of the
system and are often derived from user requirements and use cases.

Characteristics

 Action-oriented: They define the explicit actions, processes, and

data handling the system must perform.

 Observable: Functional requirements are visible to the end-user and

are easily verifiable through testing.

 Examples for an online banking system:

o The system shall allow a user to log in with a username and

password.

o The system shall display the user's account balance.

o The system shall allow a user to transfer funds between

accounts.

2. Non-functional requirements (NFRs)

These describe the qualities and characteristics of a system, rather than
its specific functions. They constrain the system's operation and ensure it
performs well, is secure, and provides a positive user experience. NFRs
are often more quantitative and define "how well" the system must do its
job.

Categories and examples

 Performance: How the system reacts to user actions.

o Example: The system shall process a transaction in less

than two seconds during normal load.

 Security: How the system protects itself and its data.

o Example: All user data shall be encrypted in transit and

at rest.

 Scalability: The system's ability to handle an increasing

workload.

o Example: The system shall support up to 500 concurrent

users without any noticeable performance degradation.

 Usability: How easy the system is for users to interact with.

 Example: The user interface shall be intuitive enough for a

first-time user to complete a transaction without training.

 Reliability: The system's ability to operate without failure.

 Example: The system shall have an uptime of 99.9%.

 Availability: When the system is operational and accessible.

 Example: The system shall be available 24/7, excluding a

planned maintenance window.

 Maintainability: How easy the system is to modify and fix.

 Example: The system shall have well-documented APIs to

allow new features to be integrated easily.

3. Derived system requirements

These are requirements that emerge from an analysis of the user and
functional requirements. For instance, a user's request for real-time ticket
availability could lead to a system requirement for a high-speed,
networked infrastructure and a common database to handle concurrent
updates.

4. Constraints
These are limitations or boundaries placed on the system's design and
implementation.

 Hardware/software requirements: Specific CPU speed, memory, or

operating system a program needs to run.

 Technical constraints: Any limitations of the technical environment,

such as platform dependencies or required APIs.

 Legal/regulatory constraints: Compliance with specific laws and

regulations (e.g., GDPR, HIPAA).

System requirements specification (SRS)

The SRS document brings together all system requirements and serves as
a contract between the client and the developers.

 Purpose: The SRS translates business needs into a precise, technical

format.

 Structure: A typical SRS includes:

o An introduction describing the system's purpose and scope.

o A general description of its functions and interfaces.

o Detailed sections on specific functional and non-functional

requirements.

o Information on design constraints and assumptions.

o A section on performance criteria.

Importance of system requirements

Clearly defined system requirements are foundational to a successful
software project.

 Reduces risk: They help identify and address potential problems

early in the development cycle, reducing costly rework.

 Ensures project alignment: They keep all stakeholders (developers,

testers, clients) on the same page, ensuring the final product meets
expectations.

 Guides design: System requirements provide the basis for system

architecture and design activities.

 Enables effective testing: They provide the objective criteria needed

to create and execute test cases and verify that the system is
correct and complete.

4.Interface Specification:

An interface specification in software engineering is a detailed document

or set of rules that defines how different software components, systems,
or modules should interact and communicate with each other. It acts as a
contract, outlining the communication protocols, data formats, and
behavioral expectations required for seamless integration and
interoperability.

The primary goal of an interface specification is to define a system's

public-facing boundary, separating the internal implementation details
from the external view. This separation of concerns allows different teams
to develop components independently while ensuring that they can
communicate effectively when brought together.

Types of interfaces specifications

Interface specifications can be broadly categorized based on the nature of
the interaction they describe.

1. Procedural interfaces (APIs)

 Definition: These specifications define the services offered by a

software component or subsystem that can be accessed by calling
its procedures or methods.
  Content: A procedural interface specification details the names of
the

 parameters required for each call (including their types and order),
and the data types of the return values.

 Example: An Application Programming Interface (API) specification

for a payment service, outlining methods
like processPayment(amount, currency, cardNumber) .

2. Data structure interfaces

 Definition: These define the structure and format of the data being
passed between different subsystems.

 Content: They specify the data types, field names, and organization
of data objects, often using graphical data models for clarity.

 Example: A specification for a JSON object that a server will send to

a client, detailing the object's keys ( userId , orderId ) and the data
type for each value.

3. Data representation interfaces

 Definition: This is a more low-level specification that defines the

exact format of data, such as the bit-level ordering, for
communication between systems.

 Use case: These are most common in embedded systems or real-

time systems where performance is critical and every bit of data
matters.

4. User interface (UI) specification

 Definition: This is a specific type of interface specification that

describes the interaction between the software system and the end-
user.

 Content: It details the visual layout (wireframes, mockups), logical

flow of user actions, and descriptions of display elements, buttons,
and error cases.
  Example: A document that specifies the user flow for a web
application's checkout process, detailing the fields, buttons, and
validation messages on each screen.

Key components of an interface specification document

An effective interface specification document (ISD) is comprehensive and
leaves no room for ambiguity. It typically includes:

 Interface overview: A high-level description of the interface's

purpose, a list of communicating systems, and a definition of the
communication protocol (e.g., REST, SOAP).

 Operations/methods: For a procedural interface, this section lists all

the public methods or functions available. Each entry includes:

o Name: The name of the method.

o Parameters: A description of all input parameters, including

their data type, constraints (e.g., must be a positive integer),
and whether they are optional.

o Return values: The data type and meaning of the value

returned by the method.

o Behavior: A clear explanation of what the method does,

including any side effects.

 Data structures: Detailed definitions of all data objects that are

exchanged across the interface, including their attributes and data
types.

 Error handling: A description of how the interface handles and

reports errors,

 including a list of possible error codes and the circumstances under

which they are returned.

 Security measures: Specifications for authentication, authorization,

and data encryption to secure communication across the interface.

 Versioning: A strategy for managing changes to the interface over

time, including clear guidelines for backward compatibility.
Importance of interface specification
 Enables parallel development: By defining a clear contract, teams
can develop subsystems concurrently without needing to know each
other's internal implementation details.

 Facilitates integration: A precise specification ensures that different

components, even those developed by separate teams or
organizations, can integrate smoothly.

 Reduces ambiguity and errors: Detailed and unambiguous

specifications minimize the risk of miscommunication and
integration errors, which can be costly to fix later in the
development cycle.

 Enhances testability: With a clear contract defined, test cases can

be created early to validate that the interface and its components
function as expected.

 Supports maintenance: The specification provides essential

documentation for maintaining and upgrading components, as it is
clear which parts of the interface are public and what their expected
behavior is.

 Aids system evolution: With versioning and clear rules, an interface

can evolve without breaking existing clients, ensuring the system
remains robust and adaptable

5.The Software Requirements Document(SRS)

A Software Requirements Document (SRD), more commonly known as

a Software Requirements Specification (SRS), is a comprehensive and
detailed description of a software system to be developed. It captures the
functionalities, performance, and constraints of the system, acting as a
blueprint for developers, a reference for testers, and a binding contract
between the client and the development team.

The SRS is typically produced during the early phases of the Software
Development Life Cycle (SDLC) after extensive interaction with
stakeholders to understand their needs.
Key components of an SRS
A well-structured SRS, often following a standard like the IEEE 830-1998,
typically contains these key sections:

1. Introduction

This section provides a high-level overview of the document and the

project it describes.

 Purpose: States the objective of the software and its intended use.

 Scope: Outlines the project's boundaries, defining what the software

will and will not do.

 Definitions and acronyms: Lists technical terms and abbreviations

used throughout the document to ensure clarity for all readers.

 References: Lists any related documents, such as business

requirements or technical guides, for further information.

2. Overall description

This section provides a broad view of the software, its context, and its
users.

 Product perspective: Explains how the new software fits into an

existing system or ecosystem.

 Product functions: A summary of the major features and capabilities

of the software.

 User classes and characteristics: Describes the different types of

users who will interact with the system, along with their roles and
levels of expertise.

 Operating environment: Specifies the hardware, software, network,

and other systems the software must operate within.

 Design and implementation constraints: Lists limitations on the

project, such as specific programming languages, regulatory
compliance, or budgetary limitations.
  Assumptions and dependencies: Documents any external factors or
conditions that the project relies upon.

3. Functional requirements

This is a detailed list of the core behaviors and features the system must
provide. Each requirement is precisely defined to avoid ambiguity.

 User interactions: Describes how users will interact with the system
(e.g., login, data entry).

 Business rules: Specifies the rules governing the software's

operation (e.g., password strength, access control).

 Data handling: Defines how the system will process inputs, produce
outputs, and manage data.

 Error handling: Specifies how the system should behave when errors
or invalid inputs are encountered.

4. Non-functional requirements (NFRs)

These define the quality attributes and operational characteristics of the

software, such as performance, security, usability, reliability, availability,
and maintainability.

5. External interface requirements

This section specifies all interactions between the software and external
components, including user interfaces (UI), hardware interfaces, software
interfaces (like APIs and databases), and communication interfaces
(network protocols and data formats).

6. System models and diagrams

Visual aids like use case diagrams, data flow diagrams (DFDs), entity-
relationship diagrams (ERDs), and sequence diagrams can help clarify
complex system components and workflows.

7. Acceptance criteria and test cases

This section outlines the conditions for accepting a feature and may
include test scenarios to validate the software against its requirements.

Importance and benefits of an SRS

An SRS clarifies project scope, facilitates communication between
stakeholders, and reduces risks by identifying requirements early. It
guides development and testing, supports maintenance, and can serve as
a contract between the client and development team.

6.Requirements Engineering Process:

The Requirements Engineering (RE) process is a systematic and

disciplined approach to defining, documenting, and managing the needs
and expectations of stakeholders for a software system. Its primary goal is
to produce a high-quality Software Requirements Specification (SRS) that
serves as the foundation for all subsequent development activities.

The RE process is highly iterative, as requirements are rarely perfect after

the first round of gathering and analysis. It typically involves a series of
interconnected stages:

1. Feasibility study
This initial stage determines if the project is viable from technical,
economic, operational, legal, and schedule perspectives.

2. Requirements elicitation
Also known as requirements gathering, this stage involves collecting
information from stakeholders through various methods, such as
interviews, workshops, surveys, observation, document analysis, and
prototyping.

3. Requirements analysis and negotiation

In this phase, gathered requirements are examined for inconsistencies,
conflicts, and incompleteness. The team works with stakeholders to
prioritize and resolve conflicting requirements through negotiation.

4. Requirements specification
This involves documenting the finalized requirements, including functional
and non-functional requirements and constraints, often in an SRS
document. System models like UML diagrams can be used to visually
describe the system.

5. Requirements validation
This stage verifies that the documented requirements accurately reflect
stakeholder needs through methods like requirements reviews,
prototyping, test case generation, and checklists.

6. Requirements management
This ongoing process involves managing changes to the requirements
throughout the development lifecycle, including change control,
traceability, and version control.

7.Feasibility Study :

A feasibility study is an assessment performed during the initial phase of

software development to determine the viability and practicality of a
proposed project. It evaluates the project from multiple perspectives to
help stakeholders make an informed "go/no-go" decision before
committing significant resources. By identifying potential opportunities
and risks early on, the study helps in defining the project's scope and
increasing its chances of success.

Types of feasibility studies

A comprehensive feasibility study in software engineering typically
examines several key areas. These are often remembered using the
acronym TELOS.

Technical feasibility

This analysis determines whether the project can be implemented using

existing or new technologies within the organization's technical
capabilities.

 Resource assessment: Evaluates the availability and capability of

hardware, software, and development tools.

 Expertise evaluation: Assesses the technical skills and experience of

the development team.

 Technical risk identification: Uncovers potential technical challenges

like scalability issues, integration problems, or performance
bottlenecks.
  Compatibility: Checks if the proposed solution is compatible with the
organization's current IT infrastructure.

Economic feasibility

This study, often considered the most crucial, analyzes the financial
viability of the project by comparing the costs and benefits.

 Cost-benefit analysis: Calculates the total costs of development

(including hardware, software, and personnel) and compares them
to the expected financial gains or return on investment (ROI).

 Budget estimation: Provides a realistic estimate of the funds

required for the project, helping with budget planning and financial
management.

 Profitability analysis: Determines if the potential long-term benefits

and revenue generated by the software justify the initial
investment.

Legal feasibility

This evaluation assesses whether the proposed project conflicts with any
legal, regulatory, or ethical requirements.

 Compliance analysis: Ensures the project adheres to relevant laws,

such as data protection acts (e.g., GDPR), accessibility standards,
and licensing regulations.

 Intellectual property review: Examines potential issues related to

patents, copyrights, and trademarks.

 Regulatory assessment: Checks for any legal barriers that might

prevent the project from being implemented successfully.

Operational feasibility

This analysis determines how well the proposed system will be received
and integrated into the organization's existing workflows and daily
operations.

 User acceptance: Measures user comfort and willingness to adapt to

the new system, which is crucial for operational success.
  Process impact: Identifies how the new software will affect the
company's daily processes and what new procedures need to be
established.

 Ease of maintenance: Considers how easy or challenging it will be to

operate and maintain the software after deployment.

Schedule feasibility

This study determines whether the project can be completed within the
proposed timeframe and sets realistic deadlines for completion.

 Timeline analysis: Assesses the proposed project deadlines and

whether they are reasonable given the project's scope and resource
availability.

 Milestone tracking: Sets key project milestones and timelines to

help maintain momentum and ensure the project remains on track.

 Resource dependencies: Evaluates how resource constraints and

project complexity might impact the schedule.

The feasibility study report

The outcome of the feasibility study is a formal report that provides a
comprehensive overview of the analysis and includes the final
recommendations. A typical report includes:

 Executive summary: A brief overview of the project and the main

findings and recommendations.

 Project scope and overview: Defines the project's purpose, scope,

and objectives.

 Analysis of each feasibility type: Detailed sections presenting the

findings from the technical, economic, operational, and schedule
analyses.

 Risk assessment: Identifies potential risks and outlines proposed

mitigation strategies.

 Alternatives: Lists alternative solutions and compares them against

the proposed solution.
  Conclusion and recommendations: Presents a clear recommendation
to proceed, modify, or abandon the project, supported by the
analysis.

Importance of a feasibility study

 Reduces risk: By identifying potential problems and challenges
early, the study minimizes the risk of project failure and costly
setbacks.

 Informed decision-making: It provides stakeholders with crucial

information, allowing for objective and data-driven decisions about
whether to invest in the project.

 Optimizes resource allocation: The analysis helps in accurately

estimating and allocating the necessary resources, including
budget, personnel, and time.

 Clarifies scope and objectives: The study forces a clear definition of

the project's scope, ensuring all stakeholders are aligned on the
goals and objectives.

 Enhances credibility: A thorough and well-documented feasibility

study enhances the project's credibility with investors,
management, and other stakeholders.

8.Requirments Elicitation and analysis:

Requirements elicitation and requirements analysis are two distinct but closely related
activities within the requirements engineering process. Elicitation is the process of
gathering raw information and understanding stakeholder needs, desires,
and constraints. Analysis then systematically examines that gathered
information to refine, organize, and model the requirements before they
are specified in a formal document.

Requirements elicitation
This phase is sometimes called "requirements discovery" and involves
actively working with stakeholders to understand the problem domain and
the system's requirements. Elicitation is a complex and highly
collaborative process, often facing challenges because stakeholders may
have difficulty articulating their needs, or their requirements may be
contradictory.
Elicitation techniques

Analysts use a variety of techniques to gather requirements from

stakeholders. A combination of these methods is often the most effective
approach.

 Interviews: Structured or unstructured one-on-one sessions are held

with stakeholders to understand their needs and concerns in detail.

 Workshops: Facilitated, group-oriented sessions bring together a

diverse set of stakeholders to brainstorm and resolve conflicts
collaboratively.

 Surveys and questionnaires: These are used to collect data from a

large number of stakeholders, particularly when they are
geographically dispersed.

 Observation (Ethnography): Analysts observe users in their natural

work environment to uncover unspoken, or tacit, needs and
inefficiencies.

 Prototyping: Creating simplified models or mockups of the system

helps stakeholders visualize and provide feedback on potential
designs and features.

 Document analysis: Existing documents, such as manuals, business

procedures, and legacy system specifications, are reviewed to
extract relevant information.

 Use cases and scenarios: These describe the system's behavior from
a user's perspective, detailing a sequence of interactions between
an "actor" and the system to achieve a specific goal.

Requirements analysis
After requirements have been elicited, they must be analyzed to ensure
they are complete, consistent, and feasible. This process helps to organize
the gathered information and identify any ambiguities, conflicts, or
missing details.

Analysis and negotiation activities

  Classification and organization: Raw requirements are categorized
into groups, such as functional, non-functional, and technical, to
make them more manageable. The Model-driven approach can also
be used for better visualization.

 Prioritization and negotiation: Not all requirements are equally

important. Analysts work with stakeholders to prioritize
requirements based on business value, technical feasibility, and
cost. Conflicts and differing needs are resolved through negotiation.

 Consistency and completeness checking: The requirements are

reviewed to ensure there are no contradictions and that all
necessary information has been captured. This helps prevent costly
rework later in the development cycle.

 Modeling: Creating graphical models of the system helps clarify

complex requirements. Techniques like Data Flow Diagrams (DFDs),
Entity-Relationship Diagrams (ERDs), and Unified Modeling
Language (UML) are commonly used.

 Requirements specification: The finalized and analyzed

requirements are formally documented in a Software Requirements
Specification (SRS) document, which serves as a reference for all
team members.

Challenges in elicitation and analysis

 Communication barriers: Misunderstandings can arise from technical
jargon, differing terminology, or simply poor communication
between developers and stakeholders.

 Incomplete or ambiguous requirements: Stakeholders may struggle

to articulate their needs fully, leading to gaps in the requirements.
Vague terms like "user-friendly" or "fast" are also common
challenges.

 Conflicting requirements: Different stakeholders often have

competing or contradictory requirements that need to be carefully
negotiated and resolved.
  Stakeholder engagement: Ensuring that all relevant stakeholders
are identified and willing to participate is crucial but can be
challenging.

 Tacit knowledge: Some of the most important requirements are

based on unspoken assumptions or tacit knowledge held by
experienced users. Techniques like observation are necessary to
uncover these needs.

9. Requirments Validation:

Requirements validation is the process of checking that the documented

requirements for a software system accurately reflect the needs and
expectations of the stakeholders. It is a critical step in the requirements
engineering process, as errors or ambiguities in the requirements
document can lead to significant rework costs if discovered later in the
development lifecycle.

The main goal of requirements validation is to discover problems with the

requirements before design and implementation begin. This involves
checking for validity, consistency, completeness, and realism.

Key requirements checks

During the validation process, several types of checks are performed on
the requirements documented in the Software Requirements Specification
(SRS).

 Validity checks: Confirms that the requirements truly address the

customer's actual needs. A stakeholder might state a requirement
based on their current process, but a deeper analysis might reveal a
different, more effective function is needed to solve the underlying
problem.
  Consistency checks: Ensures that the requirements are not
contradictory. The document is checked to make sure there are no
conflicting statements or different descriptions of the same system
function.

 Completeness checks: Verifies that the requirements document

includes definitions for all functions and constraints intended by the
system user. The validation process aims to find missing information
or scenarios.

 Realism checks: Assesses if the requirements can actually be

implemented given the available technology, budget, and schedule.
It helps ensure that the proposed solution is technically and
economically feasible.

 Verifiability checks: Confirms that each requirement is written in a

way that allows it to be objectively tested. A requirement should be
clear enough to allow for the creation of tests to demonstrate that
the delivered system meets the specification.

Requirements validation techniques

A variety of techniques are used to validate requirements, often in
combination, to ensure a thorough review.

 Requirements reviews and inspections: Involves a systematic,

manual analysis of the requirements by a team of experts and
stakeholders. Reviewers check for errors, ambiguities, and
inconsistencies. Formal inspections follow a structured process with
assigned roles, while walkthroughs are less formal.

 Prototyping: Involves creating a working, executable model of the

system to demonstrate to end-users and stakeholders. This allows
them to experiment with the system and identify problems or
missing requirements that were not obvious from the written
documentation.

 Test case generation: Developing test cases from the requirements

specification is a powerful validation technique. If a requirement is
ambiguous or unrealistic, it becomes difficult or impossible to design
 a clear test case for it. This reveals potential problems early and
helps ensure the requirements are testable.

 Traceability analysis: Establishes links between requirements,

design artifacts, and test cases. A Requirements Traceability Matrix
(RTM) is used to ensure that every requirement is accounted for and
to assess the impact of any changes.

 Automated consistency analysis: For requirements written in a

formal or structured notation, Computer-Aided Software Engineering
(CASE) tools can automatically check for certain types of
inconsistencies, such as circular definitions or type errors.

 Checklists for validation: Using pre-made checklists to

systematically confirm that requirements meet predefined
standards for quality attributes like completeness, clarity, and
verifiability.

Importance of requirements validation

 Cost reduction: Finding and fixing errors in the requirements phase
is significantly cheaper than correcting them later in development or
after the system has been deployed.

 Increased user satisfaction: By involving stakeholders and ensuring

that the documented requirements truly reflect their needs, the
validation process helps create a product that aligns with customer
expectations.

 Reduced risk: Validation helps to identify potential issues,

ambiguities, and inconsistencies early on, which lowers the overall
project risk.

 Prevents scope creep: A thorough validation process ensures that

the established requirements are clear and agreed upon, which
helps prevent uncontrolled changes later in the project.

 Improves quality: By detecting and resolving potential problems

with the requirements early, validation contributes to a more
durable and dependable final product.

11.Requirments Management:
Requirements management is a systematic process for defining,
documenting, prioritizing, tracking, and controlling changes to
requirements throughout the entire software development life cycle
(SDLC). It is a continuous, umbrella activity within the larger requirements
engineering process. Its primary goal is to ensure that the final product
meets stakeholder needs and project objectives by preventing common
problems like scope creep, miscommunication, and project delays.

Core activities of requirements management

1. Requirements identification and prioritization

This activity ensures that all requirements are uniquely identified and that
their relative importance is clearly understood. This step helps the team
focus on the most valuable work first.

 Identification: Each requirement is assigned a unique identifier,

making it possible to cross-reference and track throughout the
project.

 Prioritization: Requirements are ranked based on factors like

business value, technical feasibility, cost, and urgency, which
informs release planning and resource allocation.

2. Requirements change management

Changes to requirements are inevitable, but they must be managed

consistently and in a controlled manner to avoid project disruption. The
change management process includes:

 Problem analysis and change request: A problem or proposed

change is identified, analyzed for validity, and a formal change
request is submitted.

 Impact analysis: The potential effects of the proposed change are

assessed, including its impact on other requirements, design,
implementation, schedule, and cost. This is often done using
traceability information.

 Decision-making: Stakeholders review the change request and

impact analysis, and a decision is made to approve, reject, or defer
the change.
  Implementation: If approved, the requirements document and
related artifacts (design, code, tests) are modified, and the changes
are communicated to all relevant parties.

3. Requirements traceability

Traceability is the ability to track a requirement throughout the

development lifecycle, from its origin (the stakeholder) to its final
implementation and testing.

 Backward traceability: Links system requirements to user and

business requirements, ensuring that the system is being built
according to stakeholder needs.

 Forward traceability: Links requirements to design components,

code modules, and test cases, ensuring that every requirement is
implemented and tested.

 Requirements traceability matrix (RTM): A table that maps

requirements to other project artifacts. For complex projects, this
information is stored in a database to ensure accuracy and ease of
maintenance.

4. Requirements baselining

Baselining is the process of formally defining a stable and agreed-upon set

of requirements at a specific point in time. Once a baseline is established,
any changes must go through a formal change control process.

 Defines scope: A baseline clearly defines the project scope and is

critical for managing scope creep.

 Sets commitments: It allows the team to make staffing and budget

commitments based on a stable set of requirements.

 Formal change control: Establishes a controlled environment for

managing changes to the agreed-upon requirements.

Importance of requirements management

 Reduces project risk: Studies have shown a strong correlation
between poor requirements management and project failure, cost
 overruns, and delays. Managing requirements effectively helps
mitigate these risks by detecting issues early.

 Controls scope creep: Requirements management provides a formal

process for handling changes, preventing the uncontrolled
expansion of a project's scope.

 Improves communication and collaboration: It ensures all

stakeholders have a shared and accurate understanding of the
requirements, aligning expectations and reducing
miscommunication.

 Increases product quality: A clear and controlled set of requirements

ensures that the final product accurately addresses stakeholder
needs and performs according to quality standards.

 Facilitates compliance: In regulated industries, maintaining a digital

audit trail and full traceability is crucial for demonstrating
compliance with standards.

 Supports maintenance and reuse: Well-managed and documented

requirements serve as a valuable resource for future maintenance
and for reusing requirements in subsequent projects.

Requirements management tools

While simple projects might use spreadsheets or documents, complex
projects require dedicated tools to effectively manage requirements.

 Key features: These tools provide a central repository for

requirements, support traceability, automate change control
workflows, and offer real-time visibility and reporting through
dashboards.

 Examples: Tools like IBM Engineering Requirements Management

DOORS Next and Jama Connect offer robust features for managing
requirements in complex and regulated environments.