Solar Requirements Traceability: Keep Customer Needs Connected to Delivery

A solar project can lose a customer requirement long before anyone notices it has gone. A buyer mentions a planned roof repair, a facilities team requires a particular access window, or a prospect wants an option that respects a budget ceiling. If the information lives only in a call note, it can disappear when the work changes hands. Requirements traceability gives it a durable path from conversation to decision.

This is not a demand for a heavy engineering system. It is a compact way to preserve the reasoning behind material requirements and show whether they have been addressed, deferred, changed, or remain open. It is especially useful for installers and EPCs whose projects move between sales, design, operations, procurement, and field teams.

Begin With Materiality

Not every preference requires a controlled record. Track a requirement when it can change project scope, physical configuration, customer commitment, price, timing, site access, production or financial inputs, procurement, approval route, or field execution. A request for a different proposal cover colour is usually not material. A request to avoid a known construction window may be.

The record should separate requirements from assumptions. “The customer requires work outside peak operating hours” is a requirement if the customer or site authority has stated it. “The team assumes access can occur outside peak hours” is an assumption that needs confirmation. Mixing them creates trouble because a later reader cannot tell whether the project is responding to a commitment or working from a temporary guess.

NASA’s requirements-verification matrix guidance connects uniquely identified requirements to their source and planned verification. The useful analogy here is the evidence chain, not adoption of NASA rules as solar-project requirements. Record the actual customer, contract, manufacturer, authority, or site source that governs each item.

This guide addresses project needs and delivery constraints. It does not establish PV-material provenance, domestic-content eligibility, or supply-chain certification; those require their own applicable evidence and rules.

Use a Simple Traceability Table

The goal is a record that any handoff participant can read quickly. The following roof-renewal example is illustrative, not a customer case.

Avoid statuses that look finished without evidence. “Addressed” should link to the proposal condition, design note, customer confirmation, or review appropriate to that requirement. If the response is only “discussed,” it remains an open communication item.

Preserve the Customer’s Wording Before Interpreting It

When requirements are first captured, include a short source statement rather than immediately translating it into an internal conclusion. “Customer says new process equipment may be installed next year” is different from “load will increase by 30%.” The former is a statement requiring further information; the latter is a quantified assumption that may not be supported.

This distinction is important for energy and financial scenarios. PVWatts estimates grid-connected PV energy production from specified inputs. A customer requirement about future operation can inform a scenario, but it should not be transformed into a precise production, savings, or payback claim without a defensible input basis.

Ask follow-up questions that reduce ambiguity: what changes, when, who can confirm it, and which decision is waiting? Record the answer with its source. If evidence is unavailable, state the limitation and define the stage at which it must be resolved.

Connect Requirements to Design Choices

The middle of the chain matters most. A requirement list that never reaches design is just a better call note. For each material item, record the current response: an array-location decision, an option included in a proposal, a planned survey question, a scope exclusion, an escalated review, or a decision to pause.

For example, a buyer might require minimal operational disruption. The project response may be to request a shutdown window, include an implementation condition, or tell the buyer that a site-specific operations plan requires further review. Do not claim that the requirement is solved simply because it appears in a heading. The response must be appropriate to the available evidence and release stage.

Use the same revision reference as the solar design basis record. This links the design reasoning to the requirement that initiated it. When a later reviewer asks why an option was selected, they can trace back to the stated need rather than infer intent from a drawing.

Treat Unresolved Requirements as Decisions, Not Background Noise

Some requirements are clear but not yet actionable. A customer may want storage but not have decided its purpose. A landlord may need to approve roof access. A tariff question may need current utility information. Mark these items open and identify the next decision or evidence required.

Do not leave an unresolved requirement in a generic “notes” field. If it can affect a later release, move it into the project’s constraint register and set its deadline. A solar project constraint register can show which condition blocks a proposal, purchase, permit, or field action. Traceability shows why the condition exists; the register controls the route to closure.

This also gives sales teams a better follow-up. Instead of asking whether the customer has reviewed a proposal, they can ask about the specific requirement that remains unanswered. The conversation becomes useful without assuming that a document view proves buying intent.

