Extended Waterfall Model

This article explains the extended waterfall model, including typical exam questions, core components, and key concepts. Read a “random article” each day on this page and build your knowledge—even if some topics feel unfamiliar at first.

In a Nutshell

The extended waterfall model preserves the clear phases of the classic waterfall but adds controlled feedback loops between adjacent phases and early prototypes. This catches defects sooner and reduces risks in a targeted way.

Detailed Technical Description

In the extended waterfall, phases still proceed sequentially (Requirements → Design → Implementation → Testing → Deployment/Maintenance), but:

• Defined backjumps return to the previous phase if acceptance criteria are not met.
• Test planning and QA are prepared in parallel (for example, test concepts drafted during analysis or design).
• Prototypes (UI or architecture spikes) are created early to validate unclear requirements or technical risks.

Key terms:

• Verification: “Are we building the product correctly?” (against specification)
• Validation: “Are we building the right product?” (against business purpose)

Especially Popular in IHK Exams for Application Development Specialists

Why? The waterfall model works well for small projects—the kind typically completed during apprenticeships or internships. The extended waterfall is less rigid than the classical approach and allows for corrections through backjumps. I chose it myself, and it was straightforward to explain and execute.

Key Terms in Detail

Baselines

Definition: A baseline is a documented state of project artifacts at a specific point in time. It serves as a reference point for future changes.

Types of baselines:

• Requirements Baseline: Approved requirements (functional specification or requirements document)
• Design Baseline: Released design documents (architecture, module design)
• Code Baseline: Stable, tested code version (release candidate)
• Test Baseline: Accepted test results and test protocols

Example: After the requirements phase, the requirements baseline is created. All later changes must be formally requested as a change request.

Change Requests

Definition: A change request is a formal request to modify already-baselined artifacts.

Change request process:

1. Submission: Who is requesting what and why?
2. Impact analysis: What are the consequences of this change?
3. Evaluation: Weigh costs, benefits, and risks
4. Decision: Approval or rejection by the Change Advisory Board (CAB)
5. Implementation: Execute the change and document it

Example: During implementation, a customer wants to add a new feature. This requires a change request with an impact analysis.

Impact Analysis

Definition: Impact analysis examines the consequences of a planned change across the entire project.

Analysis areas:

• Technical impact: Which components need adjustment?
• Schedule impact: Does the project timeline extend?
• Cost impact: Do development and testing incur additional expenses?
• Quality impact: Does the change affect system quality?
• Risk impact: Are new technical or project-related risks introduced?

Example: When a requirement changes, the analysis identifies which design elements, code modules, and test cases are affected.

Traceability from Requirements to Tests

Definition: Traceability ensures tracking of requirements across all project phases through to testing.

Traceability chain:

Requirement (REQ-001) → Design (ARCH-015) → Code (CODE-042) → Test (TEST-087)

Purposes of traceability:

• Completeness verification: Every requirement is implemented and tested
• Impact analysis: Quickly identify affected areas when changes occur
• Quality assurance: Detect coverage gaps
• Audit evidence: For regulatory compliance and certifications

Traceability matrix example:

Requirement ID	Requirement	Design ID	Code Component	Test Case ID	Status
REQ-001	User registration	ARCH-015	UserService.java	TEST-087	✅
REQ-002	Password reset	ARCH-016	PasswordService.java	TEST-088	✅
REQ-003	Product catalog	ARCH-017	ProductService.java	TEST-089	❌

Especially Popular in IHK Exams for Application Development Specialists

Why the extended waterfall model matters in IHK exams:

1. Structured Approach

The IHK assesses whether candidates can work systematically and methodically. The extended waterfall provides this structure with clear phases and responsibilities.

2. Quality Awareness

Quality assurance is central to IHK assessment. The extended waterfall integrates QA measures at every phase (reviews, testing, prototypes).

3. Documentation Requirements

The IHK demands comprehensive documentation. The model produces verifiable artifacts at each phase (functional specification, requirements specification, test protocols).

4. Risk Management

