Your Software Requirements Need a Volume Knob

Three words, three different promises

According to RFC 2119, MUST identifies an absolute requirement. MUST NOT identifies an absolute prohibition. SHOULD means there may be valid reasons to choose differently in a particular situation, but the consequences need to be understood carefully. MAY marks something as genuinely optional.

Those definitions are stricter than ordinary conversation. People casually say, “We should capture the approval date,” when they may actually mean the date is necessary for the process to work. Someone else says, “The dashboard must use blue charts,” when blue may merely be a preference. The grammar is familiar, but the commitments are crossed.

In Poygan’s view, a useful translation for a small software project is simple. MUST protects a necessary outcome or boundary. SHOULD describes the normal, preferred behavior while allowing a considered exception. MAY identifies an option that can be included without becoming a promise. The words do not make the decision for the team. They make the decision visible.

• MUST: The workflow is not acceptable without this behavior.
• SHOULD: This is the expected behavior unless a documented reason justifies an exception.
• MAY: This is permitted or useful, but the project still works without it.

Run every request through one full turn

A volume knob helps only if someone actually turns it. For each proposed requirement, move through a four-part review: state the request, assign a strength, test the consequence, and record the decision. New information can send the request through the loop again. That makes requirement writing a small flywheel rather than a one-time paperwork exercise.

Start by describing observable behavior. “The system must be secure” is too broad to test. “A user MUST sign in before viewing this record” describes something a person can verify. Next, ask what fails if the behavior is absent. If the answer is merely “we would prefer it,” the requirement may be a SHOULD or MAY. If the workflow becomes invalid, the requirement may deserve MUST.

Then look for conflicts. A requirement can sound essential by itself and still collide with cost, accessibility, privacy, maintainability, or another requirement. Finally, write down the chosen strength and the reason. The explanation matters because a future reader may understand the word differently than the original group did.

• State an observable behavior.
• Choose MUST, SHOULD, or MAY.
• Test what happens when it is absent.
• Record the reason, then revisit it when conditions change.

A synthetic example: the traveling invoice

Consider this clearly labeled synthetic example. A hypothetical service business wants invoices generated from completed work orders. The first draft says the system must create an invoice, must email it automatically, must use a particular template, and must show a celebratory animation. Four musts have entered the room. They are not carrying equal weight.

After review, the team might decide: the invoice MUST use the approved customer and line-item data; the system MUST NOT send an invoice that lacks a required approval; the system SHOULD prepare an email draft when the invoice is ready; and the interface MAY display a small completion animation. These are hypothetical choices, not universal recommendations.

Notice what changed. The exercise did not automatically cut features. It clarified which promises define acceptable behavior, which behavior is the normal path, and which enhancement is optional. That gives design, testing, and review a shared structure. A tester can verify the MUST statements first. The owner can discuss exceptions to the SHOULD statement. The animation can remain pleasant without quietly becoming a launch condition.

MUST is not a synonym for important

RFC 2119 also warns that its requirement words should be used sparingly and only where needed for interoperability or to limit behavior that could cause harm. That guidance belongs to standards work, but the restraint is useful elsewhere too. Poygan’s interpretation is that MUST should be reserved for a boundary the team is genuinely prepared to design, test, document, and maintain.

An important idea can still be a SHOULD. A valuable feature can still be a MAY. Lowering the requirement level does not insult the idea. It tells the truth about the commitment being made now.

There is also a human benefit. Requirement debates often become debates about taste because the underlying consequence remains unstated. Asking “What breaks if we do not do this?” is calmer and more specific than arguing about whose feature matters most. The answer may expose a missing dependency, a genuine exception, or an optional flourish wearing a hard hat.

A ten-minute requirement tuning exercise

Take one upcoming feature, automation, website change, or internal tool. Copy five requirements into a short list. Circle every must, required, always, never, should, optional, and nice-to-have. Rewrite each line using one capitalized requirement word and one observable behavior.

For every MUST or MUST NOT, add a sentence explaining the unacceptable consequence it prevents. For every SHOULD, name at least one circumstance that could justify an exception. For every MAY, confirm that omitting it does not block the required outcome.

If the team cannot complete one of those sentences, the requirement is not finished. It may need a clearer decision, a narrower scope, or a conversation with the person responsible for the workflow. That is useful progress. A fuzzy sentence discovered before implementation is usually easier to handle than a hidden disagreement discovered during testing.