Do you get a better system with Mediocre or Very Good requirements?

[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.

[achen]

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.

this is a really interesting question. We are working on a very large project that is somewhat understaffed so we can simply not write excellent requirements. My gut says that a mix of excellent and mediocre is required depending on the priority and difficulty of getting the area right.

[MGoyal]

this is a really interesting question. We are working on a very large project that is somewhat understaffed so we can simply not write excellent requirements. My gut says that a mix of excellent and mediocre is required depending on the priority and difficulty of getting the area right.

Great question indeed! If project reality precludes creating "excellent" requirements, I do think a mix of mediocre and excellent reqs should be the goal. Excellent shows the desired end result, while mediocre gets enough of the job done to successfully move the project forward.

[bkuhn]

If I'm reading the question correctly (and I may not be, so feel free to correct me), you're assuming that the documented requirements were correct, but just expressed poorly and/or with holes. So you're putting the burden on the development team to correctly interpret and fill in wholes where necessary.

But how do you know you got the correct requirements? Without properly expressed requirements, how can the business sign off and say "Yup, that's what we want you to build"? So dev could do an awesome job in interpreting the requirements, but wind up building the wrong thing. And let's not forget about the other consumers of the requirements (e.g. testing, training).

So I'd argue that there's a potentially large difference between very good and mediocre. You could probably recover from missing some stuff, but if the core requirements aren't right, you're toast.

My 2 cents-
B

[gescober]

Looks like a question Agile tries to answer. By your definition, User Stories are "mediocre" requirements that simply give the developer a basis for estimation and perhaps initial design. As you work iteratively, the user and developer collaborate closely to get the missing holes filled in through "conversations" and generation of "acceptance criteria." The Agile methodology eschews large, up front requirements efforts since they assume the requirements are going to change anyway.

The key difference here is how much collaboration occurs between user and developer after the requirements are done. If this is typical waterfall, where the requirements are thrown over the wall, then "very good" requirements will get you a better system than "mediocre" requirements. If there is lots of collaboration during development where the developers are working iteratively and validating their work with users, then the difference between "mediocre" and "very good" is much smaller.

[BizAnalyst]

If I'm reading the question correctly (and I may not be, so feel free to correct me), you're assuming that the documented requirements were correct, but just expressed poorly and/or with wholes. So you're putting the burden on the development team to correctly interpret and fill in wholes where necessary.

But how do you know you got the correct requirements? Without properly expressed requirements, how can the business sign off and say "Yup, that's what we want you to build"? So dev could do an awesome job in interpreting the requirements, but wind up building the wrong thing. And let's not forget about the other consumers of the requirements (e.g. testing, training).

So I'd argue that there's a potentially large difference between very good and mediocre. You could probably recover from missing some stuff, but if the core requirements aren't right, you're toast.

My 2 cents-
B

Great slant on the question and excellent points.

I'm kind of wondering about the psychology of reviewing. If you consider finding a problem a "reward", then what is the correct "reward" level for maximum performance in reviewing?

[AlanAJ]

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...)

[JCR]

Looks like a question Agile tries to answer. By your definition, User Stories are "mediocre" requirements that simply give the developer a basis for estimation and perhaps initial design. As you work iteratively, the user and developer collaborate closely to get the missing holes filled in through "conversations" and generation of "acceptance criteria." The Agile methodology eschews large, up front requirements efforts since they assume the requirements are going to change anyway.

The key difference here is how much collaboration occurs between user and developer after the requirements are done. If this is typical waterfall, where the requirements are thrown over the wall, then "very good" requirements will get you a better system than "mediocre" requirements. If there is lots of collaboration during development where the developers are working iteratively and validating their work with users, then the difference between "mediocre" and "very good" is much smaller.

Your assessment makes sense and is actually what we tend to do in following an Agile process. We have moved to an Agile approach for the last 1.5 years from iterative. Everyone had the requirements fear up front that I think is typical of such a switch. It is amazing how people come around though. It is harder for us to get participation in the requirements work we do up front than it is in the requirements work we do once people are looking at a live system. When stake holders can see the solution and play with it, suddenly they are way more interested in refining the requirements.

Our business side has been much happier since going to a psuedo-Agile model for us (Agile purists would not say we are fully Agile). They are invested in the solution and seem to feel the same pride of authorship that development usually feels. So the answer for us is that we get better end solutions doing pretty mediocre up front requirements. The customer is really the only guage of the system being bad, good or great that matters - and ours are giving us better marks with wimpy reqs.

[achen]

Your assessment makes sense and is actually what we tend to do in following an Agile process. We have moved to an Agile approach for the last 1.5 years from iterative. Everyone had the requirements fear up front that I think is typical of such a switch. It is amazing how people come around though. It is harder for us to get participation in the requirements work we do up front than it is in the requirements work we do once people are looking at a live system. When stake holders can see the solution and play with it, suddenly they are way more interested in refining the requirements.

Our business side has been much happier since going to a psuedo-Agile model for us (Agile purists would not say we are fully Agile). They are invested in the solution and seem to feel the same pride of authorship that development usually feels. So the answer for us is that we get better end solutions doing pretty mediocre up front requirements. The customer is really the only guage of the system being bad, good or great that matters - and ours are giving us better marks with wimpy reqs.

How large are the projects that you work on? How many developers, how many analysts, what kind of time frame between releases?

[JCR]

How large are the projects that you work on? How many developers, how many analysts, what kind of time frame between releases?

We are not doing "pure" Agile since we try to communicate to business larger release scopes. Internally, we have numerous sprints and releases, but we communicate outward releases that can range from 1 to 8 months.

We have feature teams made up of a minimum of 3 people and usually cap at 8. Each feature team has 1 BA, 1 QA, 1 Dev minimum. The larger feature teams have more BA or direct stake holders involved.