Good Requirements Are More Than Good Sentences

A requirement can be clearly written, unambiguous and formally correct – and still provide only limited value to an engineering process. It may describe precisely what a system is expected to do without explaining why that capability is needed, which higher-level need it originates from, which other requirements depend on it or how its fulfilment will eventually be demonstrated.

This is one of the central challenges of Requirements Engineering. Good requirements are not created by good wording alone. Their real value emerges when they are embedded in a traceable context that connects stakeholder needs, technical decisions, architecture, implementation and verification.

ISO/IEC/IEEE 29148:2018 accordingly treats Requirements Engineering as a lifecycle process rather than merely an activity for producing specifications. The standard addresses requirements and the associated information items across the lifecycle of systems and software.

This also changes the way requirement quality should be assessed. The decisive question is not only whether a sentence is well written, but whether the requirement can be understood, justified, traced, changed and verified throughout the engineering process.

A good sentence is only the beginning

The linguistic quality of a requirement remains important. Ambiguous terms, multiple statements combined into one requirement, subjective wording or properties that cannot be objectively assessed all create room for interpretation and therefore technical risk. It is consequently useful to formulate requirements according to established rules and review them systematically for clarity, consistency and verifiability.

INCOSE addresses this subject directly in its Guide to Writing Requirements. The guide considers the characteristics of well-formed needs and requirements, rules for writing them and the attributes that can complement the actual requirement statement to form a more complete requirement expression.

That final point is particularly important. In an engineering context, a requirement does not necessarily consist only of the sentence visible in a specification. Additional information may include its source, rationale, priority, status, responsibility, relationships to other requirements or the intended verification approach.

The sentence is therefore the core of the requirement, but not its entire meaning.

A formally excellent requirement might, for example, state that a system must respond within a specific period of time. Without additional context, however, it may remain unclear why precisely that limit exists. Does it originate from higher-level system behaviour, an external interface, a safety consideration or merely an early design assumption? If that origin cannot be traced, it also becomes difficult to judge what should happen when the value is challenged or changed later.

Good wording reduces ambiguity. Good Requirements Engineering additionally creates context.

From need to technical requirement

Requirements do not emerge in isolation. They usually originate from a need, expectation, objective, constraint or problem that is to be addressed. During development, these inputs are progressively transformed into more concrete technical statements that are distributed across different system levels, functions and components.

This transformation is not simply an act of translation. It requires interpretation and technical decision-making.

A stakeholder may, for example, expect a system to respond quickly in a particular situation. This describes desired behaviour, but it does not necessarily define which component must meet which response time. Only through architecture, functional decomposition and technical analysis are more specific requirements allocated to individual system elements.

NASA describes Technical Requirements Definition accordingly as an iterative and recursive process in which stakeholder expectations are progressively transformed into validated technical requirements and developed further across lower product and component levels. The process addresses not only functions and performance, but also relationships, interfaces, constraints and relevant interactions with other systems and people.

Every technical requirement therefore has a history. It was derived from something, allocated somewhere or introduced because a technical decision made it necessary.

Understanding that history matters because it explains the role a requirement plays within the overall system. Without it, a specification may contain many technically plausible statements while still leaving unclear whether those statements collectively satisfy the original need.

Requirements Engineering therefore has to work in both directions: from stakeholder need towards technical detail, and from a specific technical requirement back to the question of why it exists at all.

A requirement needs context

A requirement statement is often deliberately kept concise and precise. That is sensible because the requirement and its explanation serve different purposes. The requirement itself should state what is expected, while its rationale may explain why that expectation exists.

For precisely this reason, omitting the rationale entirely can become problematic.

NASA explicitly recommends documenting rationale when defining technical requirements. This can include the reason for the requirement, underlying assumptions, relationships to the concept of operations and relevant design constraints. If a requirement, for example, prescribes a particular implementation method, it should be possible to understand why design freedom was intentionally restricted at that point.

This contextual information becomes particularly valuable as a project evolves. At the time a requirement is created, the people involved usually still remember why a particular decision was made. Months or years later, that knowledge may no longer be readily available because team members have changed, architectural decisions have evolved or the original discussion is no longer present.

