A previous Tip discussed how to estimate the logical or business view of the scope. The very rough manual estimate approach is based upon the experience of SBDi. At this point in time, a tool such as KnowledgePlan (www.spr.com) can be used to assist in determining the duration and cost of the project. The results are based upon actual metrics from over 8,000 projects. The product is extremely easy to use and can be calibrated with experience from your company's past projects. Your own process, with assistance from Software Productivity Research, can be incorporated and cross-referenced to their project template.

At this point in the project, the scoping requirements have evolved into business requirements. Now the business requirements will evolve into a designer's view or designer-level requirements. Remember that technology is still not imposed upon the requirements. This is when the essential details of the requirements are defined. It is with this perspective that all the details needed to determine the physical design would be specified. Data/class models, DFD/object models, state transition diagrams, activity diagrams, network models, and so forth, will be produced in detail.

Though SBDi uses KnowledgePlan to estimate the whole project effort, we also use our experience to estimate this phase of requirement evolution. During this phase we take into account the same adjustment variables that were described during the scoping phase. We also add the scope creep estimates described during the business requirement phase. Both of those adjustments are made upon the following initial manual estimate.

1. Start with three days to set up and organize for this phase of the project.
2. For each "who" business requirement, estimate two days to talk to each area identifying the details of their responsibilities and means of interaction with the scope.
3. For each "what" business requirement, estimate four days to refine the object or entity and its relationship.
4. For each "where" business requirement, estimate two days to refine your understanding.
5. For each "when" business requirement, estimate two days to define the event and use case.
6. For each "why" business requirement, estimate three days to define the business rules.
7. For each "how" business requirement, estimate three days to define the product functions and features needed by the users.
8. For each "product constraint" and quality of service business level requirement, estimate two days.
9. For each "project constraint" business requirement, estimate three days. Assembling the project plan that includes a full schedule takes time.
10. Three days for each intersecting requirement cell to uncover additional derived requirements.
11. Fifteen days to assemble a detailed requirement specification covering all types of requirements and expectations. This includes the time spent cleaning up all models produced during this phase.
12. Ten days to validate the requirement specification that will take multiple individual reviews.
13. Two days to schedule and hold final meeting with the executive sponsor and make any final adjustments to the detailed requirement definition.

This is a manual estimate based only upon SBDi experience, which is much less than the experience of Software Productivity Research. Therefore, this estimate will probably be incorrect by about 35%, at least 75% of the time. We acknowledge that our estimating approach to requirement development would be considered by most of the software community as an art rather than a science.

Though approximately 20% to 30% of the entire project has been completed, we acknowledge that this is NOT the end of the requirement evolution. Derived requirements and scope creep will continue as the development process continues. For the remaining phases, we recommend approximately 5% of the phase/stage time be allocated to requirements. This will include modifications to existing requirements, validation of other work product adhering to the requirement set and, of course, developing new (initial [scope creep] and derived [perspective specific]) requirements.

We will end the quarter and the discussion on requirement estimation with a request:

Please let us know your method of estimating the requirement effort. We at SBDi are open to all comments and are willing to adjust our thinking based upon others' experience and results from the metric community. The International Standards Organization (ISO) is currently attempting to define an overall standard for sizing software using function points as the start. SBDi has great hope for such a standard.

SBDi recommends that the IEEE Software Engineering Standards be used to develop the template for the requirement specification.

Pat Ferdinandi