DaSy Framework: System Design and Development (SD) Subcomponent

The System Design and Development subcomponent addresses the characteristics of the functional and technical requirements for database applications, and the development and implementation of applications based on those requirements. This subcomponent includes the process of defining the database structure, user interface, system standards and components, and the data elements. State staff involvement, input, and review throughout the entire process are hallmarks of a high-quality Part C and Part B 619 data system.

The purpose of the System Design and Development subcomponent is to assist states in creating and supporting database applications based on the Part C and Part B 619 program requirements consistent with 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 database applications as well as major enhancements to existing 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 should begin once a high-level plan is approved for a new database application or enhancement and ends when the application or enhancement is deployed. Ongoing management to support the application is addressed in the Data Governance and Management subcomponent, and the evaluation of the application to determine needed enhancements is addressed in the Sustainability subcomponent. Designing and developing a database application involves numerous technical requirements and processes usually performed by the information technology (IT) team and not the Part C and Part B 619 staff. Although the technical activities conducted by the IT team are not addressed within this subcomponent, Part C and Part B 619 staff should collaborate with them to ensure the application functions as expected.

This subcomponent consists of three sections, each of which addresses two phases of the SDLC. The first section, Initiation and Requirements Analysis, addresses the first two phases of the life cycle: initiation of a new database application or enhancement, and system requirements analysis. The purpose of requirements analysis is to obtain a thorough and detailed understanding of the “business” or program needs and to break those into discrete requirements that provide the foundation this work. These requirements must then be clearly defined, reviewed, and agreed upon by the state Part C and Part B 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 Part B 619 must also be actively involved in defining business requirements through an iterative process.

This first section also addresses critical data elements and functions that should be included in a high-quality Part C or Part B 619 database application. A fundamental purpose of the framework is to help states develop more robust and comprehensive database applications, and such applications include the suggested data elements and functions. Although many state database applications do not have all the suggested data elements and functions, the purpose of the framework is to help states move toward more effective systems. It is important to look to the future when developing system functionality, e.g., designing for access through mobile devices, electronic signature capability, parent portals, and predictive analytics.

The second section, Design and Development, addresses the technical aspects of the system design and development work. Part C and Part B 619 staff may not be directly involved in this technical work. The state should, however, have a process in place for Part C and Part B 619 state staff to work and communicate with the IT team, regularly providing input, feedback, and approval when necessary.

The third section, Acceptance and Deployment, addresses the fifth and sixth phases of the SDLC. Successful acceptance testing is the final opportunity to establish that the database application performs as expected in environments that closely simulate those which will be used after deployment. During acceptance testing, end users thoroughly test the application as if it were fully implemented. This section also includes updating supporting documentation and reference materials. Deployment refers to the launch of the new database application or enhancement.

Section 1: Initiation and Requirements Analysis

Quality Indicator SD1

Part C/619 state staff are actively involved in initiating the development of the new database application or enhancement, including business requirements, process models, and data models.

about SD1 Elements of Quality

SD1 – Elements of Quality
SD1a	Input is provided to determine project team roles and responsibilities and commit staff to the development of the database application/enhancement.
SD1b	Input is provided on how the new system/enhancement will be developed (i.e., vendor/contractor, in-house, commercially available product).
SD1c	Input is provided into the plan and the schedule for the system requirements analysis and other remaining system design/development phases.
SD1d	A plan for the application/enhancement is reviewed to ensure that it meets Part C/619 goals and needs.
SD1e	The following are developed with input and ongoing review to ensure they reflect an accurate understanding of the Part C/619 program, processes, and language: Business requirements Process model Data model
SD1f	Stakeholder input is gathered for business requirements, process models, and data models.
SD1g	A clear process is used for the approval of the final business requirements.

Read More +

Quality Indicator SD2

The system requirements analysis results in documented requirements for the new database application/enhancement that accurately describe what the new application/enhancement must do.

about SD2 Elements of Quality

SD2 – Elements of Quality
SD2a	Functions of the database application/enhancement are fully specified and expressed in the language of the Part C/619 program.
SD2b	Business requirements are drafted, prioritized, and then identified as either in or out of scope.
SD2c	The system requirements address technical requirements that operate in the background (e.g., encryption, system performance and load, data archiving, and audits and controls).
SD2d	Process models and workflow diagrams visually depict major processes such as eligibility determination and IFSP/IEP and subfunctions such as IFSP/IEP development, review, etc.
SD2e	All data needed for Part C/619 reporting, accountability, program improvement, and program operations have been identified for the application/enhancement.
SD2f	A data model identifies the data elements, the attributes that define those data, and the relationships between the entities (database tables).
SD2g	An initial data dictionary is produced that defines the data elements, their attributes, and the logical relationships among the data elements.
SD2h	Criteria are established for running the legacy system in parallel with the new database application and the point at which the legacy system is retired.

