• Practice field observation and interview techniques;
• Practice analysis and synthesis of workplace data;
• Apply scenario generation and claims analysis methods to an authentic case;
• Develop and refine skills for working in a group.

You need to identify one or more faculty members to work with as your customer. To do this, you may need to "pitch" your project and convince potential customers that their interests will be seriously considered and addressed in the project. You might also try to interest them in some of the design concepts the project might explore, for example the idea of creating vitual classroom spaces and activities along the lines of the virtual science fair project described in the textbook and illustrated in projects you can invesigate at http://ucs.cs.vt.edu

What to do:
1. Organize and assign roles: This will be the first time your group has worked together, so you will need to investigate one another's skills, interests, schedules, etc. You may decide that individuals will take on different roles for this project. Possibilities include meeting scheduler, interviewer, note taker, scenario writer, claims analyst, technical writer, editor and/or proof reader. Note that although specific tasks may become the prime responsibility of one or more members, all members should be familiar with all of the activities that take place...i.e., stay in touch with each other, use status reports.

2. Brainstorm a root concept, develop field study plan: Your first job will be develop a root concept as described in Chapter 2. This will have a strong influence on the remainder of the project, so think carefully about this. Based on the root concept, you should then develop a field study plan, including a plan for field visits to your customer organization, artifacts you expect to collect, a guide for asking questions, roles each of you will take on, and so on.

3. Collect data from your customer organization:

• Make at least one visit of no less than 30 minutes to collect field notes, photos, etc.
• Conduct an in-depth interview of your contact person. Find out as much as you can about this person's role(s) and tasks in the organization as well as those of other stakeholders (for example, students and departmental staff). Also find out about the technology now in use (or not), the different stakeholders' technology background, and so on.
• Collect at least three artifacts from the customer that are revealing with respect to current activities. These might be photographs of key aspects of a physical location, records of transactions, print-outs of data or other information, brochures or other media, etc. (If the artifact is three-dimensional, take a photo of it or make a drawing so that it can be turned in with your report.)

4. Summarize your field data:

• Write a description of the stakeholders for your project. List each stakeholder group that you have identified and summarize their responsibilities, their relationships to other stakeholder groups, and their technology background. This can be done in a table format.
• Describe the three different artifacts that you have collected, indicating for each what it conveys about the information or procedures of the organization. This can also be done as a table; see the examples in Chapter 2.
• Develop three different hypothetical stakeholders that you will use as actors in your scenarios. At least two of these actors should come from different stakeholder groups.

5. Synthesize problem scenarios and claims: Using your observations, interviews, collected artifacts, and summary analyses as source material, develop six problem scenarios, two for each of the actors described as hypothetical stakeholders. Each scenario should have a brief but evocative name.

These scenarios should have a realistic feel to them (i.e., they should be believable), but need not be based on actual episodes observed or described to you. The point is to write scenarios that best convey what you have learned about the current situation. Remember that it is OK (often essential) to include multiple actors in a scenario, but the story is told from one actor's perspective. Remember also that these are problem scenarios, so they should have nothing to do with any online tool or environment you think you might design in the next phase.

Analyze 1-2 claims for each scenario. As discussed in Chapter 2, a claim may express issues associated with multiple scenarios. This is fine -- again, the point is to document what you think are the most interesting or critical features of the current situation, along with your analysis of these features' upsides and downsides. Indicate with underline, font color, or other text formatting the piece of the narrative that gave rise to each claim. Each claim included should have at least one positive consequence and one negative.

Use the VSF examples of scenarios and claims in the book and those in the case study library as examples for how to write scenarios and claims.

6. Prepare your requirements analysis report: The requirements reports should have the following labeled sections. Number all pages that follow the Table of Contents to make the report easier to browse and review.

1. Cover Sheet: label the phase as "Requirements Analysis", and include group number, team member names and student numbers, and due date
2. Table of Contents: list page numbers for each required element
3. Overview: a 1-2 page introduction to this phase, introducing your customer, summarizing the requirements analysis process, and previewing the online tools/environment you will be designing in the next phase.
4. Preparing for the Field Study: the root concept, interview guide(s), as well as any other documents produced in planning the field work
5. Field Data: notes from your interview, photographs or other artifacts collected as part of the field work
6. Field Data Summaries: stakeholder descriptions, artifact descriptions (refer back as necessary to the actual artifacts in the previous section), hypothetical stakeholders
7. Problem Scenarios and Claims: the six scenarios. Each scenario should be given an evocative name. The claim(s) analyzed for each scenario should follow the scenario, i.e. resulting in an interleaved ordering of scenario/claim(s).
8. Bibliography: cite any sources (printed matter or the Web) you used in preparing your analysis. This does not include the textbook, so this section is optional and is only needed if you did use another source.

Grading: The project will be evaluated for overall completeness, as well as the quality of each component, using this evaluation form.