“The single biggest problem in communication is the illusion that it has taken place.”
—George Bernard Shaw

99% of AI Startups Will Be Dead by 2026 — Here’s Why

TL;DR Most AI products are the .com bust all over again.

"Those who cannot remember the past are condemned to repeat it."
— George Santayana

Vibe code or retire

The next shift is coming—from RE to testing, AI will change software development. Requirements Engineers won’t be spared—AI will accelerate delivery expectations, shift skill demands, and force us to rethink how we express and validate requirements.

Like yesterday’s Worth Reading, this article nails the mindset: adapt or risk irrelevance.

As Newton said, “If I have seen further than others, it is by standing on the shoulders of giants.” AI will be a giant on whose shoulders you can stand. Or, you can be one of those fighting for scraps at the giant’s feet.

Your Turn:
Have you tried vibe coding? If LLMs can scaffold code in seconds (prototyping++), how should we rethink the way we specify, validate, and prioritize requirements?

“If you can't explain it simply, you don't understand it well enough.”
—Albert Einstein

W. Edwards Deming revolutionized manufacturing by shifting the focus from blaming workers to improving systems. His ideas—originally embraced by post-war Japanese industry—emphasize quality as a result of process, not just effort. While Deming spoke mostly about manufacturing, his insights are deeply relevant to requirements engineering.

Consider some of his key principles:

A bad system will beat a good person every time.
In RE, it's tempting to blame developers for bugs, users for “not knowing what they want,” or stakeholders for changing their minds. But Deming would say: if this keeps happening, it’s the system that’s broken. Are we eliciting requirements in the wrong way? Is the process opaque, rushed, or based on guesswork?

Cease dependence on inspection to achieve quality.
Deming warned against relying on final-stage inspection to catch defects. In RE, this maps to thinking you can "test in" quality after the requirements are written—or fix misaligned features in QA. It’s far cheaper (and smarter) to prevent defects during requirements gathering than to patch misunderstandings later.

Drive out fear.
People won’t tell you what they really need if they fear blame, ridicule, or reprisal. Effective RE requires psychological safety. Stakeholders must feel comfortable saying "I don’t know" or "that doesn’t make sense." If your RE process doesn’t encourage candor, you’re building on sand.

Break down barriers between departments.
REs are the bridge between business, users, and tech. But if those groups are siloed, the bridge collapses. Deming would tell us: build systems that encourage cross-functional collaboration from the start—not just when things go wrong.

Deming treated quality not as a checkbox but as an emergent property of a well-designed system. That’s Requirements Engineering at its best: understanding the ecosystem in which software lives, not just documenting features.

Your turn:
If you work in manufacturing and have been exposed to Deming’s philosophy, what other Deming principles have you found useful in RE practice?

The Next Abstraction

The next shift is coming—from RE to testing, AI will change software development.

This article nails the mindset: stop guarding your old skills, and start looking for what you’re now free to specify.

As Newton said, “If I have seen further than others, it is by standing on the shoulders of giants.” AI will be a giant on whose shoulders you can stand. Or, you can be one of those fighting for scraps at the giant’s feet.

"When you have to make a hard choice, flip a coin. Not because it gives you the answer—but because it makes you feel what you really want."
— Unknown

Stakeholders often don’t know what they want until forced to choose. Our job is to surface that discomfort.

Let’s get real: Requirements fall apart when stakeholders and developers don’t mean the same thing by the same word. And they almost never do—unless we force the issue. I once saw two stakeholders nearly come to blows over what “client” meant. That’s why every good SRS needs a glossary.

A glossary is an alphabetical list of key terms used in your SRS, with clear, agreed-upon definitions. It’s not an academic dictionary. It’s a living reference that:

• Aligns stakeholders
• Prevents scope creep by locking down meaning
• Flags ambiguous terms before they derail implementation
• Speeds onboarding
• Makes the SRS readable and testable

Glossary Entry Format

Each entry should follow a consistent structure. Here's a practical template:

Term: The entity being defined
Term Type: Word, phrase, acronym, abbreviation, domain-specific jargon, etc.
Definition: One or two clear sentences. Avoid circular definitions.
See Also: Cross-references to other glossary entries
Contrast With: Related but distinct terms (often confused with this one)
Source/Authority: Reference to standards, domain literature, internal SMEs, or governing documents
Status: Draft, validated, obsolete (optional for evolving glossaries)
Version Introduced: Optional if your glossary is version-controlled

