Client needs and requirements

The one-paragraph brief from Larchmont said what the client wanted in everyday language: charge the fleet every night, keep the trucks storm-ready, avoid a service upgrade. None of those phrases could be tested. How much energy is \"the fleet\"? How ready is \"storm-ready\"? What does \"no service upgrade\" mean in kilowatts? The team spent weeks two to four turning the brief into requirements that a design could be checked against, and this lesson shows how they did it.

Needs, requirements and specifications

It helps to separate three things. A need is what the client wants to achieve, stated in their terms: \"the line trucks must be able to leave after a storm even if the grid is down.\" A requirement is a statement of what the system must do or be, written so that it can be verified: \"the system shall hold at least 148 kWh in reserve for the two line trucks during the storm season.\" A specification is how a particular design will meet that requirement: \"a 215 kWh lithium iron phosphate battery operated with a 70 % state-of-charge floor from November to March.\" Needs come from the client; requirements are negotiated with the client; specifications are the team's design choices.

Students often write specifications and call them requirements. If the requirement says \"the system shall use a 215 kWh battery,\" the team has decided the answer before asking the question, and has thrown away the chance to compare a smaller battery with a larger grid connection, or a generator, or a different charging schedule. Good requirements state the result needed and leave the means open.

Finding out what the client needs

Leo, Hannah and Mateo visited the Lincoln Road yard in week two. They walked the site with Doug Pelletier, photographed the existing service, the transformer nameplate and the panel schedule, and measured the parking area. They asked Doug to describe a normal day and a storm day for each vehicle. They spoke to two line crew supervisors, who pointed out something the brief had not mentioned: after a major storm, the line trucks often work sixteen-hour shifts and return to the yard only to restock, so a truck might need a fast top-up in the middle of the day. They also met Nadine Cormier, the protection engineer, who explained what Larchmont would require before any generation or storage could connect to its own service, and Ravi Bhatt, who maintained the substation's relays and knew where every spare conduit ran.

Interviewing users rather than only the sponsor is one of the most valuable things a capstone team can do. Sponsors describe the problem as they imagine it; users describe it as they live it. The midday top-up requirement came only from the crew supervisors, and it changed the design: it is the reason the canopy has a direct-current fast charger as well as overnight chargers.

Turning the duty cycle into energy

The fleet's energy need came from data rather than guesses. Doug supplied each vehicle's typical weekday distance and its battery size, and the vehicle manufacturers' published consumption figures, adjusted for winter, gave the energy per kilometer. Winter matters because cabin heating, battery heating and denser air raise consumption sharply in cold climates, and a charging system sized for summer would leave trucks short in January.

# Fleet energy requirement from the client's duty-cycle data, then a requirements-to-test trace check
fleet = [  # vehicle, weekday km, kWh per km in winter, battery kWh
    ('line truck 41', 140, 0.42, 131), ('line truck 42', 120, 0.42, 131),
    ('bucket truck 17', 90, 0.55, 165), ('crew van 8', 160, 0.30, 98),
    ('crew van 9', 150, 0.30, 98), ('pickup 23', 110, 0.26, 98),
    ('pickup 24', 100, 0.26, 98), ('pickup 25', 80, 0.26, 98)]
need = sum(km * e for _, km, e, _ in fleet)
print(f"weekday winter energy at the battery: {need:.0f} kWh")
eta_charge = 0.90                                   # charger and battery losses
print(f"energy drawn by chargers: {need / eta_charge:.0f} kWh  -> requirement R1 rounded to 360 kWh/day")
storm = sorted(fleet, key=lambda v: -v[3])[:2]
reserve = sum(0.5 * b for *_, b in storm)
print(f"storm reserve for the two largest trucks at 50 %: {reserve:.0f} kWh -> R4")
# trace check: every requirement must map to at least one verification activity
reqs = {'R1 daily energy': ['T3 24-h run'], 'R2 grid import <= 60 kW': ['T4 peak-limit test', 'A1 analysis'],
        'R3 PV >= 30 kWdc': ['I1 inspection'], 'R4 storm reserve': ['T5 islanded run'],
        'R5 converter efficiency': ['T2 efficiency map'], 'R6 telemetry': ['T6 SCADA points'],
        'R7 ambient range': [], 'R8 zero export': ['T4 peak-limit test', 'T7 relay test']}
missing = [r for r, v in reqs.items() if not v]
print(f"{len(reqs)} requirements, {len(reqs) - len(missing)} traced; untraced: {', '.join(missing) or 'none'}")

