Application Development - The CIO's Guide to Oracle Products and Solutions - page 214

PRINCIPLES OF SOFTWARE ENGINEERING
Computer systems come in all shapes and sizes. There are systems that
process e-mail and systems that process payroll. There are also systems
that monitor space missions and systems that monitor student grades. No
matter how diverse the functionality of these systems, they have several
things in common:
1. All systems have end users . It is for these end users that the system has
been created. These end users have a vested interested in seeing that
this system is doing what it is supposed to be doing correctly and effi-
ciently. You might say that these end users have a stake in seeing that
the system is successful. Sometimes these end users are referred to as
stakeholders . There are different types of stakeholders. A good systems
analyst is careful to avoid leaving stakeholders out erroneously. But
this is indeed what happened when the post office started developing
the automated system that you now see in use today at all post offices.
This system was developed in a vacuum. What this means is that only
higher level employees were involved in system development. The clerks
that actually work at the windows were left out of the process. When
it came time for this system to be deployed, the lack of involvement of
this critical set of stakeholders almost led to an employee mutiny.
2. All systems are composed of functions and data . All of us like to get
our payroll checks. To create a payroll check requires us to define
several functions (sometimes called processes ). For example, there
might be functions for (a) obtaining employee information, (b) cal-
culating payroll taxes, (c) calculating other deductions, and (d) print-
ing the check. Systems analysts are not payroll clerks, nor are they
accountants. A typical systems analyst does not have the informa-
tion to create a payroll processing system without the involvement of
stakeholders. Instead, the analyst needs to utilize several analytical
techniques, including interviewing and observation, to get the details
on how to perform these processes. Functions are only one-half of
the equation, however. The other half is the data. Sometimes the data
will already be available to the systems analyst, e.g., via a corporate
database or file. Sometimes, however, the systems analyst will have
to create a new database for the application. For this particular task,
the analyst will usually work with a database administrator or data