Page 506 - Using MIS

474 Chapter 12 Information Systems Development

Prototypes can be expensive to create; however, this expense is often justified not only for
the greater clarity and completeness of requirements, but also because parts of the prototype
can often be reused in the operational system. Much of the code created for the Xbox prototype
at PRIDE can be reused for the operational system, if that system is created.
Unfortunately, systems developers face a dilemma when funding prototypes; the cost of the
prototype occurs early in the process, sometimes well before full project funding is available. A
common complaint is “We need the prototype to get the funds, and we need the funds to get the
prototype.” Unfortunately, no uniform solution to this dilemma exists, except applying experi-
ence guided by intuition. Again we see the need for nonroutine problem-solving skills.

Approve Requirements
Once the requirements have been specified, the users must review and approve them before
the project continues. The easiest and cheapest time to alter the information system is in the
requirements phase. Changing a requirement at this stage is simply a matter of changing a de-
scription. Changing a requirement in the implementation phase may require weeks of rework-
ing applications components and the database structure.

Design System Components

Each of the five components is designed in this stage. Typically, the team designs each compo-
nent by developing alternatives, evaluating each of those alternatives against the requirements,
and then selecting from among those alternatives. Accurate requirements are critical here; if
they are incomplete or wrong, then they will be poor guides for evaluation.
Figure 12-12 shows that design tasks pertain to each of the five IS components. For hard-
ware, the team determines specifications for what the system will need. (The team is not design-
ing hardware in the sense of building a CPU or a disk drive.) Program design depends on the
source of the programs. For off-the-shelf software, the team must determine candidate products
and evaluate them against the requirements. For off-the-shelf with alteration programs, the
team identifies products to be acquired off-the-shelf and then determines the alterations re-
quired. For custom-developed programs, the team produces design documentation for writing
program code.
If the project includes constructing a database, then during this phase database design-
ers convert the data model to a database design using techniques such as those described in
Chapter 5. If the project involves off-the-shelf programs, then little database design needs to be
done; the programs will have been coded to work with a preexisting database design.
Procedure design differs, depending on whether the project is part of a BPM process or part
of a systems development process. If the former, then business processes will already be de-
signed, and all that is needed is to create procedures for using the application. If the latter, then

Requirements
Analysis Approved User
Requirements

Component Design
System
• Determine hardware Design
specications.
• Determine program Implementation
specications
(depends on source).
• Design the database.
• Design procedures.
Figure 12-12 • Create job denitions.
SDLC: Component Design Phase