Writing Complete requirements is one of the twelve elements of writing good requirements. Sometimes, you don’t have the opportunity to finish the job, and are forced to write incomplete requirements. How would you go about doing that?
Limited Time For Writing Requirements
Some projects dedicate enough time to define the requirements. “Enough” is a subjective term, but the precise definition isn’t the point. Your project probably doesn’t allocate enough resources to do everything you want with requirements. Also note – this is not an iterative vs. non-iterative discussion. BUFR (big up front requirements) have an obvious and easy to measure allocation of time and resources dedicated to requirements management. Agile processes and approaches that define “requirements as you go” also allocate time and resources to requirements management. It might not be tracked as such, but the allocation is still there.
Regardless of the process you choose, your requirements gathering activities will want to exceed the allocated capacity. In our article about managing software delivery with timeboxes, we presented four alternative solutions:
- Increase Time to finish everything.
- Increase Cost / Resources to finish everything.
- Finish a subset of the work.
- Reduce the quality of the deliverables.
A single deliverable is a combination of both content and quality.
By analogy, the same is true of requirements. You can deliver a use case poorly or well. Delivering it well takes more time.
Finishing A Subset of the Requirements
There are times that you can’t increase staff (or when Brooke’s law prevents that from being effective). There are times when you can’t delay the product. This leaves you with two choices – reduce quality or reduce quantity.
Suzanne Robertson has just written an article at the Requirements Networking Group site describing how to approach reducing the quantity. Suzanne’s approach involves working with stakeholders to identify which requirements to write first. Check it out.
The first comment there raises the point that this may be impractical – to deliver less than was promised. It is a very valid concern, and one of the areas that many iterative projects struggle with. Join in on the conversation there or here.
Latest Articles
Comments on all Articles
