Phase Two: Writing Material Requirement Cards (part two of two)

This is Unit Five of The M-CaReM-AI Method, part two, on drafting and checking Material Requirement Cards. Part one built the card: its required sections, its sizing rules, and a first set for an Eligibility Determination. This part puts cards to work: drafting them with AI, checking them, reusing patterns, and writing the library's own. Carry one question through this lecture: when a requirement hides a decision nobody has made, how does writing it as cards bring that decision into the open? The answer arrives with the library's muddy renewal requirement. By the end you will be able to draft a card with AI and review it into your own. To judge a card with the six checks. To use the Toolbox's card patterns. And to write a full card and split a muddy requirement.

Two entries on drafting cards with AI, and on the six checks that say whether a card is reliable enough to use.

Drafting a card with AI.

MCM 119 Drafting a Card With AI

The method drafts cards with AI only after the scaffolding is ready, and treats the result as a first draft; Generative AI at Work covers the prompt skeleton. First, prepare a short definition of the thing, the fields you know, the relevant policy text and the card template. Second, ask the tool for one named card, naming the thing and change, listing fields as required or optional, and including only the rules the policy states. Third, forbid invented fields, and have it list anything missing as a question. Fourth, review the draft: delete invented fields, add missing ones such as the policy version, and use your own terms. The review is what makes the card yours; a card nobody reviewed is the tool's guess in your template.

Six checks of a good card.

MCM 120 Six Checks of a Good Card

The book gives six checks for whether a card is reliable enough to use. Thing clarity: can you name its thing in one word? Change clarity: could you explain it to a developer in one sentence? Property realism: do the fields match real forms, policies and data? Rule testability: could a tester write cases straight from the rules? Stakeholder recognition: does someone who does the work say that is how it works, or point out what is missing? And atomicity: is it one behavior? Either answer to the stakeholder check is valuable, because a correction found now is cheap.

Two entries on the Toolbox's card patterns for situations that recur in every domain.

Create and transition.

MCM 121 Card Patterns: Create and Transition

Two Toolbox patterns are especially common. Create and validate: when a story tangles creation with validation, write one card to create the thing, listing required and optional fields, field and cross-field validation, and timing and permissions; one such card often supports web, mobile and batch entry. State transition: when status changes carry complex permissions, write one card per cluster of transitions, covering allowed from-and-to states, preconditions, who may change them, and the logging required. The transition card is where rules scattered across diagrams and old emails usually come together for the first time.

Generate, sync and schedule.

MCM 122 Card Patterns: Generate, Sync, Schedule

Three more Toolbox patterns. Generate a document: name the fields that feed it, what triggers it, when it must not be generated, and what is logged. Cross-thing consistency: when updating one thing must change another, write one card naming both, saying which is the source of record, whether the update is immediate or batched, and what happens on failure. Scheduled process: for a nightly or monthly job, name the things it touches, how it selects records, what it changes, and how it logs failures. Scheduled jobs are the behaviors teams most often forget, because no screen shows them.

Three constructed examples that write the library's cards. The opening question is answered here.

The library's first full card.

MCM 123 The Library's Create Loan Card

A worked example, constructed for this course, writes the library's Create Loan card. Its business statement says staff and kiosks must lend items so the library knows who has each one, when it is due, and which rules applied. Its focus is the Loan, with the Member, Item, Branch and Loan Policy Version as related things. Its properties are grouped into parties, timing, place and rules, with the due date calculated from the policy version in force, and that version recorded on the Loan itself. Its constraints cover an active card, an available item, a loan limit, and laptops for adults only. Recording the policy version came straight from the audit thing found in unit four: a finding in one phase became a field in the next.

A muddy requirement, split.

MCM 124 One Muddy Requirement, Two Cards

A second constructed example rewrites an old library requirement: the system shall manage renewals and notify members. It names no single thing and covers two behaviors at different times, so it becomes two cards. Renew Loan updates the Loan: no more renewals than the policy version allows, none if another member holds the item, and a new due date from the policy in force on the day of renewal, a rule argued over for ten minutes and written down for the first time. Generate Renewal Confirmation is a generate card, not sent when the member is at the desk. The split also exposes an unasked question about holds. That answers this lecture's question: a card must name its thing, change and rules, so the contested rule had to be decided and the hidden question had to be asked.

A card checked six ways.

MCM 125 A Card Checked Six Ways

A third constructed example runs the Renew Loan card through the six checks beside an AI draft of the same card. Both name the Loan and say update. But the tool's draft invents a renewal reason field, omits the policy version, writes an untestable limit, and bundles the confirmation into the same card. Showing the team's version to desk staff adds the phone channel. The analyst corrects the tool's draft and keeps it as a reference. The draft failed exactly as the book predicts, with an invented field and a missing audit field, and the six checks turned a vague sense that it looked fine into specific, fixable faults.

Look at what you can now do. You can draft a card with AI, with the scaffolding ready first, and review it until it is yours. You can judge any card with the six checks, and value the stakeholder check most. You can reach for the Toolbox patterns: create and validate, state transition, generate, consistency and scheduled jobs. And you can write a full card and split a muddy requirement, bringing hidden decisions into the open. Unit Six gathers cards into Object Packs.