What Is a Requirement and Why Is It Misunderstood? Types, Qualities of a Good Requirement and Separating Problem from Solution

Version note: This post is conceptual; the definition of a requirement and the qualities of a good requirement follow ISO/IEC/IEEE 29148:2018, the joint standard of ISO (International Organization for Standardization), IEC and IEEE (Institute of Electrical and Electronics Engineers), and the requirement levels follow the BABOK Guide v3 from IIBA.

Guess First

Late June. Hakan, Bookstore's corporate sales manager, sends a short email to Selin, the Product Owner: "We want an Excel upload screen for orders from schools and libraries. It has to be ready by early September, that's when schools place their orders." Selin forwards it to the team. Emre, who works on the backend, reads it and gives an estimate: "File upload, parse the rows, add them to the cart. Three days."

Three days later the screen is ready. Hakan uploads a file a school sent and the screen fails on the first try: there is no ISBN in the file, only book titles and class sections. In the second file the ISBNs contain dashes; in the third the same book appears on four different rows, one per class section. "These are the files we get every September," Hakan says.

Before reading on, think about it: is there a requirement in Hakan's email? If so, which sentence is it? Which three questions, asked before writing any code, would have saved Emre those three days?

What Is a Requirement?

ISO/IEC/IEEE 29148:2018 defines a requirement as a "statement which translates or expresses a need and its associated constraints and conditions". Three things stand out in that definition. First, a requirement is a statement; it is not a screen, a table or an endpoint. Second, a need sits at its center; a sentence that does not express a need is an instruction, not a requirement. Third, the need alone is not enough; the constraints it lives under and the conditions in which it applies are part of the requirement too.

Read Hakan's email with that lens and you cannot find a single sentence that states a need. "An Excel upload screen" is a solution. "Ready by early September" is a constraint. "That's when schools place their orders" is context. The need itself, what schools and libraries fail to get done when they order, is written nowhere.

The standard also separates two words, and the distinction is very useful for a developer. Requirements verification confirms, by examination, that requirements are well formed: unambiguous, measurable, consistent. Requirements validation confirms that those requirements describe the system the stakeholders actually intend. Emre's screen correctly implemented a well-written instruction and still built the wrong system: work that passes verification and fails validation.

Requirement Levels: From Business to Constraint

The word "requirement" is used for sentences at very different levels of detail, and most confused conversations are two people talking at different levels. Hakan thinks at the business level, Emre at the functional level. The feature we follow throughout this series is schools and libraries placing bulk (institutional) orders; here is what each level looks like for it:

The levels connect like a ladder. Ask why a functional requirement exists and you climb to a stakeholder requirement; ask why that exists and you reach a business requirement. If a functional requirement cannot be connected to any level above it, there are two possibilities: either you forgot to write down a stakeholder need, or that requirement is not needed. The standard calls this upward and downward linkage traceability and treats it as part of requirements management.

Constraints and non-functional requirements are often confused. A non-functional requirement describes a quality and can usually be negotiated within a range: would 8 seconds be acceptable instead of 5? That is a conversation. A constraint is a limit the team did not choose that narrows the design space: the ERP transfer is not a technical preference, it is accounting's decision. The standard defines constraints to cover limits on the development process as well as on the system, which is why "before September 1" is a constraint.

BABOK adds one more class to this list: transition requirements. These are needs that exist only while moving from the old state to the new one and disappear once the transition is over. In our example, importing last year's list of institutional customers, kept in Excel, into the new system and getting the customer service team used to the new screens are two such requirements.

We will see how to make non-functional requirements measurable in post 06, together with the ISO/IEC 25010:2023 quality model. In this post it is enough to recognize them as a separate level.

Why Are Requirements Misunderstood?

Hakan's email was not written carelessly. Misunderstanding leaks in from several places at once.

First, words mean different things on each side. For Hakan a "bulk order" is an order placed by an institution; for the warehouse it means many copies of the same book; for Emre it means adding many rows to a cart. Even the word "order" differs on the school side: for the school's accounting office an order is a document of its own with a purchase order number, not our Order record.

