Requirements Definition
The User and Domain Analysis Part 1 document described the outcome of the Research and Modeling phases of the Goal Directed Design process.
The third phase in this process is Requirements Definition, which will become Part 2 of the analysis. This isn't requirements in the sense that developers mean it, but follows these five steps
- Creating a Problem and Vision Statement
- Brainstorming
- Identifying persona expectations
- Constructing Context Scenarios (see Fluid page on Scenarios)
- Identifying Requirements (data and functional requirements)
The Problem and Vision statements are below. Steps 2-5 (described in detail below) were done in meetings in March with a few people who participated in the earlier research phase. The context scenarios and requirements are captured below.
The first column describes the stages of working with learning activities. That link captures some notes, including why we chose to write scenarios for the selected persona. In general, we tried to start with a persona who would have typical scenarios. If certain persona had unique aspects to their situations, we wrote additional scenarios for them.
The subsequent columns are the scenarios for each persona. Not every persona has a scenario for every stage. In some cases, it's because the persona doesn't participate in all stages (Amanda doesn't teach, Terry doesn't grade), while in others, it's because their needs in that stage are covered by others. We are still looking to see if we have missed unique needs persona we haven't written about. As much as possible, we tried to be task agnostic in our descriptions of what the persona was doing to meet the needs they had in their scenario. That is we didn't describe the exact tasks. Once we have a design, we will describe key path scenarios that describe users clicking buttons or using pulldown menus but we are intentionally staying high level.
When you view a persona's scenario for a particular stage, you'll see the requirements we pulled out of them.
Instructor Scenario Matrix
|
||||||||
|---|---|---|---|---|---|---|---|---|
Course Planning (Scheduling and weighting activities) |
n/a |
n/a |
|
|||||
Activity creation(3/15, activity specific) |
n/a |
n/a |
n/a |
|
||||
Deploying and administering |
n/a |
|
n/a |
|
|
|
||
Reviewing submissions, giving grades, scores,feedback (3/8, cross activity and activity specific) |
n/a |
|
|
|||||
Reviewing question, problem set, class stats |
|
|
|
|
|
to come |
to come |
|
Student
Area |
Mike |
Fiona |
Gita |
Evan |
|---|---|---|---|---|
1. Assignment overview(cross-activity) |
|
|
|
|
2. Assignment detail (activity-specific variations) |
|
|
|
|
3. Grade and Feedback overview(cross-activity) |
|
|
|
|
4. Grade and Feedback detail(activity-specific variations) |
|
|
|
|
1. Problem and Vision Statement
Problem and vision statements should come from the research and modeling phase. The problem statement describes the situation that must change for the persona and the community providing the product to the community.
Problem statement
Instructors and students have to manage multiple tools for different assignments in their class or classes. Often these tools are outside the CMS, which offer them flexibility but also additional management burden. They communicate about the assignment separately (announcing it, asking and answering questions about it), meaning information about an assignment loses its context. When an activity can't be described, answered, or graded with simple text or a button selection, instructors and students must use external applications and/or print/scantheir work to create or complete an assignment. Instructors have separate process for managing related offline activities, even when they could benefit from using online tools to manage their learning activities.
Vision statement
To create unified creation, deployment, and access to all learning activities by
- Giving instructors and students a common view across activities and classes to help them plan, direct their attention, and improve.
- Planning for peer involvement and adjustments in deployment
- Integrating communication into the context of the assignment
- Making it possible/easier to create and submit assignments that require rich text or multimedia expression directly online
- Allowing offline activities to take advantage of online capabilities.
2. Brainstorming
While it's best not to develop a preconception of what a solution looks like, and simply write context scenario, it's sometimes hard not to think of solutions. Brainstorming is a way to get these early ideas out of your head, even if it's only to let them go
3. Identifying persona expectations
What is the mental model a persona has about the work they are doing (as opposed to the way the system is actually implemented)? What attitudes, experiences, aspiration and other factors influence their expectations. What behaviors do they expect or desire of the product, how do they think about basic elements or units of data? For reference, here's a table of photos; full background on each persona can be found in the User and Domain Analysis Part 1 document.
4. Constructing context scenarios
These are high level stories rather than descriptions of the detail of the user's interactions. They are entirely textual, as opposed to keypath scenarios, which step through designs. It is important that they not represent the behaviors of current systems. In fact, one should pretend that the persona is using magic---this is a good way to focus on goals, rather than tasks.
5. Identifying requirements.
Once we have the context scenarios, we can extract the needs of that persona for data and functions (objects and actions in context)