SOFTWARE SCOPE

The first activity in software project planning is the determination of software scope.
Function and performance allocated to software during system engineering should be assessed to establish a project scope that is unambiguous and understandable
at the management and technical levels. A statement of software scope
must be bounded.
Software scope describes the data and control to be processed, function, performance,
constraints, interfaces, and reliability. Functions described in the statement of scope are evaluated and in some cases 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. Performance considerations
encompass processing and response time requirements. Constraints identify limits
placed on the software by external hardware, available memory, or other existing
systems.
Obtaining Information Necessary for Scope
Things are always somewhat hazy at the beginning of a software project. A need has
been defined and basic goals and objectives have been enunciated, but the information
necessary to define scope (a prerequisite for estimation) has not yet been delineated.
The most commonly used technique to bridge the communication gap between
the customer and developer and to get the communication process started is to
conduct a preliminary meeting or interview. The first meeting between the software
engineer (the analyst) and the customer can be likened to the awkwardness
of a first date between two adolescents. Neither person knows what to say or ask;
both are worried that what they do say will be misinterpreted; both are thinking
about where it might lead (both likely have radically different expectations here);
both want to get the thing over with; but at the same time, both want it to be a
success.
Yet, communication must be initiated. Gause and Weinberg suggest that
the analyst start by asking context-free questions; that is, a set of questions that will
lead to a basic understanding of the problem, the people who want a solution, the
nature of the solution desired, and the effectiveness of the first encounter itself.
The first set of context-free questions focuses on the customer, the overall goals
and benefits. For example, the analyst might ask:
• Who is behind the request for this work?
• Who will use the solution?
• What will be the economic benefit of a successful solution?
• Is there another source for the solution?
The next set of questions enables the analyst to gain a better understanding of the
problem and the customer to voice any perceptions about a solution:
• How would you (the customer) characterize "good" output that would be
generated by a successful solution?
• What problem(s) will this solution address?
• Can you show me (or describe) the environment in which the solution will be
used?
• Will any special performance issues or constraints affect the way the solution
is approached?

The final set of questions focuses on the effectiveness of the meeting. Gause and
Weinberg call these "meta-questions" and propose the following (abbreviated) list:
• Are you the right person to answer these questions? Are answers "official"?
• Are my questions relevant to the problem that you have?
• Am I asking too many questions?
• Can anyone else provide additional information?
• Should I be asking you anything else?
These questions (and others) will help to "break the ice" and initiate the communication
that is essential to establish the scope of the project. But a question and answer
meeting format is not an approach that has been overwhelmingly successful. In fact,
the Q&A session should be used for the first encounter only and then be replaced
by a meeting format that combines elements of problem solving, negotiation, and
specification.
Customers and software engineers often have an unconscious "us and them" mindset.
Rather than working as a team to identify and refine requirements, each constituency
defines its own "territory" and communicates through a series of memos,
formal position papers, documents, and question and answer sessions. History has
shown that this approach works poorly. Misunderstandings abound, important information
is omitted, and a successful working relationship is never established.
With these problems in mind, a number of independent investigators have developed
a team-oriented approach to requirements gathering that can be applied to
help establish the scope of a project. Called facilitated application specification techniques
(FAST), this approach encourages the creation of a joint team of customers
and developers who work together to identify the problem, propose elements
of the solution, negotiate different approaches, and specify a preliminary set of
requirements.
Feasibility
Once scope has been identified (with the concurrence of the customer), it is reasonable
to ask: “Can we build software to meet this scope? Is the project feasible?” All
too often, software engineers rush past these questions (or are pushed past them by
impatient managers or customers), only to become mired in a project that is doomed
from the onset.

Putnam and Myers correctly suggest that scoping is not enough. Once scope is understood,
the software team and others must work to determine if it can be done within
the dimensions just noted. This is a crucial, although often overlooked, part of the
estimation process.
A Scoping Example
Communication with the customer leads to a definition of the data and control that
are processed, the functions that must be implemented, the performance and constraints
that bound the system, and related information. As an example, consider
software for a conveyor line sorting system (CLSS).

The project planner examines the statement of scope and extracts all important software
functions. This process, called decomposition, was discussed in and
results in the following functions:
• Read bar code input.
• Read pulse tachometer.
• Decode part code data.
• Do database look-up.
• Determine bin location.
• Produce control signal for shunt.
• Maintain record of box destinations.