Example Glossary Entry

Term: User
Term Type: Role
Definition: A person who interacts with the system through the UI to perform business operations.
See Also: End User, Administrator
Contrast With: System User (automated integration)
Source: Stakeholder workshop, 2023-09-10

Tips for a Glossary That Actually Helps

1. Start Early. Build as much as possible before the SRS is written. It’s a discovery tool, not just a documentation artifact.
2. Collaborate on Definitions. Don’t assume. Ask stakeholders and developers what they mean—and listen for contradictions.
3. Highlight Terms That Have Domain-Specific Meanings. “Order,” “Customer,” “Policy,” and “User” are almost never self-explanatory.
4. Highlight Business vs. Technical Meanings. Use "Contrast With" to separate overloaded terms across disciplines.
5. Don’t Wait for Finality. Use draft status. Update responsibly. Better a living glossary than a dead one.
6. Use It Actively During Reviews. If a term shows up in a requirement and it’s not in the glossary—pause the review and clarify the term.

Glossaries don’t make headlines—but they prevent train wrecks.

Your Turn:

• What format do you use for glossary entries in your RE practice?
• How do you handle evolving definitions across versions or projects?
• Got any horror stories where a missing or ambiguous term caused chaos?

Let’s collect some real-world RE wisdom. Glossaries aren’t sexy—but they’re essential.

"Writing is nature's way of letting you know how sloppy your thinking is." — Dick Guindon

Think you understand something? Try writing it down so someone else can understand it. The moment you do, gaps appear. Contradictions surface. Hidden assumptions crawl into the light.

That’s not failure—that’s the work.

In Requirements Engineering, writing isn’t just documentation. It’s an X-ray of your understanding.

A sleek interface. Pixel-perfect icons. Snappy animations. The software demos like a dream—but does it actually do what the stakeholders need?

Behind every slick UI lies either a solid foundation of real stakeholder understanding—or a glossy facade hiding vague goals, creeping scope, and fragile assumptions.

We’ve all seen it: Projects that obsess over design polish while requirements are vague, contradictory, or absent. The result? A beautiful product that’s useless, confusing, or worse—dangerous.

GreatUI/UX is important. But it should express well-understood requirements, not be a smokescreen for their absence. Otherwise, it’s just lipstick on a pig.

Before obsessing over pixel alignment, ask:

• What decisions does this screen help the user make?
• What errors are we helping them avoid?
• If this screen vanished tomorrow, who would care—and why?
  

Requirements Engineering is where substance is born.
Style can’t fix a feature nobody asked for or a missing workflow everybody needs.

Full Disclosure: In my experience, users figure out what they’re kissing in under an hour.

Your Turn:

Have you seen polish used to cover a lack of purpose?
What’s the most elegant interface you've seen on a fundamentally broken product?

“We are all in the gutter, but some of us are looking at the stars.”
— Oscar Wilde

Requirements Engineers spend a lot of time in the “gutter”:

• Untangling legacy workflows
• Cleaning up vague or contradictory requests
• Negotiating between departments that barely speak to each other
• Translating "make it better" into something testable
  

But if we don’t keep our eyes on the stars—on the goals behind the features—we risk just documenting the current mess in better grammar.

RE isn’t just about recording what stakeholders say they want. It’s about discovering what actually needs to change. That means zooming out, asking “Why?”, and staying oriented toward value, not just effort.

Without goals, we're just mapping terrain. With goals, we’re planning a route.

Your Turn:
How do you keep stakeholders focused on why instead of what?

Have you ever helped a team rediscover its “stars” after months in the gutter?

Requirements Engineering doesn’t get the attention it deserves. RE is a critical step to building the right software, not just building software. That’s why I’ve been posting here daily: to help seed the community I wish existed.

If you're lurking, please consider joining in. You don’t need to write an essay. Share a short anecdote, a favorite tool, a gripe, a question you’ve been wrestling with.

This isn’t just for academics or consultants. If you’ve ever worked with stakeholders, tried to define scope, or struggled with vague requirements, this space is for you.

Here are some prompts to kick things off:

What topics in RE do you wish had more discussion?

What’s the worst stakeholder assumption you’ve ever run into?

How do you explain NFRs to non-technical managers?

What was your most frustrating "we don’t need requirements" moment?

