"Correct" Requirements

Warning: This is one of my, how shall I say it – more “opinionated” posts. It is geared toward a specific audience; I posted it as a reply on the Agile-Testing Discussion list.

Concepts like “right” and “wrong” requirements “before design can begin” assume that:

(1) The customer can speak with one voice,
(2) The customer can know what he wants without first seeing an example,
(3) The customer never changes his mind,
(4) The market never changes: The “right” requirements last week, last month, or next year are all the same.
(5) Design and Requirements are two separate and distinct processes that do not feed each other. That is to say, it is not possible, or at least not desirable, to innovate on the specification with interesting design ideas. (For example: “The spec says do A,B,C,D which might take a year. But just A,B,C we could do in two months. Can we do just A,B,C, deliver it, and see if we need D at all?”)

Now let me ask: for any given project you are working on, are statements one through five actually true?

One comment on “"Correct" Requirements

Leave a Reply

Your email address will not be published. Required fields are marked *