Chapter 3: Requirements Elicitation

Introduction

Requirements elicitation is a critical phase in the software development lifecycle. It involves

gathering, analyzing, and documenting stakeholders' needs and expectations for a system. This
chapter discusses various techniques and approaches to effectively elicit requirements, ensuring
that the final product aligns with user expectations.

3.1 Importance of Requirements Elicitation

 Understanding User Needs: Clear requirements help in understanding what users expect
from the system.
 Reducing Risks: Early identification of requirements can mitigate risks related to project
scope, budget, and timelines.
 Guiding Development: Well-defined requirements serve as a roadmap for the
development team.

3.2 Requirements Elicitation Concepts

1. Types of Requirements

 Functional Requirements: Describe what the system should do, outlining specific
behaviors and functions.
 Non-Functional Requirements: Specify how the system performs its functions,
including performance metrics, usability, security, and reliability.

2. Stakeholder Identification

 Primary Stakeholders: Direct users of the system who interact with it regularly.
 Secondary Stakeholders: Individuals who support or are affected by the system
indirectly, such as managers or IT staff.
 Tertiary Stakeholders: Other interested parties who might influence the project, like
regulatory bodies or external partners.

3. Elicitation Techniques

 Interviews: One-on-one discussions to gather detailed insights.

 Surveys: Structured questionnaires to collect data from a broader audience.
 Workshops: Group sessions aimed at collaborative requirement gathering.
 Observation: Watching users in their natural environment to identify needs and
workflows.

4. Requirements Documentation
  User Stories: Simple descriptions of features from the user's perspective.
 Use Cases: Detailed scenarios that describe how users interact with the system.
 Requirements Specification: Formal documents that outline all gathered requirements.

5. Validation and Verification

 Validation: Ensuring that the requirements meet the needs of stakeholders.

 Verification: Checking that the requirements are feasible and can be implemented within
the project constraints.

6. Change Management

 Recognizing that requirements may evolve over time, establishing a process for
managing changes is crucial to maintain project alignment and scope.

3.2 Requirements Elicitation Concepts

3.2.1 Functional Requirements

Functional requirements define specific behaviors and functions that a system must exhibit. They
describe what the system should do, outlining the interactions between the system and its users
or other systems. These requirements are crucial for guiding the design and development
process.

Characteristics of Functional Requirements

 Specific: Clearly describe actions the system must perform.

 Measurable: Can be tested and validated against expected outcomes.
 User-Centric: Often framed from the perspective of the end-user's needs and tasks.

Examples

 User Authentication: The system must allow users to log in using a username and password.
 Data Entry: Users must be able to input and save information into specified fields.
 Reporting: The system should generate monthly sales reports in a PDF format.

3.2.2 Non-Functional and Pseudo Requirements

Non-Functional Requirements

Non-functional requirements specify criteria that judge the operation of a system, rather than
specific behaviors. They often relate to the quality attributes of the system and how well it
performs its functions.
Characteristics of Non-Functional Requirements

 Quality Attributes: Focus on aspects like performance, usability, reliability, and security.
 Constraints: Often impose restrictions on how functional requirements are implemented.

Examples

 Performance: The system must handle 500 concurrent users without performance degradation.
 Usability: The user interface should allow users to complete a task within three clicks.
 Security: All data transmissions must be encrypted using industry-standard protocols.

3.2.3 Levels of Description

Requirements can be described at various levels of detail, each serving a different purpose in the
development process. Understanding these levels helps ensure that all aspects of the system are
captured accurately.

1. High-Level Requirements

 Overview: Broad statements that capture the general goals and objectives of the system.
 Purpose: Provide a strategic vision and context for the project.
 Example: "The system shall improve user productivity by streamlining workflow processes."

2. User Requirements

 Overview: Detailed descriptions of what users need from the system.

 Purpose: Focus on user interactions and experiences with the system.
 Example: "Users must be able to create new tasks and assign them to team members."

3. System Requirements

 Overview: Technical specifications that define how the system will meet user needs.
 Purpose: Serve as a blueprint for developers and testers.
 Example: "The system shall support at least 1000 concurrent users with a response time of less
than 2 seconds."

4. Detailed Requirements

 Overview: Specific and actionable requirements that provide precise criteria for
implementation.
 Purpose: Facilitate testing, development, and validation.
 Example: "The login page shall require users to input a valid email address and password, with
error messages displayed for invalid inputs."

3.2.4 Correctness, Completeness, Consistency, Clarity, and Realism

These attributes are essential for evaluating the quality of requirements:

1. Correctness

 Definition: Requirements should accurately reflect stakeholder needs and expectations.

 Importance: Ensures that the system developed meets the intended purpose.

