Quote:
|
Originally Posted by BizAnalyst
Suppose you have very good/smart/engaged dev team. Consider 3 levels of requirements:
- Mediocre: gives the dev team some structure/thought about what the system must do, but definitely has holes.
- Very good: well thought-out, covers most of bases. Has a few holes.
- Excellent: well thought-out, has as few holes as humanly possible.
I believe you get the best system with the excellent requirements.
Here's my interesting question: do you get a better system with the mediocre requirements or the very good requirements?
I think this is a legitimate question because the very good requirements may be good enough that the developers start to trust them, and don't perform an excellent review. Whereas with the mediocre requirements, the developers get in the habit of questioning everything. |
Great question!
First, it depends what you mean by "better system". One view of requirements is that they describe a system that is "good enough". They may also indicate the value of being better than "good enough" in certain ways. If your requirements are deficient in this respect, then you are quite likely to get a system that is better than "good enough" in some respects. Some people might argue that such a system is "too good", but try taking away some of the excess goodness and see what sort of response you get!
Secondly, it depends what you mean by "well thought-out". To some extent I think it means "designed", and here's why. To specify a requirement is to establish a criterion for a solution, to limit the universe of possible solutions to those that meet the requirement. The more completely you specify the requirements, the smaller this "solution universe" becomes. Let's suppose for the moment that an "excellent" set of requirements does not reduce the "solution universe" to a single solution. This leaves room for design to establish the preferred solution. But what criteria will the designer use? Those specified in the "excellent" requirements. So the requirements would include all conceivable trade-offs that a designer might need to consider, and express an opinion about the relative value of each characteristic. If your mind has not boggled at this thought, you might like to think of this as "hyper design" since, having no pre-conception about what the actual trade-offs might be, you have nevertheless pre-defined how to make all the design choices. Scary stuff! In practice, I think this means that requirements that resemble "excellent" requirements are actually the product of reverse-engineering a design.
Well, that's not the most convincing argument I've ever constructed, but it will have to do for now. What it boils down to is the belief that for any particular problem there are some requirements that only need to be specified for some solutions or solution sets. These may correspond to the "holes" in your "mediocre" requirements (by luck or good judgment), in which case maybe the "mediocre" requirements are better than the "excellent" ones. In any event, the "mediocre" requirements will tend to include the most critical requirements, and so provide sufficient input into the initial design phase. So long as everyone knows that there will need to be a further iteration of requirements specification, which may result in the need to revisit some high-level design decisions, where's the problem? (Oops! Sounds like I've just blundered into the Inception/Elaboration distinction in RUP. Not where I thought I was heading...)