GlossaryCopy link

Acceptance Criterion AC

A Given/When/Then statement attached to a user story, naming a precondition, an event, and an observable expectation. The central primitive of the methodology. One AC maps to exactly one test suite. See Acceptance criteria as the contract.

Build Context

The set of references a Functional Build Specification declares so the worker executing the slice has the right inputs without grepping for them. PRD sections, TAD components, code modules, schemas, external docs. Lives on the FBS as a typed field.

Build Cycle

The five-stage cycle per Functional Build Specification: Define, Build, Review, Test, Finalise. Each stage commits. See The build cycle.

Build Sequence BS

The directed acyclic graph of Functional Build Specifications that gets the product from nothing to shipped. One per product. Each node is an FBS; each edge is a declared dependency.

Document Chain

The nine artefacts RCF defines and the references between them: PRD → Requirements → User Stories → Acceptance Criteria → Technical Architecture → Build Sequence → Functional Build Specification → Test Suite → Test Case. See The document chain.

Functional Build Specification FBS

One slice of the product that can be built, tested, and shipped in one go. Carries the slice’s story scope, dependencies, build context, testable outcomes, and status. The unit the build cycle runs against.

PRD Product Requirements Document

The top of the chain. One per product. States what the product is, who it’s for, what it does, and what it deliberately doesn’t do. Holds the requirements list as its main payload.

Requirement REQ

A short statement of what the product must do. Carries a category, priority, and domain. Lives inside the PRD. Each requirement breaks down into one or more user stories.

Requirements Confidence

The property RCF is named for. Confidence not in any single artefact but in the chain that connects business decisions to shipped behaviour. The chain answers is the requirement met, which tests prove it, and why does this code exist by mechanical query.

Story Scope

A Functional Build Specification field that names the user stories and acceptance criteria in scope for the slice. The canonical mapping from FBS to the ACs it satisfies.

Technical Architecture Document TAD

One per product. Describes the systems, components, data stores, and external integrations the product needs. Architectural decisions live inline in the TAD’s decisions section, dated and signed.

Test Case TC

The individual scenario inside a test suite. Happy path, named edge case, or failure mode. One assertion-bearing path through the behaviour the suite is testing.

Test Suite TS

The implementation of one acceptance criterion in test code. One suite per AC, one AC per suite. Made up of test cases.

Testable Outcomes

A Functional Build Specification field that restates the in-scope acceptance criteria in the worker’s terms. Used by the Define stage of the build cycle as the brief for what tests to write.

Traceability

The property of the document chain that lets you answer questions mechanically. Forward: given a requirement, what tests prove it? Backward: given a line of code, what business decision does it serve? See Traceability.

User Story US

The human shape of a requirement. “As a [role] I want [action] so that [outcome].” Carries one or more acceptance criteria. Belongs to one requirement and one Functional Build Specification.