Tài liệu Module 3: Using a Conceptual Design doc

Module 3: Using a Conceptual Design
for Data Requirements






Module 1: Course
Overview
Module 4: Deriving a
Logical Data Design
Module 5: Normalizing the
Logical Data Design
Module 6: Deriving a
Physical Data Design
Module 7:
Implementing Data
Integrity
Module 2: Solution
Design Processes
Module 3: Using a
Conceptual Design for Data
Requirements
Module 8: Designing
Data Services
Module 9: Data Storage
Considerations
Designing Data
Services and

Data Models
Investigation
Process
Data
Requirements
Activity 3.1: Identifying
Data-Related Use Cases
and Data Requirements
Module 3: Using a
Conceptual Design for Data
Requirements
Activity 3.2: Relating Data
Requirements to
Conceptual Design

Module 3: Using a Conceptual Design for Data Requirements 47



!
!!
! Overview
" Investigation Process
" Data Requirements
" Activity 3.2: Relating Data Requirements to Conceptual
Design
" Review
In this module
In this module

At the end of this module, you will be able to:
"
Describe the information investigation process.
"
Determine functional data requirements from use cases.
"
Identify nonfunctional requirements that will affect a solution’s design.

Slide Objective
To provide an overview of
this module’s topics and
objectives.

48 Module 3: Using a Conceptual Design for Data Requirements



!
!!
! Investigation Process
" Gathering Information
" Analyzing Information
" Creating Use Cases
In this section
In this section


In this section, the discussion will focus on the reasons for gathering and
analyzing data, as well as the formulation of this data into use cases. Use cases

will be the foundation for determining data requirements for the system.
Slide Objective
To introduce use cases and
nonfunctional requirements
that are used in the
solution’s conceptual
design.

Delivery Tip
This section provides an
overview of what students
would normally do to get
information about data and
nonfunctional requirements.
They will not actually do this
in the course. If students
want more information about
this process, refer them to
Course 1585: Gathering and
Analyzing Business
Requirements.
Module 3: Using a Conceptual Design for Data Requirements 49



Gathering Information
"
Identify necessary information
"
Identify sources for required information

"
Use perspectives when looking at source information
"
Gather information
$
Conduct interviews
$
Shadow
$
Collect artifacts


To identify data requirements, the project team starts a process of investigation.
This process involves gathering and analyzing data from users, systems, and
documentation to determine the current state and desired future state of the
solution.
Gathering data involves:
"
Determining what information is needed to identify the data, functional
requirements, and nonfunctional requirements.
"
Identifying sources from which to obtain relevant and supporting
information. Sources can include people, systems, and systems-support
documents.
"
Looking at source information from different perspectives to ensure that all
the relevant information is gathered from a particular source.
"
Gathering the information needed to determine requirements from the
identified sources. Information can be gathered in several ways:

• Conduct interviews with users, managers, and other customers.
• Shadow users, managers, and other customers to gain first-hand
knowledge of the skills and experience necessary to perform a task.
• Collect artifacts, such as printed documentation and manuals.

Slide Objective
To provide an
understanding of the
gathering phase as a part of
the investigation process.
Lead-in
You will take a look at the
gathering of information as it
relates to the investigation
process.
50 Module 3: Using a Conceptual Design for Data Requirements



Analyzing Information
"
Organization
$
Provide structure to the original information and remove
redundancies
"
Identification of relationships
$
Determine which groups of information are related
"

Prioritization
$
Determine which requirements are important
"
Validation
$
Determine whether information is accurate and
representative of the real world



When analyzing the gathered information, the team needs to organize, identify,
prioritize, and validate the information. Rarely is all the necessary information
obtained the first time, so this is an iterative process.
Organization
When organizing information, the team tries to understand what has been
gathered, removes redundancies, and determines whether the resulting
information is relevant to the overall design of the solution.
Identification of relationships
The team must identify the relationships between objects. For example,
“manager approves timesheet” is a relationship.
Prioritization
After all relationships have been identified, the team must prioritize the
requirements from most important to superfluous.
Validation
Information provided is not always accurate, so it is important for the team to
validate the information gathered. One method of validating information is to
gather the same information from different people, systems, or documents and
verify that the information is largely the same.
Slide Objective

To show the actions
involved in the analysis
process.
Lead-in
After information has been
gathered, you need to
analyze it. Analysis includes
the following steps.
Delivery Tip
The organization of
information will lead to data
requirements (functional and
nonfunctional requirements
and use cases). This is a
good time to discuss these
topics before they are
formally defined. Otherwise,
you might want to defer any
questions that the students
might have until the next
slide.
Module 3: Using a Conceptual Design for Data Requirements 51



Creating Use Cases
"
Show actions:
$
Between users

