A requirement is a test that nobody runs
Notes from my first months building a requirements tool for an aerospace programme, where the specification is the product and most of it has never been executed.
I finished my degree this year and my first job is on a requirements-management tool for an aerospace programme. I expected to write software. What I mostly do is read requirements, thousands of them. I am new at this, so take what follows as notes from someone still finding their way around. The main thing I have noticed so far is that requirements are a kind of code.
A requirement looks like this:
It has a subject, a verb, a condition and a tolerance. It can be traced to a parent, it can be satisfied or not, and somebody will eventually have to prove which. That is a test case. The difference is that nobody runs it for years.
Bugs in a language without a compiler
Since a requirement is written in English, nothing checks it when it is saved. The mistakes are the same ones I make in code, they just survive longer.
Undefined references. "The system shall respond as specified in the interface document." Which document, which version? In code this would not link.
Two statements in one. "The unit shall log the fault and notify the operator." If it logs and does not notify, has it passed? An and in a requirement is two requirements sharing one identifier, and one traceability link.
No tolerance. "The display shall update quickly." Quickly cannot fail, so it cannot pass.
Escape clauses. "Where possible", "as appropriate", "if necessary". Each one turns an obligation into a suggestion.
None of this is new, and anyone who has done this job for twenty years will find it obvious. There are guides that list these patterns, and a notation called EARS that gives each kind of requirement a fixed sentence shape. What surprised me is how mechanical most of it is. A person reviewing requirement number nine hundred is not better at spotting "as appropriate" than a program would be.
What the tool is really for
I thought a requirements tool was a database with a nice editor. I was wrong about that, and it took me a few months to see it. It is closer to a build system. The valuable features are the ones that fail:
a requirement with no parent is an orphan, and someone added scope without saying so,
a requirement with no child was never implemented or never traced,
a requirement that changed after its children were written makes every child suspect.
That last one is exactly a stale build. The parent changed, the dependents were not rebuilt, and the tool's job is to mark them dirty and refuse to call the baseline clean.
What I take from it
Two things, for now.
The first is that the cheapest moment to find a problem is when the sentence is written, and a check that runs then is worth more than a review that runs later. I would like the tool to complain the way a compiler does: immediately, about the exact word.
The second is about my own code. I used to write tests after the fact, to confirm what I had built. Here the order is reversed for everything: the statement of what must be true exists first, and the implementation is judged against it. Working inside that for a few months has made "what would prove this wrong?" the first question I ask, before I write anything.
I do not know yet how far automatic checking of plain English can go. That is what I want to find out next.