The pieces

What each thing in a workspace holds, and the rules it follows. The figure on the first page shows how they connect. Status explains the statuses.

Requirement lists

A list is a named set of requirements, such as everything about the hardware. It has:

Code

A short id, such as HW, that starts every requirement's cite in the list. See Ids and names for the rules.

Title

A display name, such as Hardware.

Description

Optional. What the list covers and what it leaves out. On the list's page it shows on one line under the header; hover over it to read the rest. It can be formatted, except that cites in it stay as text.

• Lists appear in the sidebar in the order you put them in. Drag one to move it. A new list goes at the bottom.
• The title and description are changed in List settings, the gear in the list's header. The list is deleted there too.
• Deleting a list deletes every requirement in it and closes their mappings.

Requirements

A requirement belongs to one list and stays in it. It has:

Cite

The list's code and a number: HW-18. Numbers count up from 1 in the order requirements are created. They say nothing about where a requirement sits in the tree: HW-40 can sit above HW-5.

Title

A short label, such as 3V3 rail tolerance, for where there is room for only a few words. Required.

Statement

The requirement itself: The 3V3 rail shall stay within 3% of nominal from 0 to 2 A. It may be empty, which suits a requirement whose children carry the detail.

Body

Optional. The detail the statement depends on: a table of limits, a register layout, sub-clauses. The body is part of the requirement and binds as the statement does: a pass covers both. Up to 16 KiB.

A requirement has one status however much its body holds. When the rows of a table are checked by different tests, or some pass and some fail, give each its own child requirement, so the tree shows which.

Each saved change to the title, statement or body is kept, however small, and can be read under History in the requirement pane, along with the runs that recorded a result against each version. Moving a requirement in the tree is not a change to it.

The tree

The requirements in a list form a tree. Any requirement can have children that break it down; there is no separate heading type.

• A child's status counts towards its parent's: HW-1 fails above because HW-4 does (see a requirement's status).
• A requirement can be moved anywhere in its own list, under another parent or to the top level, but not to another list. Moving requirements says how.
• A requirement that has children cannot be deleted; move or delete the children first. Deleting a requirement closes its mappings.

Verifications

A verification is a procedure that checks requirements: a bench test, an analysis, an inspection. BreezeBlock does not record which kind. It has:

Short id

An id you choose, such as VERIF-PWR. VERIF- is only a convention, and VERIF-HW is not tied to the list HW in any way.

Name

A display name, such as Power rail test. Changing it does not make a new version.

Description

The procedure: what to set up, what to measure, what counts as a pass. It is kept in versions.

Verifications appear in the sidebar below the lists, in their own order, which you set by dragging.

Versions

A verification's description is never edited in place. Each change is committed as a new version, numbered 1, 2, 3 and so on, and each run records the version it used.

1. Version 1

   Committed. RUN-1 to RUN-4 used it, and RUN-4 still sets the statuses.

2. →

3. Version 2

   Committed, the latest. Not yet run; the next run will use it.

4. →

5. Draft

   Saved but not committed. No run can use it.

• Committed versions never change. The verification's page shows the latest; each run's page shows the version that run used.
• Committing a version changes no status. Statuses come from the last completed run, on whatever version it used, until a run of the new version completes. Until then the page says Version 2 has not been run., and which run the statuses still come from (example).

Mappings

A mapping says that a verification covers a requirement. A requirement can be mapped to any number of verifications, and a verification to any number of requirements, in any lists.

• Add one from either end: Map a verification in the requirement's pane, or Map a requirement on the verification's page, under Requirements it checks.
• A mapping can have notes saying how the verification covers this requirement: Measured at TP4 under the 2 A load step.
• Close mapping ends it. It stops counting towards any status, and runs that already included it keep it. Mapping the same pair again makes a new mapping, which is untested until a run includes it.
• Adding or closing mappings does not make a new version of the verification.

Runs

A run is one occasion on which a verification was carried out, cited as VERIF-PWR:RUN-3, or RUN-3 on the verification's own page. Runs are numbered in each verification.

1. In progress

   RUN-3

   Set each row, edit the details. Red as soon as a row fails.

2. →

3. Completed

   RUN-3

   Frozen except for run notes. Its rows now count towards statuses.

4. →

5. Replaced

   RUN-3

   A later run completed. Kept, faded, and no longer counted.

Opening a run

The button on a verification's page that starts one is named for the run it makes, such as Start RUN-4. It needs a committed version and at least one mapping, and only one run per verification can be in progress.

The run takes the latest committed version and one row for each requirement mapped at that moment. That is fixed for the life of the run: later mappings, closed mappings and new versions do not change it. A requirement deleted during the run keeps its row, marked deleted, and still counts towards the result.

Recording results

Each row starts unset. While the run is in progress, choose one of three; the choice is saved at once. It can be changed, but not cleared.

Each row can also have notes: Ripple 41 mV at 2 A, limit 30 mV. The run itself has three more fields, saved together with Save details:

Completing a run

• Complete run is refused while any row is unset, and when every row is didn't cover, since such a run checked nothing.
• It is also refused while a row is marked Needs review: the requirement changed in meaning after that row's status was set. Set the status again, then complete.
• A completed run cannot be reopened. If something was wrong, open another run.
• Only completed runs count towards statuses. A run in progress affects only its own cite.

Later runs

Each completed run replaces the one before it: a requirement's status uses only the latest completed run of each verification. The older run stays, faded, and its page says A later completed run replaces this one.

A run can be deleted. It no longer counts, and the latest completed run before it counts again. Reviews of the deleted run stop counting too; the confirmation says, for each requirement whose result changes, what it will show instead.

Ids and names

• For ever means an id is never used again, even after the thing is deleted. A title or name can be reused once nothing uses it.
• Codes and ids are letters, digits and hyphens. They start with a letter, do not end in a hyphen, and have no doubled hyphen. They are shown in capitals, whatever case you type.

How long a field can be

Anything longer than its limit is refused. Notes on a mapping or a run row say how many bytes are left once you are close, and a requirement's body shows its size from 12 KiB.