Child pages
  • A Community Process for Requirements Gathering
Skip to end of metadata
Go to start of metadata

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.

  • We may want to discuss different processes for each of the three types of requirement gathering noted above, this might go something like:
    • Functional Visions
      1. Start with some type of fundamental learning theory, assessment model, etc. that would be important to support with Sakai (e.g. constructivism)
      2. Select a functional "theme" to brainstorm around (e.g. student created content, group work, interacting with guest experts, etc.)
      3. Brainstorm with a group of early adopter faculty at your local institution, record/capture outcome
      4. Write a narrative that captures the outcomes from the brainstorm (maybe also connect it back to underlying theory)
      5. If needed/possible, create a "persona" that would represent a composite of the early adopters at your local institution.
    • Use Cases
      1. Start with either an existing tool/workflow or one that is being consider for or already in development.
      2. Select an instructional theme or objective (e.g. students working on a group project)
      3. Through interviews/focus groups/brainstorms gather ideas on how the tool/workflow needs to be developed/designed to best support the theme or objective.
      4. Write a narrative or storyboard that captures the key ideas/outcomes.
      5. If needed/possible, create a "persona" that would represent a composite of the users.
    • Requirements (this is mostly what we do today, IU has a well established and successful model for this)
      1. Start with an existing tool/early prototype/contrib.
      2. Collect feedback from users on challenges/problems they encounter using it.
      3. Develop solutions to challenges and review with users.
      4. Post JIRAs for those solutions that appear to have consensus support.

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

  • No labels


  1. I imagine that  "functional visions" can include  descriptions of teaching strategies such as Just-in-Time Teaching and roll-playing activities.

  2. I like the term "Functional Vision", although I worry about the implication that this might be focused on "pie in the sky" situations. From instructors (researchers, students) I think we really need simple descriptions of what they do (or would like to do) in their classroom (lab, dorm). This descriptions should, as much as possible, not contain descriptions of particular technologies. Stealing a piece of Ken Romeo's description of a language learning class to provide an example:

    I prepare two short (30 sec) audio clips of news or some other natural speech, along with a transcript for each. I put students into two groups and give each group one of the transcripts and a pair of scissors and tell them to cut out 15 words to make a fill-in-the-blanks listening exercise for the other group. When they are done, they exchange cut-up passages and listen to each passage once or twice (as a group) and try to fill in the blanks (as a group). The object of the activity is for them to try to figure out what is difficult to hear in natural speech (function words and reduced forms). (

    I think this is what you mean by "Functional Visions" but am not sure. Daphne Ogle called these User Scenarios on list at some point. We should agree on terminology but I don't really care what the terms are as long as we use them consistently.
    In any case, This is a rich description in language anyone can understand. Translating it into functional requirements for Sakai 3 will be a complex process, but I think this kind of information is critical to the design process. We can begin to abstract this information into functional requirements and interaction designs. And we can test those designs against these descriptions. We may not support all of them, but the exercise will stretch our thinking in the right way.

  3. I want to caution against the mapping of various kinds of requirements to the Sakai Development stages. Design and development is likely to be iterative and each stage of project maturity is likely to benefit from all three kinds of requirements as described.

    I would propose, though, that the existence of a variety of types of requirements be a community requirement for a project graduating from incubation stage.