Requirement Collection & Analysis

First Phase of the Database Design Process

 Six Main Phases of a Database
Design Process
Phase (1): Requirements collection and analysis.
Phase (2): Conceptual database design.
Phase (3): Choice of a DBMS.
Phase (4): Data model mapping (also called
logical database design)
Phase (5): Physical database design.
Phase (6): Database system implementation and
tuning.
 Six Main Phases of a Database
Design Process
PHASE PARALLEL ACTIVITIES

Requirements Data Requirements Processing

Collection & Analysis Requirements
Conceptual Design Conceptual & External Transaction Design
(DBMS independent) Schema Design
Choice of DBMS
Logical Design Mapping conceptual
design to a specific
DBMS
Physical Design Internal Schema Design
Implementation Build and populate Transaction
database Programming
 What is Requirement Collection &
Analysis?

Before we can effectively design a database, we

must know and analyze the expectation of the
users and the intended uses of the database

This is called requirements collection and

analysis.

Potential users of an application are interviewed

to determine problems and needs.

A requirements specification document is

produced.
 What is Requirement Collection &
Analysis?

Before we can effectively design a database,

we must know and analyze the expectation of
the users and the intended uses of the
database

This is called requirements collection and

analysis.
 Examples of activities:

Identification of user groups and application

areas

Analysis of the operating environment and

processing requirements

Interviews
 Requirements

To specify the requirements, we must 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.
Activities of Requirement Collection
& Analysis

Typically, the following activities are part of this

phase:
Major application areas and user groups that
will use the database or whose work will be
affected by it are identified. Key individuals and
committees within each group are chosen to carry
out subsequent steps of requirements collection
and specification
Activities of Requirement Collection
& Analysis (contd)
Existing documentation concerning the
applications is studied and analyzed Other
documentation-policy manuals, forms, reports, and
organization charts are reviewed to determine
whether they have any influence on the 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, etc... are studied. Input and output data
for the transactions are specified
Activities of Requirement Collection
& Analysis (contd)

Written responses of certain 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
 Customer/User Specification

Requirement analysis is carried out for the final

users, or "customers," of the database system
by a team of analysts or requirement experts

The initial requirements are likely to be

informal, incomplete, inconsistent, and partially
incorrect

So there needs to be some transformation done

so early requirements become a specification of
the application that developers and testers can
use as a 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.

It is important to use techniques that help

customers converge quickly on the
implementation requirements.

Customer participation in the development
process increases customer satisfaction with
the delivered system so many practitioners now
use meetings and workshops involving all
stakeholders

One such methodology of refining initial system

requirements is called Joint Application Design
(JAD)

Contextual Design, that 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
prototype of the application
 Structure Refinement

The preceding modes help structure and refine

requirements but leave them still in an informal
state.

To transform requirements into a better

structured form, requirements techniques are
used e.g. OOA (object-oriented analysis), DFDs
(data flow diagrams), and the refinement of
application goals.

These methods use diagramming techniques

for organizing and presenting information-
processing requirements
 Structure Refinement (contd)

Additional documentation in the form of text,

tables, charts, and decision requirements usually
accompanies the diagrams

The model-based formal specification methods,

of which the Z-notation and methodology is the
most prominent, can be thought of as extensions
of the ER model and are therefore the most
applicable to information system design.

Computer-aided techniques such as Upper
CASE tools - have been proposed to help
check the consistency and completeness of
specifications

Usually stored in a single repository for display

and update 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

This phase can be quite time-consuming, but it
is crucial to the success of the information
system

Correcting a requirements error is much more

expensive than correcting an error made during
implementation, because the effects of a
requirements error are usually pervasive, and
much more downstream work has to be re-
implemented as a result

Not correcting the error means that the system
will not satisfy the customer and may not even
be used at all.