Must for Strong Requirements

By the end of this lesson, you will be able to...

• Use must to state a strong technical requirement in an API, rollout, or design review.

• Separate must from uncertainty with might, capability with can, and hard limits with cannot.

• Rewrite vague advice into a precise requirement with the object and condition visible.

Idea in one sentence: Use must when the sentence is not a guess, option, or capability, but a rule the system or team has to satisfy.

Core Insight

Lesson 006 used might for an uncertain hypothesis:

The spike might be related to the deploy.

That sentence keeps the investigation open.

This lesson moves to a stronger commitment:

Every request must include an idempotency key.

This is not a hypothesis. It is not a suggestion. It is not only a useful capability.

It is a requirement.

Must tells the reader that the rule is strong. If the rule is not satisfied, the design is wrong, unsafe, or incomplete.

In lesson 004, you saw the hard limit:

The client cannot retry without a request id.

Must turns that limit into a requirement:

Every retryable request must include an idempotency key.

That is the useful connection:

cannot safely do X without Y -> Y must be present

The first sentence explains the boundary. The second sentence states the rule.

The Small Situation

Imagine the checkout API from lesson 004.

A mobile client sends a payment request. The network times out. The client does not know whether the payment was created. The team wants retries, but payment retries are dangerous without a stable id.

A teammate writes this design note:

We should add idempotency keys.

That is reasonable advice, but it may be too soft for this part of the design. If payment requests can retry, the idempotency key is not optional. It is the thing that lets the server recognize the same request instead of creating a duplicate payment.

The stronger sentence is:

Every request must include an idempotency key.

Even better, make the scope exact:

Every retryable payment request must include an idempotency key.

Now the reader can see:

• the object: every retryable payment request;
• the requirement: must include;
• the required piece: an idempotency key.

That is the shape of a useful must sentence.

The Naive Idea

The naive idea is:

must = sounds serious

That is not enough.

Must should not be used just to make a sentence feel important.

Weak:

We must improve reliability.

This sounds strong, but it does not tell the reader what rule to follow.

Better:

Every retryable payment request must include an idempotency key.

This sentence is strong and inspectable. A reviewer can check the API schema. A developer can check the request builder. A tester can write a test for missing keys.

So the useful test for must is:

Can someone verify whether this requirement is satisfied?

If yes, must is probably doing real work.

Must, Might, Can, and Cannot

The track now has several commitment levels.

Compare these sentences:

The spike might be related to the deploy.
The system can recover, but it could still lose logs.
The client cannot retry without a request id.
Every retryable payment request must include an idempotency key.

They are not interchangeable.

Must belongs where the rule is not optional.

It is stronger than advice:

Advice:
We should add an idempotency key.

Requirement:
Every retryable request must include an idempotency key.

It is different from a hard limit:

Limit:
The client cannot retry safely without an idempotency key.

Requirement:
Every retryable request must include an idempotency key.

The limit explains why the requirement exists. The requirement tells the team what the design has to satisfy.

A Worked Review Trace

Let us revise a pull request comment.

Starting comment:

Add idempotency keys.

This is too abrupt. It gives a command, but not the requirement behind the command.

Step 1: name the rule.

Retryable payment requests must include an idempotency key.

Now the comment says what must be true.

Step 2: name the reason.

Retryable payment requests must include an idempotency key, because the server needs a stable id to detect duplicate retries.

Now the reader sees the mechanism.

Step 3: name the boundary.

Retryable payment requests must include an idempotency key, because the server needs a stable id to detect duplicate retries. Without that key, the client cannot retry safely after a timeout.

Now the comment connects must and cannot.

Step 4: make the next action clear.

Retryable payment requests must include an idempotency key, because the server needs a stable id to detect duplicate retries. Without that key, the client cannot retry safely after a timeout. Can we add this to the request schema before enabling retries?

This is a strong review comment. It is firm, but it is not vague. It names the requirement, the reason, the hard limit, and the next action.

