Reference Guide on Requirements and Specifications
Overview
Read the following information to understand how to craft strong use case requirements and specifications.
Overall, because interoperability projects are by their nature at the “heart” of a school district or other education organization, the requirements can differ significantly as the source systems and desired outputs differ. An interoperability project focused on easily transporting transcript information as students migrate will look very different from an interoperability project seeking to unify a district’s Student Information System (SIS) and Northwest Evaluation Association (NWEA)’s Measures of Academic Progress (MAP) data to correlate attendance with assessment results.
At the same time, interoperability projects have threads of common work and a similar project lifecycle.
Below are some examples of verbiage from Request for Proposals (RFPs) that you may find helpful for your project or any upcoming Request for Proposals your school or district issues.
- SFUSD Ed-Fi Implementation RPF
- West Ada Ed-Fi Implementation
- Indiana University INSITE Ed-Fi Implementation RPF
- UCF Center for Community Schools Ed-Fi Implementation
- UConn Ed-Fi Planning RFP
Read the full article here.
PROJECT BACKGROUND
This project is a district-wide initiative that pairs with a system consolidation effort that was already underway. As the district sought to reduce duplicative systems, they wished to implement Ed-Fi to unify data from those systems for downstream use. In some cases, system consolidation would involve procuring a new system, so the district was able to consider built-in Ed-Fi support as a potential requirement. The project did not envision bi-directional data flow, where some data systems would read from the Ed-Fi API.
KEY PAGES
The following table summarizes key pages in the RFP document that may be most relevant to you.
| Page(s) | Description | Commentary |
|---|---|---|
| 10 | Goals | The district communicates the “why” behind the project. Including this information can help the implementing team identify additional things to propose or new ways to accomplish the requirements that align even more with your desired outcomes. |
| 11-13 | Three-Year Roadmap | The district had a multi-year vision to prioritize and integrate systems related to their use cases. This was developed with the help of a consultant with Ed-Fi implementation experience. The roadmap is ambitious overall, which is why they properly planned on a three-year project timeframe. Even if your project is smaller in scope, it can be helpful to outline where interoperability could go in your district over a longer timescale, as early decisions can be made in a way to bring you closer to that long-term desired outcome. |
| 14 | Data Vault | The district wished to develop a new data warehouse using the Data Vault 2.0 data warehousing methodology. This is a very specific requirement that focuses on the “how” rather than the “what”. Focusing on the “what” may allow implementation partners to propose solutions that your team did not imagine, but could be superior. However, if your team has a strong preference, as the team did here, it is important to include that preference; otherwise, a subset of your options will end up discarded simply because the respondent did not predict an unstated requirement. |
| 24 | Evaluation Criteria | The evaluation criteria should reflect your relative priorities. Are you seeking the most experienced vendor to minimize project risk, or are you comfortable with risk of a less experienced vendor if it lowers the cost? Does the project management approach matter to you, or do you focus on the delivery and leave the method open? This example criteria does not communicate priorities, as it lists many things and there is little differentiation in the weighting. |
Read the full article here.
PROJECT BACKGROUND
The district was seeking to unify data and process it through a custom or commercial off-the-shelf data quality solution to improve data quality. The RFP also cites a desire to store the data over time in a data warehouse, though the district already had a data warehouse that it intended to keep. One objective of the district was to create a solution that addresses Idaho-specific data sources and state reporting needs so that the solution could be shared with other Idaho districts with fewer resources. The RFP document is difficult to understand, because it specifies requirements in multiple sections, as noted in the Key Pages table.
KEY PAGES
The following table summarizes key pages in the RFP document that may be most relevant to you.
| Page(s) | Description | Commentary |
|---|---|---|
| 16-18 | Project Purpose, Vision, & Goals + Requirements | This section does outline the purpose of the project. However, it also quickly goes to requirements in the third paragraph. Some of these requirements are not found elsewhere in the document. We recommend having a unified description of scope. |
| 19-21 | Requirements | This section outlines the scope that must be delivered in the project. However, as noted, there is scope not listed here that is described in other sections. We recommend having a unified description of scope. |
| 22-23 | Use Cases + Requirements | It’s important to outline the use cases served by the scope, and this section documents these use cases. However, it’s important to be clear about which use cases will be fully accomplished by the scope and which are predecessor steps or partial work towards a use case. For example, it’s not clear whether the Roster Verification Use Case is additional scope, accomplished by existing scope, or something that will be fully accomplished once district staff complete a downstream step. To avoid confusion, use cases should clearly map to the scope outlined to be delivered (pages 19-21 and/or 25-28, in this case). |
| 25-28 | Requirements | This section also outlines scope that must be delivered in the project. Some of the scope overlaps with pages 19-21, and some of it does not. In isolation, this section is the clearest description of what scope is expected. However, as noted, there is scope not listed here that is described in other sections. We recommend having a unified description of scope. |
| 29-30 | Requirements | This section, called “Key Vendor Activities”, lists additional scope that must be delivered in the project. We believe the district saw these as distinct because they did not produce a specific document or code output to deliver. We recommend considering what output could be produced, or simply stating the scope but noting no output is expected, in order to have a unified description of scope. |
| 30-34 | Requirements | This section, named “Detailed Requirements”, contains a table of specific requirements attached to various pieces of scope expected to be delivered in the project, as well as some general requirements that are not attached to a specific scope item. These details may be useful to you as you identify your own specifications. This format works better for product solutions where evaluators are attempting to make apples-to-apples comparisons of long feature lists. For interoperability projects, we recommend noting all requirements within the unified description of scope. |
| 39 | Evaluation Criteria | The evaluation criteria does an adequate job of communicating relative priorities. It could be improved by having fewer categories, such as “Use Case Solutions (50pts)” to make it more obvious that the most important thing to the district is the extent to which proposals fulfill the use cases outlined on pages 22-23. |
Read the full article here.
PROJECT BACKGROUND
The Indiana University’s School of Education is building an Indiana K-12 district collaborative to support stronger outcomes for Indiana students, while providing a way for K-12 districts to opt-in to providing their data in anonymized form for School of Education research purposes. Each participating district will have a separate Ed-Fi ODS and Ed-Fi Dashboard Data Store, hosted by the University.
KEY PAGES
The following table summarizes key pages in the RFP document that may be most relevant to you.
| Page(s) | Description | Commentary |
|---|---|---|
| 7 | Project Goals | This section outlines the goals of the project. It does also mix in a description of technical scope, which is better left to other sections. |
| 7-8 | Requirements | The 2.0 Scope of Work for the Systems Integrator and 3.0 Additional Requirements sections outline the technical architecture requirements and also the expectations of what’s included in the proposed services. This latter part is useful to avoid surprise change orders for items you expected to be performed, perhaps as a normal course of system development, but the vendor did not include. |
| 8-10 | Requirements | The sections numbered 3.1 through 3.5 actually contain the requirements for the bulk of the deliverables that are in scope. The RFP does a good job of staying consistent with the scope briefly listed in section 2.0, but it is safer and less confusing to vendors if scope is listed once in a unified form. |
| 10 | Support Requirements | The RFP outlines a desire for long term support from the vendor. The RFP also previously mentions a lot of knowledge transfer and training deliverables in section 3.4. The University may be uncertain about whether it wants to take over long term support or continue with vendor support, and price may be a factor in a future decision they make. Without an explanation, it may be confusing to vendors what the goal of the knowledge transfer is since a significant knowledge transfer curriculum seems in conflict with a desire for six years of support from the vendor. This could lead to the vendor underestimating the amount of knowledge transfer desired or underestimating the level of support desired. |
| 11 | Evaluation Criteria | This section explains briefly the factors that will be considered as proposals are evaluated. The RFP does not communicate the relative priority of these factors, and it doesn’t commit to the list of factors being comprehensive. We recommend a concise table of evaluation criteria with relative weights using a numerical system adding up to 100 total points. |
Read the full article here.
PROJECT BACKGROUND
The higher education institution is sponsoring a multi-district collaboration supported by Ed-Fi based infrastructure. Collaborations like this can provide economies of scale, as the common threads of work for interoperability are done once and shared. Generally, collaborations like this only work if the use case(s) are also shared and the data sources are the same or similar. In this case, the use case centers around an Early Warning and Response System. You’ll notice that the RFP focuses primarily on the visualization layer and does not speak to the data sources involved, which forced vendors responding to make assumptions in order to develop a plan, budget, and timeline.
KEY PAGES
The following table summarizes key pages in the RFP document that may be most relevant to you.
| Page(s) | Description | Commentary |
|---|---|---|
| 6 | Purpose | This section does an adequate job of outlining the purpose of the project. Ideally, it would have included information from page 8 listing the schools that make up the collaboration. It also would have been helpful to calculate the approximate student count served by the collaboration. |
| 6-7 | Requirements | This section contains a brief explanation of the scope to be delivered in the project. As noted in the background, discussion about data sources is omitted, forcing implementation vendors to make assumptions about the number and type of data sources. Overall, you will notice that the description of scope is limited compared to other RFP documents. We would recommend additional specification around data sources, environment (e.g., cloud), architectural considerations (e.g., one database or one per district), and data quality considerations. |
| 12-13 | Evaluation Criteria | The evaluation criteria communicate the institution’s priorities well. In this case, the institution is favoring approach and technical experience over cost and experience specifically in education. |
Read the full article here.
PROJECT BACKGROUND
This project involves only a planning phase, and implementation is not in scope. This approach can make sense if your district is uncertain about what should be contained in an implementation RFP. Indeed, for some implementations, there can be a “chicken before the egg” problem, where you need expert input before knowing what to ask of an expert for implementation. In these scenarios, asking an expert to help with planning can be helpful.
KEY PAGES
The following table summarizes key pages in the RFP document that may be most relevant to you.
| Page(s) | Description | Commentary |
|---|---|---|
| 3-5 | Requirements | This section represents a unified list of scope expected to be delivered in the project, as well as a preview of scope that may be requested in subsequent phases. The bulleted list of planning deliverables is largely in sequential order. There is the appearance of some overlap between the early deliverables and the content of the detailed final report. We would recommend being more clear about the content that should be replicated in the final report, versus what content is new and distinct. Failing to do this may result in a vendor assuming the report is all new work, thus inflating the budget. |
| 10 | Evaluation Criteria | The evaluation criteria in this RFP does an excellent job of clearly stating the relative priorities. There are only three evaluation categories: They are distinct, the point spread between them is large, and they sum to 100 (making it easy to understand the relative weighting of each component). |