, , , ,

Gary Lloyd author of  Business Leadership for IT Projects regularly writes on his blog Double Loop, this post asking “how else would one start a project, except with requirements?”, caught our eye, Gary continues…

After all, are not the “user requirements” an expression of what the customer wants?

Well yes and no.

In my experience, most approaches to requirements define what the customers wants at a micro-level or, at best, mixes micro and macro, such that the macro gets lost. It becomes difficult to see the wood for the trees.

And even when the macro requirements are highlighted, they are usually defined in terms of features and functions, rather than business value.

In addition, there is no consistent, unambiguous way of defining requirements. In some approaches, a requirement is represented by a one line statement, saying something like:

“Must be able to cancel a policy during the cooling off period”

In other approaches, this sort of statement would be accompanied by detailed definitions of associated data and functions. But this approach drifts into design, defining how goals are achieved, not what goals need to be achieved.

“Use Cases” or “User Stories” are another popular approach.  But these too are, to my mind, more design than requirements.

It’s little wonder that “poor or changing requirements” is cited as one of the majour causes of project failure…

Read the rest  on the Double Loop blog