Chapter 10: Turn Needs into Outcomes, Requirements, and Scope

The catalogue of two hundred and fourteen

The tranche two planning workshop is an hour old when Marcus Chen opens the catalogue on the screen and the room falls silent, because the number is larger than anyone expected. Two hundred and fourteen items. Marcus has grouped them by module, vendor configuration, and interface, and the slides are careful and orderly. Dana Okafor looks at the first row.

“‘A clinician can open a patient’s chart and see the medication list within three seconds,’” she reads. “Who wrote this?”

“A nurse from clinic five, at the elicitation day,” Marcus says. “The vendor says it is standard. It comes with the package.”

“Then it is not a requirement,” the vendor’s consultant says, “it is a configuration.”

Hana Lindqvist, the clinical director, disagrees in her quiet way. “Three seconds is the decision. In a consultation I have ten minutes. If the list takes three seconds or thirty, the difference decides whether my clinicians check it at all. That is not configuration. That is what we are buying.”

Priya Raman, the privacy officer, adds a line of her own. “And whatever the screen does, every access to a patient’s chart must leave an audit trail that records which clinician, when, and what they viewed. That is not configuration either. That is the certification.”

Sam Otieno, who leads clinical training, has been taking notes. “Whatever we decide, the training plan has to be written against it. If the screen changes in month 14, the training written in month 10 is wrong.”

Marcus is still looking at the number. “Two hundred and fourteen items, and I can trace maybe sixty of them to something we actually decided. The rest are asks. Good asks, but asks.”

That sentence is the chapter. “Install the patient-record platform” was authorized at the gate, and the word install hid the real work: deciding what the platform must do, how well it must do it, what the project must build around it, and how anyone will know when it is done. Requirements are the translation layer between what stakeholders need and what a team can build, and the craft is keeping the translation honest. The Alignment lens of the Mastery equation meets the Delivery lens here: Project Mastery = Judgment × Alignment × Delivery × Learning, and the catalogue is where shared intent becomes buildable work.

The ladder from need to benefit

The first discipline is vocabulary, because the word “requirement” is a crowd of different statements, and treating them as one thing produces the two-hundred-and-fourteen-item catalogue. The working vocabulary is a ladder, and every rung has a test.

A need is what a stakeholder actually requires to do a job, relieve a pain, or close a gap, before any solution is chosen. A patient’s condition needs safe prescribing; a nurse needs to know what the patient is taking before recommending anything. A need has no solution in it.

An outcome is the changed state or behavior the project exists to produce, with a measure and an owner. Chapter 2 introduced this discipline and chapter 8 made it a charter line: “access outcomes meet the grant threshold in six neighborhoods, owned by the clinic operations director, measured from the grant’s own reporting.” The outcome is the parent of everything below it on the ladder.

A capability is what the organization can do after delivery that it could not do before. Meridian could not record a prescription where the platform and the pharmacy can see it; after the project it can. Capabilities are the bridge between what the project produces and the outcomes that follow, and chapter 1 drew this chain as output to capability to outcome to benefit to strategic impact.

A feature is a visible element of the solution the project will produce: the chart screen, the audit log, the refill queue. Features are the vocabulary of the product, not of the needs.

A deliverable is an artifact produced by the project, and it is the only rung the project directly controls: a configured screen, a migrated record, a training program, a building.

A requirement is a verifiable statement about a feature or a deliverable: what it must do, and how well. The standard that organizes this territory is ISO/IEC/IEEE 29148:2018, the second edition of the international standard on requirements engineering; it defines a requirement as a statement that translates or expresses a need and its associated constraints and conditions. The two crucial words are “need” and “verifiable.” A statement with no need behind it is an ask; a statement that cannot be verified is prose.

The chain is the chapter’s primary picture, and it deserves a figure because traceability is a relationship, not a column.

Figure 10.1: The need-to-benefit traceability chain. Every requirement
sits on this chain with a parent (the outcome it serves) and children
(the acceptance evidence that proves it). A requirement with no parent
is an orphan; an outcome with no children is a wish.

  NEEDS ------> OUTCOMES ------> CAPABILITIES ------> FEATURES ------> REQUIREMENTS ------> ACCEPTANCE
  what a        changed state     what the org        visible          verifiable          evidence that
  stakeholder   + measure +       can now do after    elements of      statements of       each link is
  needs: the    owner             delivery            the solution     what each feature   true: observed
  job, the                                             the project      must do and how     by the right
  pain, the                                           will produce     well (how fast,     people, tested,
  gap                                                                  how private,         signed
                                                                       how reliable)

  forward trace (relevance):  does this requirement serve a feature that enables a
                              capability that produces an outcome a stakeholder values?
  backward trace (coverage):  is every outcome covered by requirements that carry
                              acceptance evidence?

