Requirements Engineering is the process of identifying, eliciting, analyzing, specifying, validating, and

managing the needs and expectations of stakeholders for a software system.

What is Requirements Engineering?
A systematic and strict approach to the definition, creation, and verification of requirements for a software
system is known as requirements engineering. To guarantee the effective creation of a software product, the
requirements engineering process entails several tasks that help in understanding, recording, and managing
the demands of stakeholders.
Requirements Engineering Process

Requirements Engineering Process

1. Feasibility Study
2. Requirements elicitation
3. Requirements specification
4. Requirements for verification and validation
5. Requirements management
Tools Involved in Requirement Engineering
 Observation report
 Questionnaire ( survey, poll )
 Use cases
 User stories
 Requirement workshop
 Mind mapping
 Roleplaying
 Prototyping
Advantages of Requirements Engineering Process
 Helps ensure that the software being developed meets the needs and expectations of the
stakeholders
 Can help identify potential issues or problems early in the development process, allowing for
adjustments to be made before significant
 Helps ensure that the software is developed in a cost-effective and efficient manner
 Can improve communication and collaboration between the development team and stakeholders
 Helps to ensure that the software system meets the needs of all stakeholders.
 Provides an unambiguous description of the requirements, which helps to reduce
misunderstandings and errors.
 Helps to identify potential conflicts and contradictions in the requirements, which can be
resolved before the software development process begins.
 Helps to ensure that the software system is delivered on time, within budget, and to the required
quality standards.
 Provides a solid foundation for the development process, which helps to reduce the risk of
failure.
Disadvantages of Requirements Engineering Process
 Can be time-consuming and costly, particularly if the requirements-gathering process is not well-
managed
 Can be difficult to ensure that all stakeholders’ needs and expectations are taken into account
  It Can be challenging to ensure that the requirements are clear, consistent, and complete
 Changes in requirements can lead to delays and increased costs in the development process.
 As a best practice, Requirements engineering should be flexible, adaptable, and should be
aligned with the overall project goals.
 It can be time-consuming and expensive, especially if the requirements are complex.
 It can be difficult to elicit requirements from stakeholders who have different needs and
priorities.
 Requirements may change over time, which can result in delays and additional costs.
 There may be conflicts between stakeholders, which can be difficult to resolve.
 It may be challenging to ensure that all stakeholders understand and agree on the requirements.

Requirement Gathering:

What is Requirements Gathering?

Requirements gathering is a crucial phase in the software development life cycle (SDLC) and project
management. It involves collecting, documenting, and managing the requirements that define the features and
functionalities of a system or application. The success of a project often depends on the accuracy and
completeness of the gathered requirements in software.
Requirements Gathering Subprocesses:
Requirements gathering is a critical phase in the software development lifecycle, and it involves several
subprocesses to ensure a comprehensive understanding of the project’s needs. The main subprocesses include:
Stakeholder Identification:
 Objective: Identify all stakeholders who will be affected by the system, directly or indirectly.
 Process: Conduct interviews, surveys, or workshops to determine the key individuals or groups
involved.
Stakeholder Analysis:
 Objective: Understand the needs, expectations, and influence of each stakeholder.
 Process: Analyze stakeholder inputs to prioritize requirements and manage conflicting interests.
Problem Definition:
 Objective: Clearly define the problems or opportunities that the software system aims to address.
 Process: Engage stakeholders in discussions to uncover and articulate the core problems or
opportunities.
Requirements Extraction:
 Objective: Gather detailed requirements by interacting with stakeholders.
 Process: Employ techniques such as interviews, surveys, observations, or brainstorming sessions to
extract requirements.
Requirements Documentation:
 Objective: Document gathered requirements in a structured format.
 Process: Create requirements documents, use cases, user stories, or prototypes to capture and
communicate requirements effectively.
Validation and Verification:
 Objective: Ensure that gathered requirements are accurate, complete, and consistent.
  Process: Conduct reviews, walkthroughs, or use validation tools to verify that the requirements meet
the defined criteria.
Processes of Requirements Gathering in Software Development:
There are 6 steps crucial for requirement gathering processes

Processes of Requirements Gathering in Software Development

Step 1- Assigning roles:
 The first step is to identify and engage with all relevant stakeholders. Stakeholders can include end-
users, clients, project managers, subject matter experts, and anyone else who has a vested interest in
the software project. Understanding their perspectives is essential for capturing diverse requirements.
Step 2- Define Project Scope:
 Clearly define the scope of the project by outlining its objectives, boundaries, and limitations. This
