On Tue, Apr 30, 2013 at 8:30 AM, Duncan <1i5t5.dun...@cox.net> wrote: > Another analogy would be that these people are human versions of the > kernel's trinity fuzz tester...
Requirements generally are not intended to be defensible to fuzz testing, or completely determinate. Rather, they're intended to be detailed in the things that are really critical, and less detailed where everybody should be able to get the gist of what is specified. When you actually take the time to write an absolutely unambiguous requirement spec a few things happen: 1. Nobody bothers to read it. 2. Those who read it can't grok it, because the forest is invisible for the trees. 3. The result of 1+2 is that the spec usually ends up being wrong. So, if the goal of the exercise is to be able to blame the people who signed the requirement for anything that goes wrong, then an extremely detailed requirements document is generally the best way to go. If the goal is to just get everybody on the same page and align subject matter experts with those who will be designing/coding the software, then the appropriate level of details is generally lower. There are also compromises like a series of nested documents that spell out the specs in increasing levels of detail (use cases, business requirements, functional requirements, design specifications, etc). This a fairly bureaucratic exercise, and rarely do orgs have the time to properly document and maintain trace-ability between these, so the result is that it ends up being a lot of paper done for the sake of checking boxes and the code is even more likely to be broken because everybody is looking at different documents that are never completely in-sync. However, done right (ie, with cost overruns like that of the F-35) this can allow projects to scale to fairly large sizes. Most of us are here because we find it "fun," so I think the simplest solution is to just do the right thing and treat requirements docs as useful tools when they're actually useful. I think PMS has been a great thing for Gentoo, but we shouldn't treat changing it like changing the TCP spec. Rich
