Translating Customer Problems into Measurable System Requirements

Hello, and welcome. This course starts with a decision that affects every pilot: what, exactly, are you promising the system will do? The first module builds the tools for making technical choices and delivering pilots safely. Before choosing a model, device, or architecture, you need a way to turn a customer’s problem into requirements that your team can build against and the customer can check.

In this lesson, you will distinguish a customer need from a system requirement, write functional and non-functional requirements, and attach meaningful measurements to them. We will use an illustrative edge-video scenario throughout. Its numbers are examples for learning, not targets you should promise to a customer without discussion and testing.

Begin with the operating problem

Imagine a customer says: “We sometimes miss when people enter a restricted area. Can you put an AI camera system there and alert us quickly?”

There is a real problem here, but not yet a specification. “Enter” might mean crossing a marked boundary or remaining inside it. “Alert us” might mean displaying something at the site, sending a remote notification, or both. “Quickly” could mean one second or one minute. The customer may also expect the system to work when the internet is down—even though a remote notification cannot arrive through a disconnected network.

A useful first response is not “Which detection model should we use?” It is to understand the operating situation:

• Who acts on the result? An on-site operator, a remote supervisor, or nobody until a later review?
• What event matters? Where is the zone boundary, and what counts as an entry?
• Under what conditions? How many cameras, at what resolution, in which lighting and network conditions?
• What happens when the system is wrong or unavailable? Is a missed event inconvenient, or could someone rely on the alert for safety?
• What is outside the promise? For example, does the product record video, control a gate, or replace an existing safety procedure?

The MATLAB video An Introduction to Requirements provides a compact foundation before we formalize this example.

A customer need describes a desired outcome from the customer’s perspective: “The on-site operator needs to know when a person enters the restricted zone.” A system requirement states an obligation of the product: “The system shall display a local alert when it creates a zone-entry event.” The second statement is closer to something a team can implement and check, but it still needs supporting definitions and performance measures.

The word shall is useful because it distinguishes an obligation from an idea. It does not make a sentence good by itself. “The system shall be fast and accurate” remains too vague to guide either engineering or a pilot review.

Translate the need without choosing the design prematurely

The product you are specifying is the system of interest. For this example, suppose it includes video ingestion on an edge device, event detection, local event records, and a local operator display. The existing cameras and the customer’s wider network sit outside that boundary. Drawing the boundary prevents a common mistake: promising a result that depends on equipment or services your team does not control.

Read the relevant parts of SEBoK’s System Requirements Definition. It explains why translating a need involves analysis rather than merely rewriting the customer’s words.

The process is broader than drafting sentences. Stakeholder needs must be examined against the system boundary, interfaces, operating conditions, and ways to verify the result. The following diagram shows where that work sits before architecture and design.

For a small pilot, you do not need an elaborate requirements department. You do need the discipline represented by the diagram. A short, reviewed requirements document can be sufficient if it says what is in scope, records the obligations clearly, and preserves why each one exists.

Separate behavior from quality

A functional requirement states behavior: what the system does with an input, event, or user action. In our scenario, detecting a zone entry, creating an event record, displaying an alert, and indicating camera loss are distinct behaviors.

A non-functional requirement specifies a quality or operating limit of that behavior or of the whole system. Detection quality, alert latency, concurrent stream capacity, reliability, and data retention are examples. The categories are useful prompts, not rigid boxes: “Display an alert within three seconds” combines a function with a performance limit. It is often clearer to keep the alert behavior and its timing as separately identified requirements so each can be checked.

Do not try to make every possible quality attribute a pilot requirement. Instead, ask what could make this product fail its intended use. For edge audio/video analytics, particularly important questions often concern:

• Detection quality: How many real events can be missed, and how many false alerts can operators tolerate?
• Timeliness and capacity: When does the measurement clock start and stop, and how many streams must work at once?
• Failure behavior: Can operators tell when a camera or the application is not providing trustworthy results?
• Data handling: What media or metadata may be stored, where, and for how long?

A statement becomes measurable only when its test conditions are defined. “At least 90% detection” leaves open 90% of what, in which scenes, and according to whose labels. Likewise, an alert latency measured from the instant the system recognizes an event says little about the delay from the event appearing in the camera feed.

