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:
- 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".
- Tool Requirements - These would be at the "nitty gritty" level and would be focused on near-term improvements to existing tools. 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). Tool requirements would generally be dealt with in the "maintenance" stage.
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
- 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.
- Tool 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.