Plugins

Requirements

Requirements

The Requirements plugin turns a page into a requirements database: numbered items with a schema you control, trace links between them, allocation to a system architecture, and a verification matrix that tells you what is not covered.

Requirements is a paid plugin (SKU requirements).

Collections

A collection is a page of type Requirements. Create one from the New content menu in a space, or from the space rail. Because it is a page, it inherits space permissions, sharing, search and URLs.

Each collection owns:

• a key scheme used to number its items: a prefix, a separator and a digit count. The default is REQ, a hyphen and three digits, producing REQ-001; a collection that chooses WB, a hyphen and four digits produces WB-0001
• an item label, singular and plural, requirement / requirements by default. A collection that tracks objectives or user stories can say so here
• vocabularies for statuses, priorities, verification methods, and trace link types
• its own field schema

Defaults for new collections come from Admin -> Requirements. Existing collections keep whatever they were created with.

Reference keys

Open Workflow from the rail. The Reference keys section holds three controls and an example that updates as you change them:

Saving a new scheme changes how items created from now on are numbered. Items that already have a key keep it.

Renumbering a collection

To move the existing items onto the scheme, press Renumber in the same section. A preview lists the first keys as Now and After, with the number of items and how many will move. Confirm, and every item is renumbered 1, 2, 3 and so on in the order of the grid, with items in the trash numbered after the live ones. Gaps close: an item that was REQ-007 may become WB-0005.

Nothing is lost. Each item remembers every key it used to have (open it and look behind the (i) beside the key), so a search for an old key still finds it and the verification matrix filter matches it. Every renumbered item gains a history entry called Renumbered holding the old key. Trace links are relabelled with the new keys and nothing is flagged as suspect. Baselines keep the keys they froze, and comparing a baseline from before with one from after lists the moves under Renumbered rather than as removals and additions.

Renumbering needs full access to the collection, so Renumber is shown only to people who have it, and a collection under a baseline refuses it. To undo one, renumber again under the previous scheme.

Templates

A brand-new, empty collection opens on Choose a template. A template instantiates the field schema, statuses and verification methods for a standard. The schema is copied into the collection, so you can tailor it afterwards.

A collection adopts a template once. After that, change the schema through the Fields editor.

The tool rail

Everything in a collection is reached from the icon rail on the right.

If you can only view the collection, the header says so, and the rail offers no Add new item, Custom fields, Workflow, Template upgrade or Save as template. System architecture and Baselines open for reading, without the controls that add, edit, take, lock or delete.

The grid

The grid lists every requirement on one line each, with columns Ref, the item label (Requirement by default), Status and Priority. Rename with the pencil in the row’s actions, or double-click the title. Click the status chip to move the item to one of the statuses its workflow allows from there; press a glyph on the priority strip to set the priority, or the hollow circle to clear it. Click the row, title included, to open a summary under it (the statement, the rationale, the verification method and when it last changed; the priority and status are already on the row), and again to close it; only one row is open at a time, and Escape closes it. Click the ref key, or the Open glyph in the summary, to open the detail modal. When the window is too narrow for every column, the grid scrolls sideways inside its own frame with the ref key, the title and the row actions staying put.

The requirement schema

Every requirement carries built-in fields:

The editor reads in that order: title, statement, rationale, then status, priority and verification, then the collection’s own sections (classification and the rest), then decomposition, allocations and traces.

The rationale is not a column. Every collection starts with one ordinary custom field named Rationale, carrying the Rationale role, and that role is what puts it under the statement. Rename it, change its help text, or delete it, as with any field; a collection that has none simply shows nothing there. A template that adopts onto a fresh collection updates this field rather than adding a second one.

On top of that, a collection defines custom fields through Custom fields in the rail. Add a field with a name, a type, and an optional role.

A role tells the rest of the plugin what a field means. Roles are unique per collection.

Fields can be added and deleted. A field’s type cannot be changed once created, and deleting a field hides its stored values rather than erasing them: re-add the field and the values reappear.

Traceability

A trace is a typed, directed link between two requirements. Add one from the Traces section of a requirement’s detail modal: pick a link type, pick the target, press Link.

The link types available by default are derives, satisfies, verifies, refines, depends_on and conflicts. The set is per collection and configurable.

graph LR
SYS["REQ-001 System requirement"]
HL["REQ-014 High-level requirement"]
LL["REQ-102 Low-level requirement"]
TC["REQ-310 Verification item"]
NODE["Flight Control System (subsystem)"]

HL -->|derives| SYS
LL -->|refines| HL
TC -->|verifies| HL
HL -.->|allocated_to| NODE

verifies is the one link type with extra meaning: it is what the verification matrix reads to fill the Verified by column.

Suspect links

When either end of a trace changes after the link was made, the link is flagged suspect and the collection header shows a count, for example “3 suspect links”, with the tooltip Trace links whose endpoints changed since last review. Open the requirement, read the change, and press Review on the link to clear the flag.

The trace canvas

Trace canvas in the rail draws the collection as a graph. Requirement nodes show the ref key, safety badge, title, status and verification method. Drag from one requirement’s handle to another to create a link, then pick the type from the popup. Drag from a requirement to a system node to allocate it. Select an edge and press Delete or Backspace to remove it.

Node positions are saved. Re-layout resets manual positions and auto-lays out the graph.

The systems tree

System architecture opens the Systems panel: a shared architecture tree for the whole nexus, not per collection. Requirements allocate to nodes from their detail view or by dragging on the canvas.

Nodes have a name, an optional ref number, and a kind: System, Subsystem, Assembly, Component, or Interface. Add a node with the Add node form, choosing a Parent (or “root (new architecture)”). Use the row’s add button to pre-select that row as the parent. Deleting a node deletes its entire subtree, along with its allocations.

graph TD
A["Aircraft (system)"] --> B["Flight Control System (subsystem)"]
A --> C["Power (subsystem)"]
B --> D["Autopilot Computer (assembly)"]
D --> E["IMU (component)"]
D --> F["ARINC-429 Bus (interface)"]

Each row shows how many requirements in the current collection are allocated to it.

Allocation is the answer to “which part of the architecture is responsible for this requirement”. Manage it from the Allocated to section of the detail modal: pick a node, press Allocate. It is distinct from a trace link.

The verification matrix (VCRM)

Verification matrix in the rail opens the verification cross-reference matrix: one row per requirement, showing how each one is verified and what is missing.

Three summary widgets sit above the table:

• Unallocated requirements: requirements not allocated to any system node.
• System nodes without requirements: nodes with no allocation on the node or anywhere beneath it.
• Compliance issues: the total count of problems found in the table.

The table columns are:

Three issues are reported: no verification method, no verifying trace, and suspect verification link. The first two are only raised for requirements that have reached a status where verification is expected (approved, implemented, validated, verified, closed), so drafts do not flood the count.

Admin defaults

Open Admin -> Requirements and pick the nexus under Nexus. The list holds the nexuses you administer.

The tab sets what new collections in that nexus start with. Existing collections are untouched.

Vocabulary lists are comma-separated. Leaving a list blank keeps the current default, so a collection never inherits an empty vocabulary. Press Save defaults.