This page was discussed during 7-22-2009 T&L Conference Call

A Community Process for Requirements Gathering (Strawman)

There are three types of requirements gathering that would be useful during the life cycle of the Sakai product:

  1. Functional Visions - These would be stories that would capture, at a high level, innovative teaching and learning strategies (grounded in teaching and learning theory/research) that could be facilitated by Sakai.  They would be tool/technology agnostic "pie-in-the-sky" narratives who's goal would be to provide a "functional target" at which future development could be aimed.  The ultimate goal would be to get teaching, learning, and research needs out ahead of development efforts.  Functional Visions would be used most often during the "R&D" and "Incubation" stages.
  2. Use Cases - These would be more specific descriptions of how users want/need to use particular tools or workflows that would cut across tools/capabilities.  Although teaching/learning/research (TLR) focused, they would be more practical in nature and more grounded in usability practices then teaching and learning theory.  Use cases might be used most often during the transition from "incubation" to "development".
  3. Requirements - These would be at the "nitty gritty" level and would be focused on near-term improvements to existing capability.  The might range from purely usability issues (e.g. button is poorly located) to more functional issues (e.g. instructors need to be able to edit this item after it is released).  Requirements would generally be dealt with in the product development and maintenance stages.

Process Planning Brain Dump

Overall I'm imagining a two tiered process that would start at the local level and feed up into a larger community effort.   We could work to establish point contacts at institutions who were responsible for implementing these three types of "requirement gathering" activities.  These would help folks to identify local needs.  The outcomes from local efforts would then feed into (how we do this I don't know) a community effort that would need to synthesize the information and develop some type of community "vision".  An approach of this nature would also allow us to create a network of folks who were involved in this type of work...such a group could be of great value to the community and product.

An important component to this process would be the dialog and interactions between those collecting and surfacing these visions, cases and requirements and the developers that would be working on them.  I feel that we need to create some type of communication process that helps facilitate such dialogs.

An Alternative

I (John) find intriguing the approach being taken in the portfolio group to allow thinking to develop without technology prejudice; they are identifying verbs (assess, grade, create, display) that capture 'essential' (as in essence) processes and then planning to build out from there. If we can identify the right words and capture useful meanings across institutions without going bland, it could be very valuable. A lot of "ifs" there but worth considering I think.

I (David G.) agree that these fundamental needs, expressed in simple everyday language, are anchors for what we hope Sakai might support. Those fundamental needs can lead to very complex scenarios.  For example,  starting with "I want my students to receive feedback on their performance or progress"  I see that in Sakai 2 the instructor can add a simple text note to a grade, can add a rich-text comment and attachment to an assignment, can send a message to an individual student.  Instructors have already asked for broader capabilities (some of which are available in selected Sakai tools) -- the ability to make a private comment on authored content and the ability to comment on a collection of artifacts.  Even more broadly, one could see supporting instructor feedback, self feedback, peer feedback, feedback from someone outside the class, outside the system, outside the institution; see the need for unstructured as well as structured feedback; structured feedback may be defined by the individual, the instructor, the program, the department, the campus; and so on.  Despite the complexity, it's still important to understand the fundamental need of providing feedback.
[Update] I've added an attachment to this page which is a very rough attempt at describing in plain language some basic T&L needs, current touchpoints in Sakai 2, basic and expanded capabilities, and short descriptions of complex cases and pie-in-the-sky thinking (i.e., functional visioning).

References to other work

Video from Sakai Boston