Requirements Engineering for moderne Software-Teams

You can identify, in a concrete sprint timeline, where the requirements decision was made or left unmade - and explain why a retrospective diagnosis of "communication problem" addresses the symptom, not the cause.

You can explain why agile adoption didn't eliminate requirements work - only distributed it implicitly across roles and conversations - and why the user story format is a container for requirements work, not a substitute for it.

The learner can describe what requirements engineering looks like as a practiced craft - not just a set of named activities - and can identify, from observable team behavior, which of the three competencies (elicitation, specification, validation) represents their team's primary gap.

Classify any backlog item as a genuine requirement, a wish, or a solution idea - and justify the classification in one sentence.

You can identify a solution-baked backlog item by the implementation decisions it silently embeds - and reformulate the underlying requirement so that a developer can implement it without making design choices that belong to the team, not to the ticket.

You can sub-classify a genuine requirement as functional, non-functional, or a constraint - and use that classification as a signal for where it belongs in your team's process, how it needs to be written, and when it needs to be addressed.

You can distinguish between a product vision that is explicit and shared and one that is implicit and private - and identify, for any given product situation, which type exists and what structural consequence that has for writing requirements.

Use the Product Vision Board to surface implicit team disagreements about target group and core need - and distinguish between fields where a single agreed answer is required versus fields where iteration is acceptable.

Apply a completed Product Vision Board as a decision filter for incoming feature requests - and correctly classify each request as fits, doesn't fit, or needs more information, with explicit reasoning tied to Vision Board fields.

After this lesson, you can build a Stakeholder Map for a B2B SaaS product that goes beyond a name list - distinguishing primary users, secondary users, decision makers, and affected stakeholders, and using that map to decide who to interview for what kind of information.

You can formulate questions that surface behavior and context instead of collecting opinions and feature requests - and you have a concrete technique for the moment when a correctly structured interview slides back into solution-mode anyway.

You can take the raw output of a stakeholder interview - statements that mix solution requests, user needs, and constraints - identify which category each statement belongs to, and translate the user needs into formulated need statements that describe the situation and outcome without specifying the implementation; you recognize when multiple divergent requests point to the same underlying need, and when they don't.

You can identify a problem statement versus a solution in disguise, apply the Torres test to any stakeholder input, and explain why that distinction is worth making - not as a rule, but as a tool that keeps the option space open until you've understood the need well enough to close it deliberately.

You can apply the two-column analysis to a concrete product domain - mapping problem statements to solution candidates, identifying gaps, and naming the scope implications when one solution addresses more than one problem.

You understand that problem space and solution space co-evolve - and you can apply this model to Kira's full discovery output, classifying all 12 statements, distinguishing business requirements from stakeholder requirements in Tim's inputs, and identifying 3 Iteration Points where solution exploration is most likely to generate new problem knowledge.

Distinguish an activity-based backbone from a system-component backbone - and catch the structural mistake before it shapes the entire backlog.

Judge whether a story on a Story Map is too large to survive sprint planning - and split it into sprint-ready pieces without losing the user value that made it worth writing in the first place.

Draw release group boundaries on a Story Map as horizontal slices of a minimum viable user journey - not as complete Epics - and position the Map as a conversation artifact that anchors decisions without making commitments.

Identify within two minutes whether a given Acceptance Criterion has the first or second failure mode - too vague or over-specified - and articulate in one sentence what is missing.

Choose the appropriate AC format (Given-When-Then or rule-oriented) for a given story type - and write at least two ACs in that format that pass the sprint-ready test from last Lesson.

Apply a three-step edge case discovery process to a set of written ACs and identify at least two missing scenarios - concurrency, boundary, or exclusion - before a developer starts implementing.

You can identify the pre-condition that makes MoSCoW produce usable output - a shared, written failure definition - and you can use that definition to categorize a real backlog in a way that survives scrutiny rather than political pressure.

You can use the absent/present test to assign provisional Kano categories to qualitative interview data - and you can name both why that classification is a working hypothesis rather than a validated finding, and why that's still good enough to make a Release 1 decision with.

You can select the prioritization framework that answers the most dangerous question for your product stage, resolve conflicts between framework outputs with explicit reasoning, and present a defended Release-1 scope decision - including the borderline calls - in a stakeholder conversation.

Recognize the causal path from an informal quality observation to an implicit architectural decision - and name why NFRs systematically disappear in agile processes.

Turn a vague quality intention into a specific, measurable, testable NFR - and judge when a formulation is testable and when it is not.

Judge which quality attributes genuinely shape a product's experience for a given context - and distinguish those from qualities that simply need to be present, qualities that trade off against each other, and qualities that can wait.

Draft a concrete, checkable Definition of Ready from the RE artefacts the team has already produced - INVEST, acceptance criteria, and NFR constraints - whose criteria hold up as decision-making tools in Sprint Planning.

Structure a refinement meeting so that it secures requirements quality - not just estimates - and integrate the Three Amigos principle into a repeatable sprint rhythm that a four-person team can run in 45 minutes.

Recognize when a Definition of Ready becomes a stage-gate, apply the gate / conversation-starter distinction to a team's specific criteria, and use precise language to send a story back to the backlog without creating friction.

Distinguish a complete Requirements-Set from an ad-hoc backlog - and articulate precisely what changed between ten weeks ago and today, using the language of Strong, Thin, and Gap.

Locate your own team on the RE maturity spectrum using observable symptoms - not self-assessment of intent - and identify the one gap that produces the most pain today.

Choose the highest-ROI RE practice for your team's specific pain point and design a one-sprint experiment that makes the result visible without requiring a process mandate.

Introduce one RE practice to your team in a way that lands as a solution to a known problem - not as process overhead - using three practitioner tools.