CS486 – Capstone Design
Final Project Report

Overview: The purpose of the Final Project Report is to summarize all of the salient features and history of the project. Sometimes it is confused with the "as-built report"; this is not strictly accurate. The as-built report can be seen as a section(s) of the final report. That is, the final report summarizes the as-built info -- but is much more than just that. So to be clear:

as-built report: provides a detailed description of your final design. It is the final evolutionary outcome of your design process. So you did:

proposal (requirements) --> functional spec --> detailed design (v1,v2,..vn) --> as-built report.

A coherent format will include a brief one paragraph intro saying which project this report is for, briefly reviewing the sponsor and problem overview. It then gives brief review of the fun. specs, overviews the architecture, then gives detailed info on how you actually implemented the thing. This is basically the complete and detailed "blueprints" for the house you actually built (as opposed to what you planned to build starting out). The as-built report should appear as a separate section near the end of your project notebook.

Final Project Report: This is an independent document that reviews the highlights and history of the project. Everything in it is a summary (!!), not the gory details. The final report should answer the question "What was this project about, how did it develop, and what were the outcomes". The audience here is some corporate V.P. or technical auditor that wants a comprehensive post-mortem on this project. You should tell the whole "story" of the project from start to finish, with appropriate detail throughout. This is a separate deliverable, but would be good to include as either the very first or very last section of your project notebook.

The following is a list of suggested sections to be included in your Final Project Report:

Team Overview --- Lay out . Then overview

Problem Statement - Here you present a brief summary of how the project came to be:

• Who the sponsors are,
• what their business is, what problem they have,
• what sort of solution they requested in their RFP
• why such a solution would be valuable to them.

Basically a condensed version of what you've been putting in intros for the last deliverables.

Process Overview --- Give an overview of how the project was tackled. This includes:

• team organization/make-up/roles
• project management framework you used: reporting, monitoring process, decision process.
• Design methodology – why chosen and how applied
• Deliverables: documentation – Review the deliverables you provided along the way.
• Timeline --- Review the actual (i.e. how it really worked out) timeline for the project. Give a post-mortem here: discuss what slippage occurred and why, and what effect if any it had on outcome.

Requirements -- Start with an intro paragraph that describes your requirements acquisition process, i.e., how you went about extracting requirements from your sponsor. Interviews? Site visits? etc. Then introduce and summarize the main requirements. Allude to the requirements doc in the notebook for details.

• Overall Goals – overview statement of what, in general, the application is expected to accomplish
• Requirements: List and briefly describe the major functional and performance requirements. Doesn't have to be as detailed as your requirements doc, just give highlights. So you could/should condense groups of detailed requirements into larger scale ones.
• Constraints – Any constraints the (a) the client put you under or (b) you determined would limit development in your problem analysis.

Solution Statement --- Here is where you describe what you proposed to build for the client. It starts with a general overview and then gives increasing detail in subsequent sections.

• Overall Solution -- Describe the overall solution that was proposed to the client. Feel free to include a screen snapshot or two from the final product, anything to help us visualize, at a high level, what you were planning to build. Should leave us with a solid notion of what your solution looks like and does.
• Functional Specifications --- Summarize the central functional specs. These should directly reflect the requirements that you described earlier. Same comments as for requirements apply, i.e., you may condense groups of detailed functional specs into single more abstract specs --- you don't want the whole huge detailed list here, just a solid grasp of the function you promised to provide.
• Architecture Overview --- Outline the architecture that you developed to implement the spec. This is the most important "implementation" section in the report --- without a good comprehension of this high-level design, anything you say later about low level details will be meaningless. Carefully diagram major modules and describe responsibilities of each
• As-built Design --- Here's where you report on exactly what you produced. Doesn't have to be as detailed as your as-built report (which should allow your successors to understand your design well enough to repair/extend it). Rather, it should give a technical reader a solid idea of how you implemented the design. Go through each module, give an implementional overview of it, then discuss the various services it provides, and how these services contribute to overall behavior (i.e. when/how/who called).

Usability Testing and Future work --- Describe your usability testing and outcomes

• Outline the tests you ran: subjects, method, materials
• Describe the outcomes of the tests: what did you learn? Might separate into "little" and "big" shortcomings/insights.
• Describe what you did about the exposed issues. Fixed it? Put it on the docket for version2?
• Summarize the usability: Did you create a usable application?

Conclusion --- Wrap it all up. Just general post-mortem on the whole project. Who did it go? Where the sponsors happy? Are you satisfied? This is NOT a place to reflect on your educational experience or personal growth; this is a professional document --- I want to know about the project you did as consultants, not about what you learned as students.