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.