A previous Tip discussed how to estimate the scoping effort for a project. It was a guide that was presented as a very rough, manual estimate approach based upon the experience of SBDi. True estimating methods are complex and require the integration of many kinds of information that one does not have this early into the project.

Once the scoping effort is complete, management needs a cost estimate to determine if the project is even worth moving to the next step. T. Capers Jones, in his book Estimating Software Costs (McGraw-Hill, 1998) defines a high-level gross estimate approach for technology-based projects that is based upon the scope, class and system type of the application. The benefit of using this calculation is to obtain a rough estimate without a full understanding of the requirements. The concern with using this estimating formula is that all systems of the same scope, class, and system type will generate the same estimate. However, it will provide a cost estimate for executive management to assist in determining the estimated return on investment (potential revenue/potential cost).

After defining the scope, the next phase is the requirement definition phase. This phase is the most detailed of the requirements and takes the most amount of time to define. For technology-based projects, T. Capers Jones defines the percentage of time by project type, class, and system that is spent on the requirement definition.

SBDi takes a different approach based upon their experience. Again, this is a rough estimate and will vary considerably for the same reasons as specified in the April 2001 tip. However, it is a means of estimating staff and work effort. This estimate assumes you are using the Requirements Set Pattern to organize your requirement set.

1. Start with three days to set up and organize for this phase of the project.
2. For each "who" scope level 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" scope level requirement, estimate three days to refine the object or entity and its relationship among them.
4. For each "where" scope level requirement, estimate a day to refine your understanding.
5. For each "when" scope level requirement, estimate two days to define the event and high-level use case.
6. For each "why" scope level requirement, estimate two days to define the business rules.
7. For each "how" scope level requirement, estimate three days to define the product functions and features needed by the users.
8. For each "product constraint" and quality of service scope level requirement, estimate one day.
9. For each "project constraint" scope level requirement, estimate two days.
10. Two days for each intersecting requirement cell to uncover additional derived requirements.
11. Ten days to produce a business requirement specification covering all types of requirements and expectations. This includes the time spent cleaning up any diagrams so they are readable by all reviewers.
12. Five days to validate the requirement specification.
13. Two days to schedule and hold final meeting with the executive sponsor and make any final adjustments to the requirement definition (logical/business perspective).
14. Four days for Requirement Configuration Management support.
15. Two days for Process Improvement adjustments.

Scope creep begins to appear at this early stage of the product definition. Therefore, to the above estimate, we increase our time estimate by the following:

7% for small projects or when skilled requirement engineers are involved.

15% for medium sized projects or when varying skill sets are involved.

22% for large projects with many risks or when the skill set is unknown or multiple trainees are involved.

At this point in the project, you may be increasing the number of requirement engineers working on the project. Once you have more than one, a requirement architect is needed to coordinate the efforts and ensure that all requirements are captured (including any interfacing requirements between "requirement cells") and resolve any conflicts between requirements. Depending on the size of the project, a requirement engineer will be assigned to represent each domain in the product scope.

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

SBDi is available to assist your organization in defining the responsibilities that will fully support a quality requirement engineering effort.

Pat Ferdinandi