Child pages
  • OSP-SPEC - Specification Template
Skip to end of metadata
Go to start of metadata
This page contains macros or features from a plugin which requires a valid license.

You will need to contact your administrator.

Specification ID:

OSP-SPEC-# or OSP-SUGGESTION-# (until confirmed)

Working Title:

(Representative, short title of the feature)

Related Issue(s):

(JIRA issue numbers as links)


(Sakai / OSP components where the feature is implemented)

Confirmation Status and Date:

Status: (Suggested, Pending, Confirmed)
Date: (Date of Status declaration)


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.

Community Acceptance

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.

Workflow Steps

(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.

Quality Metrics

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.

Outstanding Issues

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.

  • No labels