Coursify

SOFTWARE ENGINEERING

Sub-Phases of Requirement Analysis

This section examines the main sub-phases involved in requirement analysis, from elicitation through analysis, validation, and documentation.

Learning Goals

  • List the major sub-phases of requirement analysis in their logical sequence.
  • Describe the purpose and outputs of elicitation, analysis, specification, validation, and management activities.
  • Map sample project tasks to the appropriate sub-phase of requirement analysis.
  • Identify inputs and deliverables associated with each sub-phase.
  • Construct a simple workflow showing how sub-phases of requirement analysis interact in a software project.

In software engineering, Requirements Engineering serves as the foundation of project success . A failure to properly gather, structure, and check requirements represents one of the primary drivers of software project failures, budget overruns, and scope creep.

To manage this complex process, requirements engineering is broken down into five distinct, sequential yet iterative sub-phases 2:

  1. Requirements Elicitation: Discovering stakeholder needs.
  2. Requirements Analysis: Reconciling conflicts, determining technical feasibility, and modeling system behaviors.
  3. Requirements Specification: Drafting the official system blueprint, usually the Software Requirements Specification (SRS).
  4. Requirements Validation: Checking the document against stakeholder expectations and quality parameters.
  5. Requirements Management: Controlling changes, managing versions, and ensuring end-to-end traceability.

The diagram below illustrates the iterative loop and workflow connections between these sub-phases:

Footnotes

  1. Requirements Engineering Process - GeeksforGeeks - Explains the fundamental workflow of eliciting, analyzing, specifying, and validating software requirements. ↩ ↩2

  2. Visual Paradigm Guide on Requirements Engineering - Provides deep insight into managing change control and maintaining traceability across software project modules.Action: tavily_search ↩

Understanding the Requirements Engineering Process

Chronological Roadmap of Requirements Sub-Phases

Requirements Elicitation

Phase 1

Interacting with customers and stakeholders to discover system boundaries, user needs, and constraints. Deliverables include raw notes and meeting minutes."

Requirements Analysis

Phase 2

Analyzing, sorting, and modeling the gathered requirements to resolve conflicts, determine feasibility, and model behavior."

Requirements Specification

Phase 3

Translating the analyzed requirements into a formal, structured document—typically the Software Requirements Specification (SRS) document."

Requirements Validation

Phase 4

Reviewing the SRS document with stakeholders to ensure correctness, completeness, consistency, and realism."

Requirements Management

Phase 5

Managing changes to the requirements over time using version control, change control boards, and maintaining traceability."

Walkthrough of a Requirement's Lifecycle

  1. 1
    Step 1

    | The analyst conducts interviews and workshops with stakeholders to capture user needs. For example, a stakeholder requests: "The system must load reports quickly."

  2. 2
    Step 2

    | The raw request is analyzed to define "quickly". Through negotiation, it is quantified mathematically: the response time TT must satisfy T≤2.0T \le 2.0 seconds under a load of U=100U = 100 concurrent users.

  3. 3
    Step 3

    | The refined requirement is formally written into the SRS using structured templates, including UML use cases or sequence diagrams.

  4. 4
    Step 4

    | A formal review meeting is held. Testers, developers, and clients verify that the requirement is testable, unambiguous, and aligned with business goals.

  5. 5
    Step 5

    | The requirement is assigned a unique identifier (e.g., REQ-104) and mapped in a Traceability Matrix to monitor updates and changes.

Pro Tip: Prioritize with MoSCoW

