CHAPTER TWO

Business requirements, product scope, and user stories

Chapter 1 described Otahque’s problem, people, and first version in plain language. This chapter turns that brief into requirements precise enough to design, build, and check.

By the end of the chapter, you will be able to:

• separate a need from a proposed solution, and evidence from a hypothesis;
• define the scope of a first release and follow its journeys;
• write user stories with observable acceptance criteria;
• state product rules for capacity, timing, and repeated actions;
• describe quality expectations without inventing measurements;
• trace a requirement to a planned check.

You will produce three working documents: a business requirements document (BRD), a product requirements document (PRD), and a traceability register. All three are review drafts, not approved specifications.

2.1 Needs and agreed outcomes

Sam has a list of workshop registrations. Raj has sent a cancellation message, but the list still includes him. Sai asks whether her registration succeeded. Before deciding what to build, we need to say whose difficulty we are addressing and what a useful result would look like.

Chapter 1 gave us a short brief. We will now turn it into a business requirements document, or BRD: a shared record of the problem, the people affected, the outcomes sought, and the boundaries of the work. Its purpose is to make our understanding available for review. Writing it does not make its contents agreed.

Who has a stake in the result?

A stakeholder is someone who is affected by the product or has a responsibility for it. A person can be a stakeholder without using every screen. The person responsible for community access, for example, has a stake in who may manage an event.

Sam needs a dependable registration list for planning. Sai needs to know whether her place is confirmed. Raj needs his cancellation to be reflected in the record. Soni needs clear event information before she decides to register. These names make our examples concrete; they do not represent four special accounts that the application must create.

Chapter 1 described three roles: visitor, attendee, and organizer. From this chapter on, we need two more words. A member is a person with an Otahque account. An attendee is a member who holds a registration for a particular event. Sai is a member whenever she signs in, and an attendee of the workshop while her registration is active. Soni remains a visitor until she creates an account.

The community administrator is a new stakeholder. The administrator manages accounts and access, including who may organize events. We still need to decide how organizers are appointed. Naming a responsibility helps us identify a question; it does not answer every permission question.

Separate a need from a proposed solution

Suppose Sam says, “Send me a spreadsheet every evening.” That is a proposed solution. Ask what decision the spreadsheet supports. Sam might need to prepare enough seats using the current registrations. An evening export could already be out of date when Raj cancels the next morning.

The useful outcome is that Sam can plan from the current registration record. The product behaviour that supports it is access to an up-to-date list for the event he manages. The format of an export can be decided later. This distinction keeps the reason for a feature visible when its design changes.

Que. 1 Does “Sam needs a nightly spreadsheet” fully describe the business need?

Answer. No. It names a possible delivery method. We must first establish what Sam needs to decide and how current the information must be. Here, the desired outcome is reliable preparation using current registrations.

Trust, privacy, and accountability

Trust here has a concrete meaning: Sai’s displayed registration status and Sam’s list must agree about whether she has a place. If Raj cancels successfully, both views must reflect his cancellation. Conflicting answers can lead to unnecessary travel, mistaken preparation, and extra messages to resolve the uncertainty.

Privacy means setting boundaries around personal information. Soni needs public event details to decide whether to attend; that need does not justify showing her everyone else’s registration information. Attendees manage their own participation, and organizers manage their assigned events.

Accountability means being able to establish who was responsible for an important action. If access to an event is changed, the community needs a way to investigate who made that change. We are recording the need here. Later chapters will decide which records support it, who may read them, and how long they are kept.

What do we actually know?

Our workshop is a fictional teaching example. It makes the problem understandable, but it is not evidence that real organizers experience the same difficulty or would adopt Otahque. Evidence is information we have actually gathered, such as an observed workflow or an interview record, with its source and context.

A hypothesis is an idea we intend to investigate. “Small volunteer-led communities would spend less time reconciling registrations if the records stayed connected” is a hypothesis. Independent technical communities and college clubs are proposed audiences to investigate. Neither demand nor time savings has been established.