$
Between users and independent portions of a system
"
Describe the current state and desired future state
"
Components
$
Actor
$
Object
$
Relationship


Use cases provide one of the best ways to understand how users and data
interact. Each use case is typically a short sentence that describes the actions
that a user performs on or with other users or other portions of a system.
Examples might include “Students check out library books,” or “Management
creates ad-hoc reports.”
Initially, use cases can describe the known situation, also referred to as the
current state. Use cases can also describe the intended solution or the desired
future state. Describing this future state is an important aspect of use cases
because it helps document how the system should act, given the appropriate
design and implementation.
Use cases consist of three components:
"
Actor
The person or thing that will act upon something else to produce an output.
The actor is usually located on the left side of the use case description.
"

Object
The recipient of the actor’s actions. The object may or may not behave in a
prescribed manner because of the actions performed upon it.
"
Relationship
The description of the action performed by an actor and received by an
object.

Slide Objective
To explain what use cases
are and what they consist
of.
Lead-in
Use cases help determine
what types of data need to
be tracked and how the data
is used.
52 Module 3: Using a Conceptual Design for Data Requirements



!
!!
! Data Requirements
"
Characteristics of Data Requirements
"
Categories of Data Requirements
"
Identifying Functional Data Requirements

"
Identifying Nonfunctional Data Requirements
"
Activity 3.1: Identifying Data-Related Use Cases and
Data Requirements
"
Validating Data Requirements
In this section
In this section


Knowing how to establish data requirements during conceptual design helps
define the final product.
Slide Objective
To introduce the role of data
requirements in conceptual
design.
Lead-in
In this section, you will learn
how to establish data
requirements.
Module 3: Using a Conceptual Design for Data Requirements 53



Characteristics of Data Requirements
"
Required for design
"
Explicit

"
Hidden


Data requirements at the conceptual level will have some identifying
characteristics that will help solidify the conceptual design and lead to a better
set of future-state use cases. Although this is not an exhaustive list, consider the
following characteristics when determining requirements:
"
Required for design
The logical and physical implementation of a database necessitates that the
data requirements be defined. What types of data (at a high level) are going
to be stored?
"
Explicit
The data requirements should be clear and should ensure that the data is
unambiguous. The use cases must present a clear idea about what types of
data each user or system will work with.
"
Hidden
Sometimes the most difficult data to define is that which cannot be seen.
Hidden artifacts and unforeseen circumstances will always be present during
data design.
"
For example, Ferguson and Bardell, Inc. might be planning to conduct
business overseas. An explicit data requirement would be that their
scheduling and invoicing system must support tracking of billing and
invoices. A hidden data requirement would be that their system must
instantaneously convert currencies when billing clients in other countries.
Thus, the solution would require currency exchange rates. This requirement

is not stated, but it is implied because of Ferguson and Bardell Inc.’s
intended expansion into foreign markets.
Slide Objective
To introduce the
characteristics of data
requirements.
Lead-in
Some characteristics of data
requirements are as follows.
54 Module 3: Using a Conceptual Design for Data Requirements



Categories of Data Requirements
"
Functional data requirements
$
Identified from use cases
$
Traceable to a current or future-state business process
"
Nonfunctional data requirements
$
Define a specification that functional data requirements
should consider
$
Help to more completely describe the functional
requirement and its underlying information
$
Can be categorized

Typically, a system must meet data requirements that fall into one of two
categories. These categories complement each other and help the design team
see the complete picture when considering the conceptual design for a system.
Functional data requirements
When iterating through the conceptual design for a solution, it is important to
understand how data is used in the current system and how the solution’s future
state will interact with data. This understanding will help you produce a set of
functional data requirements.
A functional data requirement is any tangible requirement that must be tracked
within a data system in for a data-centric use case to function properly. It is the
information and knowledge that an actor must know to perform a function or
task. Each functional data requirement is directly traceable to an actor and an
object within a use case.
Nonfunctional data requirements
A nonfunctional data requirement more completely describes a functional data
requirement. It is important to consider nonfunctional data requirements in the
conceptual design of a solution because they may alter the design ideas and
framework.
Considering the following categories and asking some common questions will
help you identify nonfunctional requirements:
"
Scalability
What is the range of the data values? How many total users and concurrent
users need access to the system? How much data needs to be tracked? How
many transactions will be processed in a given timeframe?
Slide Objective
To introduce the two types
of data requirements

covered in this module.
Lead-in
There are two categories of
data requirements:
functional and
nonfunctional.
Module 3: Using a Conceptual Design for Data Requirements 55



