Last week I started talking about using AI in requirements engineering in this post. This week I continue the story.

A Tale of Three Projects: How Things Go Sideways (and How They Don’t)

Let’s start with stories, because numbers rarely change minds, but lived experience does.

Project Northwind looked simple: a new customer portal, a clean UI, a few integrations, and a go-live date shoved neatly between two quarterly board meetings. What could go wrong? Quite a lot, as it turned out. The initial statement—“Make sign-up fast and secure”—read well on a slide. Yet nobody agreed on “fast,” and “secure” meant different things to different teams. Legal wanted consent tracking, operations wanted smooth onboarding for call center reps, and security wanted strict password rules that clashed with UX. The build moved forward while definitions lagged. You can guess the ending: rework, delays, and a go-live that was technically successful but emotionally exhausting.

Project Halcyon tried to avoid that fate by writing everything down—pages upon pages of requirements. The pendulum swung the other way. The document spelled out not only what the system should do, but also which components should do it and how they should talk to one another. Engineers felt boxed in before discovery even began. When load assumptions changed, the team struggled to adapt because design decisions were locked into the requirement set. A tidy plan led to brittle delivery.

Project Cedar took a different path. The team set a simple standard for requirement entries—ID, description, rationale, acceptance criteria, and type (functional or non-functional). They also set up a review rhythm. After each workshop, someone turned raw inputs—emails, chat snippets, meeting notes—into structured entries. Ambiguous phrases were marked with a friendly warning. Missing non-functional needs were suggested, not dictated. The team kept the requirements focused on outcomes, not mechanisms, and let design evolve within guardrails. Did it all go smoothly? Of course not. But the bumps were visible early, discussed openly, and resolved before they grew teeth.

These three projects hint at a theme: clarity beats volume, structure beats improvisation, and gentle discipline beats heavy-handed control.

What Makes Ambiguity So Tempting?

Ambiguity hides in our favorite words—”simple,” “intuitive,” “robust.” They’re comforting because they don’t force decisions. Why commit to 300ms response time when “snappy” feels easier? Why spell out availability targets when “high uptime” sounds nice? The trouble is, these words solve meeting discomfort, not system design.

The fix isn’t to strip language of personality; it’s to ground it. If a requirement uses subjective phrasing, pair it with something testable: a number, a threshold, a clear condition. This is where AI helps. It can spot the soft spots and nudge: “You wrote fast. Do you mean time-to-first-byte, full render, or task completion time? Suggest a metric.” The nudge matters because it turns preference into intent.

The Missing Middle: Non-Functional Needs

Non-functional requirements are like plumbing—you don’t notice them until something smells off. Performance, security, resilience, accessibility, observability, data retention—none of these sparkle in a demo, yet they decide whether a platform holds up in the real world.

Teams miss them for boring reasons. People assume they’re implicit. Backlogs favor visible features. And when schedules get tight, the quiet items are first to slip. AI can’t force anyone to care, but it can hold up a mirror. If it sees a payment flow with no fraud controls called out, it can ask questions. If it finds a login journey without a session timeout policy, it can suggest one. That’s not bureaucracy; that’s muscle memory.

Scope Creep Isn’t Evil—It’s a Signal

Scope creep usually signals learning. Stakeholders see a demo and realize a gap. A new regulation appears. A dependency shifts. The answer isn’t “never change scope.” The answer is “change it with eyes open.”

Good change handling looks like this: an impact note that traces the requirement to screens, services, test cases, and operational runbooks. A short assessment of time, risk, and trade-offs. A visible decision with a rationale. AI can assemble the first draft of that picture by following links and previous patterns. Decision-makers still decide—but now they’re deciding with context rather than gut feel alone.

Stakeholders Don’t Need More Documents; They Need Better Conversations

Stakeholder friction rarely stems from a lack of information. It stems from mismatched views. Executives think in goals and risk. Engineers think in constraints. Operations think in stability and cost-to-serve. The wrong artefact for the wrong audience creates friction.

