Recommended resources
The freely available resources this lesson will direct you to.
Hello again. Last lesson turned a customer’s concern about restricted-area entry into candidate requirements for detection, local alerts, and operating conditions. Those requirements were deliberately candidates: the example assumed two camera streams, proposed performance targets, and left several test conditions for agreement.
Before a team builds against such a document, you need to know which statements are supported by evidence and which are still bets. This lesson gives you a practical way to separate verified facts, assumptions, constraints, and external dependencies—and to keep those distinctions visible as a pilot approaches.
Four different questions hidden in a project plan
Consider the sentence: “The existing cameras will provide two 1080p streams at 15 frames per second.”
It sounds precise, but precision is not evidence. Perhaps someone reported those settings in a meeting. Perhaps a camera supports them on paper but is configured differently on site. Perhaps the streams work on the local network but your team has not been granted access.
Ask four different questions:
| Question | What it reveals |
|---|---|
| What have we established? | A verified fact, supported by identifiable evidence within a stated scope. |
| What are we treating as true for now? | An assumption, which permits planning but still needs checking. |
| What limits our choices? | A constraint, such as an approved budget, site rule, or contractual deadline. |
| What must someone or something outside our control provide? | An external dependency, such as camera access or customer approval. |
These are not four mutually exclusive labels for an entire topic. Camera access can be an external dependency, while “access will be granted by Monday” is an assumption about that dependency. A signed site rule could constrain where video may be stored, while the configuration of the actual device remains unverified.
The first habit is therefore to record specific claims, not broad labels such as “cameras: done.”
Distinguish evidence from confidence
A verified fact is a statement you can trace to evidence: what was checked, by whom, when, under which conditions, and with what result. Its scope matters. “We decoded one stream for ten minutes on the lab network” does not establish that two streams will run continuously at the customer site. A product datasheet can verify a documented capability; it cannot verify the site’s current configuration.
An assumption is a claim you rely on without enough evidence yet. It is not necessarily a bad guess. Assumptions let a small team estimate work and make provisional designs. The danger comes when an assumption quietly becomes a promise.
Watch What is an Assumptions Log? Project Management in Under 5 from Online PM Courses – Mike Clayton. Focus on the log as a way to preserve the difference between a working belief and a confirmed result.
What is an Assumptions Log? Project Management in Under 5
Mike Clayton explains what an assumptions log records and how it helps a project make progress without disguising uncertainty.
Watch the definition for the distinction between a belief used for planning and a verified claim. Then watch assumption risk for why an incorrect belief can become a project problem. In log fields, note the owner, validation action, review date, and status; you can use fewer fields in a small pilot, but not omit the action that will resolve a consequential assumption.
For the camera claim, a useful assumption might be:
A-01: Both existing cameras can supply accessible 1080p, 15-frame-per-second streams to the proposed edge device over the pilot network.
A validation action is more valuable than a confidence adjective: arrange network access, inspect both streams’ reported formats and frame rates, and run a sustained capture test on the intended device. Record the result with the device, network, configuration, and date. If it fails, revise the design or renegotiate the operating condition. If it succeeds, replace the assumption with a scoped verified fact.
An open question differs slightly from an assumption. “Who can authorize access to the camera network?” has no working answer yet. Do not invent one just to fill a plan; assign someone to find out. You may need to proceed provisionally, but mark the resulting schedule belief as an assumption.
Identify which limits are actually binding
A constraint narrows the solution space. “The pilot must run without sending raw video off site,” if imposed and approved by the customer, limits possible architectures. So might a maximum equipment budget, a power limit, a mounting location, or an agreed delivery date. By contrast, “We prefer a particular edge device” may be a preference rather than a binding constraint. Ask who imposed the limit, where it is recorded, and whether it can be changed.
Watch What are Project Constraints?, also from Online PM Courses – Mike Clayton, for the breadth of limits you may encounter.
Mike Clayton defines project constraints as restrictions on available choices, then surveys common sources of those restrictions.
Watch the definition. Continue through constraint types, paying particular attention to resources, information handling, policy, technology, and stakeholder demands. In a pilot, each proposed constraint still needs a source and an agreed interpretation.
Constraints and requirements can be closely related. Last lesson’s candidate Q-05—“The system shall not persist raw video from live camera streams to device storage”—describes product behavior. If an approved customer data-handling rule imposes that limit, the rule is its source constraint. If Q-05 was merely the team’s initial design preference, do not present it as an external rule.
This distinction is especially important when a choice has substantial cost. “Must use the equipment already supplied” can rule out easier alternatives. “We assumed we should use it” leaves room to compare options. Either may be reasonable; only one accurately describes the decision you face.
For a compact treatment of how these items belong in project documentation, read the selected passages of Rachel S. Smith’s Writing a Requirements Document. Its terminology is somewhat broader than ours: when it calls some assumptions “facts which are simply true,” do not treat that wording as a substitute for verification. For pilot planning, retain the explicit evidence test above.
Writing a Requirements Document
Rachel S. Smith shows how to keep assumptions and unresolved issues visible alongside requirements and how to describe constraints and technical dependencies.
In “Classifying Requirements” (on the page ending with the footer “Writing a Requirements Document | Rachel S. Smith 3”), begin with “Once requirements are recorded, the development team should spend some time classifying them.” Read the classification discussion, ending after the instruction to flag open issues. Then find “Writing the Document,” under “General description.” Begin with “General description. Devote the next section of the document to a description of the product in nontechnical terms.” Read the general description through the start of “Specific requirements.” Notice where Smith places constraints, assumptions, and technical dependencies rather than burying them in a requirement sentence.
Treat dependencies as interfaces to ownership
An external dependency is something your delivery needs but your team cannot provide unilaterally. In an edge-video pilot, examples include permission to connect to existing cameras, customer-provided network credentials, a usable power outlet, agreement on where a zone boundary lies, or an operator available to assess alerts. A vendor service or software component maintained outside your team can also be a dependency.
“External” does not mean “someone else’s problem.” Your team still needs an internal owner to track each dependency, an external party expected to provide it, a due date, and a fallback if it does not arrive. For example, without camera-network access, engineers might test with recorded clips; that helps development but does not verify live operation at the pilot site.
The following vendor diagram illustrates why boundaries deserve attention. It depicts one possible multi-pipeline analytics arrangement, not the architecture or required components for our pilot. Its named services and data paths would need separate ownership and interface checks if a team chose to use them.
Notice the difference between seeing a connection on an example diagram and having a verified integration. A diagram can suggest questions—who provides the stream, who operates the data store, what happens if monitoring is unavailable—but cannot answer them for your deployment. The next lesson will make this distinction concrete by drawing a simple system-context and data-flow diagram for a specified product.
Build one decision-ready uncertainty register
You do not need four elaborate documents for an early pilot. A shared, versioned register can hold the important claims as long as each entry says what kind of claim it is and what would settle it. Here is an illustrative extract, continuing the restricted-area example. None of its proposed dates or conditions represents a real customer commitment.
| ID | Claim and classification | Current basis | Owner’s next action |
|---|---|---|---|
| F-01 | Fact: One test camera stream decoded on the lab device for ten minutes. | Capture log, device configuration, and test date attached. Valid for that stream and setup only. | Engineering owner records whether the configuration matches the proposed pilot setup. |
| A-01 | Assumption: Both site cameras will provide accessible 1080p, 15-frame-per-second streams. | Reported verbally; no site test yet. | Engineering owner tests both streams on site before confirming capacity or latency targets. |
| C-01 | Proposed constraint: Raw video may not be stored on the device. | Raised in discussion; approval and exact scope unclear. | Project owner obtains the approved rule and clarifies whether short diagnostic clips are permitted. |
| D-01 | External dependency: Customer grants camera-network access. | Access process and granting party not confirmed. | Project owner identifies the authorizer and agrees an access date; tracks the effect on the site-test schedule. |
| D-02 | External dependency: Customer representative approves the zone boundary and event-labeling examples. | No approved examples yet. | Product owner arranges review before finalizing the test set. |
| Q-01 | Open question: What local alert-latency target remains useful to the operator? | Last lesson used three seconds as an example, not an agreement. | Product owner confirms the need; engineering owner checks feasibility under agreed test conditions. |
This format prevents several costly substitutions:
- A meeting statement is not a measured camera capability.
- A proposed restriction is not an approved constraint.
- A dependency’s expected delivery date is not a guaranteed delivery date.
- A plausible performance number is not an accepted requirement.
An owner should update an entry when evidence arrives, not merely change its status to “done.” For A-01, the update should cite the test result and replace the broad claim with what was actually shown—or state that the assumption was disproved. If the two streams work only at a lower frame rate, that new fact affects the requirement and the design.
The SEBoK section Addressing Unknowns offers another useful convention for requirements themselves: TBD when a value is not yet known, and TBR when a proposed value needs resolution. It also emphasizes assigning work to close those placeholders. Use them sparingly and visibly; neither is suitable for an unqualified pilot promise.
System Requirements Definition - SEBoK
SEBoK explains how to mark unresolved requirement values without letting them silently pass as settled.
In “Addressing Unknowns,” start at “When initially generating a set of requirements, there is often a set of parameters which may require future analysis to determine their actual value.” Read the unknowns guidance through the paragraph on assigning and completing closure actions. Focus on the difference between an unknown value, a proposed but unconfirmed value, and a resolved requirement.
Decide what must be resolved before a promise
Not every uncertainty needs to disappear before development starts. You can implement a local alert prototype using recorded footage while site access is pending. But you should not claim that the prototype has met the two-camera site requirement.
Use the consequence of being wrong to set priorities. If the assumed camera access fails, can you still conduct the pilot? If the raw-video rule is stricter than expected, must you change diagnostic logging? If the zone is not agreed, can anyone consistently judge a missed entry? Resolve high-consequence unknowns before the decision that depends on them—particularly before ordering equipment, committing to a delivery date, or agreeing to acceptance criteria.
As you update the register, keep the requirement document aligned with it. A confirmed constraint may require a new or revised requirement. A failed assumption may change a capacity estimate. An unmet dependency may move a test date or require a documented pilot exclusion. Recording the uncertainty is not a substitute for acting on it; it makes the required action visible.
Key takeaways
A verified fact has evidence and a limited scope. An assumption is a working belief with a validation plan. A constraint restricts choices and needs an identifiable source. An external dependency needs a provider, an internal owner, and a way to track whether it arrives. These distinctions let you make progress without presenting untested conditions as commitments.
Next, you will draw a system-context and data-flow diagram. The register you have just seen will make that diagram more honest: it will show not only the components you propose, but also the boundaries and interfaces whose behavior still needs confirmation.