Articles

How Open Are You to Feedback? Your Requirements Should Be, Too

Requirements don’t just come from stakeholders — they live in people, systems, and documents. The broader your sources, the fewer blind spots you’ll have.

The Interview: A Quiet Superpower in Requirements Engineering

We often focus on diagrams, tools, or templates — but one of the most effective elicitation tools is far simpler: a well-structured interview.

What’s Better Than a Great Requirements Engineer?

A team where the RE thrives. Even the most skilled RE can only go so far alone — but in a well-functioning team, results go further, faster, and deeper.

AI in Requirements Engineering: Where It Helps — and Where It Never Will

Everyone talks about AI taking over jobs. Here’s where it genuinely helps in RE — and the parts of the work it simply can’t replace.

Brainstorming in Requirements Engineering: When Quantity Beats Quality (At First)

Ever sat in a brainstorming session that felt messy and aimless? There’s a method to that chaos — and knowing it changes how you run elicitation workshops.

When Requirements Engineering Meets Silence and Shrugging

A fellow RE shared a situation where stakeholders simply stopped engaging. Here’s what was really happening — and how to move forward when you hit a wall.

What Level Are Your Requirements?

One of the most overlooked causes of confusion in requirements engineering is mismatched abstraction levels. Here’s how to identify the problem and fix it.

Changes: From Request to Reality

Every project eventually faces Change Requests. Here’s a practical look at how to handle them in a way that keeps requirements traceable and the team aligned.

When Team Conflicts Block Requirements Engineering: What You Can (and Can’t) Control

In RE we expect conflicts around content — scope, feasibility, priorities. But what happens when the conflict is about people? Here’s what you can actually influence.

Requirements Dashboards: Seeing the Bigger Picture

Dashboards are more than visual displays — they deliver clarity, traceability, and cross-team alignment. Here’s what a requirements dashboard should show, and where most go wrong.

Apprenticing as a Requirements Engineer: Lessons from the Test Floor

Observing stakeholders isn't always enough. Sometimes the sharpest requirements come from spending a week on the test floor, running cases side by side with the people who live the system every day.

The RE Process: The Most Overlooked Work Product

The requirements engineering process is not background infrastructure — it is a work product with a lifecycle, stakeholders, and KPIs. Here's what process maturity actually looks like.

Avoiding Transformation Effects in Requirements Engineering

Two people hear the same stakeholder and walk away with different understandings. This is the transformation effect — and knowing how to counteract deletion, generalisation, and distortion is where requirements quality is built.

Variant Management in Requirements Engineering: One Size Doesn't Fit All

Most products come in more than one form. Without explicit variant management, projects either overspecify or underspecify — both leading to waste. Here's how to make variability visible and manageable.

Mind Mapping in Requirements Engineering: Making Complexity Visual

Linear formats capture ideas but hide relationships. Mind maps do the opposite — and in elicitation workshops, that difference changes how stakeholders engage and what gets discovered.

Observation in Requirements Engineering: Watching Without Interfering

Users rarely behave as they describe. Observation is the elicitation technique that reaches what interviews miss — the workarounds, the missing features, and the integration gaps hidden in plain sight.

Skills of a Requirements Engineer: Part 1 of 3

The CPRE Elicitation Handbook identifies ten soft skills beneath the techniques. Part 1 covers Communication, Courtesy, Flexibility, and Integrity — and why the real question is whether you hold yourself to the same standard.

Skills of a Requirements Engineer: Part 2 of 3

Part 2 of the soft skills series: Empathy, Creativity, Independence, and Reliability. The more of these sensors are active, the more confidently you can focus on the work itself.

Skills of a Requirements Engineer: Part 3 of 3

The final two soft skills: Self-Confidence and Tolerance. And why the real strength of a Requirements Engineer isn't in mastering one skill — it's in switching between all ten seamlessly.

Requirements Conflicts: Identification

Conflicts in requirements are structural, not exceptional. The question is whether they are found during elicitation — or during integration testing, when the cost is far higher.

Overview of Requirements Topics: How They Connect

A reflection on the range of topics in the series — from pragmatic tools like dashboards and mind maps to longer-term challenges like process maturity and conflict management. And an honest question: where do you need more clarity?

Functional Requirements: What Are They, Really?

Functional requirements define what a system shall do — but the definition alone doesn't tell you how to write one well. Here's what they look like at different abstraction levels, with a real product example.

Performance Requirements: Time Behavior

Time behavior requirements constrain when the system must act, not just what it must do. Here's what they cover, why they matter, and what they look like across abstraction levels.

Performance Requirements: Resource Utilization