During the Requirements Analysis sub-phase, use the MoSCoW method (Must have, Should have, Could have, Won't have) to categorize stakeholder requests. This prevents scope creep and sets clear delivery expectations.

Common Pitfall: Confusing Elicitation with Analysis

Do not jump straight into documentation (Specification) while performing Elicitation. Without a distinct Analysis phase to resolve inconsistencies and evaluate technical feasibility, you risk building the wrong features or conflicting systems.

Estimated Effort Distribution by Sub-Phase

Typical percentage of total requirement engineering time spent on each activity

| ### Elicitation - Inputs: Product charter, business goals, stakeholder lists, domain standards. - Deliverables: Raw user stories, interview transcripts, observation reports, domain models. - Sample Tasks: Conducting stakeholder workshops, brainstorming sessions, and distributing user surveys.

Deep Dive FAQs

Knowledge Check

Question 1 of 3
Q1Single choice

Which sub-phase of requirement engineering is primarily concerned with resolving conflicts between different stakeholders' requirements?

In software engineering, Requirements Engineering serves as the foundation of project success . A failure to properly gather, structure, and check requirements represents one of the primary drivers of software project failures, budget overruns, and scope creep.

To manage this complex process, requirements engineering is broken down into five distinct, sequential yet iterative sub-phases 2:

  1. Requirements Elicitation: Discovering stakeholder needs.
  2. Requirements Analysis: Reconciling conflicts, determining technical feasibility, and modeling system behaviors.
  3. Requirements Specification: Drafting the official system blueprint, usually the Software Requirements Specification (SRS).
  4. Requirements Validation: Checking the document against stakeholder expectations and quality parameters.
  5. Requirements Management: Controlling changes, managing versions, and ensuring end-to-end traceability.

The diagram below illustrates the iterative loop and workflow connections between these sub-phases:

Footnotes

  1. Requirements Engineering Process - GeeksforGeeks - Explains the fundamental workflow of eliciting, analyzing, specifying, and validating software requirements. ↩ ↩2

  2. Visual Paradigm Guide on Requirements Engineering - Provides deep insight into managing change control and maintaining traceability across software project modules.Action: tavily_search ↩

Understanding the Requirements Engineering Process

Chronological Roadmap of Requirements Sub-Phases

Requirements Elicitation

Phase 1

Interacting with customers and stakeholders to discover system boundaries, user needs, and constraints. Deliverables include raw notes and meeting minutes."

Requirements Analysis

Phase 2

Analyzing, sorting, and modeling the gathered requirements to resolve conflicts, determine feasibility, and model behavior."

Requirements Specification

Phase 3

Translating the analyzed requirements into a formal, structured document—typically the Software Requirements Specification (SRS) document."

Requirements Validation

Phase 4

Reviewing the SRS document with stakeholders to ensure correctness, completeness, consistency, and realism."

Requirements Management

Phase 5

Managing changes to the requirements over time using version control, change control boards, and maintaining traceability."

Walkthrough of a Requirement's Lifecycle

  1. 1
    Step 1

    | The analyst conducts interviews and workshops with stakeholders to capture user needs. For example, a stakeholder requests: "The system must load reports quickly."

  2. 2
    Step 2

    | The raw request is analyzed to define "quickly". Through negotiation, it is quantified mathematically: the response time TT must satisfy T≤2.0T \le 2.0 seconds under a load of U=100U = 100 concurrent users.

  3. 3
    Step 3

    | The refined requirement is formally written into the SRS using structured templates, including UML use cases or sequence diagrams.

  4. 4
    Step 4

    | A formal review meeting is held. Testers, developers, and clients verify that the requirement is testable, unambiguous, and aligned with business goals.

  5. 5
    Step 5

    | The requirement is assigned a unique identifier (e.g., REQ-104) and mapped in a Traceability Matrix to monitor updates and changes.

Pro Tip: Prioritize with MoSCoW

During the Requirements Analysis sub-phase, use the MoSCoW method (Must have, Should have, Could have, Won't have) to categorize stakeholder requests. This prevents scope creep and sets clear delivery expectations.

Common Pitfall: Confusing Elicitation with Analysis

Do not jump straight into documentation (Specification) while performing Elicitation. Without a distinct Analysis phase to resolve inconsistencies and evaluate technical feasibility, you risk building the wrong features or conflicting systems.

Estimated Effort Distribution by Sub-Phase

Typical percentage of total requirement engineering time spent on each activity

| ### Elicitation - Inputs: Product charter, business goals, stakeholder lists, domain standards. - Deliverables: Raw user stories, interview transcripts, observation reports, domain models. - Sample Tasks: Conducting stakeholder workshops, brainstorming sessions, and distributing user surveys.

Deep Dive FAQs

Knowledge Check

Question 1 of 3
Q1Single choice

Which sub-phase of requirement engineering is primarily concerned with resolving conflicts between different stakeholders' requirements?

Previous

Next

Sub-Phases of Requirement Analysis | SOFTWARE ENGINEERING | Coursify