EPICS User Centered Des Doc Template V1

8/11/2019 EPICS User Centered Des Doc Template V1

1/20

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]





2/20

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/20


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/20


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/20


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:

Statusis 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
https://sharepoint.ecn.purdue.edu/epics/teams/Public%20Documents/EPICS_Design_Process.pdfhttps://sharepoint.ecn.purdue.edu/epics/teams/Public%20Documents/EPICS_Design_Process.pdfhttps://sharepoint.ecn.purdue.edu/epics/teams/Public%20Documents/EPICS_Design_Process.pdfhttps://sharepoint.ecn.purdue.edu/epics/teams/Public%20Documents/Project_Management_Document_Template.docxhttps://sharepoint.ecn.purdue.edu/epics/teams/Public%20Documents/Project_Management_Document_Template.docxhttps://sharepoint.ecn.purdue.edu/epics/teams/Public%20Documents/Project_Management_Document_Template.docxhttps://sharepoint.ecn.purdue.edu/epics/teams/Public%20Documents/EPICS_testing_document_template%20-%20draft.docxhttps://sharepoint.ecn.purdue.edu/epics/teams/Public%20Documents/EPICS_testing_document_template%20-%20draft.docxhttps://sharepoint.ecn.purdue.edu/epics/teams/Public%20Documents/EPICS_testing_document_template%20-%20draft.docxhttps://sharepoint.ecn.purdue.edu/epics/teams/Public%20Documents/EPICS_testing_document_template%20-%20draft.docxhttps://sharepoint.ecn.purdue.edu/epics/teams/Public%20Documents/EPICS_testing_document_template%20-%20draft.docxhttps://sharepoint.ecn.purdue.edu/epics/teams/Public%20Documents/Project_Management_Document_Template.docxhttps://sharepoint.ecn.purdue.edu/epics/teams/Public%20Documents/Project_Management_Document_Template.docxhttps://sharepoint.ecn.purdue.edu/epics/teams/Public%20Documents/EPICS_Design_Process.pdfhttps://sharepoint.ecn.purdue.edu/epics/teams/Public%20Documents/EPICS_Design_Process.pdf


6/20


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/20


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 identi fi ed

appropriate EPI CS project that meets

a compell ing 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/20


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/20


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 identi f ied theright need, specif ication document is

completed and no existing commercial

products meet design specif ications.

[This includes their agreeing that you

have captured and documented the

cri tical requirements and specif ications

for thi s project - see below.]


Advisor approval:


10/20


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, How you made decisions, and

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/20


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/20


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 solu tion space

has been appropriately explored and

the best solu tion 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/20


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 nextPhase. 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/20


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

feasibi l ity 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/20


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 inthe 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/20


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 EPICS Admin agree that

project is ready for deli very!


Advisor approval:

Summary of Phase 5

In text form, with supporting tables and figures, describe:

What was done,

How you made decisions, and 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/20


18/20


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 fi elding 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/20


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/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.

If details are contained in external Design Records, then the summary should describe themain 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!

Date post:	02-Jun-2018
Category:	Documents
Upload:	nhan-vo
View:	232 times
Download:	0 times