AI can reframe. The same requirement can be summarized three ways without twisting meaning: a goal statement for leaders, acceptance criteria for testers, and integration notes for teams who run the thing at 3 a.m. That isn’t cloying; it’s respectful. It meets people where they are.

Over-Specification: The Quiet Thief of Agility

Telling engineers how to implement a requirement can feel helpful. It’s also a fast path to regret. When the world shifts—new constraints, new data—those baked-in decisions turn flexible architecture into poured concrete. Keep requirements about outcomes. If you must record a design decision early, mark it as a decision, not a requirement. That tiny act of labeling preserves room to improve.

Traceability Without the Pain

Traceability often dies under its own weight. Teams picture delicate diagrams, stale spreadsheets, and a chorus of sighs. It doesn’t have to be that way. The light version:

• Every requirement has an ID.
• Commits reference IDs.
• Tests reference IDs.
• A report shows coverage: which requirements have code, which have tests, which have neither.

AI helps by suggesting links rather than demanding them. “This change set mentions address normalization—likely connected to REQ-143. Link?” One click. Done. The goal isn’t to impress auditors. It’s to know what you built and why it exists.

What Standardization Actually Means (and Doesn’t)

Standardization gets a bad rap because it’s confused with uniformity. The point isn’t to make every project identical. The point is to make them legible to one another. Legibility gives you reuse, shared learning, and faster onboarding.

A light standard can live on a single page:

• ID: Machine-friendly, human-memorable.
• Type: Functional, non-functional, or regulatory.
• Description: Outcome-focused, not mechanism-focused.
• Rationale: Why this matters; the business or risk story.
• Acceptance Criteria: Observable, verifiable conditions.
• Links: To decisions, designs, code, tests, and runbooks.
• Status & History: Proposed → Agreed → Implemented → Verified; with dated changes.

If that sounds dull, good. Boring is stable.

Turning Messy Inputs Into Clean Output

Here’s a day-in-the-life scene. Monday morning, your inbox groans. A regional sales lead has sent a “quick thought,” a support manager has forwarded an escalation, and compliance has attached a PDF with cheerful highlights. Meanwhile, your chat stream has a thread titled “Crazy idea, hear me out,” and your calendar holds a two-hour workshop that will absolutely run over.

AI acts like a diligent note-taker. It extracts requirement candidates, threads them back to sources, surfaces contradictions, and drafts entries that follow your standard. It flags uncertainty, not with scolding, but with prompts: “You mention fast. Consider a threshold.” “No acceptance criteria yet. Want suggested checks?” It’s the difference between starting from a blank page and editing a first draft.

Validation: Bring Testing Forward

Nothing makes a requirement more real than a test written early. Even a simple one. If your requirement says, “Customers can reset their password,” a quick script for the happy path changes the conversation. It tells you whether the requirement is clear, whether edge cases exist, and whether the success condition is observable.

AI can produce skeleton tests or BDD-style scenarios. These aren’t replacements for skilled testers; they’re conversation starters. They give stakeholders something to react to beyond words on a page.

Design Without Premature Commitments

An enterprise can’t freeze design while it gathers requirements. Work happens in parallel. The trick is to reduce irreversible choices while knowledge is still forming. Name decisions clearly. Record assumptions. Keep a short, living risk log. Teach teams to treat early choices as pilots rather than monuments.

When AI spots language that looks like a design prescription disguised as a requirement, it can ask: “Is this a requirement or a design decision?” That question, asked at the right moment, protects future flexibility.

The Reference Architecture, Told as a Story

Imagine a river with six gentle falls from source to basin.

1. Sources: Raindrops of information—emails, chats, tickets, transcripts, policies—gather into streams.
2. Ingestion: The river is filtered. Sediment is removed; rocks are tagged. Audio becomes text; PDFs become paragraphs.
3. AI Processing: The water clears. Patterns appear. Similar stones cluster together. Outliers stand out. Drafts form.
4. Standardization & Compliance: The river runs through a straight channel. Entries take a shape—the one-pager structure everyone knows. Compliance checks the banks.
5. Output & Integration: The water feeds fields. Repositories get updated. Dashboards show coverage. Stakeholders see what they need without squinting.
6. Governance & Feedback: Sensors along the banks note changes. People review, correct, and refine. The river learns, season after season.