What remains is the statement stored in the tool.

Without documented decision logic, a requirement can acquire an apparently unquestionable status even though it may originally have resulted from an assumption that is no longer valid. Conversely, a requirement that appears easy to change may in fact protect an important system decision whose context is no longer visible.

Rationale therefore does not mean documenting every technical thought in detail. It means preserving enough context for future decisions to remain grounded in the technical reasoning that led to the requirement.

Traceability is more than a collection of links

Traceability can quickly be reduced to a formal project obligation: requirements have to be linked. The result is a network of parent-child relationships, references between system and software requirements, or connections to verification cases.

The mere existence of these links, however, does not guarantee useful traceability.

NASA defines traceability in terms of identifiable relationships between logical entities such as requirements, system elements, verification activities or tasks, and describes bidirectional traceability as the ability to trace a requirement both upwards to its origin and downwards to derived requirements. Requirements Management maintains this continuity across stakeholder expectations, technical requirements, component requirements, design information, test plans and procedures.

The engineering value therefore lies not in the link itself, but in the question that link allows us to answer.

For a derived requirement, it should be possible to understand which aspect of a higher-level need it satisfies. For a system requirement, it should be visible which lower-level elements realise it. When a change is proposed, it should become possible to identify which other requirements, architectural elements or verification activities may be affected.

Traceability therefore becomes a model of dependencies within the engineering process.

A large matrix containing thousands of links can still deliver little value if the meaning of those relationships is unclear. Conversely, a relatively simple trace structure can be highly effective when the meaning of each relationship is defined and when those relationships support concrete engineering decisions.

The relevant quality question is therefore not:

Are the requirements linked?

It is:

Can we use those relationships to answer engineering questions reliably?

Without rationale, change becomes expensive

Requirements change. Stakeholders refine their expectations, architectural decisions evolve, technical constraints shift, testing reveals new information and previously unknown dependencies become visible.

Requirements Management should therefore not attempt to prevent change. Its purpose is to make change controlled and its consequences understandable.

This is where traceability and rationale come together.

When a requirement is to be changed, two fundamentally different questions need to be answered. The first is where the requirement came from and why it exists. The second is which other elements may be affected by changing it.

Rationale supports the first question; traceability supports the second.

If either is missing, impact analysis quickly becomes a manual reconstruction exercise. Teams then have to search through documents, version histories, architectural knowledge and personal memories to understand why a value was originally selected and what consequences changing it might have.

NASA therefore treats Requirements Management as a lifecycle process in which proposed changes to requirement baselines are assessed and approved changes are implemented in a controlled manner. At the same time, consistency must be maintained between requirements, the concept of operations and the architecture or design.

A well-structured requirement landscape therefore does more than reduce mistakes during initial specification. It also reduces the cost of future decisions because relationships do not need to be reconstructed every time a change occurs.

Verification begins while writing the requirement

Verification often takes place much later in the project than requirement definition. Methodologically, however, the two activities should be closely connected.

Even while a requirement is being written, the team should consider how it will later be possible to determine objectively whether the requirement has been fulfilled. If no credible answer exists, the requirement itself is often not yet sufficiently understood.

NASA includes individual verifiability among the characteristics expected of technical requirements and requires sufficient information to determine after product realisation whether the requirement has been satisfied. The NASA Systems Engineering Handbook therefore contains not only guidance for writing requirements but also the concept of a Requirements Verification Matrix.

Bringing verification into the discussion early changes the quality of the requirement conversation.

A statement such as “The system shall respond quickly” is already problematic from a linguistic perspective. The verification question immediately makes the missing information even more obvious: what response time is acceptable, between which events is it measured, under which conditions does the limit apply, and what result constitutes successful compliance?

Verification therefore acts backwards on requirement quality.

It forces the requirement to be considered from the perspective of future evidence and helps prevent unclear expectations from becoming testing problems only at the end of development.

Good Requirements Engineering consequently does not treat a test case merely as a downstream artefact. The basic verification logic should already be considered when the requirement is defined.

