Docs
BreezeBlock keeps a product's requirements together with the tests that verify them, and the record of each time a test was run. These pages say what each thing in the workspace is, how the pieces connect, and where every status comes from.
- The pieces: what lists, requirements, verifications, mappings and runs hold, and the rules each follows.
- Status: how every status is worked out, with examples.
- Text formatting: bold, italic, code, maths, links and cites in written text, and Cited in.
- Using the workspace: the tree, moving requirements, the filters, Go to, and editing in two windows.
What BreezeBlock holds
Requirement list
HW Hardware
HW-1Power supplyHW-33V3 rail toleranceHW-4Inrush current
mapped to
Verification
VERIF-PWR Power rail test
Versions 1, 2, 3, and one draft.
opens a run on the latest version
Run VERIF-PWR:RUN-3
HW-3passedHW-4failed
One row per mapping, fixed for this run.
- Requirement list
- A named set of requirements with a short code, such as
HWfor Hardware. A workspace usually has a few: hardware, firmware, integration. - Requirement
- One thing the product must do, cited by its list's code and a number:
HW-3. The requirements in a list form a tree. A requirement can have children that break it down, and its status takes theirs into account. - Verification
- A test, analysis or inspection that checks requirements. You give it a short id, such as
VERIF-PWR. Its description, the procedure, is kept in numbered versions. Changing the procedure means committing a new version. - Mapping
- A link saying that a verification covers a requirement. A requirement can be mapped to several verifications, and a verification to many requirements.
- Run
- One occasion on which a verification was carried out, cited as
VERIF-PWR:RUN-3. It uses the latest version at the moment it is opened, and takes one row for each requirement mapped then. Later mappings do not join it, and a version committed later does not change it. - Row
- One requirement's line on a run. Whoever runs the test sets it to passed, failed or didn't cover, with notes if needed.
Rows are the only place a result is entered. Every other status in BreezeBlock is worked out from them: a run's result from its rows, a verification's result from its last completed run, and a requirement's status from the latest completed run of each verification mapped to it or to its children. Status gives the rules.
Reading a cite
Every list, requirement, verification and run has a short id, its cite. The workspace draws each cite as a small tag, and the tag's fill is that thing's own status. It is never used for anything else: where the workspace states some other result, it does so in words (below).
Shape: what kind of thing
| Kind | Drawn as | Example |
|---|---|---|
| Requirement | Rectangle | HW-3 |
| Verification | Pill | VERIF-PWR |
| Run | Pill, with the run number | VERIF-PWR:RUN-3 |
| List | Outline only. A list has no status. | HW |
On a verification's own page its runs are shortened to RUN-3, since the page already names the verification.
Fill: what status
Each status has a pattern as well as a colour, so it can be told apart without colour.
| Status | Looks like | Examples |
|---|---|---|
| Pass | Flat green, green edge | HW-3VERIF-PWR |
| Partial pass | Left half filled green | HW-3VERIF-PWR |
| Fail | Diagonal hatching, red edge | HW-3VERIF-PWR |
| Untested | Flat grey, no edge | HW-3VERIF-PWR |
| No coverage | White, dashed edge | HW-3VERIF-PWR |
No coverage is not a status of its own. It is Untested with nothing mapped: on a requirement, nothing on it or below it is mapped to a verification; on a verification, it is mapped to no requirement. Untested with something mapped means a mapping exists but no completed run has passed or failed it yet.
In the workspace, hovering over a cite shows its status in words.
Selected
The cite of the place you are on, such as the selected row in a tree or the heading of the open page, is drawn solid in its own status's colour. Selecting something never hides its status.
HW-3 HW-4 HW-5 HW-6 HW-7
Faded
A completed run that a later completed run of the same verification has replaced is faded, along with every requirement cite on its page. Its results no longer count towards any status. Here VERIF-PWR:RUN-2 failed, and VERIF-PWR:RUN-3 replaced it.
In written text
A cite typed into a statement, a body, notes or a description becomes a link drawn the same way, a little quieter so that it reads as part of the sentence. It has no edge, except where the edge is the cue: dashed for No coverage, an outline for a list. It is not faded, even when the run it names has been replaced.
The 3V3 rail shall stay within 3% of nominal from 0 to 2 A, as measured by VERIF-PWR. Load limits are in HW-9, and the regulator's enable pin in FW-12.
Results as words
Where the workspace states a result rather than drawing a cite, it writes the status as a word with a mark whose shape does not depend on colour:
Pass Partial pass Fail Untested No coverage
A mapping's outcome is written the same way: Passed, Failed, Didn't cover or Untested. Didn't cover means the latest completed run included the mapping but did not check it, and it counts as untested.
A row that states an outcome is about a pair, a requirement and a verification, so the cites on it are drawn neutral. On HW-3's pane:
VERIF-PWR Passed in RUN-3
HW-3 can say Passed for VERIF-PWR while its own cite is hatched because another verification failed it, and RUN-3 can have failed overall because of another requirement. Each of those statuses is on its own cite, elsewhere.
Bars count requirements by status in the same colours, with Fail hatched and No coverage broken. The legend under a bar draws each status as a cite: Pass, Partial pass, Fail, Untested, No coverage. On a list's page the legend is also the status filter.