Requirement Engineering

 It is a critical process in software development that involves defining, documenting,

and maintaining software requirements.
 The primary goal of requirements engineering is to understand the needs and
expectations of stakeholders and to translate these needs.
 Requirement engineering helps in bridging the gap between the customer’s
expectations and the software system being developed.

Types of Requirements in Software Engineering

In software engineering, requirements are generally classified into two main categories:

1. Functional Requirements
2. Non-Functional Requirements

1. Functional Requirements
Functional requirements describe what the system should do. They define the specific
behavior or functions of the system and represent the primary capabilities that the system
must provide. Functional requirements answer questions like:
- What inputs the system should accept?
- What outputs the system should produce?
- What data the system should store and manipulate?
- How the system should behave in particular situations?

Examples of Functional Requirements:

- User login and authentication.
- Payment processing for an e-commerce application.
- Generating a monthly sales report.
- Searching for items in a catalog.
- Sending notifications to users.
2. Non-Functional Requirements

Non-functional requirements describe the quality attributes, constraints, and other properties
of the system. They define how the system should perform and are often referred to as
"quality attributes." These requirements are crucial for determining the usability, reliability,
and performance of the system.

Non-functional requirements are often categorized into various subtypes, such as:

- Performance Requirements: Define the system's response time, throughput, and resource
utilization.
- Example: "The system should handle 10,000 concurrent users with a response time of less
than 2 seconds."

- Security Requirements: Specify the security aspects like access control, data protection, and
encryption.
- Example: "All user pas swords must be encrypted using a secure hashing algorithm."

- Usability Requirements:Focus on the ease of use and user experience aspects.

- Example: "The system should provide a user-friendly interface accessible to users with
disabilities."

- Reliability Requirements: Define the system's ability to operate without failure.

- Example: "The system should have an uptime of 99.9%."

- Maintainability Requirements: Specify how easy it should be to modify, update, or maintain

the system.
- Example: "The system should allow new modules to be integrated with minimal changes
to existing components."

- Scalability Requirements:Describe how well the system can scale up or down in response to
varying loads.
- Example: "The system should support scaling from 100 to 10,000 users without requiring a
complete redesign."
- Compliance Requirements: Include regulations or standards that the system must adhere to.
- Example: "The system must comply with the GDPR (General Data Protection
Regulation)."

Requirement Documentation
What Is Requirement Documentation in Software Engineering?
• Requirement documentation in software engineering is the systematic process of
documenting all necessary information related to a software project's requirements.
• It serves as a single source of truth for project stakeholders, including product
managers, software testers, and developers.
• Investing in requirement documentation is a good practice for ensuring project
success.

Key components include:

• Software Requirements Document (SRD): The foundation of requirement
documentation, the SRD outlines functional requirements, non-functional
requirements, and external components necessary for the software's functionality and
performance.
• Software Requirements Specification (SRS) Document: An elaboration of the
SRD, the SRS document provides a detailed breakdown of requirements, often
including diagrams, code snippets, and acronyms for clarity and precision.
• Project Stakeholders: Vital contributors to requirement documentation, including
product managers, developers, testers, and key stakeholders from client organizations.
• Process Documentation: Describes the methodology for eliciting, analyzing, and
validating requirements, ensuring a smart, efficient approach to software
development.
• External Interface Requirements: Specifies the interactions between the software
system and external components, such as APIs, databases, or third-party services.
• Test Automation Tutorials: Guides automated testing techniques to ensure software
quality and reliability.
 How To Make Requirement Documentation in Software Engineering

A structured approach is essential for project success in requirement documentation in

software engineering. Here are five steps to guide you through the process, ensuring
clarity, accuracy, and alignment with project objectives and stakeholder needs.

1. Stakeholder Requirements
• Purpose: In this step, you gather requirements directly from stakeholders such as
clients, end-users, or other people involved in the system. It ensures that the software
aligns with business goals and user expectations.
• Activities:
o Conduct interviews, surveys, and workshops.
o Collect both explicit needs (what the user asks for) and implicit needs (what
they may not express but still require).
o Prioritize based on the importance to stakeholders.
2. Document Functionality
• Purpose: This step involves capturing the functional requirements, which describe the
core behaviors and functionalities that the system must support.
• Activities:
o Define how the system will perform specific tasks.
 o Create use cases, user stories, and process flows.
o List the expected features, such as the ability to create user accounts, handle
transactions, or generate reports.
• Output: This often results in a Software Requirements Specification (SRS) document
detailing what the system should do.
3. Document Non-Functionals
• Purpose: Non-functional requirements (NFRs) describe how the system performs
certain functions, including constraints on system operation such as performance,
scalability, security, and usability.
• Activities:
o Identify constraints like load time, maximum concurrent users, uptime
requirements, and security protocols.
o Ensure the system’s architecture can support these demands.
o Address areas like reliability, portability, and maintainability.
• Output: A detailed list of performance metrics, security standards, and other quality
attributes.
4. Review Requirements
• Purpose: This step ensures that all documented requirements (both functional and
non-functional) are accurate, complete, and feasible.
• Activities:
o Validate requirements with stakeholders to confirm their needs are fully
captured.
o Check for consistency and ensure that there are no conflicting requirements.
o Assess the feasibility of implementing the requirements, given the available
resources, technology, and time constraints.
• Output: Reviewed and confirmed requirement documents that all stakeholders agree
upon.
5. Assumptions Document
• Purpose: Documenting assumptions is crucial for managing expectations and
identifying any constraints or dependencies that the team should be aware of.
• Activities:
o List assumptions about the environment, technology, user behavior, or
business processes that impact requirements.
o Note external factors like third-party systems or integration with external
tools.
 o Identify any potential risks or issues that could arise from these assumptions.
