The requirements describe the solution not the problem


The ideal user requirements should describe the required functionality in terms of what the system needs to do, but should not say anything about how the system is to do what it is to do.


Design is the prerogative of the designer.  The designer should be making decisions on how the system is to achieve the required functionality.  The designer is the person in whom all the necessary information comes together; before this happens, nobody is in full possession of the facts, any decision made earlier risks being wrong owing to inadequate information.  Yet requirements providers often give the requirements in the form of a ‘preferred’ solution; either in the mistaken belief that they are being helpful, or because it is the way they think about what they need, and don’t have the skill to analyse their needs better.  Unfortunately, recognizing the problem when it occurs is a bit of an art.

Prevention, Amelioration, Cure

If the requirements that are provided are too abstract, make them more concrete by asking ‘How’… How are we to go about filling this requirement?  In the more common case that the requirements are too concrete and are describing a specific solution, make them more abstract by asking ‘Why’ (AskFiveTimesWhy)… Why do you want the system to do this for us?  What goal is it achieving?


The problem of recognizing that what is being given is a particular solution can be addressed by asking if this could be done in a different way.  Ask yourself that, and ask the requirements provider that.  The experienced requirements elicitor gets a feel for solution requirements by the level and type of detail being provided, among other things.