Requirements and Specifications Template

Overview

In this section you will draft requirements and specifications for your district’s use case. The needs you define at this point, and the priorities you attach to them, will be used during the next phase of the overall process: implementation planning.

Functional requirements can be inserted into each of the requirements identified in your Needs Assessment. They should describe how a product will work entirely from the user’s perspective.

A functional requirement states in detail what exactly the interoperable solution should be expected to do (rather than what your district should be able to do).

It is recommended that details related to current processes and systems be included in the functional requirements. This should cover the type of information the systems are responsible for managing as well as a high-level description of the processes and procedures utilized by the users to maintain the data. 

Because the integration technology will change these processes and procedures by streamlining the flow of information, it is critical that all of the user’s current responsibilities are well understood.

The functional requirements should be developed with direct alignment to the requirements. It should describe the characteristics or functions to be carried out within the data integration. Include all of the information that you feel comfortable with; but don’t feel like you must include everything.

Read more about defining requirements by reading this article from the SIF Implementation Planning Toolkit. This is also located in your resources folder.

Next, watch the following video by the Ed-Fi Academy about categories of requirements. Keep in mind the video references a workbook specific to Ed-fi Academy and is not the same at the Data Readiness Module workbook.

• Identification Number: Each major requirement should be assigned a unique identification number. If there are related sub-requirements, assign those a sub-number (i.e. 3.1.1).
• Description: As you describe each requirement, make sure they are concise and written in such a way that they can be used to test against.
• Priority: Based upon the requirement conventions, assign a value to each requirement. Those statements containing the terms “shall” or “must” are hard requirements and must be met. Requirements that are desirable but not mandatory will contain the term “should.”
  • Equity Highlight: Priority identification for subgroups within specialized populations are highly encouraged. For example, students in more restrictive settings vs. students in inclusion settings; disaggregated data for English Language Learners indicating levels 1-4)
• Procedural Impact: If the requirement involves changing policies or procedures, this should be noted here. This will be important because these must be in place and documented prior to deployment. 
• Acceptance Plan: To make sure the statement is concise enough to be measurable, describe what user expectations would be to indicate that this requirement has been fulfilled. 
• Source(s): Identify where the requirement came from. This may be an individual, group, or external source. It’s important because additional questions may come up later and you will want to follow up with the appropriate individuals.
• Rationale: The supporting rationale for each requirement should be described here. If it is not understood why a need exists, it’s likely the solution may not satisfy it correctly. 

Example