Specialists must identify and assess risks. The extended waterfall offers formalized risk reduction through prototypes and reviews.

5. Change Management

In practice, changes must be handled professionally. Change requests and impact analyses are competencies tested by the IHK.

6. Traceability

Examiners need to understand why specific decisions were made. Baselines and traceability provide this clarity.

7. Real-World Relevance

Many mid-sized companies still work with waterfall-like models. The IHK prepares candidates for actual working conditions.

Typical IHK exam scenarios:

• Create and justify a project phase plan
• Perform and evaluate a change analysis
• Build a traceability matrix
• Define QA measures for a phase
• Describe and manage a feedback scenario

The Extended Waterfall Model in Detail

Phase Flow with Feedback Loops

    ┌─────────────────────┐
    │  1. Requirements    │
    │      Phase          │
    └─────────┬───────────┘
              │ Approval
              ▼
    ┌─────────────────────┐
    │  2. System Design   │◄────────────────┐
    └─────────┬───────────┘                 │
              │ Approval                     │
              ▼                              │
    ┌─────────────────────┐                 │
    │  3. Architecture    │◄────────────────┤
    │      Design         │                 │
    └─────────┬───────────┘                 │
              │ Approval                     │
              ▼                              │
    ┌─────────────────────┐                 │
    │  4. Module Design   │◄────────────────┤
    └─────────┬───────────┘                 │
              │ Approval                     │
              ▼                              │
    ┌─────────────────────┐                 │
    │  5. Implementation  │◄────────────────┤
    └─────────┬───────────┘                 │
              │ Approval                     │
              ▼                              │
    ┌─────────────────────┐                 │
    │  6. Test Preparation│◄────────────────┤
    └─────────┬───────────┘                 │
              │ Approval                     │
              ▼                              │
    ┌─────────────────────┐                 │
    │  7. Test Execution  │◄────────────────┤
    └─────────┬───────────┘                 │
              │ Approval                     │
              ▼                              │
    ┌─────────────────────┐                 │
    │  8. Deployment      │                 │
    └─────────────────────┘                 │
                                           │
                                           │ Controlled
                                           │ Backjumps
                                           │ on Defects
                                           └─────────────────

Detailed Phase Descriptions

Phase 1: Requirements

Goals: Capture, specify, and approve requirements completely

Artifacts:

• Requirements specification (customer perspective)
• Implementation specification (vendor perspective)
• Requirements catalog with IDs
• Acceptance criteria
• Glossary

Activities:

• Stakeholder interviews
• Workshops with subject matter experts
• Requirements analysis
• Prioritization (MoSCoW)
• Requirements approval

Quality Assurance:

• Requirements reviews
• Consistency checks
• Completeness verification
• Traceability matrix initialization

Typical Feedback Loops: Generally none, as this is the starting point

---

Phase 2: System Design

Goals: Define system boundaries, specify interfaces

Artifacts:

• Context diagram
• Interface catalog
• Data flow diagrams
• System architecture (high-level)
• Technical concepts

Activities:

• Define system boundaries
• Specify external interfaces
• Model data flows
• Specify non-functional requirements
• Justify technology choices

Quality Assurance:

• Architecture reviews
• Interface validation
• Performance estimation
• Security concept review

Typical Feedback Loops: Unclear requirements → Requirements phase

---

Phase 3: Architecture Design

Goals: Establish detailed architecture, minimize technical risks

Artifacts:

• Component diagram
• Deployment diagram
• Data model (ERD)
• Quality goals catalog
• Architecture decision record (ADR)

Activities:

• Design components
• Data modeling
• Define quality attributes
• Develop prototypes (UI spikes, technology proofs of concept)
• Elaborate security concepts

Quality Assurance:

• Architecture reviews
• Prototype testing
• Performance benchmarks
• Security reviews

Typical Feedback Loops: Technical ambiguities → System design

---

Phase 4: Detailed Design

Goals: Finalize detailed design for all modules, complete interface contracts

Artifacts:

• Class diagrams
• Sequence diagrams
• Interface specifications
• Algorithm descriptions
• Database schema

Activities:

• Design classes and objects
• Specify algorithms
• Database design
• UI design (screens, wireframes)
• Integration concepts

Quality Assurance:

• Design reviews
• Code generation testing
• Database normalization
• UI usability testing

Typical Feedback Loops: Design issues → Architecture design

---

Phase 5: Implementation

Goals: Create code according to specification, implement quality assurance measures

Artifacts:

• Source code (version controlled)
• Unit tests
• Code documentation
• Build scripts
• Deployment packages

Activities:

• Programming to standards
• Code reviews
• Static code analysis
• Unit test development
• Continuous integration

Quality Assurance:

• Code reviews
• Static analysis (SonarQube)
• Unit test coverage
• Coding standard compliance

Typical Feedback Loops: Implementation issues → Detailed design

---

Phase 6: Test Preparation

Goals: Create comprehensive test strategy, set up test environment

Artifacts:

• Test concept
• Test cases (detailed)
• Test data
• Test automation scripts
• Test environments

Activities:

• Define test strategy
• Derive test cases (from requirements)
• Prepare test data
• Develop test automation
• Set up test environments

Quality Assurance:

• Test concept review
• Test case coverage analysis
• Test data validation
• Test environment verification

Typical Feedback Loops: Test gaps → Implementation/Detailed design

---

Phase 7: Testing

Goals: Demonstrate system quality, find and fix defects

Artifacts:

• Test reports
• Defect reports
• Acceptance test reports
• Performance measurements
• Security test results

Activities:

• Module testing
• Integration testing
• System testing
• Acceptance testing
• Performance testing

Quality Assurance:

• Test reviews
• Defect analysis
• Regression testing
• Acceptance verification

Typical Feedback Loops: System defects → Implementation/Architecture

---

Phase 8: Deployment

Goals: Start production operation, train users, provide documentation

Artifacts:

• Installation guide
• User manual
• Administrator manual
• Training materials
• Maintenance contract

Activities:

• Installation/deployment
• Data migration
• User training
• Create operations manual
• Establish support structure

Quality Assurance:

• Installation testing
• Migration validation
• Training feedback
• Support readiness checks

Typical Feedback Loops: Operational issues → Testing

Key Examination Points

• Sequential phases with controlled feedback loops
• Integrate test planning early (acceptance criteria in requirements phase)
• Verification/validation per phase (reviews, walkthroughs)
• Gate decisions with acceptance criteria (IHK)
• Prototyping to reduce risk
• Traceability (requirement → design → code → test)
• Change management plus baselines

Core Components

1. Requirements phase (specifications, acceptance criteria)
2. System design (context, interfaces, data model)
3. Architecture design (quality goals, decisions, prototypes)
4. Detailed design (detailed design, interface contracts)
5. Implementation (reviews, static analysis)
6. Test preparation (test concept, test cases, test data)
7. Testing (module/integration/system/acceptance)
8. Deployment (migration, operations, documentation)
9. Feedback loops (approved iterations)
10. Configuration/change management (version control)

Verification and Validation in Detail

Verification: “Are We Building the Product Right?”

Verification confirms that the developed product meets the specifications.

Verification Methods:

• Code reviews: Does the code conform to coding standards?
• Unit tests: Do the functions meet the specified requirements?
• Static analysis: Does the code contain known errors or anti-patterns?
• Integration tests: Do the interfaces work as specified?
• Documentation reviews: Is the documentation complete and accurate?

Verification Example:

Specification: "Password function must accept 8-20 characters"
Verification: Unit test checks boundary values 7, 8, 20, 21 characters
Result: ✅ Specification correctly implemented

Validation: “Are We Building the Right Product?”

Validation confirms that the developed product meets the actual needs of users.

Validation Methods:

• Acceptance tests: Does the system meet business requirements?
• Usability tests: Can users operate the system intuitively?
• Beta tests: Do real users respond as expected?
• Performance tests: Does the system achieve the required performance?
• Security tests: Is the system secure enough for deployment?

