EPICS User Centered Des Doc Template V1

EPICS - [Enter semester and year, e.g.
Spring 2010]
User Centered Design -
Reference Document
Version - , Date -

Team -
Project -

Semester, Year (repeated for successive semesters)
Project Partner Contact
[Enter Project Partner's Name]
[Enter Project Partners Address]
[Enter Project Partner's Telephone]
[Enter other contact information if
necessary]
Project Team Members
[Enter Team Members Name, and email address]

Project Specification Document

2

[One-paragraph summary of the project]

Current Semester - Document Change History
Changed by Nature of Changes Date Version No.

List of Design Records
No. Phase Author(s) Date Title
Team-Proj-DR#

Design Record List:
This is just a list or table of all the design records referenced in this document. The design
records should also be referenced as "pointers" in the tables for appropriate sections of the
design report.
Definition: A design record is a small report outlining the development of some aspect of
the design. These are where the meat of the design should be documented. Students will
produce design records to document decisions, procedures, research, user analyses,
results of testing, and feedback on prototypes as well as the designs for components of the
final project.
These records should be out on SharePoint under a folder for this project, and possibly
subfolders like for the gates in the process, as the project sees fit.
The recommended format is as follows:

3
File name like "team-project-phase-DR#"
Title page containing:
o Name of design record (i.e. Design of A-weighting Filter)
o Authors
o Date
o Team/Project
o Summary of the information contained in the design record
Content:
o Description of the purpose of the design record
o Detailed description of the design, decision, research, procedure, etc.
o Results/Conclusions

Table of Contents

Design Record List: ................................................................................................................... 2
References for the points in all the tables below, and in the associated discussions: ................ 5
Legend for the columns in each table: ....................................................................................... 5
Cross-cutting concerns for each Phase: ..................................................................................... 6
Phase 1: Project Identification Phase ......................................................................................... 7
Project Charter ................................................................................................................... 7
Summary of Phase 1 .......................................................................................................... 8
Details of Phase 1............................................................................................................... 8
Testing, Prototyping and User Interfaces for Phase 1 ........................................................ 8
Phase 2: Specification Development Phase ............................................................................ 9
Requirements and Specifications ..................................................................................... 10
Summary of Phase 2 ........................................................................................................ 10
Details of Phase 2............................................................................................................. 10
Testing, Prototyping and User Interfaces for Phase 2 ...................................................... 11
Phase 3: Conceptual Design Phase ....................................................................................... 12
Summary of the conceptual design .................................................................................. 12
Summary of Phase 3 ........................................................................................................ 12
Details of Phase 3............................................................................................................. 13
Phase 4: Detailed Design Phase ............................................................................................ 14
Design Report .................................................................................................................. 14
Summary of Phase 4 ........................................................................................................ 15

4
Details of Phase 4............................................................................................................. 15
Phase 5: Delivery Phase ........................................................................................................ 16
Summary of Phase 5 ........................................................................................................ 16
Details of Phase 5............................................................................................................. 16
Phase 6: Service / Maintenance Phase ..................................................................................... 18
Summary of Phase 6 ........................................................................................................ 18
Details of Phase 6............................................................................................................. 18
Phase 7: Retirement or Redesign .......................................................................................... 20
Summary of Phase 7 ........................................................................................................ 20
Details of Phase7.............................................................................................................. 20

Figure 1 - EPICS Design Process


5
References for the points in all the tables below, and in
the associated discussions:

[1] EPICS_Design_Process.docx, at
https://sharepoint.ecn.purdue.edu/epics/teams/Public%20Documents/EPICS_Design_Process.
pdf.

[2] Service-Learning: Engineering in Your Community, by Marybeth Lima and William
Oakes. Copies available on reserve, in the Purdue Engineering Library.

[3] Project Management Document Template, p 4, at
https://sharepoint.ecn.purdue.edu/epics/teams/Public%20Documents/Project_Managem
ent_Document_Template.docx.

[4] Draft of EPICS Testing Document Template, at
https://sharepoint.ecn.purdue.edu/epics/teams/Public%20Documents/EPICS_testing_do
cument_template%20-%20draft.docx.

Legend for the columns in each table:
Status is so that people reading this document know what's done and what isn't. It helps
them find the things which are ready to look at. So, this aids in your team discussion and
for review by everyone (project partners, advisors and TA's, and outside reviewers).

Examples of Status entries:

Blank = not worked on yet.
"In progress", with expected completion date
"Complete", with date
"N/A" = not applicable (the next column should explain why)

Pointers are one or more entries telling the reader where to look for information about how
you did this, and the resulting knowledge. These pointers can be:

The subsections of this document that most relate, or
External references, as appropriate, such as to Design Records


6
Cross-cutting concerns for each Phase:
In support of your EPICS design work, during each phase documented below you also should
be considering the following three topics:

Testing
Prototyping
User Interfaces

We have included reminders about these topics in some of the tables describing activities for
the phases. There are additional reminders in the discussion following each table.


7

Phase 1: Project
Identification Phase
Status Pointers
Goal is to identify a specific, compelling need to be addressed [1, p 3]
Conduct needs assessment (if need
not already defined) [1, p 3]

Identify stakeholders (customer,
users, person maintaining project,
etc.) [1, p 4]

Understand the Social Context [1, p
4]

Define basic stakeholder
requirements (objectives or goals of
projects and constraints) [1, p 5]

Determine time constraints of the
project [1, p 5]

Gate 1: Continue if have identified
appropriate EPI CS project that meets
a compelling need for the project
partner [This includes a Project
Charter - see below]
Decision: Rationale summary:
Advisor approval:

Project Charter
This can be the same passage in your Project Management document. It summarizes the
needs of the project partner and defines the scope of the project.
See Project Management document template [3], p 4, for a description of the charter.


8
Summary of Phase 1
For all the items described in the above table for this phase, you should describe in text
form, with supporting tables and figures:
What was done,
How you made decisions, and
The results
Details of Phase 1
If details relating to this Phase then follow the summary, these sections should all have
some identifying header, so they can be referred to in the table, above.

If details are contained in external Design Records, then the summary should describe the
main conclusions of that activity. For example, if you did an interview with your Project
Partner to determine the Community Context, then you could at least give a sentence or
two in this summary, highlighting the main findings of that.

The importance of duplicating the Project Charter here is to be sure that the current version
of this charter is in synch with the design work you are doing.
Testing, Prototyping and User Interfaces for Phase 1
While you want to be focused on user needs here, and not pin down a solution, it is certainly
possible to test the needs you are hearing about, from the stakeholders, by making a
drawing or a simple paper prototype, and asking, "Is this the kind of thing you are asking
for?" People often give additional information about their requirements when they see
something to contrast those requirements against.

9

Phase 2: Specification
Development Phase
Status Pointers
Goal is to understand what is needed by understanding the context, stakeholders,
requirements of the project, and why current solutions dont meet need, and to develop
measurable criteria in which design concepts can be evaluated. [1, p 5]
Understand and describe context
(current situation and environment) [1,
p 5]

Create stakeholder profiles [1, p 5]
Create mock-ups and simple
prototypes: quick, low-cost, multiple
cycles incorporating feedback [1, p 6]

Develop a task analysis and define
how users will interact with project
(user scenarios) [1, p 6]

Identify other solutions to similar
needs and identify benchmark products
(prior art) [1, p 6]

Define customer requirements in more
detail; get project partner approval
[1, pp 7-8]

Develop specifications document [1, p.
9]

Establish evaluation criteria [1, p 8]
Gate 2: Continue if project partner and
advisor agree that you have identified the
right need, specification document is
completed and no existing commercial
products meet design specifications.
[This includes their agreeing that you
have captured and documented the
critical requirements and specifications
for this project - see below.]
Advisor approval:


10
Requirements and Specifications
Probably most importantly, this design document needs to have a set of customer
requirements and other specifications upon which your design is going to be based, or else
it must point to where a complete set of such specs can be found.

This is a list or table of the specifications that the project must meet. An example
of a list of customer specifications, in a preferred format, is on p 8 of [1]. While this
example is much shorter than the list you will end up with, it shows how to categorize specs
so that they are easy to refer to while you are designing your solution.

Specifications must be measurable, and define WHAT the project must to do to meet the
need. This is a living document that may be edited in later phases and should be used to
guide the development of the project.
Summary of Phase 2
In Phase 2, generally, you should describe things related to each topic in the table, above,
in text form, with supporting tables and figures, describe:
What was done,
The results
In this phase, an example of a result expected to be shown here would be a list of
key user-oriented requirements for the product or service that would solve the
Project Partner's problem.
Details of Phase 2
Again, if details relating to this Phase follow the summary, these sections should all have
some identifying header, so they can be referred to in the table, above.

main conclusions of that activity. For example, if you wrote-up a discussion of other
solutions to similar problems, or competing products, then these would be pointed to in the
table, above. However, you could add a couple sentences in the details here, about your
major findings from that.


11
Mockups and simple prototypes are strongly recommended as a part of this phase. Most
often, these relate to the design of user interactions - something users can play with and
react to. For testing, a goal should be that you write your requirements in a way which
clearly sounds like it could be tested. E.g., "The learning appliance will withstand a drop of
3 feet onto a linoleum floor." This clarity makes it easy to write "acceptance tests" later.
(These are tests that show you met the requirements and specifications.) Before long,
you will want a table of these key tests, so that you can "design to the tests" in creating
your solution.


12

Phase 3: Conceptual
Design Phase
Status Pointers
Goal is to expand the design space to include as many solutions as possible. Evaluate
different approaches and selecting best one to move forward. Exploring how. [1, p 12]
Complete functional decomposition
[1, pp 10-11]

Brainstorm several possible
solutions [1, p 11]

Prior Artifacts Research [1, p 12]
Create prototypes of multiple
concepts, get feedback from users,
refine specifications [1, p 13]

Evaluate feasibility of potential
solutions (proof-of-concept
prototypes) [1, p 13]

Choose "best" solution [1, pp 13-17]
Gate 3: Continue if project partner
and advisor agree that solution space
has been appropriately explored and
the best solution has been chosen.
[Docs should include a summary of
your conceptual design - see below.]
Advisor approval:

Summary of the conceptual design
This is a description of the overall design concept including any sketches and constraints.
Summary of Phase 3
As before, in text form, with supporting tables and figures, describe:
What was done,
The results

13
In this phase, an example of a result expected to be shown here would be a picture
of the overall solution, with a text description explaining how it solves the project
partner's problem.
A second example would be a list of the key features of your design, and a brief
summary of what you've done to show proof of concept for those.
Details of Phase 3
As before, these sections should all have some identifying header, if they are referred to in
the table, above.

main conclusions of that activity. For example, if you did some research on "prior art" in
the patent world, and the documents related to that are elsewhere, you could summarize
the main findings of that research.
Creating "proof of concept" prototypes is strongly suggested here. In addition to testing
user interactions, they also could verify things like whether a certain overall approach
breaks down into useful, smaller chunks which could be designed bottom-up in the next
Phase. E.g., if our Soap Box car carries two people rather than one, can we still use the
same design approach that they used for steering, brakes, etc., for a one-person car, and
expect sufficient reliability?

Testing: By the time some design work is started, you also should begin inventing the
tests that your design must pass. The first phase of this is creating a "test plan." For an
example of what should be in a test plan, please see the Test Plans section, in our draft of
an EPICS Testing Document Template [4].


14

Phase 4: Detailed
Design Phase
Status Pointers
Goal is to design working prototype which meets functional specifications. [1, p 17]
Bottom-Up Development of
component designs [1, p 17]

Develop Design Specification for
components [1, p 18]

Design/analysis/evaluation of
project, sub-modules and/or
components (freeze interfaces) [1, p
18]

Design for Failure Mode Analysis
(DFMEA) [1, pp 18-24]

Prototyping of project, sub-modules
and/or components [1, p 24]

Field test prototype/usability testing
[1, p 24]

Gate 4: Continue if can demonstrate
feasibility of solution (is there a
working prototype?). Project Partner
and advisor approval required. [Docs
should include a Design Report - see
below.]
Advisor approval:

Design Report
This is a detailed report which fully describes the design. For physical projects, this would
include a full set of drawings and a bill of materials and description of the components. For
software projects, a full copy of the code with comments, references with supporting
documentation.

As before, these things may all exist in other documents, which you point to from here.

15
However, they should all be easy to get to and, overall, they should cover all the crucial
aspects of the design.

For example, the Bill of Materials normally is kept on a spreadsheet, and you could reference
where that is from here. See [2, p 66] for details on this particular artifact.
Summary of Phase 4
As before, in text form, with supporting tables and figures, describe:
What was done,
The results
In this phase, an example of a result expected to be shown would be an example of
a strategic interface, and briefly how it will cause two different parts of the design to
work properly together.
Another example would be a highlight of the DFMEA analysis, and how your design
avoids that failure scenario.
Details of Phase 4
As before, these sections should all have some identifying header, if they are referred to in
the table, above.

Again, if details are contained in external Design Records, then the summary should
describe the main conclusions of that activity. For example, if you had all your DFMEA
data in a separate file, you could highlight the major conclusions here.
Prototyping of sub-modules and components is common in this phase, as noted in the
table, above, and discussed in [1]. Acceptance testing and field testing are used to verify
user interfaces with real users. See our draft of an EPICS Testing Document Template [4].


16

Phase 5: Delivery
Phase
Status Pointers
Goal is to refine detailed design so as to produce a product that is ready to be delivered! In
addition, the goal is to develop user manuals and training materials. [1, p 24]
Complete deliverable version of
project including Bill of Materials
[1, p 24], [2, 66]

Complete usability and reliability
testing [1, p 25]

Complete user manuals/training
material [1, p 25]

Complete delivery review [1, p 25]
Project Partner, Advisor, and EPICS
Admin Approval [1, p 25]

Gate 5: Continue if Project Partner,
Advisor and EPI CS Admin agree that
project is ready for delivery!
Advisor approval:

Summary of Phase 5
In text form, with supporting tables and figures, describe:
What was done,
The results
a results from usability testing, showing what advantages your solution has for a
group of users.
Details of Phase 5
These sections should all have some identifying header, if they are referred to in the table,
above.

17
main conclusions of that activity. For example, if you have testing details in separate
documents, you could just summarize those.
Usability and reliability testing are an art form, which require that one come close to
duplicating the environment of real use. See [1, p 25]. Testing as a part of delivery also
includes introducing the real product into the user environment, training users and
administrators (who changes the batteries? etc.), and observing, documenting and
correcting problems. Careful documentation is important to be able to list and prioritize
known problems.


18

Phase 6: Service /
Maintenance Phase
Status Pointers
See [1, p 26]
Evaluate performance of fielded
project [1, p 26]

Determine what resources are
necessary to support and maintain
the project [1, p 26]

Gate 6: Project Partner and Advisor
approve continued fielding of project.
I f not, retire or redesign.
Advisor approval:

Summary of Phase 6
What was done,
The results
a observation of your product or service being used in the field, with key advantages
and issues you saw.
Details of Phase 6
above.

main conclusions of that activity.

19
Evaluating the performance of a fielded project [1, p 26] is crucial as a step toward fixing
any problems and also in designing new projects so as to avoid these same problems.
Thus, the audience for documenting these things includes following semesters of students.

20

Phase 7: Retirement or
Redesign
Status Pointers

Redesign [2, p 69]
Retirement/Disposal [2, p 70]
Gate 7: (Possibly the Pearly Gate) Decision: Rationale summary:
Advisor approval:

Summary of Phase 7
What was done,
The results
In this phase, an example of a result expected to be shown would be a conceptual
description of a redesign which might lead to an improved solution.
Details of Phase7
above.

main conclusions of that activity.
The decision to redesign or retire often is based on observation of the condition of the
existing product being used, and reports of the users on what has happened to it. Good
documentation of these facts leads to the best decisions!

EPICS User Centered Des Doc Template V1

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

EPICS User Centered Des Doc Template V1

Uploaded by

Copyright:

Available Formats

EPICS - [Enter semester and year, e.g.

You might also like