Read More +

Quality Indicator SD3

The Part C/619 state database application has the capacity to support accountability, program improvement, and program operations, and should contain the following data elements and functions.

about SD3 Elements of Quality

Read More +

SD3 – Elements of Quality
SD3a	Includes, but is not limited to, the following types of data: Child-level data elements Unique child identifier Family demographics Primary language spoken in the home Home address Socioeconomic status (e.g., eligibility for Medicaid, free and reduced lunch) Child demographics Gender Race/ethnicity Primary language Date of birth For Part C: Child Protective Services involvement In foster care Referral Date Source Evaluation and eligibility Date of consent for evaluation Date of evaluation Date eligibility determined Date of enrollment in the program Eligibility status Reason eligible (e.g., developmental delay, visual impairment, established condition or disability) Reason for delay of eligibility determination Descriptive information on nature of delays/disabilities (e.g., International Classification of Diseases codes (ICD-9), diagnosed conditions, areas of delay) IFSP/IEP Date Type (e.g., initial, annual) Services (planned and received) For each planned service: Type Start date End date Frequency Intensity (e.g., minutes/session) Method Setting For services received: Types Dates Minutes Providers For Part C: Reason for delay of initiation of service(s) Attendance in any center-based program (e.g., child care, preschool) Enrolled in public insurance, e.g., Medicaid, CHIP Child outcomes Family survey/outcomes Transition Date of transition plan Date of transition notification Parental opt out of notification Parental approval for transition conference Date of transition conference Reason for delay of notification to Part B Reason for delay of transition conference Exit Date Reason Service provider/teacher-level data elements Identifier that can be linked to child identifier and program identifier Service provider/teacher demographics Gender Race/ethnicity Date of birth Languages other than English License, certification Education Field(s) of study Degree(s) awarded Date(s) awarded For Part C: Continuing education information (e.g., units, hours) Employment Employer/agency Date started Position title For Part C: Number of years working with children Local Early Intervention Services (EIS) program/local educational agency (LEA)-level data elements Name of entity Unique ID of entity Address of entity Type (e.g., school district, other public provider, private) Size of program/district in terms of number of children (e.g., total # of children ≤ 5 years old) Size of program/district in terms of number of children ≤ 5 years old who receive IDEA services Size of program/district in terms of staff (e.g., number of full-time equivalent [FTE] serving children ≤ 5 years old receiving IDEA services) Inclusion opportunities (i.e., does entity provide IDEA services in settings where children without disabilities are receiving early care and education?) Local determination Financial data Total funds budgeted for the Part C or 619 program Total funds expended for the Part C or 619 program Funds budgeted by revenue source (e.g., federal Part C/ Part B, state, private insurance, public insurance) Funds expended by revenue source (e.g., federal Part C/ Part B, state, private insurance, public insurance)
SD3b	Has the capacity to share and transfer child records when they move from one Part C/619 local program to another in the state.
SD3c	Has built-in data validation and edit-check routines (e.g., format checks, field validation restrictions, logical consistency checks).
SD3d	Has established reports to assess data quality (e.g., error reports, outliers, missing data).
SD3e	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).
SD3f	Has embedded supports and training materials for end users (e.g., mouse over definitions, support documents, practice scenarios, practice site, audiovisual tutorials).
SD3g	Directly or through a related application, has reporting and analytic tools that: Provide access to raw and aggregate data in reasonable time Allow users to disaggregate the data, e.g., by race, ethnicity, type of disability Support standing and ad hoc reporting Meet the unique needs of role-based user types Employ dashboards Support data visualization
SD3h	For transactional systems: 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).
SD3i	Has provisions that allow the state to comply with federal, state, and local data privacy and security requirements, including those that address the following: Data transmission Data storage Data encryption Data back-up and recovery Data archival and destruction
SD3j	Allows for selected administrative modifications within the database application with little or no reliance on the IT team, such as adjusting user permissions and adding support documents.
SD3k	Has the capacity to link various child-level data elements, including child outcomes.
SD3l	Has the capacity to link child-level data with service provider/teacher data.
SD3m	Has the capacity to link child-level data with program/school/classroom data.
SD3n	Has the capacity to link service provider/teacher data with program/school/classroom data.
SD3o	Has the capacity to link family survey/outcomes data with other child-level data, including child outcomes.
SD3p	For transactional systems: Can track entries/changes made by end users to data in the database, and the user who made them.
SD3q	Has interoperability that allows for Part C or 619 data to be linked with other statewide longitudinal and early childhood data systems.

