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