step helps in establishing a common understanding of what the software is expected to achieve and
what functionalities it should include.
Step 3- Conduct Stakeholder Interviews:
 Schedule interviews with key stakeholders to gather information about their needs, preferences, and
expectations. Through open-ended questions and discussions, aim to uncover both explicit and implicit
requirements. These interviews provide valuable insights that contribute to a more holistic
understanding of the project.
Step 4- Document Requirements:
 Systematically document the gathered requirements. This documentation can take various forms, such
as user stories, use cases, or formal specifications. Clearly articulate functional requirements (what the
system should do) and non-functional requirements (qualities the system should have, such as
performance or security).
Step 5- Verify and Validate Requirements:
 Once the requirements are documented, it’s crucial to verify and validate them. Verification ensures
that the requirements align with the stakeholders’ intentions, while validation ensures that the
documented requirements will meet the project’s goals. This step often involves feedback loops and
discussions with stakeholders to refine and clarify requirements.
Step 6- Prioritize Requirements:
  Prioritize the requirements based on their importance to the project goals and constraints. This step
helps in creating a roadmap for development, guiding the team on which features to prioritize.
Prioritization is essential, especially when resources and time are limited.
Requirement Gathering Techniques:
Effective requirement gathering is essential for the success of a software development project. Various
techniques are employed to collect, analyze, and document requirements.

Requirements Gathering Techniques

Here are some commonly used requirement gathering techniques:
1. Interviews:
 Conducting one-on-one or group interviews with stakeholders, including end-users, clients, and
subject matter experts. This allows for direct interaction to gather detailed information about
their needs, expectations, and concerns.
2. Surveys and Questionnaires:
 Distributing surveys and questionnaires to a broad audience to collect information on a larger
scale. This technique is useful for gathering feedback from a diverse set of stakeholders and
can be particularly effective in large projects.
3. Workshops:
 Organizing facilitated group sessions or workshops where stakeholders come together to
discuss and define requirements. Workshops encourage collaboration, idea generation, and the
resolution of conflicting viewpoints in a structured environment.
4. Observation:
 Directly observing end-users in their work environment to understand their workflows, pain
points, and preferences. Observational techniques help in uncovering implicit requirements that
users might not explicitly state.
5. Prototyping:
 Creating mockups or prototypes of the software to provide stakeholders with a tangible
representation of the proposed system. Prototyping allows for early visualization and feedback,
helping to refine requirements based on stakeholders’ reactions.
 6. Use Cases and Scenarios:
 Developing use cases and scenarios to describe how the system will be used in different
situations. This technique helps in understanding the interactions between users and the system,
making it easier to identify and document functional requirements.
7. Document Analysis:
 Reviewing existing documentation, such as business process manuals, reports, and forms, to
extract relevant information. This technique provides insights into the current processes and
helps identify areas for improvement.
Why Requirement Gathering is important?
Requirement gathering holds immense importance in software development for several critical reasons:
1. Clarity of Project Objectives:
 Requirement gathering sets the stage by defining and clarifying the objectives of the software
project. It ensures that all stakeholders, including clients, users, and development teams, have a
shared understanding of what needs to be achieved.
2. Customer Satisfaction:
 Understanding and meeting customer needs is paramount for customer satisfaction.
Requirement gathering allows developers to comprehend the expectations of end-users and
clients, leading to the creation of a product that aligns with their desires and requirements.
3. Scope Definition:
 Clearly defined requirements help in establishing the scope of the project. This delineation is
crucial for managing expectations, avoiding scope creep (uncontrolled changes to project
scope), and ensuring that the project stays on track.
4. Reduced Misunderstandings:
 Ambiguities and misunderstandings are common sources of project failures. Requirement
gathering facilitates clear communication between stakeholders, reducing the risk of
misinterpretations and ensuring that everyone involved is on the same page.
5. Risk Mitigation:
 Identifying and addressing potential issues at the requirements stage helps mitigate risks early
in the development process. This proactive approach minimizes the chances of costly errors,
rework, and delays later in the project life cycle.
Benefits of Requirements Gathering:
The benefits of effective requirements gathering in software development include:
 Cost Reduction: One of the primary benefits of effective requirements gathering is cost reduction.
When requirements are well-defined and thoroughly understood at the beginning of a project, it
minimizes the likelihood of costly changes and rework later in the development process.
 Customer Satisfaction: Clear and accurate requirements gathering directly contributes to customer
satisfaction. When the end product aligns closely with the expectations and needs of the stakeholders,
it enhances user experience and meets customer demands. This satisfaction is not only vital for the
success of the current project but also contributes to positive relationships between the development
team and clients, fostering trust and potential future collaborations.
  Improved Communication: Requirements gathering serves as a communication bridge between
