Capstone Project Wiki

System Refinement approval is granted when the desirability and transferability of the design meet the minimum requirements for the end of System Refinement. The purpose of the System Refinement review is to answer the questions, “What is the complete system design?” and, “How well does the system meet the Key Success Measures and other requirements?” In preparation for the System Refinement review, the team will submit a draft of the Final Design Report. The desirability and transferability are evaluated by a careful review of the draft submitted by the team, followed by the System Refinement design review. After the review, the team will revise the Final Design Report and submit the final version by the due date listed in Learning Suite.

At the review, the team will give a short presentation that includes the Project Objective Statement and a summary of the full system design and its evaluation. Following the presentation, the reviewers and the team will discuss the desirability and transferability of the design. Suggestions for improvement will be considered. The objective of the review is to strengthen the design by finding and making plans to remove any weaknesses present.

The Report and the review should demonstrate that the design has evolved enough to meet the requirements for the end of System Refinement. The artifacts should address the issues listed below. Satisfactorily addressing these issues constitute the minimum requirements for completion of System Refinement.

The final submission of the Final Design Report should explicitly reflect feedback given by the sponsor after the Final Design Presentation.

You should deliver the final version of the Final Design Report to your sponsor in PDF form and/or printed form, as desired by your sponsor. Ask them what they would like. If they would like a printed version, use your CAEDM group account to print it, and use the spiral binding system in the Capstone office to bind the report.

NOTE: No reimbursements will be given for printing or binding charges. You should use CAEDM and the Capstone office to accomplish these functions.

See Checkout Clearance for information on the printed documents that are required for checkout.

The purpose of the Final Design Report is to answer the questions, “What is the complete system design?” and, “How well does the system meet the Key Success Measures and other requirements?” The Final Design Report is a single PDF compilation containing the following:

1. A Final Design Report title page
2. A Table of Contents listing the Executive Summary and all of the included artifacts, but with no page numbers for the artifacts. The PDF compilation must have bookmarks for each of the Table of Contents entries. See Formatting for an easy way to make these bookmarks. Individual artifacts should have page numbers. The page numbering of each artifact should start at 1.
3. The Executive Summary. See the next section for more information.
4. PDF copies of each of the Primary Artifacts, as listed below. Primary artifacts need not contain all of the details needed to reproduce the work, but should cite Supporting Artifacts that do contain these details.
5. PDF copies of each of the Supporting Artifacts for the review, as listed under the review questions. Supporting Artifacts will be evaluated by the graders only when they have questions they would like to answer.

All PDF files included in the package must be searchable for text, meaning they must not be scanned documents

The artifacts in the Final Design Report should be thoughtfully arranged in order to facilitate rapid access and understanding.

The Final Report should contain every artifact necessary to understand your project. It is expected that most of the artifacts previously submitted for the Subsystem Engineering Review will be included in the Final Design Report for your Project. The artifacts should be updated to reflect the current state of the design.

New writing for the Final Design Report will focus on the Executive Summary, the Written and Visual Description of the Design, and the Performance Summary for the system.

In previous years, a signature page was required with signatures of each team member. That document is no longer required.

The Executive Summary is a two-page summary of the results of your design work. In addition to text, the summary may contain a few key figures and/or tables that best show your work. Detailed figures and tables should be in the individual artifacts.

The primary audience for the Executive Summary is the management team for the sponsor. It is not the liaison for your project; it is the managers of your liaison. The Executive Summary should stand on its own and inform the management team of the progress on your project, without reading any of the artifacts. However, it should be consistent with the artifacts and make it easy for management to know which artifacts to peruse to get more information. Because it is so short, you should be concise and clear. Carefully consider what the target audience will want to know, and present that information as clearly as possible.

The Executive Summary should summarize the following topics:

• Introduction: Appropriate (brief) background of the project. Indicate why the project is important. Share your project objective statement. Indicate the key success measures for the project.
• Brief description of design: Briefly describe the design in words and with appropriate top-level pictures. The description should not be a detailed definition. The detailed definition is found in the artifacts. The description should provide an overview of the design that will make it easy for the reader to understand the details found in the artifacts. Refer to appropriate design artifacts as needed.
• Summary of final performance: Summarize how well the design has been demonstrated to perform, compared with the key success measures and perhaps other important requirements. Summarize available market response data. Summarize the kind of tests that were performed with prototypes or engineering models to measure or predict the performance. Refer to appropriate testing and analysis artifacts as needed.
• Conclusion and recommendations: Holistically evaluate the desirability of the design based on the evidence present in the Executive Summary and the artifacts. Make recommendations for resolving any issues that have shown up in your testing. Discuss the next steps that the sponsor should take to move the product forward to release.

The artifacts and the review should answer the questions, “What is the complete system design?” and, “How well does the system meet the Key Success Measures and other requirements?” Satisfactory answers to these questions constitute the minimum requirements for completion of System Refinement.

• Written and visual description of design, including relevant subsystems and/or block diagrams. Note this is a high-level, rather than detailed, artifact. It is more likely to contain renderings or flowcharts than engineering drawings.
• Performance summary for the system, which refers to supporting artifacts as needed
• System requirements matrix or Software Requirements Specification. For a System requirements matrix, include measured and/or predicted values for performance measures (refer to supporting artifacts as needed) and values for the market response (refer to supporting artifacts as needed)

