Tài liệu Module 3: Using a Conceptual Design for Data Requirements docx

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 Int

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

! Overview

" Investigation Process

" Data Requirements

" Activity 3.2: Relating Data Requirements to Conceptual Design

" Review

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

! Investigation Process

" Gathering Information

" Analyzing Information

" Creating Use Cases

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

Gathering Information

" Identify necessary information

" Identify sources for required information

" Use perspectives when looking at source information

" Gather information

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

Analyzing Information

" Organization

redundancies

" Identification of relationships

" Prioritization

" Validation

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

Creating Use Cases

" Show actions:

" Describe the current state and desired future state

" Components

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

! 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

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

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

Categories of Data Requirements

" Functional data requirements

" Nonfunctional data requirements

should consider

requirement and its underlying information

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

" 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?

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

Identifying Nonfunctional Data Requirements

" Iterative process

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