FI-AE 03 Anforderungsanalyse und Lastenheft (EN)

FI-AE 03 Requirements Analysis and Statement of Work

In this module, you will learn the systematic collection and documentation of software requirements. You will understand how to capture, prioritize, and translate functional and non-functional requirements into binding documents. The ability to create precise statements of work and specifications forms the foundation for successful software projects.

You will learn to prioritize requirements using the MoSCoW method, formulate user stories effectively, and clearly distinguish between statements of work and specifications. These competencies are essential for managing stakeholder expectations and defining project objectives unambiguously.

Concepts and Background

Functional Requirements

Describe what the system should do. They answer the question "What should the system be able to do?" and are directly testable. Example: "The system must allow users to authenticate with email and password."

Non-functional Requirements

Define properties of the system, how it should do something. They relate to quality, performance, security, and usability. Example: "The login function must respond within 2 seconds of request."

MoSCoW Prioritization

Method for categorizing requirements into four priority levels: Must-have (essential), Should-have (important), Could-have (useful), and Won't-have (not in this version). It helps in decision-making with limited resources.

Statement of Work (Lastenheft)

Document that describes requirements from the client's perspective. It is binding and serves as the basis for contract formation. The statement of work is created and released by the client.

Specification (Pflichtenheft)

Detailed technical specification that represents the implementation plan for the development team. It is based on the statement of work and describes how requirements should be technically implemented. The specification is created by the contractor.

Practical Steps

1. Conduct stakeholder interviews to capture all relevant perspectives. This ensures that no important requirements are overlooked.
2. Formulate functional requirements as concrete, testable statements. Use active verbs and avoid vague formulations.
3. Convert non-functional requirements into quantifiable criteria. For example: "The system must be available 99.9% of the time" instead of "The system must be very stable".
4. Prioritize and document requirements using the MoSCoW method. Create a table with all requirements and their respective priority levels.
5. Create user stories in the format "As [Role] I want [Functionality] so that [Benefit]". Add acceptance criteria if necessary.
6. Structure the statement of work according to DIN 69905 and have it formally approved. Include at least project objectives, functional and non-functional requirements, and acceptance criteria.
7. Create the specification as the technical implementation of the statement of work. Define architecture, interfaces, data models, and implementation details here.
8. Link requirements in a traceability matrix to ensure that each requirement feature is implemented in the system.
9. Conduct regular reviews of requirements to capture changes and keep the documentation up to date.

Common Pitfalls

Further Resources

• DIN 69905 - Project Management in Engineering - Official standard for statements of work and specifications
• IONOS Digital Guide - Formulating User Stories Effectively - Practical guide to creating user stories
• Scrum.org - Requirements Management - Resources on requirements management in an agile context
• PMI - Prioritization Techniques: MoSCoW Method - Official explanation of MoSCoW prioritization
• Federal Ministry for Economic Affairs and Energy - Guideline for Statements of Work and Specifications - Practice-oriented guide with examples

Knowledge Check

Four questions for self-assessment. Click on each question to see the correct answer and explanation.

What is the main difference between a statement of work and a specification?

• A) The statement of work is more detailed than the specification
• B) The statement of work is created by the client, the specification by the contractor
• C) The specification contains only non-functional requirements
• D) The statement of work serves for internal planning, the specification for client communication

Correct Answer: B. The statement of work describes requirements from the client's perspective and is created by the client, while the specification represents the technical implementation by the contractor. Option A is incorrect because the specification is more detailed. Option C is incorrect because both also contain functional requirements. Option D is incorrect because the statement of work serves for client communication.

Which MoSCoW prioritization category describes requirements that are essential for basic functionality?

• A) Should-have
• B) Could-have
• C) Won't-have
• D) Must-have

Correct Answer: D. Must-have requirements are essential for basic functionality. Should-have requirements are important but not critical. Could-have requirements are useful but optional. Won't-have requirements will not be implemented in this version.

Which statement correctly describes a functional requirement?