Requirements
Functional requirements are the backbone input: everything downstream hangs off them. The generator maps each requirement onto the components that implement it, which is what powers the traceability you see later: "satisfies requirements" on component cards, the requirements-to-components traceability export, and acceptance criteria on delivery stories.
Work the List
On Design Inputs, the requirements editor manages the list directly: add a requirement, edit it in place, remove what no longer applies. Requirements imported from Jira arrive as drafts for your review before they count.
Write Them so the Machine Can Use Them
The generator reads requirements literally, so phrasing has leverage:
- One capability per requirement. "Patients pay outstanding balances by card" gives the generator something to place; "the system shall be modern and scalable" gives it nothing. Split compound statements.
- Name the actors and the data. "Staff issue refunds against a payment record" tells the design who touches what; both the actor and the data class flow into the model.
- State volumes when they matter. "Handles 50,000 payments a month" is a scale signal that shapes deployment and cost figures.
- Keep quality bars in the structured fields. Availability, recovery, and residency belong in input fields, where they act as constraints, not as prose the generator has to interpret.
The Requirement Is the Unit of Traceability
When an auditor asks "where is this requirement implemented?", the answer is generated from these exact statements. Writing them as short, testable sentences pays off every time that question is asked.
Where Requirements Resurface
| Surface | How They Appear |
|---|---|
| Component cards | "Satisfies requirements" listing on each implementing component |
| Traceability export | Requirement-to-component matrix as a document |
| Delivery stories | Build stories carry their component's requirements as acceptance criteria |
| Design review | Critics judge the design against the stated requirements |