Second, people do not say what they know, because to them it is obvious. Hakan has known for years that files arrive section by section; it does not occur to him to write it down. Bringing out this unspoken knowledge (tacit knowledge) is the subject of the next post.

Third, people describe their needs in the language of solutions. "An Excel upload screen" is how Hakan describes the problem with a tool he knows. If the team reads the sentence as the requirement, the design decision has been made on day one.

Fourth, information arrives through intermediaries. The school's purchasing officer explains the need to Hakan, Hakan writes to Selin, Selin forwards it to the team. Each hand-off drops a little context and adds a little interpretation. The sentence Emre reads is not the sentence the owner of the need said.

Qualities of a Good Requirement

ISO/IEC/IEEE 29148:2018 lists nine qualities a single requirement should have and five qualities a set of requirements should have as a whole. Instead of repeating the standard's text, let's turn the most useful ones into questions a developer can ask:

The remaining three qualities are mostly about writing discipline: a requirement should have the level of detail that fits its level (no database tables in a business requirement), contain everything needed to understand it, and follow the writing pattern the team agreed on.

The set-level qualities catch something else: individually flawless requirements can contradict each other or leave a gap when put together. The warehouse says "every order ships in a single shipment", the library wants "a separate delivery to each branch"; each sentence is unambiguous and verifiable on its own, but together they are inconsistent. A requirement set is expected to be consistent, complete, feasible as a whole, comprehensible and able to be validated with the stakeholders. That is why you review requirements not one by one but by reading related ones side by side.

Hunting Vague Words

The most practical way to get unambiguous requirements is to search the text for words that carry vagueness. When reviewing a requirement, underline each of these words and ask "how much, who decides, under which condition?": "fast", "easy", "user-friendly", "flexible", "if necessary", "as far as possible", "appropriate", "etc.", "supports", "sufficient", "large", "and/or".

Let's rewrite three sentences from Bookstore's first draft with this lens.

"The system should process large lists quickly." There are two vague words here. Suppose elicitation showed the largest school list is around 900 rows; the sentence becomes "the validation result for a list of up to 1,000 rows is shown within 5 seconds under normal load". We will make "normal load" measurable in post 06 as well.

"Accounting approval is obtained if necessary." Who decides whether it is necessary? Talking to the school's accounting office reveals that the rule depends on an amount limit: "If the order total exceeds the approval limit defined by the institution, the order waits in the 'Awaiting Approval' state and is not prepared until the institution's accounting officer approves it."

"Institutional orders have a minimum of 20 copies." This sentence looks innocent but has at least three readings: must the order as a whole contain 20 copies, 20 copies of each book, or 20 per class section? Is exactly 20 valid? We do not invent the answer here; we put it on the open questions list. Clarifying rule questions like this with examples is the job of post 05 and Example Mapping.

A warning: the number that replaces the vague word has to come from somewhere. If "5 seconds" is a number the team made up, the sentence becomes unambiguous but not correct.

Separating Problem from Solution: "An Excel Upload Screen"

After Emre's screen fails, Selin sets up a half-hour conversation with Hakan and with Gül from customer service. None of the questions is about the screen:

"Last September, how did a school's order reach you? Can you walk me through it from the beginning?" Gül explains: the school merges the lists prepared by teachers and sends them by email; the file format changes from school to school; Gül looks up every row in the catalog and adds it to the cart. An average 240-row list takes half her day. Last September 46 institutional orders came in; in 11 of them at least one wrong book was shipped because of a wrong ISBN.

"What happens if this work doesn't get done today?" Hakan answers: in the first two weeks of September institutional orders pile up, and some schools stop waiting and go to another supplier.

Now a problem statement can be written: "Institutions' book lists reach us in different formats and customer service types them into the system by hand. This takes half a day per list, orders pile up during the September peak, and last season a wrong book was shipped in one out of every four orders." Excel does not appear in this sentence. An Excel upload is still one possible solution, but now it has company: the purchasing officer pasting the ISBN and quantity columns into a text box, copying the institution's order from last year and editing it, or giving customer service a fast ISBN validation tool.

