This unit settles what everyone is actually talking about when they say "requirement".

• Requirement, stakeholder and system as the load-bearing terms
• Functional requirements and quality requirements told apart
• What weak requirements engineering costs a project
• The requirements engineer's role alongside the rest of the team

This is where you get the nine principles every later decision can be measured against.

• Value contribution, stakeholders and shared understanding as the starting point
• Context, problem and solution kept properly apart
• Why requirements change, and what that means for how you work
• Iteration and validation as continuous activity rather than a phase

This unit decides the form a requirement gets written down in.

• Natural-language requirements and the language traps that come with them
• Sentence templates as a tool against ambiguous wording
• Model-based documentation for goals, processes and data
• Quality criteria a work product is checked against

Here you get requirements out of the heads of the people involved and into a state that holds.

• Survey, observation and creativity techniques, and when each one fits
• Sources of requirements beyond the people in the room
• Validation for completeness, freedom from contradiction and testability
• Spotting conflicts between stakeholders, classifying them and resolving them

This unit fits the approach to the project rather than the other way round.

• The factors that shape an RE process: context, goal, constraints
• Plan-driven, agile and mixed approaches compared
• How requirements engineering fits into the development process

This is about everything that happens after the writing down.

• Attributes and views that keep a large body of requirements manageable
• Prioritisation as a decision about order and about what gets dropped
• Traceability from the source through to implementation
• Versioning, and handling change while the project runs

The final unit places what tools can do and what they cannot fix.

• Types of RE tool and what each one is built for
• Selection criteria taken from how you actually work
• What introducing a tool costs in effort further down the line