2. Completeness

 Definition: All necessary requirements must be captured, covering all functions and conditions.
 Importance: Prevents omissions that could lead to incomplete functionality or user
dissatisfaction.

3. Consistency

 Definition: Requirements should not conflict with each other and must align with project goals.
 Importance: Reduces ambiguity and confusion during development and testing.

4. Clarity

 Definition: Requirements must be expressed in clear and understandable language.

 Importance: Minimizes misinterpretation and ensures all stakeholders have a common
understanding.

5. Realism

 Definition: Requirements should be achievable within the project's constraints, including time,
budget, and technology.
 Importance: Prevents setting unrealistic expectations that could lead to project failure.

3.2.5 Verifiability and Traceability

1. Verifiability

 Definition: A requirement is verifiable if it can be tested or measured to confirm that it has been
implemented correctly.
 Importance: Ensures that each requirement can be validated through testing, reducing
ambiguity in what constitutes successful implementation.
 Example: "The system shall generate a report within 5 seconds" is verifiable because it can be
tested.

2. Traceability

 Definition: The ability to link requirements to their origins and to subsequent development
artifacts (design, code, tests).
 Importance: Facilitates impact analysis when requirements change and ensures that all
requirements are addressed throughout the project lifecycle.
  Types:
o Forward Traceability: Tracking requirements through design, implementation, and
testing.
o Backward Traceability: Ensuring that all implemented features trace back to
documented requirements.

3.3 Requirements Elicitation Activities

Effective requirements elicitation involves a series of structured activities that help gather and
define the necessary requirements for a system. Below are key activities involved in this process:

3.3.1 Identifying Actors

Actors are entities that interact with the system, which can include users, external systems, or
devices. Identifying actors is crucial for understanding who will use the system and their specific
roles.

Steps to Identify Actors:

 Engage Stakeholders: Collaborate with stakeholders to gather insights about different user
groups.
 Analyze System Boundaries: Define what parts of the system are within and outside the scope
to clarify interactions.
 Document Actors: Create a list of identified actors, including primary and secondary users.

3.3.2 Identifying Scenarios

Scenarios describe specific situations where actors interact with the system to achieve particular
goals. They provide context for understanding user needs and system behavior.

Steps to Identify Scenarios:

 Brainstorm Use Cases: Collaborate with stakeholders to outline potential scenarios.

 Focus on Goals: Identify what each actor aims to accomplish in various situations.
 Document Scenarios: Write detailed descriptions of scenarios, including context and conditions.

3.3.3 Identifying Use Cases

Use cases are detailed descriptions of how actors will achieve specific goals using the system,
encapsulating functional requirements.

Steps to Identify Use Cases:

 Review Scenarios: Use the identified scenarios to derive use cases.

 Define Preconditions and Post conditions: Note what must be true before and after the use
case execution.
  Document Use Cases: Create a structured format for each use case, outlining the main flow and
alternative paths.

3.3.4 Refining Use Cases

Refining use cases involves adding detail and clarity to ensure completeness and accuracy.

Steps to Refine Use Cases:

 Engage Stakeholders: Review use cases with stakeholders for feedback and additional insights.
 Identify Variations: Document alternative flows and exceptions.
 Clarify Steps: Ensure each step is clear, concise, and actionable.

3.3.5 Identifying Relationships Among Actors and Use Cases

Mapping relationships helps clarify interactions, dependencies, and hierarchies among actors and
use cases.

Steps to Identify Relationships:

 Create Diagrams: Use tools like UML diagrams to visualize relationships.

 Define Associations: Note how actors relate to specific use cases (e.g., primary, secondary).
 Document Dependencies: Identify and document any dependencies between use cases.

3.3.6 Identifying Initial Analysis Objects

Initial analysis objects are key entities and concepts relevant to the system. Identifying these
objects helps structure the requirements and supports subsequent design efforts.

Steps to Identify Analysis Objects:

 Review Use Cases and Scenarios: Extract potential objects from the defined use cases.
 Identify Key Entities: Focus on objects that represent significant data or functionality.
 Document Objects: Create a list of identified analysis objects with descriptions.

3.3.7 Identifying Non-Functional Requirements

Non-functional requirements specify criteria that judge the operation of a system, focusing on
quality attributes.

Steps to Identify Non-Functional Requirements:

 Engage Stakeholders: Discuss quality attributes with stakeholders to gather their expectations.
 Consider System Constraints: Analyze performance, security, usability, and scalability needs.
 Document Non-Functional Requirements: Clearly articulate each requirement, ensuring they
are measurable and specific.