Section 2: Design and Development

Quality Indicator SD4

Part C/619 state staff work together with the IT team to translate requirements into the design, build, and testing of the new database application/enhancement.

about SD4 Elements of Quality

SD4 – Elements of Quality
SD4a	Aspects of the applications’ infrastructure (e.g., hardware and software, naming conventions, importing legacy data) are jointly decided.
SD4b	The database application requirements are jointly refined with consideration of the scope.
SD4c	Mock-ups of modules, reports, and other functions are jointly reviewed, refined, and approved.
SD4d	The data dictionary is jointly developed and continually refined throughout the process.
SD4e	Modules are jointly developed and reviewed before user acceptance testing.
SD4f	Adequate system performance is jointly designed for anticipated peak usage.
SD4g	Legacy data and new data are accurately processed together per the requirements.

Read More +

Section 3: Acceptance and Deployment

Quality Indicator SD5

Part C/619 state staff prepare for, communicate about, and conduct user acceptance testing to ensure the new database application/enhancement functions properly before deployment.

about SD5 Elements of Quality

SD5 – Elements of Quality
SD5a	Representative end users (e.g., based on user types, permissions) are selected for user acceptance testing.
SD5b	A user acceptance testing plan, including a schedule and expected testing environment, is created in collaboration with the IT team.
SD5c	Testing materials (e.g., test data, sample cases) and feedback mechanisms are prepared for user acceptance testing.
SD5d	User acceptance testing findings and other forms of user feedback are communicated to the IT team.
SD5e	User acceptance testing plans are adjusted as needed in collaboration with the IT team
SD5f	User acceptance testing is repeated as necessary until the system functions properly.

Read More +

Quality Indicator SD6

Part C/619 state staff participate in creating, reviewing, and revising materials to support the implementation of the database application/enhancement.

about SD6 Elements of Quality

SD6 – Elements of Quality
SD6a	User support and technical materials (e.g., technical documentation, user manuals, online tutorials, webinars) are created and updated, as necessary.
SD6b	Materials are updated based on users’ review and feedback.
SD6c	Changes to the materials are communicated to help desk support.
SD6d	Written documentation delineating administrator/staff roles associated with the application is developed to guide the transfer of knowledge about the application to new Part C/619 state staff, IT staff, and vendors.

Read More +

Quality Indicator SD7

Part C/619 state staff communicate and work with the IT team to deploy the new database application/enhancement.

about SD7 Elements of Quality

SD7 – Elements of Quality
SD7a	A deployment plan, including guidelines for transition to the new data application/enhancement, schedule for running legacy and new system in parallel, roles and responsibilities, and contingency steps, is created in collaboration with the IT team.
SD7b	The deployment plan is communicated to all necessary parties, including state and local staff.
SD7c	End user support (e.g., training, release notes) is provided for the new application/enhancement.
SD7d	The new database application is deployed, or new enhancement released, in collaboration with IT.
SD7e	The responsibility for the new database application/enhancement is transitioned to the state agency.

Read More +

Resources Related to System Design and Development

Key Considerations for Initiating and Planning a New Data System or Data System Enhancement
This 2021 DaSy brief is an updated version of the 2015 document and presents key considerations in the form of questions that can be used ...
Read more
Part C Data System Functions
This DaSy Part C Data System Functions resource contains a list of Part C data system functions designed to assist in developing and enhancing ...
Read more
Business Requirements Analysis: Clearly Agreeing What You’re Going to Deliver
This is a five step guide to conducting a business requirements analysis. Published by: MindTools.com Business Requirements Analysis: Clearly Agreeing What You’re Going to Deliver
Read more
Building a Better Data System: What Are Process and Data Models?
This DaSy report provides an overview of process modeling and data modeling and explains the value of each in the development or major enhancement of ...
Read more
IFSP Information Toolkit
This DaSy toolkit provides resources to support decision-making for states that wish to develop or enhance an IDEA Part C data system. The toolkit details ...
Read more
Developing and Sharing Your Business Requirements to Build a Better Data System
This DaSy brief follows Key Considerations for Initiating and Planning a New Data System or Major Data System Enhancement and provides Part C/619 staff with ...
Read more
What I Wish I Knew Then: Lessons Learned Designing and Managing State Data Systems
In this DaSy presentation, former data managers share lessons they’ve learned designing and managing data systems based on their own state experience and their technical ...
Read more
Project Management Guidebook: System Development Life Cycle
This 2003 electronic book provides guidance to increase project management competence and foster sustained success for projects. Published by: New York State Office for Technology Project ...
Read more