Review Requirements at Every Handoff

Requirements tend to disappear at transitions. Before a proposal is delivered, check that current customer objectives, included options, exclusions, and conditions match the traceability record. Before acceptance is handed to operations, check that the selected option and any conditions have been carried forward. Before a purchase or field release, check that no material requirement is being violated by a revised configuration or schedule.

The reviewer should not certify matters outside their remit. The purpose is to identify whether a requirement needs the appropriate technical, local, contractual, or qualified review. A traceability table can show the boundary; it cannot decide it.

Section 6.4 of the 2018 NREL PV and storage O&M guide discusses current document versions, change history, responsible contacts, and retained equipment and inspection records. Early requirements records contribute to the same continuity: the people who later operate, support, or modify a project can understand what the original project was meant to achieve.

Handle Changed Requirements Openly

Customer needs change. A budget can move, a building plan can shift, a stakeholder can introduce a new condition, or an early objective can become less important than a delivery deadline. When this happens, preserve the former requirement, record the change source and date, and assess what it affects.

Do not overwrite history so completely that a later team cannot understand why an earlier proposal used a different configuration. A short note is enough: “Customer elected the smaller option after internal budget review; proposal v1 superseded by v2.” This supports honest customer communication and keeps internal teams from acting on a choice that no longer exists.

If a changed requirement materially affects the project, use change control. Ask whether it changes scope, quantities, model inputs, price, schedule, approvals, or field instructions. Route the impact to the responsible role before telling the customer that the request has been accepted.

Make the Record Useful to the Buyer

Customers do not need an internal traceability spreadsheet, but they benefit from a clear account of what the option addresses and what remains conditional. Solar Proposals can present that customer-facing story. The proposal should name the option, stated scope, material assumptions, and next action in language the buyer can review with colleagues.

Avoid selling certainty where the project has only a preliminary response. If roof access or service information remains to be verified, say so. If a customer requirement cannot be met under the current configuration, explain the trade-off and invite a decision. Clear limits are usually more useful than an overconfident answer that later needs reversal.

Review the Evidence Before the Next Decision

For active projects, scan the traceability list for requirements with no source, response, owner, or current revision link. Those blanks are more important than the total number of entries. Ask:

1. Which customer need has changed since the last proposal?
2. Which open requirement can affect the next project release?
3. Is a stated response supported by current evidence?
4. Has a design revision reached the customer-facing proposal?
5. Does the next team understand which conditions are still open?

This exercise can be brief. It focuses attention on the information most likely to cause rework or buyer confusion.

Start With the Material Requirements

On the next active opportunity, capture customer objectives, site and delivery conditions, and commercial or timing constraints that affect the decision. These categories are a starting point, not a limit on mandatory safety, technical, contractual, or authority requirements. Link each item to the relevant design or proposal revision and review it at the next handoff.

A proposed design response is not the same as evidence that a requirement has been met. For the illustrative roof-renewal item, retain the agreed programme, identify the reviewed installation sequence, and record who checked that they align. If the programme changes, reopen the affected item and assess its impact through field-change communication. A customer preference may be changed by the appropriate agreement; a mandatory requirement cannot be waived merely by closing a spreadsheet row.

Frequently Asked Questions

What is solar requirements traceability?

It is a record that follows a material customer, site, commercial, or delivery requirement from its source through the project response, evidence, owner, and revisions. It helps prevent important requirements from being lost in a handoff.

Is a requirement the same as an assumption?

No. A requirement is a stated need or constraint from a customer, site, authority, or project process. An assumption is a temporary input used until evidence confirms, changes, or replaces it.

When should a requirement be closed?

Close it only when the relevant response, verification criterion, evidence, and responsible review are recorded for the intended decision. If it affects a later release, keep it open or controlled until that release has the appropriate information and review.

Who owns requirement traceability?

The person who receives a requirement should capture it, but the response may be owned by sales, design, operations, procurement, or an appropriate specialist. The record should name the next action owner rather than rely on a team label.