Phase 1: Requirements Collection and Analysis
Before we can effectively design a database, we must know and analyze
the expectations of the users and the intended uses of the database in as much
detail as possible. This process is called requirements collection and analysis. To specify the requirements,
we first identify the other parts of the information system that will interact
with the database system. These include new and existing users and
applications, whose requirements are then collected and analyzed. Typically,
the following activities are part of this phase:
The major application areas and
user groups that will use the database or whose work will be affected by it are
identified. Key individuals and commit-tees within each group are chosen to
carry out subsequent steps of requirements collection and specification.
Existing documentation concerning
the applications is studied and analyzed. Other documentation—policy manuals,
forms, reports, and organization charts—is reviewed to determine whether it
has any influence on the requirements collection and specification process.
The current operating environment
and planned use of the information is studied. This includes analysis of the
types of transactions and their frequencies as well as of the flow of
information within the system. Geographic characteristics regarding users,
origin of transactions, destination of reports, and so on are studied. The
input and output data for the transactions are specified.
Written responses to sets of
questions are sometimes collected from the potential database users or user
groups. These questions involve the users’ priorities and the importance they
place on various applications. Key individuals may be interviewed to help in
assessing the worth of information and in setting up priorities.
Requirement analysis is carried out for the final users, or customers, of the database system by a
team of system analysts or requirement experts. The initial requirements are
likely to be informal, incomplete, inconsistent, and partially incorrect.
Therefore, much work needs to be done to transform these early requirements
into a specification of the application that can be used by developers and
testers as the starting point for writing the implementation and test cases.
Because the requirements reflect the initial understanding of a system that
does not yet exist, they will inevitably change. Therefore, it is important to
use techniques that help customers converge quickly on the implementation
There is evidence that customer participation in the development process
increases customer satisfaction with the delivered system. For this reason,
many practitioners use meetings and workshops involving all stakeholders. One
such methodology of refining initial system requirements is called Joint
Application Design (JAD). More recently, techniques have been developed, such
as Contextual Design, which involve the designers becoming immersed in the
workplace in which the application is to be used. To help customer
representatives better understand the proposed system, it is common to walk
through workflow or transaction scenarios or to create a mock-up rapid
prototype of the application.
The preceding modes help structure and refine requirements but leave
them still in an informal state. To transform requirements into a
better-structured representa-tion, requirements
specification techniques are used. These include object oriented analysis
(OOA), data flow diagrams (DFDs), and the refinement of appli-cation goals.
These methods use diagramming techniques for organizing and presenting
information-processing requirements. Additional documentation in the form of
text, tables, charts, and decision requirements usually accompanies the
dia-grams. There are techniques that produce a formal specification that can be
checked mathematically for consistency and what-if
symbolic analyses. These methods may become standard in the future for those
parts of information systems that serve mission-critical functions and which
therefore must work as planned. The model-based formal specification methods,
of which the Z-notation and
methodology is a prominent example, can be thought of as extensions of the ER
model and are there-fore the most applicable to information system design.
Some computer-aided techniques—called Upper CASE tools—have been proposed to help check the consistency
and completeness of specifications, which are usually stored in a single
repository and can be displayed and updated as the design progresses. Other
tools are used to trace the links between requirements and other design
entities, such as code modules and test cases. Such traceability databases are especially important in conjunction with
enforced change-management procedures for systems where the requirements change
frequently. They are also used in contractual projects where the development
organization must provide documentary evidence to the customer that all the
requirements have been implemented.
The requirements collection and analysis phase can be quite
time-consuming, but it is crucial to the success of the information system.
Correcting a requirements error is more expensive than correcting an error made
during implementation because the effects of a requirements error are usually
pervasive, and much more down-stream work has to be reimplemented as a result.
Not correcting a significant error means that the system will not satisfy the
customer and may not even be used at all. Requirements gathering and analysis
is the subject of entire books.