Page 505 - Using MIS

Q4 What Are the Phases in the Systems Development Life Cycle (SDLC)? 473

System
Denition
Project
Plan
Requirements Analysis
Approved User
•Conduct user interviews. Requirements
•Evaluate existing systems.
•Determine new Component
forms/reports/queries. Design
• Identify new application
features and functions.
Figure 12-11 •Consider security.
SDLC: Requirements Analysis •Create the data model.
•Consider all ve components.
Phase

Seasoned and experienced systems analysts know how to conduct interviews to bring such re-
quirements to light.
As listed in Figure 12-11, sources of requirements include existing systems as well as the
Web pages, forms, reports, queries, and application features and functions desired in the new
system. Security is another important category of requirements.
If the new system involves a new database or substantial changes to an existing database,
then the development team will create a data model. As you learned in Chapter 5, that model
must reflect the users’ perspective on their business and business activities. Thus, the data
model is constructed on the basis of user interviews and must be validated by those users.
Sometimes, the requirements determination is so focused on the software and data compo-
nents that other components are forgotten. Experienced project managers ensure consideration
of requirements for all five IS components, not just for software and data. Regarding hardware,
the team might ask: Are there special needs or restrictions on hardware? Is there an organi-
zational standard governing what kinds of hardware may or may not be used? Must the new
system use existing hardware? What requirements are there for communications and network
hardware?
Similarly, the team should consider requirements for procedures and personnel: Do ac-
counting controls require procedures that separate duties and authorities? Are there restrictions
that some actions can be taken only by certain departments or specific personnel? Are there
policy requirements or union rules that restrict activities to certain categories of employees?
Will the system need to interface with information systems from other companies and organiza-
tions? In short, requirements for all of the components of the new information system need to
be considered.
These questions are examples of the kinds of questions that must be asked and answered
during requirements analysis.

Role of a Prototype

Because requirements are difficult to specify, building a working prototype, as is being done for
the PRIDE Xbox prototype, can be quite beneficial. Whereas future systems users often struggle
to understand and relate to requirements expressed as word descriptions and sketches, working
with a prototype provides direct experience. As they work with a prototype, users will assess us-
ability and remember features and functions they have forgotten to mention. Additionally, pro-
totypes provide evidence to assess the system’s technical and organizational feasibility. Further,
prototypes create data that can be used to estimate both development and operational costs.
To be useful, a prototype needs to work; mock-ups of forms and reports, while helpful, will
not generate the benefits just described. The prototype needs to put the user into the experience
of employing the system to do his or her tasks.