Requirements, architecture and allocation across subsystems

Connect requirements to an agreed need

A requirement states an obligation that can be evaluated. Retain its identifier, source, rationale, conditions and planned evidence. In our constructed station case, R1 requires a result to become visible within 200 ms of a valid test card reaching the specified readable position, under a specifically defined connected test condition. This is narrower than a promise about a visitor’s entire task.

Check whether that narrower condition actually supports the intended service. If finding the card’s readable position takes several seconds, passing R1 may leave the original concern unresolved. Requirements development therefore involves iteration with stakeholders, including examination of assumptions and missing outcomes rather than merely replacing adjectives with numbers.

Separate what must happen from its implementation

A functional view identifies reading, obtaining a record, deciding a result and presenting it. A physical or implementation view assigns functions to reader hardware, software, communications and display. These views are related without being identical: one processor may implement several functions, and one function may depend on several elements.

The figure supplies a sequential time model with allocations 40, 30, 50 and 20 ms. Their sum is 140 ms, leaving 60 ms against the 200 ms requirement. This is a transparent budget, not a measured guarantee. Define what each interval includes and whether queues, scheduling, retries or overlaps exist. An unexplained gap can hide work rather than provide usable margin.

Give each allocated interval a subject and a reason

Make the existing R1 account explicit. Let event e0 be the valid card reaching its defined readable position, e1 the reader completing a valid ID, e2 that ID frame arriving at the station controller, e3 the result decision becoming ready, and e4 that result becoming visible. The four intervals join without gaps. The decision interval includes obtaining the catalogue record and any controller waiting, not merely the arithmetic performed after a record arrives. The table maps functions to responsible elements and to a proposed evidence path.

For a separate early design estimate under R1’s controlled connected condition, supply predicted interval times 32, 24, 42 and 16 ms. They total 114 ms. The proposed child limits 40, 30, 50 and 20 provide respective headroom 8, 6, 8 and 4 ms, with another 60 ms unallocated at parent level. This is the rationale for one candidate budget: each limit exceeds its corresponding estimate while their 140 ms total remains below 200. Headroom is a declared allocation choice, not a quantified probability or evidence that the estimates bound an implementation.

Once accepted within this teaching design, a child limit is an obligation. A predicted 42 ms is an assumption awaiting suitable evidence; the two entries must not be labelled interchangeably. The station and catalogue owners must agree on the record-response conditions underlying that prediction. The station team cannot allocate an external owner’s performance into existence. Test timestamps must resolve the same events, and any waiting discovered between e2 and e3 belongs in that interval rather than disappearing between teams.

Allocation creates relationships to check

An allocated requirement should retain a path to its parent and relevant interfaces. Changing display software can alter response time, power demand or the meanings of status messages. A subsystem’s local improvement can also worsen another function, so architecture review asks about the combined behaviour and constrained resources.

Avoid treating a decomposition as proof of completeness. Check every operational step, interaction and exceptional state against the proposed functions. A requirement with no implementation or evidence path needs attention; a feature with no justified need also needs explanation. Keep the distinction between a requirement, an assumed design parameter and a prediction visible in the records.

A faster path can create another function

An alternative keeps a local record mirror and predicts 18 ms for the decision interval instead of 42, reducing the predicted complete path to 32+24+18+16=90 ms. This changes the data dependency, not just a number. The mirror must determine whether its information remains usable, expire an old indication and respond when a refresh fails. The 18 ms prediction must include those checks if they are required. “Store records locally” alone does not specify them.

Trace the interruption scenario to proposed derived obligation D-expiry: a result whose agreed usable interval has ended must leave READY and show EXPIRED. Allocate interval tracking and state selection to station software, and duration/identity semantics to a shared catalogue contract. Evidence is a controlled-clock delayed/duplicate-message case, developed in the next lesson. A separate proposed D-reconcile concerns retaining whether a collection was merely indicated or actually confirmed after interruption; its journal, catalogue acknowledgement and staff responsibility need stakeholder agreement. A READY display is not itself a collection-confirmation record. These derived obligations arise from the selected architecture and service states; they are not new facts about an actual library.

This trace distinguishes a missing function from a slow component. A faster local lookup does not compensate for omitting expiry or reconciliation. Conversely, a proposed function with no parent service rationale should be questioned. Compare complete paths, associated state obligations and the evidence each architecture needs before selecting the apparently faster prediction.

Check a revised timing account

Assume a design revision increases the transfer allocation from 30 to 90 ms, while the other three supplied allocations remain 40, 50 and 20 ms. The revised total is 200 ms, exactly the stated limit in the sequential model. The model has consumed the previous 60 ms unallocated time.

That equality does not establish robust compliance. First verify consistent event boundaries and whether an omitted queue or measurement uncertainty matters to the decision. If the required condition changes to include disconnected operation, the connected-path sum may not describe the relevant behaviour at all. Review the requirement, architecture and evidence plan together.

Try the reasoning

1. Does the 140 ms allocation sum prove a real station responds within 200 ms?

   Show the answer and reasoning

   No. It is a model using supplied allocations. Completeness of the timing account and suitable implementation evidence remain necessary.

2. Can one component satisfy several functional allocations?

   Show the answer and reasoning

   Yes. Functional decomposition and implementation structure need a defined mapping, not necessarily one box per function.

3. Why retain the rationale for R1?

   Show the answer and reasoning

   It explains the underlying need and helps assess whether a proposed change still supports it.

4. Suppose the parent connected timing limit becomes 150 ms and a previously omitted 18 ms queue is found inside e2→e3. Using the supplied estimates, propose a consistent revised allocation and identify the evidence that must change.

   Show the answer and reasoning

   The decision estimate becomes 42+18=60 ms; the original 50 ms child limit is no longer supported by that estimate. One candidate is read 36, transfer 28, decision 65 and display 18 ms: total 147 leaves 3 ms parent margin and exceeds the corresponding estimates 32, 24, 60, 16. The queue is included inside the decision interval, not added again outside it. These proposed limits require review and evidence under the relevant queue/load conditions, with matching event boundaries and end-to-end timing; arithmetic is not compliance proof.

5. A mirror-based design returns records in 18 ms but has no rule for a delayed refresh or a station restart. Which architectural work is missing, and why does the fast result not settle it?

   Show the answer and reasoning

   It lacks defined freshness/expiry and recovery-state functions with owners, interface meaning and evidence. The design must say when READY ceases, what information survives or is invalidated at restart, and how indicated versus confirmed collections are reconciled. Trace those obligations to the intended service and obtain agreement. An 18 ms lookup prediction addresses one interval and cannot establish correct states or the whole service.

What to carry forward

Trace requirements to the service, allocate them through an explicit architecture and test the assumptions behind every resource budget.