Requirements, Constraints, Assumptions, and the Concept of Operations

Mission

• Measurable outcome: By the end, you can turn an ambiguous technical request into a concept of operations, five testable requirements, a constraint set, and an assumption register with no solution disguised as a need.
• Prerequisites: Modules 1–2, especially system traces and quality scenarios.
• Work product: A lightweight concept of operations and requirement-quality review.
• Time: 65–85 minutes.

Before you read: Predict → Commit → Connect

Meridian’s executive mandate is “migrate payments to regional microservices with zero downtime by Q4.” Separate this into need, proposed solution, constraint, target, and ambiguous claim. Commit to what you would challenge first. Connect “zero downtime” to the quality-scenario structure from Chapter 2.3.

Start with operation, then constrain design honestly

A requirement states a needed capability, behavior, interface, quality, or condition that can be verified. A constraint limits the solution space, for example law, mandated interoperability, fixed physical envelope, or approved budget. An assumption is treated as true for planning but needs validation because the evidence is incomplete. A design decision selects how to satisfy needs and constraints.

These categories are frequently mixed. “Use regional microservices” is likely a proposed design, not the user need. “By Q4” may be a business target or constraint depending on consequence and authority. “Zero downtime” is ambiguous until it names the customer boundary, measurement, window, allowed degradation, and evidence.

A Concept of Operations, or ConOps, describes how users, operators, systems, and organizations will achieve the intended mission across normal, degraded, transition, and recovery scenarios. It creates shared operational meaning before detailed design. The scale can be one page for a service change or a controlled document for a safety-critical system.

Accessible diagram label: Mission need becomes operational scenarios and requirements; constraints and assumptions shape alternatives, while evidence feeds learning back into assumptions and requirements.

Write operational scenarios before a giant requirement list:

• Normal: authorize, record, settle, and support a payment.
• Peak: process forecast volume with tail-latency and capacity guardrails.
• Dependency degradation: bank, region, or ledger is slow or unavailable.
• Transition: old and new platforms serve traffic simultaneously.
• Recovery: roll back traffic and reconcile in-flight and completed operations.
• Operations: detect, diagnose, communicate, and repair.
• Abuse or error: unauthorized request, duplicate, configuration mistake, or bad deployment.

Accessible diagram label: Meridian’s concept of operations includes transition and rollback states, not only the desired new-platform end state.

Good requirements are necessary, unambiguous enough for decision, feasible within known constraints, singular where practical, traceable to need, and verifiable. Avoid “shall use modern best-in-class technology.” Prefer: “During loss of one regional payment-service instance at forecast peak, the customer-visible authorization success rate remains above the approved threshold measured over the specified window.” Engineering still decides the architecture.

Traceability is not bureaucracy for its own sake. It connects need → scenario → requirement → design evidence → launch decision. Use it where consequence justifies the cost. For a low-risk internal tool, a compact table may be enough. For payment integrity, privacy, safety, or regulated behavior, formal control may be required.

Assumptions need owners and expiry. “The bank sandbox behaves like production” should lead to comparison evidence. “Customers will tolerate a brief pending state” needs Product validation. “Both schemas remain backward compatible” needs engineering proof. Unvalidated assumptions are not facts because they appear in a plan.

Decision rights: Who owns what?

Product or mission owners define the need, beneficiary, and priority. Operators define operational realities. Engineering and Architecture own feasibility and design. Domain authorities define mandatory constraints. The TPM integrates the ConOps, requirement dependencies, assumption validation, and decision schedule.

The TPM may challenge an untestable requirement but should not silently change its business intent. A named authority approves requirement changes and accepted noncompliance.

I do

I decompose Meridian’s mandate. Need: expand regional processing while preserving trusted payment and settlement behavior. Proposed solution: regional services. Target: Q4 traffic goal. Constraints: applicable data residency and payment controls, approved external contracts, and declared budget. Assumptions: dual-run capacity exists; bank identifiers reconcile across paths; operators can fail back within the target. I create scenarios and ask accountable owners to validate each assumption before its dependent decision.

We do

Helios is told: “Use the newest model to automate 80% of support with no hallucinations.” Together classify the statement and rewrite it without promising impossible certainty.

You do

Take one executive mandate. Highlight nouns and verbs by category: need, scenario, requirement, target, constraint, assumption, or design. Draft normal, degraded, recovery, and operator scenarios. Write five requirements and have an engineer attempt to interpret each differently; revise ambiguity without dictating design.

Pause & Recall

From Chapter 2.3, retrieve the components of a quality scenario. From Chapter 2.1, name the scenario actors and boundaries Meridian’s ConOps must include. From Chapter 1.3, who decides when a requirement conflicts with a security constraint?

Production lens

Requirements change. Version them, record rationale, and propagate changes into designs, tests, rollout, training, and operations. During migration, include temporary-state requirements: coexistence, backfill, rollback, reconciliation, and retirement. Temporary systems often survive longer than planned.

Workplace artifact: lightweight ConOps

Mission need / beneficiary / current problem:
Outcome, benefit hypothesis, and guardrails:
System and organizational boundary:
Actors and operational owners:
Normal scenario:
Peak / degraded / abuse scenarios:
Transition / migration scenario:
Recovery / rollback / reconciliation scenario:
Candidate requirements and measures:
Constraints and source authority:
Assumptions, owners, validation, and expiry:
Candidate design decisions kept separate:
Trace from requirement to evidence:
Change / waiver authority:
Open contradictions and decision dates:

Chapter compression

Needs explain why; ConOps explains operation; requirements state verifiable behavior; constraints limit choices; assumptions await evidence; designs choose how. Keep them distinct so teams can challenge solutions without losing intent.

Retrieval deck

• Q: What does a ConOps describe? A: How actors and systems achieve the mission across normal, degraded, transition, and recovery scenarios.
• Q: Is a deadline always a constraint? A: No; it may be a target unless authority and consequence make it binding.
• Q: What makes an assumption governable? A: Owner, validation method, due date or expiry, and consequence if false.
• Q: Why separate design from requirement? A: To preserve alternative solutions and prevent unexamined solution bias.
• Q: What does traceability connect? A: Need, scenario, requirement, design evidence, and acceptance decision.

Spaced review

• Now: Classify the five parts of Meridian’s executive mandate.
• 1 day: Classify five new statements without notes.
• 3 days: Rewrite one design-disguised requirement as needed behavior.
• 7 days: Run a degraded-mode ConOps walkthrough.
• 14 days: Inspect whether one assumption was validated before its dependent decision.

Sources and further study

• NASA Systems Engineering Handbook
• NASA Systems Engineering Handbook Appendix
• U.S. Department of Transportation, Systems Engineering Guidebook
• NIST, Guide for Conducting Risk Assessments