"
Availability
What intended level of use and readiness will the system have to support?
How long can a system be offline before a hardship is incurred? At what
hours and on what days does the system need to be available? What are the
peak use times? Are there time periods during which the system can be
offline?
"
Maintainability
How easy must the system be to update, maintain, and repair? Are data
systems currently in place, and how are they supported? How often are the
system or data structures modified? How often should the systems be
backed up?
"
Extensibility
How easy must it be to add on to the system at a later date? Are you
designing with current capacity or future capacity in mind?
"
Interoperability
Are you designing a system that works in a vacuum (vertically), or a system

that will be open-ended and able to work with other systems? Where does
the data come from? How many different systems store the data? What
current systems supply the application with data? What other systems do
you have to supply with information? What import and export capabilities
do you need?

56 Module 3: Using a Conceptual Design for Data Requirements



Identifying Functional Data Requirements
"
Inspect each use case
"
Find factors that influence the actions of each use case
"
Decide what actions will be performed on the source
information
"
Decide what characteristics the actions will have


Establishing data requirements for a business solution is a necessary first step in
determining the solution’s overall data design. If a solution has no data
requirements, it has no need for data storage, let alone a logical data
organization.
Determining the functional data requirements from the solution’s use cases
involves the following tasks:
"
Inspect each use case.

Make sure that each use case is inspected because the entire system will
revolve around the interactions of all the use cases, not just an isolated set.
Determine any actions that must be performed on information in a specific
order.
"
Find factors that influence the actions of each use case.
What happens behind the scenes to make this possible? What does the
system have to do to make the use case possible? What does the actor have
to know before the action can be performed?
"
Decide what actions will be performed on the source information.
How will the data be used? For example: What happens to the hours billed
by a consultant?
"
Decide what characteristics the actions will have.
What steps are needed to perform each action? What actions need to be
performed in groups? For example, will you use transaction processing of
information?

Slide Objective
To introduce the steps in
identifying functional data
requirements.
Lead-in
Finding the functional data
requirements in a use case
involves four tasks.
Module 3: Using a Conceptual Design for Data Requirements 57

Identifying Nonfunctional Data Requirements
"
Iterative process
$
Consider each information source
$
Look for factors that influence the use cases
$
Look for actions that are independent of the use cases
$
Identify as a nonfunctional data requirement


Not taking into account the nonfunctional requirements of a system can
adversely affect the success of a solution. For example, the consultants in the
Ferguson and Bardell, Inc. case study will need to submit billing information to
the company database. The scalability and availability of the solution is a
nonfunctional requirement that will need to be considered.
The identification of nonfunctional requirements is, like most other design
processes, iterative in nature. You should reconsider the data requirements often
during the conceptual design stage so that the correct set of nonfunctional
requirements will be produced.
The following steps will help the design team identify nonfunctional data
requirements:
"
Consider each information source.
Because it is possible to overlook data requirements by neglecting sources
of information, the design team should search all sources of information to
find all possible requirements, including nonfunctional data requirements.

"
Look for factors that influence the use cases.
As with functional data requirements, the design team should ask the
following questions: What happens behind the scenes to make this possible?
What does the system have to do to make the use case possible?
"
Look for actions that are independent of the use cases.
Consider the actions of the system that are affected by nonfunctional data
requirements. For example, does the creation of invoices in the Ferguson
and Bardell, Inc. system require any security to ensure that unauthorized
users do not tamper with the invoices?
"
Identify the requirement as a nonfunctional data requirement and include it
in the use cases for the system.
Slide Objective
To introduce the steps in
identifying nonfunctional
data requirements.
Lead-in
Identifying nonfunctional
data requirements is an
important step in completing
the solution’s conceptual
design.
58 Module 3: Using a Conceptual Design for Data Requirements



Activity 3.1: Identifying Data-Related Use Cases and Data
Requirements

In this activity, you will analyze a set of use cases derived from the Ferguson
and Bardell, Inc. case study and determine data requirements, hidden data
requirements, and nonfunctional data requirements from those use cases.
After completing this activity, you will be able to:
"
Determine data requirements from the use cases.
"
Determine what nonfunctional requirements will affect the solution’s
conceptual design.

Slide Objective
To introduce this activity.
Lead-in
In this activity, you will
practice what you have
learned about use cases.
Delivery Tip
Remind students of the
definition of a use case and
have them refer back to this
definition if necessary.
Delivery Tip
Remind students that the
activities provide more
space than will be needed
by the anticipated number of
answers. The fact that 10
answer spaces are provided

does not mean that students
are expected to provide 10
answers for every exercise.
Module 3: Using a Conceptual Design for Data Requirements 59



Validating Data Requirements
"
Purpose
$
Ensures that data requirements are traceable to the
business needs
"
Techniques
$
Source sign off
$
Collective verification


