What's Missing From This Requirement?

In 1979, Glenford Myers opened The Art of Software Testing with a test for the reader, before any of the theory. It is one page long, and it has been put in front of professional programmers ever since.

The task: a program reads three integers, which are the lengths of the sides of a triangle. It prints whether the triangle is scalene, isosceles or equilateral. Write the test cases you would need to be confident it works.

Fourteen cases are needed to cover it properly. Myers reports that highly qualified professional programmers come up with, on average, only 7.8 of them.

That result has nothing to do with testing skill, and everything to do with the sentence. The description of the program is two lines long and it reads as complete. It is not. It says nothing about zero, about negative numbers, about three values that cannot form a triangle at all, about non-integer input, about missing input. Every one of those is a decision somebody has to make. None of them announce themselves, because the sentence that skipped them still sounds finished.

That is the whole problem this series keeps circling. We are going to do it once on a requirement closer to your work.

Sixty seconds

Here is the requirement:

"Add a 'remember me' option to the login page."

Set a timer for sixty seconds and write down what this sentence does not tell you, that you would have to know before building it. Do it now, before reading on. The exercise only works in that order.

What the sentence does not say

How long is "remember"? Thirty days and forever are different products and different security postures. Nobody puts a number in the ticket. The agent will pick one, usually whatever the framework's default happens to be, which is a decision made by someone who has never seen your product.

Remember what, exactly? The username, so the field is pre-filled? Or the whole session, so login is skipped? Those are different features with different risk. "Remember me" is genuinely ambiguous between them until somebody decides.

What is stored on the device, and what happens if it is copied? If the answer is a long-lived token, then anyone who gets that token is the user, for as long as it lives. Does it rotate on each use, so a stolen copy stops working? Is it bound to anything, or does it work from any browser on any continent?

Does it skip MFA too? If a remembered device goes straight past the second factor, you have quietly made MFA optional for the most common login path. That is the kind of thing that never appears in a ticket and always appears in an audit.

What happens on a shared device? Someone will tick the box on a library computer. Whether that is the product's problem or the user's is a real decision, and the person who wrote the ticket was picturing their own laptop.

Does it survive a password change? When a user changes their password, usually because they think someone else has it, do remembered devices stay logged in? Getting this wrong is a nameable security hole, not a style preference.

Can the user see and revoke it? A list of remembered devices, with a way to kill one, is either in scope or it is not. It is much cheaper to decide that now than to add it after a support ticket from someone whose ex still has a session.

What does it do to the session timeout you already have? If the platform logs people out after fifteen idle minutes, does "remember me" override that, extend it, or fight with it in a way nobody tested?

Eight questions, from one line of ticket, for a checkbox. None of them are clever. Every one of them changes what gets built.

Where these fit

Part 6 and Part 7 used five categories: valid inputs, expected outputs, failure definition, performance and scale assumptions, and dependency behavior. This is the same set, used at speed. Here is where the eight questions land.

Valid inputs: who is allowed to be remembered, on what kind of device, and what the checkbox actually submits.

Expected outputs: what gets stored on the device and for how long, whether the user can see a device list, and whether login is skipped or the field is merely pre-filled.

Failure definition: what happens when the token is stolen, when the password changes, when the user clicks "log out everywhere", when the device is shared.

Dependency behavior: what the remembered session does about MFA, and how it interacts with the session store and the existing idle timeout.

Performance and scale assumptions: almost nothing, for this feature. One more row per device.

That last line matters more than it looks. The point of running the categories is not to fill in all five. It is to find out which ones are load-bearing for this particular ticket. On the export feature in Part 7, performance carried most of the weight. On a "remember me" checkbox, it carries almost none and failure definition carries nearly all of it. A checklist applied evenly is a waste of everyone's time. The five are there to tell you where to look, not to be filled in like a form.

Why you missed some anyway

If you wrote down four or five of the eight, you did well, and you are roughly where Myers' programmers were with the triangle.

The reason is not carelessness. It is that requirements describe the thing somebody wants, and the gaps live in the parts nobody was picturing: the stolen cookie, the shared computer, the password change three months later. Reading more carefully does not surface them, because they are not on the page to be read.

What used to surface them was building. You wrote the token check by hand, you were already in the session code, and you saw the password-change path sitting right there. The catch was accidental and it was free.

That is the part that has gone. An agent does not wander into adjacent code and notice something is off. It builds what the sentence describes, competently, and fills every silence with whatever is most common in its training data. The noticing that implementation used to do for free now has to happen before the prompt, on purpose.

What this means for you

Keep the exercise. It takes a minute and it survives contact with a busy week.

Take the next real ticket that lands on you. Before you open the agent, set a timer for sixty seconds and write down every question the ticket does not answer. Then run down the five categories and ask which of them is carrying the weight this time. Then mark the two questions whose answers would change what gets built, and answer those two before you type anything.

Not all eight. Two. The skill is not exhaustiveness, it is noticing, and then triage.

The next article is about the gaps this exercise still misses: the assumptions so basic that nobody writes them down, because they do not feel like decisions at all. They feel like facts.

Myers' triangle exercise is from Glenford J. Myers, "The Art of Software Testing" (Wiley, 1979), chapter 1.