Validation Example:

Requirement: "Users must be able to log in quickly and easily"
Validation: 50 test users complete login task (measurement: <3 seconds)
Result: ✅ User acceptance achieved, need fulfilled

V-Model: Connecting Verification and Validation

Requirements gathering ←─────────────────── Acceptance test (Validation)
        ↓                                          ↑
System design ←─────────────────────── System test (Validation)
        ↓                                          ↑
Architecture design ←─────────── Integration test (Verification)
        ↓                                          ↑
Detailed design ←───────────────────── Module test (Verification)
        ↓                                          ↑
Implementation ──────────────────────────

Comprehensive Case Study: E-Commerce Platform

Project Overview

Goal: Build an e-commerce platform with external payment system integrations Team: 8 people (2 PMs, 2 architects, 4 developers) Duration: 6 months Budget: €450,000

Phase 1: Requirements (4 weeks)

Artifacts created:

Requirements Specification (Client):
- 150 user stories with acceptance criteria
- 23 non-functional requirements
- 12 integration interfaces

Design Specification (Vendor):
- Detailed specifications
- Technical constraints
- Schedule and cost planning

Traceability Matrix:
REQ-001 → ARCH-015 → TEST-087
REQ-045 → INTF-003 → TEST-156
...

Gate criteria:

• ✅ All requirements prioritized (MoSCoW)
• ✅ Stakeholder approval from 3 parties
• ✅ Traceability matrix complete
• ✅ Risk analysis completed

Result: Phase approved, 2 change requests documented

---

Phase 2: System Design (3 weeks)

Artifacts created:

Context Diagram:
- 8 external systems (Payment, CRM, ERP, etc.)
- 3 user roles (Customer, Admin, Partner)

Interface Catalog:
- REST API: 47 endpoints
- SOAP: 3 legacy interfaces
- Message Queue: 12 event types

Data Flow Diagrams:
- Order process (7 steps)
- Payment processing (4 steps)
- Inventory sync (daily)

Prototype decision: UI prototype for order process developed → user feedback positive

Gate criteria:

• ✅ All external interfaces specified
• ✅ Performance requirements defined (<2s load time)
• ✅ Security concept created
• ✅ Technology stack finalized (React, Node.js, PostgreSQL)

Feedback: 1 unclear requirement → back to Phase 1

---

Phase 3: Architecture Design (3 weeks)

Artifacts created:

Component Diagram:
- Frontend: React SPA
- Backend: 6 microservices
- Database: PostgreSQL + Redis cache
- Message Queue: RabbitMQ

Quality Goals:
- Performance: <2s response time
- Availability: 99.9%
- Scalability: 10,000 concurrent users
- Security: OWASP Top 10 covered

ADR (Architecture Decision Records):
ADR-001: Microservice architecture chosen
ADR-003: Event-driven for asynchronicity
ADR-007: CQRS for complex queries

Technical prototypes:

• Payment integration (spike: 3 days)
• Performance test (load: 5,000 users)
• Security test (penetration test)

Gate criteria:

• ✅ Architecture review passed
• ✅ Performance benchmarks met
• ✅ Security review passed
• ✅ Prototypes successful

---

Phase 4: Module Design (2 weeks)

Artifacts created:

Class Diagrams:
- User Service: 12 classes
- Order Service: 18 classes
- Payment Service: 8 classes

Interface Specifications:
- Internal API: 67 methods
- External API: 47 endpoints
- Database Schema: 23 tables

UI Design:
- 47 wireframes
- 23 high-fidelity mockups
- Responsive design (mobile/desktop)

Quality assurance:

• Design reviews with senior developers
• Database normalization (3NF)
• UI usability tests with 5 users

---

Phase 5: Implementation (8 weeks)

Artifacts created:

Source Code:
- 45,000 lines of code
- 237 unit tests (92% coverage)
- 47 integration tests

CI/CD Pipeline:
- Automated builds
- Code quality checks (SonarQube)
- Automated testing
- Deployment to staging

Quality metrics:

• Code Coverage: 92%
• SonarQube Quality Gate: ✅ Passed
• Build Time: 4 minutes
• Test Execution: 8 minutes

Feedback: 2 performance issues → back to Phase 4

---

Phase 6: Test Preparation (2 weeks)

Artifacts created:

Test Concept:
- 4 test levels (Unit/Integration/System/Acceptance)
- 3 test environments (Dev/Staging/Prod)
- Test automation: Selenium + Cypress

Test Cases:
- 345 functional tests
- 67 performance tests
- 23 security tests
- 12 usability tests

Test Data:
- 1,200 synthetic customers
- 5,000 test products
- 800 test orders

---

Phase 7: Test Execution (4 weeks)

Test results:

Unit tests: 237/237 ✅ (100%)
Integration tests: 45/47 ✅ (96%)
System tests: 89/95 ✅ (94%)
Performance tests: 22/23 ✅ (96%)
Security tests: 20/23 ❌ (87%)

Defects found:
- Critical: 2 (security vulnerabilities)
- Major: 8 (functional errors)
- Minor: 15 (UI issues)

Feedback:

• Security vulnerabilities → back to Phase 3 (architecture)
• Performance issue → back to Phase 4 (design)

---

Phase 8: Deployment (2 weeks)

Artifacts created:

Deployment:
- Docker containers
- Kubernetes configuration
- Monitoring (Prometheus + Grafana)
- Logging (ELK Stack)

Documentation:
- Installation guide (45 pages)
- User manual (120 pages)
- Admin guide (80 pages)
- API documentation (OpenAPI 3.0)

Training:
- 12 administrator sessions
- 45 user trainings
- 8 support guides

Go-live result:

• ✅ Deployment successful
• ✅ Data migration completed
• ✅ Users trained
• ✅ Monitoring active

---

Project Summary

Successes:

• ✅ Schedule met (+2 weeks buffer)
• ✅ Budget met (+5%)
• ✅ Quality goals achieved
• ✅ User acceptance: 87%

Challenges:

• 3 major feedback loops (phases 3, 4, 7)
• 2 change requests during development
• 1 security issue at the last minute

Lessons learned:

• Early prototypes reduce risks
• Regular reviews are critical
• Traceability saves time during debugging

Pros and Cons

Advantages

• Clear planning and responsibilities
• Earlier defect detection (reviews/prototypes)
• Lower cost of late changes
• Good audit trail (compliance/certification)

Disadvantages

• Feedback loops create coordination overhead
• Higher upfront time (specification/test planning)
• Less flexible than highly iterative models

Traceability and Requirements Management

Creating a Traceability Matrix

Purpose: Ensure every requirement is implemented and tested.

Example Traceability Matrix:

Requirement ID	Requirement Text	Design Element	Code Component	Test Case	Status
REQ-001	User registration with email validation	UserRegistrationController	UserRegistrationService	TEST-001, TEST-002	✅
REQ-015	Password reset function	PasswordResetController	PasswordResetService	TEST-045, TEST-046	✅
REQ-023	Product catalog with filtering	ProductCatalogController	ProductService	TEST-089, TEST-090	❌
REQ-034	Shopping cart functionality	ShoppingCartController	CartService	TEST-123, TEST-124	✅

Traceability tools:

• Requirements Management Tools: JIRA, Polarion, DOORS
• Test Management Tools: TestRail, Zephyr, Xray
• Excel/Google Sheets: For small projects
• Custom Solutions: Traceability scripts

Traceability Process

1. Capture requirement → REQ-XXX
2. Map to design → ARCH-XXX
3. Link to implementation → CODE-XXX
4. Derive test cases → TEST-XXX
5. Document acceptance → STATUS: ✅/❌
6. Analyze deviations → Change request

Change Management and Baselines

Defining Baselines

Baseline: A frozen state of artifacts at a specific point in time.

Types of baselines:

• Requirements Baseline: Approved requirements
• Design Baseline: Released design documents
• Code Baseline: Stable code version
• Test Baseline: Accepted test results

