Requirement Levels

The sections that follow contain guidelines for Ed-Fi API designs and implementations. Certain key terms have specific meanings in these guidelines. From this point forward, key terms are italicized when used with the specific meanings shown below:

• Must, required, shall. These terms indicate an absolute requirement for an aligned Ed-Fi API implementation.

• Must not, shall not. These terms indicate an absolute prohibition for an aligned Ed-Fi API implementation.

• Should, recommended. These terms indicate that there may be valid reasons to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

• Should not, not recommended. These terms indicate that there may be circumstances when a particular behavior is acceptable or useful, but the full implications should be understood and the case carefully weighed before implementing such behavior.

• May, could, optional. These terms indicate items that are truly optional. One organization may choose to include the item because their specific implementation requires it or because they feel it enhances the implementation, while another organization may omit the item. Client applications must be prepared to interoperate with an implementation that does not include the option, although perhaps with reduced functionality. In the same vein, a client who does include a particular option must be prepared to interoperate with another implementation that does not include the option.

• Aligned. An aligned implementation meets all the "must, required, shall" requirements of these guidelines, and avoids the "must not, shall not" prohibitions.

Language for this section has been adapted for use from Key words for use in RFCs to Indicate Requirement Levels. This document conforms to the guidelines provided there.