OSP-SPEC - Specification Template

Owned by Former user (Deleted)
Last updated: Dec 08, 2010Version comment
2 min read

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)

Component(s):

(Sakai / OSP components where the feature is implemented)

Confirmation Status and Date:

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

Summary

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.

Rationale

Explain, in objective terms, why this feature is a requirement. Avoid abstract or subjective claims.

Origin

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

Behavior

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.

Conditions

Behavior

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

Behavior:

(Objective, verifiable behavior)

Post-step Conditions or Next Step:

(Conditions or Step name)

Interaction

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.

Assumptions

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.