Define an application around a real task.

One person requests supplies and another approves or rejects the request. Messages are scattered, so nobody knows what is pending. The desired outcome is being able to record a request and inspect its decision.

Write a sentence for each role: requesters need to check their requests; approvers need to see pending ones. Do not give both roles identical permissions merely for convenience.

Example request: identifier REQ-01, item “notebook”, quantity 2, status “pending”. Describe creation, review and what changes after a decision. Include a reason for rejection.

Record necessary fields and their origins. Avoid asking for information just because it might be useful someday. This exercise needs enough data to process and locate the request.

First release: record, list and decide requests. Possible extensions: suppliers, inventory and purchasing. Leave those extensions outside the exercise so the main journey can be checked end to end.

Include an exception: if quantity is empty, the request is not ready for review and the app explains what is missing. A brief covering only the ideal case leaves important decisions unresolved.

Copy these fields: problem; users; main task; example input; output; permissions by role; incomplete cases; first-release scope; exclusions; acceptance test.

Ask a requester and an approver to walk through the example. If they disagree about who can decide or what “approved” means, resolve it in the document before turning it into code.