• System Design Package (including refined Bill of Materials and/or Software Bill of Materials). Pay close attention to the details described on pages 98 -- 100 of Product Development. This package should be complete and detailed enough that an independent production system could produce your design.
• Up-to-date approved PSA, revised as necessary
• Test results obtained using models and/or prototypes. Pay special attention to Figure 1 (Figure 2.12 in the textbook) as you consider the test results needed. Note that you will need validation testing (not just performance testing) for System Refinement approval. (Validation testing refers to the response to your product you obtain from market representatives, which may include your sponsor.)
• Definitions of models and/or prototypes used in testing
• Test procedures that were used to obtain the results listed above
• Computer files used in the testing work
• Other detailed artifacts that support assessing the performance of the system

Figure 1: The stage approval process. Performance testing and artifact checking are always done as part of approval. Validation is always done at System Refinement and is often done at Concept Development (the Architecture Review). Validation is often not done at Subsystem Engineering, because the subsystem prototypes are not usually accessible for the market to evaluate.

The Final Design Report will be reviewed for how clearly and completely it answers the questions above (evaluation of transferability). The system design and tests presented in the Report will also be reviewed for their quality.

The rubrics used in the evaluation is shown below. There are different rubrics for hardware or mixed projects and software projects. Discuss with your pod instructor which rubrics you will use.

The scoresheets used by the evaluators are available on Box for hardware or mixed projects and for software projects.

Evaluation rubric for Final Design Report

Evaluation rubric for Final Design Report on Software Projects

The mechanics of the System Refinement Review (and Final Design Report submission) are as follows:

1. No later than 10:00 AM three class days (not counting weekends or holidays) ahead of the scheduled review, the team submits the Final Design Report, as described above. The submission is done from the Capstone dashboard. The evaluating coaches and the pod instructor will receive an email when the submission is completed. If the submission is late, the evaluating coaches will not provide a grade for the initial submission.
2. No later than 8:00 AM one class day (not counting weekends or holidays) ahead of the scheduled review, the two coaches who are assigned to evaluate the submission will complete their grading and written evaluation of the Final Design Report. These evaluations will be available for download from the Capstone website team summary page. If the initial submission was late, grades will not be available, and the written evaluations may not be available before the review.
3. The team prepares an oral presentation no more than five minutes in length that includes the project objective statement and discusses why the team believes the architecture is ready for approval, including responses to the evaluator comments where appropriate.
4. At the System Refinement Review, the team will make their brief presentation and demonstrate prototypes used to test the performance of their final design.
5. The reviewers, the team, and the coach will discuss the answers to the questions as contained in the Final Design Report and the presentation for 18 minutes. Weaknesses in the answers or the report will be explored, and recommendations for improvement will be given.
6. After consulting with the evaluation coaches, the instructor will spend two minutes to communicate the results of the review to the team. Possible results are:
   • Stage approval is granted unconditionally. When approval is granted, the team can choose to allow the existing grades to stand and let the initial submission serve as the final submission. Or the team may choose to make a revised submission as described below.
   • Stage approval is conditionally granted, subject to the team making some required revisions. The team must clear the revisions with their pod instructor before approval is granted. The team presents the revised submission directly to the pod instructor for approval. After receiving approval, the team submits the revised submission on the Capstone website.
   • Stage approval is denied. The team will need to improve their work, schedule a new review, and return to step 1.
7. When the team has received stage approval, they have completed all required Capstone approvals.
8. If the approval was conditional, the team must submit a revised copy of the Final Design Report after the revisions are approved. The revised submission is due at 11:59 PM on the last day of classes for the semester. If no revised submission is received by the deadline, the team will receive a grade of zero for the stage.
9. If approval was unconditional, the team may submit a revised copy of the Final Design Report to improve their grade. The revised submission is due at 11:59 PM on the last day of classes for the semester. If no revised submission is received by the deadline, the grade on the initial submission will be used.
10. A revised submission must include the following:
    • A memo summarizing the changes to the Final Design Report, and indicating how these changes are responsive to the feedback received. This memo should not include copies of the changed artifacts; it should just be a memo.
    • A final copy of the revised Final Design Report.
      We ask for these items to facilitate the work of those who must evaluate the resubmission.
      The revised submission will be graded by the same two coaches who graded the initial submission, and the grades will replace the initial grades.
11. The average of the two coaches' scores will be the final grade for the stage. However, if the difference in the coaches' scores for the stage is greater than or equal to seven points, the instructor will also grade the Final Design Report, and the median of the three scores will then be recorded as the final grade.

The final submission of the Final Design Report should explicitly reflect feedback given by the sponsor after the Final Design Presentation.

The Final Design Report should be formatted according to the instructions in Artifact Formatting.

If your sponsor requires a bound printed report, follow the additional instructions in Formatting Printed Reports.

You should deliver the Final Design Report to your sponsor in PDF form and/or printed form, as desired by your sponsor. Ask them what they would like. If they would like a printed version, use your CAEDM group account to print it, and use the spiral binding system in the Capstone office to bind the report.

Examples of Final Reports from previous Capstone teams can be found in the Box folder under Class Documents > Examples > W.6 Final Reports. These are given as representative good examples, but are not perfect.