• Output: An assumptions document helps ensure everyone has a common
understanding and addresses potential risks early.
6. Manage Requirements
• Purpose: Managing requirements involves tracking changes, ensuring traceability, and
maintaining the requirements as the project evolves.
• Activities:
o Set up a change management process to handle evolving requirements during
development.
o Ensure traceability of each requirement through the development lifecycle
(i.e., from requirements to design, implementation, and testing).
o Monitor requirement status (e.g., approved, implemented, tested) and update
stakeholders regularly.
• Output: A requirements management system or document that helps control changes
and ensures that the development process stays aligned with the agreed-upon
requirements.

• Requirements Engineering Process

1. Feasibility Study
The feasibility study mainly concentrates on below five mentioned areas below.
• Technical Feasibility:
In Technical Feasibility current resources both hardware software along required
technology are analyzed/assessed to develop the project.
• Operational Feasibility:
 In Operational Feasibility degree of providing service to requirements is analyzed
along with how easy the product will be to operate and maintain after deployment.
• Economic Feasibility:
In the Economic Feasibility study cost and benefit of the project are analyzed.
After that, it is analyzed whether the project will be beneficial in terms of finance for
the organization or not.
• Legal Feasibility:
In legal feasibility, the project is ensured to comply with all relevant laws, regulations,
and standards. It identifies any legal constraints that could impact the project and
reviews existing contracts and agreements to assess their effect on the project’s
execution.
• Schedule Feasibility:
In schedule feasibility, the project timeline is evaluated to determine if it is realistic
and achievable. Significant milestones are identified, and deadlines are established to
track progress effectively.

2. Requirements Elicitation
It is related to the various ways used to gain knowledge about the project domain and
requirements. The various sources of domain knowledge include customers, business
manuals, the existing software of the same type, standards, and other stakeholders of the
project.
Requirements elicitation is the process of gathering information about the needs and
expectations of stakeholders for a software system. This is the first step in the requirements
engineering process and it is critical to the success of the software development project. The
goal of this step is to understand the problem that the software system is intended to solve
and the needs and expectations of the stakeholders who will use the system.
Several techniques can be used to elicit requirements, including:
• Interviews: These are one-on-one conversations with stakeholders to gather
information about their needs and expectations.
• Surveys: These are questionnaires that are distributed to stakeholders to gather
information about their needs and expectations.
• Focus Groups: These are small groups of stakeholders who are brought together to
discuss their needs and expectations for the software system.
• Observation: This technique involves observing the stakeholders in their work
environment to gather information about their needs and expectations.
• Prototyping: This technique involves creating a working model of the software
system, which can be used to gather feedback from stakeholders and to validate
requirements.
3. Requirements Specification
Requirements specification is the process of documenting the requirements identified in the
analysis step in a clear, consistent, and unambiguous manner. This step also involves
prioritizing and grouping the requirements into manageable chunks.
The goal of this step is to create a clear and comprehensive document that describes the
requirements for the software system. This document should be understandable by both the
development team and the stakeholders.
Several types of requirements are commonly specified in this step, including
1. Functional Requirements: These describe what the software system should do. They
specify the functionality that the system must provide, such as input validation, data
storage, and user interface.
2. Non-Functional Requirements: These describe how well the software system should
do it. They specify the quality attributes of the system, such as performance,
reliability, usability, and security.
3. Constraints: These describe any limitations or restrictions that must be considered
when developing the software system.
4. Acceptance Criteria: These describe the conditions that must be met for the software
system to be considered complete and ready for release.

4. Requirements Verification and Validation

Verification: It refers to the set of tasks that ensures that the software correctly implements a
specific function.
Validation: It refers to a different set of tasks that ensures that the software that has been
built is traceable to customer requirements. If requirements are not validated, errors in the
requirement definitions would propagate to the successive stages resulting in a lot of
modification and rework. The main steps for this process include:
1. The requirements should be consistent with all the other requirements i.e. no two
requirements should conflict with each other.
2. The requirements should be complete in every sense.
3. The requirements should be practically achievable.
Reviews, buddy checks, making test cases, etc. are some of the methods used for this.
Requirements verification and validation (V&V) is the process of checking that the
requirements for a software system are complete, consistent, and accurate and that they meet
the needs and expectations of the stakeholders. The goal of V&V is to ensure that the
software system being developed meets the requirements and that it is developed on time,
within budget, and to the required quality.
1. Verification is checking that the requirements are complete, consistent, and accurate.
It involves reviewing the requirements to ensure that they are clear, testable, and free
 of errors and inconsistencies. This can include reviewing the requirements document,
models, and diagrams, and holding meetings and walkthroughs with stakeholders.
2. Validation is the process of checking that the requirements meet the needs and
expectations of the stakeholders. It involves testing the requirements to ensure that
they are valid and that the software system being developed will meet the needs of the
stakeholders. This can include testing the software system through simulation, testing
with prototypes, and testing with the final version of the software.

5. Requirements Management

Requirements management is the process of managing the requirements throughout the

software development life cycle, including tracking and controlling changes, and ensuring
that the requirements are still valid and relevant. The goal of requirements management is to
ensure that the software system being developed meets the needs and expectations of the
stakeholders and that it is developed on time, within budget, and to the required quality.
Several key activities are involved in requirements management, including:
• Tracking and controlling changes
• Version control
• Traceability
• Communication
• Monitoring and reporting