An article by Nilesh Raje has been published at the IIBA website which asks “Who Defines Requirements?” This brief article touches on the iterative nature of defining requirements and settles upon the premise that the earlier you baseline requirements the better the project will run.Nilesh’s article is probably a bit too brief to add a lot of value to many practicing business analysts but it does start you thinking about the topic. We know, for example, that requirements are good.
In fact, effective requirements definition and management are important. The oft quoted Standish CHAOS report identified at on e point that 40-60% of project failures can be related back to poor requirements.
We want to know more. So, let me ask the Requirements Question a different way:
What is the journey that requirements take through the project lifecycle?
Who articulates them, in what format, where and when in the project lifecycle and environment? And while I am at it, how are they identified, and validated, who uses them and how are they communicated?
There is a requirements management maturity model written down and it deals with the increasing levels of formality and sophistication in eliciting and managing requirements. As usual the model comes in five levels.
- Chaos
- Written requirements
- Organised
- Structured
- Integrated
You can read more about this maturity model here.
Depending on an organisation’s maturity in dealing with requirements they journey will be different and as projects mature often the documentation catches up. For example, at the very earliest stages of a project it may be a few ideas or a diagram jotted down on scrap paper. These high level concepts may end up in a 150 page requirements tome.
Depending on an organisation’s maturity in dealing with requirements they journey will be different and as projects mature often the documentation catches up. For example, at the very earliest stages of a project it may be a few ideas or a diagram jotted down on scrap paper. These high level concepts may end up in a 150 page requirements tome.
At what point do you think requirements evolve from broad statements in a project scope document (or brief) to real tangible things that need to be identified in use cases or written into a requirements specification?
