Module 3: Using a Conceptual Design for Data Requirements Module 9: Data Storage Considerations Module 1: Course Overview Module 8: Designing Data Services Module 7: Implementing Data Integrity Module 2: Solution Design Processes Designing Data Services and Data Models Module 3: Using a Conceptual Design for Data Requirements Module 4: Deriving a Logical Data Design Module 6: Deriving a Physical Data Design Module 5: Normalizing the Logical Data Design Investigation Process Module 3: Using a Conceptual Design for Data Requirements Activity 3.2: Relating Data Requirements to Conceptual Design Data Requirements Activity 3.1: Identifying Data-Related Use Cases and Data Requirements Module 3: Using a Conceptual Design for Data Requirements ! Overview Slide Objective To provide an overview of this module’s topics and objectives " Investigation Process " Data Requirements " Activity 3.2: Relating Data Requirements to Conceptual Design " Review In In this this module 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 47 48 Module 3: Using a Conceptual Design for Data Requirements ! Investigation Process Slide Objective To introduce use cases and nonfunctional requirements that are used in the solution’s conceptual design " Gathering Information " Analyzing Information " Creating Use Cases In In this this section section Delivery Tip This section provides an overview of what students would normally to get information about data and nonfunctional requirements They will not actually this in the course If students want more information about this process, refer them to Course 1585: Gathering and Analyzing Business Requirements 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 Module 3: Using a Conceptual Design for Data Requirements 49 Gathering Information 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 " 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 50 Module 3: Using a Conceptual Design for Data Requirements Analyzing Information 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 Organization " Identification of relationships $ " Determine which groups of information are related Prioritization $ " Provide structure to the original information and remove redundancies 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 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 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 Module 3: Using a Conceptual Design for Data Requirements Creating Use Cases 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 " " 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 51 52 Module 3: Using a Conceptual Design for Data Requirements ! Data Requirements Slide Objective To introduce the role of data requirements in conceptual design " Characteristics of Data Requirements Lead-in " 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, you will learn how to establish data requirements In In this this section section Knowing how to establish data requirements during conceptual design helps define the final product Module 3: Using a Conceptual Design for Data Requirements 53 Characteristics of Data Requirements Slide Objective To introduce the characteristics of data requirements Lead-in Some characteristics of data requirements are as follows " 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 54 Module 3: Using a Conceptual Design for Data Requirements Categories of Data Requirements 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 " 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? 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 you have to supply with information? What import and export capabilities you need? 56 Module 3: Using a Conceptual Design for Data Requirements Identifying Functional Data Requirements 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 " 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 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? Module 3: Using a Conceptual Design for Data Requirements 57 Identifying Nonfunctional Data Requirements 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 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 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 not tamper with the invoices? " Identify the requirement as a nonfunctional data requirement and include it in the use cases for the system 58 Module 3: Using a Conceptual Design for Data Requirements Activity 3.1: Identifying Data-Related Use Cases and Data Requirements Slide Objective To introduce this activity Lead-in In this activity, you will practice what you have learned about use cases 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 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 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 Module 3: Using a Conceptual Design for Data Requirements 59 Validating Data Requirements Slide Objective To introduce the purpose of and techniques for validating data requirements within a conceptual design " Purpose $ Lead-in Validating data requirements can help improve the overall quality of a solution’s conceptual design " 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 60 Module 3: Using a Conceptual Design for Data Requirements ! Activity 3.2: Relating Data Requirements to Conceptual Design Slide Objective To introduce this activity Lead-in In this activity, you will practice what you have learned about data requirements 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 Module 3: Using a Conceptual Design for Data Requirements ! Review 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 " Guidelines " Review Questions " Looking Forward In In this this section section 61 62 Module 3: Using a Conceptual Design for Data Requirements Guidelines Slide Objective To provide some general guidelines related to the information in this module Lead-in The following are some general guidelines to consider " 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 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 Module 3: Using a Conceptual Design for Data Requirements 63 Review Questions 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 " Describe the information investigation process " Determine functional data requirements from use cases " Identify nonfunctional requirements that will affect a solution’s design 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 What are the characteristics of data requirements? Required, explicit, and hidden What are the two phases in conceptual design that can result in the creation of use cases? Information gathering and information analysis 64 Module 3: Using a Conceptual Design for Data Requirements Looking Forward Slide Objective To explain what students will learn next Module 9: Data Storage Considerations Module 1: Course Overview Module 8: Designing Data Services Module 7: Implementing Data Integrity Module 2: Solution Design Processes Designing Data Services and Data Models Module 3: Using a Conceptual Design for Data Requirements Module 4: Deriving a Logical Data Design Module 6: Deriving a Physical Data Design Module 5: Normalizing the Logical Data Design " The upcoming modules will cover the following topics: " Developing a logical data design " Normalization of data " Physical design considerations ... Services and Data Models Module 3: Using a Conceptual Design for Data Requirements Module 4: Deriving a Logical Data Design Module 6: Deriving a Physical Data Design Module 5: Normalizing the Logical... the Logical Data Design Investigation Process Module 3: Using a Conceptual Design for Data Requirements Activity 3.2: Relating Data Requirements to Conceptual Design Data Requirements Activity 3.1:... Overview Module 8: Designing Data Services Module 7: Implementing Data Integrity Module 2: Solution Design Processes Designing Data Services and Data Models Module 3: Using a Conceptual Design for Data