Data Requirements Document - HUD
[pic]
DATA
REQUIREMENTS
DOCUMENT
Project or System Name
U.S. Department of Housing and Urban Development
Month, Year
Revision Sheet
|Release No. |Date |Revision Description |
|Rev. 0 |5/30/00 |Data Requirements Document Template and Checklist |
|Rev. 1 |4/10/02 |Conversion to WORD 2000 format |
| | | |
| | | |
| | | |
| | | |
| | | |
| |Data Requirements Document Authorization Memorandum |
I have carefully assessed the Data Requirements Document for the (System Name). This document has been completed in accordance with the requirements of the HUD System Development Methodology.
MANAGEMENT CERTIFICATION - Please check the appropriate statement.
______ The document is accepted.
______ The document is accepted pending the changes noted.
______ The document is not accepted.
We fully accept the changes as needed improvements and authorize initiation of work to proceed. Based on our authority and judgment, the continued operation of this system is authorized.
_______________________________ _____________________
NAME DATE
Project Leader
_______________________________ _____________________
NAME DATE
Operations Division Director
_______________________________ _____________________
NAME DATE
Program Area/Sponsor Representative
_______________________________ _____________________
NAME DATE
Program Area/Sponsor Director
DATA REQUIREMENTS DOCUMENT
TABLE OF CONTENTS
Page #
1.0 GENERAL INFORMATION 1-1
1.1 Purpose 1-1
1.2 Scope 1-1
1.3 System Overview 1-2
1.4 Project References 1-2
1.5 Acronyms and Abbreviations 1-2
1.6 Points of Contact 1-3
1.6.1 Information 1-3
1.6.2 Coordination 1-3
2.0 DATA DESCRIPTION 2-1
2.1 Logical Database Design 2-1
2.2 Data Characteristics and Categorization 2-1
2.2.1 Static Data 2-1
2.2.2 Dynamic Input Data 2-2
2.2.3 Dynamic Output Data 2-3
2.2.4 Internally Generated Data 2-4
2.3 Data Constraints 2-4
2.4 Data Retention 2-5
2.5 Impacts 2-5
2.5.1 Equipment 2-5
2.5.2 Software 2-5
2.5.3 Organization 2-5
2.6 Data Storage 2-5
2.7 Scales of Measurement 2-5
2.8 Measurement Conversion Factors 2-6
2.9 Frequency of Update and Processing 2-6
3.0 DATA HANDLING 3-1
3.1 Source of Input 3-1
3.2 Medium and Device 3-1
3.2.1 Input Medium and Device 3-1
3.2.2 Output Medium and Device 3-2
3.3 Recipients 3-2
3.4 Data Collection Procedures 3-2
3.5 User Access 3-2
3.6 Error Handling 3-2
3.7 Data Responsibilities 3-2
3.8 Security 3-2
1.0 GENERAL INFORMATION
NOTE TO AUTHOR: Highlighted, italicized text throughout this template is provided solely as background information to assist you in creating this document. Please delete all such text, as well as the instructions in each section, prior to submitting this document. ONLY YOUR PROJECT-SPECIFIC INFORMATION SHOULD APPEAR IN THE FINAL VERSION OF THIS DOCUMENT.
Document the information gathered regarding the system’s data requirements in accordance with HUD SDM documentation standards (Handbook 2400.15). The document will take the form of a Data Requirements Document.
The Data Requirements Document is prepared when a data collection effort by the user group is required to generate and maintain system data or files. It is as detailed as possible concerning the definition of inputs, procedures, and outputs.
The Data Requirements Document provides a detailed description of the data model that the system must use to fulfill its functional requirements. Users and developers work jointly to identify requirements and with HUD Data Administration for defining the domain data model. In situations where users and Data Administration determine the model independently of developers, hold walkthroughs during the identification so that users can describe the requirements and the model to developers and receive feedback about the clarity and completeness of requirements. Separate the data description into two categories: static and dynamic data. Arrange data elements in each category in logical groupings, such as functions, subjects, or other groupings most relevant to their use. Describe the type of information required to document the characteristics of each data element. Specify information, including that related to sensitivity and privacy issues, to be collected by the user and developer.
GENERAL INFORMATION
1.1 1.1 Purpose
Describe the purpose of the Data Requirements Document.
1.2 1.2 Scope
Describe the scope of the Data Requirements Document as it relates to the project.
1.3 1.3 System Overview
Provide a brief system overview description as a point of reference for the remainder of the document. In addition, include the following:
1. Responsible organization
2. System name or title
3. System code
1. System category
1. Major application: performs clearly defined functions for which there is a readily identifiable security consideration and need
2. General support system: provides general ADP or network support for a variety of users and applications
2. Operational status
3. Operational
4. Under development
5. Undergoing a major modification
4. System environment and special conditions
1.4 1.4 Project References
Provide a list of the references that were used in preparation of this document. Examples of references are:
5. Previously developed documents relating to the project
6. Documentation concerning related projects
7. HUD standard procedures documents
1.5 1.5 Acronyms and Abbreviations
Provide a list of the acronyms and abbreviations used in this document and the meaning of each.
1.6 1.6 Points of Contact
1.6.1 1.6.1 Information
Provide a list of the points of organizational contact (POCs) that may be needed by the document user for informational and troubleshooting purposes. Include type of contact, contact name, department, telephone number, and e-mail address (if applicable). Points of contact may include, but are not limited to, helpdesk POC, development/maintenance POC, and operations POC.
1.6.2 1.6.2 Coordination
Provide a list of organizations that require coordination between the project and its specific support function (e.g., installation coordination, security, etc.). Include a schedule for coordination activities.
2.0 DATA DESCRIPTION
DATA DESCRIPTION
a 2.1 Logical Database Design
Describe and depict in a graphic representation, the logical organization of the data and defined relationships. Include business rules relevant to the data model or to specific data items.
b 2.2 Data Characteristics and Categorization
Discuss the data elements to be used by the system. When the information is published in a data dictionary, reference to an entry in the dictionary will be made rather than including an extract from that dictionary.
i 2.2.1 Static Data
Static data is defined as data primarily used for reference during operation and usually generated or updated in widely separated time frames, independent of normal software execution. Arrange the data elements in each category below in logical groupings, such as functions, subjects or other groupings that are most relevant to their use. Organize the data in a way that facilitates processing of inputs to generate outputs and that satisfies other computational requirements.
List the static data elements used for either control or reference purposes. Include the following for each data element, repeating the table for as many logical groups (e.g., entities or objects) and data elements as are needed:
|LOGICAL GROUP NAME: |
|Data element name | |
|Synonymous name | |
|Type (e.g., alpha, alphanumeric, or numeric) | |
|Definition | |
|Format | |
|Range of values or discrete values | |
|Unit of measurement | |
|Precision (e.g., number of decimal places) | |
|Data item names, abbreviations, and codes | |
|Characteristics, such as accuracy, validity, timing, and | |
|capacity | |
ii 2.2.2 Dynamic Input Data
Dynamic data includes all data to be updated and either input during normal execution or output. Arrange the data elements in each category below in logical groupings, such as functions, subjects or other groupings that are most relevant to their use. Organize the data in a way that facilitates processing of inputs to generate outputs and that satisfies other computational requirements.
Include the following for each data element, repeating the table for as many logical groups (e.g., entities or objects) and data elements as are needed:
|LOGICAL GROUP NAME: |
|Data element name | |
|Synonymous name | |
|Type (e.g., alpha, alphanumeric, or numeric) | |
|Definition | |
|Format | |
|Range of values or discrete values | |
|Unit of measurement | |
|Precision (e.g., number of decimal places) | |
|Data item names, abbreviations, and codes | |
|Characteristics, such as accuracy, validity, timing, and | |
|capacity | |
iii 2.2.3 Dynamic Output Data
Dynamic output data elements constitute the data to be changed by normal system execution or online operation. Arrange the data elements in each category below in logical groupings, such as functions, subjects or other groupings that are most relevant to their use. Organize the data in a way that facilitates processing of inputs to generate outputs and that satisfies other computational requirements.
Include the following for each data element, repeating the table for as many logical groups (e.g., entities or objects) and data elements as are needed:
|LOGICAL GROUP NAME: |
|Data element name | |
|Synonymous name | |
|Type (e.g., alpha, alphanumeric, or numeric) | |
|Definition | |
|Format | |
|Range of values or discrete values | |
|Calculation or algorithm used to derive data value | |
|Unit of measurement | |
|Precision (e.g., number of decimal places) | |
|Data item names, abbreviations, and codes | |
|Characteristics, such as accuracy, validity, timing, and | |
|capacity | |
iv 2.2.4 Internally Generated Data
Internally generated data is created as a result of program calculations or other program manipulations, such as algorithms. Arrange the data elements in each category below in logical groupings, such as functions, subjects or other groupings that are most relevant to their use. Organize the data in a way that facilitates processing of inputs to generate outputs and that satisfies other computational requirements.
Include the following for each data element, repeating the table for as many logical groups (e.g., entities or objects) and data elements as are needed:
|LOGICAL GROUP NAME: |
|Data element name | |
|Synonymous name | |
|Type (e.g., alpha, alphanumeric, or numeric) | |
|Definition | |
|Format | |
|Range of values or discrete values | |
|Calculation or algorithm used to derive data value | |
|Unit of measurement | |
|Precision (e.g., number of decimal places) | |
|Data item names, abbreviations, and codes | |
|Characteristics, such as accuracy, validity, timing, and | |
|capacity | |
c 2.3 Data Constraints
State the constraints on the data. Indicate the limits of the data requirements with regard to further expansion or use, such as the maximum size and number of files, records, and data elements. Emphasize the constraints that could prove critical during design and development.
Identify any restrictions on each data element that must be considered during definition of the system. Limitations may be placed on the data because of such factors as:
3. source of data input
4. devices used for input and output of data
5. recipients of the data
6. conversion processes, the converted form the input and output data will take
7. how often the data will be updated
d 2.4 Data Retention
Describe the data retention requirements in terms of the following:
8. historic retention to include the collection of data to be retained and its format, storage medium, and time parameters
9. periodic report data (retention period after generation of reports and retention period of periodic reports after summary reports are generated)
10. summary reports data (retention period after generation)
Refer to HUD Handbook (2229.1); Records Disposition Scheduling for Automated Systems for further information on data retention. Additional key references include HUD Handbook (2200.1); Administrative Services Policy Handbook (Chapter 11), the General Records Schedules (2228.2), and HUD Records Disposition Schedules (2225.6).
e 2.5 Impacts
Describe the impact, if applicable, of the data requirements on equipment, software, user and developer organizations. An estimate of the data storage requirements in terms of size and number of records will be provided. A description of the expected growth of the data and related components should also be provided.
i 2.5.1 Equipment
Describe the impact of the data requirements on equipment.
ii 2.5.2 Software
Describe the impact of the data requirements on software.
iii 2.5.3 Organization
Describe the impact of the data requirements on the user and developer organization.
f 2.6 Data Storage
Estimate the data storage and processing requirements in terms of size and number of records.
g 2.7 Scales of Measurement
Specify for numeric scales, units of measurement, increments, scale, zero-point, and range of values. For non-numeric scales, any relationships indicated by the legal values should be stated.
h 2.8 Measurement Conversion Factors
In some cases, stored data is measured in one unit of measure but processed by the system in another unit of measure. For example, a data element is a function of time, stored in hours; the new system requires that the data be stored in terms of minutes. In this example, the conversion factor is “multiply by 60.”
Specify the conversion factors of measured quantities that must go through analog or digital conversion processes.
i 2.9 Frequency of Update and Processing
State the expected frequency of data element change and the expected frequency of processing input data elements. If the input arrives in a random manner, specify both the average frequency and some measure of the variance.
3.0 DATA HANDLING
Document the derived data requirements in a requirement matrix to show the breakdown of system objectives to data. Use a tool to manage the matrix. Insert the matrix into the Data Requirements Document.
DATA HANDLING
1 3.1 Source of Input
Create a table identifying the source from which data elements will be entered, such as an organizational unit or operator. Describe all sources from which data will be gathered, including organizations internal and external to HUD, automated systems that will directly interface with the application under development, and those systems that will transmit data to the new system.
Identify the frequency with which data are input to the proposed system for each input data requirement. This frequency may be expressed using terms such as daily, weekly, monthly, yearly, each minute, hourly, or continuously.
The following table is provided as an example only.
|Data Element Name |Source of Input |Frequency of input from |Is source internal |Does source interface |Description of |
| |(organization, |source |to HUD or external? |directly with system? |interfacing or |
| |operator, or | | | |transmitting source |
| |workstation) | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
2 3.2 Medium and Device
1 3.2.1 Input Medium and Device
Describe, in detail, the format of data to be input to the proposed system. Descriptions may be narrative or in the form of data record layouts and screen formats, as appropriate. This may include the identity of each device by name, including a brief description, and the process used to transmit the data.
Identify the medium and hardware intended for entering each data element into the system. In situations in which only specific workstations are to be legitimate entry points, so specify.
2 3.2.2 Output Medium and Device
Identify the medium and hardware device intended for presenting output data to the recipient. Specify in what medium the recipient is to receive the data. If the output is to be passed to some other automated system, the specifics of the medium should be described.
3 3.3 Recipients
Name the organization or system that will be receiving output data. This may be shown in any form, such as data file or report.
4 3.4 Data Collection Procedures
Describe procedures that will be used to collect data, including a detailed format for the input data. Describe how the data will be transmitted to the system.
5 3.5 User Access
Describe or depict the user or user types and their associated create, read, update, and delete permissions.
6 3.6 Error Handling
Identify the process for handling inaccurate or incomplete data.
7 3.7 Data Responsibilities
Determine and describe the organization that will be responsible for managing the data.
8 3.8 Security
Describe the security classification for the data and the degree of security of the algorithms. For all sensitive data, include a statement indicating whether the data are always sensitive, become sensitive upon the occurrence of specific events, or change their degree of sensitivity upon the occurrence of specific events.
................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.
Related download
- implementation plan template cms
- answers to chapters 1 2 3 4 5 6 7 8 9 end of chapter
- enterprise analytics compass
- edwin analytics reports overview expanded
- report request form
- school data analysis
- jump to health informatics online classroom
- data requirements document hud
- edwin analytics faqs
- database design document template cms
Related searches
- crm requirements document template
- system requirements document example
- system requirements document template
- technical requirements document template
- dod system requirements document example
- functional requirements document dod
- dod functional requirements document template
- systems requirements document template
- operational requirements document dod
- functional requirements document dau
- functional requirements document checklist
- requirements document template