CONCEPTUAL DESIGN REPORT


Description

Conceptual designs are outline solutions to a design problem. A high level overview of the design (in the form of a block diagram of interacting sub-systems) should be present at this stage. As an example; rough sizes and structural relationships of mechanical blocks, input/output, impedance and voltage level interfaces between electrical sub-systems need to be established.

The main idea behind the Conceptual Design is to maximize the probability of a feasible final product. Hence, a conceptual design should be worked in sufficient detail to allow estimates of cost, weight, overall dimensions and power consumption. During this first phase of the design process, decisions should be made about major design features such as primary sub-systems and major algorithms. The designer should also present the rationale for making these decisions, supported by relevant experiments. An arbitrary decision, especially early in the design process, means a wasted opportunity for improving quality and reducing cost. Using an ad-hoc or popular method without questioning is in fact nothing but making an arbitrary decision. During the conceptual design phase, one must question the “accepted” or conventional ways of doing things and look for possible alternatives.

Broad solutions to the defined problem are developed often in the form of “design options”. This phase places the greatest demand on the designer in terms of creative thinking, since innovations can originate here. Design is not only about the final product but also about the feasibility and cost-effectiveness of the manufacturing process. When the designers choose a part shape, a circuit or an algorithm, they must also think about how these will be manufactured or implemented. “Is there an easier way to achieve the same purpose with a different material, shape, circuit or algorithm?” should be a frequently recurring question in the designer's mind.

The feasibility of design decisions or their alternatives can only be validated if major aspects of the design such as major sub-systems or algorithmic components are verified through sub-system tests. Although it is not a guarantee, the positive results of these preliminary tests convince the customer that the design has a high probability of success upon integration and acts as an experimental “Proof of Concept” on a sub-systems or module level.


Background

The EE 493 and 494 are both two credit courses; therefore about half of the work for the senior design project should be completed in each term.

A reasonable expectation for all projects in Conceptual Design stage is to have the following features:

  • The problem has been clearly defined.
  • Some alternatives have been generated and evaluated for the system as a whole as well as for its major sub-systems.
  • Evaluations are included in the report in the form of early test plans and their expected results; executions of these tests and comparative analyses of those results with the expected ones.
  • An organizational plan has been formulated, to be implemented during spring term, for improving sub-system level design and taking the design from sub-system level performance to a fully integrated performance and then to completion.

As of the end of the conceptual design, a project work that has undergone successful progress should come to a stage where the design of the selected alternative has progressed at least to the sub-system implementation stage where (1) the overall system is defined, (2) all sub-systems are defined and finally (3) experimental results can be reported from individual sub-systems and algorithms,

These are minimum requirements every team is expected to complete at the end of the first term. The conceptual design report covers the items mentioned above and provides a written, group report of progress made by the end of fall term. It differs from the Proposal Report significantly due to the fact that it contains technical and implementation details at a sub-system level, algorithm descriptions and test plans for subsystems as well as results of conducted tests. It is strictly meant for a technically oriented reader. A properly generated Conceptual Design Report means a team is well progressed into generating a feasible product and a considerable number of uncertainties are resolved.


Format and Overall Content

The report should be typed using double space and can be of any length. However, a long report, full of extraneous or repeated material is not desirable. Please write a document that is concise, well coordinated, and focused. This document will be the primary record of one semester of design activity. The contents should include:

  • Title Page
  • Executive Summary (Abstract)
  • Table of Contents
  • Nomenclature (maybe)
  • Standards Compliance (A Table)
  • Main Body of Report (Problem, Overall Design, Individual Sub-Systems, Sub-system tests and test results, Integration plan, All associated figures, tables, comments etc.)
  • Acknowledgments (maybe)
  • Bibliography (Optional) and/or References (books, papers, suppliers, web addresses)
  • Appendices (Technical material that is necessary but disrupts the main flow of the report)


Standards Compliance

This section should reference the appropriate Standards document (which should be cited at the end of the report) and present a table which lists each reference number and state (as yes/no answer) the compliance of the solution to the standard as presented in the conceptual design. An example table might take the form

