Extended Waterfall Model

This post is a definition and explanation of the extended waterfall model, including typical exam questions, core components, and key concepts. Read a “random article” each day on this site and build your knowledge. Even if many topics feel new at first.

In a Nutshell

The extended waterfall model preserves the clear phases of the classic waterfall approach, but adds controlled feedback loops between adjacent phases and early prototyping. This catches defects sooner and systematically reduces risk.

Technical Overview

In the extended waterfall, phases still flow sequentially (requirements → design → implementation → testing → deployment/maintenance), but with important differences:

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

Key terminology:

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

Why It’s Popular in IHK Exams for Application Development Specialists

This model works well for smaller projects, which is typical during apprenticeships and internships. The extended waterfall isn’t as rigid as the classic version—it allows for corrections through feedback loops. I chose this approach for my own exam project, and it proved straightforward to explain and execute.

Key Concepts in Detail

Baselines

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

Types of baselines:

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

Example: After the requirements phase, the Requirements Baseline is created. Any later changes must be formally submitted as a Change Request.

Change Requests

Definition: A Change Request is a formal submission to modify artifacts that have already been baselined.

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, the client wants to add a new feature. This requires a Change Request with impact analysis.

Impact Analysis

Definition: Impact analysis examines the effects of a proposed change across the entire project.

Analysis areas:

• Technical Impact: Which components need modification?
• Schedule Impact: Does the project timeline extend?
• Cost Impact: Are there additional costs for development and testing?
• Quality Impact: Does the change affect system quality?
• Risk Impact: Are new technical or project-related risks introduced?

Example: When requirements change, the analysis identifies which design elements, code modules, and test cases are affected.

Traceability from Requirements to Tests

Definition: Traceability ensures full tracking of requirements through all project phases and into testing.

Traceability chain:

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

Purpose of traceability:

• Completeness verification: Every requirement is implemented and tested
• Impact analysis: Quickly identify affected areas when changes occur
• Quality assurance: Spot gaps in coverage
• Audit evidence: Meet regulatory requirements and certification standards

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	❌

Why the Extended Waterfall Model Matters in IHK Exams for Application Development Specialists

Why this approach is so important for IHK certification:

1. Structured Methodology

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

2. Quality Awareness

Quality assurance is a central theme in IHK exams. The extended waterfall integrates QA measures into every phase (reviews, tests, prototypes).

3. Documentation Requirements

The IHK demands thorough documentation. The model produces verifiable artifacts in each phase (specification documents, test reports).

4. Risk Management

Specialists must recognize 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 core competencies expected by the IHK.

6. Traceability

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

7. Practical Relevance

Many mid-sized companies still use waterfall-based approaches. The IHK prepares students for real-world working conditions.

Typical IHK exam scenarios:

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

The Extended Waterfall Model in Detail

Phase Flow with Feedback Loops

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

Detailed Phase Descriptions

Phase 1: Requirements

Goals: Capture, specify, and approve requirements in full

Deliverables:

