AE Stories

In response to my previous blog someone drew my attention to an article published a year ago by Ron Tolido: “De Dood van Requirements” (the death of requirements). The author foresees a brighter future if we stop thinking in terms of requirements, a future where ict and business collaborate in such a way that there is no longer a need to specify requirements.

It is a compelling vision. Traditionally, requirement elicitation and management consumed an inordinate amount of time and effort. So instead of just trying to speed things up, elimination seems a valid cure.

Ever since user stories were introduced to the world they have been compared to use cases. There has been a small war between the agilists promoting user stories and the “mainstream analysts” holding on to their use cases. But is all this rivalry really necessary?

When comparing use cases and user stories, they turn out to be different in every way:

• Use cases can be used as permanent documentation, User stories are thrown away at the end of the iteration
• Use cases are at the level of what the user is trying to achieve with the system, User stories are small enough to plan into an iteration and to iteratively and incrementally deliver value
• Use cases are a base for high level preliminary estimations, User stories are a base for development estimates

So to me they simply serve different purposes

 

In every requirements management effort there is a moment when the seemingly inevitable question comes up: “Are we talking about business requirements or IT requirements”. Other taxonomies are in use - the BABOK lists 5 levels- , this specific question seems to be triggered by whom should own and validate which requirements.

I will not discuss the role issue but I will demonstrate a clear distinction between business requirements and IT requirements. The answer boils down to dependencies.