The top layer of the chain deserves its own name, because it is the artifact the register is built against: the outcome map, the set of confirmed outcomes with their measures and owners, as good as the charter lines that produced it. When a new requirement arrives, the first question is which box on the outcome map it serves; when a box has no requirements beneath it, the project has an uncovered outcome, a wish dressed as a goal.

The discipline of the ladder is not building the whole chain for every item; it is knowing which rung a statement occupies before deciding what to do with it. A meeting that can say “that is a new need, not a configuration” is a meeting that knows what it is deciding.

The catalogue at Meridian failed the ladder test on day one. Of the two hundred and fourteen items, the sixty-one Marcus could trace were the ones that arrived with a parent: the workflow standard decided at the gate, the privacy certification, the grant’s access targets. The rest were asks floating without parents — not requirements yet, but requests for a decision.

What it does, and how well it does it

The second discipline splits every requirement into two kinds, and the split is where the cost lives.

A functional requirement states what the thing must do: the behavior, the service, the transformation. “A clinician can open a patient’s chart and see the current medication list.” That is functional.

A nonfunctional requirement states how well it must do it: the quality, the constraint, the obligation. “The medication list renders within three seconds of the chart opening.” “The chart screen meets the clinical usability criteria agreed with the nursing council.” “Every chart access leaves an audit trail recording clinician, time, and what was viewed.” “The platform can be operated on paper for a full clinic day if it is unreachable, with data entered within 24 hours of recovery.” Nonfunctional requirements travel under many names: performance, usability, reliability, security, privacy, accessibility, maintainability, supportability, continuity, and the regulatory obligations that sit on top of all of them.

The terms are standard vocabulary; ISO/IEC/IEEE 29148:2018 organizes requirements around precisely this distinction, and this book uses its categories loosely rather than as a taxonomy. What matters is not the label but the pattern: nonfunctional requirements are where projects fail, and the two-hundred-and-fourteen-item catalogue is blind there. The catalogue at Meridian was written almost entirely as behavior: what the screen does, what the queue does, what the report does. The three-second limit was one line among dozens. The audit trail was a sentence Priya added at the workshop. Nothing in the catalogue said what happens when the platform is down, or how a clinician with low vision reads the chart, or whether the pharmacy interface can survive a spike in refill requests at 8 a.m., or what the print queue does to the exam room workflow.

The field signal for this failure is the requirement that reads like a design decision. When someone writes “the system must show the medication list in a pop-up window when the nurse clicks the patient’s name,” they have not written a requirement; they have drawn a screen in words. The need beneath it is “the nurse can review medications without leaving the chart.” The first version smuggles a solution, commits the project to it, and hides the actual decisions: whether a pop-up is the right pattern, whether it works in the exam room, whether it is accessible. A catalogue full of design decisions is a catalogue that has skipped the analysis step and inherited someone’s first idea. The repair is to ask the question that separates the kinds: “What must be true?” gets a requirement; “How must it work?” gets a design, and the design belongs to the people who will build and test it, against requirements they can verify.

The hidden nonfunctional requirement deserves its own paragraph, because it is the most common surprise in acceptance. A feature is specified, built, and demonstrated, and then fails at the moment of use because nobody wrote the quality: the screen works but the clinician cannot read it at arm’s length, the queue works but the pharmacy receives refills in bursts that swamp its own system, the chart works but the audit trail does not capture what the regulator will ask for. The discovery questions are short and repetitive: how fast, how many, how often, how private, how secure, who else uses it, what if it fails, what if it is down for an hour, what if everyone uses it at once, who maintains it, who is trained on it, what must be proven to whom by when. Every one of those questions is a category of nonfunctional requirement, and the answers, written down and verifiable, are what make a feature acceptable rather than merely present.

Product scope and project scope

The third discipline is the boundary, and it runs between two scopes that are constantly conflated.

Product scope is what the solution is: the features, their qualities, the interfaces, the things the platform does. Project scope is the work the project does to create it: the configuration, the migration, the training, the testing, the certification, the building, the change management, the acceptance events. The confusion between the two produces two classic errors. Teams manage product scope as if it were a schedule item, so a change to what the screen does becomes a fight about dates instead of a decision about value. And teams manage project scope as if it were product, so the training plan is written against features instead of against the behaviors the clinicians must perform, which is how the platform ships with nobody able to use it.

The scope statement is the minimum viable tool that keeps the two scopes honest: one page, two lists. Product scope in: what the platform must do and how well. Product scope out: what it will not do, the patient-facing app, the claims integration, the analytics warehouse. Project scope in: the work that creates and accepts the platform, the migration, the training, the certification, the continuity procedures. Project scope out: the ongoing operation after handover, the marketing, the maintenance of the buildings. Chapter 8 established the exclusion list as the charter’s honesty; the scope statement is that honesty at the level of the catalogue, where every future request can be checked against a boundary the room agreed to when nobody was asking for anything.

