Scribd
Upload
19 views3 pages

MODULE 2 Sepm Vansh

The document outlines the process of Requirements Elicitation, detailing methods such as interviewing and observation, along with challenges faced like conflicting stakeholder requirements and changing needs. It describes steps in requirements discovery, classification, prioritization, and documentation, using the example of a food delivery app to illustrate each step. The goal is to gather, organize, and finalize requirements to guide system development effectively.

Uploaded by

Vansh negi
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
19 views3 pages

MODULE 2 Sepm Vansh

The document outlines the process of Requirements Elicitation, detailing methods such as interviewing and observation, along with challenges faced like conflicting stakeholder requirements and changing needs. It describes steps in requirements discovery, classification, prioritization, and documentation, using the example of a food delivery app to illustrate each step. The goal is to gather, organize, and finalize requirements to guide system development effectively.

Uploaded by

Vansh negi
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 3

MODULE 2

Requirements Elicitation is done through

1. Interviewing: The RE team puts questions to stakeholders about the system that they use and the
system to be developed. There are two types of interviews:

Closed interviews where a pre-defined set of questions are answered.

Open interviews where there is no pre-defined agenda and a range of issues are explored with
stakeholders.

Normally a mix of closed and open-ended interviewing is good for getting an overall understanding
of what stakeholders do & how they interact with the system. This method is not good for
understanding domain requirements

2. Observation & study: Observation (in-situ): The RE team observes the manual process in action,
in-situ and infers required information. This is good for process oriented systems. Minimal
disturbance to user staff.

Study- Additional information is gathered from study of documents, forms manuals , rulebooks and
other artifacts used by the actors of the system . =

Problems with Requirement Elicitation

1. Stakeholders don‟t know what they really want.

2. Stakeholders express requirements in their own terms.

3. Different stakeholders may have conflicting requirements.

4. Organisational and political factors may influence the system requirements.

5. The requirements change during the analysis process

6. New stakeholders may emerge and the business environment change

1. Requirements Discovery and Understanding:

 What happens: You talk to people (like users, managers, or business owners) to figure out
what they want from the system.

 How it works: You ask questions, hold meetings, or study existing documents to understand
their needs.

 Example: Imagine you’re building a food delivery app. You talk to customers who want fast
delivery, restaurant owners who want easy order management, and delivery drivers who
want clear navigation. You gather all these needs.

2. Requirements Classification and Organization:


 What happens: The requirements you collect might be messy or scattered. You organize
them into groups.

 How it works: You group similar requirements together to make them easier to understand
and manage.

 Example: For the food delivery app, you might group requirements like:

o Customer needs: Fast delivery, easy payment options.

o Restaurant needs: Simple order tracking, menu updates.

o Driver needs: Real-time navigation, earnings tracking.

3. Requirements Prioritization and Negotiation:

 What happens: When multiple stakeholders are involved , requirements conflict. Different
people might want different things, and some requirements may conflict. You decide what’s
most important and find a middle ground.

 How it works: You discuss with stakeholders and agree on compromises.

 Example: Customers might want 24/7 delivery, but restaurants may only want to operate
during certain hours. You negotiate and decide on a delivery window that works for both
(e.g., 8 AM to 10 PM).

4. Requirements Documentation:

 What happens: You write down all the final requirements in a clear and organized way.

 How it works: This document becomes the guide for developers, testers, and stakeholders to
build the system.

 Example: For the food delivery app, you create a document that lists:

o Customers can track their orders in real-time.

o Restaurants can update their menus daily.

o Drivers can see the fastest routes.

You might also like