Federating a systems model

Decision records

Each record holds one decision the demo rests on: its context, the decision, the alternatives that lost, the consequences, the requirements it affects and its sources. The form is the one Michael Nygard proposed, with the alternatives, requirements and sources added. Five views and twenty-six decisions tells the story of the first twenty-six.

There are thirty-four, all accepted. Twenty-six were written in the design phase, before any code. AD-0027 and AD-0028 came during the build, and the second replaced the first. AD-0029 to AD-0034 came after the first release, with the demo’s own model, the check session, the language model experiment, the host configuration and the Gherkin scenarios.

When building the system changed what a record decides, the record kept its number and its first date and gained a dated amendment line at its head. The list below marks those records as amended. A decision that replaces another gets a number of its own, and no number is ever reused.

Inside the records, SR-nn is a system requirement and SC-nn a design constraint. From use cases to requirements describes the first forty-five requirements and the seven constraints. SR-46 to SR-48 came with the demo’s own model, and SR-49 with the host configuration. A name beginning PIPE- is a short name in the example model. C-nn is an entry on the design phase’s technical constraints card, which isn’t published, so those references show what a decision rested on and aren’t there to be looked up. The four gates are the design phase’s own, and How the design was run says what each produced.

The shape of the system

The analysis

The adapter

The apps

The repository