A requirements document earns its keep once a team starts arguing inside it instead of over it in another tab.
Saved searches — requirements
Analysts rebuild the same filters every morning. A saved search should restore a view in one step and stay current as the data changes.
Half of daily active analysts save at least one search in the first month; median time to a saved view under ten seconds.
A requirement is only useful once it can be tracked from an idea to something shipped, which means it needs an identity and a state that changes as the work moves. The argument about whether it is ready belongs next to the requirement itself, not scattered across messages nobody can find again in a month. The team building the thing needs this, not the client deciding whether to pay for it.
A status a cell's colour can carry, right in the row
Each requirement keeps its own row, with an identifier and a status typed in beside it — colour the status cell and the state of the document shows at a glance.
An argument that stays attached to the line it is about
A comment on a requirement sits as a reply beside it, not a message in another channel, and clears once the disagreement is settled — reopened the moment somebody raises it again.
Which requirement the team keeps coming back to
You see which part of the document gets revisited as the work continues — often the one requirement that still is not settled.
An example — not your document. Sections are the document’s own headings.
Most of their attention went to “Table” — 2m 10s of 4m 00s. They came back to “Checklist”.
Time each section spent on screen, counted only while the tab was in front and the reader was active. It shows what was in front of them, not what they read.
This page is about what a requirements document has to do. For the blocks the editor is built from — see the editor.
There is no built-in status field — colour a cell to mark a state, the way a team already does in a spreadsheet.
Yes — the document owner is emailed on every new comment and reply, and anyone mentioned by name in it is emailed too. The reply itself sits next to the requirement it is about and stays there until it is resolved, so the argument is where the requirement is, not in a separate inbox.