Instructions

This template is the vehicle for complying with the OSP Procedure for Feature Requests. Each element of the template is keyed to the step that the element fulfills, in whole or in part. For example, a (1) in the heading indicates that this portion of the template must be filled out in order to complete step 1 of the proposal approval process. The Proposal for Enhancement page you create in Confluence based on this template will provide a locus for community discussion of the enhancement. A primary goal of this process is to capture institutional memory about what decisions were made during the design phase and why.

The Proposal for Enhancements template has two parts, the Functional Description and the Technical Specification. The expectation is that the template will be fleshed out over time as plans for the enhancement develop through community discussion.

Part 1: The Functional Description
The Functional Description should be created before the enhancement is first proposed, usually by domain experts such as instructional designers, educators, or project leads. As much as possible, it should paint a picture of what the enhancement is and what it will allow the user to accomplish. Focus should be on functionality rather than implementation. While the Summary, Rationale, Origin, and User Stories are required before the proposal is presented to the community, diagrams, mockups, and the "Functional Details" and "Interactions and Implications" sections may be added later as the proposal matures.

Part 2: The Technical Specification
The second part of the proposal, the Specification, should be filled out once the feature is clearly defined but before coding begins. While the first part of the proposal should usually be filled out by domain experts, the specification would normally be written by a developer or other technical person.

Please remove these instructions from your document.

Part 1: Functional Description

Finer Grained Document-Level Matrix Permissions (1)

Summary (1)

The proposed functionality will provide shared control at the document level to a group of specific users.

Rationale (1)

The proposed enhancement is a requirement to enable interns to reflect on their hospital training, the difficulties they face in their trainings. They have to fill out forms prepared by a tutor where they can report their reflection on their trainings. The forms are organized in a matrix where columns are trainings and rows are competencies. The proposed enhancement is to allow reviewers to review the forms at the cell level with reviewing permissions at the document level instead of the cell level. Because these reflections can involve other residents and staff members' interaction, the resident wants to ensure that only a restricted group of people can review their reflection. In addition, the reviewers are chosen by the intern and he can remove the reviewing rights at any time. The proposed enhancement ensure confidentiality at the document level in a cell matrix and is a step toward more collaborative work between peers.

Origin (1)

The origin is the Faculty of Medicine at Université de Montréal. The department wishes to foster collaborative learning by sharing and exchanging reflections with other colleagues.

User Stories (1)

Actors and Stakeholders

• Residents: medicine residents, interns.
• Tutors: a person who is a senior resident or a doctor.

Stories

• Invite a group of individuals to review a reflection. As a resident, I want to invite a restricted group of people review my reflection. Only these people will have the right to see that the document exists, to read the document and to comment it.
• Read and comment a reflection. As an invited person, I want to see that the document exists and I want to read the reflection (the content of the reflection), and review the reflection.

Functional Details (may be added after community demo) (1)

The resident who wishes to invite individuals will pick them up from a list of possible individuals. The invited people will only see documents they are granted to review.

Interaction and Implications (1)

A participant can grant reviewing permissions by document (filled form) in a matrix cell. A reviewer can review only the forms that were granted by the owner of the forms.

Diagrams and Mockups (3)

(To be done) Include any ERDs, flowcharts, sketches, mockups, etc.

Community Acceptance (4)

Elements of this enhancement have been raised on sakai-dev@collab.sakaiproject.org and portfolio@collab.sakaiproject.org. Also, during the meeting of Monday 2009-02-03 11 am, we discussed details and that seem to raise interests among participants.

Part 2 of the Proposal for Enhancement Template: The Specification
The specification should be filled out once the feature is clearly defined.

Specification Template (5)

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.

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

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.