A useful investigation would ask an organizer to walk through a recent cancellation: where it was received, which records changed, who updated them, and what remained uncertain. Record what happened separately from our interpretation. Do not turn one person’s account into a claim about all communities.

To investigate time savings, first measure the current work for a defined task, such as reconciling registrations before an event. That starting measurement is a baseline. Later, compare the same task under comparable conditions. We have no such measurement yet, so our draft must not promise a percentage reduction.

Constraints and open questions

A constraint is a boundary our solution must respect. For the book’s first release, we have chosen one community, free events, and individual registration through member accounts. These are project decisions, not findings from customer research. They keep the first product small enough to build and verify.

Closing times and re-registration after cancellation remain open questions. Record them instead of quietly choosing answers while writing code. Later volunteer assignments and sponsor reporting are possible extensions; they do not grant additional access or expand this first release.

Que. 2 Can we write “organizers save two hours per event” in the BRD?

Answer. Not as an established result. We have no measurement supporting it. Record the proposed benefit and the investigation needed to assess it instead.

Our first structured BRD

Table 2.1 brings the discussion into one reviewable record. Each row has a separate purpose, so a reader can distinguish what the product is for from what we have assumed and what is still undecided.

Try it yourself

Write three sentences about Raj’s cancellation: the desired outcome, a boundary that must hold, and one unresolved question. Check that each sentence serves a different purpose.

Que. 3 What could those three sentences say?

Answer. Outcome: Raj can tell that his cancellation succeeded. Boundary: Raj can cancel only his own registration. Open question: until what time may he cancel? The first explains the benefit, the second limits authority, and the third identifies a decision still needed.

Next: in Section 2.2, we will define the first-release scope more precisely and follow the attendee and organizer journeys through it.

2.2 Scope and journeys

Sam agrees that current registrations would help with workshop preparation. Then more ideas arrive: could Otahque also issue certificates? Someone suggests a waiting list, and someone else asks for sponsor reports. Each idea may be useful. We still need a clear answer to a smaller question: what will the first release let people finish?

Scope is the boundary of the work we are choosing to do. It states what belongs in a release and what stays outside it. A release is a version of the product made available for use. For Otahque, the first release must connect event information, registration, and cancellation into a complete, dependable experience.

Choose a small but complete first release

A minimum viable product, often shortened to MVP, is a small usable product through which we can learn whether an approach meets a real need. “Minimum” concerns how much we include. It does not excuse incorrect registration counts, unclear results, or access to someone else’s private information.

Our first release serves one community running free events. A person can browse published events without registering for one. To register for a place, the person uses a member account. An account lets the product associate registrations with the person who can view and manage them. We have not yet chosen the account screens or their technical implementation.

Included in the first release

Visitor: browse published events and read the details needed to decide whether an event is suitable, including when and where it takes place.

Member: create an account, sign in, register for an event, see the result, return to registration history, and cancel their own registration when cancellation is allowed. The same person may browse as a visitor before signing in.

Organizer: prepare an event draft, preview it, publish it, edit an assigned event, and view its current registrations. A draft is work in preparation; publishing makes the event available to visitors. Exact rules for changing a published event still need to be settled.

Administrator: manage accounts and access. This responsibility supports the other journeys, but it does not yet settle how someone is appointed as an organizer or which exceptional actions an administrator may take.

The release must also respect event capacity, registration times, and ownership of records. Capacity means the number of available places. A small feature list still needs correct behaviour when requests repeat or two people seek the last place. We will specify those cases in Section 2.4.

Que. 1 Can we postpone cancellation because registration already works?

Answer. Not within our chosen first-release scope. Raj needs to manage his participation, and Sam needs the current record to reflect a successful cancellation. Deferring cancellation would leave that agreed journey incomplete.

Keep later work visible

Deferred means deliberately left for later consideration or a later release. Waiting lists, reminders, check-in, imports and exports, certificates, volunteer assignments, and sponsor reporting are outside this first release. Recording them prevents useful ideas from quietly becoming extra work in the current step.

