This page was discussed during 7-22-2009 T&L Conference Call
There are three types of requirements gathering that would be useful during the life cycle of the Sakai product:
- 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.
- 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".
- 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.
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
- Start with some type of fundamental learning theory, assessment model, etc. that would be important to support with Sakai (e.g. constructivism)
- Select a functional "theme" to brainstorm around (e.g. student created content, group work, interacting with guest experts, etc.)
- Brainstorm with a group of early adopter faculty at your local institution, record/capture outcome
- Write a narrative that captures the outcomes from the brainstorm (maybe also connect it back to underlying theory)
- If needed/possible, create a "persona" that would represent a composite of the early adopters at your local institution.
- Use Cases
- Start with either an existing tool/workflow or one that is being consider for or already in development.
- Select an instructional theme or objective (e.g. students working on a group project)
- Through interviews/focus groups/brainstorms gather ideas on how the tool/workflow needs to be developed/designed to best support the theme or objective.
- Write a narrative or storyboard that captures the key ideas/outcomes.
- 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)
- Start with an existing tool/early prototype/contrib.
- Collect feedback from users on challenges/problems they encounter using it.
- Develop solutions to challenges and review with users.
- Post JIRAs for those solutions that appear to have consensus support.
- Functional Visions
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.
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).
- Portfolio-related vignettes
- OSP Procedure for Feature Requests
- OSP Feature Template
- OSP-SPEC - Specification Template - Original specification template
- Rough stab at mapping T&L needs to capabilities and functional visioning. Attachment to this page.
<embed flashvars="loc=%2F&autoplay=false&vid=1772665" width="480" height="386" allowfullscreen="true" allowscriptaccess="always" src="http://www.ustream.tv/flash/video/1772665" type="application/x-shockwave-flash" />