Requirements¶
A requirements table (name.requirements.json) keeps the requirements
of a project: a row per requirement, with
- its ID, as your requirements are numbered (
LLR-012); - its title, a short name;
- its text, as a reviewer reads it;
- its formula, its logic, from which its circuit is built (Formulas);
- the state of its circuit and of its MC/DC tests.
Below the requirements, past a separator you drag to share the height, are the signals the formulas read, declared once for the whole table.
Editing the table¶
- A click selects a row (Shift and Ctrl select more; the arrow keys move between cells). Enter, F2 or a second click edits a cell: Enter applies, Escape cancels, Tab goes to the next cell.
- + Add adds a requirement numbered after the others (
LLR-013afterLLR-012). - The right-click menu of the selected rows (Shift+F10) opens a circuit, duplicates, deletes and moves them (Alt+Up, Alt+Down), generates their tests and their report.
- The table's ⋯ menu sorts by ID, writes the report, and imports and exports: Import CSV…, Export CSV…, Import circuits….
- Search shows the rows with a text.
- An identifier missing or used twice is marked.
The formula is checked as you type it: what it reads, or the mistake and where it is.
Signals¶
Signals lists every name the formulas read, and every name declared: its type (bool (not declared) for a name not declared), a description (its unit, where it comes from), and the requirements that read it. A name declared that no formula reads says so; × removes a declaration; the last line declares a new signal. Changing a type builds again the circuits that read it.
The circuits¶
A double-click on a row (or Ctrl+Enter) opens its circuit, built from the formula:
- each operator is a block: an
andor anorof several operands one gate with several inputs, a comparison its box,ifa switch; - a name used twice is one In block; a name read k steps before goes
through a chain of k unit delays (
x_pre1,x_pre2, …, shared); - the formula's value is an Out block named after the identifier
(
LLR_012), the MC/DC decision.
The circuits are files in a folder next to the table
(name/LLR-012.intrepyd.json). A circuit follows its row: a change of the
formula, of the type of a signal it reads, or of the identifier builds it
again. A change of the circuit by hand makes it edited by hand: it no
longer follows the formula, until Build circuit replaces the hand
edits. In the circuit editor, the bar above the canvas shows the
requirement, and whether the circuit is still the one built from the
formula, with Open in table.
A formula whose nexts reach N steps ahead is built late by N steps:
its Out block at step s is the requirement at step s − N, which the bar
and the report say.
Importing and exporting¶
- Import CSV… reads requirements from a CSV file with a header row:
the columns
id,title,text(orrequirement, ordescription),formulaandsignalsare found by name, separated by commas or semicolons. A requirement whose identifier is in the table is updated, the others are added, and the signals (name: type, separated by commas) not declared yet are declared. - Export CSV… writes the table as CSV, each requirement with the declared signals it reads.
- Import circuits… takes in the circuits of the project that are the requirements of no table, where they are.
The report¶
Report… (the table's ⋯, or the studio's Project › Requirements report) writes one HTML file, to open in a browser and print to PDF:
- a first page sums up each requirement's coverage;
- then a page per requirement: its text, its formula, its circuit (the decision marked, its conditions outlined), the MC/DC table, the result in words, the tests' inputs step by step, and the circuit's file and SHA-256, so that the page says exactly which circuit it is about.
It asks which requirements to put in it, and, when some have no tests or tests out of date, whether to generate them first or to report them as they are. Then it asks where to save the report. The tables, and the tests as CSV, go in a folder beside it.