Check: Why is We should add idempotency keys weaker than Retryable payment requests must include an idempotency key?

Think first, then reveal.

Answer: Should sounds like advice. Must states a requirement. The stronger sentence also names the exact object that has to satisfy the rule.

Requirement First, Evidence Second

A must sentence often belongs next to an evidence sentence.

Requirement:

Every retryable payment request must include an idempotency key.

Evidence:

The mobile client sends the same idempotency key when it retries the same payment.

The first sentence says what the design requires. The second sentence says what the implementation currently does.

Keep them separate.

If you mix them, the reader may not know whether you are stating a rule or reporting a verified fact.

Unclear:

The client must send the idempotency key.

Clearer review:

Every retryable payment request must include an idempotency key. The current mobile client does not send the key on timeout retries yet.

Now the review has two parts: the requirement and the gap.

This is especially useful in status updates:

Every retryable payment request must include an idempotency key. Backend support is ready, but the Android client still needs the request builder change.

The modal gives the rule. The rest of the update gives the evidence.

Check: Which sentence belongs in an incident hypothesis, and which sentence belongs in an API requirement?

The spike might be related to the deploy.
Every retryable payment request must include an idempotency key.

Think first, then reveal.

Answer: The first sentence is an incident hypothesis because the cause is uncertain. The second sentence is an API requirement because the rule has to be satisfied for safe retries.

Make the Requirement Testable

A good must sentence should be testable.

Vague:

The API must be safe.

Better:

Every retryable payment request must include an idempotency key.

The second sentence can be checked.

You can ask:

• Does the request schema include the key?
• Does the client send it?
• Does the server store it?
• Does a duplicate request return the existing result?

This does not mean every must sentence has to include all implementation details. It means the requirement should point to something visible.

More examples:

Every admin action must write an audit log entry.
Every webhook request must include a valid signature.
Every migration step must have a rollback path.
Every background job must have a stable id before retries are enabled.

Each sentence names the object and the rule.

That is much better than:

The system must be reliable.
The API must be secure.
The migration must be careful.

Those may be true goals, but they are not yet useful requirements.

From Must to Acceptance Checks

One reason must is powerful in technical writing is that it can create an acceptance check.

Start with the requirement:

Every retryable payment request must include an idempotency key.

Now ask what would prove it.

The answer becomes a small checklist:

This is why must is different from a strong-sounding wish.

Weak:

The retry flow must be robust.

You cannot test that sentence directly.

Better:

Every retryable payment request must include an idempotency key, and the server must return the existing result when it sees the same key again.

Now the team can write tests:

missing key -> request is rejected
same key, same payment -> existing result is returned
same key, different payload -> conflict is reported

The grammar has become engineering work.

That is the point of this track. The modal is not decorative. It tells the reader what kind of claim they are looking at and what action follows.

Strong Without Being Rude

Must is firm. That does not mean the sentence has to sound aggressive.

Blunt:

You must add this key.

Better in a review:

Retryable payment requests must include an idempotency key before we enable retries.

The better sentence moves the focus from the person to the requirement. It says what the design needs, not what the author failed to do.

This is useful in technical collaboration. You can be clear about a hard requirement and still keep the comment focused on the system.

When a sentence starts with you must, check whether the real subject should be the technical object:

Personal:
You must log admin actions.

System-focused:
Every admin action must write an audit log entry.

The second sentence is usually easier to accept and easier to test.

Common Confusions

Confusion: Must Is Just a Strong Should

Why it is tempting:

Both words can tell someone what to do.

Better model:

Use should for advice or recommendation. Use must for a requirement that the design has to satisfy.

Recommendation:
We should add a test for duplicate retries.

Requirement:
Retryable payment requests must include an idempotency key.

The recommendation may be negotiated. The requirement defines the boundary of an acceptable design.

Confusion: Must and Have To Are Always the Same

Why it is tempting:

Both can express obligation.

Better model:

In technical writing, must often sounds like a rule in the design, policy, protocol, or contract. Have to often sounds like pressure from an external situation, deadline, tool, customer, or process.

Design rule:
Every request must include an idempotency key.

External pressure:
We have to rotate the key before Friday.

The next lesson will focus on have to. For now, keep must close to strong requirements.

Confusion: Must Proves the System Already Does It

Why it is tempting:

Must sounds confident.

Better model:

Must states the required rule. It does not prove the implementation already satisfies the rule.

Requirement:
Every retryable request must include an idempotency key.

Verification:
The mobile client currently sends the idempotency key on checkout retries.

Do not confuse the requirement with evidence that the requirement is already met.

Trade-offs and Limits

The trade-off with must is force.

It is useful when ambiguity is dangerous:

Every retryable payment request must include an idempotency key.

That sentence prevents a soft interpretation. The requirement is visible.

But must can sound too heavy when the sentence is only a suggestion:

Too strong:
We must add a dashboard for this metric.

Better as advice:
We should add a dashboard for this metric if the alert stays noisy.

It can also become useless when the requirement is too broad:

Too broad:
The service must be fast.

Better:
The checkout API must return a response within 300 ms for cached product data.

The signal that must is too vague is a reviewer asking:

How would we test that?

If you cannot answer, the requirement probably needs a clearer object, condition, or measurable behavior.

There is one more social limit. Must can sound accusatory in an incident review if it points at a person instead of a requirement.

Blame-shaped:
The on-call engineer must check this sooner.

Requirement-shaped:
The runbook must include the latency check before the rollback step.

The second sentence is usually more useful. It turns the lesson into a system requirement instead of a personal complaint.

That keeps the requirement firm and the collaboration workable.

Practice

Choose the best sentence for each situation.

1. The team has incomplete evidence about a latency spike.

The spike might be related to the deploy.
The spike must be related to the deploy.

Best: might, because the evidence is incomplete.

1. The API design requires a stable key for retryable payment requests.

Every retryable payment request must include an idempotency key.
Every retryable payment request might include an idempotency key.

Best: must, because this is a strong requirement.

1. The client cannot retry safely without a stable id.

The client cannot retry safely without an idempotency key.
Every retryable request must include an idempotency key.

Both can be useful. The first names the hard limit. The second states the requirement that fixes the limit.

Now rewrite these vague requirements:

1. The API must be secure.
2. The worker must be reliable.
3. The migration must be safe.

Model answers:

1. Every webhook request must include a valid signature.
2. Every retryable job must have a stable job id.
3. Every migration step must have a rollback path.

Each rewrite makes the requirement visible and testable.

Daily Practice Lines

Repeat these three lines during the day:

Every request must include an idempotency key.
The spike might be related to the deploy.
The client cannot retry without a request id.

Then change one piece:

request -> webhook -> admin action -> migration step
idempotency key -> valid signature -> audit log entry -> rollback path
must include -> must write -> must have -> must validate

Keep the practice small. You are training this question:

Is this a rule the design must satisfy, or only a guess, option, capability, or recommendation?

The next lesson adds a related but different obligation:

We have to rotate the key before Friday.

That sentence is about external pressure. This lesson's must is about a strong rule.

Resources

• [ARTICLE] Cambridge Dictionary Grammar: Must - Use this to review the grammar form, then apply it to technical requirements.
• [ARTICLE] Stripe Docs: Idempotent Requests - Use this as a concrete API example where a retry rule depends on a stable key.
• [ARTICLE] Microsoft Writing Style Guide - Use this to keep strong requirements specific and testable instead of broad and vague.

Key Takeaways

• Must states a strong requirement: Every request must include an idempotency key.
• Might keeps an uncertain hypothesis open: The spike might be related to the deploy.
• Cannot names a hard limit: The client cannot retry without a request id.
• A useful must sentence names the object and the rule.
• Do not use must just to sound serious. Use it when the requirement is real and testable.