At Meridian the statement separates what “install the platform” hides. The product scope is the platform’s behavior: the chart, the medications, the orders, the refills, the audit trail, the interfaces with the pharmacy and the laboratory. The project scope is everything around it: the clinical workflow standard Hana owns, the data migration from the paper records and the old system, the privacy certification Priya gates, the role-based training Sam builds and measures, the continuity procedures that keep a clinic running if the platform fails, the acceptance events where Nora’s operations staff and Hana’s clinicians witness the result. The same word, platform, appears in both lists, and that is the point. The project does not deliver a platform; it delivers a clinic that can safely use one, and the requirements catalogue must say so.

Interface ownership belongs in the scope statement too, because the interfaces are where scope disputes actually happen. The platform meets the pharmacy at an interface, and someone must own the specification of that boundary: what data crosses it, in what format, with what latency, under what failure behavior. If no one owns the interface, the platform team and the pharmacy team each assume the other defines it, and the boundary is discovered at integration time, which is the most expensive place to discover anything. The owner of an interface is not “everyone”; it is a named person with the authority to set the contract on one side and the obligation to keep the other side informed.

Where requirements come from

The fourth discipline is provenance, because a requirement is only as good as the need it translates, and needs do not arrive as prose. They arrive as complaints, workarounds, observed behavior, benchmark comparisons, and things people do by hand because the system will not do them.

Elicitation is the deliberate collection of needs, and the honest methods are the ones that do not ask people to write requirements, because most people cannot and should not. The clinician cannot write “the chart must render the medication list within three seconds”; the clinician can say “I check medications at the start of every consult, and in a busy morning I skip it if it takes too long.” That observation is the raw material. The reliable methods are the ones chapter 6 taught for discovery: observation in the actual setting, interviews at the point of work, journey mapping of the whole workflow, analysis of existing records and complaints, prototypes that let people react to something concrete, and reference visits to sites that already run the system. The requirements workshop, where clinicians and the vendor and the project sit together, is useful for resolving conflicts and testing drafts, but it is a poor place to discover needs, because the people with the needs are doing work elsewhere. Meridian’s elicitation day was the workshop, and it produced the two hundred and fourteen asks: valuable material, and not yet requirements.

Analysis is the translation of raw material into statements that pass the test. The working standard for a good requirement, distilled from the guidance in ISO/IEC/IEEE 29148:2018 and compressed into this book’s practice, is that a requirement must be necessary, verifiable, unambiguous, complete, consistent, feasible, and traceable. Necessary: someone can name the need it serves, and the project would be worse without it. Verifiable: there is a test, an observation, or an inspection that can prove it true or false. Unambiguous: two readers reach the same interpretation; the tests are the questions “what counts as done” and “who would disagree about whether this is true.” Complete: the requirement says what it needs to say for the team to build to it without inventing meaning. Consistent: it does not contradict another requirement, and the catalogue is checked as a whole, because requirements that look fine individually collide in pairs. Feasible: a team with the available capability can build it within the available constraints. Traceable: it names its parent one rung up the ladder. The three-second line fails most of these: nobody can define what “within three seconds” will be measured on, the clinician who wrote it meant “fast enough that I still check the list,” and the verifiable requirement beneath it is a workflow observation, not a stopwatch.

The translation step has its own failure pattern, and it is worth naming because it is always well intentioned. Requirements are usually written by someone between the stakeholders and the builders: an analyst, a product owner, a project lead, a consultant. The translator’s game is the slow corruption of meaning as the need travels: the clinician says “I need to know what the patient is taking,” the analyst writes “display medication list,” the developer reads “show all medications on the chart screen,” and the acceptance test checks that a screen shows a list, while the clinician’s actual need, “I need to know what the patient is taking before I prescribe anything, without breaking the flow of the consult,” has evaporated somewhere between the four sentences. The repair is validation: before the catalogue is baselined, the stakeholders who own the need read the requirements in their own words and confirm the translation. The confirmation is witnessed and recorded, because a requirement confirmed by the translator alone is confirmed by the person most invested in the translation being accepted.

Validation is the check that the requirement expresses the real need, and it must be distinguished from verification, the check that the built thing meets the requirement. The pair of questions is one of the oldest in the craft: are we building the right product, and are we building the product right? The framing is widely taught and often credited to Barry Boehm’s 1981 book Software Engineering Economics; ISO 9000:2015 formalizes it, defining verification as confirmation that specified requirements have been fulfilled and validation as confirmation that the requirements for a specific intended use are fulfilled. In practice: verification asks whether the platform does what the requirement says; validation asks whether the requirement says what the clinic needs. A project that verifies without validating builds the wrong thing correctly, and that is the expensive failure, because it is discovered only at acceptance, when the cost of change is highest. Robert Glass’s synthesis of the empirical software literature, Facts and Fallacies of Software Engineering (2003), reports that the most common errors in software projects are requirements errors, not coding errors. The finding transfers to project work generally: the defects that cost the most are written into the requirements before any code or construction existed.

