Reference
Document typesCopy link
One page covering every artefact RCF defines. Purpose, ID scheme, and where each one sits. Look up what you need; the rest stays where it is.
RCF defines nine document types. They aren’t separate templates you pick from; they’re positions on a chain, each carrying a specific decision and a specific kind of reference. The chain reads top to bottom: PRD → Requirements → User Stories → Acceptance Criteria → Technical Architecture → Build Sequence → Functional Build Specification → Test Suite → Test Case.
Every artefact carries an opaque string ID. IDs never get renumbered and never get reused. They’re the keys traceability runs on; see the traceability page for why. The conventions below are recommended; the load-bearing rule is that whatever scheme you pick stays stable.
PRD: Product Requirements DocumentCopy link
Product Requirements Document PRD-NNN
The top of the chain. One per product. States what the product is, who it’s for, what it does, and (load-bearing) what it deliberately doesn’t do. Holds the requirements list as its main payload. Out-of-scope sections matter as much as in-scope. Lives as a single document; section headings handle internal structure.
References: none upward. Referenced by every Requirement.
REQ: RequirementCopy link
Requirement REQ-NNN
A short statement of something the product must do. Carries a category (functional, non-functional, regulatory), a priority (must, should, could), and a domain (auth, billing, search, whatever the product is made of). Requirements describe what, never how. Lives inside the PRD’s requirements list.
References: belongs to one PRD. Generates one or more User Stories.
US: User StoryCopy link
User Story US-NNN
The human shape of a requirement. The familiar “as a [role] I want [action] so that [outcome]” structure. Stories give a requirement a concrete actor and a stated outcome, which is what acceptance criteria can then test against. A requirement usually generates a small handful of stories, not dozens.
References: belongs to one Requirement. Carries one or more Acceptance Criteria. Belongs to one Functional Build Specification via its fbsId field, with the FBS’s storyScope as the canonical mapping.
AC: Acceptance CriterionCopy link
Acceptance Criterion AC-NNN-NN
The central primitive of the methodology. A Given/When/Then sentence that names a precondition, an event, and an observable expectation. ACs are scoped to the story they sit on; the second-segment number is the criterion’s position within that story. AC text must be testable as written. If it isn’t, it isn’t a real AC.
References: belongs to one User Story. Has exactly one Test Suite, one to one. See Acceptance criteria as the contract.
TAD: Technical Architecture DocumentCopy link
Technical Architecture Document TAD-NNN
One per product, sibling to the PRD rather than child to it. Describes the systems and components the product needs: services, data stores, external integrations, the cross-cutting decisions about how data flows and where state lives. Architectural decisions (ADRs in other vocabularies) live inline in the TAD’s decisions section, dated and signed. The TAD is a single logical artefact, but under the hood it bundles whatever it needs to land the architecture: written sections, diagrams, wireframes, schema definitions, decision records. Logical boundary, not file-based.
References: referenced by Functional Build Specifications via the buildContext.tadSections field.
BS: Build SequenceCopy link
Build Sequence BS-NNN
The plan for getting from nothing to shipped. A directed acyclic graph: each node is a Functional Build Specification, each edge is a dependency between them. One per product. The sequence decides what gets built when. Vertical-slice sequencing (ship working behaviour as early as possible) is the usual target; foundation-first sequencing (stand up shared infrastructure before slices) is the common alternative when there’s real shared work to do.
References: contains all the Functional Build Specifications for the product. Each FBS declares its dependencies on others.
FBS: Functional Build SpecificationCopy link
Functional Build Specification FBS-NNN
The unit of work. One slice of the product, sized so it can be built, tested, and shipped in one go. Carries the slice’s scope (which stories, which ACs), its dependencies (other FBSs that must finish first), its declared build context (PRD sections, TAD components, code modules, schemas, external docs the worker will need), its testable outcomes (the in-scope ACs restated), and its status. The FBS is also what the build cycle (Define → Build → Review → Test → Finalise) runs against.
References: belongs to one Build Sequence. Has zero or more dependency FBSs. Has a storyScope mapping it to specific user stories and ACs.
TS: Test SuiteCopy link
Test Suite TS-NNN-NN
The implementation of one acceptance criterion in test code. Each suite belongs to exactly one AC; each AC has exactly one suite. The suite ID mirrors the AC ID by convention (TS-088-02 implements AC-088-02), which makes it greppable. A suite is made up of Test Cases.
References: implements one Acceptance Criterion, one to one. Contains one or more Test Cases.
TC: Test CaseCopy link
Test Case TC-NNN-NN-NN
The individual scenario inside a suite. Happy path, named edge cases, failure modes. Each case is one assertion-bearing path through the behaviour the suite is testing. Cases are how you cover the AC’s intent thoroughly, not how you cover separate ACs.
References: belongs to one Test Suite.
ID scheme summaryCopy link
The full set of conventions, in one table.
- PRD-NNN. One per product. Usually three-digit, zero-padded.
- REQ-NNN. Sequential within a PRD. Width is fixed per project. Mix three- and four-digit at your peril.
- US-NNN. Sequential within a PRD. Stories are not scoped to requirements at the ID level; the relationship is by pointer (reqId), not by ID structure.
- AC-NNN-NN. Scoped to the story. The first segment is the story number, the second is the criterion’s position within that story. ACs are opaque strings; don’t rely on the numeric structure for sorting or queries beyond “is this AC on that story.”
- TAD-NNN. One per product. Usually paired with the PRD (PRD-001 and TAD-001).
- BS-NNN. One per product. Usually paired with the PRD.
- FBS-NNN. Sequential within a Build Sequence. Width is fixed per project.
- TS-NNN-NN. Mirrors the AC ID. TS-042-03 implements AC-042-03.
- TC-NNN-NN-NN. Mirrors the suite plus a case index. TC-042-03-01 is the first case of the suite that implements AC-042-03.
None of the numeric structure is queried directly. Pointer fields do the work. The mirror conventions (TS to AC, TC to TS) are for human readability and for grep, not for the data model.
What’s deliberately not hereCopy link
Some artefacts you might expect to see don’t appear because they don’t earn their keep at this level of the methodology. There’s no separate Architectural Decision Record (ADR) document; ADRs sit inline in the TAD as a decisions section. There’s no Bug document; bugs are work items in the project’s work tracker, and the fix is run through the normal build cycle against the AC the bug exposed. There’s no separate Release document; the build sequence and FBS statuses together describe what’s shippable, and the deployment record lives in whatever your release infrastructure already produces.
Keeping the document set small is deliberate. Every additional document type is another vocabulary the team has to maintain and another place where the chain can fall apart. The set above is the minimum needed to make the methodology hold together. Adding more is optional and usually a sign that something else is wrong upstream.