Verification and validation answer different questions

Verification and validation are often presented as a simple pair of opposing concepts. In Requirements Engineering, however, a more precise distinction is useful because both terms can apply to the requirements themselves and later to the realised system.

At the requirements level, ISO/IEC/IEEE 29148 uses Requirements Verification to describe checking whether individual requirements and the requirement set are well formed. This includes characteristics such as clarity, consistency, appropriate structure and fundamental verifiability. Requirements Validation, by contrast, asks whether those requirements actually define the right system – in other words, whether they adequately represent the intended stakeholder needs and expectations.

Requirements can therefore be formally excellent while still being inappropriate in substance. A requirement may be unambiguous, measurable and technically consistent, yet still originate from an incorrect interpretation of the stakeholder need. Conversely, an expectation may be correct in principle but expressed so poorly that it cannot be implemented reliably or objectively demonstrated later. Requirements Verification and Requirements Validation therefore address different quality dimensions of the same information.

Once a product or system has been realised, the perspective shifts. Verification then provides objective evidence that the specified requirements have been fulfilled. Validation considers whether the realised result actually fulfils its intended purpose and stakeholder expectations in the intended operational context. NASA captures this distinction with the familiar contrast between building the product right and building the right product.

These two levels should not be confused. A requirement can first be verified and validated before the system developed from it is later verified against its specification and validated against its intended purpose. This distinction illustrates why Requirements Engineering extends far beyond writing individual statements: requirement quality needs to be assessed before implementation, while technical compliance and fitness for purpose can only be demonstrated as development progresses.

The quality of individual requirements is not enough

Another common mistake is to assess requirement quality only at the level of individual statements. Every requirement may be clear, unambiguous and verifiable on its own while the overall requirement set remains incomplete or internally inconsistent.

A system is not specified by a single requirement, but by a network of requirements, constraints and relationships.

The quality of the requirement set therefore matters as well. Are all relevant functions covered? Are performance characteristics sufficiently defined? Do requirements on different system levels contradict each other? Has a higher-level need been fully decomposed, or has part of it disappeared during allocation? Are there requirements with no identifiable origin or higher-level objectives that are not realised at lower levels?

NASA recommends using traceability to determine whether higher-level requirements have been fully allocated to lower levels. Requirements without an identifiable parent should either be consciously justified as derived technical requirements or examined critically to determine whether they are needed at all.

Completeness therefore has a systemic meaning. It is not enough for every line in a specification to look formally correct. What matters is whether the requirement set as a whole provides a coherent description of the problem to be solved.

A good review should consequently look both horizontally and vertically: horizontally across requirements at the same level and vertically along their derivation through the system hierarchy.

Change reveals the quality of the structure

As long as a project remains stable, even a weakly structured requirement landscape can appear to work. The people involved know the context, many relationships exist in the team’s implicit knowledge and decisions are passed on informally.

Change reveals how robust that structure really is.

When a stakeholder expectation changes, it should be possible to determine which system requirements are affected. If system requirements change, the relevant components, interfaces and verification activities should become visible. If an architectural decision changes, new or modified requirements may result in turn.

Requirements Engineering is therefore not a linear process that ends when a specification is complete. The relationship between need, requirement, architecture and evidence evolves throughout the lifecycle.

ISO/IEC/IEEE 29148 accordingly treats Requirements Engineering as a lifecycle discipline and connects requirement definition, management and associated information items across the development lifecycle.

A good requirement structure therefore has to do more than represent today’s state. It needs to survive future change.

The real test of its quality is often not how tidy the specification looks immediately after creation, but whether six months later a team can still explain reliably what a proposed change affects and why the affected requirements were defined in the first place.

Requirements connect disciplines

Requirements are often associated with a Requirements Engineer or with a particular phase of a development process. In complex technical systems, however, they are better understood as shared engineering objects that connect several disciplines.

Stakeholders contribute needs and constraints. Systems Engineering structures them and develops technical requirements. Architecture and specialist disciplines refine and allocate those requirements further. Software, electrical, mechanical and other engineering domains implement them. Test and verification teams then use those same requirements as a reference for demonstrating compliance.

