Chapter 9 • Methodologies for Custom Software Development 365managers responsible for the use of the new system are
involved in defining its detailed requirements.
Also referred to as systems analysis or logical design,
the requirements definition focuses on processes, data flows,
and data interrelationships rather than a specific physical
implementation (i.e., what, not how). The systems analyst(s)
is responsible for making sure these requirements are elicited
in sufficient detail to pass on to those who will build the sys-
tem. It might appear easy to define what a system is to do at
the level of detail with which system users often describe
systems. However, it is quite difficult to define what the new
system is to do in the detail necessary to write the computer
code for it. Many business applications are incredibly com-
plex, supporting different functions for many people or
processes that cross multiple business units or geographic
locations. Although each detail might be known by someone,
no one person knows what a new system should do in the
detail necessary to describe it. This step can therefore be very
time consuming and requires analysts who are skilled in ask-
ing the right questions of the right people and in conceptual
system design techniques. In addition, there might be signifi-
cant disagreements among the business managers about the
nature of the application requirements. It is then the responsi-
bility of the IS project manager and analysts to help the rele-
vant user community reach a consensus. Sometimes outside
consultants are used to facilitate this process.
A variety of methods are used to elicit requirements,
and several are often used on the same project. Interviews of
key personnel (from the sponsor to a representative set of
users) are often done. These may be individual interviews or
group interviews, sometimes called Joint Application Design
(JAD) sessions (described later in this chapter). Review of
documents related to the application area (e.g., business
plans, communications complaining about the current sys-
tem, job descriptions, even descriptions of commercial appli-
cations or academic research about similar systems) is also
common. Sometimes it makes sense for the systems analyst
to observe people doing the job that will be supported by the
new or changed system, so that bottlenecks, errors, and con-
fusions can be seen firsthand. It is best to triangulate on re-
quirements by using a variety of these methods.
Furthermore, some new applications are intended to
provide decision support for tasks that are ill structured. In
these situations, managers often find it difficult to define
precisely what information they need and how they will use
the application to support their decision making.
Information needs might also be highly variable and
dynamic over time. As noted in Chapter 8, many of today’s
large systems development projects might also arise in con-
junction with reengineering an organization’s business
processes. Redesign of the organization, its work processes,
and the development of a new computer system could go on
in parallel. The ideal is to first redesign the process, but
even then work processes are seldom defined at the level of
detail required for a new business application.
Because defining the requirements for a system is
such a difficult and a crucial task, analysts rely on a num-
ber of techniques and approaches to document and com-
municate the requirements. Examples of some of the tech-
niques were described in detail in Chapter 8. Later in this
chapter we also describe an evolutionary prototyping ap-
proach that can be used to help define systems require-
ments—for the user interface in particular.
The deliverable for the Requirements Definition step
is a comprehensive system requirements documentthat
contains detailed descriptions of the system inputs and out-
puts and the processes used to convert the input data into
these outputs. It typically includes several hundred pages
with formal diagrams and output layouts, such as shown in
Chapter 8. This document also includes a revised cost-ben-
efit analysis of the defined system and a revised plan for
the remainder of the development project.
The system requirements document is the major deliv-
erable of the Definition phase of the SDLC. Although IS an-
alysts are typically responsible for drafting and revising the
requirements specifications document, business managers
are responsible for making sure that the written require-
ments are correct and complete. Thus, all relevant partici-
pants need to carefully read and critique this document for
inaccuracies and omissions. Case studies have shown that
when key user representatives do not give enough attention
to this step, systems deficiencies are likely to be the result.
The deliverable from this step is typically subject to
approval by business managers for whom the system is
being built as well as by appropriate IS managers. Once
formal approvals have been received, the system require-
ments are considered to be fixed. Any changes typically
must go through a formal approval process, requiring sim-
ilar sign-offs and new systems project estimates. All key
participants therefore usually spend considerable time re-
viewing these documents for accuracy and completeness.Construction Phase
SYSTEM DESIGN In this step, IS specialists design the
physical, or technical, system, based on the functional re-
quirements document from the Definition phase. In system
design, one decides what hardware and systems software
to use to operate the system, designs the structure and con-
tent of the system’s database(s), and defines the processing
modules (programs) that will comprise the system and
their interrelationships. A good design is critical because
the technical quality of the system cannot be added later; it
must be designed into the system from the beginning.