The Summary is required and should describe the feature in one or two brief sentences using the plainest, most unambiguous language possible. Good requirements are written as imperatives, using words like "must", "may not", etc. The Summary should make it obvious that this specification embodies one feature only.
Explain, in objective terms, why this feature is a requirement. Avoid abstract or subjective claims.
If the requirement is based on a specific institutional use case, identify the institution(s) and if possible, contact individuals. Provide a brief description of the conditions that generate the use case.
Indicate how this feature has been discussed by the larger community (e.g., list discussion, specific meetings, etc.). Provide specific records of community acceptance (e.g., list institutions and contacts who also identify this feature as a requirement).
Describe each specific behavior of the feature in the present tense as if the feature were implemented perfectly. Use precise, objective language to describe ideal behaviors against which actual behaviors can be evaluated.
In the case of conditions and behaviors that must be evaluated independently, they should be presented in a two-column table as below.
(Short description of mutually exclusive condition #1)
(Objective, verifiable behavior in response to condition #1)
(Short description of mutually exclusive condition #2)
(Objective, verifiable behavior in response to condition #2)
When there are workflow behaviors (steps) that must be evaluated in sequence, they should be identified with prerequisite conditions, behavior, and post-behavior conditions as below.
(Unique, short, representative name of the step)
Prerequisite Conditions or Step:
(Conditions or Step name)
(Objective, verifiable behavior)
Post-step Conditions or Next Step:
(Conditions or Step name)
List any entities or actors that are used or affected by this feature. Each should link to an entry in the OSP Terminology page.
Describe any non-functional requirements of the feature, such as usability, performance, or design. Provide objective and, where possible, quantitative measures against which actual implementations can be evaluated.
Provide any assumptions about implementation path, availability of other required features, schedule concerns or otherwise.
The Outstanding Issues section is a placeholder for the evolution of this specific feature. It should mention any explicit design or implementation decisions that are pending. There must be no outstanding decisions as of the confirmation of the feature as a requirement.