How do you know you are done?

A while back I wrote a series of posts on requirement do's and don'ts. I would like to revisit two of the themes from that series (Bad Practices - Part III - Escapes, Rambling & Mixing and Good Requirements - Part VI - Traceability & Modularity) to provide more of an end-to-end perspective on how you know when have enough to move to the next step.

If you look back at those two posts you will notice that I mentioned that traceability is very important as you move from a higher level requirement to a lower, more specific one. Furthermore, I cautioned against mixing high-level requirements with low-level requirements. To show you my reasoning, I would like to step back and examine the rationale behind the different parts of a project.

A project's steps

Please note that this is an abstraction and it makes a few assumptions such as the use of an iterative (e.g., Agile) methodology and the existence of a project with a good return.

1. Identify the business problem or opportunity.
2. Make sure it aligns with your business' goals and objectives.
3. Quantify the key performance metrics.
4. Measure how you are doing and have done historically (if you are enhancing a pre-existing behavior.)
5. Determine the major business capabilities that would address the problem (or capitalize on the opportunity.) This provides a basic overview of the big moving parts.
6. Determine the success criteria. What will happen if you do it right? This should tie back to the key performance metrics.
7. Estimate the value of each business capability (e.g., how much benefit would you get from it.) Most people equate this to ROI, however you should make sure that you account for the risk of the venture and the timing at which benefits would be realized. A project with a higher amount of risk should use a larger factor to discount the expected benefits. A project whose benefits will be realized far into the future should have those benefits discounted more than a project whose benefits will be realized earlier. After all, a million dollars today is worth more than a million dollars five years from today. This concept is called net present value or NPV. Tyner Blain has a great post on calculating ROI using NPV.
8. Prioritize the major business capabilities using a combination of their business value, dependencies and other prioritization criteria (e.g., legislative deadlines.)
9. Examine the highest value business capability and break it apart into reasonable pieces that can be investigated.
10. For each piece, define the key requirements keeping in mind design independence.
11. Determine which aspects require process changes, software solutions etc... Basically, do some solution architecture / design work. What can you reuse? What can you buy? What do you need to build?
12. Estimate a cost for realizing the design of the piece.
13. Assign a proportion of the high-level capability's benefit valuation to each piece.
14. Prioritize the pieces based on cost-benefit and dependencies.
15. Work with end-users to define the layouts, workflows and characteristics associated with the piece with the highest priority.
16. Start an iterative development cycle for this piece. You can also concurrently examine the next high priority capability.
17. Interact with your end-users to show progress, development and to keep them engaged with the project.

Observations

• Cost-benefit valuations are used to assist the prioritization of components to analyze and develop.
• Break things up into digestible chunks but know how the chunks fit into the grand scheme of things.
• More detailed requirements were prepared, but the order in which they were gathered matched the priority associated with the component. Do not waste time on things that have low value.
• Pieces that have low or negative cost-benefit may not be developed at all! The interactions with business users were deliberately setup to focus on the level of abstraction that was desired. Initially, only the big picture things were desired. Then the next level for the most important component. And finally the detailed requirements for the highest priority piece of that component.
• Engagement between business and IT users promotes joint accountability for success and failure.
• I have purposely avoided using names such as functional specifications, business requirements, user requirements, functional requirements and the like because I do not feel the name is what is important. A name may imply something different to another person. The important thing is the activity which transpires.

Other resources

If you are interested in this topic here are some other blog postings that you may want to check out.

• Requirements vs design - which is which and why? from Tyner Blain
• MRDs, PRDs, FRSes, and SRSes from Roger Cauvin
• Requirements document proliferation from Tyner Blain