Requirements engineering

Requirements engineering is the process of eliciting, analyzing,

specifying, validating, and managing the requirements for a system or
software application. The goal of requirements engineering is to ensure
that the system or application being developed meets the needs and
expectations of its stakeholders, including end-users, customers, and
other interested parties.
The requirements engineering process typically involves the following
steps:
1. Elicitation/requirement gathering: This involves identifying the
needs and requirements of the stakeholders, through various
techniques such as interviews, surveys, observation, and
workshops.
2. Analysis: This involves analyzing and organizing the
requirements into a structured form, such as a use case or a user
story, and identifying any conflicts or ambiguities.
3. Specification: (SRS) this involves creating a formal document
that describes the requirements in detail, including functional and
non-functional requirements, constraints, and acceptance criteria.
4. Validation: This involves reviewing the requirements document
with stakeholders to ensure that it accurately reflects their needs
and expectations, and that it is complete, consistent, and feasible.
5. Management: This involves tracking and maintaining the
requirements throughout the development process, including
making changes as necessary, and ensuring that they are properly
prioritized and communicated to the development team.

Effective requirements engineering is essential for the success of a

software development project. By accurately capturing the needs and
expectations of stakeholders, and ensuring that they are properly
communicated to the development team, the resulting software is more
likely to meet the needs of its users, and be delivered on time and within
budget.
User requirements refer to the needs, desires, and expectations of the
end-users or stakeholders of a system or product. User requirements are
typically gathered through various methods such as surveys,
interviews, and user testing. These requirements focus on the
functionalities and features that users expect the system to have, as well
as their user experience and user interface preferences.

System requirements, on the other hand, refer to the technical

specifications and functionalities that a system or product must have to
meet the needs of the users or stakeholders. System requirements
include details such as system performance, reliability, security, and
scalability. They are often defined by system architects and developers
to ensure that the system meets technical standards and can perform its
intended tasks efficiently and effectively.

Both user and system requirements are crucial to the success of a

project. The user requirements ensure that the system meets the needs
of the end-users, while the system requirements ensure that the system
meets technical standards and can function optimally. By defining both
types of requirements, stakeholders can ensure that the system will
meet the needs of its users and perform its intended functions as
expected.

Functional & Non-Functional

Requirements
 Description of services which a software will provide to the *end
user.
 Constraints which we will imposed on the Services are also part
of the requirements.
Additional information
 User
 End User
Functional requirements
Functional requirements are a set of specifications that describe what a
system, product, or service must be able to do to meet the needs of its
users. These requirements describe the specific functions, features, and
capabilities that the system must possess in order to satisfy the user's
requirements.
In one sentence “What the system should do.”
 This is the list of the actual services which a system will provide.
 This is the list of the services/Functions which a user wants from
the software.
Example:
 Features of software which the client demands.
 Business rules of the particular organization for which
developing software.

Functional requirements are typically written in a structured and

specific way, using clear and concise language. They should be
measurable, so that they can be tested and validated to ensure that they
have been implemented correctly. Examples of functional requirements
include:
1. User authentication: The system must allow users to log in using
their credentials and authenticate their identity.
2. Search functionality: The system must allow users to search for
information based on specific criteria.
3. Data entry and manipulation: The system must allow users to
input, edit, and delete data as necessary.
 4. Reporting and analytics: The system must provide users with the
ability to generate reports and analyze data to make informed
decisions.
5. Integration with third-party systems: The system must be able to
integrate with external systems to exchange data and information.
Functional requirements are an important part of the software
development process and serve as a basis for testing and validation.
They provide a clear and concise description of what the system must
be able to do, and help ensure that the end product meets the needs of
the users.
Non-Functional Requirements
Non-functional requirements are a set of specifications that describe
the qualities or characteristics of a system, product, or service, rather
than its specific functions. These requirements specify the overall
behavior, performance, and quality characteristics that the system
must possess in order to meet the needs of its users. Non-functional
requirements are often referred to as "quality attributes" or "quality
requirements." Unlike functional requirements, which describe what a
system must be able to do, non-functional requirements describe how
well it must be able to do it.

Examples of non-functional requirements include:

1. Performance: The system must be able to process a certain
number of transactions per second or meet a specific response
time.
2. Scalability: The system must be able to handle increased loads
without significant degradation in performance.
3. Availability: The system must be available for use during
specified hours of operation.
4. Security: The system must be secure and protect user data from
unauthorized access.
 5. Usability: The system must be user-friendly and easy to learn
and use.
6. Reliability: The system must be reliable and operate correctly
without failure.
7. Maintainability: The system must be easy to maintain and
update.
Non-functional requirements are just as important as functional
requirements in ensuring that the system meets the needs of its users.
They help to ensure that the system is reliable, secure, and easy to use,
and can have a significant impact on the overall user experience.
The requirements engineering process typically consists of the
following activities:

1. Elicitation: This involves identifying and gathering requirements

from stakeholders, including users, customers, and other
members of the development team. Techniques such as
interviews, surveys, and workshops may be used to elicit
requirements.

2. Analysis: Once the requirements have been gathered, they need

to be analysed to ensure that they are complete, consistent, and
feasible. This may involve identifying conflicts or ambiguities in
the requirements and resolving them.