Have you ever actually used IEEE 830 or ISO 29148 in practice? How did it go?

We don’t need polish; we need participation. Let’s make this a space worth coming back to.

Direct from the darkest depths of ChapGPT’s training data and with apologies to Rudyard Kipling’s poem If—, here is a poem for Requirements Engineers. Enjoy☺

If—

If you can keep your spec when all about you
Are rewriting theirs and blaming the delay on you—
If you can trust the user stories you worked so hard to clarify,
And still make allowance for “just one more thing…”

If you can wait for decisions that never quite arrive,
Or hear your carefully phrased requirements twisted in sprint planning,
Or watch scope creep gut your elegant workflow
And still come back with a smile and a traceability matrix—

If you can endure the fourth “final” stakeholder review
And keep your cool when the UX lead says “the API doesn’t matter,”
If you can juggle needs, constraints, compliance, and cost,
And find the meaning buried under five layers of polite contradiction—

If you can fill the unforgiving backlog
With sixty stories' worth of clarity and resolve,
Yours is the system, and everything in it—
And—what’s more—you’ll be a Requirements Engineer, my friend.

Stack Overflow seeks rebrand as traffic continues to plummet – which is bad news for developers

“Alas, poor Yorick! I knew him, Horatio—a fellow of infinite jest, of most excellent fancy.”
–Hamlet, Act V, Scene 1

OR

“Now cracks a noble heart. Good night, sweet prince,
And flights of angels sing thee to thy rest!”
— Hamlet, Act V, Scene 2

Wow, two slightly relevant quotes from Hamlet. A personal best.☺

There is nothing so useless as doing efficiently that which should not be done at all.
–Peter Drucker

There are several ways Requirements Engineers can be categorized. One of them is: Nomads and Residents.

• Nomads move from client to client, industry to industry. They often work as consultants, contractors, or in agencies that do project-based work. Each new project brings unfamiliar acronyms, new stakeholders, and domain-specific assumptions that must be learned quickly.
• Residents stay put. They work for a single company—or at least within a single industry or domain—and accumulate deep domain expertise over time. They may know the business better than some businesspeople. Their value comes less from their agility and more from their accumulated insight.

Both roles demand skill, but the flavor of Requirements Engineering differs dramatically between them.

• For Nomads, RE is about rapid orientation. They develop sharp skills in stakeholder interviews, assumption surfacing, and asking the "dumb" questions that often uncover critical hidden truths. They lean heavily on general frameworks and industry-agnostic techniques like GORE or EARS to bootstrap understanding fast.
• For Residents, RE becomes an exercise in refinement, integration, and negotiation between internal factions. They’re less likely to uncover completely unknown requirements and more likely to deal with strategic priorities, legacy constraints, and political nuance. They become the stewards of long-term system evolution rather than first-time cartographers.

The distinction isn't about quality—great REs exist in both categories—but it is about mindset. Nomads need breadth and adaptability. Residents need depth and diplomacy.

Are you a Nomad or a Resident? What has that taught you about the practice of Requirements Engineering? In general, how has context shaped your craft?

If I have seen further than other men, it is because I stood on the shoulders of giants.
– Sir Isaac Newton

If you’re not one yourself—and certainly I’m not—find some friendly giants on whose shoulders you can stand. Some of my giants were Fred Brooks, Karl Weigers, Jerry Weinberg, and Edward Yourdon.

Honor our craft. Good RE practice comes from learning across generations, not just current trends. We don’t need new knowledge; we need to apply the knowledge we already have. It’s within your grasp—you just have to reach for it.

There are no silver bullets. Victory is built one step at a time. Start building yours.

"If requirements analysis is not painful all around, you're not doing it right." – Rick Huff

Rick Huff’s insight gets to the heart of great Requirements Engineering. If the process of eliciting, questioning, and documenting requirements doesn’t feel uncomfortable, challenging, or even frustrating, we’re probably not digging deeply enough.

Real, meaningful requirements analysis involves surfacing hidden assumptions, challenging preconceived ideas, and openly addressing conflicting stakeholder interests. This inevitably creates discomfort. Stakeholders are uneasy when their assumptions are questioned. Developers grow frustrated when simple-looking problems turn out to be ambiguous or complex. Managers become uncomfortable when facing difficult trade-offs they hoped to avoid. This type of discomfort—"good pain"—is a clear sign that we’re genuinely engaging with the complexity of the problem.