• Specification of requirements (customer perspective)
• Statement of work (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 validation
• Traceability matrix initiation

Typical Feedback: None, as this is the starting point

---

Phase 2: System Design

Goals: Define system boundaries and specify interfaces

Deliverables:

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

Activities:

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

Quality Assurance:

• Architecture reviews
• Interface validation
• Performance estimates
• Security concepts review

Typical Feedback: Unclear requirements → Requirements phase

---

Phase 3: Architecture Design

Goals: Define detailed architecture and minimize technical risk

Deliverables:

• Component diagram
• Deployment diagram
• Data model (ERD)
• Quality goals catalog
• Architecture Decision Record (ADR)

Activities:

• Design components
• Model data structures
• Define quality attributes
• Develop prototypes (UI spikes, technology proofs of concept)
• Detail security concepts

Quality Assurance:

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

Typical Feedback: Technical uncertainties → System design

---

Phase 4: Module Design

Goals: Detail design for all modules and finalize interface contracts

Deliverables:

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

Activities:

• Design classes and objects
• Specify algorithms
• Design database structure
• Design UI (screens, wireframes)
• Plan integration points

Quality Assurance:

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

Typical Feedback: Design issues → Architecture design

---

Phase 5: Implementation

Goals: Write code to specification and apply quality measures

Deliverables:

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

Activities:

• Write code following standards
• Conduct code reviews
• Run static code analysis
• Develop unit tests
• Enable Continuous Integration

Quality Assurance:

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

Typical Feedback: Implementation issues → Module design

---

Phase 6: Test Preparation

Goals: Create comprehensive test strategy and build test environment

Deliverables:

• Test plan
• 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 plan review
• Test case coverage analysis
• Test data validation
• Test environment checks

Typical Feedback: Test gaps → Implementation/Module design

---

Phase 7: Test Execution

Goals: Demonstrate system quality and identify and fix defects

Deliverables:

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

Activities:

• Run module tests
• Run integration tests
• Run system tests
• Run acceptance tests
• Run performance tests

Quality Assurance:

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

Typical Feedback: System defects → Implementation/Architecture

---

Phase 8: Deployment

Goals: Start production operation, train users, and provide documentation

Deliverables:

• Installation guide
• User manual
• Administrator manual
• Training materials
• Support and maintenance agreement

Activities:

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

Quality Assurance:

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

Typical Feedback: Operational issues → Test execution

Key Exam Points

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

Core Components

1. Requirements phase (specification documents, acceptance criteria)
2. System design (context, interfaces, data model)
3. Architecture design (quality goals, decisions, prototypes)
4. Module design (detail design, interface contracts)
5. Implementation (reviews, static analysis)
6. Test preparation (test plan, test cases, test data)
7. Test execution (module/integration/system/acceptance tests)
8. Deployment (migration, operations, documentation)
9. Feedback loops (approved rework cycles)
10. Configuration and change management (versioning)

Verification and Validation in Detail

Verification: “Are We Building the Product Right?”

Verification checks whether the developed product conforms to its specifications.

Verification Methods:

• Code reviews: Does the code follow coding standards?
• Unit tests: Do functions meet specified requirements?
• Static analysis: Does the code contain known defects or anti-patterns?
• Integration tests: Do interfaces work as specified?
• Documentation reviews: Is 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 checks whether 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 behave as expected?
• Performance tests: Does the system achieve 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 perform 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)
        ↓                                    ↑
Module design ←───────────────────── Module test (Verification)
        ↓                                    ↑
Implementation ────────────────────────

Comprehensive Case Study: E-Commerce Platform

Project Overview

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

Phase 1: Requirements (4 weeks)

Deliverables:

Customer Requirements Document:
- 150 user stories with acceptance criteria
- 23 non-functional requirements
- 12 integration interfaces

Specification Document:
- Detailed specifications
- Technical constraints
- Timeline and cost planning

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

Gate Criteria:

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

Result: Phase approved, 2 change requests documented

---

Phase 2: System Design (3 weeks)

Deliverables:

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)

Deliverables:

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: Microservices architecture chosen
ADR-003: Event-driven for asynchronicity
ADR-007: CQRS for complex queries

Technical Spikes:

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

Gate Criteria:

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

---

Phase 4: Module Design (2 weeks)

Deliverables:

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 testing with 5 users

---

Phase 5: Implementation (8 weeks)

Deliverables:

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)

Deliverables:

Test Plan:
- 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 issues)
- Major: 8 (functional defects)
- Minor: 15 (UI issues)

Feedback:

• Security issues → back to Phase 3 (architecture)
• Performance problem → back to Phase 4 (design)

---

Phase 8: Deployment (2 weeks)

Deliverables:

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 workshops
- 45 user trainings
- 8 support guides

Go-Live Result:

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

---

Project Summary

Successes:

• ✅ Timeline met (+2 week buffer)
• ✅ Budget maintained (+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 risk
• Regular reviews are critical
• Traceability saves time during debugging

Strengths and Weaknesses

Strengths

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

Weaknesses

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

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: JIRA, Polarion, DOORS
• Test Management: TestRail, Zephyr, Xray
• Spreadsheets: Excel/Google Sheets for smaller projects
• Custom Solutions: Traceability scripts

Traceability Process

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

Change Management and Baselines

Defining Baselines

Baseline: A fixed snapshot of deliverables 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
        ↓
Perform Impact Analysis
        ↓
Change Advisory Board (CAB) Reviews
        ↓
Decision: Approved/Rejected
        ↓
If Approved:
  - Update Baseline
  - Adjust Traceability
  - Notify Affected Phases
  - Execute Tests

Change Request Template:

CR-2024-001
Title: Password Policy Update
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 Development Models

Classic Waterfall vs. Extended Waterfall

Criterion	Classic Waterfall	Extended Waterfall
Feedback Loops	None	Controlled Iterations
Defect Detection	Late (Test 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 Connection)

V-Model:
Requirements ←─────── 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, Welcome
Risk	High (End)	Low (Early)
Transparency	Phase-Based	Continuous
Customer Feedback	End	Every Iteration
Team Structure	Siloed	Cross-Functional

When Extended Waterfall Model Fits

✅ Well-Suited For:

• Regulated Industries (Medical Devices, Automotive, Aviation)
• 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 Short 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 review → Approval → Implementation.

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

9. Disadvantages vs. agile methods? Less flexible, higher planning overhead, 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 showing all relevant artifacts and gate criteria.

Practical Exercise:

Phase 1: Requirements Phase
├── Artifacts: Requirements Specification, Functional Specification, Requirements Catalog
├── Activities: Stakeholder Interviews, Workshops, Prioritization
├── QA Measures: Requirements Reviews, Consistency Checks
└── Gate Criteria: ✅ All Requirements Prioritized, ✅ Stakeholder Sign-Off

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

2. Work Through an Iteration Scenario in Detail

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

Practical Example:

Scenario: Integration Test Fails
├── Defect Detection: Integration Test Phase 7
├── Root Cause Analysis: Database Access 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 Design
├── Extended Testing: Add Performance Tests
└── Re-Approval: Phase 7 Passed

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

3. Compare Development Models Systematically

Method: Create a comparison matrix of major development models using 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	Between Phases	Between Phases	Every Iteration

Learning Goal: You can justify the pros and cons of each model and select the appropriate one.

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 shall 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

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

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

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

Learning Goal: You 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.

Practice Scenario:

Context: Project in Phase 5 (Implementation)
Change Request: Add "Social Login" Feature

Execution:
1. Complete Change Request Form
2. Perform Impact Analysis:
   - Technical Impact: OAuth2 Integration Required
   - Schedule 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: You can execute and document change processes professionally.

6. Exam-Specific Preparation

Approach: Prepare for typical chamber of commerce (IHK) exam questions by structuring your answers systematically.

Practice typical exam questions:

• “Walk through the phases of the extended waterfall model and describe the key artifacts produced in each.”
• “Explain the difference between verification and validation using a practical example.”
• “How would you conduct an impact analysis for a requirement change?”
• “What role do prototypes play in the extended waterfall model?”

Develop a consistent answer structure:

1. Explain the definition or core concept
2. Provide a concrete example
3. Discuss advantages and disadvantages
4. Emphasize aspects relevant to the exam

7. Study Schedule for Exam Preparation

Recommended learning phases:

Week 1: Build foundational knowledge

• Learn phases and artifacts
• Master verification versus validation
• Review core terminology

Week 2: Go deeper

• Walk through feedback scenarios
• Practice change management workflows
• Work through traceability exercises

Week 3: Apply concepts

• Analyze real-world examples
• Compare with other lifecycle models
• Answer practice exam questions

Week 4: Consolidate learning

• Revisit all major concepts
• Identify weak areas
• Simulate the actual exam

Learning tip: Focus on what the exam emphasizes: structure, documentation, quality assurance, and traceability.

Key Sources

1. https://de.wikipedia.org/wiki/Wasserfallmodell
2. https://dl.acm.org/doi/10.1145/360248.360251

Typical Exam Questions Your Assessor May Ask