Case studies occur frequently in engineering because, by nature, engineering analyzes (studies) situations that already exist (cases). This document explains how to use a basic engineering problem-solving method to structure case studies, but the structure may also apply to other engineering reports (including undergraduate theses). This document focuses on a particular logical structure that is important to engineering. (For format, see Type of Documents / Short Reports) Michael Jordan (not the basketball player) describes the basics of the problem-solving method this way:
- Understanding the situation being faced;
- Analyzing the specific problem to be tackled;
- Creating, analyzing, and refining a solution;
- And further evaluating, improving, and implementing. 
The method is known as: Situation — Problem — Solution(s) — Evaluation
Each of the logical components here consists more of questions than “how-to” because the goal of this web page is to help you think through the logic structure of this pattern.
1. Situation: Even when a client (or professor) defines a situation, engineers need to understand it in their own terms:
- What are the needs of the client?
- What are the constraints of the situation (time, resources, laws, technology)?
- What are the background facts?
- What are the key questions that need asking?
Example: What happens when the Client doesn’t tell you everything?
If an engineer responding to the Request for Proposal (RFP) below did not think through the whole situation, she might end up in big trouble. An RFP asks contractors to bid on a particular project. Getting the job without understanding the situation can be disastrous. This RFP describes the government’s responsibilities in a research project to test ABS brakes using an “instrumented car” (a car outfitted with sophisticated measuring equipment):
An instrumented vehicle, Pontiac 6000 STE, has been developed and will be provided to the contractor without charge by Transport Canada . A separate contractor has been engaged to perform hardware modifications to the various systems in the vehicle if they are required and approved by the scientific authority. Costs associated with any approved modifications, and the maintenance of the data collection system will be the responsibility of Transport Canada , unless the contractor has been negligent in the use of the system. 
All of this sounds good at first–someone else is worrying about maintaining the systems inside a rather expensive vehicle–BUT what about systems outside the vehicle? Such things as pop-up stop signs and means of altering the slipperiness of the track will be needed. Since these are outside the car, who pays? If those bidding on this contract do not state their understanding of the situation clearly, they could win a bid but lose a bundle. Showing a clear understanding of the situation is the first step to a clear report.
Where it fits: Typically this will fit into the introduction or background sections of a report.
2. Problem: Before you can solve a problem you need to know what it is. Defining a Problem clearly is crucial to finding a solution. In defining the problem, you need to explain the factors that affect the problem. Consider not only what the client says the problem is, but what the client might not recognize. Here is a statement of a problem, taken from an assignment in MIE 561S, Health Care Systems:
Sunnybrook’s Chronic Pain Clinic experiences two problems:
- In its present mode of operation, it loses money on initial consultations.
- Patients’ waiting times for initial consultations are perceived as being too long and should be shortened without significant expenditure.
Unless the number of consultations can be increased by 15% using the same resources, the pain clinic is in danger of being shut down.
This problem statement is not complete. In fact, it is the problem as defined by the client, which is really just the situation. The writer needs to analyze the problem: the problem here might in part be defined as inefficiency in initial consultations.
Sunnybrook’s Chronic Pain Clinic loses money on initial consultations and suffers from long patient waiting times for initial consultations. Unless the number of consultations can be increased by 15% using the same resources, the pain clinic is in danger of being shut down. The loss of money and the waiting times are related because two of the four doctors do not manage to see their patients within the allotted one hour consultation. This means not only that these doctors are unable to see as many patients as the other two doctors, but that those they do see have to wait well past their scheduled appointment. The problem, then, is to eliminate inefficiency in initial consultations without compromising the level offer.
Part of defining the problem is seeing it in terms of what has been done before. These questions might help you explain the full background to the problem:
- What are the parameters that have been set for your analysis?
- What is happening in the situation now?
- What are the shortcomings of the current or previous ways of handling the situation?
- What changes have been made in the situation? or are expected?
These questions might lead to an additional paragraph in our example to clarify and refine the definition of the problem. Here the writer goes on to consider how one parameter physicians’ financial benefit might affect the current situation.
(cont’d from above example)
If inefficiency is a factor, understanding the physicians’ relationship to the clinic becomes important. First, financially, the four doctors who provide service in the pain clinic do so out of interest in the field. They derive little financial benefit from their involvement; in fact, they incur a significant opportunity cost for not performing other, more lucrative procedures. Their pay is not proportionally dependent on the number of patients they examine; instead, it is a percentage of the total revenue generated by a pool of twenty-six physicians performing a variety of roles at the hospital. For this reason, personal income cannot influence physician behavior.
This example is only part of what goes into a problem definition, but it shows how the writer can refine his problem definition by limiting the possible parameters for solutions.
Where it fits: Typically, the Problem definition is also the purpose of the report; therefore, it will follow the situation, or sometimes, precede it. Notice that the problem and the situation overlap. This is predictable because the problem arises out of the situation.
3. Solution: University assignments often expect you to come up with alternatives; hence, you may need to examine more than one solution. Ultimately, to be effective, any solution must:
- Solve the problem. Obvious, but explain: How does the solution work?
- Explain how the solution can be derived from the available data. How does it fit with what we know?
- Fit clearly into the available research on a topic. What research supports it?
As you might guess, this section could be a huge part of the body of a report.
4. Evaluation: Before engineers can implement a solution, it needs to be refined. The first step in refining any solution is an evaluation. You need to think your way around the solution just as if it were an object you were walking around. Ask as many questions as possible. Here are a few:
- Is the solution you suggest likely to be successful?
- What limitations might prevent total success? (eg. does it depend on people being trained?)
- What must a company do to make your solution work? (funding? training? design? safety measures?)
- If you are proposing more than one solution, which one(s) do you recommend be implemented? In which order? (short term vs. long term; most important vs. less important; necessary vs. optional)
Where it fits: Typically, the evaluation comes just before the recommendations. Once you have evaluated several options, then you can make a recommendation. It may also be incorporated into the recommendations.
 Jordan, Michael P. 1988. “How can problem-solution structures help writers plan and write technical documents?” Solving Problems in Technical Writing. Ed. Lynne Beene and Peter White. Toronto: Oxford.
 Supply and Services Canada . 1989. RFP 045SZ.T8080-9-4780/B.