Use what you learned in the previous lesson to solve real-world problems.

Check what you understood with a short quiz.

Write goals from the perspective of the person trying to get something done. You’ll distinguish a real user goal from a preference, complaint, task step, or proposed feature.

Use what you learned in the previous lesson to solve real-world problems.

Recognize policies that exist whether or not software is built, such as eligibility rules, approval limits, or retention periods. You’ll convert them into system behavior only when the system must enforce, check, or record them.

Use what you learned in the previous lesson to solve real-world problems.

Check what you understood with a short quiz.

Turn a user goal into a feature-level capability the system may provide, without committing to a particular screen or technology. You’ll describe what the system must enable, not the exact design of the solution.

Use what you learned in the previous lesson to solve real-world problems.

Spot phrases that smuggle in design decisions too early, such as “use a chatbot” or “send a PDF.” You’ll rewrite them as outcomes or capabilities while preserving true constraints that really must be followed.

Use what you learned in the previous lesson to solve real-world problems.

Check what you understood with a short quiz.

Write requirements that each contain one clear obligation, actor or system subject, action, object, and condition. You’ll split compound statements so each requirement can be discussed, changed, and tested on its own.

Use what you learned in the previous lesson to solve real-world problems.

Choose when a formal “shall” statement, a user story, or a job story fits the situation. You’ll express the same need in different formats and see how each format supports different conversations.

Use what you learned in the previous lesson to solve real-world problems.

Check what you understood with a short quiz.

Use INVEST to check whether a user story is independent, negotiable, valuable, estimable, small, and testable. You’ll revise oversized or vague stories so they are easier to refine and deliver.

Use what you learned in the previous lesson to solve real-world problems.

Tell the difference between what the system does and how well it must do it. You’ll classify examples as functional requirements or quality attributes such as performance, security, usability, reliability, and accessibility.

Use what you learned in the previous lesson to solve real-world problems.

Check what you understood with a short quiz.

Replace vague quality words like “fast,” “secure,” or “easy” with observable targets. You’ll write measurable conditions such as response times, error rates, permission rules, or accessibility standards.

Use what you learned in the previous lesson to solve real-world problems.

Identify limits that narrow the possible solution space, such as laws, standards, approved platforms, budgets, dates, data residency, or integration requirements. You’ll record the source of each constraint so it can be challenged or confirmed.

Use what you learned in the previous lesson to solve real-world problems.

Check what you understood with a short quiz.

Keep unknown facts from silently turning into requirements. You’ll label assumptions, dependencies, and open questions so the team knows what must be validated before committing to a requirement.

Use what you learned in the previous lesson to solve real-world problems.

Write acceptance criteria that define how someone will know a requirement is satisfied. You’ll make each condition observable, pass/fail, and tied to the requirement rather than to a hidden implementation choice.

Use what you learned in the previous lesson to solve real-world problems.

Check what you understood with a short quiz.

Use Given-When-Then scenarios to describe a starting context, an action, and the expected result. You’ll write Gherkin-style criteria for normal cases, edge cases, and business rule checks.

Use what you learned in the previous lesson to solve real-world problems.

Connect each requirement back to the business need or user goal it supports. You’ll spot orphan requirements, gold-plated features, and acceptance criteria that no longer prove the original need.

Use what you learned in the previous lesson to solve real-world problems.

Check what you understood with a short quiz.

Review this chapter with practice based on your mistakes.