Subcomponent: System Design and Development (SD)
System Design and Development is the characteristics of the functional and technical requirements for a data system, and the development and implementation of a data system based on those requirements
Introduction: The System Design and Development subcomponent addresses the characteristics of the functional and technical requirements for a data system, and the development and implementation of a data system based on those requirements. This subcomponent includes the process of defining the architecture, database, system standards and components, and the data elements. Part C and Section 619 state staff involvement, input, and review throughout the entire process are a hallmark of a high-quality data system.
The purpose of the System Design and Development subcomponent is to assist states in creating and supporting a data system based on the Part C and Section 619 program requirements as articulated in the purpose and vision. System design and development is the means by which the operational needs of the program staff and other users are translated into a functional and technical infrastructure that will meet those needs. This subcomponent supports the development of new data systems and enhancements to existing data systems.
This subcomponent was developed around the phases and processes of a standard System Development Life Cycle (SDLC), which includes (1) system initiation; (2) system requirements analysis; (3) system design; (4) system development; (5) system acceptance; and (6) system deployment. This subcomponent begins once data governance approves a high-level plan for a new data system or data system enhancement and ends when the system or enhancement is deployed. Ongoing maintenance activities and operations to support the system are addressed in the Data Governance and Management subcomponent, and the evaluation of the data system to determine needed enhancements is addressed in the Sustainability subcomponent. Designing and developing a data system involves numerous technical requirements and processes usually performed by the Information Technology (IT) team and not by Part C and Section 619 staff. Because the subcomponent was developed for use by Part C and Section 619 staff, these technical activities are not addressed within it.
This subcomponent consists of three sections, each of which addresses two phases of the SDLC. The first section addresses the first two phases of the life cycle: initiation of a new data system or enhancement, and system requirements analysis. The purpose of system requirements analysis is to obtain a thorough and detailed understanding of the business needs and to break those into discrete requirements. These requirements must then be clearly defined, reviewed, and agreed upon by the state Part C and Section 619 staff. Sufficient time and resources should be allocated during system requirements analysis to bring stakeholders and their interests into the process. Subject-matter experts in Part C and Section 619 must also be actively involved in defining business requirements. During system requirements analysis, a set of functional specifications for the data system development or enhancement are created through an iterative process. These specifications provide the foundation for all subsequent design and development work.
The first section also addresses critical data elements and features that should be contained in a high-quality data system. A fundamental purpose of the framework is to help states develop more powerful and comprehensive data systems, and such systems include the suggested data elements and features. Although many state data systems do not have all of the suggested data elements and features, the purpose of the framework is to help states move toward such systems.
The second section addresses the third and fourth phases of the SDLC: system design and system development. Part C and Section 619 staff may not be directly involved in the technical aspects of the system design and construction work, but the state should have a process in place for Part C and Section 619 state staff to work and communicate with the IT team, providing feedback, input, and approval when necessary.
The third section addresses the fifth and sixth phases of the SDLC: system acceptance and system deployment. Successful acceptance testing is the final opportunity to establish that the data system performs as expected in an environment that closely simulates one which will be used after deployment. During acceptance testing, end users thoroughly test the data system as if it were fully implemented. An end user is an individual who uses a computer (data) system after it has been fully developed and deployed. The term is based on the idea that the “end goal” of a software or hardware product is to be useful to the consumer. System acceptance also includes creating or updating supporting documentation and reference materials. Deployment refers to the launch of the new data system or enhancement.
Simply click on the green links for each Quality Indicator and Element of Quality to view lists of related resources.
Section 1: Initiation of New System/Enhancement and Requirements Analysis
Quality Indicator SD1: Part C/619 state staff are actively involved in initiating the development of the new data system or enhancement.
- SD1a. Part C/619 state management or leadership provide input to determine project team roles and responsibilities and commit Part C/619 staff to the development of the data system/enhancement.
- SD1b. Part C/619 state staff review the high-level plan for the data system/enhancement to ensure that it meets Part C/619 goals and needs.
- SD1c. Part C/619 state staff provide input on how the new system/enhancement will be developed (i.e., vendor/contractor, in-house, commercially available product) and related staffing needs.
- SD1d. Part C/619 state staff provide input into the plan and schedule for the system requirements analysis and the plan and schedule for the remaining system design/development phases.
- SD2a. Part C/619 state staff are actively involved in defining, reviewing, and revising business requirements, which identify programmatic needs expressed in the language of the Part C/619 program.
- SD2b. Part C/619 state staff are actively involved with the IT team to create work process models that reflect an understanding of the Part C/619 program, processes, and language.
- SD2c. Part C/619 state staff are actively involved with the IT team to create data models that reflect program language.
- SD2d. Part C/619 state staff solicit end user input on business requirements, process models, and data models.
- SD2e. Part C/619 state staff are actively involved in reconciling process models and data models with business requirements, with specific consideration of budget and scope.
- SD2f. Part C/619 state staff have a clear process for the approval of the final business requirements.
- SD3a. Features and functions of the data system/enhancement, including those for reporting, interfaces and user access*, are fully described and expressed in the language of the Part C/619 program.
- SD3b. The list of required features and functions of the data system/enhancement indicates what is in and out of scope.
- SD3c. Business requirements are prioritized (e.g., as essential, useful, or desirable).
- SD3d. The business requirements address technical requirements that operate in the background, such as encryption, system performance and load, data archiving, audits and controls, and data conversion.
- SD3e. A diagram or description of Part C/619 work processes and work flows is developed and depicts processes such as referral/intake, eligibility determination, IFSP/IEP development, and transition.
- SD3f. Work processes and work flows are broken down into manageable functions and subfunctions (e.g., IFSP/IEP development and provision of services and supports).
- SD3g. All data needed for Part C/619 reporting, and for accountability, program improvement, and program operations (refer to Purpose and Vision subcomponent), have been identified for the data system/enhancement.
- SD3h. A data model identifying the data elements, the characteristics that define those data (i.e., the data attributes), and the relationships between the entities has been developed.
- SD3i. An initial data dictionary is produced that defines the data elements, their attributes, and the logical relationships among the data elements.
Quality Indicator SD4: The Part C/619 state data system has the capacity to support accountability, program improvement, and program operations, and should contain the following data elements and features.*
- SD4a. The Part C/619 state data system includes, but is not limited to, the following types of data:
1. Child-level data elements
a. Unique child identifier
b. Family demographics
i. Primary language spoken in the homec. Child demographics
ii. Home address
iii. Socioeconomic status (e.g., eligibility for Medicaid, free and reduced lunch)
i. Genderd. For Part C: Child Protective Services involvement
iii. Primary language
iv. Date of birth
e. In foster care
i. Dateg. Evaluation and eligibility
i. Date of consent for evaluationh. Descriptive information on nature of delays/disabilities (e.g., International Classification of Diseases codes (ICD-9), diagnosed conditions, areas of delay)
ii. Date of evaluation
iii. Date eligibility determined
iv. Date of enrollment in the program
v. Eligibility status
vi. Reason eligible (e.g., developmental delay, visual impairment, established condition or disability)
vii. Reason for delay of eligibility determination
i. Datej. Services (planned and received)
ii. Type (e.g., initial, annual)
i. For each planned service:
1. Typeii. For services received:
2. Start date
3. End date
5. Intensity (e.g., minutes/session)
1. Typesk. Attendance in any center-based program (e.g., child care, preschool)
5. For Part C: Reason for delay of initiation of service(s)
l. Child outcomes
m. Family survey/outcomes
i. Date of transition plano. Exit
ii. Date of notification
iii. Date of transition conference
iv. Reason for delay of notification to Part B
v. Reason for delay of transition conference
2. Service provider/teacher-level data elements
a. Identifier that can be linked to child identifier and program identifier3. Local Early Intervention Services (EIS) program / Local Educational Agency-level data elements
b. Service provider/teacher demographics
i. Genderc. License, certification
iii. Date of birth
iv. Languages other than English
i. Field(s) of studye. Employment
ii. Degree(s) awarded
iii. Date(s) awarded
iv. For Part C: Continuing education information (e.g., units, hours)
i. Employer/agencyf. For Part C: Number of years working with children ≤ 5 years old with disabilities and their families
ii. Date started
iii. Position title
a. Name of entity
b. Unique ID of entity
c. Address of entity
d. Type (e.g., school district, other public provider, private)
e. Size of program/district in terms of number of children (e.g., total # of children ≤ 5 years old)
f. Size of program/district in terms of number of children ≤ 5 years old who receive IDEA services
g. Size of program/district in terms of staff (e.g., # of full-time equivalent [FTE] serving children ≤ 5 years old receiving IDEA services)
h. Inclusion opportunities (i.e., does entity provide IDEA services in settings where children without disabilities are receiving early care and education?)
i. Local determination
j. Financial data
i. Total funds budgeted for the Part C or 619 program
ii. Total funds expended for the Part C or 619 program
iii. Funds budgeted by revenue source (e.g., Federal C/B, state, private insurance, public insurance)
iv. Funds expended by revenue source (e.g., Federal C/B, state, private insurance, public insurance)
- SD4b. The Part C/619 state data system has the capacity to track data about children when they move from one Part C/619 local program to another in the state.
- SD4c. The Part C/619 state data system has built-in edit-check routines at the application and/or database levels (e.g., format checks, field validation restrictions, import restrictions/checks).
- SD4d. The Part C/619 state data system has reports in place to assess data quality (e.g., error reports, outliers, missing data).
- SD4e. The Part C/619 state data system has controls in place so end users access* data consistent with federal, state and local privacy requirements, including requiring strong passwords; limits on the length of access* (e.g., session timeouts, use of different user types and role-based permissions).
- SD4f. The Part C/619 state data system has embedded supports and training materials for end users (e.g., mouse over definitions, support documents, practice scenarios, practice site within the application, audiovisual tutorials).
- SD4g. The Part C/619 state data system, directly or through a related application, has reporting and analysis tools that provide end users, including state and local program staff, with easy access* to the data in both raw form and reports.
- SD4h. For transactional systems: The Part C/619 state data system provides automated functions that support program practices for end users, (e.g., date tickler or calendar reminders of critical dates such as deadlines for IFSP/IEP reviews and transition conferences).
- SD4i. The Part C/619 state data system has security measures that allow the state to comply with federal, state, and local privacy requirements, including those that address:
- Data back-up and recovery
- Data storage
- Data encryption
- Proper destruction of data
- Secure transmission of data
- SD4j. The Part C/619 state data system allows for selected modifications within the data system with little or no reliance on the IT team, such as adjusting user permissions and adding support documents.
- SD4k. The Part C/619 state data system has the capacity to link various child-level data elements, including child outcomes.
- SD4l. The Part C/619 state data system has the capacity to link child-level data with service provider/teacher data.
- SD4m. The Part C/619 state data system has the capacity to link child-level data with program/school/classroom data.
- SD4n. The Part C/619 state data system has the capacity to link service provider/teacher data with program/school/classroom data.
- SD4o. The Part C/619 state data system has the capacity to link family survey/outcomes data with other child-level data, including child outcomes.
- SD4p. For transactional systems: The Part C/619 state data system is able to track entries/changes made by end users to data in the database, and the user who made them.
- SD4q. The Part C/619 state data system has interoperability that allows for linking Part C or 619 data to other statewide longitudinal and early childhood data systems.
*Unless otherwise noted, the data elements listed in this quality indicator are recommended for inclusion in data systems for both Part C and 619 programs. It is not necessary for all of the data elements to be in one data system as long as the necessary linkages are in place. For example, budgeted and expended funds for each local program/district may be obtained by linking to a separate agency financial system.
Section 2: System Design and Development
- SD5a. Part C/619 state staff or representatives work with the IT team as decisions are made about technical architecture (e.g., hardware and software, naming conventions, importing legacy data) and provide clarification as necessary.
- SD5b. Part C/619 state staff work with the IT team to review, refine, and approve mock-ups of modules, reports, and other functions.
- SD5c. Part C/619 state staff work with the IT team on the ongoing development of the data dictionary.
- SD6a. Part C/619 state staff are actively involved with the IT team in refining the data system requirements during system construction with consideration of the scope.
- SD6b. Part C/619 state staff test modules as they are developed until they function as intended.
- SD6c. Part C/619 state staff communicate with the IT team to ensure adequate system performance based upon anticipated system peak usage.
- SD6d. Part C/619 state staff or representatives require technical documentation, including instructions for system deployment and maintenance.
Section 3: System Acceptance and Deployment
- SD7a. Part C/619 state staff select representative end users (e.g., based on user
- SD7b. Part C/619 state staff collaborate with the IT team to create the acceptance testing plan, including a schedule and expected testing environment.
- SD7c. Part C/619 state staff prepare materials (e.g., test data, sample cases) and feedback mechanism for acceptance testing.
- SD7d. Part C/619 state staff work with the IT team to ensure that legacy and new data are processed together as specified in the systems requirement analysis (e.g., test associated system utilities and processes for accuracy and fidelity).
- SD7e. Part C/619 state staff conduct acceptance testing, process user feedback, and communicate findings to the IT team.
- SD7f. Part C/619 state staff work with the IT team and/or project management to adjust plans as needed.
- SD7g. Part C/619 state staff repeat system acceptance testing as necessary until the system functions properly.
Quality Indicator SD8: Part C/619 state staff participate in creating, reviewing, and revising materials to support the implementation of the new data system/enhancement.
- SD8a. Part C/619 state staff ensure data dictionary is reviewed and revised as necessary.
- SD8b. Part C/619 state staff participate in creating and updating system materials (e.g., user manuals, online tutorials, webinars) as necessary.
- SD8c. Part C/619 state staff ensure changes to the materials are communicated to help desk support.
- SD8d. Part C/619 state staff revise updated materials based on acceptance testers’ review and feedback.
- SD9a. Part C/619 state staff collaborate with the IT team to create a deployment plan, including guidelines for transition to the new data system/enhancement, schedule, and roles and responsibilities.
- SD9b. Part C/619 state staff communicate the deployment plan to all necessary parties, including state and local staff.
- SD9c. Part C/619 state staff ensure end user support (e.g., training, release notes) is provided to all end users for the new data system/enhancement.
- SD9d. Part C/619 state staff or representatives confirm that contingency plans exist for problems during and after deployment of the new data system/enhancement.
- SD9e. Part C/619 state staff coordinate with the IT team to release the new data system/enhancement.
- SD9f. Part C/619 state staff coordinate with the IT team to transition the responsibility for the new data system/enhancement to the state agency according to the deployment plan.
- SD9g. For new systems only: Part C/619 state staff coordinate with the IT team on the retirement of the legacy system, including the decision to run the two systems in parallel.