Priorities with teeth

The fifth discipline is prioritization, because the catalogue always outruns the capacity, and the question is not which items are good but which items get built now, which later, and which never, with the decisions made deliberately instead of by accident.

The oldest prioritization vocabulary in the field is the MoSCoW scale, developed by Dai Clegg and Richard Barker at Oracle in the early 1990s and published in Case Method Fast-Track: A RAD Approach (1994): must have, should have, could have, and won’t have this time. The method’s contribution is not the four buckets; it is the fourth bucket. A prioritization that has no “won’t” category is a prioritization that has refused the decision it exists to make. The other classic lens is the Kano model from Noriaki Kano and colleagues (1984), which sorts features by their relationship to satisfaction: must-be features whose absence dissatisfies regardless of how well the rest works, one-dimensional features where more is better, and attractive features that delight when present but do not harm when absent. The two lenses answer different questions: MoSCoW says what the delivery can afford; Kano says what the stakeholders will punish you for omitting. A must-be requirement that nobody scored as valuable still has to be built, because its absence fails the project. A catalogue that scores only delight will build a wonderful platform that cannot pass certification.

The working method at Meridian is the value-per-hour sort, and it deserves a worked example because it shows both the power and the limit of arithmetic. The tranche holds about 500 hours of configuration and integration effort before the clinic one gate. The candidate set, scored by the clinicians for value on a 0 to 60 scale and by the team for effort in hours, looks like this.

Sort by value per hour, with ties broken by value: R1 (90 hours), R2 (60), R8 (50), R4 (90), R3 (60), R5 (40), R6 (30), R7 (80), for 500 hours exactly, and R9 is out. The arithmetic is clean, and the method has done its job: it made the trade-offs visible and dated. Now the judgment overlay, which is where the method’s limits appear. R7, the SMS booking confirmation, sits near the bottom of the ratio because the clinicians who scored the candidates did not carry the cost of no-shows; the grant pays on access outcomes, and no-shows are one of the largest leaks in access. R4 and R1 both trace to safe prescribing and certification, and R1 is regulatory, so it is must-have regardless of ratio, which the sort already honored. And the sort assumed the candidates were the catalogue, but the catalogue had no line for the workflow-standard configuration Hana’s team requires before any clinic opens: 120 hours, mandatory, not scored by anyone because it was assumed. The 500-hour budget does not hold. The team re-sorts: R7 comes into the tranche, something defers to tranche two, and the deferral is a decision with an owner and a date, not an accident.

The lesson is that prioritization arithmetic gives a starting allocation, never a verdict. Value is an opinion, and the opinion depends on who scored it; effort is an estimate, and the estimate carries uncertainty; dependencies, regulatory obligations, and the cost of delay reshape the ranking the moment it is built. The discipline is to do the arithmetic anyway, because it forces the opinions and estimates to be stated, compared, and dated, and then to let judgment, with the owners in the room, make the final allocation. The failure pattern is the all-must-have catalogue, where every stakeholder protects their own items into the must bucket and the MoSCoW scale collapses into a single column. The tell is a prioritization meeting where the “won’t” column is empty and nobody feels uncomfortable. A prioritization that produces no losers has produced no decisions.

What done means

The sixth discipline is the meaning of done, and it has two levels that are constantly confused.

At the level of a single requirement, acceptance criteria are the conditions that must be true for the requirement to be accepted, written so that someone can witness them. The three-second medication list, once analyzed, produces acceptance criteria that match the real need: a clinician opens the chart in a live consult with a patient record of at least 200 entries and can review the medication list without leaving the chart; the review does not delay the consult; the list is legible at arm’s length on the exam room screen. Each criterion names an observation that a clinician, not the vendor, performs. Acceptance criteria are the children of the requirement on the traceability chain: they are how the project will prove the requirement is true, and a requirement without acceptance criteria is a requirement that will be argued about at the worst possible time.

At the level of a release or an increment, the definition of done is the shared written statement of what must be true for the work to be considered complete and releasable, rather than merely built. The term comes from the Scrum Guide (2020 edition, by Ken Schwaber and Jeff Sutherland); this book uses it generically, as every delivery approach needs some version of it. The definition of done at Meridian is not a single sentence; it is the integrated readiness checklist that chapter 8 placed at the gate, and it spans the seams: the platform behavior passes the clinical workflow review, the audit trail passes the privacy certification checks, the migration reconciliation reports zero unexplained gaps, the clinicians scheduled for clinic one complete the competency check, and the continuity drill shows a clinic operating on paper and recovering within 24 hours. A feature can be built and delivered while the definition of done is unmet, and the discipline is that “done” means the checklist, not the handoff.