Every system runs on a finite budget of CPU, memory, bandwidth, and power. Resource utilization requirements make those budgets explicit — before the system is built, not after.

Traceability of Requirements: Why It Matters

Traceability is not just documentation overhead. It is what makes consistency verifiable, change manageable, and coverage provable. Here are the three reasons it belongs in every serious RE process.

ASPICE Base Practice 1: Specifying Lower-Level Requirements

Decomposition in ASPICE is not just splitting requirements into smaller pieces. It means deriving lower-level requirements that implement the intent of higher-level ones — with traceability and consistency maintained across the hierarchy.

Performance Requirements: Capacity

Capacity requirements specify how much a system can take or deliver — not how fast, but how much. Here is what they cover and why getting the upper bounds right matters before the system is built.

Capacity Requirements vs. Constraints: Knowing the Difference

Capacity and constraints are easy to confuse — but they are opposites. One defines what the system can do; the other limits how much it is allowed to spend doing it. The verbs you choose reveal which one you mean.

Requirements Management Tools: The Mandatory Aspects

A requirements tool is not just a fancier spreadsheet. Here is what any serious requirements management solution must be able to do — and where Excel-style approaches start to break down.

Requirements Management Tools: The Optional Aspects

Beyond the basics, the right optional features in a requirements tool can eliminate significant manual overhead. Here is what to look for — and what is worth paying for.

ASPICE Base Practice 2: Structure Requirements

Structuring requirements is not just organisation for its own sake. In ASPICE, how requirements are structured determines whether they can be managed, assessed, and maintained across the full project lifecycle.

Functional Safety Requirements: An Introduction

Functional safety adds a layer of requirements that most RE frameworks don't cover by default. Here is what ISO 26262 means for requirements work — and why safety requirements are a different kind of specification.

Stakeholder Relationship Management: The Human Side of RE

Requirements engineering is often discussed in terms of techniques and artefacts. But requirements always come from people — and the quality of the relationship determines the quality of the feedback.

The Requirements Team Paradox

Requirements teams need authority to function but rarely have direct authority. They must know the domain deeply but stay independent. They satisfy stakeholders who disagree. Here’s how to navigate it.

Reliability Requirements: Applied on Coffee Grinders

Maturity, availability, fault tolerance, recoverability — the four sub-characteristics of reliability, illustrated with an example you didn’t expect but won’t forget.

INCOSE Guide: Writing Accurate Requirements

Accuracy in requirements means the stated need correctly reflects the real need — with the right technical terms, validated data, and no guessed tolerances. Here are the rules and how to spot violations.

ASPICE Base Practice 3: Analyze Requirements

Most teams read a requirement, nod, and mark it done. That’s not analysis — that’s a checkbox. BP3 demands two lenses: technical feasibility and planning impact. Here’s what each one looks for.

Walkthrough: Requirements Validation

What is the first step to validating requirements that is process-compliant and delivers results with minimum effort? A walkthrough — and here’s how to run one.

Prompt Engineering for Requirements Engineering: An Intro

LLMs can assist with RE tasks — but only if you know how to prompt them well. The RTF pattern (Role, Task, Format) is a practical starting point, with examples built specifically for requirements work.

INCOSE Guide: Writing Non-Ambiguous Requirements

Non-ambiguity means exactly one valid interpretation. Here are the rules that get you there — and the violations that silently undermine requirements that look fine on the surface.

Pitfalls in RE: Requirements Change Too Often — So Why Write Them Down?

If requirements always change, why document them? Because writing them down gives you something to change. That's what makes the product better — and the change manageable.

Security Requirements: Confidentiality

"Confidentiality" in a requirement is not a specification — it's a direction. Who is authorised? View or retrieve? Which data, explicitly? Here's how to make confidentiality requirements precise enough to verify.

Requirements for Kids: Part 1

A five-year-old asked to remove napkins from beside her bed throws them on the floor. Then next to her dolls. Then, when told exactly where — in the bin — does it immediately. Sound familiar?

ASPICE Base Practice 4: Analyze the Impact on the Operational Environment

BP4 asks what happens beyond the software boundary when a feature runs. How does what you eat influence your health? It's kind of the same in ASPICE — consequences matter, not just functions.

INCOSE Guide: Writing Singular (Atomic) Requirements

One requirement, one statement of need. Compound requirements split accountability, complicate verification, and hide partial satisfaction. Here are the rules — and the ISO 26262 exception worth knowing.

Non-Functional Requirements: Compatibility vs Constraints

Compatibility focuses on information exchange and resource sharing — illustrated with a maps app running on both phone and CarPlay. A practical distinction that’s easy to blur in practice.