This isn’t poetry for its own sake. It’s a reminder that movement matters. Stagnant pools breed bugs. Flow turns mess into value.

Compliance Isn’t a Department; It’s a Habit

Compliance teams are often cast as the people who say “no.” That’s unfair and unwise. Treat them as partners early. Ask which obligations carry strict wording and which allow interpretation. Capture those constraints as requirements with IDs of their own. Tie them to tests that can be run often.

When obligations change—and they do—AI can highlight affected requirements and tests. What could be a scramble becomes a checklist.

Observability Starts at Requirements Time

You can’t operate what you can’t see. If a requirement is important enough to build, it’s important enough to observe. That means attaching an operational signal to it: a log line, a metric, an alert condition. “Customers receive order confirmations within two minutes” becomes real when there’s a timer to measure it and a report that shows performance across days.

AI can suggest observability hooks. It can remind teams that done is more than merged: it’s measurable in production.

The Human Loop: Reviews That People Don’t Dread

No one wakes up excited for a two-hour requirement review. Make them shorter, more frequent, and focused. Send pre-reads. Start with the riskiest or most ambiguous items. Time-box the rest. Use comments rather than monologues. Celebrate deletions—dead requirements don’t haunt releases.

AI can tee this up by sorting items by risk, novelty, and dependency. It can remind you that REQ-208 touches three services and affects a holiday season peak. That little nudge shapes the meeting agenda in a useful way.

Metrics That Actually Help

Measure what improves behavior, not what looks tidy on a dashboard.

Useful signals include:

• Ambiguity rate: Share of entries with flagged vague terms, trending down over sprints.
• Coverage: Percentage of requirements with linked tests and code.
• Change clarity: Fraction of scope changes with an impact note and decision record.
• Lead time: Days from requirement proposed to verified.
• Defect linkage: Bugs traced back to missing or unclear requirements.

If a metric triggers gaming, toss it. If it sparks a real conversation, keep it.

AI Pitfalls—and How to Avoid Them

AI is powerful and fallible. Four traps to watch:

1. Overconfidence: A smooth summary doesn’t equal truth. Keep the review step. Always.
2. Drift: Models learn from new data. That’s good until it isn’t. Schedule checks. Keep a small, curated set of gold-standard examples.
3. Privacy: Requirements often include sensitive context. Govern who sees what. Mask data where you can.
4. Bias: If past projects sidelined certain needs, a model can learn that habit. Counter with explicit guardrails—non-functional prompts, compliance lists, diversity of inputs.

The antidote to all four is the same: human judgment and simple rules you actually follow.

A 30–60–90 Day Adoption Plan

You can’t flip a switch and change culture. You can, however, stack small wins.

Days 1–30

• Write the one-page standard and socialize it.
• Pick one pilot team and one product slice.
• Turn transcripts and emails into draft entries using AI; review together.
• Add IDs to commits and tests. Keep it simple.

Days 31–60

• Start change notes for scope shifts. Short, factual, linked.
• Add ambiguity checks to your definition of ready.
• Publish a tiny dashboard: coverage, ambiguity rate, lead time.

Days 61–90

• Tie key requirements to observability signals.
• Establish a rotating review squad from different functions.
• Hold a retrospective: what to keep, what to drop, what to refine.

Three months won’t fix everything. It will build momentum and trust.

Global Teams, Local Realities

Large enterprises span cultures and time zones. Words carry different weight in different places. A “yes” may mean “I hear you,” not “I agree.” A “quick change” may be polite shorthand for “this is strategically important.”

Write requirements for a global audience: clear, literal, free of local idioms. Pair async reviews with short live sessions. Rotate meeting times so the same region isn’t always drinking midnight coffee. Small signals of respect buy a lot of goodwill.