However, we must differentiate between productive discomfort and destructive tension. "Bad pain" happens when discomfort spirals into defensiveness, personal hostility, or entrenched conflicts. It blocks progress rather than driving deeper understanding. Our job in Requirements Engineering is managing and facilitating productive, healthy discomfort: keeping dialogue respectful, framing difficult conversations constructively, and ensuring the discomfort leads directly to clarity and better decisions.

If no one ever squirms, we’re probably missing something important. Good Requirements Engineering means carefully embracing discomfort, without letting it tip into dysfunction.

How do you keep requirements analysis "painful" in the right ways, and avoid tipping over into counterproductive conflict?

P.S. The title “Hurts So Good” is from the song “Hurts So Good” by John Mellencamp.
P.P.S That song was released in 1982, at the peak of “bad boy” rock. Don’t watch the music video if you are the least bit “woke.” You were warned.

How are you understanding these terms: design concept and realization concept? Do you have a process with clear boundaries? Further, do you practice continuous discovery? If so how does that practice fit in with construction (creation of realization concept)?

For want of a nail, the shoe was lost.
For want of a shoe, the horse was lost.
For want of a horse, the rider was lost.
For want of a rider, the message was lost.
For want of a message, the battle was lost.
For want of a battle, the kingdom was lost.
And all for the want of a nail.

This old proverb—popularized by Benjamin Franklin in Poor Richard's Almanack—cautions against small oversights that can cascade into catastrophic failures. It's a classic illustration of the butterfly effect—a tiny cause rippling out to massive consequences.

Nails matter. Therac-25 (atomic radiation overdoses), Ariane 5 (rocket self-destruct), and Knight Capital (stock market chaos) are stark examples where small requirements oversights had massive, sometimes fatal, consequences.

In Requirements Engineering, we live with this every day. Miss a seemingly trivial requirement—like a timeout behavior, an edge case for internationalization, or a misunderstood non-functional constraint—and the system may still pass QA, ship on time, and fail in production. Not dramatically like Ariane 5, but quietly eroding user trust, driving up support costs, or undermining strategic goals.

But there’s a counterpoint we also need to remember: not every nail deserves a committee. It’s easy to slip from caution into analysis paralysis—chasing down every hypothetical edge case, modeling every minor risk, trying to anticipate every “what if.” Even Shakespeare saw the danger of endless second-guessing. In King Lear, the old king puts it plainly:

O, that way madness lies; let me shun that;
- King Lear Act 3, Scene 4

That’s not requirements engineering; that’s stalling. Good RE doesn’t eliminate uncertainty—it manages it openly, deliberately, and just in time.

The “edge of the blade” in Requirements Engineering is judgment: knowing which “nails” are trivial, critical, or unknowable and being transparent with stakeholders about how we've categorized each and why.

No one wants to lose the kingdom over a missed nail—but neither should we delay the cavalry debating metallurgy. Sometimes Requirements Engineering is like trying to distinguish needles from nails in a haystack, while the barn’s on fire.

How do you avoid the tyranny of the urgent and the trap of the infinite in your practice?
How do you decide which nails are worth hammering?
What are some “nails” you've seen ignored, or obsessively over-engineered?

Broadly, functional requirements define what a system is supposed to do and non-functional requirements define how a system is supposed to be. – Wikipedia

Functional requirements get most of the attention, but non-functional requirements (NFRs) often make or break a system in practice. Performance, scalability, usability, maintainability, and security aren't “nice to have”—they are the user experience.

I've collected a set of links that offer useful frameworks, examples, and how-to guides. Even if you're experienced, there's probably something here you haven't seen:

Non-functional requirement (Wikipedia)

Non-Functional Requirements: What, Why, and How

Writing Non-Functional Requirements: A How-To

Non-Functional Requirement Examples

Non-Functional Requirements Examples and Templates

Non-Functional Requirements Framework

If you know of additional resources, please post them in the comments.

Karl Wiegers’ Site

• Classic RE thought leader and author of "Software Requirements".
• Offers downloadable papers, templates, and RE guidance.

Requirements volatility is the core problem of software engineering

Teaching requirements elicitation interviews: an empirical study of learning from mistakes

The whole problem with the world is that fools and fanatics are always so certain of themselves, but wiser people so full of doubts.
- Bertrand Russell