THE PRODUCT

A software project manager is confronted with a dilemma at the very beginning of a
software engineering project. Quantitative estimates and an organized plan are
required, but solid information is unavailable. A detailed analysis of software requirements
would provide necessary information for estimates, but analysis often takes
weeks or months to complete. Worse, requirements may be fluid, changing regularly
as the project proceeds. Yet, a plan is needed "now!"
Therefore, we must examine the product and the problem it is intended to solve
at the very beginning of the project. At a minimum, the scope of the product must be
established and bounded.
Software Scope
The first software project management activity is the determination of software scope.
Scope is defined by answering the following questions:
Context. How does the software to be built fit into a larger system, product, or
business context and what constraints are imposed as a result of the context?
Information objectives. What customer-visible data objects (Chapter 11) are
produced as output from the software? What data objects are required for input?
Function and performance. What function does the software perform to
transform input data into output? Are any special performance characteristics
to be addressed?
Software project scope must be unambiguous and understandable at the management
and technical levels. A statement of software scope must be bounded. That
is, quantitative data (e.g., number of simultaneous users, size of mailing list, maximum
allowable response time) are stated explicitly; constraints and/or limitations
(e.g., product cost restricts memory size) are noted, and mitigating factors (e.g., desired
algorithms are well understood and available in C++) are described.
Problem Decomposition
Problem decomposition, sometimes called partitioning or problem elaboration, is an
activity that sits at the core of software requirements analysis . During
the scoping activity no attempt is made to fully decompose the problem. Rather,
decomposition is applied in two major areas: (1) the functionality that must be delivered
and (2) the process that will be used to deliver it.
Human beings tend to apply a divide and conquer strategy when they are confronted
with a complex problems. Stated simply, a complex problem is partitioned
into smaller problems that are more manageable. This is the strategy that applies as
project planning begins. Software functions, described in the statement of scope, are
evaluated and refined to provide more detail prior to the beginning of estimation Because both cost and schedule estimates are functionally oriented, some
degree of decomposition is often useful.
As an example, consider a project that will build a new word-processing product.
Among the unique features of the product are continuous voice as well as keyboard
input, extremely sophisticated “automatic copy edit” features, page layout capability,
automatic indexing and table of contents, and others. The project manager must first
establish a statement of scope that bounds these features (as well as other more mundane
functions such as editing, file management, document production, and the like).
For example, will continuous voice input require that the product be “trained” by the
user? Specifically, what capabilities will the copy edit feature provide? Just how sophisticated
will the page layout capability be?
As the statement of scope evolves, a first level of partitioning naturally occurs. The
project team learns that the marketing department has talked with potential customers
and found that the following functions should be part of automatic copy editing:
(1) spell checking, (2) sentence grammar checking, (3) reference checking for
large documents (e.g., Is a reference to a bibliography entry found in the list of entries
in the bibliography?), and (4) section and chapter reference validation for large documents.
Each of these features represents a subfunction to be implemented in software.
Each can be further refined if the decomposition will make planning easier.