Vendor and Partner Dance

Few enterprises build alone. Partners bring expertise and capacity—and their own habits. Share your standard early. Ask theirs. Map the differences. Keep a shared glossary. If IDs differ across systems, set up a translation table rather than fighting over naming.

Change control is trickier with external parties. AI can help by tracking cross-organization dependencies and reminding both sides when a decision in one place affects a milestone in another. Clear beats clever. Repetition beats surprise.

Security as a First-Class Requirement

Security isn’t a feature; it’s a property. Treat it like performance—measurable, discussed early, tracked over time. Define what “secure” means in context: encryption at rest and in transit, key rotation, session policies, rate limits, audit trails. Write them down as requirements with acceptance criteria you can test, not as warnings in a slide deck.

AI can surface typical gaps and flag risky phrasing. It’s not a gatekeeper; it’s a flashlight.

Accessibility Is Not a Nice-to-Have

If your system can’t be used by people with different abilities, you’ve limited your market and invited risk. More importantly, you’ve missed the point of building software for humans. Bake accessibility into requirements, not as a catch-all note but as specific, testable statements: keyboard navigation, color contrast, screen reader support, captions. Treat this like any other quality—not optional, not later.

Performance in the Real World

Response times that look fine in a lab can crumble under peak traffic. Tie requirements to realistic loads and seasonal patterns. A retail site behaves differently in late November than in April. A travel platform shifts with holiday waves. Name those periods in your requirements. Attach test data that mirrors them. Add watchpoints to production and review them together.

The Power of Deletion

It’s thrilling to add requirements. It’s wise to retire them. Old constraints linger longer than anyone expects. Every quarter, ask: which requirements no longer reflect reality? Which were temporary? Which emerged from a workaround that no longer exists? Deleting with care is a mark of maturity.

AI can propose candidates for retirement by spotting unused test links or code paths with no recent activity tied to them. Use judgment, not autopilot—but have the conversation.

Story-Driven Templates That People Actually Use

Templates fail when they fight the way people think. Make them conversational:

• As a [role], I need [capability], so [benefit].
• Because [risk/goal], the system shall [observable behavior].
• We’ll know we’re done when [acceptance criterion].

This blend of story and verification lowers the barrier for non-engineers and keeps engineers focused on outcomes. AI can keep the cadence consistent without turning it robotic.

When Speed Matters—and When It Doesn’t

Not every requirement needs a stopwatch. Some need clarity of flow or completeness of data. Be selective. Over-quantifying everything can produce a forest of numbers no one respects. Under-quantifying breeds drift. Strike balance through review and experience. Encourage teams to annotate why a metric was chosen or why a narrative standard suffices.

Frequently Asked (and Quietly Worried) Questions

“Will AI replace our analysts?” No. It will make their work saner by taking on the tedious parts. The hard work—trade-offs, negotiation, context—stays human.

“Can we trust automated links and summaries?” Treat them as drafts. Validate, correct, and move on. Over time, quality improves.

“What about sensitive content?” Define clear handling rules. Mask where feasible. Limit who can view raw sources. Keep logs of access.

“How do we keep from drowning in process?” Keep the standard short. Measure few things well. Review little and often. If a step doesn’t help, drop it.

A Seasonal Note: Peak Season Pressure

Every enterprise has its crunch periods. Year-end closing. Summer travel spikes. Holiday shopping. Write seasonality into requirements. Tie rehearsal drills to those waves. Let AI look back at last year’s signals and remind you where things creaked. Future you will send a thank-you note.

Closing: Quiet Confidence Over Noise

Strong requirements work doesn’t shout. It reads clean, tells a clear story, and leaves traces you can follow months later. With AI as a steady helper, you’ll catch ambiguity sooner, fill gaps faster, and handle change with fewer theatrics. The craft becomes calmer. Release nights feel less like cliff dives and more like well-timed steps.

That’s the point—not ceremony, not perfection. Just steady outcomes that match what people actually need. Less chaos. More quiet confidence. And software that does the job.