The precision trap deserves its own warning. Acceptance criteria can be precise and meaningless: “the medication list renders in under 100 milliseconds” is precise, untestable in the clinic, and probably beside the point, because the clinician’s need is about flow, not frame time. The criteria that matter are the ones a stakeholder can witness in the real setting. The person who writes them should be the person who will accept them: the clinician for clinical criteria, the privacy officer for audit criteria, the operations director for continuity criteria — not the builder who will be measured against them. A criterion written by the builder is a criterion designed to be passed.

The traceability discipline

The seventh discipline is traceability, and it is the practice that keeps the catalogue from drifting away from the needs it exists to serve. Requirements traceability has been studied as a problem since at least Orlena Gotel and Anthony Finkelstein’s 1994 analysis, which distinguished tracing requirements back to their origins in the stakeholder world, pre-requirements traceability, from tracing them forward into design and evidence, post-requirements traceability. Both directions matter, and both are about the two questions the ladder poses: does this requirement serve an outcome, and is every outcome covered.

The minimum viable traceability register is a table with five columns: the requirement, its parent outcome, its source, its acceptance evidence, and its owner. That is it. The register is created in the same session as the catalogue, one row per requirement, and it is maintained as the catalogue is maintained, because a register that lags the catalogue is a register nobody trusts. The forward question is asked of every new item: what outcome does this serve, and who confirmed it? The backward question is asked of every outcome: which requirements cover it, and what evidence will prove it? The register makes both questions cheap, and cheap questions are the ones that actually get asked.

The orphan census is the diagnostic that makes the register useful at Meridian. Of the two hundred and fourteen items, only sixty-one carried a parent outcome on the day the register was built. The census is not an argument that the other one hundred and fifty-three are worthless; it is an argument that they are undecided. Each orphan gets one of three dispositions: it is linked to an outcome and confirmed by the stakeholder who owns that outcome, which makes it a requirement; it is linked to an outcome the stakeholders decide not to pursue, which makes it an explicit exclusion, the “won’t” list, which is a decision and a protection; or it stays unlinked, which is a sentence no one should accept, because an unlinked item will either be built without justification or fight for a place at the worst moment. The census at Meridian sends forty items to the linkage table, ninety to the won’t list with reasons, and the rest to a review queue with an owner and a date.

Traceability theater is the failure pattern that gives the discipline its bad name: a matrix is maintained in obsessive detail, updated by someone whose job it is to update it, reviewed by no one, and consulted by no one. The tell is the matrix that lives in a file nobody opens, while decisions about scope and acceptance are made from the catalogue alone. The repair is to demand that the register be read at the moments it exists to inform: when a new item arrives, when an outcome changes, when an acceptance fails. A register that is not consulted at decision time is a cost, not a control. The tailoring rule is proportionality: the depth of the register follows the consequence of getting the link wrong. Regulatory, safety, and privacy requirements carry full traceability, because the certification examiner will ask for it. A nice-to-have display feature carries a lighter link, and the register says so. The project that traces everything at the same depth either drowns in the matrix or abandons it; the project that traces by consequence keeps the register alive.

The assistant that drafts the catalogue deserves the same honesty this book has applied to the charter and the stakeholder map. A machine can transcribe the workshop, cluster the asks into themes, and propose first-pass requirement statements and acceptance criteria; it can even flag orphans, because an item with no parent outcome is detectable in a table. What it cannot do is validate: it cannot sit with the nurse and confirm that the three-second line expresses the real need, and invented needs are indistinguishable from real ones in a well-written sentence. The boundary holds: patient data, staff records, and anything regulated or personal stay out of any tool the organization has not approved, and every requirement and parent link on the machine’s draft is confirmed by the stakeholder who owns the need before it earns a place in the register.

The boundaries that keep scope honest

The eighth discipline is the boundary itself, because the catalogue is where scope actually changes, one item at a time.

Scope boundaries, exclusions, and interface ownership were drawn in the scope statement, and the boundary discipline is what keeps them alive. The rule is simple to state and hard to practice: a new item inside the boundary is elaboration, and a new item outside it is a change, and a change is a decision with an owner, not an event that happens in a meeting. The two categories are not the same thing, and treating them alike is how projects drown in uncontrolled drift.

Progressive elaboration is the legitimate growth of detail as understanding improves, and it is a feature of every serious project, not a sign of failure. At Meridian, the workflow standard was decided at the gate in terms of principles, how a clinic schedules, books, checks in, escalates, and documents; the requirements that elaborate it, the three-second list, the audit trail, the continuity procedure, are written in tranche two as the clinic one go-live gets close enough to specify. That is elaboration: the far term is kept at outcome level, the near term is detailed to the point of buildable, verifiable requirements, and the detail is written when the information to write it honestly exists. The practice has a name in predictive delivery: rolling-wave planning. The same idea appears in adaptive delivery as the constantly re-prioritized backlog. In both, the principle is the same: do not detail what you cannot yet know, and do not treat the detail you do write as final.

