Child pages
  • OSP-SPEC - Specification Template

Specification ID:

OSP-SPEC-#

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 should be one or two sentences that provide a verifiable overview of the feature.  Since the description is of a requirement, it should be written as an imperative.  Complex conjunctions or conditions indicate that either the summary is too complicated or that the feature is not cohesive.  This section is normative and required .

Rationale

The Rationale should indicate, in objective terms, why this feature is a requirement.  Intangible, subjective claims should be excluded or explicitly qualified.  This section is informative and required .

Origin

In the case of a requirement being delivered on behalf of a specific institutional use case, the institution(s) and possibly contact individuals should be identified, along with a brief description of the conditions and a note of acceptance by the community as a whole-group requirement.  In the case of no explicitly identified institution, the date and conditions of community acceptance should be noted.  This section is informative and required .

Behavior

The Behavior section must indicate all objective, verifiable behaviors of the feature.  Each description should be written in the present tense as if the feature were implemented perfectly.  Each actual behavior must be verifiable as accurate or deficient according to the description.

In the case of conditions and behaviors that must be verified independently, they should be presented in a two- column table as below.  When there are workflow steps that must be verified in sequence, they should be identified with prerequisite conditions, behavior, and post-behavior conditions.

This section is normative and required .


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)

 

Workflow Steps

Step Name:

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

Quality

The Quality section should indicate any fitness conditions for verification of non-functional requirements, such as usability, performance, or design.  Any of this fitness conditions should be objective or numerical, rather than subjective.  This section is informative and optional.

Assumptions

The Assumptions section should indicate any assumptions about implementation path, availability of other required features, schedule concerns or otherwise.  This section is informative and optional .

Outstanding Issues

The Outstanding Issues section is a placeholder for the evolution of a specific requirement.  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.