various stakeholders involved in a project, including developers, clients, users, and project managers.
Miscommunication is a common source of project failures and delays. By clearly documenting and
understanding requirements, the development team ensures that everyone involved has a shared vision
of the project objectives, functionalities, and constraints.
 Efficient Resource Utilization: Thorough requirements gathering enables the efficient allocation and
utilization of resources. Resources, including time, manpower, and technology, are finite and valuable.
When requirements are well-defined, project teams can allocate resources more accurately, avoiding
unnecessary expenditures or overcommitting resources to certain aspects of the project.
 Enhanced Quality: Well-documented requirements serve as the foundation for quality assurance
throughout the development process. When the project team has a clear understanding of what needs to
be achieved, they can establish quality standards and criteria from the outset. This clarity enables the
implementation of effective testing strategies, ensuring that each aspect of the system is thoroughly
evaluated against the specified requirements.
 Risk Management: Requirements gathering is a crucial component of effective risk management. By
identifying potential risks early in the project, stakeholders can proactively address ambiguities,
conflicting requirements, and other challenges that could pose a threat to the project’s success.
 Accurate Planning: Accurate project planning is dependent on a clear understanding of project
requirements. When requirements are well-documented, project managers can create realistic
schedules, milestones, and deliverables. This accurate planning is crucial for setting expectations,
managing stakeholder timelines, and ensuring that the project progresses according to the established
timeline.

Feasibility Study:
Feasibility is the practical extent to which a project can be performed successfully.
To evaluate feasibility, a feasibility study is performed, which determines whether the solution considered to
accomplish the requirements is practical and workable in the software.
Information such as resource availability, cost estimation for software development, benefits of the software to
the organization after it is developed and cost to be Incurred on its maintenance are considered during the
feasibility study.
The objective/goal of the feasibility study is to establish the reasons for developing the software that is
acceptable to users, adaptable to change and conformable to established standards. Various other
objectives/goals of feasibility study are listed below.
1. To analyze whether the software will meet organizational requirements.
2. To determine whether the software can be implemented using the current technology and within the
specified budget and schedule.
3. To determine whether the software can be integrated with other existing software.
Types of Feasibility:
Various types of feasibility that are commonly considered are: Technical Feasibility, Operational Feasibility,
and Economic Feasibility as shown in following figure-

1. Technical Feasibility:

Technical feasibility refers, "to the technical resources needed to develop, purchase, install, or operate the
system".
Technical feasibility assesses the current resources (such as hardware and software) and technology, which are
required to accomplish user requirements in the software within the allocated time and budget.
For this, the software development team determines whether the current resources and technology can be
upgraded or added in the software to accomplish specified user requirements.
Technical feasibility also performs the following tasks:
(i) Analyzes the technical skills and capabilities of the software development team members.
(ii) Determines whether the relevant technology is steady and established.
(iii) Ascertains that the technology chosen for software development has a large number of users so that they
can be consulted when problems arise or improvements are required.
2. Operational Feasibility:
Operational feasibility means that, "a proposed system will be used effectively after it has been developed".
It assesses the extent to which the required software performs a series of steps to solve business problems and
user requirements.
This type feasibility is dependent on human resources (software development team) and involves visualizing
whether the software will operate after it is developed and be operative once it is installed.
Operational feasibility also performs the following tasks:
(i) Determines whether the problems anticipated in user requirements are of high priority.
(ii) Determines whether the solution suggested by the software development team is
acceptable.
(iii) Analyzes whether users will adapt to new software.
(iv) Determines whether the organization is satisfied by the alternative solutions proposed by the software
development team.

3. Economic Feasibility:
It determines whether the required software is capable of generating financial gains for an organization.
It involves the cost incurred on the software development team, estimated cost of hardware and software, cost
of performing feasibility study, and so on.
For this, it is essential to consider expenses made on purchases (such as hardware purchase) and activities
required to carry out software development. In addition, it is necessary to consider the benefits that can be
achieved by developing the software.
Software is said to be economically feasible if it focuses on the issues listed below:
(i) Cost incurred on software development to produce long-term gains for an organization.
(ii) Cost required to conduct full software investigation (such as requirements elicitation and requirements
analysis).
(iii) Cost of hardware, software, development team, and training.

Fact Finding Techniques:

To study any system the analyst needs to do collect facts and all relevant information. the facts
when expressed in quantitative form are termed as data. The success of any project is
depended upon the accuracy of available data. Accurate information can be collected with help
of certain methods/ techniques. These specific methods for finding information of the system
are termed as fact finding techniques. Interview, Questionnaire, Record View and
Observations are the different fact finding techniques used by the analyst. The analyst may use
more than one technique for investigation.
Fact finding is the formal process of using research, interviews, questionnaires, and other
techniques to collect information about systems, requirements, and preferences.
It is also called as Information Gathering or Data Collection.

1. Interview:-
Interview is the best method for producing qualitative information such as opinions. polices,
subjective descriptions of activities and problems.

Interviews are strong medium to collect requirements from individuals or from group.

In this method, the analyst sits face to face with the people and records their responses.

During the interview, the respondents and analyst discuss with each other.

This method use to find the area of misunderstanding, unrealistic expectations.

Using question-answer format, analyst collects the general information about the system.

The information collected is quite accurate and reliable as the interviewer can clear and cross
check the doubts there itself.

Types of Interviews:
There are main two types of interviews i.e. Structured and Unstructured as explained below:

1. Structured (Closed) Interviews: In this type, every single information to gather is decided in
advance.

Advantages:
1. These interviews follow pattern and matter of discussion firmly.

2. Structured interview ensures uniform wording of questions for all respondents.

3. It is easy for analyst to evaluate.

4. It contains the set of prescribed answer, resultant into shorter interview.

5. For this interviewer required limited training.

Disadvantages:

1. Cost of preparation of uniform question is high.

2. High level of structure may not be suitable for all situations.

3. This interview reduces the respondent's spontaneity and ability of the interview to follow up
the comments of interviewee.

2. Unstructured (Open) Interview: In this type the information to gather is not decided in
advance, more flexible and less biased.

Advantage:

1. In Unstructured interviews, the respondents are free to answer in their own words. In this
way their views are not restricted. So the interviewer gets a larger area to further explore the
issues relating to a problem.

Disadvantages:

1. It may happen that the interview goes in some unwanted direction and the basic facts for
which the interview was organized do not get relieved

2. Analysis and interpretation of results may be lengthy.

3. It may take extra time to collect required facts.

Apart from these there are some more interview techniques like Oral interviews, Written
interviews etc.

The advantage of interviews is that the analyst has a free hand and he can extract almost all
the information from the respondents but it is a very time consuming method. He should also
employ other means such as questionnaires, record reviews, etc.
4.6.2 Questionnaires
It is the technique used to extract information from large number of people.

This technique can be adopted and used only by a skillful system analyst.

A document with pre-defined set of objective questions and respective options is handed over
to all customers to answer, which are collected and compiled.

Advantages:

1. The questionnaire contained the series of questions framed together in logical manner.
These questions are simple, clear and to the point

2. The questionnaire can send to people by email or by post.

3. This is the cheapest source of fact finding.

Disadvantage:

1. A drawback of this method is, if an option for some issue is not mentioned in the
questionnaire, the issue might be left unattended

Example: We can get basic information of students using following questionnaire.

Record View

Records and reports are the collection of information and data about the system and its
operations.

The information related to the system is available in documents, newspapers, magazines,

journals, electronic media etc.
This record review helps the analyst to get valuable information about the system and the
organization.

The analyst may examine the records either at the beginning of the study which may give him
a fair and perfect data about the system.
It is easy to understand the system with actual operations.

Example: Employee attendance record, Salary record, Service book can be observed by
analyst to know how to manage the requirements in the system.

4.6.4 Observation

Unlike the other fact finding techniques, in this method the team of experts visit the customer's
organization or workplace.

Analysts observe the actual working of the existing installed systems or manual system.

They observe the workflow of document at customer's end and how execution problems are
dealt.

The experts may observe the unwanted things from existing system as well and simply cause
delay in the development of the new system.
The experts team itself finds some conclusions which help to form requirementi expected from
the software.

SRS:
SOFTWARE REQUIREMENTS SPECIFICATION (SRS)

A software requirements specification (SRS) is a document that captures complete description about how the
system is expected to perform. The SRS needs to be correct, complete, consistent, updatable, verifiable etc. It
is usually signed off at the end of requirements engineering phase.

Characteristics of SRS:

Various characteristics of SRS are:

1. Correct: The SRS should be made up to date when appropriate requirements are identified.

2. Unambiguous: When the requirements are correctly understood then only it is possible to write an
unambiguous SRS.
3. Complete: To make the SRS complete, it should be specified what a software designer wants to create a
software.

4. Consistent: It should be consistent with reference to the functionalities identified.

5. Specific: The requirements should be mentioned specifically.

6. Traceable: What is the need for mentioned requirement? This should be correctly identified.

7.