For example, registration records that a person has a place. Check-in records evidence of arrival at an event. Our first release handles registration; it does not claim to establish who actually attended. A registration history must not be described as an attendance history.

Multi-community support, subscription billing, team events, and jobs have later places in the book. Their presence in the curriculum does not put them into the first product release. Paid event tickets are also outside our free-event boundary. A deferred idea is not automatically a promise that we will build every proposed extension.

If a proposed addition becomes essential, revisit the scope explicitly. Identify the need, the extra work, and what would move out or change. Adding a certificate button, for example, would raise questions about eligibility and attendance evidence that registration alone cannot answer.

Follow an attendee’s journey

A user journey is the sequence of steps a person takes to reach an outcome. It helps us find gaps between features. A list containing “events”, “accounts”, and “registration” does not tell us whether Soni can move from reading an event to knowing that her place is confirmed.

Start with Soni as a visitor. She opens the published event details and checks whether the workshop suits her. If it does and she chooses to register, she creates an account or signs in to an existing one. After signing in, the event must remain easy to find so she can continue her task.

Soni requests a place. The request is not itself confirmation: Otahque must determine whether registration is allowed and show a clear result. If it succeeds, Soni can later find the registration in her history. If the event is full or registration has closed, the product must explain that no place was confirmed. The first release does not silently put her on a waiting list.

Sai’s confirmation question provides a useful check on this journey: can a member return later and establish the current result? Raj adds another branch. He opens his existing registration and requests cancellation. When cancellation succeeds, Raj sees the cancelled status, and Sam’s current registration list reflects the change. The cancellation deadline remains an open rule for Section 2.4.

Que. 2 Does clicking Register mean Soni has a place?

Answer. No. The product must check whether it can confirm a place and show the result. The journey must explain unsuccessful requests as well as successful ones.

Follow an organizer’s journey

Sam signs in with permission to manage the workshop. He prepares its details as a draft, previews what visitors will see, corrects mistakes, and publishes it. Previewing helps him inspect the information before making it public; a preview is not publication.

Once the event is published, visitors can find it, and members can request places while registration is allowed. Sam returns to the current registration list to prepare for the event. A successful registration adds an active participant; a successful cancellation removes that person from the current active list. The member’s history can still show the cancellation.

This is where the two journeys meet. Soni’s successful registration must be visible to her and reflected in Sam’s list. Raj’s successful cancellation must be reflected in both places too. Drawing the journeys separately must not lead us to treat them as unrelated records.

Sam may also need to edit published details. We include that capability while keeping its detailed rules open: which changes are allowed after people register, and how should affected members learn about them? A journey exposes such questions; it does not authorize us to invent a notification policy or automatically add reminders.

Que. 3 Can Sam manage another organizer’s event simply because he is an organizer?

Answer. No. Our scope gives organizers responsibility for assigned events. The journey must preserve that boundary whenever Sam opens, edits, or views registrations for an event.

Review the scope through a complete task

To review the first release, follow one event from Sam’s draft through publication, Soni’s registration, a later status check, and Raj’s cancellation of his own registration. At each step, name what the person does, what result they need to see, and who else needs the record to change. Keep unresolved timing and event-change rules beside the journey for the next sections.

Try it yourself

Sam asks for a sponsor attendance report. Classify that request as included, deferred, or unresolved in the current scope. Then identify one included behaviour that would help him prepare for the workshop today.

Que. 4 How should we classify Sam’s request?

Answer. Sponsor reporting is deferred. Attendance evidence also requires later capabilities; registrations alone cannot prove attendance. An included behaviour is viewing current registrations for Sam’s assigned workshop. An unresolved rule, by contrast, is the exact cancellation deadline for that included workflow.

Readiness checkpoint: explain the first-release boundary, walk through a successful registration and one unsuccessful result, and show where the attendee and organizer journeys share a change.

Next: in Section 2.3, we will turn parts of these journeys into user stories and acceptance criteria: statements of need and observable conditions for correct behaviour.

2.3 Stories and acceptance criteria