We discussed problem statements and hypotheses in the "Outcomes over Output" post of the Introduction to Product Management series; here we look at the requirements side of the same idea. Don't throw away the solution sentence; follow it upward: "If this screen existed, what would change? Who would that change help?" By the second or third "why" you usually reach the real need. Which solution gets chosen is a product decision; the requirement's job is to make that decision possible in the language of the problem.

The Developer's Role in the Requirements Process

It is tempting to leave requirements to the business analyst or the Product Owner. But the person who notices most gaps in a requirement first is the one trying to turn it into code. In the "From Requirements to Diagrams" post of the UML and Modeling series we saw that whether "day" meant calendar day or working day came up while naming an attribute on a class. Code does not tolerate ambiguity.

A developer brings four things to the process: edge case questions ("What if the same ISBN appears on two rows? What if 50 are requested and 30 are in stock?"), cost and feasibility information ("writing to the ERP in real time is six weeks, a nightly transfer is two days"), cheaper alternatives (a paste box instead of a file upload) and record-keeping discipline: writing the answer, who gave it and the date next to the requirement.

That last item is a light but sufficient form of traceability. Give each requirement a short identifier (such as REQ-BULK-03) and use it in the related story, the test name and the commit message. Not every project needs a heavy traceability matrix; but six months from now you need to be able to answer "why does this check exist?" with a single search.

In Production

Requirements change; that is a sign of learning, not a failure. The problem is change that leaves no trace. If Hakan said in a meeting that "schools actually want a separate invoice per branch", that sentence must not stay in a chat channel; it should be recorded as a new version of the requirement, with who said it and when.

Every requirement needs an owner: who answers questions about it? For bulk orders, corporate sales owns the discount rule, the institution itself owns the approval limit, and Bookstore's accounting owns the ERP transfer. When a requirement has no clear owner, the developer fills the gap with a guess, and that guess becomes a rule in production.

Common Pitfalls

The first pitfall is thinking requirements are a list of screens. "Institutional order screen, approval screen, invoice screen" is not a requirement set but a design sketch. Rules, constraints, quality expectations and behavior with no screen (the nightly ERP transfer, waiting when the approval limit is exceeded) are invisible in a screen list.

The second pitfall is stating the cost of late-found misunderstandings with precise numbers. The chart saying "a defect found during requirements costs 1 unit, in production 100 units" circulates widely in presentations and is usually attributed to the IBM Systems Sciences Institute. As Laurent Bossavit traced in "The Leprechauns of Software Engineering" and later writing, no published study behind that number could be found; the institute cited as the source was an internal training program, and the number spread largely through a citation of course notes in Roger Pressman's 1987 textbook. The idea that a late defect can cost more is reasonable, but presenting the multiplier as established fact is wrong. Build your argument on your own project's data: 11 orders shipped with a wrong book at Bookstore last September is more convincing than a "100x" on a chart.

The third pitfall is accepting the solution as the requirement. If you put "Excel upload" in the backlog as written, the team does a great job of writing the right file parser and the problem stays where it was.

The fourth is assuming "the customer knows what they want". Customers know their problem well; they remember the exceptions in their own work only when asked. A requirement is not a package handed over once but an agreement built through conversation.

A Small Experiment

★☆☆ Take the five most recently added items in your team's backlog and label each with one of the levels in this post: business, stakeholder, functional, non-functional, constraint or transition. See which level is not represented at all.

★★☆ Hunt for vague words in a requirement text (a PRD, a Jira description, an email). Mark at least five words and write the question "how much, who decides, under which condition?" for each. Put the ones you cannot answer on an open questions list, with who you will ask.

★★★ Think of the last request that came to you as a solution sentence ("add this screen", "give us that report"). Before talking to the requester, write the problem you have in mind as a problem statement in the form used in this post; then ask the requester "how did this go last time?" and compare your sentence with their story. The difference between the two sentences is your list of assumptions.

We defined a requirement, separated its levels and saw what a good requirement looks like. But Selin's half-hour conversation won't be enough to fill the gaps in Hakan's email. In the next post we move on to elicitation: we'll see how to uncover the real need behind bulk orders with a stakeholder map, interviews, observation, workshops and prototypes.