Build a small, testable requirement set

Let us make the example more precise. Suppose the customer’s proposed need is:

NEED-01: An on-site operator needs a reviewable warning when a person enters a configured restricted zone, so the operator can respond.

For illustration, assume the pilot covers two existing camera views, each supplying 1080p video at 15 frames per second, with a local operator display. A zone-entry event means a person moves from outside a configured zone to inside it and remains there for at least one second. The test team and customer would still need to agree on how to label borderline cases, such as partial visibility at the zone edge. The system is for operator awareness, not an automatic safety control.

Here is a candidate set. All entries trace to NEED-01 or to an operating condition necessary to support it.

These are candidate requirements, not an approved specification. Several details still require agreement. For Q-01, the parties could define a customer-reviewed test set with at least 100 annotated entries from the two views, covering the lighting and activity expected during the pilot. For Q-02, they could use at least 20 hours of representative footage and count false events, not every incorrect frame-level prediction. An event-matching rule is needed so both sides count the same things.

Those details matter because metrics can otherwise conceal disagreement. If 90 of 100 annotated entries produce matching events, the measured event detection rate is 90%. If 30 false events occur during 20 camera-hours, the false-alert rate is 1.5 per camera-hour—even if many true entries were also detected. Neither result alone tells the whole story. Q-03 also needs a consistent way to match each qualifying entry to its local alert and timestamp both ends of the interval.

Notice what the set does not say: “Use a particular model,” “run a particular inference framework,” or “send every frame to the cloud.” Those are possible design choices. If the customer genuinely requires a specific device, protocol, or integration, record that as a constraint and its source rather than quietly treating a preferred implementation as a customer need.

Also notice the limits of the set. F-04 makes input loss visible; it does not claim that the product can detect entries while frames are missing. Q-05 concerns persisted raw video, not event metadata or temporary processing in memory. If operators need clips for review, Q-05 and that need must be reconciled before approval.

Check both the wording and the promise

Each candidate should have an owner or source, a short rationale, and a proposed verification method. For example, Q-03 might record:

Rationale: Alerts must reach an on-site operator while an entry remains actionable.
Verification: Play annotated footage through both configured streams at the agreed rate; compare the timestamp of each first entry frame with the timestamp when its matching alert appears locally; calculate the 95th-percentile elapsed time.

This is more useful than keeping a number with no explanation. If testing later shows three seconds is infeasible on the available hardware, you can discuss the customer’s actual time need rather than treating “three” as sacred.

There are two distinct reviews:

1. Check the requirement’s wording: Is it singular, clear, bounded, consistent with the other requirements, and possible to verify? “The system shall be reliable and user-friendly” fails this check.
2. Check the requirement against the need: Would meeting the entire set solve the customer’s problem under the agreed conditions? A perfectly testable requirement to count vehicles would be irrelevant if the customer needs warnings about people.

Then check the set for conflicts and gaps. A customer might want immediate remote alerts during an internet outage. That combination cannot be promised without clarifying what “remote,” “immediate,” and “outage” mean, or adding a viable communication path. A detection target established only on bright daytime footage may not answer a need that extends through dark shifts. These are conversations to have before a pilot is judged against unstated expectations.

For an early pilot, a practical deliverable is a brief versioned document containing the problem and intended user, system boundary, agreed operating and test conditions, numbered requirements, each requirement’s rationale and verification method, and unresolved questions. Ask the customer to review whether it describes the outcome they need. Ask the engineering team to review whether the obligations are feasible together. Approval should capture the agreed version, not imply that unknowns have disappeared.

Key takeaways

A customer problem becomes engineerable when you define the system boundary, express the needed behaviors, set measurable quality and operating limits, and decide how each obligation will be checked. Good requirements preserve the customer’s intent without prematurely locking in a design. Most importantly, a requirement can be precise yet still be the wrong promise—review the complete set with the people who will use and build the system.

The next lesson will separate verified facts, assumptions, constraints, and external dependencies. That distinction will help you identify which parts of a proposed requirement set are already supported by evidence and which still need confirmation before a pilot commitment.