Skip to main content

rbtk requirements

Requirements are the spine of the V-model. The CLI lets you push them in, inspect what’s tracked, see what’s covered, and export them back out.

rbtk requirements upload

Push requirements into the platform. Three input formats are accepted; the CLI sniffs by extension.

Examples

ReqIF round-trip caveats live on each RM connector page — see Jama, Polarion, codeBeamer, DOORS.

rbtk requirements list

List requirements in the current project.
Output:
stale means the last confirming test ran more than project.staleness_window ago — set in Project Settings → Requirements (default 7 days).

rbtk requirements show

Show one requirement with its full link graph.
--output json returns the full link graph including MCAP attachments, deadlines, and prior-run history.

rbtk requirements coverage

Per-requirement coverage status and gap analysis.
Compact output:
--format matrix emits a requirement-by-test grid suitable for jq or spreadsheet ingestion.

rbtk requirements export

Export the current requirement state as ReqIF (for round-trip into your RM tool) or YAML.
ReqIF exports are accepted by Jama, Polarion, codeBeamer, and DOORS (with ReqIF Studio for DOORS Classic). See the matching Integrations page.

Working with baselines

Every release tag implicitly snapshots a requirement baseline. Compare baselines:
Baselines are immutable — your auditor can ask “what were the requirements at v2.3.0?” and you can answer to the byte.

Next

Test commands

Run tests, see coverage update on PRs.

GitHub App

Auto-link PRs to requirement deltas via Check Runs.