Cycle 1: Defining the problem
This page provides an
overview of the communication documents required for Cycle 1. Please refer to
the Overview of Design and Communication page for
background on the engineering and communication process in Capstone Design. About
engineering and communication cycle 1 In Cycle 1, you will
begin working together as a team to plan your project and build a shared
understanding of your design problem. Your documents will preserve the
knowledge your group acquires. The documents will also report your initial
work to your manager, sponsor, and other stakeholders, enabling you to set expectations,
gain insights, and reach consensus on your project plans. Graphical
Representation of Cycle 1 in the Design Development and Documentation
Process. Note that not all deliverables are listed- only the primary ones.
See the table below for a complete list of deliverables for Cycle 1. All documents in
Cycle 1 will be due at least twice.
You will compile an initial draft that your manager will comment on and
return to you. While considering this feedback, you will also begin using
some of the initial documents created in Cycle 1 (e.g., the mission
statement) to create other Cycle 1 documents (e.g., the design context
review). A complete set of revised Cycle 1 documents will be due at the end
of Cycle 1. During
Cycle 1, you will begin maintaining a binder containing all of your capstone
design documents. During Cycle 1, you will also begin producing two
sets of documents that you will maintain throughout the course: a binder and
weekly progress reports. Documentation
Management Why you do it Properly documenting and
preserving your design documentation helps your team:
Key Sections of
Team Documentation For the purposes of the
senior design project you will maintain a team notebook, team document binder
and a team SVN site. Instructions for each are listed below. How to prepare
the team notebook This notebook must be a
bound notebook that the team uses to record ideas, brainstorming sessions,
team meeting minutes, etc. All entries must be dated and labeled as in a
laboratory notebook. Care should be taken to date and sign each new idea to
serve as an invention record. How to prepare
the binder You will receive a binder
and a set of tabbed dividers at the beginning of the fall semester. You
should start maintaining the binder during Cycle 1. You will receive a grade
for your binder’s organization and format. Consider the following
tips as you organize your binder:
How to maintain
the team SVN site See this link for a complete description of the SVN
site expectations: SVN
Documentation
Management Grading Rubric Why you do it Engineered products are
defined by their specifications. The specification sheet provides a
quantitative measure of the performance of a product as measured by my
Products that fall out of spec may require warranty repairs. In the real world, spec
sheets can contain many hundreds or thousands of items. This is obviously
impractical for a project that is the result of a capstone course. In this
course you need to submit at least 4 specs in each Design Cycle. How specs work in
this course In this course the majority of team points come from the spec sheet. You will determine, along with your technical mentor or customer, a small number of specifications. You will submit a spec sheet as part of your Design Cycle 1 documents. The spec sheet itself will be worth a small number of points for Design Cycle 1. Then at the end of Design Cycle 2 you will test your project vs. the specs on the spec sheet. The results of the tests will how many team points you are awarded. The same process will
occur in each Design Cycle. Spec sheets submitted in Design Cycle 2 will for
the basis of tests at the end of DC3, and specs submitted in DC 3 will form
the basis of final testing in DC4. Additionally, your team will have the
opportunity to revise the spec sheet due in DC1 and to submit the revised
spec sheet a few weeks later (with new approval from the sponsor if there are
significant changes.) The specs in DC 1 and 2
should not represent the final specs for the project. Instead, they should represent milestones
on the route to your final specs. E.g. in DC 1 you should write specs
covering a few key aspects of a “proof of concept” to be delivered at the end
of fall semester (DC2). Similarly, the spec sheet submitted at the end of DC
2 does not need to encompass every aspect of the final project, although it
should be fairly complete. By the end of Fall semester your team should have
an accurate assessment of realistic project deliverables. In each Design Cycle the
team must obtain the approval of the technical mentor or customer for the
project. The spec sheet should be signed by the team and the technical mentor
or customer. Point
values for meeting specs The spec sheet also
allows the team to allocate their points among the various specs. The majority
of points should be allocated to the most important specs. Less critical
specs, nice-to-have features, etc. should be allocated fewer points. At least
10% of the points for each Design Cycle should be allocated to “stretch
goals” –those that are high-risk. The team and mentor/ customer should
discuss and agree on the allocation of points. The course professors have the
option of changing the point allocation. For instance, suppose a team was
building a web-enabled bread-slicing machine, and that in DC1 there were 1200
points to allocate. The team might allocate 500 points to demonstrating
functionality on a hand-driven bread slicer, 400 points to a basic user
interface on a standalone PC that has a start & stop button, 150 points
to the measurement of the cutting properties of various knives, and 150
points to a mechanism that allows multiple knives to be used simultaneously
(the latter being a stretch goal.) What
if the team discovers they won’t be able to meet the specs committed to in
the previous design cycle? There is always some risk
when committing to achieving definite specs by a particular time. In this
course the commitment happens about 6-8 weeks in advance of the test. A lot
can go wrong in the interim: unforeseen technical roadblocks, unavailability
of key parts, teammates who disappear for a week to work on other classes, or
even just an underestimate of the time required. That is the nature of
engineering in the real world. In the real world, it is sometimes possible to
get approval from the customer on reduced specs, slipping of a schedule or
re-negotiation of costs as it becomes clearer that the original specs/
schedule/ cost were too optimistic. In
this capstone course, the team is allowed to change the spec sheet, including
point allocations, assuming the team can get approval from the customer/
mentors and the professor. Writing
good specs A spec needs to have an
unambiguous way to determine if it is met – an associated test. Sometimes
this is easy because it is purely quantitative and obvious how to measure it:
“Output power > 100 W”, ”Volume < 1 liter” etc. Sometimes a more
“squishy” spec has to be included, such as “intuitive graphical user
interface.” In this case one should try to make the test semi-quantitative,
as in “At least 80% of all users rate intuitiveness 4 or 5 on a scale of
1-5.” In this course you are
allowed to pre-designate “partial credit” for partial achievement of specs.
Sometimes this is done in the real world as well – the design team may have some
incentive bonus based on performance of the product. Consider the following
example: The spec is a 12-lead wireless electrocardiogram system with battery
life of 1 week, worth 500 team points.
The team, not sure if they could hit the aggressive battery spec,
could stipulate 300 team points for achievement of 8 hours of battery life
and the full 500 points if the full spec is met. How to fill out the
First Semester Objectives sheet The First Semester
Objectives sheet is a Word document [ Word
or PDF
] you can fill out. You can generate an equivalent document in LaTeX or Google Docs if you prefer. The first spec sheet
is due in DC 1 and will be graded according to the following rubric. Your
team needs to sign a hardcopy of the First Semester Objectives and get the
signature of their technical mentor or customer of the project. (Approval by
email can suffice if necessary.) You should revise the objectives based on
feedback from the professors and graders. Submit the revision a few weeks
later (see course schedule for details) in order to receive some points back
and to set the objectives that the team will be responsible for at the end of
DC 2. The document will be graded according to the following rubric. (In
general the revised objectives should also be signed by the team and the
customer or mentor.) An annotated example of a
completed First Semester Objectives for Design Cycle 1 is located here. Specification Sheet Grading Rubric Weekly progress reports (tag ups) Why you do it The weekly progress
reports (or tag ups) help your team:
How to prepare
weekly progress reports Weekly progress reports
should be emailed to your course instructor, faculty mentor, your assigned
teaching assistant, your off-campus mentor (if applicable and desired by
mentor). You should confirm with your professor and primary faculty mentor
exactly who should receive the weekly reports. Reports are due every Tuesday
night at midnight (except during winter break and spring break). If your
mentors agree to a different timing for the weekly report, this is
acceptable. Some teams chose to submit their report one day before team
meetings with their mentor. Your report will contain
a short summary of activities completed since the last report, major
successes or accomplishments, problems you have encountered or questions you
have, and the number of hours the team has worked on the design project
during the period covered by the report. A copy of your weekly
update email should also be stored in your team binder in reverse
chronological order. Access a template for
creating reports by consulting Weekly
Progress Report Accelerator #1. See examples of poor and high quality reports by
consulting Weekly Progress Report
Accelerator #2. Team mission statement Why you do it The mission statement
helps your team:
In your academic
coursework, instructors discuss assignments in class, explain them in
detailed handouts or on a website, and assign similar projects each year. In
industry, however, sponsors or managers often charge teams to accomplish a
certain task without such explicit instructions. Managers may not know enough
to provide this detail, or the situation may depend on an array of complex
factors. From the manager’s perspective, it is the team’s responsibility sort
through these details and complexities. In the mission statement,
your team will rearticulate its assignment (or mission) in order to clarify
expectations, both between team members and between your team and your
manager and stakeholders. View annotated mission
statement examples by consulting Mission Statement Accelerator #1.
NOTE: This document will appear as a word document with embedded comments. How to prepare
the mission statement The mission statement is
the first formal document that your team will write. Your goal is to
summarize your task—your mission as a team. Mission statements focus on
introducing your team and the problems or needs that you plan to address. Your mission statement
will have two parts. The first document will be a one-page mission statement
document that includes background on
In addition to the
one-page mission statement, draft a cover letter/email message to project
mentors and sponsors that will accompany your mission statement. If this is
the FIRST time you have contacted your mentors you should explain who you
are, what you are doing, and what you want them do. Within the cover letter
and/or the mission statement itself, you should provide your team name, a
list of team members, team contact information, and a list of team
mentors/sponsors. This message should be only 2-3 short paragraphs. If you
have already met your mentor then you can be less formal about the cover
letter. How to revise the
mission statement Remember that the purpose
of the mission statement is to receive feedback and direction from your manager
and sponsors. You should expect and welcome their insights. The more you can
learn early in the project about what your stakeholders want you to achieve,
the easier it will be to organize and plan your work. Do not simply
incorporate what you perceive as wording changes or grammatical nitpicks.
Think about the questions your manager raises about your document: How has
your writing been perceived? Is it accurate? How can you better communicate
your mission? In addition to revising
your mission statement for the final Cycle 1 deadline, you will also use the
mission statement to help you formulate a specific problem statement while
writing the design context review. Team Mission Statement Grading Rubric Team contract Why you do it The team contract sets
the “rules of work” for your team. You will use the team contract to define
initial standards, expectations, and work practices for your group. The
initial time spent discussing these issues and developing this contract will
help your team work productively and enable you to resolve conflicts that
arise. How to prepare
the team contract Each team will have a
unique way of working together. Some may prefer strict rules, a set
hierarchy, and regular meeting times. Another team may adopt a flexible model
that “outsources” responsibilities to individual team members, who report
back their work to the group. Your contract will define your team’s culture. Write the contract
together as a team. You may need several meetings or online conversations to
develop the document. All team members should sign and date the document and
turn it in for the first deadline. All contracts should
state, at the top, the purpose of the contract (NOT the purpose of your
project, but rather who it applies to, for what reasons, and for how long).
It should then provide information on the following broad categories. The
decisions you make within each category will be personal, but use the
suggestions as a guide to the choices you need to make about how you will
work together.
How to revise the
team contract You will receive feedback
from your manager after handing in the team contract for the first deadline.
Incorporate this feedback into the version handed in at the end of Cycle 1. The
rules set forth in the contract will help you plan the project and allocate
time and resources. Later in Cycle 1, your Gantt chart will reflect the
thinking that went into your contract. Design context review Why you do it Preparing the design
context review helps your team
The design context review
in capstone design serves two primary purposes. First, it ensures that your
team has educated itself thoroughly about the problem your project will solve
and the status of other currently used or proposed solutions. Senior
engineering students must become familiar with the terminology, technology,
physiology, and economics associated with their projects. In addition, they
must often refine vague missions from sponsors into clear mandates that
motivate projects. Writing a design context review requires your team to
locate appropriate source material, sort through background information, and
write a focused document that describes the specific problem you plan to
solve. Second, it improves your
team’s ability to communicate with its audiences—managers, sponsors,
advisors, and others standing to benefit from your project—who don’t need to
know as much as you do. In academic and industry work, a design context
review (also called a literature review) is an essential requirement in
proposals. This review puts you—the student team—in the role of expert and
educator. Your design context review will persuade your audience that a
problem exists. The written review also demonstrates your team’s
understanding of the problem and factors associated with solving it. How to prepare
the design context review The design context review
process consists of five steps:
You will create the
following documents as part of this process:
A comprehensive guide to
writing the design context review, including complete instructions for each
step and accelerators to streamline the task, is available in A Guide to
Writing a Design Context Review in Capstone Design. Revising the
design context review You will receive feedback
from your manager on both the design context map and the draft of the design
context review. The final document submitted at the end of Cycle 1 should
contain a clear problem statement and reflect your team’s assessment of the
need for and significance of your project. As you proceed with
developing a design strategy, your understanding of the problem may change.
You may make it more specific or modify the focus. You seek out new
references to support directions you explore or choices you make in your design.
In Cycle 2, you will modify your design context review to reflect the
background and problem statement driving your proposed design strategy. In
Cycle 3, you will use the design context review as the basis for the
Introduction to your final report. You can find more information on this
assignment and the process of revision in the Cycle 3 overview resource. References Your references prove
that your work is credible and provide resources for readers interested in
exploring more about your work. You will cite all references that you consult
for your design context review (books, articles, expert interviews, etc.) in
the body of your documents and in a single list at the end of your binder.
All references cited in your report should be from credible sources. Be wary
of citing corporate websites or other resources that may contain biased,
non-peer reviewed information. Only a small proportion of your reference list
should come from solely websites. If you cite information from personal
interviews or other communications, please reference them as such. In addition to compiling
your bibliography, note and list any additional general websites or other
resources that were helpful to you and that might be useful to other capstone
design students. Keep this list separate from your bibliography. How to prepare
references Store full bibliographic
information for each reference, following the approproiate
referencing format Annals for Biomedical
Engineering
format: ·
For journal articles:
Last name of first author, followed by initials, initials and last names of
each coauthor. Title of article (first word only capitalized). Name of journal
(abbreviated as in Serial Sources for the BIOSIS Data Base, published by BioSciences Information Service). Volume:inclusive pages, year. ·
For book references:
Author(s) as above. Title of book (main words capitalized). City of
publication: Publisher; year, total number of pages. Example: Thompson, D. A. W. On Growth and
Form. Cambridge: Cambridge University
Press, 1961, 346 pp. ·
For a chapter in an edited book:
Authors as above. “Title of chapter.” In: Name of book (main word
capitalized), edited by initials and last names of editor(s). City of
publication: Publisher, year, inclusive pages for chapter. Example: Glass, L. and A. Shrier. "Low dimensional chaos in the
heart." In: Theory of Heart: Biomechanics, Biophysics, and Nonlinear
Dynamics of Cardiac Function, edited by L. Glass, P. Hunter, and A.
McCulloch. New York: Springer−Verlag, 1991, pp.
289−312. American
Society of Mechanical Engineers
format: (1)
Reference to journal articles and papers in serial publications should
include: ·
last
name of each author followed by their initials ·
year
of publication ·
full
title of the cited article in quotes, title capitalization ·
full
name of the publication in which it appears ·
volume
number (if any) in boldface (Do not include the abbreviation,
"Vol.") ·
issue
number (if any) in parentheses (Do not include the abbreviation, “No.”) ·
inclusive
page numbers of the cited article (include “pp.”) (2)
Reference to textbooks and monographs should include: ·
last
name of each author followed by their initials ·
year
of publication ·
full
title of the publication in italics ·
publisher ·
city
of publication ·
inclusive
page numbers of the work being cited (include “pp.”) ·
chapter
number (if any) at the end of the citation following the abbreviation,
“Chap.” (3)
Reference to individual conference papers, papers in compiled conference
proceedings, or any other collection of works by numerous authors should
include: ·
last
name of each author followed by their initials ·
year
of publication ·
full
title of the cited paper in quotes, title capitalization ·
individual
paper number (if any) ·
full
title of the publication in italics ·
initials
followed by last name of editors (if any), followed by the abbreviation,
“eds.” ·
publisher ·
city
of publication ·
volume
number (if any) in boldface if a single number, include, “Vol.” if part of
larger identifier (e.g., “PVP-Vol. 254”) ·
inclusive
page numbers of the work being cited (include “pp.”) (4)
Reference to theses and technical reports should include: ·
last
name of each author followed by their initials ·
year
of publication ·
full
title in quotes, title capitalization ·
report
number (if any) ·
publisher
or institution name, city Examples: [1] Ning, X., and Lovell, M. R., 2002, “On the Sliding
Friction Characteristics of Unidirectional Continuous FRP Composites,” ASME
J. Tribol., 124(1), pp. 5-13. [2]
Barnes, M., 2001, “Stresses in Solenoids,” J. Appl. Phys., 48(5), pp.
2000–2008. [3]
Jones, J., 2000, Contact Mechanics, Cambridge University Press, Cambridge,
UK, Chap. 6. [4]
Lee, Y., Korpela, S. A., and Horne, R. N., 1982,
“Structure of Multi-Cellular Natural Convection in a Tall Vertical Annulus,”
Proc. 7th International Heat Transfer Conference, U. Grigul
et al., eds., Hemisphere, Washington, DC, 2, pp. 221–226. [5]
Hashish, M., 2000, “600 MPa Waterjet
Technology Development,” High Pressure Technology, PVP-Vol. 406, pp. 135-140. [6]
Watson, D. W., 1997, “Thermodynamic Analysis,” ASME Paper No. 97-GT-288. [7]
Tung, C. Y., 1982, “Evaporative Heat Transfer in the Contact Line of a
Mixture,” Ph.D. thesis, Rensselaer Polytechnic Institute, Troy, NY. [8]
Kwon, O. K., and Pletcher, R. H., 1981, “Prediction
of the Incompressible Flow Over A Rearward-Facing Step,” Technical Report No.
HTL-26, CFD-4, Iowa State Univ., Ames, IA. [9]
Smith, R., 2002, “Conformal Lubricated Contact of Cylindrical Surfaces
Involved in a Non-Steady Motion,” Ph.D. thesis,
http://www.cas.phys.unm.edu/rsmith/homepage.html EndNote, a software
program that manages references in conjunction with common word processing
programs, can be exceedingly helpful in compiling bibliographies. The program
stores bibliographic information and notes. Many references can be
automatically downloaded directly into Endnote from search engines, including
Web of Science and other sourcing systems available through Fondren Library. The software will also convert
references automatically into any one of hundreds of predefined bibliographic
and citation formats. You are encouraged to use this program to manage your
references. Citing references Because your documents
will initially be turned in separately and stored separately in your binder,
you should employ the author date referencing system when citing references.
Include your full list of references in your binder and when citing a reference,
place the author’s last name and date in parentheses following the sentence
you wish to reference. Example: This apparatus is based on the
discovery that applying tension to broken bones causes osteogenesis
and soft tissue regeneration [Ilizarov,
1989]. When you compile your
final report, you will employ the citation format of the Annals of Biomedical Engineering or of the American
Society of Mechanical Engineers. When you cite a reference, you
will assign it a number (the first reference cited is 1, the second
reference cited is 2,
and so on). Your references will appear in a sequentially numbered list at
the end of your document. This is another reason to use Endnote; it manages
the references and automatically reorganizes and renumbers them should you
move text (and associated citations) around in your document. When citing a reference,
remember the following tips:
Design criteria The design criteria
document helps teams develop quantitative, measurable criteria that can be
used to define a successful solution. Your design criteria link the needs,
market forces, and constraints that you researched in the design context
review to measurable objectives and specifications. How to write the
design criteria Your professor has
lectured on procedures for developing quantifiable constraints from
qualitative needs. Please refer to those notes for information on how to
develop the criteria. Format your criteria as a bulleted list or as a table
that maps objectives (for example, durability) to target criteria (for
example, durable over 5 years of use) and outlining methods you will use to
verify that the criteria have been met in your design (e.g., accelerated
exposure test of device to equivalent years of use). Be sure to completely
explain your criterion in a sentence rather than simply listing a concept
such as ‘durability.’ (e.g. The device will survive
a drop test from 5 feet without sustaining significant damage.) Include an
introductory paragraph or two that justifies your choices of criteria and
explains your rationale. How to revise the
design criteria You will receive feedback
on the initial draft of the design criteria document and will revise the
criteria for submission at the final Cycle 1 deadline. The document will be
further revised in Cycle 2 as you articulate your design strategy. As you proceed with
developing a design strategy, the specific criteria that underlie the
strategy may change. Track these modifications and note any revisions or
changes in the version you will submit in Cycle 2. You will also use the
design criteria document to inform your decision matrix/Pugh analyses as you
evaluate ideas for solutions generated during brainstorming sessions.
Ultimately, the design criteria will appear either in the introduction to
your report or as an introduction to your design strategy. For more
information on these choices, please see the Cycle 3 overview resource. Brainstorming/Ideas for solutions Why you do it Brainstorming is a
process for developing creative solutions to problems. It is a wonderful way
to develop a large list of options for solving your design problem.
Brainstorming works by focusing on a problem or subset of a problem and
deliberately coming up with as many solutions as possible. It is effective
not just because team members come up with new ideas, but because it can
enhance existing ideas as they are developed and refined in association with
other ideas. How to develop
your brainstorming/ideas for solutions Your course instructor
has lectured about brainstorming; please refer to your lecture notes for
further information and guidelines on brainstorming techniques. The rules are
summarized here:
Following these rules,
work as a team to create a list and/or drawings of many different possible
solutions to your team’s design problem. You can compile this list by hand,
note ideas on a whiteboard or large piece of posterboard,
or disseminate sheets for team members to scribble on separately. You should
develop at least 15–20
concepts or ideas pertaining to your project. Drawings can be especially
useful for this process. Save brainstorming tools/evidence. For items too
large to put in your binder or notebook, photographs are sufficient. Store the list and
associated figures in the appropriate section of the team binder. If you have
several brainstorming sessions, include all of these results in your team
binder. Revising the
brainstorming/ideas for solutions Decision matrix/Pugh analyses Why you do it Once the team has a
candidate list of ideas to solve their design problem, they must select from
these ideas to finalize their design. A rigorous analysis helps the team make
appropriate decisions about the overall design and the individual components.
How to prepare
the decision matrix/Pugh analyses The candidate solutions
that were developed in your brainstorming sessions should be rigorously
compared to one another using decision matrix analyses, cost analyses, engineering
calculations, environmental analyses, and other factors to ultimately select
the final design option. Examples of how you can complete this analysis were
provided in lecture. The text of this section should help the reader
understand the decisions you made and understand why you selected your final
design option. All the comparisons, analyses, and calculations should be
shown in the final decision matrix document. Revising the
decision matrix/Pugh analyses Your decision matrix and
Pugh analyses will ultimately be described in the design strategy section of
your final report. Gantt chart The Gantt chart helps
your team
A Gantt chart is a common
method used to track project progress. The chart shows every task relevant to
a project with beginning and end dates, responsible parties, and time scales.
You will initially populate the chart using estimates, but as project
progresses, you will update the chart to show actual time spent on duties.
The resulting visual representation of plans and actual work done by your
team will help future sponsors and teams dedicate appropriate resources and
time to subsequent projects.
View a sample Gantt chart
by consulting the example in Gantt
Chart Example. How to prepare
the Gantt chart The definitive software
for project management is Microsoft Project. A simplified and open-access
version called Open Project is available for the capstone design course. Consult Gantt
Chart Example to see how the tips below are used to
create an actual chart.
Web
documentation Your team Web
Documentation will be completed online. You will complete this in stages depending
on the cycle. In order to enter your
information online, you must go to the OEDK website, oedk.rice.edu. Navigate
to Students: Team Profile Form. In this form you will enter details of your
team. The form requests information about your team, your project as well as
team members. Much of the information provided on this form will
automatically appear online as an OEDK team project. Team member names,
personal information or contact information WILL NOT be posted online.
However, your project summaries (after being checked by OEDK staff) will be
public and will count as public disclosure, so you need to be careful about
your word choice. As such you do not need to disclose specifically how you
are solving your challenge. Each Cycle has different
requirements for the web documentation as listed below. Specific instructions
and examples for a few of the sections are included below. Cycle 1:
Cycle 2:
Cycle 3:
Cycle 4:
Cycle 5:
Design Challenge
Entry Expectations: This is a short 3-4
sentence summary of your project. It can borrow heavily from your mission
statement. This will be used to motivate a web browser to look at the
subsequent in-depth description of your project. Example Design
Challenge Entries: Example 1: As much of the world lives in rural communities, physicians are called on to visit areas that are reached by traveling on foot. Travel over rough terrain or a lack of resources such as electricity can further inhibit the doctor’s ability to provide even routine examinations in these rural environments. For a physician embarking on such a trip, gathering the appropriate medical equipment they need into an easily transportable pack is a tremendous challenge. The Lab-in-a-Backpack provides an efficient and cost effective way to deliver quality healthcare to remote areas. Example 2: Our project focuses on developing a high-throughput device so that multiple 3D cell cultures can be levitated in the same multi-well tissue culture plate. By optimizing magnetic field strengths, culture media conditions, and cell line compatibility, we will be able to improve the tools available for rapid and revolutionary in vitro research. Design Summary
Entry Expectations: This is a longer summary
of the current status of your project. There is a 3000 character limit for
this section. It is likely to have many features of your Executive
summary. It should include your approach to solving the challenge. Include
some reference to your goals or design criteria and the current status of
your solution. End
this document with the following: “Last Updated: xx/xx/xxxx”.
|
© Rice University 2006, 2007, 2008, 2009, 2010, 2011