What the electrical engineering version asks of you
Compared with a business case, an engineering case study swaps market share for measured behaviour: loads, ratings, fault levels, protection settings. The writing task is translation. Raw data — a breaker schedule, a one-line diagram, a test report — has to become prose that a reader can follow without the datasheet open, while losing none of the precision that makes it engineering rather than narration.
Three habits carry most of the marks. First, units stay attached. A current without amperes, a length without metres, a power without kW or kVA is a typing error in an engineering document. Second, every calculation shows its assumptions. Demand factors, diversity, power factor, ambient derating — the reader should see the assumption next to the arithmetic, not reverse-engineer it. Third, safety and compliance appear as analysis, not as a closing paragraph of housekeeping: if the case involves an installation or a design decision, the relevant compliance question belongs inside your argument, because it constrains which options are even legal.
A note on honesty: worked numbers in this guide are illustrative, chosen to show presentation, not to describe any real installation. In your own paper the numbers come from the case pack, and anything you assume gets labelled.
Stuck? Shuffle a prompt
Twelve prompts, each aimed at a paragraph your case study probably needs. Deal one, write 80–120 words against it, and the structure assembles itself section by section.
Case study prompt shuffler
Runs in your browser — nothing is uploadedPress shuffle to deal your first prompt.
Turning spec sheets into sentences
The flip cards below pair a fragment you'd meet in a datasheet with the prose register your paper needs. Tap each one. The pattern to steal: name the item, give the value with its unit, then state what the value decides.
"In = 250 A, Icu = 35 kA"
Two ratings on a breaker label. What do you write?
"The feeder breaker is rated at 250 A and its ultimate breaking capacity of 35 kA covers the prospective fault level calculated at the board." Name, value, unit, and the consequence.
"PF = 0.86 lag"
A power factor line item.
"At the measured power factor of 0.86 lagging, the site draws appreciable reactive power, so correction is assessed in the next section rather than assumed away." The number becomes a decision point.
"Cable: 4×95 mm² Cu XLPE"
Conductor spec shorthand.
"The circuit uses four 95 mm² copper conductors with XLPE insulation — a size the case justifies on ampacity rather than on voltage drop, which the calculation confirms." Turn the datasheet into a claim.
"IP54 enclosure"
Ingress protection rating.
"Panels are housed in IP54 enclosures, which the case notes were selected for the dust-laden production hall — an environmental constraint that also shaped the cooling layout." The spec reveals a design reason.
"Tripping: LSI settings"
A protection setting column header.
"The breaker's long-time, short-time and instantaneous settings were coordinated so downstream faults clear first — the selectivity study behind that coordination is summarised in Exhibit 4." Settings become a story about order.
"η = 94.5%"
An efficiency figure from a motor.
"At 94.5% rated efficiency the motor's losses stay modest, yet the case shows they run continuously across two shifts — small percentages on large, long-running loads is where the energy analysis pays off."
A load calculation, presented two ways
Numbers earn marks only when their presentation carries the reasoning. The example below is an illustrative snapshot — a small workshop's lighting and socket load, with invented figures — used to show the difference between dumping arithmetic and narrating it.
"12 × 0.8 = 9.6. 9.6 + 14.4 = 24. 24 × 1.25 = 30. So 30 kVA transformer."
Every number might be defensible, and the paragraph still scores poorly: no units, no labels, no origin for the factors, and a conclusion that appears from nowhere.
"Illustrative figures. The lighting circuit takes a connected load of 12 kW; applying a diversity factor of 0.8 (assumed, following typical practice for a small workshop) gives a demand of 9.6 kW. Socket circuits add an assumed 14.4 kW of demand, bringing the total to 24 kW. Allowing 25% headroom for future growth — the case states expansion is planned — sets the supply requirement near 30 kVA, which supports selecting the next standard transformer size up. The answer is most sensitive to the diversity assumption: at unity diversity the requirement rises to roughly 33 kVA, still within the same size class, which is why the recommendation holds."
The narrated version does four things: labels the figures as illustrative, gives each factor an origin or an "assumed", converts arithmetic into a requirement, and closes with a sensitivity sentence. That four-move pattern works for cable sizing, voltage drop, battery autonomy — any calculation your case needs.
Safety and compliance are analysis, not appendix
In an electrical case study, compliance constraints do quiet work: they eliminate options before economics even gets a vote. A design that fails earthing requirements or lacks documented protection coordination isn't the cheap option — it isn't an option. Build a short compliance passage into the analysis: name the obligation the case raises (earthing, discrimination between protective devices, documentation of tests), state how the case data shows the design meeting or missing it, and carry that verdict into your option comparison.
You don't need to quote clause numbers from memory, and you shouldn't invent them. Reference the type of requirement the case mentions, and cite the case document itself. If your course expects a specific wiring code or standard, its name goes in your references; the six checks below make sure the reasoning around it is complete.
- Every value in the draft carries a unit
- Each calculation lists its assumptions beside the arithmetic
- The case's compliance obligations are named in the analysis
- Protection and safety constraints shaped the option comparison
- Diagrams and exhibits are numbered and referenced from the text
- No invented clause numbers or standards — only what the case cites
A structure that fits most electrical cases
Adapt freely, but this order has yet to fail a student: 1) the engineering question the case poses, in one sentence; 2) the system as built — one-line description in prose, pointing to the diagram; 3) the data — loads, measurements, ratings, each with units and source; 4) the calculation or comparison the question demands, narrated the way the tabs above show; 5) compliance and safety verdicts folded into the options; 6) recommendation with its most sensitive assumption named; 7) references and exhibits. Keep exhibits numbered, and never leave a figure unreferenced in the text — graders check.
If your case leans toward buildings and infrastructure rather than electrical detail, the cross-discipline guide to engineering case studies extends these habits to civil and mechanical work, including standards referencing and exhibit hygiene. And when the write-up is nearly done, the word counter for essays helps you keep the wordage inside your brief's tolerance.
Case pack long, weekend short?
When the calculations are piling up faster than the prose, a quoted, deadline-bound writer with the right subject fit can draft the paper while you keep control of the technical sign-off.
Frequently asked questions
How technical should the language be?
Technical enough that an engineer can check your claims, clear enough that a marker who isn't a power specialist still follows the argument. Define specialist terms on first use and keep sentences doing one job each — precision comes from structure, not from jargon density.
Do I have to include calculations?
If the case provides data and the brief asks for analysis, yes — a case study with no arithmetic reads like a summary. Even one narrated calculation with assumptions and a sensitivity note demonstrates the skill being marked.
How do I reference standards correctly?
Cite the standard the case itself names, with the edition given, and use your course's required citation style for it as you would a report. Never quote clause numbers you cannot verify in the source — describe the requirement instead, or check the document itself.
Can I present my own assumed values?
Yes, clearly labelled as assumptions and chosen conservatively. Markers generally reward an explicit assumption plus a sensitivity sentence over a silently borrowed number — the first is engineering judgement, the second is a citation problem.
What belongs in an exhibit versus the text?
Raw schedules, full diagrams and long tables go to exhibits; the text carries only the values your argument uses, each pointed at its exhibit by number. If a reader never needs to open the exhibit to follow your paragraph, you've found the right split.
Will the prompt shuffler save your next writing session?