Sai returns to Otahque after requesting a workshop place. The registration page looked reassuring, but she still wants to know: “Am I on the list?” Our journey identifies that moment. We now need a short description of the need and clear conditions for deciding whether the product meets it.

Write the need from the person’s point of view

A user story describes a capability someone needs and the reason it matters. A useful starting pattern is “As a [person or role], I want [capability], so that [benefit].” The pattern helps us ask who, what, and why. Filling in its blanks does not make an unclear requirement useful.

For Sai: “As a member, I want to see the current status of my registration, so that I know whether I have a place.” This keeps the benefit visible. “As a user, I want a green message” chooses a display detail without saying what the person must learn.

For Raj: “As a member, I want to cancel my own registration, so that my decision is reflected in the event record.” For Sam: “As an organizer, I want to see current registrations for my assigned event, so that I can prepare for the people who have places.” These stories describe related needs without combining every action into one oversized story.

Stories are not only about registration. For Sam: “As an organizer, I want to preview my event before publishing it, so that visitors see correct details.” For Soni: “As a visitor, I want to read a published event’s date, time, place, and intended audience, so that I can decide whether to register.” Publication and browsing belong to the same first release as registration.

Describe observable conditions

Acceptance criteria are conditions a behaviour must satisfy before we accept it as meeting a requirement. Observable means that someone can inspect the result. “Registration works properly” is too vague. “After a successful registration, Sai sees a confirmed status and appears once in Sam’s active registration list” gives us something to check.

One way to write a concrete example is Given, When, Then. Given describes the starting situation. When describes an action or event. Then describes the expected result. This is a writing aid, not a requirement to use a particular testing tool.

Given: the event is published, registration is open, Sai is signed in, she has no active registration for it, and a place remains. When: Sai requests a place. Then: she receives confirmation, can find that registration later, and appears once in the assigned organizer’s current list. The active count increases by one.

Given: Sai already has an active registration for that event. When: she submits another registration request. Then: the product shows her existing registration; it does not create another active place or increase the active count. Repeating an action is common, even without anyone trying to cause harm.

Criteria for publishing an event

Publication needs criteria too, because visitors rely on the details Sam publishes.

Given: Sam is assigned to a draft event with a title, description, start time, timezone, place, capacity, and registration times. When: he previews it. Then: he sees the details as visitors will see them, and the event is still not visible to visitors.

Given: the same draft is complete and valid. When: Sam publishes it. Then: visitors can find and read it, and members can request places once registration opens.

Given: a draft is missing its timezone, or its registration would close after the event starts. When: Sam tries to publish it. Then: publication is refused, the event stays a draft, and the message names each detail he must correct without discarding the details he has already entered. Section 2.4 explains the timing rule behind this example.

Given: an event is still a draft. When: Soni, or any other visitor, looks for it. Then: it does not appear, and nobody can request a place for it.

Describe unsuccessful and forbidden actions

Given: all places are taken. When: Soni requests a place. Then: no new active registration is created, the active count stays unchanged, and she receives an explanation that no place was confirmed. The first release does not offer an unplanned waiting list.

Given: Raj has an active registration and cancellation is allowed. When: he cancels it. Then: Raj sees a cancelled status, the registration no longer consumes capacity, and Sam’s active list excludes it. Raj’s history can still show the cancelled registration. Removing a place from the active count need not erase its history.

An abuse case describes an attempt to use the product in a harmful or unauthorized way. Suppose Sai tries to cancel Raj’s registration by changing a reference in a request. The expected result is rejection: his registration and the count remain unchanged, and she receives no private registration details. Hiding a button does not define this boundary; every attempt must respect ownership.

Given: Sam is assigned to one event but not another. When: he attempts to open the other event’s registration list or change its details. Then: access is denied, and nothing is changed. A role name alone does not explain which records a person may manage.

Keep criteria separate from implementation

These criteria say what must be true. They do not select database tables, page layouts, or Python functions. Later we will implement checks and write executable tests. For now, we can review examples on paper and find contradictions before they spread into code.

Que. 1 Is “show a green success message” enough to accept registration?

