386 Part III • Acquiring Information Systems
Definition Phase
What outputs should the system produce?
What processes are necessary to produce the needed outputs?
What should the system be able to do?
What input data are needed?
How can data best be obtained?
How can data accuracy, completeness, and timeliness be assured?Construction Phase
What data must be stored in the system?
How should data be organized?
How can data be maintained?
How can this system be decomposed into modules?
How do these modules relate to each other?
In what sequence should the modules be executed?
How can the system be recovered if anything happens?
Is an audit trail necessary?
What level of documentation is necessary?
What system tests need to be run?FIGURE 9.16 Questions to Guide User Developersbe provided and kept up-to-date; documentation that is not
embedded in the application itself is needed in the event of
a system crash. The documentation for a multiuser system,
or a stand-alone application used by different people in dif-
ferent workgroups, typically requires relatively detailed
user documentation, such as that produced for users by IS
documentation specialists. Depending on the organiza-
tional context, a formal internal audit or other oversight
mechanism may be needed before the application is uti-
lized to ensure that it does not expose the organization to
unacceptable levels of risk or to comply with financial
reporting laws.
IT professionals have also learned that a simple sys-
tem that works reliably is much more useful than an elabo-
rate failure. It often is a good idea to start with a limited
version of a user-developed system and then to expand it
after having some experience with the initial version.
Indeed, user-developed systems sometimes also lead to
more complex systems projects that require custom devel-
opment work by IS professionals.Summary
The choice among the traditional systems development
life cycle (SDLC), prototyping, RAD, and the newer
“agile” methodologies for developing a customized appli-
cation is essentially an IS management decision. Within
firms that have their own capable IS staffs, the methodol-
ogy choice might be based on factors such as the degree to
which system requirements can be easily determined and
the application’s functionality, size, and complexity.
Custom application development using the multistep
SDLC methodology, with well-defined sign-offs, is now
the traditional way to develop new computer systems and
to maintain them; it is still the preferred approach when
the system is large, complex, and serves multiple organi-
zational units. A prototyping methodology is a more
effective approach for small, simple projects. A prototyp-
ing approach is also used within an SDLC methodology to
help users and IS professionals begin with a set of basic
requirements and then develop a fuller set of functional
requirements. A combination prototyping/piloting
approach within an SDLC methodology is especially
useful when the systems project is characterized by sig-
nificant technological risks or organizational risks, or
both, that can be tested out early in the project using a
prototype.
Whether the traditional SDLC, prototyping, or
some combination of the two is used, it is the responsibil-
ity of both business managers and IS specialists to ensure
that the system that is installed meets the needs of the