Requirements¶

Requirements live in the specification documents: URS, FS, DS and IS. Each has an ID (for example URS-001), a title, the requirement text, tags and a risk assessment.

Writing requirements¶

Add requirements to a draft specification. Each edit asks for a reason for change, which goes into the audit trail. Requirements are locked while their document is in review or approved.

Tracing¶

FS and DS requirements trace to the URS requirements they implement (URS ← FS ← DS). An FS or DS requirement that traces to nothing is the RTM gap orphan-requirement.

Tags¶

Tags group requirements (for example audit-trail, security). The RTM can be filtered by tag.

Importing from Markdown¶

A specification can import requirements from a pytest-gxp Markdown spec, so requirements written alongside the test code arrive with their IDs intact.

Requirement library¶

The library holds reusable requirements (LIB-001, …) that you can copy into any system.

• Authors create, edit and tag library requirements. Every content edit increments the version.
• When a version is first copied into a validation, it is frozen as a write-once record with its own page.
• The copied requirement links to that exact library version, and the link is part of the signed content.

Copy from the library on a draft specification, then risk-assess the copies in the context of this system.