Answer. No. The message must agree with the saved registration and the organizer’s list. A colour or message alone cannot establish that a place exists.

Que. 2 Why include a request that should be rejected?

Answer. A useful requirement defines its boundaries. Full events, duplicate requests, invalid publication, and attempts to alter another person’s registration reveal whether the product protects capacity, accuracy, and ownership.

Try it yourself

Write a Given/When/Then example for a visitor who tries to register without signing in. State what must not happen as well as what the visitor should see.

Que. 3 What is one suitable answer?

Answer. Given a visitor who is not signed in, when the visitor requests a place, then the product asks the visitor to create an account or sign in and does not create a registration yet. Returning from sign-in must still allow the person to continue with the intended event.

Next: Section 2.4 makes the timing, capacity, and repeated-action rules behind these examples explicit.

2.4 Product rules and edge cases

Sam’s workshop has twenty places. Nineteen are already taken. Two members each see one place remaining and request it. Both requests look reasonable on their own. The product must still avoid confirming twenty-one people.

A product rule states a condition the product must enforce consistently. An edge case is a situation near a boundary or outside the most straightforward path: the last place, the exact closing instant, or a repeated cancellation. These cases belong in requirements because they affect what a correct result means.

Separate fixed boundaries from proposed policies

The project already requires one active registration per member and event, capacity protection, personal ownership, and access limited to assigned organizers. The following timing and re-registration policies are a proposed working specification for review. They make our examples precise without claiming that real stakeholders have approved them. We have not assigned actual event deadlines.

An active registration means a currently confirmed place that consumes capacity. A cancelled registration does not consume capacity. Neither status proves physical attendance, and neither says that a person received a meal, a certificate, or any other item. Those are different facts for later workflows.

Opening and closing boundaries

Proposed policy: each event has three times: when registration opens, when it closes, and a cancellation deadline. Opening must be earlier than closing. Closing and the cancellation deadline must be no later than the event’s start. The organizer must supply valid values before publication. The exact choices depend on the event and remain to be agreed.

Registration is allowed at or after opening and strictly before closing. At the closing instant, it is closed. Cancellation is allowed strictly before its deadline. These decisions use Otahque’s own clock, not the clock on a member’s phone or laptop, so changing the time on a device must not extend a deadline.

For an illustrative event whose registration closes at 18:00 in its stated timezone, a request processed at 17:59:59 is before closing; one processed at 18:00 is not. This is an example of the boundary, not a deadline selected for Otahque’s events. A page opened earlier is not a promise that registration remains open when the request is processed.

Cancellation may remain open after registration closes if the configured times allow it. Raj can then release a place, but that release does not reopen registration. A place being free and a place being available to book are different conditions.

Count places, not clicks

Capacity is a positive whole number of places. Available capacity is the configured capacity minus the number of active registrations. For twenty places and nineteen active registrations, one place remains. A request that is refused must not change that count.

An invariant is a condition that must always remain true. Our capacity invariant is that the active registration count never exceeds capacity. Another invariant is that a member has at most one active registration for the same event. Repeated clicks, retried requests, and simultaneous requests must preserve both.

When two people compete for the last place, at most one can receive a new confirmed registration. If both requests are otherwise eligible and processing succeeds, one succeeds and the other receives a full-event result. We do not promise that the person who clicked first on their own device wins the place. An unexpected failure must not result in two confirmations.

Cancellation and registering again

A successful cancellation changes an active registration to cancelled and releases exactly one place. Repeating the cancellation leaves it cancelled and releases no additional place. If Raj retries after the deadline but his earlier cancellation already succeeded, show him the current cancelled result; do not pretend a second cancellation occurred.

Proposed re-registration policy: a member may request a place again after cancellation only when the ordinary registration conditions still hold, including an open window and spare capacity. A previous place is not reserved. The product retains enough history to explain the cancellation and the return, while allowing at most one active registration. Whether one record changes status or several records represent that history is a later design question.