weekday winter energy at the battery: 327 kWh
energy drawn by chargers: 363 kWh  -> requirement R1 rounded to 360 kWh/day
storm reserve for the two largest trucks at 50 %: 148 kWh -> R4
8 requirements, 7 traced; untraced: R7 ambient range

The eight vehicles need about 327 kWh a day at their batteries on a winter weekday. Charging is not lossless: the charger's conversion, the vehicle's onboard charger and the battery's own charge efficiency together lose roughly 10 %, so the chargers must draw about 363 kWh from the canopy's supply. The team rounded this to 360 kWh a day for requirement R1. The storm reserve came from a different question. Doug said that after a storm the two largest line trucks must be able to leave with at least half a battery, even if the grid had been down all night. Half of 131 kWh and half of 165 kWh is 148 kWh, which became requirement R4.

Writing good requirements

The team followed the guidance in the international standard for requirements engineering, ISO/IEC/IEEE 29148, which describes the properties of a well-formed requirement. Each requirement should be necessary, meaning that removing it would leave a real need unmet; unambiguous, so that two readers cannot interpret it differently; verifiable, so that some test, analysis, inspection or demonstration can show it is met; feasible within the project's constraints; and singular, stating one thing rather than several joined by \"and\". The set as a whole should be complete and consistent.

In practice that means writing \"shall\" statements with numbers and conditions. Compare \"the system should charge the vehicles quickly\" with \"the system shall deliver at least 360 kWh to the vehicle chargers between 17:00 and 06:30 on a winter weekday.\" The first cannot be tested; the second can. Each requirement also gets an identifier, a rationale explaining where it came from, and a verification method, one of test (T), analysis (A), inspection (I) or demonstration (D).

Constraints and negotiations

Two requirements came from constraints rather than needs. The existing 300 kVA service transformer and the yard's other loads left about 60 kW of spare capacity, and a service upgrade would cost tens of thousands of dollars and take a year. The team proposed, and the client accepted, a hard limit of 60 kW on grid import: requirement R2. The second constraint came from Nadine. Any system able to send power back into Larchmont's distribution system would need an interconnection application and review, the kind of study Leo would later do himself for a ten-megawatt solar plant. A system that never exports could connect under a simpler process. The team chose zero export, requirement R8, and accepted that surplus solar on summer weekends would sometimes be wasted.

Some requests had to be refused or changed. Doug initially asked for all eight vehicles to be able to charge at full power at the same time. With chargers totaling about 130 kW and a 60 kW grid limit, that could only be met with a very large battery. Leo explained the trade-off with numbers, and the client agreed instead that every vehicle would be fully charged by its departure time, which smart charging could achieve within the limit. Changing a requirement in this way is normal and healthy, provided the change is agreed by the client and recorded. What is not acceptable is quietly designing to a weaker requirement and hoping nobody notices.

Derived requirements

Top-level requirements describe the whole system. As the design develops, the team writes derived requirements for each subsystem. Requirement R5, the converter efficiency, is an example: the client did not ask for it, but the team's energy balance showed that losses in the battery path above a few percent would make R1 hard to meet in winter, so Aisha set herself a target the demonstrator would be tested against. Every derived requirement must trace upward to the top-level requirement it supports. If it traces to nothing, it is either unnecessary or a sign that a top-level requirement is missing.

Traceability

A traceability matrix links each requirement to the design elements that meet it and to the tests that verify it. It answers two questions that reviewers always ask: is every requirement covered by some verification, and is every test there for a reason? The program above runs the simplest form of this check. It found that requirement R7, the ambient temperature range, had no planned verification activity. Nobody had thought about how a student team could test equipment at −35 °C. Mateo arranged time in the university's environmental chamber, which became test T8, and the gap was closed before the preliminary design review rather than discovered at the end.

Traceability also protects the team when requirements change. When the client changed the simultaneous-charging request, Leo could see from the matrix exactly which design elements and tests depended on it. Without the matrix, changes ripple through a design unpredictably.

The requirements review

At the end of week four the team held a requirements review with Doug, Marguerite, Nadine and Professor Gagnon. They presented the needs, the requirements with their sources and rationale, the constraints and the open questions. The reviewers challenged several: was 360 kWh a day based on the coldest week or an average winter week? Would the fleet grow? Should the system be able to charge visitors' vehicles? The team updated the document, recorded the answers in the decision log, and released version 1.0 of the requirements as the baseline. From then on, changes went through a simple change request, so that everyone knew which version the design was answering.