A frequently heard comment about Senior Design is that the documentation is tedious and time consuming. This conjures up the image of slaving over a hot word processing program, cranking out hundreds of pages a week. The reality of the situation is considerably less onerous. Most Senior Design Final Reports are less than a hundred pages total. This works out to less than one page a week for each team member.
If the amount of writing is so small, then the difficulty must be extraordinary to cause such tedium and time consumption. While "extraordinary" may be an exaggeration, it is true that many students find it difficult. Engineers are used to writing logical, precise, carefully reasoned analysis which proves that the answer given or conclusion reached is the correct one. While there is plenty of analysis to be written in engineering documentation, in many cases there is no single, correct answer.
Design involves choosing an answer which balances the greatest amount of right with the least amount of wrong when applied to a whole range of questions. The notion of weighted, rather than absolute, correctness is unfamiliar to many engineering students. What's worse, not only are the answers less than absolute, but you have to make up your own questions.
Design problems are presented in the form of a statement: "Design a system that does x, subject to constraints y and z." The only question that is obviously embedded in this statement is "Does it do so?" and it can't be answered until the process is complete. The questions which will actually drive the design process must be deduced from this statement and its context and then answered. Your design documentation is the vehicle by which you will deliver the answers to these questions.
In approaching this documentation it is important to keep in mind the structure of the design process that it documents. As we have seen, that process evolves through a number of phases beginning with the definition of the problem (documented in Chapter 1) and culminating in a successfully working design which is documented in Chapter 6. What happens in between will vary from one project to another, but any successful design will go through one form or another of the following:
What about Chapter 3? Because this is a substantial and complex project, an effective plan will be necessary to achieve completion in the limited time available. Clearly you should not wait until halfway through your project before formulating a plan. However, since it will take some time for the finer details of the project to emerge, Chapter 3 is an appropriate point at which to produce a formal document of your plan.
For each of these chapters the corresponding outline from the documentation guidelines has been reproduced below, in bold and italics, followed by annotations, comments, and explanations.
Don't take the word "problem" too literally. Terms like "goal" or "what needs to be done" may be more appropriate to your project, but "problem" is the term traditionally used in discussions of engineering design. When you see "problem," think "what my project is supposed to accomplish."
This should be very concise. More than a single paragraph is too long, and the core of that paragraph should be no more than one or two sentences. Details well be developed later, in subsequent sections. Here's an example: "We will design a low maintenance system to keep a set of batteries fully charged and ready for use during emergencies." Note that this statement contains both the goal (a battery charger) and the problem it's intended to address (need for battery power during emergencies).
Although you should be brief, you must also be complete. "We're going to design a battery charger" is too vague.
It is important to define the problem here, not the solution. "We will build a system using the Acme-Helios 50 watt solar panel which will charge 8 AA nickel-cadmium cells" doesn't leave much room for the decisions which will be necessary to optimize the suitability of your design to the stated goal, i.e. coping with emergencies.
What is the history of this problem?
Nearly every design problem has a history. Very few appear out of nowhere fully developed, like Venus rising from the sea in her seashell. This history is important because it enables you to discover the context of the problem, which is often absent from the formal problem statement. As a somewhat trivial example, the battery charger project defined above doesn't explicitly say why having a supply of freshly charged batteries is important during an emergency. But knowing this is essential to developing an appropriate specification.
Why is it important that it be solved?
Hopefully someone will benefit from the work that you are doing. Who? What benefits will they receive? What important things will fail to happen in the absence of your design?
What are its economic, social, or environmental impacts?
This is a continuation of the previous question, suggesting additional aspects to discuss. It also suggests a broader context in which to consider the problem. You are solving it for a particular reason, or for a particular group of people. Is the problem (and its potential solution) significant for other reasons, or for other groups of people?
There's another question lurking in here. It's possible that your solution (or possibly any solution) will have negative impacts. While this is not strictly an impact of the problem itself, it is relevant: you don't want your design to make things worse. Discuss the potential negative consequences of your project (if any) and show that they are outweighed by the benefits.
What does the literature have to say about it?
This is not necessarily a separate topic. If the conclusions given above concerning the history, importance, and impacts of your project are your own, compare them with what others who have studied the problem have concluded. If you have already done that in answering the previous questions, you can leave this part out. In either case, you should cite the sources of your information.
List everything that is required for the solution to be successful.
How is this different from Part A? This is where you start exploring the details. Remember that the Problem Statement is a statement of what is to be achieved (i.e. the goal), often in very non-technical terms. Your job as a designer is to determine what must be done in order to achieve the desired goal (i.e. the path to be taken). Since you are an engineer, this will be a technical description, with technical details which may be of no concern to, or indeed unrecognized by, the author of the problem.
Returning to the battery charger example, requirements implicit in the definition, though not explicitly stated, include: the device must be easy to use, it should require no attention during use, it must fully charge the batteries without damaging them, it should indicate when batteries are fully charged, it must be safe, etc.
Give both qualitative requirements and quantitative specifications
Remember, at this point you are parametrizing the problem, not your (or any other) potential solution. A picture of what the solution might look like, and what its parameters might be will emerge in Chapter 2. As an example of how these two are different, consider the battery charger. Parameters of the problem include the types of devices in which the batteries will be used, how much power they consume, how much usage they will receive, how long the emergency will last, etc. Parameters of the solution will include charging requirements of the batteries, sources of power for charging, efficiency, cost, size, etc.
Since this problem has probably been around for a while (as you have documented in Part B) it's likely that other people have attempted to solve it, and possibly have succeeded. You don't want to reinvent the wheel, so find out what they have done. Note that even if the problem has been solved you may be able to substantially improve upon existing solutions: wheels with pneumatic tires and ball bearings are much better than the original stone disk with a wooden axle.
Be thorough and detailed in your research. Describe how much attention this problem has received, what approaches have been used so far, and what their shortcomings are. Identify the areas where you intend to focus your effort at improvement. If in fact little work has been done in this area, try to figure out why.
In that sense, this Chapter is an extension or an expanded version of Chapter 1. The reason for not combining them is the separation in time of the processes that produce them. Your problem needs to be well defined before you can productively begin delving into the details. You do not want to be chasing a moving target. Since defining the problem in Chapter 1, you should have extended and modified your project definition in the following ways:
Depth and refinement. You've had another month or so to study the problem, so your characterization is more accurate and more complete. Since we last saw the battery charger example in Chapter 1, you will have researched the types of battery powered devices your user community will be using during emergencies. You will know how much power they draw, what their usage pattern is, what kinds of batteries they use, and what the charging parameters of those batteries are.
Focus. Beyond achieving a deeper understanding of the problem, you should also be examining the relationship between the requirements of the problem and the ability of potential solutions to satisfy them. I.e. you are beginning to characterize a realizable solution to your problem.
Narrowing the target. The problem as stated in Chapter 1 may be too broad to be solved with a single implementation. It may be necessary to choose a specific subset of this broad problem class. For example we could design a big, expensive, all purpose battery charger or one which is small and inexpensive, but only handles a subset of potential battery types. Both are valid solutions to the problem as stated in Chapter 1, but we need to choose one or the other before continuing with our design.
Constraints. Although the initial statement of the problem may have included constraints, others may be implicit in the problem or in your approach to a solution. Note that due to these constraints it may be impossible to solve the problem as originally stated. Hopefully it will be possible to revise the problem statement to allow a feasible solution without deviating too far from the original goal.
Usually a complex problem is solved hierarchically: first it is decomposed into a set of subproblems or subsystems, then each of these is solved or implemented individually. There are a number of advantages to this approach: It allows for more efficient distribution of work among team members. Smaller, more compactly defined problems are easier to research when searching for potential solutions. Analysis of small subsystems is easier than that of larger systems.
For our battery charger, the subsystems might be: a source of power for charging the batteries, a controller to deliver charging power to the batteries at the proper rate, a compact, rugged package, and an easy to understand user interface.
If you have not done this, explain why it is not appropriate for your problem.
While most problems can be decomposed along fairly obvious lines, in a few cases dividing into subproblems is an unnatural approach. For example, if your project is to develop a high gain antenna for a 5 GHz data link, dividing the antenna into sub-antennas will be counter productive.
Subsequent sections of this Chapter should address both the problem as a whole and each subproblem or subsystem.
Up to now you have been focused on the requirements of the overall problem. While you should continue to refine the definition of those requirements, you now also have to determine the specific requirements of each subsystem of your overall design. In subsequent sections and chapters, keep in mind (and write about) both what your complete system must do and what each subsystem must contribute to that overall goal. Explain how the subsystem requirements are derived from the overall requirements.
Define your design target:
(Notice the colon. This is not a topic in its own right, but a statement of the goal of this section.)
Remember (as remarked in Section A) that you should be concerned with requirements and specifications of both the project itself and each of the subprojects that you have defined.
Summarize and prioritize the constraints and scope of the project.
The process of design is one of constrained optimization. Seldom are you able to adjust all design parameters arbitrarily to achieve the best possible outcome. External constraints and constraints inherent in the problem, but not explicit in its definition, will limit the allowable range of many of those parameters.
The specific constraints which apply will vary from one project to another. However, there are some constraints which are common to all projects:
Regulatory. If your project interacts with its environment in any way, its use is probably subject to the approval of one or more regulatory agencies. If it emits electromagnetic radiation, either deliberately or as a side effect of its operation, it must meet FCC regulations. Biomedical devices are subject to FDA approval. If it will be used in an industrial environment, OSHA will be concerned about how safe it is. Needless to say, there are many other sources of regulations, though not all will be relevant to your project.
Safety. Even if your project doesn't fall under the purview of the FDA or OSHA, you should be concerned about safety. Components such as rechargeable lithium cells, which may be perfectly safe in the hands of skilled, knowledgeable people like yourself, may be extremely hazardous to the general public if not properly utilized.
Environmental. The social and environmental impacts you discussed in Part B of Chapter 1 may necessitate some constraints to minimize negative impacts.
Similarly, the scope of your project may have to be constrained from the initial concise (and perhaps overly broad) definition given in Chapter 1. We can't charge an arbitrary number of batteries in preparation for an arbitrary emergency of arbitrary duration.
Enumerate the requirements that your design will satisfy. Give a detailed set of specifications.
This looks a lot like Part C of Chapter 1, and as mentioned above, that is intentional. This is where you expand the simple, largely non-technical specifications given there into a detailed, technical definition of what your project will do. Although this revisits the material from Chapter 1, there are a number of important differences. One is the thoroughness and organization that your description should have (note the words "enumerate" and "detailed"). Another is that you are beginning to characterize your approach to the solution as well as refining the characterization of the problem.
This is the central focus of this chapter and will likely be longer than its Chapter 1 counterpart for several reasons. Because of the constraints identified in the previous section, you will have more things to specify. Likewise, due to the refinement of the scope of your project, you should enumerate the things that your project will not do. Because of the decomposition of the stated problem into subproblems, you will have to develop requirements and specifications for the formerly hidden subsystems. Be sure to organize your presentation in such a way that it is easy for the reader to know what is being specified.
State and justify assumptions.
If two design teams were to undertake the same project, their outcomes would likely be significantly different. This would be partly due to differences in style, but also because the two teams would have seen the problem from different viewpoints and made different assumptions about the meaning of the goal, the environment of the problem, etc. This does not mean that one design is better or worse than the other, just that they are directed at different targets. It is important that you recognize that such assumptions are being made and insure that they are reasonable.
Think of this section and the next as appendices to previous sections. This analysis could have been presented along with the material that it supports, but that might interfere with the concise presentation of your design criteria. To some extent this is simply a question of style: if you feel that an inline presentation would be smoother, leave out this section (and the next). In either case, be sure that you do perform all required analysis (and research).
At this point you should know a lot of things that you didn't know at the beginning of the project. Summarize what you have learned and how you went about learning it. Be sure to credit the sources of the information you used in formulating your requirements and specifications.
List the topics which remain to be researched, i.e. things which you don't currently know but will need to know in order to complete your project.
Since this point is still a considerable distance from the end of the project, there are probably a few things that you still don't know, but should. If you are aware that you don't know them, list them here. If you have ideas about how you are going to find them out, discuss those.
In Chapter 2 you defined the list of subsystems which will comprise your design. If those subsystems are not all completed and working, list all of the things which remain to be done. Explain how you are going to do them. If there are things you are not sure about, list the questions that must be answered and how you plan to answer them.
Don't forget that even after all the subsystems are complete, you still have to combine them into a complete working project, so be sure to consider potential system integration problems as well. Also, once it is completely assembled, it must be tested to verify that it meets its specifications.
Remember the definition of a task: it is something you or one of your teammates must do to achieve one of the goals or sub-goals of your project. It is not the goal itself. For example, one of the subsystems of the battery charger is a controller to insure proper charging of the battery. Some (but not all) of the tasks required to complete this subsystem are: Determine the different types of batteries likely to be encountered. Research the required charging parameters for each. Find circuits or algorithms to implement each required charging regime. Order components required for prototypes. Build or code prototypes and test them. Integrate the chosen controller into the charger.
Produce a set of milestones to serve as indicators that a particular task or phase has been completed.
Milestones are significant points along the path to completion of your project. Like the intermediate towns on a long trip, they provide visible indications of progress and an indication of whether or not you are on schedule. Some events (e.g. presentations and documentation due dates) are set by external factors. While these may be suitable as milestones, it's important to include events which are are specific importance to your project. "Project Complete" is an obvious one, but you need a sufficient number of earlier ones, fairly evenly distributed throughout the course of the project. Some possibilities are "problem characterization complete," "prototype testing complete," "PC layout complete," "final testing complete," etc.
Give a schedule showing dates on which these milestones will be completed.
There's a chicken-and-egg relationship between this section and the next. A Gantt chart can't be produced without a list of tasks (the product of this section), but dates for the schedule can't be determined until the resource allocation is performed (in the next section). You will have to do the work outlined in the next section, then come back and complete this subsection. While documentation due dates are fixed, dates for other events in your design process are outputs from the resource allocation process, not inputs.
Several criteria drive this division. A person with a unique skill must obviously be assigned to all tasks requiring that skill. The remaining tasks should be apportioned in such a way as to achieve an equitable distribution of work, as well as to minimize the length of the critical path in the Gantt chart.
Using a Gantt chart or other technique, show how you are going to allocate the available resources of time and personnel to achieve the schedule in the previous section.
The Gantt chart is one of the most powerful tools available for project resource management. Unfortunately, this portion of the documentation is often viewed as mere window dressing, to be cobbled together as quickly as possible, copied into the report, and promptly forgotten. In fact this section is much more important to the designers than it is to the instructors. A few hours of careful work developing this detailed schedule, combined with a few additional hours over the course of the projecting checking that you are on schedule, and revising the schedule if you are not, can make the difference between successfully finishing your project in mid-April and running out of time before you run out of things to do.
The key to success in using a Gantt chart is to have a well thought out list of tasks and their dependencies, to estimate the expected duration of those tasks as accurately as possible, and to assign the tasks to team members so as to minimize the amount of non-productive time. Do not create the Gantt chart directly; allow your project management software to build it based on your tasks and their dependencies.
Be sure to allow time for delivery of parts and other external delays.
It is an unfortunate fact that not every item listed in a catalog or on a manufacturer's web site is available for immediate delivery. You should identify items with potentially long delivery times and organize your schedule so that final decision on ordering these items occurs early enough to allow for expected delivery time. In some cases it will be necessary to find substitutes or even to change your design to deal with essentially unavailable parts.
Produce a proposed budget indicating how much you expect to spend on each aspect of the project.
Try to include everything expect to have to purchase. For estimated costs, explain how you arrived at your estimate. Include donated items and indicate what they would cost if purchased.
Although you may not have examined all possible solutions, you should have considered several different concepts for the implementation of each of the subsystems of your design.
Include any analysis which was performed during evaluation.
Quantitative comparisons between solution candidates should be based on appropriate analysis or simulation. Explain how these were conducted and give the results.
This is your design, or at least your intended design at this point. Although you may not yet have complete circuit diagrams, software, etc., describe what you do have in as much detail as is available at this point. This is the focal point of this chapter, so devote some effort in making this a thorough, easily understandable explanation of your design.
Explain why it was chosen and how it compares to the other proposed solutions.
If your solution is better in every aspect than all other solutions, then this part will be fairly straightforward. If not, explain the reasoning behind your decisions.
Since this is Chapter 4, it means that you are now 2/3 of the way through your design. Hopefully by this point there are no unanswered questions and no major decisions to be made. If this is the case, omit this section. If not, talk about the decisions remaining to be made and how you plan to make them. Even if you do have a complete set of solutions chosen, you may have a few backups available in case your first choice doesn't work out. This would be a good place to discuss where such alternatives may be required.
If there is a high degree of certainty that your chosen solution will work as expected, you could immediately begin construction of the final version of your project without building any prototypes. However, if your solution relies on technology, materials, processes, algorithms, etc. with which you are unfamiliar, it would be best to gain some familiarity with them before committing the fate of your design to an untested concept.
A prototype is often thought of as a trial run or initial version of a project. In fact the dictionary's first definition of prototype is "the original or model on which something is based or formed." However, another popular meaning of prototype is a quick and dirty (or at least quick) implementation of a device, circuit, subsystem, etc. which is built to test an idea. You might build an exploratory prototype of your entire system, changing various parts until the whole thing works. Or you could build prototypes of each subsystem then combine the working versions to form the final product.
Note that you do not have to wait until this point in the design process to build a prototype. If you want to test an idea during the concept evaluation process, a prototype may be the best way to do so.
Whether or not you decide to build intermediate prototypes, you will have to test your final product to verify that it meets the requirements and specifications given in the Problem Definition. Describe the tests you will perform, the specific information that they provide, and how this information will be used to verify the performance of your design.
If you are building partial or full system prototypes or prototypes of individual subsystems, describe the tests they will be subject to, if different from the overall system tests.
If you have built prototypes, describe their performance. Did it meet expectations? If not, in what ways was it deficient?
If you have not constructed any prototypes, describe the means you have used to verify that your ideas will work.
If you have decided to skip the prototype stage and proceed directly to final construction, explain why you feel confident that your project will work. Have you done extensive simulations? Are you nearly finished with construction and all intermediate tests have been successful?
Prototypes may be used to verify expected performance, or to test uncertain ideas. In either case, a less than perfect outcome from a prototype test provides information on how to improve the next prototype or the final product. What have you learned from your prototype testing? What changes will you make to your design as a result?
If you have not constructed any prototypes, what refinements do you intend to make between now and the completion of your project? Describe why you have decided to make these changes.
Note that the target audience for this chapter (or at least the interest of the audience) is different from previous chapters. Before you were talking to people who were interested in the progress of your design process and the reasoning behind it. Now your readers are interested in the result of that process, i.e. the design itself.
Although you have written about that topic several times previously, what you will be writing here is mostly new. For one thing, it is nature of most Senior Design projects that much changes in the last month or so of the semester. There may be many things in your design that your audience has not seen before. But even if your design is essentially the same as described in Chapter 5 and Part B of Chapter 4, what you will write about it here is very much different. In Chapter 4 you described your design in terms of concepts. Here you will be giving detailed, nuts-and-bolts descriptions of exactly what you built. I.e. the level of detail here should be significantly higher than in previous chapters.
This is not a separate topic but the goal of this section.
Start with a broad scale overview of the entire system, and then describe in detail how each component or subsystem works.
If your design has a significant software component, describe the overall program structure and the function of each major routine.
Justify the choices you have made (algorithms, materials, dimensions, gains, clock rates, etc.).
Include block diagrams, flow charts, drawings, sketches, circuits, etc. as necessary.
Note that the appendices will contain the complete, formal drawings and listings for your project. The material you include here should be excerpts or additional graphics which helps to support your descriptions and explanations.
As you were formulating each of the components of your design, your analysis should have indicated how that component should have performed. Using those results, compute the expected value for each of the specifications given in Part B of Chapter 2. For the battery charger, one of the specifications might have been charging time. Using the current capacity of your power source, the charging profile of your controller, and the charging characteristics of the batteries, compute the expected charging time.
When available, measure the actual performance of your prototype.
"Prototype" is used here in its formal, dictionary sense mentioned above, i.e. the initial version of your complete design.
Compare the performance of your design with the problem specifications from Chapter 1 and account for any discrepancies.
This is the moment of truth: Did your design succeed? Does it meet the goals set for it at the beginning of the design process?
As in Section C of Chapter 2, if you feel that your presentation is improved by including the supporting analysis as it is needed, you can do so and omit this section. In any event, be sure you do include all necessary analysis somewhere.
Lengthy calculations should be placed in an Appendix.
This section should summarize the thinking behind your analysis and avoid getting sidetracked by elaborate derivations and computations. If you need a result which requires such support, simply use it and reference the appropriate appendix.
This was covered in detail in Section A. Boil that down to a cogent summary of what your design does.
Discuss how (or to what extent) it meets the design objectives set out for the project.
This was covered in detail in Section B. Distill from that detail the essence of your success.
Describe how it could be improved and what you would have done differently if you were to do it again.
Chapter 6 should form a smoothly flowing prose narrative of how your design works. Although specific technical details may be necessary for that understanding, embedding large circuit diagrams and code listings in your prose will likely impede the flow of the narrative. For this reason you should gather such material into a set of appendices and refer to them as necessary in the text of Chapter 6. This will also allow hard core engineers who don't like to read prose to go straight to the good stuff. A Corollary of this is that the Engineering Drawings and the Program Listings together should contain sufficient information for another skilled engineer to duplicate your design.