Although not a document template, requirements management tools such as IBM Rational DOORS are full-fledged requirements databases. For each requirement, one can add additional attributes to it for various purposes, ranging from commentary to tracking. As a project progresses, these attributes are updated to reflect the current state of the requirement along with the feature(s) that it represents. You can then query over these attributes (find attributes with a certain value or set of values, free-form text fields that are not empty, and so on) and produce counts and metrics over these. In addition, you can export requirements to Word or Excel formats, optionally including these other attributes.

I’m not familiar with any other requirements management systems. Systems I’ve worked on tended to be small enough where an Excel spreadsheet was sufficient to provide the tracking and traceability of requirements, or DOORS was the system of choice by my employer. I suspect that a requirements database or a spreadsheet (with the ability to count, filter, and sort) would be far better the capturing these numbers and performing analysis.

So, yes. Tools like this exist. However, probably not in document/textual form – you really need some kind of table or data management system to do the kind of automated analysis you’re talking about.

For mobile software specification, we were using plain word documents to formalize requirements. We just used color conventions to annotate requirement status, like:

• dark for validated
• grey for new (not reviewed)
• red for requirement with issue discovered during review (before fix)
• green for requirement fixed after review (before change acceptance review)
• purple for requirement where client and subcontractor cannot agree on the requirement (these need special attention)

There was also a tracking of requirement status progress, updated by counting colored requirements when the document is edited.

For airborne software requirements, before formal review, we were using a yellow underfill whenever the content is known to be incomplete (like a ‘todo’). It’s more like a reminder for the document writer. There shall not be any yellow underfill before a formal review.

I found these color conventions quite efficient (agile?) to reduce the workload, compared to bug tracking or DOORS tools. Moreover it’s very easy to define your own standard.