Part 1 of this two-part article described top-down estimation techniques and their applicability to estimating effort and duration needed to define requirements. In Part 2, bottom-up estimation will be described. The article concludes with a suggested initial set of tasks that probably would be needed to define requirements and thereby estimate requirements definition time and effort.
- Reliably estimating the software requirements effort
- Reliably estimating the requirements effort - Part 2
The second major estimating approach, bottom-up estimates, breaks down the expected work into task and sub-task pieces, estimates each piece, and rolls up the estimates into the estimate for the total.
Bottom-up estimates take longer to prepare than top-down estimates but generally are more accurate because they are less likely to overlook tasks, which is the greatest mechanical source of estimating errors. Overlooked tasks cause wrong estimates by reducing the reference's similarity to the target, distorting scaling, and making historical data inaccurate.
Driving a task down into detail increases estimating accuracy by identifying lower-level tasks that are overlooked at higher levels. Smaller tasks can be estimated more reliably because they are easier to fit to reference tasks. On the other hand, the further down in detail a task is decomposed, the longer it takes to do the bottom-up estimate; and especially early in a project, there may not be enough information known to drive some tasks into much detail.
Thus, when estimating, it's important to balance the depth of task definition detail. Tasks that are known and near-term should be driven down to greater detail. Tasks that are less certain and further out in time should be kept at higher levels of detail and adjusted with suitable factors to take uncertainty into account.
Since it's necessary, ultimately, to know what the tasks are, in order to perform the project, why not define them when they also can assist in creating more accurate estimates? The requirements effort is the part of a software project that is least amenable to top-down estimates, because there's no reliable way to identify, size, and scale a reference requirements effort. That is, you can't just estimate this target project's requirements effort based on whatever you spent defining requirements on your last project. Consequently, identifying the specific needed requirements definition tasks is essentially the only way to reliably estimate the effort and duration.
Requirements Definition Estimating
The following set of tasks and sub-tasks represent a fairly thorough starting point for planning and reliably estimating the requirements definition work. Work should be estimated for defining high-level REAL business requirements, typically during a project initiation, chartering or feasibility analysis phase, and for a requirements definition and analysis phase that drives down to detail the subset of the high-level business requirements which will be implemented. I encourage using the powerful Problem Pyramid™ to guide discovering the REAL business requirements.
Then the detailed REAL business requirements deliverable whats should be mapped to requirements specifications and use cases of a product or system how which meets the REAL business requirements. Each expected requirements detailing iteration and increment should be identified and estimated individually.
For each lowest-level task, identify a relevant reference to use in estimating the effort and intrinsic duration needed by a resource of a defined skill to accomplish the task. Then estimate the project schedule timeline by working backwards from the deadline, arranging tasks with respect to task and resource dependencies and concurrencies, and accounting for extrinsic factors that affect when tasks can be started and completed.
Requirements Definition Tasks
Some business analysis tasks that need to be planned and estimated for defining high-level and detailed requirements include:
- Meet with management to understand the project and (ongoing) review status.
- Research the subject area.
- Gather data about the business requirements:
- Plan, conduct, and document interviews with specified stakeholders/roles.
- Arrange and conduct follow-up and other unplanned interviews.
- Review documents collected during data gathering.
- Prepare, distribute, collect, analyze, and follow-up on surveys and questionnaires.
- Plan, conduct, and document requirements workshops (Joint Application Development—JAD), focus groups, and other facilitated group sessions.
- Observe operations.
- Learn to do the work.
- Prototype on paper and/or electronically.
- Analyze the collected data and gather additional data to update it as needed.
- Draft business requirements.
- Review business requirements draft for clarity, accuracy and completeness.
- Finalize business requirements, including re-review as needed.
- Gather data, draft, and review user acceptance criteria.
- During project initiation, identify top-level product/system requirements and estimate resources, effort, intrinsic duration, and ROI for alternative ways to accomplish the business requirements.
- Review and decide among alternatives to be implemented, including "no change."
- During detailed requirements definition/analysis
- Map REAL business requirements to product/system requirements and use cases.
- Estimate resources, effort, intrinsic duration, and ROI for implementing the selected products/systems.
- Update project plans based on current information.
Robin F. Goldsmith, JD is President of Needham, MA consultancy Go Pro Management, Inc. He works directly with and trains business and systems professionals in requirements, quality and testing, metrics, ROI, and project and process management. He is the author of Discovering REAL Business Requirements for Software Project Success.