If a cancellation and a new registration happen close together, the product must use a consistent count. Soni may obtain the released place only after Raj’s cancellation has taken effect. These are concurrent actions: actions whose processing overlaps in time. We have described the required outcome without choosing the database technique; Chapter 33 returns to it.

Event changes and authority

Only an assigned organizer may perform the ordinary event-management actions. Reducing capacity below the current active count must be rejected; silently removing members is not an acceptable way to make the count fit. A draft event must not accept registrations. Revoking organizer access must stop future attempts to manage that event.

Some decisions need more than a convenient default. We must agree how event cancellation works, which published details may change after people register, and how affected members are informed. We must also define organizer appointment, exceptional administrator actions, and any permitted corrections. These are explicit release blockers for the affected workflows, not permission to improvise in code. Until they are resolved, a draft test for changing an event must not claim that these policies are complete.

Que. 1 Raj cancels when registration is already closed. Can Soni automatically take his place?

Answer. No. Cancellation releases capacity, but a new registration still needs an open registration window. Free capacity does not override the closing rule.

Que. 2 The same cancellation arrives twice. How many places are released?

Answer. One. The first successful change releases the place. The repeated request reports the cancelled state without changing capacity again.

Try it yourself

A fictional event has capacity twenty and nineteen active registrations. Raj, who holds one of those nineteen places, cancels successfully. Two other eligible members then register successfully while registration remains open. Calculate the active count and available capacity after each step.

Que. 3 What counts should we expect?

Answer. Initially: nineteen active and one free. After Raj cancels: eighteen active and two free. After one new registration: nineteen active and one free. After the second: twenty active and none free. A further request must not increase the count.

Next: Section 2.5 describes how usable, understandable, and dependable these behaviours need to be, then gathers the requirements into a working document.

2.5 Quality expectations and the product requirements document

Sai can register, but the result is unreadable on her phone. Raj can cancel with a mouse, but he cannot reach the control using a keyboard. Sam sees an event time without a timezone. A feature may exist and still fail the person trying to use it.

A functional requirement describes what the product does, such as cancelling a registration. A quality requirement describes how well or under what conditions it must do it, such as making cancellation usable without a mouse. Both need observable checks. “Fast”, “secure”, and “easy” are starting concerns, not finished specifications.

Make quality observable

For usability, propose this review task: give a new reader the event page and ask the reader to find the date, time, location, and registration result without coaching. Record where the reader hesitates. A sensible target is completion without assistance; whether our design achieves it must be observed, not assumed.

For accessibility, require the main journeys to work using a keyboard, with visible focus and understandable control names. Labels must explain form fields. Errors must identify what needs correction, and status must be conveyed in words rather than colour alone. Check the page with enlarged text and on a narrow screen; content and controls must remain reachable. These are initial product checks, not a claim of accessibility certification or exhaustive coverage.

For time clarity, show the date and timezone wherever a person acts on an event time or deadline. The event details, registration status, and organizer view must refer to the same intended instant. Test with a reader whose device uses a different timezone. A bare “6 pm” leaves too much for the reader to infer.

For privacy, visitors see published event information, members see their own registration details, and assigned organizers see only the information necessary to manage their events. Test attempts to read another member’s record and an unassigned event’s list, not just whether links are hidden. Required identity and contact fields and retention periods still need explicit decisions before we collect real people’s data.

Reliability includes uncertain outcomes

Imagine that Raj requests cancellation and the connection fails before the result appears. The product may have completed the action even though he did not receive the response. A useful message must not claim success or failure without knowing. Let Raj check his current registration status and retry safely if needed. Repeating the request must not release a second place.

The signed-in registration history is a way to recover the current result without relying on a separate message. Email reminders are outside this release. If the service itself is unavailable, an error page must not promise a confirmed place or manufacture an offline registration. A manual fallback, if adopted later, needs an owner and a reconciliation procedure before it can become an alternative booking route.

Set performance targets with a measurement plan

Responsiveness matters, but “instant” cannot be tested consistently. Before choosing a numerical target, define which action is timed, when timing starts and stops, what device and connection are used, and how many people are active. Record both ordinary and busy-event conditions. The twenty-place teaching example is a capacity example, not proof of a supported traffic level.

