04 Requirements Engineering: From Process to Practice

December 2025 (4014 Words, 23 Minutes)

1. Introduction: From Documentation to Discovery

Where we left off:

In Part 1, you learned:

• What requirements are (functional vs non-functional)
• Who cares about them (stakeholders)
• What makes them good (INVEST, testability)
• How to document them (User Stories, GitHub Issues)
• How to link them to tests (traceability)

But we haven’t answered the harder questions:

• How do requirements fit into the development workflow?
• How do you actually discover what stakeholders need?
• What happens when requirements change mid-project?
• Is there a better way than “write everything upfront”?

Today’s focus: The process of requirements engineering - from elicitation to change management, and why Agile emerged as a response to requirements uncertainty.

2. Learning Objectives

By the end of this lecture, you will:

1. See requirements from different perspectives (developer, PM, product manager, founder)
2. Apply elicitation techniques to discover requirements through stakeholder interviews
3. Distinguish bugs from change requests and understand why this matters
4. Use POC-driven approaches to discover requirements through prototyping
5. Understand traditional development models (Waterfall, V-Model, V-Modell XT) and their limitations
6. Recognize why V-Modell XT matters for German government and regulated industry projects
7. Preview Agile methodology as a response to requirements uncertainty

Connection to Part 1: These skills build on the documentation and quality criteria from Part 1. You can’t elicit requirements well if you don’t know what makes a good requirement.

3. Beyond the Developer: Business Perspectives

Different roles ask different questions about requirements.

3.1 The Developer’s View

Questions:

• What exactly should this function do?
• What are the edge cases?
• How do I test this?

Focus: Precision, testability, implementation details

3.2 The Project Manager’s View

Questions:

• How long will this take?
• What’s the priority?
• What’s the scope?

Focus: The iron triangle:

graph TD
    Scope --- Time
    Time --- Budget
    Budget --- Scope

    Quality((Quality))

    Scope -.-> Quality
    Time -.-> Quality
    Budget -.-> Quality

“Good, Fast, Cheap - pick two.”

3.3 The Product Manager’s View

Questions:

• Does this deliver value to users?
• What’s the minimum we can build to test the hypothesis?
• What should we build next?

Focus: Value delivery, user needs, prioritization

3.4 The Startup Founder’s View

Questions:

• Is there a market for this?
• Will people pay for it?
• Are we solving a real problem?

Focus: Product-market fit, validation, pivoting

Key insight: The same “requirement” looks different at each level:

“Display intersection point”

• Developer: Algorithm, data structures, UI component
• PM: 2 days effort, depends on chart library
• Product Manager: Enables core workflow, high priority
• Founder: Part of our value proposition, differentiator from competitors

4. Eliciting Requirements: How to Interview Stakeholders

Requirements don’t write themselves. Someone has to discover them through conversation with stakeholders.

4.1 Techniques for Requirements Elicitation

4.2 Good Questions vs Bad Questions

Bad questions (leading, closed):

• “You want the button to be blue, right?”
• “Is the system fast enough?”
• “Do you like the current design?”

Good questions (open, exploratory):

• “Walk me through how you currently do this task.”
• “What’s the most frustrating part of your current workflow?”
• “What would success look like for this feature?”
• “What happens if this calculation is wrong?”

4.3 The 5 Whys Technique

When you hear a requirement, dig deeper:

User: “I need the intersection calculation to be faster.”

Why? “Because I’m waiting too long.”

Why does waiting matter? “Because I have to process 50 profiles per day.”

Why 50 per day? “That’s how many road segments we survey.”

Why not batch them? “I need results before the next measurement.”

Why immediately? “To adjust the camera angle for the next segment.”

Real requirement discovered: Not “faster calculation” but “real-time feedback loop for camera adjustment.”

Solution might be: Prediction/preview, not faster calculation.

5. Change Request vs Bug Fix: A Critical Distinction

