Techniques Document Analysis

▶▶ Decision-makers may be reluctant to revisit decisions, even when more information

is available on areas of uncertainty that might change the optimal decision.

9.9 Document Analysis

9.9.1 Purpose
Document analysis is a means to elicit requirements by studying available documentation
on existing and comparable solutions and identifying relevant information.

9.9.2 Description
Document analysis may include analysis of business plans, market studies, contracts,
requests for proposal, statements of work, memos, existing guidelines, procedures,
training guides, competing product literature, published comparative product reviews,
problem reports, customer suggestion logs, and existing system specifications, among
others. Identifying and consulting all likely sources of requirements will result in
improved requirements coverage, assuming the documentation is up to date.

Document analysis is used if the objective is to gather details of existing solutions,

including business rules, entities, and attributes that need to be included in a new
solution or need to be updated for the current solution. This technique also applies
in situations where the subject matter experts for the existing solutions are no longer
with the organization, or are not going to be available throughout the duration of the
elicitation process.

9.9.3 Elements
.1 Preparation
Evaluate which existing system and business documentation is relevant, available and
appropriate for study.

.2 Document Review
▶▶ Study the material and identify relevant business details.

▶▶ Document business details as well as questions for follow-up with subject matter
experts.

.3 Wrap-up
▶▶ Review and confirm the selected details with subject matter experts.

▶▶ Organize information into requirements format.

▶▶ Obtain answers to follow-up questions.

9.9.4 Usage Considerations

.1 Advantages
▶▶ Not starting from a blank page.

▶▶ Leveraging existing materials to discover and/or confirm requirements.

BABOK® Guide, Version 2.0 169

Complimentary IIBA® Member Copy. Not for Redistribution or Resale.

Estimation Techniques

▶▶ A means to cross-check requirements from other elicitation techniques such as

interviews, job shadowing, surveys or focus groups.

.2 Disadvantages
▶▶ Limited to “as-is” perspective.

▶▶ Existing documentation may not be up-to-date or valid.

▶▶ Can be a time-consuming and even tedious process to locate the relevant

information.

9.10 Estimation
9.10.1 Purpose
Estimating techniques forecast the cost and effort involved in pursuing a course of
action.

9.10.2 Description
Estimation techniques are used to develop a better understanding of the possible range
of costs and effort associated with any initiative. Estimation is used when it is impossible
to determine exact costs. Estimation cannot and does not eliminate uncertainty; rather,
the purpose of estimation is to get a reasonable assessment of likely costs or effort
required.

The less information that is available to the estimator, the greater the range of uncertainty
will be. Estimates should be revisited as more information becomes available. Many
estimation techniques rely on historic performance records from the organization to
calibrate them against actual performance. Estimates should include an assessment of
the range of uncertainty associated with that estimate.

9.10.3 Elements
.1 Analogous Estimation
Use of a similar project as the basis for developing estimates for the current project. It is
used when little is known. Analogous estimating is often used to develop a rough order of
magnitude (ROM) estimate, and is also known as “top-down” estimating. This is usually
done at the beginning of the project or project phase and more detailed estimates follow
as more is known.

.2 Parametric Estimation
The use of parameters, multiplied by the number of hours. For parametric estimating to
be usable, enough history has to be available to be used as a basis of comparison. With
this type of estimating, the business analyst has done enough work to determine which
parameters can be used and how many there will be. For example, the business analyst
has determined that there will be ten use cases developed. The business analyst also has
history that indicates for each use case the total hours that will be spent, in this case
will be 20 hours. Using this technique, the business analyst can multiply 10 x 20 to get a
total, or 200 hours.

A number of well-defined methods for parametric estimation exist for software

170 A Guide to the Business Analysis Body of Knowledge®

Complimentary IIBA® Member Copy. Not for Redistribution or Resale.