Chapter 3: Requirements Elicitation

1.1. An overview of requirements elicitation

Business analysts conduct requirements elicitation to identify the business need, scope, assumptions, and risks of
a project based on data from key stakeholders

Requirements elicitation is the process of gathering and defining the requirements for a software system. The
goal of requirements elicitation is to ensure that the software development process is based on a clear and
comprehensive understanding of the customer’s needs and requirements.

Requirements elicitation is perhaps the most difficult, most error-prone, and most communication-intensive
software development.

Requirements elicitation involves the identification, collection, analysis, and refinement of the requirements for
a software system. It is a critical part of the software development life cycle and is typically performed at the
beginning of the project.

Requirements elicitation involves stakeholders from different areas of the organization, including business
owners, end-users, and technical experts. The output of the requirements elicitation process is a set of clear,
concise, and well-defined requirements that serve as the basis for the design and development of the software
system.

The requirements elicitation and analysis has 4 main process

1
Features of Requirements Elicitation:
1. Stakeholder engagement: Requirements elicitation involves engaging with stakeholders such as
customers, end-users, project sponsors, and subject-matter experts to understand their needs and
requirements.
2. Gathering information: Requirements elicitation involves gathering information about the system to be
developed, the business processes it will support, and the end-users who will be using it.
3. Requirement prioritization: Requirements elicitation involves prioritizing requirements based on their
importance to the project’s success.
4. Requirements documentation: Requirements elicitation involves documenting the requirements in a clear
and concise manner so that they can be easily understood and communicated to the development team.
5. Validation and verification: Requirements elicitation involves validating and verifying the requirements
with the stakeholders to ensure that they accurately represent their needs and requirements.
6. Iterative process: Requirements elicitation is an iterative process that involves continuously refining and
updating the requirements based on feedback from stakeholders.
7. Communication and collaboration: Requirements elicitation involves effective communication and
collaboration with stakeholders, project team members, and other relevant parties to ensure that the
requirements are clearly understood and implemented.
8. Flexibility: Requirements elicitation requires flexibility to adapt to changing requirements, stakeholder
needs, and project constraints.

Advantages of Requirements Elicitation:

1. Clear requirements: Helps to clarify and refine customer requirements.
2. Improves communication: Improves communication and collaboration between stakeholders.
3. Results in good quality software: Increases the chances of developing a software system that meets
customer needs.
4. Avoids misunderstandings: Avoids misunderstandings and helps to manage expectations.
5. Supports the identification of potential risks: Supports the identification of potential risks and problems
early in the development cycle.
6. Facilitates development of accurate plan: Facilitates the development of a comprehensive and accurate
project plan.
7. Increases user confidence: Increases user and stakeholder confidence in the software development
process.
8. Supports identification of new business opportunities: Supports the identification of new business
opportunities and revenue streams.
Disadvantages of Requirements Elicitation:
1. Time consuming: Can be time-consuming and expensive.
2. Skills required: Requires specialized skills and expertise.
3. Impacted by changing requirements: May be impacted by changing business needs and requirements.
4. Impacted by other factors: Can be impacted by political and organizational factors.

2
5. Lack of commitment from stakeholders: Can result in a lack of buy-in and commitment from
stakeholders.
6. Impacted by conflicting priorities: Can be impacted by conflicting priorities and competing interests.
7. Sometimes inaccurate requirements: May result in incomplete or inaccurate requirements if not properly
managed.
8. Increased development cost: Can lead to increased development costs and decreased efficiency if
requirements are not well-defined.

Steps of Requirements Elicitation:

1. Identify all the stakeholders, e.g., Users, developers, customers etc.
2. List out all requirements from customer.
3. A value indicating degree of importance is assigned to each requirement.
4. In the end the final list of requirements is categorized as:

 It is possible to achieve.
 It should be deferred and the reason for it.
 It is impossible to achieve and should be dropped off.

The two questions are answered during requirements elicitation and analysis
• Requirements elicitation: Definition of the system in terms understood by the customer (―Requirements
specification‖)
• Analysis:
Definition of the system in terms understood by the developer (Technical specification, ―Analysis model‖)
• Requirements Process: Contains the activities Requirements Elicitation and Analysis.

Requirements Elicitation: Activities

• ¨ Identify actors
• ¨ Identify scenarios
• ¨ Identify use cases
• ¨ Identify relationships among use cases
• ¨ Refine use cases
• ¨ Identify nonfunctional requirements
• ¨ Identify participating objects

Types of Requirements
 Functional requirements: Interactions between the system and its environment independent from
implementation
 Nonfunctional requirements: User visible aspects of the system not directly related to functional
behavior.
 Constraints (―Pseudo requirements‖): Imposed by the client or the environment in which the system will
operate

3
Requirements Validation
It is a critical step in the development process, usually after requirements engineering or requirements analysis.
Requirements validation criteria are:
 Correctness: The requirements represent the client’s view.
 Completeness: All possible scenarios through the system are described, including exceptional behavior
by the user or the system
 Consistency: There are functional or nonfunctional requirements that contradict each other
 Clarity: There are no ambiguities in the requirements.
 Realism: Requirements can be implemented and delivered
 Traceability: Each system function can be traced to a corresponding set of functional requirements

What is usually not in the Requirements?

 System structure, implementation technology
 Development methodology
 Development environment
 Implementation language
 Reusability

There are five main steps to the requirements elicitation process:

1. Gathering requirements:

An effective way to prepare for requirements elicitation is for business analysts to gather all available
requirements and study them for insights. A few techniques for requirements gathering include:

 Document analysis, such as studying process models or researching regulations.

 Analyzing system interfaces and business rules.
 Reading available user feedback.