This seems like a technical detail, but it’s actually a business-critical decision.

5.1 Definitions

Bug:

The software does not meet an existing, documented requirement.

Change Request (CR):

The stakeholder wants the software to do something different or additional to existing requirements.

5.2 Why This Matters

5.3 The Gray Area

Customer says: “The intersection point is wrong!”

Is it a bug or CR?

graph TD
    A[Customer reports issue] --> B{Is expected behavior documented?}
    B -->|Yes| C{Does software match documentation?}
    B -->|No| D[Gray area - discuss with stakeholder]
    C -->|Yes| E[Change Request - software works as specified]
    C -->|No| F[Bug - software doesn't match spec]
    D --> G{Was behavior implied by context?}
    G -->|Yes| H[Probably a bug]
    G -->|No| I[Probably a CR]

Real example:

“The intersection calculation returns wrong results for angles greater than 180°.”

• If the requirement says “angle in range 0-360”: Bug (should handle 180+)
• If the requirement says “angle in range 0-180”: Change Request (new capability)
• If the requirement doesn’t specify: Discussion needed

Key insight: Good requirements documentation prevents these disputes.

Warning: Beyond Software Development

This distinction isn’t just a technical matter—it can have legal and financial consequences that go far beyond the scope of software engineering. In real-world projects, bug vs. change request disputes often escalate to contract negotiations, legal discussions, or even court cases.

Real-world scenarios you should be aware of:

• A customer receives software that crashes under normal use. The vendor claims: “The requirements didn’t specify stability.” → Legal dispute
• A vendor delivers exactly what was specified, but the customer expected more. The customer claims: “This is obviously broken.” → Contract renegotiation
• Ambiguous requirements lead to months of “is it a bug?” discussions, delaying the project → Scope creep and cost overruns

What this means for you as a student:

• Requirements engineering has direct financial and legal implications
• When you write or review requirements, think: “Would this survive a contract dispute?”
• This topic intersects with business law and contract management—fields beyond our scope, but ones you’ll encounter in professional practice

Bottom line: The clearer your requirements documentation, the fewer disputes arise. When disputes do occur, good documentation protects both parties.

6. POC-Driven Requirements: Build to Learn

Here’s the uncomfortable truth about requirements:

Customers don’t know what they want until they see it.

This isn’t a failure - it’s human nature. Requirements emerge through interaction with tangible artifacts.

6.1 The Problem with Big Upfront Requirements

Traditional RE assumes you can:

1. Interview stakeholders
2. Write complete requirements
3. Build the system
4. Deliver what they wanted

Reality:

1. Stakeholders describe what they think they want
2. You build it
3. They see it and say “Actually, I meant…”
4. Expensive rework

6.2 Lean Startup: Build-Measure-Learn

The Lean Startup approach (Eric Ries) flips the process:

graph LR
    A[Idea] --> B[Build MVP]
    B --> C[Measure]
    C --> D[Learn]
    D --> A

MVP = Minimum Viable Product: The smallest thing you can build to test your hypothesis about what users want.

Example for Road Profile Viewer:

Instead of building the full system:

1. MVP 1: Command-line script that calculates intersection → Show to user
2. MVP 2: Simple plot with hardcoded data → “Is this what you need?”
3. MVP 3: Interactive angle selector → “Does this workflow work?”

Each iteration refines requirements based on real feedback.

6.3 Design Thinking: Empathize First

Design Thinking (IDEO, Stanford d.school) emphasizes understanding users before defining solutions:

Empathize → Define → Ideate → Prototype → Test
     ↑_____________________________________|

Key activities:

• Empathize: Observe users, interview them, experience their pain
• Define: Synthesize observations into problem statements
• Ideate: Generate many possible solutions
• Prototype: Build quick, cheap, disposable prototypes
• Test: Get feedback, refine understanding

Requirements emerge from this process - they’re not inputs to it.

6.4 Modern Approach: Gen AI for Rapid Prototyping

Here’s where it gets exciting for modern developers:

Traditional prototyping:

• Build a prototype: 2-4 weeks
• Show to customer, get feedback
• Iterate

Gen AI-assisted prototyping (“vibe coding”):

• Describe what you want to an AI assistant
• Get working prototype in hours (or minutes)
• Show to customer the same day
• Iterate rapidly

Example workflow:

Developer: "Create a simple Python GUI that loads a CSV of road points
           and displays them as a line chart. Add a slider for angle."

[AI generates working code in 10 minutes]

Developer: *Shows to road engineer*

Engineer: "This is interesting, but I need to see the camera position too.
          And can the intersection point blink when it updates?"

Developer: "Add camera position marker and blinking intersection to the code."

[AI updates code in 5 minutes]

Developer: *Shows updated version*

Engineer: "Yes! But actually, I realize I need to compare two profiles
          side by side..."

The insight: AI lets you create POCs so fast that requirements discovery becomes interactive.

Instead of:

1. Long interview → Written requirements → Build → Wrong thing

You get:

1. Quick chat → Working prototype → Immediate feedback → Refined prototype → Real requirements emerge

Requirements become conversations with working software as a shared reference.

6.5 When Traditional RE Fails

POC-driven approaches are especially valuable when:

• High uncertainty: You’re building something novel
• Stakeholders can’t articulate needs: “I’ll know it when I see it”
• Fast-moving market: Requirements change before you can document them
• Innovation context: You’re discovering, not just building

Traditional RE still works for:

• Regulatory environments (medical, aviation)
• Well-understood domains with stable requirements
• Large systems with many integration points
• Contract-based development with fixed scope

7. Traditional Development Models

Before we dive into Agile, we need to understand what came before it. Traditional development models dominated software engineering for decades, and many organizations—especially in regulated industries—still use them today. Understanding these models helps you appreciate why Agile emerged and when traditional approaches might still be appropriate.

7.1 The Waterfall Model: Origins and Structure

The Waterfall model is the grandfather of all software development methodologies.

History:

• 1956: Herbert Benington presented the first description of sequential phases at a symposium on advanced programming methods
• 1970: Winston Royce published “Managing the Development of Large Software Systems”—the paper most often cited as the origin of Waterfall
• 1976: Thomas Bell and T.A. Thayer coined the term “waterfall” in their paper on software requirements

Each phase “flows” into the next like water cascading down a waterfall—hence the name. Once you’ve passed a phase, going back upstream is difficult and expensive.

The Royce Irony:

Here’s a fascinating historical detail: Winston Royce, whose 1970 paper is universally cited as the origin of the Waterfall model, actually warned against the pure sequential approach. In his paper, he called the basic waterfall “risky and inviting failure.” The rest of his paper described iterative improvements and feedback loops.

The industry adopted his diagram but ignored his warnings. Royce’s “cautionary example” became the standard process.

Characteristics:

• Sequential phases: Each phase must complete before the next begins
• Phase gates: Formal reviews and sign-offs between phases
• Heavy documentation: Complete documentation at each phase
• Big Design Up Front (BDUF): All requirements and design completed before coding
• Change is expensive: Late changes require revisiting earlier phases

Where Waterfall Works:

Despite its limitations, Waterfall can be appropriate for:

• Projects with stable, well-understood requirements
• Regulatory environments requiring documentation trails
• Fixed-price contracts with clearly defined deliverables
• Hardware-software integration where hardware is fixed early

7.2 The V-Model: Testing Built In

The V-Model emerged in the 1980s as an evolution of Waterfall, addressing one of its key weaknesses: testing as an afterthought.

Origin: Paul Rook introduced the V-Model in the late 1980s, primarily for software development in regulated industries.

Key Innovation: Each development phase on the left side of the “V” has a corresponding testing phase on the right side. Test planning happens in parallel with development, not after it.

The V-shape: development flows down the left arm, reaches Implementation at the bottom point, then testing flows up the right arm. The horizontal dashed lines show that test planning happens in parallel—acceptance tests are designed when requirements are written, not after coding.

The V-Shape Explained:

Improvement over Waterfall:

• Tests are planned early, so testers think about verification during design
• Clear traceability from requirements to test cases
• Defects are detected earlier (at least in theory)

Still Sequential:

Despite the improvement, the V-Model suffers from the same fundamental problem as Waterfall: working software appears only at the end. If requirements were wrong, you still discover it late.

7.3 V-Modell XT: The German Government Standard

If you work on IT projects for the German federal government, you are required to use V-Modell XT. This isn’t optional—it’s mandated by law.

What is V-Modell XT?

V-Modell XT (where “XT” stands for “eXtreme Tailoring”) is the standard development process for German federal IT projects since 2005. Version 2.3 (published March 2019) is currently in use.

Official Resources:

• V-Modell XT Homepage (German)
• V-Modell XT FAQ (German)

History:

• 1992: Original V-Model developed by IABG (Industrieanlagen-Betriebsgesellschaft) for the German Federal Ministry of Defense
• 1997: V-Model 97 released for civilian use
• 2004: V-Modell XT introduced with modernized, adaptable structure
• 2019: Current version 2.3 published

Why “Extreme Tailoring”?

Unlike rigid process models, V-Modell XT is designed to be adapted to different project types and sizes. The “tailoring” process selects which parts of the model apply to your specific project.

Core Components:

1. Decision Points (Entscheidungspunkte): Project gates where specific deliverables must be approved before proceeding. These ensure quality and provide management visibility.

2. Process Building Blocks (Vorgehensbausteine): Approximately 20 standardized modules that can be combined:
   • Project Management (PM)
   • Quality Assurance (QA)
   • Configuration Management (KM)
   • Problem and Change Management (PÄM)
   • Requirements Management
   • System Development
   • And more…
3. Project Types:
   • System Development Project (Systementwicklungsprojekt)
   • System Implementation Project
   • Combined Development and Implementation
   • Service Projects
   • Agile Development Project (yes, even V-Modell XT has agile variants!)

4. 108 Defined Deliverables (Produkte): From requirements specifications to test reports, each deliverable has a defined structure and approval process.

5. 35 Defined Roles: Project managers, architects, developers, testers, quality managers, and more—each with defined responsibilities.

Tailoring Process:

graph LR
    A[Select Project Type] --> B[Select Project Type Variant]
    B --> C[Define Project Characteristics]
    C --> D[Generate Project-Specific Model]

Real-World Applications:

• Federal government IT systems: Tax administration, social security, public services
• Defense and aerospace: Military systems, air traffic control
• Medical device software: Regulatory compliance (IEC 62304)
• Automotive software: Safety-critical systems (ISO 26262)
• Public administration: E-government, citizen services

Why This Matters for Students:

Even if you don’t plan to work in government, understanding V-Modell XT is valuable because:

• Many large German companies (Siemens, Bosch, SAP) use it or variants
• It demonstrates how regulated industries handle software development
• It shows the extreme of documentation-driven development—making Agile’s contrast clearer
• Job interviews in German industry often reference it

7.4 The Problem with Sequential Models

All sequential models—Waterfall, V-Model, and V-Modell XT—share fundamental limitations that eventually led to the Agile movement.

The Late Feedback Problem:

In sequential models, working software appears only at the end. If requirements were wrong, you discover it months (or years) after the decision was made.

graph LR
    A[Requirements<br>Decision] -->|"6-18 months"| B[Working<br>Software]
    B --> C[Discovery:<br>'That's not what I meant!']
    C --> D[Expensive<br>Rework]

The Cost of Change:

Barry Boehm’s seminal 1981 book “Software Engineering Economics” documented what became known as the “cost of change curve.” His studies showed that defects found late in development are dramatically more expensive to fix:

• Requirements phase: Relative cost = 1x
• Design phase: Relative cost = 3-6x
• Coding phase: Relative cost = 10x
• Testing phase: Relative cost = 15-40x
• Maintenance (production): Relative cost = 30-100x

Note: Modern studies show varying ratios depending on context. The exact numbers are disputed, but the principle is robust: late changes cost more than early changes.

Why? A requirements error found during requirements means changing a document. The same error found in production means:

• Changing the requirement document
• Updating design documents
• Rewriting code
• Re-running tests (regression testing)
• Redeploying
• Handling customer impact
• Possible data migration

The Fundamental Tensions:

Sequential models assume we can:

1. Know all requirements upfront
2. Design a complete solution before coding
3. Build it right the first time

Reality contradicts all three assumptions:

The Paradox:

• If we plan more: We spend time on plans that will change
• If we plan less: We build the wrong thing
• Sequential models assume stability: But software development is inherently uncertain

The Solution?

Accept that change is inevitable and build processes that embrace it. Don’t fight uncertainty—work with it.

This insight led to the Agile movement…

8. Preview: Toward Agile Development

Everything we’ve discussed points to a fundamental tension:

The planning problem:

• We need requirements to build the right thing
• But requirements change constantly
• And users don’t know what they want until they see it

Traditional response: More planning, more documentation, change control

Agile response: Embrace change as inevitable, iterate quickly, deliver value early

8.1 The Agile Manifesto (Preview)

We are uncovering better ways of developing software by doing it and helping others do it.

Through this work we have come to value:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

8.2 Agile Requirements

In Agile development:

• Requirements are captured as User Stories (small, negotiable)
• Stories live in a Backlog (prioritized list)
• Work happens in Sprints (short iterations, 1-4 weeks)
• Requirements are refined continuously (backlog grooming)
• Customer feedback happens frequently (sprint reviews)

Next lecture: We’ll dive deep into Agile methodology - Scrum, sprints, backlogs, and how testing fits into iterative development.

9. Summary

The Big Picture (Both Parts Combined):

Stakeholder Needs
       ↓
   Requirements (User Stories, Acceptance Criteria)  ← Part 1
       ↓
   Elicitation & Refinement  ← Part 2
       ↓
   Tests (verify requirements)  ← Part 1
       ↓
   Code (implements requirements, passes tests)
       ↓
   Change Requests & Bug Fixes  ← Part 2
       ↑
   Gaps reveal missing requirements
       ↑
   Back to stakeholder conversations

10. Reflection Questions

1. Look at your current project: What requirements are implicit in your code? Where are they documented?

2. Stakeholder analysis: Who are the stakeholders for the Road Profile Viewer? What might a “safety officer” stakeholder require that wasn’t in our original list?

3. Bug or CR? A user reports: “The system crashes when I load a file with 1 million points.” The documentation says nothing about file size limits. Bug or change request? How would you handle this?

4. Testability: Take this requirement: “The system should be reliable.” Rewrite it to be testable.

5. POC approach: If you were building a new feature for Road Profile Viewer and didn’t know exactly what users needed, how would you use a Gen AI-assisted POC approach to discover requirements?

11. Further Reading

Books:

• Karl Wiegers & Joy Beatty: Software Requirements (3rd ed.) - The comprehensive reference
• Eric Ries: The Lean Startup - POC-driven product development
• Mike Cohn: User Stories Applied - Practical guide to user stories

Standards:

• IEEE 830: Software Requirements Specifications (older but foundational)
• IEEE 29148: Requirements Engineering (modern standard)

Tools:

• GitHub Issues: Built-in requirements tracking
• Jira: Enterprise requirements management
• Linear: Modern, developer-friendly issue tracking
• pytest-bdd: Behavior-driven development with pytest