Topic · Requirements summary

What is a requirements summary, and how do I keep it true in CI?

Gist

A requirements summary is the counts, IDs, and trace ratios that still match this graph. Proof prints that table from the current traces with proof doc generate req-summary, then fails the merge when the graph is stale.

proof doc generate req-summary --output docs/requirements.html

Keep Jama if you author the programme. Keep the SRS template if a review still asks for the full specification. Proof is not that document, and a printed summary is not proof the shalls are complete.

Request demo Last summary vs this push

01 · The one-page table

An SRS is not a summary. Last review's spreadsheet is not this push.

The summary lists how many shalls exist, which component they sit on, and how many still have a parent, a test, or an implementation. A person can fill those once. The next commit does not reopen Excel.

The full specification lives on software requirements specification. The matrix of links lives on requirements traceability matrix. The NASA procedure lives on NPR 7150.2D. This page is the compact table: render req-summary from the graph you already gate.

The template is seven blocks from loaded project data: key metrics (requirement count, components, variables, test-trace ratio), counts by status, by category, by type, by component, the ID list, and coverage ratios. Every loaded requirement ID appears. It will not invent a shall you did not declare. The “test coverage” cell is the share of shalls with a test trace, not line coverage, not MC/DC.

proof validate --preflight
proof doc generate req-summary --format html --output docs/requirements.html
proof audit --fail-level warn

The first command rejects a sentence the templates cannot parse. The second renders HTML (or Markdown) from the current graph. PDF is a separate path and currently fails. The third is the standing gate. Generating the summary before traces are refreshed is how last review's pack got stale.

02 · The exhibit

Same ID column. A date, or this graph.

The spreadsheet still has 48 rows. The graph moved. Click the tabs.

Excel / Confluence

Opened 48 IDs from last CCB
PAY-SYS-025 still listed active

Rows present

This push

The shall was split. The table did not.

No re-render

Excel / Confluence

Still last CCB. Still a date.

Keep the review minutes

Proof

Ask does req-summary still match traces
Gate audit --fail-level warn

Merge blocked if the graph is stale

Same ID column. A date, or this graph. Click the tabs.

Who	What they notice	What they lose
Excel / Confluence	A one-page ID list a reviewer can scan in a gate	The file is a date. It does not re-count after the next commit.
Jama Connect	Programme authoring, baselines, the shall as written	They still win at authoring. Proof does not replace Jama. That H1 lives on Proof vs Jama.
SRS (`npr7150-srs`)	The full specification: purpose, specific shalls, FRETish, LTL	Different H1. The artefact lives on software requirements specification.
RTM (`trace-matrix`)	Parent, test, and implementation links as a matrix	Different H1. The matrix lives on requirements traceability matrix.
Proof	Counts, IDs, and trace ratios from this tree, then the same audit on every push	Not an SRS. Not a Word template. Trace ratios are not MC/DC. PDF currently fails.

The ID list is the scan. The ratios are parent / test / implementation traces on those IDs, not statement coverage. Condition-level coverage is a different command:

proof mcdc measure ./... --engine go
proof audit --fail-level warn

Unknown requirement language fails before the table is printed. A thin graph makes a thin summary. Treat the ratios as a view of the traces, not as a second source of test completeness. We have not run this against a frozen corpus, and we have not scored it against Jama or DOORS on the same pack. The loss is named, not scored.

03 · The honest loss

A green Proof audit is not a complete requirements pack.

A summary is a table of what is already in the graph. It will not write the shall. It will not invent a component. Jama still authors.

Proof does not write a software quality assurance plan, a software verification plan, or a software development plan. Those strings have demand. This product does not ship those templates. An interface control document is the same park: no ICD template. IEEE 1012 is V&V process; that H1 stays on NASA-STD-8739.8. Object-code coverage on C still wants the qualified toolchain. That H1 lives on MC/DC for Go and on Proof vs LDRA. Proof generates inputs. It does not run them. Keep go test.

The verification report is a different template. That H1 lives on NASA-STD-8739.8. The design document is software design document. Jama still authors.

Request demo How the install is bought

04 · Nearby questions

What people type next.

What is a software requirements specification? The full artefact. Different template. SRS.

What is a requirements traceability matrix? The links, not the counts. RTM.

What is a software design document? Architecture and unit design under the shalls. SDD.

What is a verification report? Completeness by assurance level. NASA-STD-8739.8.

What is IEEE 1012? Software V&V process. Stays on 8739.8. Do not twin this URL.

What is a software quality assurance plan? No SQAP template. Parked. Do not treat this URL as that pack.

What is a software verification plan? No SVP template. Parked.

What is an interface control document? No ICD template. Parked. Do not rank 880 searches here.

What is a software development plan? No SDP template. Parked.

How do I measure MC/DC coverage for my Go code? The instrument, not the table. MC/DC for Go.