The findings from requirements gathering can help identify key stakeholders and inform which requirements
elicitation techniques might best suit the project. Business analysts can then begin the work of drawing out the
enlightening experiences that fill in the missing requirements. Therefore, a requirement gathering is the perfect
first step in the process of requirements elicitation.

2. Identifying key stakeholders

Requirements gathering can provide insight on relevant stakeholders. It is important to identify the right people
up front so everyone can begin on the same page. Doing so eliminates the need to fill in missing requirements
later that could potentially change the course of the project.

3. Eliciting requirements from key stakeholders

In this part of the process, business analysts need to determine which requirement elicitation techniques will
provide the best results given the project at hand and appropriate stakeholders.

4
There are a variety of requirement elicitation techniques; here are some of the most popular methods:

Brainstorming –
Use case: Current solutions may not be innovative enough to meet the project’s goal.
Designed to: Uncover new, innovative ideas and solutions.
How to: Assemble a mix of key stakeholders for an open conversation on innovative ideas and solutions. As
facilitator, the business analyst ensures that the conversation stays on topic and records ideas discussed.
Focus groups –
Use case: Business analysts need more information about specific aspects of the project. Time is short.
Designed to: Help stakeholders be more forthcoming and articulate solutions. Get a lot of information at once.
How to: Gather representatives from stakeholder groups. The facilitator asks questions to get team members to
discuss specific areas of interest and records ideas discussed.
Interviews –
Use case: Get an in-depth perspective from a specific subject matter expert (SME).
Designed to: Obtain a stakeholder’s one-on-one insight on the business need or viability of given solutions.
How to: Create questions that will allow the SME to be open about the issues on the table. Questions can be
shared in advance or be conducted as a conversation. The interviewer should take notes and share them with the
SME to ensure he or she correctly understood the SME’s point of view.
Observation –
Use case: When the development project is an augmentation of a current work process.
Designed to: Provide a direct view of how a stakeholder performs a particular process.
How to: Observation can be conducted passively—the facilitator watches the stakeholder work without
interrupting—or actively—the facilitator asks questions about the work as it is being performed. In both cases, the
facilitator should take notes and get feedback from the stakeholder on the information collected.
Prototyping –
Use case: When stakeholders do not understand written technical requirements and would benefit from seeing a
version of the product.
Designed to: Collect feedback from non-technical stakeholders by showing them an example with which they can
physically interact.
How to: At first prototyping can be executed via storyboard, interactive screen, virtual mock-up, navigation flow,
etc. The exact method depends on the project, but it is usually an iterative process that is improved based on
input. As more requirements come forward, more detailed prototypes are created to ensure they meet the
expectations as recorded.
Requirements workshops –
Use case: When time is short, and the business need is not clear.
Designed to: Get the stakeholders together in a structured, time-based setting to elicit, refine, and edit
requirements. Stakeholders can discuss and provide immediate input on identified business needs.
How to: Set a specific timeframe and agenda for the workshop. Include brainstorming, focus group, and
prototyping (if applicable) opportunities within the schedule. Use these to guide the discussion and record input.
Surveys –
Use case: When business analysts need data from large groups of participants.
Designed to: Obtain objective feedback from large groups of customers or end-users.

5
How to: Choose participants wisely based on desired criteria. Create clear questions that do not lead the
respondents. Questions can have a number of finite choices or be open-ended—for best results consider the goal
of the question, as well as the number of respondents, to determine the best structure for proper analysis.

4. Documenting requirements elicitation:

There are a variety of formats for documenting requirements: a home-grown product requirements document
(PRD), a government-mandated system requirements specification, a requirements management tool like Jama
Connect, a spreadsheet, etc. The best tool for documenting requirements depends on the project. If the project
has many stakeholders, complex development, or compliance or functional safety standards, it’s a best practice
to choose a requirements management tool like Jama Connect. These are purpose-built to mitigate risks
associated with complex systems and regulatory compliance. Assessing needs and researching functionality
will help determine the best option for the project

5. Confirming the findings

Once business analysts document the requirements, it is time to make sure they are recorded correctly.
Requirements are sent to all stakeholders to review so there is a collective understanding of what’s being
developed. Stakeholders are likely to make refinements. It is also possible that this step elicits further
requirements, which will necessitate revisions before approval can take place.

Business analysts conduct the process of requirements elicitation at the beginning of a project, and the process is
ongoing throughout the development process. This is because change is always occurring and it’s never possible
to know all the questions to ask or have all the correct answers upfront.

Challenges of successful requirement elicitation

The elicitation process may seem easy: ask the stakeholders what they want. However, it’s a much more rigorous
endeavor. Here are some of the most common challenges of the requirements elicitation process.

Finding the right stakeholders – Identifying the correct subject matter experts isn’t always easy. Hunt down
―hidden‖ stakeholders who can be excellent sources of knowledge. Examples include customer-facing personnel
like sales/support reps and maintenance techs.
Uncovering the best insights – Unfortunately, stakeholders don’t always know what they want. In the practice of
requirements elicitation, multiple elicitation methods can be used concurrently to identify the business need and
an optimal list of requirements. The expertise is in realizing the best combination of techniques to yield success
for that development project.
Documenting the requirements – Using the wrong documentation tool for the job can be detrimental. Issues can
arise with everything from reviews and approvals to managing change. Spreadsheets or home-grown PRDs may
work for smaller, non-regulated projects. Complex products or those in regulated industries, on the other hand,
greatly benefit from requirements management software that can streamline requirements elicitation and the
overall process with features like live traceability and compliance management.
Planning for change – Priorities shift and problems arise—it’s best to plan for changes up front. Be sure to have
a process in place that allows time to address problems, document changes, and add new requirements, and
conduct additional reviews.