3. Specification: The requirements need to be documented in a clear

and concise manner. This may involve creating use cases, user
stories, or other types of requirements documents.

4. Validation: The requirements need to be validated to ensure that

they meet the needs of stakeholders, are complete and consistent,
 and can be implemented within the constraints of the system.
Techniques such as prototyping, simulation, and testing may be
used to validate the requirements.

5. Management: Throughout the development process, changes to

the requirements may occur. It is important to track these
changes, ensure that they are properly prioritized, and
communicate them to stakeholders.

Effective requirements engineering involves close collaboration

between developers, stakeholders, and users. It is an iterative process
that may involve revisiting earlier activities as new information is
gathered or changes occur. By following a well-defined requirements
engineering process, developers can ensure that they deliver software
that meets the needs of stakeholders and users. And be delivered on
time and within budget.

Requirements elicitation

Requirements elicitation is the process of identifying and gathering the

requirements of a system or software application from stakeholders,
including users, customers, and other members of the development
team. The goal of requirements elicitation is to ensure that all relevant
requirements are identified and documented in a clear and concise
manner.
The following are some common techniques used for requirements
elicitation:
 1. Interviews: One-on-one meetings with stakeholders to discuss
their needs and expectations.
2. Surveys: Questionnaires that are distributed to stakeholders to
gather information about their requirements.
3. Workshops: Group sessions that allow stakeholders to collaborate
and discuss their requirements.
4. Observation: Watching users perform tasks to identify their
requirements.
5. Prototyping: Creating mock-ups or prototypes to gather feedback
from stakeholders.
6. Document analysis: Reviewing existing documents, such as user
manuals, to identify requirements.
7. Brainstorming: A group technique where stakeholders generate
ideas and requirements.
8. Focus groups: Group sessions where stakeholders discuss their
requirements and provide feedback on prototypes or mock-ups.
Requirements elicitation is an iterative process, and it may be necessary
to revisit earlier stages as new information is gathered or changes occur.
It is important to involve stakeholders throughout the process to ensure
that their needs and expectations are understood and incorporated into
the final requirements.
Requirements specification
Requirements specification is the process of documenting the
requirements of a system or software application in a clear and concise
manner. The goal of requirements specification is to provide a
comprehensive and unambiguous description of what the system or
application should do and how it should behave.
The following are some common techniques used for requirements
specification:
1. Use cases: Use cases describe the interactions between users and
the system or application, including the actions that the system or
application should take.
 2. User stories: User stories provide a high-level description of a
user's needs or goals, and how the system or application should
fulfil those needs or goals.
3. Functional requirements: Functional requirements describe the
specific functions or features that the system or application
should provide.
4. Non-functional requirements: Non-functional requirements
describe the characteristics that the system or application should
have, such as performance, security, or scalability.
5. Data requirements: Data requirements describe the data that the
system or application should process, store, or transmit.
6. Business rules: Business rules describe the policies or procedures
that the system or application should follow.
7. Constraints: Constraints describe any limitations or restrictions
on the system or application, such as technology, budget, or
schedule.
Effective requirements specification involves creating clear, concise,
and unambiguous requirements documents that can be easily
understood by stakeholders and development team members. It also
involves ensuring that the requirements are complete, consistent, and
traceable, and that they meet the needs of stakeholders and users.
Requirements specification is an iterative process that may require
revisiting earlier activities as new information is gathered or changes
occur.
Requirements validation
Requirements validation is the process of checking that the
requirements of a system or software application are complete,
consistent, and can be implemented within the constraints of the
system. The goal of requirements validation is to ensure that the
requirements are accurate and meet the needs of stakeholders and users.
The following are some common techniques used for requirements
validation:
 1. Prototyping: Creating early versions of the system or application
to gather feedback from stakeholders and validate the
requirements.
2. Simulation: Creating models of the system or application to test
the requirements and identify any potential issues.
3. Testing: Conducting tests to ensure that the system or application
meets the requirements, and that any defects or issues are
identified and addressed.
4. Peer reviews: Having other members of the development team
review the requirements to identify any potential issues or areas
for improvement.
5. Walkthroughs: A walkthrough is a step-by-step review of the
requirements with stakeholders and team members to identify any
issues or ambiguities.
Effective requirements validation involves ensuring that the
requirements are complete, consistent, and traceable, and that they can
be implemented within the constraints of the system. It also involves
actively seeking feedback from stakeholders and team members

Requirements change
Requirements change refers to a situation where the requirements for a
project or product change during the development process. This can
occur for a variety of reasons, such as a change in the project scope,
new information becoming available, or changes in the market or
business environment.
When requirements change, it can have a significant impact on the
project timeline, budget, and deliverables. It may require additional
resources, rework, or changes to the overall project plan. Therefore, it's
important to manage requirements changes effectively to minimize
their impact on the project.
Managing requirements change typically involves a formal change
control process, where proposed changes are evaluated for their impact
on the project and approved or rejected based on their feasibility and
impact on the project objectives. This process helps to ensure that
changes are properly documented and communicated to all relevant
stakeholders, and that they are implemented in a controlled and
managed way.