Requirements Engineering · Specification
Process
Process
Requirements Specification is the process step in which the outcomes of Requirements Analysis are formulated as precise, unambiguous and verifiable requirements.
IMPULS3 definition.
Requirements Specification is the systematic process of formalising analysed and agreed system meaning
into explicit requirements using consistent syntax, structure and terminology, while preserving the
intended meaning and traceability established during Requirements Analysis.
Information Element
People
Added value / output
Specification consumes decisions, not raw opinions. By the time information reaches this process step, the relevant stakeholder needs have been analysed, system-level meaning has been established and the engineering decisions that must be expressed have been made.
The task of Specification is therefore not to reconsider what the system should achieve, but to express those decisions in a form that can be reliably used for design, implementation, procurement, verification and validation. This requires deliberate wording, consistent structure, explicit quantification and traceability.
IMPULS3 principle. Specification does not introduce new meaning. It preserves and formalises meaning established during Analysis.
Input–Process–Output overview
Analysed and agreed system information
Analysed and agreed system information
- Analysis Statements
- Requirements Specification Outline
- Functions, Properties and Constraints identified during Analysis
- Agreed terminology, definitions and assumptions
- Applicable standards, templates and writing rules
- Higher-level Design Decisions, where applicable
Formalise analysed intent as requirements
- Translate Analysis Statements into well-formed requirements
- Apply consistent syntax, structure and terminology
- Distinguish Functions, Properties and Constraints
- Quantify Properties and make Constraints explicit
- Ensure each requirement is atomic, unambiguous and verifiable
- Preserve traceability to Analysis Statements and Stakeholder Needs
Explicit and verifiable requirements
Explicit and verifiable requirements
- Uniquely identified requirements
- Requirements structured according to the agreed outline
- Explicit Functions, quantified Properties and Constraints
- Clear verification intent
- Traceability to the originating Analysis Statements
- A coherent and internally consistent requirement set
Information flow through Specification
IMPULS3 distinguishes explicitly between an Analysis Statement and a Requirement. An Analysis Statement records an engineering conclusion. A Requirement formalises that conclusion as an explicit obligation for the system.
Inputs
Specification starts from information whose engineering meaning has already been established. The primary input is the Analysis Statement, supported by the structure, terminology and rules needed to express that meaning consistently.
Analysis Statements
Explicit conclusions from Requirements Analysis. They capture what has been reasoned and decided about the system and provide the primary semantic input to Specification.
Requirements Specification Outline
Requirements Specification Outline
The agreed structure in which requirements will be organised, typically around the system’s primary and secondary Functions, associated Properties and Constraints, followed by system-level Properties and Constraints.
Terminology and writing rules
Terminology and writing rules
Agreed definitions, controlled vocabulary, sentence patterns, templates, style guides and applicable organisational or project-specific writing conventions.
Higher-level engineering decisions
Higher-level engineering decisions
Where requirements are specified for a lower-level system element, higher-level Design Decisions may provide additional constraints or derived information that must be formalised at that level.
Activities
1 Select and understand the Analysis Statement
Identify the Analysis Statement that is ready to be formalised. Understand its meaning, rationale, assumptions and traceability before attempting to write a requirement.
2 Identify the system aspect
Determine whether the analysed statement concerns a Function, Property or Constraint. This semantic classification guides the form and content of the resulting requirement.
3 Formulate the requirement
Translate the analysed decision into a formal requirement using agreed syntax, terminology and sentence patterns. Each requirement should express one identifiable obligation.
4 Quantify Properties and make Constraints explicit
Functions describe what the system does and do not require numerical quantification merely to exist. Properties that become requirements must be measurable or bounded. Constraints must be stated explicitly enough to determine whether they are satisfied.
5 Build intrinsic quality into the requirement
Check the requirement while it is being specified. It should be unambiguous, atomic, quantified where applicable, consistent, verifiable and well structured. Undefined terms and unintended implementation bias should be avoided.
6 Structure and trace the requirement
Assign the requirement its place in the Requirements Specification Outline, give it a unique identity, record the relevant attributes and establish traceability to the Analysis Statement from which it was specified.
IMPULS3 principle. A Property becomes a requirement when the required characteristic is quantified or otherwise bounded so that satisfaction can be determined objectively.
Outputs
The primary output of Specification is a coherent set of explicit and verifiable Requirements. These requirements represent deliberate engineering commitments rather than provisional interpretations.
A requirement is more than its sentence. In practice, it forms a structured record consisting of the requirement core, supporting attributes and the metadata needed for identification, traceability, status and configuration control.
Primary output entity
- Requirement — an explicit and verifiable engineering commitment that formalises an analysed decision about the system.
Requirement record
- Core — the requirement statement itself.
- Attributes — for example type, rationale and verification information.
- Metadata — for example unique ID, status, version and traceability links.
The resulting requirements are organised according to the agreed Requirements Specification Outline and together form a coherent representation of what the system is required to achieve.
Process boundary: where does Specification begin and end?
Specification begins when the meaning of the relevant engineering information has been established sufficiently through Analysis to allow it to be expressed as a formal requirement. Questions about stakeholder intent, conflicts between needs or system-level consequences therefore belong to Analysis.
IMPULS3 principle. Do not use requirement wording to hide unfinished Analysis. If writing the requirement requires a new decision about what the system should do or how well it should perform, that decision must first be made explicitly.
Specification ends when the analysed intent has been expressed in requirements that are sufficiently precise, structured, traceable and verifiable to enter formal Requirements Verification & Validation.
Example
Stakeholder Need: “Production Operations needs the machine to support rapid cleaning in order to minimise production downtime between production runs.”
The 30-minute value is established during Analysis. Specification does not invent that value; it formalises the analysed decision as an explicit, measurable and traceable requirement.
Relationship with the subsequent process
Requirements Specification produces requirements that are intended to be precise, atomic, quantified where applicable, consistent and verifiable. These quality characteristics must already be considered during Specification rather than being added afterwards.
Requirements Verification & Validation subsequently assesses both the quality of the requirements themselves and their continued alignment with the analysed stakeholder intent. Requirements Management then preserves their identity, status, traceability, configuration and change throughout the lifecycle.
Requirements Engineering · Specification
Transformation Engine
The IMPULS3 Transformation Engine defines the rules by which analysed engineering information is transformed into explicit, structured and verifiable requirements. It formalises meaning without changing it and preserves the traceability to the Analysis from which each requirement originates.
During Specification, transformation does not mean deciding again what the system should achieve. The relevant engineering decisions have already been made during Analysis and captured in Analysis Statements, Functions, Properties and Constraints.
The Transformation Engine governs how that analysed meaning is committed to formal Requirements. It determines how system aspects are expressed, how Properties are quantified, how Constraints are stated explicitly, how Requirements are structured and how their relationship to the underlying Analysis remains visible.
Transformation overview
Analysed engineering information
- Analysis Statements
- Functions, Properties and Constraints
- Requirements Specification Outline
- Rationale and assumptions
- Agreed terminology and definitions
- Applicable standards, templates and writing rules
- Higher-level Design Decisions, where applicable
Formalise, quantify and structure
- Preserve analysed meaning
- Apply Function / Property / Constraint semantics
- Formulate one explicit obligation per Requirement
- Quantify required Properties
- Make Constraints explicit
- Apply agreed syntax and terminology
- Embed intrinsic quality
- Preserve semantic traceability
Explicit engineering commitments
- Formal Requirements
- Unique requirement identities
- Requirement attributes
- Requirement metadata
- Verification intent
- Traceability to Analysis Statements
- Structured Requirements Specification
Specification is not necessarily a one-to-one conversion
Formalising analysed information does not imply that every Analysis Statement becomes exactly one Requirement. The number and structure of Requirements depend on the engineering meaning that must be expressed clearly, atomically and verifiably.
One Analysis Statement may lead to several Requirements
An analytical conclusion may concern several distinct obligations. These are separated during Specification so that each Requirement remains atomic and can be verified independently.
Several Analysis Statements may support one Requirement
Several analytical conclusions may collectively establish the meaning or justification for a single Requirement. Their combined provenance must remain traceable.
One system aspect may require several formulations
A Function may have several associated Properties or Constraints. These different obligations may need to be expressed as separate Requirements while remaining semantically related.
Specification may expose unfinished Analysis
If a value, interpretation or engineering decision is still missing, Specification should not invent it. The unresolved issue is returned to Analysis before formalisation continues.
IMPULS3 principle. The number of Requirements is determined by the obligations that must be expressed clearly and verifiably, not by the number of Analysis Statements from which they originate.
Transformation rules
The Specification Transformation Engine is governed by a set of rules that preserve analysed intent while turning that intent into usable engineering commitments.
1 Preserve meaning
Requirement formulation may make information more explicit and precise, but it must not silently change the engineering decision established during Analysis.
2 Decision before formulation
A Requirement expresses an engineering decision; it is not the place where that decision should first be made. Unresolved engineering questions belong to Analysis.
3 Classification before formulation
Determine whether the information concerns a Function, Property or Constraint before deciding how it should be expressed as a Requirement. Semantic structure precedes wording.
4 Functions express behaviour
A Function describes what the system does. The existence of a Function is fundamentally binary: the required behaviour is provided or it is not. Performance characteristics belong to Properties.
5 Quantify Properties
Where a Property becomes a Requirement, its required value, limit, range, tolerance or other measurable criterion must be stated so that satisfaction can be determined objectively.
6 Make Constraints explicit
Restrictions on the solution space must be stated explicitly. References such as applicable legislation, standards, interfaces or mandated technologies must be sufficiently bounded to be meaningful.
7 One Requirement, one obligation
Each Requirement should express one identifiable engineering obligation. Separate independent obligations where necessary so that meaning, change and verification remain manageable.
8 Use controlled terminology
Requirements use agreed terms, definitions, syntax and sentence patterns. Undefined, subjective or ambiguous wording is avoided.
9 Design for verification
A Requirement must be formulated so that objective evidence can ultimately demonstrate whether the specified obligation has been satisfied.
10 Avoid unintended design bias
Requirement wording should describe the required result without prescribing an implementation unless that implementation choice is itself an agreed Constraint or a legitimate higher-level Design Decision.
11 Preserve traceability
Every Requirement remains explicitly related to the Analysis Statement from which it was specified. The semantic path back to Stakeholder Needs and Source Information must remain navigable.
12 Build quality in while specifying
Clarity, atomicity, quantification, consistency and verifiability are properties of the Requirement as it is created. Quality is not added afterwards.
From system aspect to Requirement
The fundamental IMPULS3 distinction between Function, Property and Constraint determines how analysed system information is formalised.
Function — F
A Function expresses what the System-of-Interest must do. The corresponding Requirement commits the system to providing that behaviour. Performance associated with the Function is expressed separately as Properties.
Property — P
A Property becomes a Requirement when the required characteristic is quantified or otherwise objectively bounded. Examples include capacity, accuracy, duration, availability, mass and response time.
Constraint — C
A Constraint Requirement makes a restriction on the permissible solution space explicit, for example compliance with a specified standard, interface, technology, physical boundary or regulation.
Formal Requirement
The resulting Requirement expresses an analysed Function, quantified Property or Constraint as an explicit engineering commitment with sufficient precision to support downstream engineering and verification.
IMPULS3 principle. First understand the nature of the system aspect; then choose the appropriate form of Requirement. Wording follows semantics, not the other way around.
Constructing the Requirement record
Specification does not produce isolated sentences. A Requirement is an identifiable and controlled Information Element that combines the obligation itself with the information required to understand, verify, trace and manage it.
Requirement Core
The normative statement that expresses the obligation placed on the System-of-Interest.
Requirement Attributes
Supporting engineering information such as Requirement type, rationale, verification intent and other information required for correct use and interpretation.
Requirement Metadata
Control information such as unique ID, status, version or revision and relevant traceability relations.
Controlled Information Element
Together, Core, Attributes and Metadata make the Requirement a first-class, version-controlled engineering Information Element rather than merely a sentence in a document.
Transformation patterns and traceability
The Transformation Engine preserves semantic relations rather than assuming a fixed one-to-one conversion chain.
Analysis Statement → Requirement
The common transformation pattern. An analysed engineering conclusion is formalised as an explicit Requirement.
One Analysis Statement → multiple Requirements
An analytical conclusion may contain several independent obligations that must be separated to preserve atomicity and verifiability.
Multiple Analysis Statements → one Requirement
Several analytical conclusions may collectively support a single obligation. The Requirement retains traceability to the relevant analytical basis.
Design Decision → derived Requirement
A legitimate higher-level Design Decision may impose an obligation on a lower-level system element. Such a Requirement is explicitly identified as derived from that Design Decision.
Example
Consider the analytical result concerning cleaning duration:
A maximum normal cleaning-cycle duration of 30 minutes is required to maintain the agreed production availability.
Property: Cleaning duration
Required value: ≤ 30 minutes
The Transformation Engine has not decided that 30 minutes is the appropriate value. That decision belongs to Analysis. Specification has formalised the analysed value as an explicit, measurable and traceable Requirement.
What the Transformation Engine does not do
The Specification Transformation Engine provides discipline for formalising analysed engineering information, but it does not replace Analysis, engineering judgement or subsequent Verification & Validation.
It does not determine new system meaning
Decisions about what the system should achieve belong to Analysis. Specification expresses those decisions; it does not silently create new ones.
It does not invent missing values
If a Property requires quantification but no justified value has yet been established, the issue must return to Analysis rather than being resolved through convenient wording.
It does not prove system compliance
Specification makes Requirements verifiable. Demonstrating that the realised system actually satisfies them belongs to subsequent verification activities.
It does not replace the engineer
Templates, patterns, quality rules and tools support good specification, but judgement and responsibility for the resulting Requirement remain with the engineering process and its participants.
Requirements Engineering · Specification
Information Model
The IMPULS3 Information Model defines the Information Elements used during Requirements Specification and the semantic relations between them. It connects formal Requirements to the analysed engineering information from which they originate and preserves their meaning, rationale and traceability throughout the lifecycle.
Analysis Statement
Structured specification
The Specification Information Model builds directly on the structured engineering information established during Analysis. Stakeholders, Stakeholder Needs, Source Information, Analysis Statements and identified Functions, Properties and Constraints remain part of the information network.
Specification adds a normative information layer. Analysed system meaning is formalised as uniquely identifiable Requirements, together with the attributes, metadata and semantic relations required to interpret, verify, manage and change them.
Core Information Elements
Source Information
Recorded information preserving what was communicated, written, observed or otherwise obtained from a source, together with its provenance and context.
During Specification, Source Information remains available as the ultimate evidential origin of the engineering information chain.
Stakeholder
The person, group, organisation or other party whose needs, expectations or responsibilities contributed to the engineering information being specified.
Stakeholder identity remains relevant for understanding why a Requirement exists and for subsequent validation.
Stakeholder Need
A documented expression of an outcome, capability, quality or condition needed by a stakeholder, together with the rationale explaining why it matters.
Stakeholder Needs remain the semantic origin against which the eventual Requirements can be validated.
Analysis Statement
An explicit statement capturing a relevant analytical conclusion, interpretation, assumption, clarification or other result of Analysis.
Analysis Statements form the principal semantic bridge between stakeholder information and formal Requirements.
Function
An aspect describing what the System-of-Interest does. Functions provide the behavioural structure within which functional Requirements are specified.
Property
An aspect describing a characteristic of the System-of-Interest or one of its Functions.
A Property becomes normative when its required value, range, limit, tolerance or other measurable criterion is specified.
Constraint
An aspect restricting the permissible solution space. During Specification, the applicable restriction is stated with the precision required to determine whether it is satisfied.
Requirement
An explicit and verifiable engineering commitment that formalises analysed system meaning as an obligation that the System-of-Interest must satisfy.
A Requirement may specify a Function, quantify a Property or make a Constraint normative and explicit.
The Requirement as a structured Information Element
Within IMPULS3, a Requirement is not merely a sentence in a document. It is a structured and controlled Information Element consisting of the normative statement itself and the additional engineering information required to interpret, trace, verify and manage it.
Requirement Core
The normative requirement statement expressing the obligation placed on the System-of-Interest.
The Core states what the system shall do, what characteristic it must achieve or which Constraint it must satisfy.
Requirement Attributes
Supporting engineering information that contributes to the correct interpretation and use of the Requirement.
- Requirement type
- Rationale
- Verification intent or method
- Applicability or conditions
- Other domain-specific attributes
Requirement Metadata
Information required to identify, control and manage the Requirement as an engineering configuration item.
- Unique ID
- Status
- Version or revision
- Traceability relations
- Configuration information
Requirement record
Core, Attributes and Metadata together form the complete Requirement record.
This makes the Requirement a first-class, version-controlled engineering Information Element rather than simply a line of text in a specification document.
Semantic relations
The value of the Specification Information Model lies not only in the Requirement itself, but in its semantic connections to the engineering information that explains where it came from, what it represents and how it is to be used.
Requirement ← Analysis Statement
A Requirement is specified from an Analysis Statement that records the engineering conclusion or decision being formalised.
Analysis Statement ← Stakeholder Need
The Analysis Statement retains the relation to the Stakeholder Need or Needs that contributed to the analytical conclusion.
Requirement ↔ Function
A functional Requirement may specify that the System-of-Interest must provide a particular Function.
Requirement ↔ Property
A Requirement may quantify or otherwise bound a Property of the System-of-Interest or one of its Functions.
Requirement ↔ Constraint
A Requirement may make an applicable Constraint explicit and normative.
Function ↔ Property
A Property may characterise a specific Function, for example its duration, capacity, accuracy, availability or response time.
Requirement ← Design Decision
Where a legitimate higher-level Design Decision imposes an obligation on a lower-level system element, a derived Requirement may be related explicitly to that Design Decision.
Requirement ↔ verification information
A Requirement establishes the verification intent that subsequent Verification activities use to determine how compliance can be demonstrated objectively.
From traceability chain to semantic network
A useful Requirements Information Model is not simply a table containing requirement identifiers and source identifiers. It preserves the meaning of the relations between engineering Information Elements.
This sequence describes the principal semantic path through Requirements Development. In practice, however, the information model must support one-to-many, many-to-one and other legitimate relations.
One Analysis Statement → multiple Requirements
An analytical conclusion may contain several independent obligations that must be expressed as separate Requirements.
Multiple Analysis Statements → one Requirement
Several analytical conclusions may together justify one formal Requirement.
One Function → multiple Requirements
A Function may be associated with its behavioural obligation and with several quantified Properties or applicable Constraints.
One Requirement → multiple downstream relations
A Requirement may subsequently be related to verification evidence, design information, procurement information and configuration information without losing its original analytical provenance.
IMPULS3 principle. Traceability preserves semantic provenance. A Requirement should remain connected to the analytical reasoning from which it was specified, rather than appearing as an isolated statement.
Structuring the Requirements Specification
Requirements are not organised arbitrarily. The Requirements Specification reflects the structured system view established during Analysis and provides a predictable semantic location for each Requirement.
Primary Function
Requirements concerning the primary Function of the System-of-Interest, together with its associated Properties and Constraints.
Secondary Functions
Requirements concerning supporting or secondary Functions, again structured together with their relevant Properties and Constraints.
System Properties
Requirements concerning characteristics that apply to the System-of-Interest as a whole rather than to one specific Function.
System Constraints
Requirements expressing restrictions that apply to the overall System-of-Interest and limit the permissible solution space.
IMPULS3 principle. The structure of the Requirements Specification should reflect the semantic structure of the System-of-Interest, not merely administrative categories or document conventions.
Example
Consider the analysed cleaning example:
Property: Cleaning duration
Required value: ≤ 30 minutes
The Requirement does not replace the Analysis Statement or the Property from which it was specified. These Information Elements remain connected so that the decision, its meaning and its normative expression can each be inspected independently.
Information Model boundary: a Requirement is not its source
Specification deliberately creates a new Information Element. The Requirement is related to the Analysis Statement from which it was specified, but the two are not interchangeable.
Keeping these Information Elements separate prevents analytical reasoning, rationale and assumptions from disappearing inside normative requirement wording.
IMPULS3 principle. Preserve identity across transformations. Information may become more precise and more formal, but the source, reasoning and resulting Requirement remain distinct and traceable Information Elements.
Relationship with Verification & Validation
The Specification Information Model provides the semantic foundation for subsequent Requirements Verification & Validation. Verification can inspect the Requirement as a formal engineering object, while Validation can follow its traceability path back through Analysis to the Stakeholder Needs and Source Information that explain why it exists.
Because Requirement Core, Attributes, Metadata and semantic relations are explicitly represented, quality assessment does not have to rely on the requirement sentence alone. The Requirement can be evaluated both as an individual engineering statement and in the context of the wider information network.
IMPULS3 principle. A Requirement is only fully meaningful in context: its wording, attributes, provenance and semantic relations together determine its engineering value.
Requirements Engineering · Specification
Tools & Techniques
Tools & Techniques
Requirements Specification uses techniques, patterns and supporting tools to transform analysed engineering decisions into precise, consistent and verifiable Requirements.
No single technique guarantees a good Requirement. Good Specification results from a disciplined combination of semantic understanding, appropriate sentence structure, quantification, controlled terminology, traceability and quality-conscious writing.
IMPULS3 therefore treats Tools & Techniques as a toolbox. The engineer selects the technique that best addresses the specific formulation problem while preserving the meaning established during Analysis.
Start with the specification question
A useful way to select a technique is to first identify what must be made explicit in the Requirement.
What kind of system aspect is being specified?
Determine whether the analysed information concerns a Function, Property or Constraint. The semantic nature of the information determines the appropriate formulation approach.
How should the obligation be expressed?
Use an agreed requirement sentence pattern or template to express the obligation consistently and without unnecessary ambiguity.
What must be quantified?
Identify Properties that require a value, limit, range, tolerance or other measurable criterion so that compliance can be assessed objectively.
Can the Requirement be verified?
Examine whether objective evidence could ultimately demonstrate that the stated obligation has been satisfied.
Core specification techniques
1 Requirement sentence patterns
Use agreed sentence structures to express system obligations in a predictable and consistent form.
Patterns reduce linguistic variation and help distinguish the subject, required behaviour, conditions and measurable criteria of the Requirement.
2 Function-based formulation
Formulate functional Requirements around the behaviour that the System-of-Interest must provide.
Functions express what the system does. Performance or quality characteristics associated with that behaviour are treated separately as Properties.
3 Property quantification
Convert an identified Property into a verifiable obligation by stating the required value, range, limit, tolerance or other measurable criterion.
Techniques such as Planguage support disciplined quantification and help replace vague expressions such as fast, high, reliable or easy with explicit engineering criteria. [Gilb2005]
4 Constraint formulation
Express restrictions on the permissible solution space explicitly and sufficiently precisely.
A Constraint should identify the applicable restriction rather than rely on broad expressions such as “all applicable standards” or similarly undefined references.
5 Atomic formulation
Express one identifiable obligation per Requirement.
Where a statement contains several independent obligations, separate them so that each can be understood, changed, traced and verified independently.
6 Controlled terminology
Use agreed terminology, definitions and vocabulary consistently. Undefined or overloaded words introduce unnecessary interpretation and weaken both specification and verification.
7 Verification-oriented formulation
Formulate the Requirement with objective verification in mind. Ask what evidence would demonstrate compliance and whether the wording supports an unambiguous pass/fail conclusion.
8 Semantic cross-check
Compare the drafted Requirement with the originating Analysis Statement and related engineering information.
Confirm that formulation has not silently added, omitted or changed the analysed meaning.
Writing methods and frameworks
Several established approaches can support disciplined Requirement formulation. They should be used as aids to engineering craftsmanship, not as substitutes for understanding the Information Element being specified.
Requirement templates
Organisation- or project-specific templates provide consistent structure for Requirement wording and associated information.
Templates are particularly useful for recurring types of Functions, Properties and Constraints.
EARS
EARS provides structured sentence patterns that can help formulate system behaviour and conditions consistently.
Its value lies in reducing avoidable linguistic variation while keeping the engineering meaning explicit.
Planguage
Planguage provides a disciplined approach for expressing measurable qualities and performance characteristics.
Within IMPULS3 it is particularly relevant when Properties must be quantified and turned into objective engineering commitments.
SMART
SMART can be used as a supporting quality lens when examining whether a Requirement is sufficiently specific and usable.
It complements, but does not replace, explicit IMPULS3 semantics and Requirement quality criteria.
SITIO
SITIO can be used as a structured aid when reviewing Requirement formulation and the information needed for clear engineering use.
As with other frameworks, its role is supportive: semantic correctness remains determined by the underlying engineering information. [Fischer2012]
Style guides and writing rules
Agreed rules concerning syntax, terminology, prohibited wording, sentence structure and notation help create a coherent Requirements Specification across multiple authors and disciplines.
IMPULS3 principle. A writing method can improve expression, but it cannot make an incorrect engineering decision correct. Semantic correctness precedes linguistic correctness.
Quality-aware specification
Requirement quality is created while the Requirement is being specified. It is not something that can be added reliably after the wording has already been completed.
Unambiguous
The Requirement should support one intended interpretation. Undefined terms, subjective adjectives and vague qualifiers should be eliminated or made explicit.
Atomic
The Requirement should express one obligation so that its meaning, status, change and verification can be managed independently.
Quantified where applicable
Properties must be measurable or otherwise objectively bounded when they form part of a normative Requirement.
Verifiable
The Requirement must permit objective determination of whether the specified obligation has been satisfied.
Consistent
Terminology, values, assumptions and obligations should not contradict other Requirements or the wider engineering information model.
Well structured
The Requirement should follow the agreed syntax, conventions and semantic structure of the Requirements Specification.
IMPULS3 principle. Quality is embedded in the act of Specification. A poorly specified obligation cannot be repaired reliably by downstream design, implementation or verification.
Supporting quality checks
Lightweight checks can help expose formulation problems while the Requirement is being written. These checks support Specification; formal Requirements Verification subsequently provides a separate quality assessment.
Ambiguity check
Look for words or sentence structures that permit multiple reasonable interpretations.
Atomicity check
Look for conjunctions or combined obligations that should be separated into independently managed Requirements.
Quantification check
Identify Properties that are still expressed qualitatively where measurable criteria are required.
Verification check
Ask whether objective evidence could establish compliance with the Requirement as currently written.
Terminology check
Confirm that important terms are defined and used consistently with the project vocabulary and Information Model.
Traceability check
Confirm that the Requirement is connected to the Analysis Statement or legitimate Design Decision from which the obligation originates.
Supporting tools
Requirements can be specified with simple or sophisticated tools. The important criterion is whether the tool preserves the Requirement as a structured Information Element together with its identity, attributes, metadata and semantic relations.
Requirements management systems
Support Requirement identity, attributes, metadata, traceability, status, versioning and controlled change.
Requirement templates
Provide reusable structures for common Requirement forms and help authors apply organisational writing conventions consistently.
Controlled vocabularies
Help maintain consistent terminology across Requirements, disciplines and authors.
Style guides
Capture agreed writing rules, sentence patterns, prohibited wording and project-specific conventions.
Structured spreadsheets
Can support lightweight Requirement records, attributes and traceability where a dedicated requirements management environment is not required.
Automated quality checks
Can help identify potential ambiguity, missing values, prohibited terms, malformed structures or missing metadata. Such checks flag possible issues; engineering judgement remains necessary.
Example
Consider the following analysed information:
Property: cleaning duration · Required value: ≤ 30 minutes
The technique improves the expression of the Requirement. It does not determine that 30 minutes is the correct value; that decision must already have been justified by Analysis.
Choosing the right technique
IMPULS3 does not prescribe one universal requirement-writing method. The appropriate technique depends on the kind of engineering information, the nature of the system aspect and the formulation problem that must be solved.
Function unclear?
Return to the Function identified during Analysis before attempting to improve the sentence wording.
Property vague?
Use quantification techniques such as Planguage and determine whether the analysed information provides a justified measurable criterion.
Sentence difficult to formulate?
Use a Requirement template, EARS pattern, controlled vocabulary or applicable style guide.
Requirement difficult to verify?
Re-examine the obligation, conditions and measurable criteria. If the underlying decision itself is unclear, return the issue to Analysis.
IMPULS3 principle. Specification is semantics first, formulation second. A perfectly structured sentence expressing the wrong engineering requirement is still a bad Requirement.
Requirements Engineering · Specification
IMPULS3 Principles for Specifying Requirements
IMPULS3 principles provide the rules that keep Requirements Specification precise, consistent, verifiable and semantically faithful to the engineering decisions established during Analysis.
The principles below apply throughout Requirements Specification. They are not separate process steps. They govern how analysed engineering information is formalised, how Requirements are structured, how Properties are quantified, how quality is embedded and how provenance remains traceable.
A Requirement expresses an engineering decision; it is not the place where that decision should first be made. If the intended system behaviour, required value or applicable Constraint is still unclear, return the issue to Analysis before writing the Requirement.
Requirement wording may increase precision and formality, but it must not silently alter the engineering meaning established during Analysis. The resulting Requirement must remain defensible from the Analysis Statement on which it is based.
Determine first whether the analysed system aspect is a Function, Property or Constraint. The semantic nature of the information determines the appropriate form of the Requirement.
A Function describes what the System-of-Interest must do. A Function itself is fundamentally binary: the required behaviour is provided or it is not. Performance and quality characteristics associated with that behaviour belong to Properties.
A Property becomes a usable Requirement when the required characteristic is quantified or otherwise objectively bounded. Values, limits, ranges, tolerances or comparable measurable criteria should make satisfaction objectively assessable.
Restrictions on the permissible solution space must be expressed explicitly enough to determine their applicability and satisfaction. Avoid vague statements such as “comply with all applicable standards” when the relevant standards can be identified precisely.
Each Requirement should express one identifiable engineering obligation. Independent obligations should be separated so that meaning, traceability, change and verification can be managed independently.
Requirements should use agreed terminology, definitions and sentence structures consistently. Undefined, subjective, overloaded or ambiguous wording should be removed or explicitly defined.
A Requirement must be formulated so that objective evidence can demonstrate whether it has been satisfied. If a pass/fail conclusion cannot be defined, the Requirement is not yet sufficiently precise.
Specify what the System-of-Interest must achieve without prescribing how it must be realised, unless the implementation choice is itself a legitimate Constraint or the consequence of an explicit higher-level Design Decision.
Every Requirement should remain explicitly related to the Analysis Statement from which it was specified. Through that relation, its semantic path to Stakeholder Needs, Source Information and relevant reasoning remains navigable.
Requirement quality is created during Specification. Clarity, atomicity, quantification, consistency, verifiability and structural correctness are not qualities that can reliably be added afterwards.
Three essential distinctions
Several of the principles above can be summarised through three distinctions that are particularly important during Requirements Specification.
Analysis Statement versus Requirement
An Analysis Statement records an engineering conclusion, interpretation or decision. A Requirement turns that analysed meaning into a normative engineering commitment.
Function / Property / Constraint versus Requirement
Function, Property and Constraint describe the nature of a system aspect. A Requirement states what is normatively required of that aspect.
Requirement versus Design Decision
A Requirement states what the System-of-Interest must satisfy. A Design Decision records a deliberate choice about how the system will realise its requirements.
Why the distinctions matter
Keeping these concepts distinct prevents analytical reasoning, normative commitments and design choices from collapsing into a single body of text that is difficult to understand, verify and manage.
Principles in the information flow
The Specification principles can also be understood as safeguards applied to the transformation from analysed engineering information to formal Requirements.
Common anti-patterns
The principles become particularly useful when contrasted with recurring Specification mistakes.
Writing before deciding
A Requirement is drafted while the underlying system meaning, value or engineering decision is still unresolved. The wording then hides unfinished Analysis.
Copy-and-shall
An Analysis Statement or Stakeholder Need is copied into a Requirement and prefixed with “shall” without considering whether the formulation is semantically appropriate or verifiable.
Compound Requirement
Several independent obligations are combined into one statement, making interpretation, change and verification unnecessarily difficult.
Unquantified Property
A qualitative term such as fast, lightweight, high availability or easy to maintain is presented as a Requirement without an objective criterion.
Vague compliance
The Requirement refers to “applicable standards”, “relevant legislation” or similar categories without identifying what actually applies.
Design hidden as Requirement
A preferred implementation is written as though it were an inherent system need, even though no legitimate Constraint or Design Decision requires it.
Lost provenance
A Requirement exists in the specification but its originating Analysis Statement and supporting engineering reasoning can no longer be identified.
Quality-by-review
Poorly structured Requirements are written quickly on the assumption that reviewers or testers will repair them later. Quality is treated as an inspection activity rather than a Specification discipline.
Quality is part of Specification
A Requirement is only useful when both its meaning and its expression are sound. IMPULS3 therefore distinguishes between the quality of the Requirement itself and the correctness of that Requirement in its engineering context.
Intrinsic quality
The Requirement itself is clear, unambiguous, atomic, quantified where applicable, consistent, verifiable and well structured.
Extrinsic quality
The Requirement correctly reflects the analysed engineering decision, remains traceable to its origin and is appropriate for the intended system level and downstream use.
High intrinsic, low extrinsic
The Requirement may be beautifully written and perfectly testable, yet still specify the wrong engineering decision.
High extrinsic, low intrinsic
The intended engineering meaning may be correct, but poor wording, ambiguity or lack of quantification makes the Requirement unusable.
IMPULS3 principle. Good Requirement quality requires both semantic correctness and formulation quality. Neither can compensate for the absence of the other.
The essence of Requirements Specification
This sequence is not intended as a rigid procedural waterfall. Specification remains iterative and may return to Analysis when unresolved decisions, missing values or semantic inconsistencies are exposed. The principle expresses the logical separation of concerns: engineering meaning precedes normative formulation.
IMPULS3 principle. Increase precision and formality without losing meaning, provenance or engineering intent.