The boundary between elaboration and change is the discipline’s entire content. Elaboration answers questions the requirement already asked: what does “within three seconds” mean in a live consult, what does “audit trail” record, what does “continuity” require when the platform is down. Change asks a new question: the patient-facing app, the claims integration, the analytics warehouse. The test is the parent link. If the new item links to an outcome already in the register, it is elaboration and it flows through the catalogue. If it links to an outcome not in the register, it is a change, and it flows through the change decision, with a cost, a priority, and a sign-off, because chapter 8’s tolerance rules govern scope as much as they govern money. The failure pattern is the yellow-sticker project: scope grows one small request at a time, each one reasonable in isolation, each one agreed to in a meeting by someone who can say yes, and none of them individually crossing the threshold that would trigger a decision, until the sum of the stickers is a different project. The tell is the request that is small, reasonable, and about the solution rather than the need: the pop-up window, the extra report, the “quick” configuration. The discipline is that every sticker is checked against the parent link before it is accepted.

One discipline, three cadences

The discipline does not change with the delivery approach; the cadence does.

In predictive delivery, requirements are baselined early, traceability is formal, and the gates review the catalogue as a controlled artifact: what changed since the gate, what was verified, what is ready to be accepted. The cost of change is high, so elicitation is front-loaded and acceptance criteria are written before the work, as part of the contract with the builders. This is the shape of Meridian’s regulatory and continuity requirements: baselined, traced, witnessed at the certification gate, and any change to them is a formal change with an owner.

In adaptive delivery, requirements are a backlog of small items, elaborated continuously, reprioritized every iteration, and accepted against criteria written and agreed per item. The backlog is often organized as a story map, the user journey walked left to right with capability slices arranged by priority, a practice taught in Jeff Patton’s User Story Mapping (2014) and used here as a working tool rather than a prescribed format. The definition of done is the increment-level commitment, reviewed empirically at each iteration’s review event, and the traceability is deliberately light, because the value of the work is its responsiveness, and heavy tracing would defeat it. The discipline is not absent; it is continuous, and the parent link is maintained per item even when the matrix is not.

In hybrid delivery, which is Meridian’s shape, the two cadences run side by side and the seams are explicit. The regulatory and privacy requirements run on the formal cadence, baselined and traced, because certification demands it. The clinical workflow requirements run on the adaptive cadence, written as the workflows are designed, reviewed with the clinicians, reprioritized as the go-live approaches. The seam discipline is ownership: any requirement that crosses the seam, the continuity procedure that involves both the platform’s behavior and the clinic’s paper fallback, has one owner for its acceptance and one place in the register, so that the same requirement is not governed twice at different speeds. The hybrid fails when the seams are invisible: a requirement governed formally is reprioritized adaptively, or one governed adaptively is frozen into a baseline it was never meant for, and the catalogue is pulled in two directions until someone stops trusting it.

How the catalogue dies

The failure patterns deserve to be named together, because competent people produce every one of them in good faith, and each one kills the catalogue in a different way.

The wishlist: asks with no parents, no owners, and no criteria, treated as authoritative because it is comprehensive, its count growing every month while progress is measured by how many items are “in progress.” A wishlist does not die; it metastasizes.

The frozen dictionary: baselined once, early, and treated as sacred, so the three-second decision made in month 10 is locked while the clinic’s workflow evolves, the pharmacy changes its interface, and the regulator updates its guidance; the date on the catalogue is older than the last two changes to the work, and every argument is won by whoever can quote the older document. A frozen catalogue does not keep the scope stable; it keeps the scope wrong.

The translator’s game: needs rewritten by intermediaries until the meaning is smooth and the substance is gone, discovered at acceptance, “that is not what I asked for” against “that is what you approved.”

The all-must-have: no losers, an empty won’t column, a tranche that is a fantasy; the value-per-hour table exists and nobody will admit that R9 is out.

The precision trap: rigor as decoration, the 100-millisecond render nobody will measure, the “100 percent uptime” no continuity plan can deliver, an acceptance pack so thick that the go-live rehearsal still fails on the first real workflow.

Traceability theater: a perfect matrix nobody opens, while the last three scope decisions were made without it.

The repairs are the disciplines the failures invert: the ladder test and the orphan census, the deliberate re-baseline, validation with witnesses, the dated decision with an owner, criteria the acceptors can witness, and the register read at decision time.

Practice

One. A quick classification. Each statement below is one rung of the ladder. Name the rung, and for the requirements, say whether functional or nonfunctional. (a) “Meridian must record a prescription that the pharmacy can see.” (b) “The platform handles 200 concurrent chart opens without slowing.” (c) “A clinician can open the chart and see the current medication list.” (d) “The audit trail records clinician, time, and what was viewed on every chart access.” (e) “The grant’s access outcomes are met in six neighborhoods, owned by the clinic operations director.” (f) “Every chart access leaves an audit trail.” (g) “If the platform is unreachable for more than 15 minutes, the clinic operates on paper and enters data within 24 hours.”