Change Request Process

Submit Change Request
        ↓
Conduct Impact Analysis
        ↓
Change Advisory Board (CAB) Evaluates
        ↓
Decision: Approved/Rejected
        ↓
If Approved:
  - Update Baseline
  - Adjust Traceability
  - Notify Affected Phases
  - Execute Tests

Change Request Template:

CR-2024-001
Title: Password Policy Change
Rationale: New Security Requirements
Impact:
- REQ-015: Increase Password Complexity
- ARCH-007: Adjust Password Validator
- TEST-045: Add New Test Cases
Cost Estimate: 8 Hours
Priority: High
Approved: ✅

Comparison with Other Process Models

Classic Waterfall vs. Extended Waterfall

Criterion	Classic Waterfall	Extended Waterfall
Feedback Loops	None	Controlled Iterations
Defect Detection	Late (Testing Phase)	Early (Prototypes/Reviews)
Flexibility	Very Low	Moderate
Planning Effort	Low	High
Risk Management	Limited	Comprehensive
Documentation	Comprehensive	Extensive

Waterfall vs. V-Model

Waterfall Model:
Requirement → Design → Implementation → Test → Deployment
    ↓
    ↑
   (No Direct Link)

V-Model:
Requirements Definition ←─────── Acceptance Test
        ↓                      ↑
System Design ←─────── System Test
        ↓                      ↑
Architecture Design ←─── Integration Test
        ↓                      ↑
Module Design ←─────── Module Test
        ↓                      ↑
Implementation ────────────────

Waterfall vs. Agile Methods

Aspect	Waterfall	Agile (Scrum/Kanban)
Planning	Upfront, Detailed	Iterative, Adaptive
Changes	Expensive, Formal	Simple, Welcomed
Risk	High (End)	Low (Early)
Transparency	Phase-Based	Continuous
Customer Feedback	End Only	Each Iteration
Team Structure	Siloed	Cross-Functional

When Extended Waterfall is Appropriate

✅ Suitable for:

• Regulated Industries (Medical Devices, Automotive, Aerospace)
• Safety-Critical Systems
• Projects with Stable Requirements
• Government and Public Sector Projects
• Systems with High Compliance Demands

❌ Less Suitable for:

• Highly Volatile Markets
• Startups with Frequent Pivots
• Projects with Unclear Requirements
• Small, Experimental Projects
• User-Centric Products with Frequent UX Changes

Typical Exam Questions (with Brief Answers)

1. Difference between classic and extended waterfall? Extended = defined iterations + early QA/prototypes.

2. Role of prototypes? Validate risks early (performance, security, UX).

3. Verification vs. Validation? Verification against specification, validation against purpose/benefit.

4. How do you control iterations? Gate decision, impact analysis, change request, re-approval.

5. What is a baseline? A fixed state of artifacts at a specific point in time.

6. Purpose of traceability? Ensure every requirement is implemented and tested.

7. Change request process? Impact analysis → CAB evaluation → Approval → Implementation.

8. Advantages over classic waterfall? Earlier defect detection, better risk control, higher quality.

9. Disadvantages compared to agile methods? Less flexible, higher planning effort, late customer feedback.

10. When to use prototypes? For technical risks, unclear requirements, complex UIs.

Learning Strategy

1. Visualize Phases with Artifacts and Acceptance Criteria

Method: Create a detailed phase overview with all relevant artifacts and gate criteria.

Practical Exercise:

Phase 1: Requirements Phase
├── Artifacts: Requirements Document, Specification, Requirement Catalog
├── Activities: Stakeholder Interviews, Workshops, Prioritization
├── QA Measures: Requirement Reviews, Consistency Checks
└── Gate Criteria: ✅ All Requirements Prioritized, ✅ Business Approval

Learning Goal: Understand which artifacts are created in each phase and how quality assurance works.

2. Work Through a Feedback Loop Scenario in Detail

Method: Document a complete feedback cycle from defect discovery through re-approval.

Practical Example:

Scenario: Integration Test Fails
├── Defect Discovery: Integration Test Phase 7
├── Root Cause Analysis: Database Query Performance Issue
├── Impact Analysis: Identify Affected Components
├── Change Request: Create and Approve CR-2024-001
├── Iteration: Return to Phase 4 (Module Design)
├── Correction: Optimize Database Schema
├── Additional Tests: Add Performance Tests
└── Re-Approval: Phase 7 Passed Successfully

Learning Goal: Understand how iterations are controlled and what steps are necessary.

3. Systematically Compare Process Models

Method: Create a comparison matrix of important process models with concrete criteria.

Complete the Comparison Matrix:

Criterion	Classic Waterfall	Extended Waterfall	V-Model	Scrum
Phase Flow	Linear	Linear with Iterations	V-Shaped	Iterative
Flexibility	Very Low	Moderate	Low	Very High
Risk Management	Late	Early (Prototypes)	Early	Continuous
Documentation	Comprehensive	Extensive	Comprehensive	Minimal
Customer Feedback	End Only	Between Phases	Between Phases	Every Iteration

Learning Goal: Justify the pros and cons of each model and select the right one for a situation.

4. Create a Practical Traceability Table

Method: Build a complete traceability matrix for a small project example.

Project Example: User Registration System

Capture Requirements:
REQ-001: User should register with email and password
REQ-002: Password must be 8-20 characters
REQ-003: Email must be validated
REQ-004: Duplicate emails must be prevented

Link to Design:
ARCH-001: UserRegistrationController
ARCH-002: PasswordValidator
ARCH-003: EmailService
ARCH-004: UserRepository

Link to Implementation:
CODE-001: UserRegistrationService.java
CODE-002: PasswordValidator.java
CODE-003: EmailValidator.java
CODE-004: UserRepository.java

Derive Test Cases:
TEST-001: Register with Valid Data
TEST-002: Register with Too Short Password
TEST-003: Register with Invalid Email
TEST-004: Register with Existing Email

Learning Goal: Understand how end-to-end traceability is ensured and why it matters.

5. Practice Change Management

Method: Simulate a change request for an active project.

Exercise Scenario:

Starting Point: Project is in Phase 5 (Implementation)
Change Request: Add "Social Login" Feature

Execution:
1. Complete Change Request Form
2. Conduct Impact Analysis:
   - Technical Impact: OAuth2 Integration Required
   - Timeline Impact: +2 Weeks Development
   - Cost Impact: +8,000€
3. Assess Risks: OAuth2 Integration Security
4. Make Decision: Approved with Additional Security Tests
5. Update Baselines and Adjust Traceability

Learning Goal: Execute and document change processes professionally.

6. Exam-Specific Preparation

Method: Prepare for typical IHK exam questions by practising structured answers.

Typical exam questions to practise:

• “Describe the phases of the extended waterfall model along with key artefacts.”
• “Explain the difference between verification and validation using a practical example.”
• “How do you conduct an impact analysis for a requirements change?”
• “What role do prototypes play in the extended waterfall model?”

Train your answer structure:

1. Explain the definition or concept
2. Provide a practical example
3. Discuss advantages and disadvantages
4. Emphasise IHK-relevant aspects

7. Study Schedule for Exam Preparation

Recommended learning phases:

Week 1: Understand the Fundamentals

• Learn phases and artefacts
• Master verification vs. validation
• Review core terminology

Week 2: Deepen Your Knowledge

• Work through feedback loop scenarios
• Practise change management
• Get hands-on with traceability

Week 3: Apply What You’ve Learned

• Analyse practical examples
• Compare with other models
• Answer exam questions

Week 4: Review and Consolidate

• Revisit all concepts
• Identify weak areas
• Run a mock exam

Learning tip: Focus on the IHK-relevant aspects: structure, documentation, quality assurance, and traceability.

Key Resources

1. https://en.wikipedia.org/wiki/Waterfall_model
2. https://dl.acm.org/doi/10.1145/360248.360251

Typical Exam Questions Your Examiner Might Ask