Objectives
- To identify the requirements for your project.
- To become familiar with data gathering and requirements analysis
methods.
What To Do We are following up from Assignment 5. Before you start the following,
please check for comments from the instructor and students on how
you might improve the data gathering plan you outlined in that
assignment.
- Conduct the data gathering activities that you planned
in Assignment 5.
- It is up to you to decide how many stakeholders to
involve in interviews, focus group, questionnaires,
or naturalistic observation, but keep in mind our
guidelines that more than one representative of each
stakeholder group is desirable.
- I recognize that
you may not be able to get to all stakeholder groups,
but try your best. I expect to see group projects
reach more stakeholders than individual projects,
because there are more of you to do the work.
- You
may find that you need to revise your plans as
you learn more about needs. For example, you
might do some initial interviews and then revise
a questionnare based on issues uncovered
in the interviews. You might also uncover additional
needs while doing part 2 below.
- Perform data analyses based on the
data you gathered.
Every
group should do the following (which summarizes the data,
and then answers key questions about the users and the task
to be supported):
- Summary of the data gathered. For example,
if you did interviews or a focus group, what were the key
points raised? If a questionnaire, describe the statistical distribution
of responses
for
each question.
If you did naturalistic observations, what were the salient
features of the workplace and activity that you observed?
This will potentially provide input to all types of requirements
(data, functional, environmental, user, usability).
- User Model: capture relevant characteristics
of your users with either the structured User
Role Form from
UCD, or with textural descriptions of typical fictional users
as in
SBD. This will provide your user requirements.
- Task Model: capture the nature of the task
to be supported with either Essential Use Cases or a Hierarchical
Task Analysis (your choice). This will provide your functional
requirements.
- Claims Analysis: What features of the current
situation are desirable and should be kept? What features
are problematic? Record them in the Claims
Matrix form. Also,
if features of potential technology solutions were discussed
in your data gathering, record them and their pros and cons
here. This potentially informs all types of requirements.
Groups of more than one person should also add at least one of these
analyses (your choice). Groups and overachieving
individuals shooting for an "A" are also welcome to add more!
- Artifact Analysis: What information is captured in the artifact?
What does the use of the artifact tell you about the nature
of the task to be supported? Informs
data and functional requirements.
- Dataflow Analysis: How is data transformed by processes? This represents
functional requirements.
- Data Model: Use Entity-Relationship diagrams or other suitable format
to catpure data requirements.
- Problem Scenario: this is another way of ensuring you have
understood the situation. Based on the fictional users you
invented, write stories describing how they currently try
to carry out the task to be supported, and the problems encountered.
(Don't mention your planned solution yet.)
- Additional Task Modeling: Essential Use Cases or Hierarchial Task
Analysis if not used above (functional requirements)
- Share your analyses / models with users and revise. As I've repeatedly said in class,
part of the value of the various notations and representations we are using is to initiate
and support conversations between designers and users. These representations are externalizations of
what you think the system should do: share these with some of the stakeholders and discuss
whether you agree on the requirements they imply.
- Identify and document your requirements using
the Requirements
Template format (fields are described in
the text).
- You will make one copy of this template for each
requirement.
- Be sure to have at least one requirement in each of the categories
discussed in the text (Functional, Data, Environmental, User, Usability).
- All
of these, especially the Usability requirements, should include measurable criteria
by
which you tell whether you have succeeded. (Give it your best shot; we'll refine
this when we cover the evaluation chapters.)
- The Origin of these requirements will
be a reference your data from step 1 above (notes from interviews,
focus groups, or naturalistic observation); while others will reference the represntations
you created in step 2 above (user
role
models,
use cases, scenrios, etc.).
What To Turn In As before, document your work in web pages on your project site.
I suggest that you have a page called Requirements
Analysis, and then link from this page to the various documentation,
which should include pages for the following:
- Summary of the data gathered. This page in turn could link
to the raw data collected. (Please remove personal names and
information for
confidentiality.)
- User Model
- Task Model
- Claims Analysis
- Other analyses added (for larger groups)
- The Requirements: This page will have a subsection for each
category of requirement (data, functional, environmental, user,
usability).
Under each category, provide links to pages stating the requirements
(one page per category, based on the Template).
The Origin field of these requirements pages in turn link to
the foregoing analyses
or data as needed.
As usual, this material should
be presented in a professional manner, as if you were preparing
documentation for management
and for colleagues on the design and implementation team. Submit the link to the main Requirements Analysis page to disCourse
as usual, and then comment on other projects' work.
Due 3/14
Pau |