(a) is a capability: what the network can do after delivery. (b) is a nonfunctional requirement: a performance constraint on the platform. (c) is a functional requirement: a behavior. (d) and (f) are both nonfunctional requirements, privacy and audit obligations; (d) is more complete because it names what the trail records. (e) is an outcome: a changed state with a measure and an owner. (g) is a nonfunctional requirement, a continuity constraint, and notice it is also a small system of its own: it implies paper procedures, a data-entry process, and a recovery procedure, which is why continuity requirements need their own acceptance criteria rather than a single sentence. The drill’s lesson: the same sentence can change rungs with one word, and a catalogue that cannot classify its items cannot prioritize them.

Two. A field drill: decompose an install. Take something your organization recently “installed”: a system, a machine, a facility, a policy. Produce a one-page scope statement with four lists: product scope in, product scope out, project scope in, project scope out. Then take the single most consequential capability and write its outcome, its parent outcome statement with a measure and an owner, and three acceptance criteria a stakeholder could actually witness. Finally, run the ladder test on your own catalogue: how many items can name their parent outcome, and what do the orphans say about the project?

The drill succeeds when the scope statement surprises you, when at least one item lands in “out” that someone on the project secretly expects to be built, and when the acceptance criteria are witnessable rather than measured-and-meaningless. The orphans are the diagnostic: a project whose catalogue has no orphans has not done the elicitation, and a project whose orphans outnumber the traced items has not done the analysis. The most valuable output is the “out” list, because it is the boundary the project will defend.

Three. A decision room: the 500-hour tranche. The table above is the Meridian tranche two candidate set, scored by the clinicians and estimated by the team, with a 500-hour budget and a clinic one gate. Choose the tranche. Defend your allocation in terms of value, obligation, and dependency, and name the judgment overlay: who scored the value, what cost did they not carry, and what is missing from the candidate set that the project cannot go-live without?

The defensible answer starts from the value-per-hour sort: R1, R2, R8, R4, R3, R5, R6, R7 fill the budget exactly and R9 defers, with R1’s regulatory status honored at the top. The judgment overlay is where defensible answers diverge, and that is the point of the drill. R7 sits second from the bottom because the clinicians who scored value do not carry the no-show cost, and the grant pays on access outcomes, so a project that follows the arithmetic blindly underfunds its own success metric. And the candidate set is incomplete: the workflow-standard configuration, 120 hours and mandatory, is absent, so no allocation that stops at the table is honest. The strongest answers re-open the budget: defer one of the 0.50-ratio items, bring R7 in, and add the workflow configuration with a named owner and a return date for what defers. Unsafe choices: dropping R1 because its ratio ties R2, since R1 is regulatory and its absence fails certification, and pretending the budget is fixed while the mandatory work is not in it. Reasonable but risky: accepting the table as-is with the workflow configuration treated as a separate workstream, defensible only if that workstream has a real owner, a real date, and a real budget, not a hope.

Four. The mastery drill: the label printer. The clinicians’ representative asks for “a medication label printer in every exam room, so we can print the label when we hand the patient the prescription.” It sounds simple. Find the hidden nonfunctional requirements, and write the five acceptance criteria you would insist on before this request earns a place in the register.

The hidden nonfunctional requirements are the ones the request does not say. Performance: the label must print in time to stay inside the consult, and the print queue must not block the chart screen while it prints. Reliability: the printer must not be the reason a prescription is delayed, and a failed print must not produce a half label. Privacy and security: the label carries patient identity and medication, so the print must happen only when a clinician is signed in, the label must not sit in a shared tray, and the workflow must not print in the corridor. Legibility and accessibility: the label must be readable at arm’s length, in the clinic’s lighting, by a patient with low vision, and in the languages the visit summary uses. Usability: the print must happen from the same screen as the prescription, with no navigation, because any navigation is a step clinicians will skip. Continuity: when the printer fails, the clinician must be able to proceed without it, and the fallback must be defined before the failure, not during it. Maintainability and environment: consumables, cleaning, power, and the printer’s place in the room all belong somewhere, and “somewhere” is a requirement. The five acceptance criteria to insist on: (1) a clinician signs in, prescribes, and prints a label within the consult, witnessed live; (2) a failed print produces no unreadable label and no patient data left exposed, verified by a test that simulates the failure; (3) the label is legible at arm’s length in the exam room’s lighting by a reviewer with low vision, using the largest type size the label permits; (4) the bilingual and dosage fields print correctly for a sample of real prescriptions, checked by the clinicians who will accept them; and (5) a paper fallback lets the clinician complete the prescription when the printer is down, demonstrated in the continuity drill. The drill’s lesson: a request that names only the feature is a request that has hidden the entire project inside itself.

