Skip to main content

​
Requirements Overview

A Requirement in Roboticks is a single, addressable, testable statement of intent — “E-stop halts motion within 100 ms”, “battery low triggers return-to-home”, “perception latency stays under 50 ms at p99”. Each one has an ID. Each one can be linked to one or more tests. Each one carries its own audit trail.
Requirements are the unit of truth in Roboticks. Test results, evidence packs, and Check Run summaries are all measured against the requirement set in scope for the run.

​
Anatomy of a Requirement

The canonical JSON Schema lives at roboticks-sdk/schemas/requirement.schema.json — every ingest path validates against it.

​
The four ingestion paths

You can mix and match per project — for example, ingest a ReqIF export from Jama for the production set and use inline YAML for sandbox/exploratory work.

ReqIF

The industry standard XML format. Round-trippable — export from Polarion, Jama, codeBeamer, or DOORS and re-export later without losing fields.

PDF

Bedrock Claude extracts structured requirements from a PDF (ISO 10218 text, internal SRS) into the schema. Low-confidence extractions are flagged for human review before commit.

Inline YAML

Commit roboticks/requirements.yaml to your repo. Simplest for small projects; lives next to the tests and ships through the same PR review.

Manual

Add requirements one at a time in the dashboard. Best for ad-hoc additions or quick spikes.

​
Hierarchy

Requirements form a tree via parent_id. A common shape: Coverage rolls up: a parent requirement is confirmed if all child requirements are confirmed. See Hierarchy for the full rollup rules.

​
Snapshotting

When you cut a release, Roboticks freezes the requirement set into an immutable snapshot. From that point on:
  • Editing a snapshotted requirement creates a new version. The release continues to reference the version that was in scope at snapshot time.
  • The evidence pack generated for the release embeds the snapshot. Anyone — auditor, future self, regulator — can replay exactly what the release was verified against.
  • The audit trail records every edit, with author, timestamp, and diff.
This is what makes Roboticks audit-grade: a release passes or fails against the requirement set that existed at the moment it was cut, not whatever the live state happens to be when the auditor opens the package three years later. Full details in Snapshotting.

​
Lifecycle of a requirement

Each stage adds an entry to the requirement’s audit trail. The trail is exposed in the dashboard under the requirement detail page and exported in full in the evidence pack.

​
Where requirements appear in the platform

​
What requirements are not

  • Not user stories. A user story is “as a forklift operator, I want to pick a pallet”; a requirement is “the perception stack shall detect a EUR-pallet at 5 m with 99% recall”. User stories live in Jira/Linear; requirements live here.
  • Not test cases. A test confirms a requirement; the requirement is the spec.
  • Not free-text design notes. Anything you can’t bind a pass/fail criterion to belongs in your design doc, not in Roboticks.

​
Next

Upload requirements

Step-by-step for each of the four ingestion paths.

Authoring inline YAML

The schema, with examples per requirement type.

ReqIF round-trip

Polarion / Jama / codeBeamer / DOORS field mappings.

Snapshotting

Per-release immutability and the audit trail.