The first draft therefore records a requirement to measure event viewing, registration, and cancellation under an agreed workload. Response-time and availability targets remain open until that workload and the operating environment are chosen. Do not replace missing evidence with invented measurements. Regardless of speed, the capacity and ownership rules must hold.

Also define limits for user-supplied content before implementation: which fields are required, how long text may be, and how invalid input is reported without losing valid work. Exact limits need review with realistic event descriptions. A limit is useful only when its purpose, enforcement, and error behaviour are clear.

Assemble a product requirements document

A product requirements document, or PRD, gathers what the product must do, the rules it must follow, its quality expectations, and the questions still awaiting decisions. The business requirements document explains the problem and desired outcomes. The PRD connects those outcomes to behaviour that we can design and check. Neither document becomes approved because it has a formal name.

Table 2.2 summarizes our working PRD. It is a review draft for the first learning release, not a completed implementation or a launch authorization.

Account access, event publication, and registration form one connected release; none may silently bypass the others’ boundaries. When the project assigns responsibility for a decision, record that person beside it. We have not invented named approvers.

Que. 1 Is “the page is secure” a useful acceptance criterion?

Answer. It is too broad. Replace it with concrete conditions, such as refusing an attempt to read another member’s registration without disclosing its private details. That check covers one boundary; it does not prove the whole product is secure.

Que. 2 Does a missing response prove that Raj’s cancellation failed?

Answer. No. The action may have completed before the connection failed. The product needs a way to show the current status and handle a repeated request safely.

Try it yourself

Rewrite “event times should be clear” as a requirement with a check. State what evidence you would record.

Que. 3 What would a useful answer include?

Answer. Show the event date and timezone beside the time and relevant deadlines. Inspect the event and registration views with a device set to another timezone, confirming that they describe the same instant. Record the displayed values and any mismatch; do not merely mark the task “looks fine”.

Next: Section 2.6 links our requirements to review scenarios so we can see what each planned check is meant to protect.

2.6 Traceability and review

We now have a problem statement, scope, journeys, stories, criteria, and product rules. Keeping them in one chapter is helpful, but we also need to find their connections. If cancellation changes, which needs and checks should we revisit?

Traceability means being able to follow a requirement back to its reason and forward to the work and evidence that address it. It prevents a check from becoming an isolated task whose purpose nobody remembers. It also reveals a requirement for which no meaningful check has been planned.

Give requirements short names

Clear sentences come first. Once we need to refer to them repeatedly, short identifiers help. In this chapter, BR means business requirement and PR means product requirement. The number identifies an entry; it does not indicate priority. These labels belong to this working set, not to an external standard.

BR-1: attendees can establish and manage their current participation. BR-2: organizers can prepare from current registrations. BR-3: people’s information and responsibilities stay within defined access boundaries. These are concise references to the needs already explained, not additional product scope.

PR-1: eligible registration produces one current confirmed place, visible to the member and the assigned organizer. It supports BR-1 and BR-2. Check a successful registration and a repeated request; inspect the member’s status, the organizer’s list, and the active count.

PR-2: an allowed cancellation releases one place and leaves a clear cancelled status, even when the request repeats. It supports BR-1 and BR-2. Check the first cancellation, its repetition, and recovery after a lost response.

PR-3: competing requests cannot push active registrations beyond capacity. It supports BR-1 and BR-2 because confirmation must be dependable. Check two otherwise eligible members seeking the last place; inspect both outcomes and the final active count.

PR-4: members access their own registration information, and organizers manage only assigned events. It supports BR-3. Check forbidden reading and writing attempts as well as allowed actions. Refused attempts must not change records or reveal private details.

Two more labels cover the rest of the release. PR-5: only a complete, valid draft can be published by its assigned organizer, and visitors see only published events. PR-6: organizer access is granted or removed only through the administrator’s workflow. PR-5 supports BR-1 and BR-2; PR-6 supports BR-3.