Five. The transfer question. In the last project you were part of, which requirement was precise and meaningless, which stakeholder’s need got lost in translation, and where was the boundary between the product and the project drawn, or not drawn? Who owned the interfaces, and what happened at the interface nobody owned?

The durable principle: requirements are the translation layer between stakeholder needs and accepted solutions, and mastery is keeping the translation honest, traceable to an outcome, verifiable by a witness, bounded by an explicit scope, and elaborated only as understanding genuinely improves. The most common next failure is the one the catalogue cannot see coming: the team builds exactly what the requirements say, the acceptance evidence is signed, and the clinicians still work around the platform, because requirements describe what the solution does and adoption is a change in what people do. The traceability chain ends at acceptance, and the next chain begins with the behavior: designing for adoption and organizational change, which is the next chapter, “Design for Adoption and Organizational Change.”

Notes

• Meridian Community Health Network is a composite case created for this book; no real network, vendor, system, or people are depicted. The 214-item catalogue, the 61 traced items, the tranche budget of 500 hours, the candidate table, the 200-entry chart, the 15-minute and 24-hour continuity figures, the three-second target, and the 40/90/rest disposition of the orphan census are author-created illustrative figures consistent with the earlier Meridian chapters. All named characters are composite.
• The definition of a requirement as a statement that expresses a need and its associated constraints and conditions, and the working characteristics of a good requirement (necessary, verifiable, unambiguous, complete, consistent, feasible, traceable), follow the guidance in ISO/IEC/IEEE 29148:2018, “Systems and software engineering: Life cycle processes: Requirements engineering,” second edition (Geneva: ISO; New York: IEEE; 2018). The characteristics are presented here as this book’s working set, not as a quotation from the standard. Readers should consult the official standard for the current text.
• The functional and nonfunctional distinction follows the same standard’s organization of requirements; the categories used in this chapter (performance, usability, reliability, security, privacy, accessibility, maintainability, supportability, continuity, regulatory) are the author’s practical list, not the standard’s taxonomy.
• The verification and validation definitions are paraphrased from ISO 9000:2015, “Quality management systems: Fundamentals and vocabulary” (Geneva: ISO, 2015), clauses 3.8.12 and 3.8.13. The questions “are we building the right product” and “are we building the product right” are widely taught in software and systems engineering and are commonly attributed to Barry W. Boehm, Software Engineering Economics (Englewood Cliffs: Prentice-Hall, 1981); the framing is used here as a teaching aid in the author’s own words.
• The finding that requirements errors, rather than coding errors, are the most common errors in software projects is from Robert L. Glass, Facts and Fallacies of Software Engineering (Boston: Addison-Wesley, 2003), which synthesizes earlier empirical studies; the claim is a synthesis, not a single experiment, and its relevance here is the general lesson that specification defects outlast construction defects.
• The MoSCoW prioritization scale was developed at Oracle in the early 1990s and is published in Dai Clegg and Richard Barker, Case Method Fast-Track: A RAD Approach (Wokingham: Addison-Wesley, 1994); the scale is described here in this book’s own words.
• The Kano model of must-be, one-dimensional, and attractive quality is from Noriaki Kano, Nobuhiko Seraku, Fumio Takahashi, and Shinichi Tsuji, “Attractive Quality and Must-Be Quality,” Journal of the Japanese Society for Quality Control 14, no. 2 (1984): 39-48.
• The distinction between pre-requirements and post-requirements traceability is from Orlena C. Z. Gotel and Anthony C. W. Finkelstein, “An Analysis of the Requirements Traceability Problem,” Proceedings of the First International Conference on Requirements Engineering (Colorado Springs: IEEE, 1994): 94-101. The five-column minimum register and the orphan census are this book’s working instruments, not the paper’s vocabulary.
• The term “definition of done” as a team-owned commitment for completed work comes from the Scrum Guide (2020 edition, by Ken Schwaber and Jeff Sutherland); this book uses the idea generically, in its own words, and does not reproduce the guide’s text. The integrated readiness checklist at Meridian is the author’s adaptation for hybrid delivery.
• The user-story and story-mapping traditions, which this chapter deliberately touches lightly because chapter 14 treats decomposition and chapter 32 treats adaptive delivery, are taught in Jeff Patton, User Story Mapping (Sebastopol: O’Reilly, 2014). The working practice of a “definition of ready” for backlog items is an industry adaptation, not a formal standard, and is treated as such here.
• ISO 21502:2020, “Project management: Guidance on project management,” speaks of interested parties where this book says stakeholders, and the current PMBOK Guide (Eighth Edition, Project Management Institute, 2025) covers requirements management and scope management in detail; readers should consult the official publishers for current editions. This book is independent of ISO, PMI, and all named framework owners.