Requirements therefore sit directly at the transitions between different perspectives.

This is why document quality alone is not sufficient. A requirement must serve several purposes at once: it must be technically precise enough to support implementation, contain enough context for reviews and future change, fit into the system structure and provide a credible basis for later verification.

The INCOSE Requirements Working Group consequently considers needs and requirements in direct connection with their definition, management, verification and validation throughout the lifecycle, while also promoting the evolution of Systems Engineering from document-centric towards more data-centric ways of working.

This highlights an important distinction between a requirement as a sentence and a requirement as an engineering object. The sentence communicates an expectation. The engineering object connects different disciplines and phases.

The better that connection works, the less information is lost at the transitions between definition, architecture, implementation and verification.

Tools do not replace decision logic

Modern Requirements Management tools can manage large amounts of structured information. They support attributes, baselines, versions, traceability, reviews, status models and links to other engineering artefacts.

This can make a significant contribution to managing complex systems.

It does not automatically solve the underlying requirements problem.

A tool can store a link between two requirements, but it cannot determine whether the relationship is technically meaningful. It can provide a rationale field without ensuring that the rationale contains useful information. It can store a status of “verified” without judging whether the underlying evidence is actually appropriate.

Poor requirements therefore initially become only more systematically stored when a better tool is introduced.

The same applies to the frequent debate between document-centric and data- or model-centric approaches. Structured data creates new possibilities for analysis, consistency checking, automated reporting and impact analysis. Its value, however, depends on whether the underlying relationships and attributes have been defined in a technically meaningful way.

The central question should therefore not be which tool offers the largest number of functions. What matters is which information the engineering process actually needs, which relationships between that information are relevant and which decisions those relationships are intended to support.

Only once this logic is clear can a tool represent it effectively.

A pragmatic quality model

Requirements Engineering can quickly appear complex, particularly when standards, tools, traceability models and different system levels are considered simultaneously. In practice, however, requirement quality can be reduced to a set of closely connected questions.

First, the expectation itself needs to be understandable. It must be clear which behaviour, property or constraint is required and under which conditions it applies. At the same time, it should be possible to understand where the requirement comes from and why it is needed. This allows the team to judge whether it is genuinely necessary and which higher-level expectation it supports.

Its position within the system must then be visible. Which other requirements does it derive from, which system elements are affected and which lower-level requirements result from it? These relationships provide the foundation for traceability and later impact analysis.

The way compliance will be demonstrated should also be considered early. This does not initially require a complete test case, but it does require a credible answer to whether objective acceptance criteria and an appropriate verification approach exist.

Finally, the requirement must remain manageable when change occurs. Changes need an assessment that considers both the original rationale and the impact on connected requirements, architecture and verification activities.

These questions lead to a relatively simple model:

What is required? Why is it required? Where does it come from? What is it connected to? How will it be demonstrated? What happens if it changes?

If these questions can be answered, a requirement provides substantially more engineering value than an isolated, well-written sentence.

Good requirements create decision capability

Requirements Engineering is often understood primarily as a way to prevent misunderstandings between customers and developers. That is an important purpose, but it is too narrow.

A good requirement structure primarily creates decision capability.

It allows teams to understand why a technical expectation exists, what consequences a change may have and which evidence is required before decisions are made. It exposes where expectations have not yet been sufficiently clarified, which assumptions an architecture is based on and where changes may affect other system elements.

Requirements thereby become part of a project’s technical memory.

They do not preserve every discussion and they do not replace engineering expertise or direct communication. They preserve, however, the information required for technical decisions to remain understandable even when systems, teams and constraints change.

Good requirements are therefore more than precise statements about what a system is expected to do. They connect needs with technical definition, technical decisions with their rationale, architecture with implementation and requirements with verification.

A good sentence remains important. But only through its relationships does it acquire its full value for engineering.

The quality of a requirement is determined not only by how clearly it is written, but by how reliably it supports decisions throughout the engineering process.