Standard Item Compliance Status Notes
State the number of the standard item here Yes/No Explain, if necessary, how you comply with the standard. There may be references to the specific design features, exact dimensions etc. to make clear how the design complies with the standard. Sometimes, an explanation may not be necessary and a Yes answer may indicate that you have read and understood the item in the reference. Each item in the reference should have a row in this table.

with as many rows as the number of standards items. If you feel that the table disturbs the flow of the document, you may indicate your compliance with the standard as a short paragraph here and refer to the actual table in an Appendix.

Note that a “No” answer in this table would indicate either that you are doing something wrong or there is a problem with the Standard that was very lately discovered.

Main Body Content

The main body should concisely present the overall structure and all sub-systems of the design, the rationale behind it as well as experimental verifications at subsystem level.

The contents of the main body will differ for each project, but a general outline might include:

  • Introduction or Background
    • Problem recognition
  • Problem Statement
    • Clear statement of problem or Goals of project
    • Constraints or Scope of project
  • Approach to Solution
    • Design Requirements
    • Discussion of relevant alternative solutions
    • Organization Plans (Summary of major decisions made thus far)
    • Test Plans; Test procedures including expected results for determining success;
    • Summary of analysis and test procedures (details for appendices)
  • Solution
    • Proposed Conceptual Design in the form of overall system block diagram including sub-system interaction and interfaces,
    • Description of individual sub-systems and algorithms.
    • Actual test results and comparative analyses with the expected ones as given in the section :”approach to solution”
    • Interleaved Figures, diagrams etc. to support the above material.
  • Plans
    • Detailed breakdown of completed and planned work as well as other responsibilities among the project team members.
    • “Gantt chart” to present project timeline and all necessary steps to take design from sub-system level implementation to fully integrated completion.
    • Foreseeable difficulties (risks) and contingency steps to overcome (mitigate) these difficulties.
    • Cost analysis and deliverables of the design.
  • Conclusion

The appendices contain supporting information, which may be of importance to some readers who require additional details but would disrupt the main flow of the report. Additional background information; extra and raw data backing up your claims in the body; detailed calculations may go here if necessary and contribute to the document. They should individually have a brief introduction and wrap-up. In deciding what to include in the appendices, consider yourself as the reader: an intelligent, technical person.

A bibliography is a list of material that you read to learn more about the problem or to get ideas about solutions. A reference section gives a citation of materials that you directly used in your report, such as analytic techniques or experimental results that are not originally yours. References are a must but you may or may not have a bibliography section.

All drawings should be of professional quality, generated with a drawing program, have an appropriate caption, and should be cited in the body. Drawings can be placed in between the text blocks if small, or covering the next page after citation if large. Figures for the body should not appear in an appendix. Figures in appendices would be included in their respective appendix with a different numbering scheme, e.g. Figure A2-5 for the fifth figure in appendix two.


Evaluation Criteria

The detailed evaluation guidelines for the Design Studio Coordinators are given in the corresponding Conceptual Design Reports Evaluation Rubric document for Conceptual Design Reports. However, the following can also be mentioned as important components:

a) report organization, effective communication, grammar, and

b) technical aspects which include well founded assumptions and claims.

Although writing style varies depending on the writer and intended audience, some general guidelines should always be followed:

1) diversity of sentence structure is desirable to stimulate reader's interest, but should not unnecessarily add to the length or should not confuse the reader,

2) written reports are concise documentation of a technical and complex engineering activity and they should reflect this professional and technical attitude,

3) confusing statements cannot cover up lack of needed information;

It is important to document which team member is responsible for which tasks. It is quite natural that different team members are writing different sections of the document that covers their areas of responsibility. This may result in some variation in writing style but this does not change the requirement that the overall report should be a coordinated whole. In a smooth flow, one section should lead into another, with a solid introduction and conclusion that covers the whole project.

Last modified: 2013/12/17 14:03
   
 
 
Except where otherwise noted, content on this wiki is licensed under the following license: GNU Free Documentation License 1.3