Data requirement validation ensures that specified business wants, needs, and
constraints are satisfied.
"
After data requirements are defined, ensuring that they are traceable to the
business requirements helps guarantee that the business requirements are
met.
It is imperative that the design team validate the data requirements because
if the use cases identified in conceptual design are partially erroneous or
only partially represent the intended solution, the data requirements may

change as well.

As the solution’s conceptual design is finalized, it is important that everyone on
the design team, as well as customers and key stakeholders, agree about what
the conceptual design represents. The conceptual design should represent not
only the intended solution, but also the data involved in the solution.
The following two techniques can be used to ensure the validity of the data
requirements specified in the conceptual design:
"
Source sign off
Make sure that the users on which the current-state use cases, data
requirements, and scenarios are based are in agreement with the conceptual
design.
"
Collective verification
Have the project team review the use cases, scenarios, and gathered data to
make sure that the conceptual design represents the sum of all its parts. It is
easy for a conceptual design and its data requirements to appear correct until
it is matched against the entire set of inputs, when it becomes apparent that
the design does not represent the desired output.

Slide Objective
To introduce the purpose of
and techniques for
validating data requirements
within a conceptual design.
Lead-in
Validating data
requirements can help
improve the overall quality

of a solution’s conceptual
design.
60 Module 3: Using a Conceptual Design for Data Requirements



!
!!
! Activity 3.2: Relating Data Requirements to
Conceptual Design


In this activity, you will participate with other students and the instructor in an
instructor-led discussion on conceptual design and data design.
After completing this activity, you will be able to:
"
Discuss use cases, data requirements, and requirements validation as they
relate to conceptual design for data systems.

Slide Objective
To introduce this activity.
Lead-in
In this activity, you will
practice what you have
learned about data
requirements.
Module 3: Using a Conceptual Design for Data Requirements 61

!
!!
! Review
"
Guidelines
"
Review Questions
"
Looking Forward
In this section
In this section



Slide Objective
To explain the purpose of
this section and what
students will learn.
Lead-in
This section reviews what
you have learned and
prepares you for the next
modules.
62 Module 3: Using a Conceptual Design for Data Requirements



Guidelines
"
Iteration is the key to steady progress

"
Help users focus on their tasks, not on the product
"
Avoid working on the physical design
"
Make sure data requirements match the conceptual
design
"
Do not forget the nonfunctional requirements


Iteration is the key to steady progress. By reviewing the design multiple times,
you will force it to be re-evaluated. Constant evaluation will help determine its
overall worth.
Keeping users focused on what they need to do, rather than on the tools they
will use to do it, will be easier if the tools supplement the task, rather than the
task being dictated by the tools.
Avoiding the trap of going straight to physical design may be difficult at times.
If you move the finished conceptual design straight to implementation,
however, you circumvent logical design, and the inner workings of the design
are never specified.
Keep in mind that there is no real conceptual data design. There are, however,
high-level data requirements that must match the conceptual design for logical
design to take place. Make sure that the data requirements and the design are
synchronized.
It can often be easy for the design team to consider only the facts. Functional
data requirements tend to show visible and tangible requirements, while
nonfunctional requirements can be more difficult to identify and somewhat
more difficult to quantify. Do not neglect the nonfunctional requirements
because they are often just as important as the functional requirements.

Slide Objective
To provide some general
guidelines related to the
information in this module.
Lead-in
The following are some
general guidelines to
consider.
Module 3: Using a Conceptual Design for Data Requirements 63



Review Questions
"
Describe the information investigation process
"
Determine functional data requirements from use
cases
"
Identify nonfunctional requirements that will affect
a solution’s design


1. Why should the solution’s conceptual design and its data requirements be
synchronized?
To allow the conceptual design to accurately depict the desired solution,
both from a user scenario and data-centric point of view


2. What are the characteristics of data requirements?

Required, explicit, and hidden


3. What are the two phases in conceptual design that can result in the creation
of use cases?
Information gathering and information analysis


Slide Objective
To reinforce module
objectives by reviewing key
points.
Lead-in
The review questions cover
some of the key concepts
taught in this module.
64 Module 3: Using a Conceptual Design for Data Requirements



Looking Forward
Module 1: Course
Overview
Module 4: Deriving a
Logical Data Design
Module 5: Normalizing the
Logical Data Design
Module 6: Deriving a
Physical Data Design
Module 7: Implementing

Data Integrity
Module 2: Solution Design
Processes
Module 3: Using a Conceptual
Design for Data Requirements
Module 8: Designing Data
Services
Module 9: Data Storage
Considerations
Designing Data
Services and
Data Models


"
The upcoming modules will cover the following topics:
"
Developing a logical data design
"
Normalization of data
"
Physical design considerations

Slide Objective
To explain what students
will learn next.