ELICITING REQUIREMENTS

requirements gathering
problem solving, elaboration,
negotiation, and specification
• Collaborative Requirements Gathering
• Meetings (either real or virtual) are conducted and attended
by both software engineers and other stakeholders.

• • Rules for preparation and participation are established.

• • An agenda is suggested that is formal enough to cover all
important points but informal enough to encourage the free
flow of ideas.
• • A “facilitator” (can be a customer, a developer, or an
outsider) controls the meeting.
• • A “definition mechanism” (can be work sheets, flip
charts, or wall stickers or an electronic bulletin board, chat
room, or virtual forum) is used.
SafeHome project
• Objects described for SafeHome might include the
control panel, smoke detectors, window and door
sensors, motion detectors, an alarm, an event (a
sensor has been activated), a display, a PC,
telephone numbers, a telephone call, and so on.

• The list of services might include configuring the

system, setting the alarm, monitoring the
sensors, dialing the phone, programming the
control panel, and reading the display (note that
services act on objects)
• constraints (e.g., the system must recognize when
sensors are not operating, must be user friendly, must
interface directly to a standard phone line) and

• performance criteria (e.g., a sensor event should be

recognized within one second, and an event priority
scheme should be implemented).
Quality Function Deployment
• normal requirements identify the objectives and goals that are
stated for a product or system during meetings with the
customer. If these requirements are present, the customer is
satisfied.

• Expected requirements are implicit to the product or system

and may be so fundamental that the customer does not explicitly
state them. Their absence will be a cause for significant
dissatisfaction.

• Exciting requirements go beyond the customer’s expectations

and prove to be very satisfying when present.
Elicitation Work Products
• : (1) a statement of need and feasibility, (2) a bounded
statement of scope for the system or product, (3) a list
of customers, users, and other stakeholders who
participated in requirements elicitation, (4) a description
of the system’s technical environment, (5) a list of
requirements (preferably organized by function) and the
domain constraints that applies to each, (6) a set of
usage scenarios that provide insight into the use of the
system or product under different operating conditions,
and (7) any prototypes
Agile Requirements Elicitation
• Service-Oriented Methods
NEGOTIATING REQUIREMENTS
• “win-win” result.
• Identification of the system or subsystem’s key
stakeholders.
• 2. Determination of the stakeholders’ “win conditions.”
• 3. Negotiation of the stakeholders’ win conditions to
reconcile them into a set of win-win conditions for all
concerned (including the software team)
Validating requirements
• requirements gathered from stakeholders are clear,
complete, consistent, and aligned with the business goals.

• Why Validate Requirements?

• To ensure the final software meets the user's needs.
• To avoid costly changes during later stages of development.
• To confirm that the requirements are complete, clear,
consistent, and testable.
• To reduce misunderstandings between stakeholders and
developers.
Steps for Validating Requirements
• Requirements Reviews
• Definition: This is a structured meeting in which stakeholders, analysts,
designers, and developers review the requirements document.
• Purpose: To identify missing, unclear, ambiguous, or conflicting
requirements.
• Participants: Customers, Business Analysts, Developers, Testers, and
Project Managers.
• Outcome: Acceptance, Rejection, or Modification of requirements.
• 👉 Example:
• Reviewing the Functional and Non-functional requirements document
(SRS).
• Checking if there are any contradictions or unclear requirements.
• Prototyping
• Definition: Building a simplified version of the software to
demonstrate functionalities.
• Purpose: Helps stakeholders visualize the requirements and
confirm if they are captured correctly.
• Benefit: Reduces misunderstanding and helps refine
requirements.
• Outcome: Feedback from stakeholders.
• 👉 Example:
• Creating a prototype for an e-commerce website to verify the
checkout process.
• Model Validation
• Definition: Using models like Use Case Diagrams,
Data Flow Diagrams (DFD), ER Diagrams, etc. to
represent requirements.
• Purpose: Validate the correctness of models and
ensure they accurately capture user requirements.
• Outcome: Clarified and verified models.
• 👉 Example:
• Validating a Data Flow Diagram (DFD) to confirm if
the data flow is accurate.
• Test Case Generation
• Definition: Creating test cases based on the requirements to
check if the system behavior meets the specified requirements.
• Purpose: Ensures that requirements are clear, complete, and
testable.
• Outcome: Identified gaps in requirements.
• 👉 Example:
• Creating a test case like:
Test Case: User should be able to reset the password via email.
Expected Outcome: Email with reset link should be sent.
Software Requirement Specification
(SRS)
• describes the functional and non-functional
requirements of a software system.

• It acts as a blueprint or contract between the client

(who wants the software) and the development team
(who builds the software).
The SRS document outlines:

• What the software will do (functionality)?

• How the software will perform (performance,

constraints)?

• Who will use the software (users, stakeholders)?

• Under what conditions the software will operate

(environment, platform)?
Structure of an SRS Document (IEEE
830 Standard)
• 1. Introduction
• The introduction provides a high-level overview of the software
product and describes the purpose and scope of the project.
• 🔥 1.1 Purpose
• It defines why the software is being developed.
• Describes the intended use of the software.
• Specifies the target audience or users of the software.
• 👉 Example:
The purpose of this project is to develop an Online Food
Delivery System that allows users to order food online, make
payments, and track their orders in real-time.
• 1.2 Scope
• Describes the features and functionalities of the software.
• Defines the boundaries of the project (what is included and what is
not).
• Specifies the platform, devices, or environments where the software will
work.
• 👉 Example:
The Online Food Delivery System will provide functionalities like:
• User Registration & Login.
• Browse Restaurants and Menus.
• Place Orders and Payments.
• Real-time Order Tracking.
2. Overall Description
• 2.1 Product Perspective
• Describes whether the software is a standalone application,
a component of a larger system, or a web application.
• Defines how the product will interact with other software,
hardware, or APIs.
• 👉 Example:
The Online Food Delivery System is a web-based application
that will interact with:
• Payment Gateway (PayPal, Stripe)
• Google Maps API (for location services)
• SMS Gateway (for OTP Verification)
• 2.2 User Classes and Characteristics
• Defines different categories of users that will use the
system.
• Mention user skills, technical knowledge, and expected
behavior.
• 2.3 Assumptions and Dependencies
• Specifies any assumptions made during requirement
gathering.
• Lists external dependencies that the software may rely
on.
• 👉 Example:
• The system assumes the user has a stable internet
connection.
• The system relies on Google Maps API for order
tracking.
• 3. Functional Requirements
• This is the most important part of the SRS document. It lists the
functional features that the software must perform. It is often
represented as:
• ✅ 3.1 User Registration and Login
• Description:
The system shall allow users to register and login using valid
credentials.
• Functional Requirements:
• FR001: The system shall allow users to register with Name, Email,
and Password.
• FR002: The system shall verify the user email with OTP.
• 3.2 Place Order
• Description:
The system shall allow users to browse menus and
place orders.
• Functional Requirements:
• FR004: The system shall allow users to select items
from the menu.
• FR005: The system shall calculate the total price based
on the items selected.
• FR006: The system shall allow users to make payments.
• Conclusion
• The Software Requirement Specification (SRS)
document is one of the most critical documents in
software development. It serves as a clear and detailed
contract between stakeholders and the
development team. A well-prepared SRS ensures that:
• ✅ There are no ambiguities or conflicts in the
requirement.
• ✅ The project is delivered on time and meets user
expectations.
• ✅ It acts as a reference document during