Topic · ISO 29148

What is ISO 29148, and how do I keep the SRS hierarchy true in CI?

Gist

ISO/IEC/IEEE 29148:2018 is the requirements engineering standard. It names four documents. Proof compiles the two that are software (SyRS and SRS), prints them with proof doc generate npr7150-srs, and fails the merge when the graph is stale. Business requirements stay in the tool that already holds them.

proof doc generate npr7150-srs --output docs/srs.html

Keep Jama for programme authoring. Keep the IEEE 830 template if a class still asks for it. Proof is not a 29148 auditor, and it does not write a BRS.

Request demo One Word file vs four documents

01 · Four documents, not one Word file

A student SRS is not the hierarchy. The hierarchy is four named specs.

ISO 29148 clause 5.2 splits intent by owner. BRS is business. StRS is stakeholder. SyRS is the system. SRS is the software. One file that pretends to be all four is how the next commit leaves a heading that no longer matches the graph.

IEEE 830-1998 is the superseded sibling. It listed SRS sections. 29148 kept those sections and added the documents above the SRS. Proof's npr7150-srs template is a superset of the 830 section list. That is why IEEE 830 is an FAQ on this URL, not a twin. The NASA procedure that names the same SRS headings is NPR 7150.2D. That page is the handbook. This page is the ISO document types.

Clause 6.2 says a requirement shall be necessary, implementation-free, unambiguous, consistent, complete, singular, feasible, traceable, and verifiable. FRETish enforces the ones a grammar can see. Necessary is still a person. BRS is not supported: business goals stay in Jira or Linear. StRS is partial: a stakeholder requirement can carry a persona and a derived link; it is not a full StRS document.

proof validate --preflight
proof doc generate npr7150-srs --format html --output docs/srs.html
proof audit --fail-level warn

The first command rejects a sentence the 288 templates cannot parse. The second renders HTML or Markdown from loaded project data. PDF is a separate path and currently fails. The third is the standing gate. Generating docs before traces are refreshed is how the Word file got stale in the first place.

02 · The exhibit

One Word SRS, or four named documents with two of them gated.

The Word file still has Section 3. The owner of the shall moved. Click the tabs.

Word / IEEE 830 template

Opened Section 1–3 from last review
Owner everyone, which is no one

Headings present

This push

The SyRS shall changed. The Word file did not.

No re-render

Word / IEEE 830 template

Still last quarter. Still one file.

Keep it if a class asks

Proof

BRS not supported
StRS persona + derived_reqs, partial
SyRS / SRS FRETish + npr7150-srs
Gate audit --fail-level warn

Merge blocked if the graph is stale

One Word SRS, or four named documents with two of them gated. Click the tabs.

Who	What they notice	What they lose
ISO 29148:2018	Four document types. Clause 6.2 characteristics. Language rules in 6.3.	They write the requirement. Keep the standard. Proof is not a 29148 auditor.
IEEE 830-1998	SRS section list. Still what a class asks for.	Superseded. The section list lives as an FAQ here, not on a twin.
Jama / DOORS	A stored shall a person typed	They author the programme. They do not emit SyRS/SRS from the current graph. Keep them.
Proof	SyRS and SRS compiled, then `npr7150-srs` from current traces, then the same audit on every push	No BRS. StRS is partial. Necessary is still a person. PDF currently errors. Tests are not executed.

Clause 6.2, as the product actually enforces it:

proof validate --preflight
proof realize specs/system ./... --diagnose
proof audit --check spec_lint_ac_subset_of_satisfies
proof doc generate npr7150-srs --format md --output docs/srs.md

Unambiguous and singular fail at compile. Consistent and feasible are Kind2. Traceable is a re-derived link, not a cell someone filled. Verifiable is vacuity plus a witness. Necessary has a shall / should / may field and still needs a person. Implementation-free is the grammar: FRETish says what, not how.

We have not run this template against a frozen ISO 29148 corpus. The loss is named, not scored.

03 · The honest loss

A green Proof audit is not an ISO 29148 assessment.

BRS is not supported. StRS is partial. Necessary is human judgment. Proof will not sign that the programme wrote the right business goals.

Do not rank software requirements specification as a head. That SERP is student templates. This URL is the standard. IEEE 830 stays a FAQ. NPR 7150.2D keeps its own H1: NASA's procedure, not the ISO document types.

INCOSE Guide for Writing Requirements is the same grammar under another cover. FRETish already owns that H1 on machine-checkable requirements. The matrix H1 still lives on requirements traceability matrix. Jama still authors.

Request demo How the install is bought

04 · Nearby questions

What people type next.

What is IEEE 830? The 1998 SRS standard. Superseded by ISO 29148. Same section list, no document hierarchy. FAQ here, not a twin.

What is NPR 7150.2D, and how do I keep the SRS true in CI? NASA's procedure. Same template, different H1. NPR 7150.2D.

How do I write machine-checkable requirements for my software? FRETish is the compiler under clause 6.3. FRETish.

What is a requirements traceability matrix, and how do I keep it true? Clause 6.7. RTM.