Page 296 -

10.4 System development 279

2. System design This process overlaps significantly with the requirements devel-
opment process. It involves establishing the overall architecture of the system,
identifying the different system components and understanding the relationships
between them.
3. Subsystem engineering This stage involves developing the software components
of the system; configuring off-the-shelf hardware and software, designing, if
necessary, special-purpose hardware; defining the operational processes for the
system; and redesigning essential business processes.
4. System integration During this stage, the components are put together to create
a new system. Only then do the emergent system properties become apparent.
5. System testing This is usually an extensive, prolonged activity where problems
are discovered. The subsystem engineering and system integration phases are
reentered to repair these problems, tune the performance of the system, and
implement new requirements. System testing may involve both testing by the
system developer and acceptance/user testing by the organization that has pro-
cured the system.
6. System deployment This is the process of making the system available to its
users, transferring data from existing systems, and establishing communications
with other systems in the environment. The process culminates with a ‘go live’
after which users start to use the system to support their work.

Although the overall process is plan driven, the processes of requirements devel-
opment and system design are inextricably linked. The requirements and the high-
level design are developed concurrently. Constraints posed by existing systems may
limit design choices and these choices may be specified in the requirements. You
may have to do some initial design to structure and organize the requirements engi-
neering process. As the design process continues, you may discover problems with
existing requirements and new requirements may emerge. Consequently, you can
think of these linked processes as a spiral, as shown in Figure 10.8.
The spiral reflects the reality that requirements affect design decisions and vice
versa, and so it makes sense to interleave these processes. Starting in the center, each
round of the spiral may add detail to the requirements and the design. Some rounds
may focus on requirements, and some on design. Sometimes new knowledge col-
lected during the requirements and design process means that the problem statement
itself has to be changed.
For almost all systems, there are many possible designs that meet the require-
ments. These cover a range of solutions that combine hardware, software, and
human operations. The solution that you choose for further development may be the
most appropriate technical solution that meets the requirements. However, wider
organizational and political considerations may influence the choice of solution. For
example, a government client may prefer to use national rather than foreign suppli-
ers for its system, even if national products are technically inferior. These influences
usually take effect in the review and assessment phase of the spiral model where