Connect controls to evidence

A control is a measure that helps enforce a rule. For PR-4, checking access whenever protected information is read or changed is a planned control. For PR-2, allowing only an active registration to release a place is a planned control. We will choose their implementation later, then test both permitted and refused actions.

A scenario is a concrete situation we use to examine behaviour, such as Raj submitting the same cancellation twice. A test executes a check against an implementation. Evidence records what actually happened: the version examined, the starting data, the action, the observed result, and whether it matched the expectation. A written scenario is not an executed test, and a requirement is not evidence of its own satisfaction.

For the cancellation scenario, a future evidence note might record the event’s capacity, the initial active count, Raj’s initial status, both of his requests, and the final status and count. Until that experiment runs, its status is “planned”. We have written no Django application in this chapter, so we have no application-test results to report.

The working register

Table 2.3 brings these links together. Every row is planned; none has been executed. Extend the register as requirements become precise, and mark an open decision as open rather than attaching a passing result to an undefined policy.

Review consistency before advancing

Read the attendee and organizer journeys together. Confirmation must agree with the active list. Cancellation must release one place without erasing the ability to explain its result. A full event must refuse a new place. Closing registration must remain effective even if a cancellation later creates spare capacity. Registration history must not be mistaken for attendance evidence.

Then inspect the scope boundary. A scenario that automatically sends reminders, promotes a waiting-list member, or issues a certificate has introduced a deferred capability. Either remove that behaviour from the first-release scenario or explicitly reopen the scope decision. Do not smuggle it in through an expected result.

Finally, review the decision register. The first release cannot be declared ready while its affected event-change policies, required data, or operational targets are undefined. We can still learn how the web works and prepare to implement incrementally. An open product decision is a visible dependency, not a reason to pretend the whole learning path has stopped.

A closing workshop exercise

Sam’s published workshop has twenty places and nineteen active registrations, including Raj’s. Registration and cancellation are both open. Sai already has a confirmed place and submits again. Raj then cancels twice. Soni and another eligible member then request the two remaining places, and both requests complete successfully.

Before reading the answers, write the final active count, what each person should see, two requirements involved, and one forbidden-action check. Then list one decision from this chapter that still needs review before the affected feature is implemented.

Que. 1 What should the final active count be?

Answer. Twenty. Sai’s repeated request leaves nineteen active. Raj’s first cancellation reduces that to eighteen; his repeated cancellation leaves eighteen. The two new successful registrations bring the count to twenty. No place is released or consumed twice.

Que. 2 What results should people see?

Answer. Sai sees her existing confirmed registration. Raj sees a cancelled status. Soni and the other successful member each see confirmation. Sam’s active list contains twenty registrations, includes the two new members, and excludes Raj’s cancelled registration.

Que. 3 Which requirements and forbidden-action check apply?

Answer. PR-1 covers Sai’s single active registration; PR-2 covers Raj’s cancellation releasing one place. PR-3 protects the capacity boundary. For PR-4, attempt to cancel Raj’s registration while signed in as another member: the request must be refused without changing the record or disclosing private details.

Que. 4 Does completing this exercise establish that Otahque works?

Answer. No. It checks our reasoning about the proposed behaviour. We must later implement it, execute meaningful tests, and record evidence. Event-change and cancellation policy, for example, still needs review before that affected workflow is complete.

Key terms

Use Table 2.4 to check your vocabulary before Chapter 3. Each term was explained where it first appeared.

What we take into the next chapter

We have a working business brief and product requirements draft, a bounded first release, two connected journeys, examples of correct and refused actions, explicit rules, and a way to trace checks to needs. Proposed policies and remaining decisions are visible. The six planned sections of Chapter 2 are complete as a draft for review.

Readiness checkpoint: without looking back, explain the difference between a BRD and a PRD, write one Given/When/Then example for cancellation, state the capacity invariant, and name one decision that must be made before implementation.

Next: Chapter 3 explains how the web works. We will use these same journeys to understand what happens when a person opens an event page or submits a registration request.