Detailing Business Data Requirements

Introduction

• What is a business data requirement? Why are these requirements important?
• Review the requirements package.
• What is the difference between business data and database design?
• Review the 7 characteristics of "excellent" requirements.
• Review the 5 core requirements components.

Entities and Attributes

• Review the components included in the project initiation section of the requirements package.
• Learn to use the context level dataflow diagram as a starting point for identifying data requirements.
• Entity types are the basic building blocks of the business data. This section defines entities, gives suggested naming guidelines, teaches the importance of entity definitions, gives criteria to evaluate potential entities, describes entity unique identifiers, and has students identify and document entities from the case study.
• Attribute types are characteristics of entity types. This section defines attributes, gives suggested naming guidelines and class words, teaches attribute cardinalities, gives criteria to evaluate attributes, and has students identify and document attributes from the case study.
• Understand the difference between logical unique identifiers and primary keys.

Entity Relationships and Diagramming Conventions

• Learn how business data requirements are displayed in an entity relationship diagram.
• Relationships are data associations that define the business rules of the project as they relate to data. This section defines relationships and business rules, gives suggested naming guidelines, teaches relationship cardinalities, and has students identify and document relationships from the case study.
• Review common diagram notations for data related business rules.

Detailing the Data Requirements

• Detailing repeating data elements. Repeating attributes must be broken down into their components, properly named, and clearly documented with example data values. Students will refine their requirements document based on additional business requirements.
• Detailing complex business rules. Complex business rules (many to many relationships) should be properly named and clearly documented with example data values. Students will refine their requirements document based on additional business requirements.
• Detailing sub-category entities. Some business data naturally falls into sub-categories and should be documented as such. These entities must be properly named, and be related to the supertype entity. The sub-category is defined as either exclusive or inclusive and a discriminating attribute is created.

Transition from Business Data to a Physical Design

• Learn how to link the data and process elements to identify missing or incomplete requirements. Each essential process must use data, and each data element must be used by at least one essential process.
• How does business data become a database design? Review the data requirements for completeness, understand how logical components are translated to physical components, and develop a strategy for maintaining the business requirements.
• Introduction to database design.
• Scope the design area using subject areas.
• What is de-normalization? Why de-normalize a database design?

Workshop - e-commerce case study

• Identify and document entities.
• Identify and document attributes.
• Identify and document data related business rules.

Appendix - Data Normalization

• What is data normalization and why is it important?
• What are the rules of normalization?

Course Length:
3 days

PDUs:
Earn 21 IIBA CDUs and PMI PDUs

Public Pricing:
$1795.00 per student