ĐẠI HỌC FPT CẦN THƠ

CHAPTER 13

Specifying data requirements

 Objectives

Student should enhance the ways to explore

and represent the data.
Student understand the ways to specify any
reports or dashboards of application needs to
generate.

Chapter 13: Specifying data requirements _ BayHV 2

 Contents

1.Modeling data relationships

2.The data dictionary
3.Data analysis
4.Specifying reports
5.Dashboard reporting

Chapter 13: Specifying data requirements _ BayHV 3

 Modeling data relationships
A commonly used data model is the entity-relationship diagram
or ERD. If your ERD represents logical groups of information from
the problem domain and their interconnections, you’re using the
ERD as a requirements analysis tool.
When you create an ERD during design, you’re defining the logical
or physical (implementation) structure of the system’s database.
That implementation view extends or completes the
understanding of the system begun during analysis and optimizes
its realization in, say, a relational database environment.
Entities could represent (đại diện) physical items (including people)
or aggregations of data that are important to the business you’re
analyzing or to the system you intend to build. Entities are named
as singular nouns and are shown in rectangles in an ERD.
Chapter 13: Specifying data requirements _ BayHV 4
 Modeling data relationships
The entities named
Chemical Request,
Vendor Catalog, and
Chemical Stockroom
Inventory appeared as
data stores in the data
flow diagram
Other entities
represent actors who
interact with the
system (Requester),
physical items that are
part of the business
operations (Chemical
Container).
During physical
database design of a
relational database,
entities normally
become tables.
Chapter 13: Specifying data requirements _ BayHV 5
 Modeling data relationships
Each entity is described by one or more attributes; individual
instances of an entity will have different attribute values.
The diamonds in the ERD represent relationships, which identify the
logical linkages between pairs of entities. Relationships are named
in a way that describes the nature of the connection.
For example, the relationship between the Chemical Request and the
Requester is a placing relationship.
The cardinality, or multiplicity, of each relationship is shown with a
number or letter on the lines that connect entities and relationships.
Ex: Requester can place multiple requests, there’s a one-to-many
relationship between Requester and Chemical Request.

Chapter 13: Specifying data requirements _ BayHV 6

 The data dictionary

A data dictionary is a collection of detailed information about the data

entities used in an application.
Collecting the information about composition, data types, allowed values,
and the like into a shared resource identifies the data validation criteria,
helps developers write programs correctly, and minimizes integration
problems.
The data dictionary feeds into (góp phần) design in the form of database
schemas, tables, and attributes, which ultimately lead to variable names in
programs.
The time you invest in creating a data dictionary will be more than repaid
by avoiding the mistakes that can result when project participants have
different understandings of the data.
Maintaining a data dictionary is a serious investment in quality. Data
definitions often are reusable across applications, particularly within a
product line.
Chapter 13: Specifying data requirements _ BayHV 7
 The data dictionary
Figure 13-4 illustrates a portion of the data dictionary for the Chemical Tracking
System. Organize the entries in the data dictionary alphabetically to make it easy
for readers to find what they need.

Chapter 13: Specifying data requirements _ BayHV 8

 Data analysis
A CRUD matrix is a rigorous data analysis technique for detecting missing
requirements.
CRUD stands for Create, Read, Update, and Delete. A CRUD matrix correlates
(tương quan) system actions with data entities to show where and how each
significant data entity is created, read, updated, and deleted.
EX:

Chapter 13: Specifying data requirements _ BayHV 9

 Specifying reports

Many applications generate reports from one or more

databases, files, or other information sources.
Reports can consist of traditional tabular presentations
of rows and columns of data, charts and graphs of all
types, or any combination.
Exploring the content and format of the reports needed
is an important aspect of requirements development.
Report specification straddles (lưỡng lự) requirements (what
information goes into the report and how it is organized)
and design (what the report should look like).

Chapter 13: Specifying data requirements _ BayHV 10

 Specifying reports

Eliciting reporting requirements: If you’re a BA working with

customers on defining reporting requirements for an information
system, consider asking questions like the following:
What reports do you currently use? (Some reports from an existing
system, or manually generated reports from the business, will need to
be replicated in the new system.)
Which existing reports need to be modified? (A new or revised
information system project provides an opportunity to update reports
that don’t fully meet current needs.)
Which reports are currently generated but are not used? (Perhaps you
don’t need to build those into the new system.)
Can you describe any departmental, organizational, or government
standards to which reports must conform, such as to provide a
consistent look and feel or to comply with a regulation? (Obtain copies
of those standards and examples of current reports that meet them.)
Chapter 13: Specifying data requirements _ BayHV 11
 Specifying reports

Following are some questions to explore for each customer-requested

report:
What is the name of the report?
What is the purpose or business intent of the report?
Is the report generated manually? If so, how frequently and by which user
classes?
Is the report generated automatically? If so, how frequently and what are the
triggering conditions or events?
What are the typical and maximum sizes of the report?
What is the disposition (bố trí) of the report after it is generated? Is it displayed on
the screen, sent to a recipient, exported to a spreadsheet, or printed
automatically? Is it stored or archived somewhere for future retrieval?
Are there security, privacy, or management restrictions that limit the access of
the report to specific individuals or user classes, or which restrict the data that
can be included in the report depending on who is generating it? Identify any
relevant business rules concerning security.
Chapter 13: Specifying data requirements _ BayHV 12
 Specifying reports

The following questions will elicit information about the

report itself:
What are the sources of the data and the selection criteria for
pulling data from the repository?
What parameters are selectable by the user?
What calculations or other data transformations are required?
What are the criteria for sorting, page breaks, and totals?
How should the system respond if no data is returned in
response to a query when attempting to generate this report?
Can this report be used as a template for a set of similar
reports?

Chapter 13: Specifying data requirements _ BayHV 13

 Specifying reports

Report specification considerations

Consider other variations
Find the data
Anticipate growth
Look for similarities
Distinguish static and dynamic reports
Prototype reports
A report specification template: page 255

Chapter 13: Specifying data requirements _ BayHV 14

 Dashboard reporting
A dashboard is a screen display or printed report that uses multiple textual and/or graphical
representations of data to provide a consolidated, multidimensional view of what is going
on in an organization or a process.
Purpose
pull together information about sales, expenses, key performance indicators (KPIs), and the
like.
Stock trading (giao dịch chứng khoán) applications display a bewildering (bối rối) (to the novice) array
of charts and data that the skilled eye (con mắt nhà nghề) can scan and process at a glance (nháy mắt).
How to build:
Determine what information the dashboard users need for making specific decisions or
choices.
Identify the sources of all the data to be presented so you can ensure that the application
has access to those feeds (nguồn cấp dữ liệu) and you know whether they are static or dynamic.
Choose the most appropriate type of display for each set of related data. Should it appear
as a simple table of data, a modifiable spreadsheet containing formulas, blocks of text, bar
chart, pie chart, line chart, video display, or one of many other ways to present
information?
Determine the optimal layout and relative sizing of the various displays in the dashboard,
based on how the user will absorb and apply the information.
Chapter 13: Specifying data requirements _ BayHV 15
 Dashboard reporting

Hypothetical reporting dashboard for a charitable foundation.

Chapter 13: Specifying data requirements _ BayHV 16
 Review chapter 13

Chapter 13

Modeling data Dashboard

Dada dictionary Data analysis Specifying report
relationship reporting

ERD-Entities
relationship CRUD matrix
diagram

Chapter 2: Requirements from customer's perspective _ BayHV 17

Chapter 4: The business analyst - BayHV 18