Requirements Categorization

04 February 2001

Prepared by the Requirements Working Group of the International

Council on Systems Engineering, for information purposes only.

Not approved by INCOSE Technical Board.

Not an official position of INCOSE.

Project Team

Editor: Andrew Gabb

email: agabb@tpgi.com.au

phone: +61 8 8342-1021, fax: +61 8 8269-3280

George Caple David Haines Dave Lamont

Paul Davies Anthony Hall Jim van Gaasbeek

Steve Eppig David Jones Bill Vietinghoff

Introduction
Imagine that you have inherited a set of requirements documents, and wish to assemble and
rationalize them into a single baseline set, possibly using a requirements management tool. How
are you going to organize them and keep track of them? Which requirements should you deal with
first? How are you going to track what compliance you have against them? In cases of query or
challenge, how do you know where the requirement came from, and who owns the problem? The
key to solving these problems is categorization - the assignment of values to different requirements
to aid in their subsequent management.

This paper discusses the categorization of requirements and suggests definitions for different
categories of requirements. The objectives of the paper are to improve the standardization and
communication of requirements, with guidance in the use of categories.

This paper is the result of an INCOSE Requirements Working Group (RWG) project.

The categorization schemes described in this paper should not be regarded as a strict classification
system for requirements which can immediately be applied to projects. The category sets below
would more typically be used as a guide for developing categories for specific organizations and
projects, and might be regarded as a cookbook or checklist. Some categories will not be meaningful
for some organizations and/or projects.

Some guidance in the selection and application of category sets is provided in the section
‘Guidance on Implementing a Categorization Scheme'.

Scope
The scope of this paper is primarily the requirements applicable to the product of an engineering
development project (or program).

However, requirements documents in many projects include requirements which apply to more than
the product being developed, and may include the following, for example:

• Programmatic requirements, e.g. requirements for tasks, schedule, quality management,

meetings, reports.

• Work requirements, e.g. process standards, manufacturing constraints, test requirements.

• Service requirements, where specific services are to be provided, e.g. requirements for
delivery, training and support.

While the categories provided should also support these additional requirements, no attempt has
been made to provide detailed categorization in these areas.

This paper addresses the full spectrum of requirements from customer requirements down to the
lowest-level technical requirements, recognising that there will be a need to categorize
requirements at all levels.

Definitions
A requirement is here defined as an expression of a perceived need that something be
accomplished or realized. See Appendix A - What is a Requirement?

A category set is a related set of categories which may be applicable to requirements. A category
set is used to organize requirements according to a classification scheme which is specific to that
category set.

A category is a division or class within a category set.

The Need for and Use of Requirements Categories

Why Categorize Requirements?
The categorization of requirements has been shown to be very useful for a number of reasons.
These include:

• Organizing the presentation of requirements according to different viewpoints, and the

needs of different audiences.
 • Determining the requirements applicable to different aspects of development. For example,
safety requirements need special assurance activities, while reliability requirements can be
important drivers of certain aspects of the design.

• Viewing or reporting requirements according to categories to assess relationships between

associated requirements, to identify conflicts and overlaps, or to assess completeness
and/or consistency.

• Planning, modelling and managing requirements-related activities.

Why Define Specific Categories of Requirements?

There are numerous books, articles and papers which address categorization of requirements at
least in part. Unfortunately, there is a great deal of variation both in the categories described and in
the nomenclature used. By providing definitions of a limited number of category sets which are likely
to be generally applicable, including guidance on their use, this paper contributes to the
standardization of nomenclature in this field, both among INCOSE members and in the wider
community.

Comprehensive and standardized category sets will also benefit those performing requirements
engineering activities, particularly those with limited experience in using requirements categories.
The benefits include the following:

• Providing a checklist for requirements categories, which can assist both in structuring the
requirements, including different aspects of each requirement, and in identifying omissions.
Such a checklist can also stimulate users to think differently about requirements, expanding
their overall understanding of requirements engineering tasks.

• Providing a basis for the definition of requirements attributes when setting up and using
requirements management tools, noting that adding attributes later in the project will
generally require more effort than getting them correct at the start.

Appendix B - Requirements Categories and Attributes’ provides further discussion on the difference
between 'categories' and the 'attributes' used in requirements management tools.

Users of Requirements Categories

The users of requirements categories include all those responsible for and using requirements in a
project. This will include those responsible for the following:

• Requirements elicitation, analysis and definition.

• Requirements management, including configuration management of requirements and

requirements metrics and status reporting.

• System, subsystem and component design in accordance with requirements.

• Project and engineering management.

• Qualification including component, subsystem, system and integration testing.

• Analysis and design of system support.

However, the main users of the requirements category set definitions described in this paper are
those responsible for the following:
 • Establishing the requirements framework, particularly in requirements management tools.

• Managing the requirements engineering effort.

• Establishing and managing the requirements and the requirements database(s).

• Verifying and validating requirements, particularly with regard to completeness.

Discussion of Category Sets and Categories

A category set is defined above as a related set of categories which may be applicable to
requirements. A category set is used to organize requirements according to a classification scheme
which is specific to that category set. A category is a division or class within a category set.

The following are examples of different category sets:

• Basic type - with categories Functional, Performance, Quality factor, Environment, Physical,
Interface, Constraint, Non-requirement.

• Priority - with categories Essential, High, Medium, Low.

• Owner - with categories defining the different requirements owners for the project, e.g.
Customer, QA, Systems Engineering.

Categories within a category set are often exclusive, so that a requirement can only be assigned to
one category within the set, such as in the Priority set above. Other category sets may contain non-
exclusive categories, so that a requirement may be assigned to more than one category, such as in
the Basic type above, where a requirement may be both an Interface and Functional requirement.

Some categories may themselves be category sets, providing sub-categories and a hierarchy of
categories.

Our objective in choosing the category sets and categories shown below was to provide a
reasonably coherent and comprehensive structure of category sets and categories, which could be
used by practitioners to develop their own structure. While use of the full structure is likely to be
overkill for most projects, it is generally much easier to 'tailor down' than to 'tailor up'.

To provide some structure, and address related issues, the category sets below are arranged in
groups. For example, the section 'Source and Ownership' addresses a group of three category sets,
Derivation, Source and Owner. Like the selection of category sets themselves, the grouping is
somewhat arbitrary and appropriate groupings will vary from project to project.

To reduce the list to a reasonable minimum, we have resisted going too far down the design path,
and have limited the category sets to those reasonably likely to be needed up to the end of system
analysis, and are less oriented to the design and implementation of the system. Another reason for
this limitation is the likelihood that approaches taken by different projects may diverge strongly from
this point, and generic categories will be less useful. Note that this limitation does not reduce the
need to handle requirements applicable to later phases, such as requirements for disposal.

For example, there are some very important categories which are often relevant later in the project,
including the following:

• Assigned to: person or organization responsible for developing the requirement.

• Allocated to: subsystem, component.

 • Verified by: Verification plans and procedures.

Summary of Category Sets

The following table summarizes the candidate category sets described in this paper. Details on
each category set are provided in the following section.

Group Category Sets Example Categories

Intrinsic Basic Type Functional, performance, quality factor, environment, interface, constraint, non-
Characteristics requirement.

Product/Process (PP) Type Product, process, data, service.

Quantitative/Qualitative (QQ) Type Quantitative, qualitative

Life Cycle Phase Pre-concept, concept, development, manufacturing, integration/test,

deployment/delivery/installation, operation, support, disposal.

Priority and Priority (Compliance Level) Mandatory, non-mandatory, guidance, information.

Importance

Importance Key, high, medium, low, nil.

Source and Derivation Primary, interpreted, derived.

Ownership

Source (Origin) Contract, A-Spec, SOW, company policy, regulatory, agreement, derived.

Stakeholder Users, capability developers, supporters, supplier.

Owner (Approval Authority) Specific authorities, people or organizations.

Context Requirements Set (Requirements User Requirements, Functional and Performance Specification, Statement of
Document) Objectives, System Specification.

Subject Radar, reporting, user interface, software, delivery, mission analysis.

Scope global, specifc components, local.

Verification and Verification Method Test, demonstration, analysis, inspection, N/A.
Validation

Verification Stage Component/unit test, integration test, subsystem test, system test, factory
acceptance test, field acceptance test.

Verification Status Verified, unverified, integration test, system test, acceptance test.

Validation Method Test, demonstration, analysis, inspection, N/A.

Validation Stage Component/unit test, integration test, subsystem test, system test, factory
acceptance test, field acceptance test, user trials, operational evaluation.

Validation Status Validated, unvalidated, integration test, system test, acceptance test.

Miscellaneous Status Draft, approved, pending approval, internal review, external review, deferred,
Category Sets waived, active/inactive, query pending, deleted, cancelled, proposed, validation in
progress, validated.

Maturity (Stability) High, medium, low.

Risk Level Critical, high, medium, low, none

Cost Specific cost bands.

Product Release Specific product release identifiers.

Candidate Category Sets

Intrinsic Characteristics Group
This group addresses intrinsic characteristics of a requirement, which can normally be determined
from the requirement itself. Thus the category sets in this section tend to apply to the substance of
the requirement, rather than where the requirement came from, or how the requirement may be
assigned, used, treated etc., which are discussed in subsequent groups.

This is a difficult area in which to establish categories, and without any doubt the most controversial.
It is also the area of most interest, and one of the most important. Notes on the different category
sets and their interactions are provided at the end of the section.

Basic Type

The Basic Type category set consists of the following categories:

• Functional - what is to be accomplished.

• Performance - how well the functions are accomplished.

 • Quality Factor - addresses other factors of product or process quality.

• Environment - requirements defining the physical (and possibly socio-political-economic)

environment for system operation, or in which the work is done.

• Physical - requirements for the form of the product.

• Interface - requirements affecting product interfaces.

• Constraint - constraints on how and where the other requirements apply, or how the work is
to be performed.

• Non-requirement - provided for completeness or to provide clarification or context, e.g. user

domain knowledge, environmental descriptions, scenarios.

The Quality Factor category may also include sub-categories as follows (examples):

• Workmanship requirements.

• Reliability, availability.

• Maintainability.

• Supportability

• Portability.

• Flexibility.

• Usability.

• Safety.

• Security.

• Integrity.

Product/Process (PP) Type

The PP Type category set identifies the target or effect of the requirement, typically a product or
process. PP Type categories can be used for selecting groups of requirements which affect the
quality and content of deliverable documentation, for example, by using the Data category.

The PP Type category set consists of the following categories:

• Product - requirements for the form, fit or function of the product being supplied.

• Process - requirements for how the work is performed.

• Data - requirements for project internal and deliverable data, including technical data,
manuals and on-line help.

• Service - requirements for the services to be provided.

Quantitative/Qualitative (QQ) Type

The QQ Type category set identifies whether a requirement is quantitative or qualitative. The
definitions below are indicative only. Some engineers equate 'quantitative' with 'testable', meaning
that the requirement is expressed in a form which facilitates testing, regardless of whether it is
numeric or not in nature. Others use these terms to distinguish whether the requirement is qualified
by test or other methods (e.g. demonstration or analysis). As with other categories, it is very
important that the criteria for assignment are clear within the organization using them.

This category set may be useful as an indicator to the method which will be used to verify a
requirement. For example, quantitative requirements are the most likely candidates for quantitative
testing.

The QQ Type category set consists of the following categories:

• Quantitative - requirements which express needs in numeric terms - usually performance

requirements.

• Qualitative - requirements which do not express needs in numeric terms, and which may
require subjective judgement for testing. Functional requirements are usually qualitative.

Life Cycle Phase

The Life Cycle Phase category set identifies the phase to which the requirement applies, or where
the requirement may be satisfied. Example categories: Pre-Concept, Concept, Development,
Manufacturing, Integration/Test, Deployment/Delivery/Installation, Operation, Support, Disposal.

There may also be requirements for the product that constrain its design, but that are based on a
certain phase (e.g. a prohibition of the use of specific materials in a product may be required by
environmental regulations, due to consideration of the problems of disposal of these materials.)

Alternatively, the phase might be the phase from which the requirement for the product was derived
(or this might be a separate category set).

Notes on Intrinsic Characteristics

a. The Functional/Performance separation is traditional, and is included mainly for that reason.
Generally, the statement of performance is a characteristic of a functional or other
requirement, stating 'how well' the function is achieved. Note that there are usually
quantitative requirements relevant to other categories as well. See also the QQ Type
category set.

b. The traditional category 'non-functional requirements' is used variably by different authors

to mean significantly different groups of requirements. It may include almost all of the Basic
Type categories or only the Constraint category as addressed above. It may or may not
include performance requirements. Because the name 'non-functional requirements' is not
inherently meaningful, and is highly variable in scope, we have omitted it.

c. The Constraint category includes design constraints, noting that constraints can apply to
more than design.

d. Regulatory requirements (e.g. legal, technical, policy) and programmatic requirements (e.g.
schedule, meetings, reports) are usually categorized as Constraints, and their
discrimination is often based on requirements source, rather than any inherent character of
the requirements themselves.

e. Functional and Performance requirements apply to the entire system being developed, so
may include support requirements (if defined as such), i.e. they may not necessarily be
limited to the delivered operational system.
 f. Safety, security, integrity and other specialty engineering areas may have Functional and
Performance requirements, Quality Factors, or Constraints, and may also have
requirements for work to be done or services to be provided.

g. Most Process requirements tend to be Constraints.

h. Service requirements would generally be classified as either Functional or Performance

requirements, but others may emerge during the project as a result of constraints.

i. Requirements for resource use would normally be Functional or Performance requirements.

j. There is likely to be some overlap between the {Functional, Performance} and

{Environment, Interface, Quality Factors} category subsets. Note that a requirement which
implies an interface is not necessarily an Interface requirement in itself, but may be flowed
down to Interface requirements.

Priority and Importance Group

The understanding of what 'priority' and 'importance' mean will vary considerably with the types of
project, agreement and organizations involved. Two of the more common uses are described below.

Priority (Compliance Level)

The Priority category set indicates the priority of the requirement, which may also be the level of
specification compliance that is needed.

Example category sets include:

• Mandatory, non-mandatory, guidance, information.

• Essential, very important, important, desirable, advice.

• Very high, high, medium, low, none.

Additional categories may be used for 'intended compliance' and/or 'predicted compliance' in some
projects, where these may differ from the customer's assignment of priorities, for example.

Importance

The Importance category set identifies key requirements that are critical to project success,
particularly to the planning or design effort. Such requirements are typically drivers of cost,
schedule, risk or performance. These are sometimes referred to 'Key Drivers' or 'Most Important
Requirements'. Example categories include the following:

• Key, none.

• Primary, Secondary, none.

Importance may differ considerably from Priority, depending on the criteria used for assigning
requirements to the different categories. For example, Priority may be based on contractual
compliance with a customer's statement of requirements, whereas Importance may be the
supplier's assessment of the importance of different requirements for project success.

The number of key requirements is normally restricted to a manageable handful, typically 10 to 20

requirements. In many organizations, these key requirements are used as the prime objectives for
the project, and drive most aspects of development.
In some projects, more than one Importance category set may be needed, based on different
aspects of the project. For example, there may be a separate Importance category set applying to
safety.

Source and Ownership Group

Derivation

The Derivation category set typically indicates whether a requirement is an original requirement
(within the context of the overall requirements), or derived from other requirements. It may be used
for discriminating between those requirements which are input to the development effort (and hence
potentially difficult to change), and those which are a result of the engineering effort.

Example categories include:

• Primary - an original or source requirement, including customer requirements or those

requirements specified in the contract.

• Interpreted - restatements of customer requirements to remove ambiguity, or decomposed

primary requirements.

• Derived - derived from other requirements.

Source (Origin)

The Source category set indicates where the requirement came from. The actual source categories
will vary but may include documents, sub-documents, meetings, persons, organizations, and other
requirements.

Example category sets include:

• Contract, A-Spec, SOW, company policy, regulatory, agreement, derived.

• Users, capability developers, supporters, policy, regulatory, compatibility.

Stakeholder

The Stakeholder category set indicates who has the need for the requirement. Each category
usually indicates an authority, person or organization.

Owner (Approval Authority)

The Owner category set indicates who is responsible for changes to this requirement, or for
approval for changes. Each category usually indicates an authority, person or organization.

Context Group
Requirements Set (Requirements Document)

The Requirements Set category set indicates the requirements set (or document) in which a
requirement is contained. Example categories: User Requirements, Functional and Performance
Specification, Statement of Objectives, System Specification, Software Requirements Specification.

Subject

The Subject category set indicates the subject(s) to which this requirement is relevant. It should be
noted that, depending on the selection of the subjects (which are usually project dependent),
requirements may be relevant to a number of different subjects. For implementation, this may
require a number of different subject category sets with exclusive categories, or the use of a tool
which allows a number of categories from the same set to be assigned to a requirement. Example
categories: radar, reporting, user interface, software, delivery, mission analysis.

Scope

The Scope category set indicates the scope of a requirement, i.e. whether the requirement covers
the entire system (such as some regulatory requirements) or to a component of the system or is
local in scope. Examples: global, component (names), local.

Verification and Validation Group

Verification Method

The Verification Method category set indicates the verification method which is proposed to verify
that the requirement has been met. Examples: test, demonstration, analysis, inspection, N/A (not
applicable, meaning that no verification is required).

Verification Stage

The Verification Stage category set indicates at what stage(s) of the project, or in what project
activities, verification of the requirement will occur. Examples: component/unit test, integration test,
subsystem test, system test, factory acceptance test, field acceptance test.

Verification Status

The Verification Status category set indicates whether, where or to what extent the requirement has
been satisfied, as evidenced by verification activities. Example categories: verified, unverified,
integration test, system test, acceptance test.

Validation Method

The Validation Method category set indicates the validation method which is proposed to validate
that the requirements and the system meet stakeholder needs. Examples: test, demonstration,
analysis, inspection, N/A (not applicable, meaning that no validation is required).

Validation Stage

The Validation Stage category set indicates at what stage(s) of the project, or in what project
activities, validation of system compliance with stakeholder needs will occur or in what stage the
requirements are to be validated against stakeholder needs. Examples: component/unit test,
integration test, subsystem test, system test, factory acceptance test, field acceptance test, user
trials, operational evaluation.

Validation Status

The Validation Status category set indicates whether, where or to what extent the requirement has
been validated against the stakeholder needs, as evidenced by validation activities. Example
categories: validated, unvalidated, integration test, system test, acceptance test.

Miscellaneous Category Sets

Status
One or more Status category sets may indicate the current status of the requirement. Example
categories: draft, approved, pending approval, internal review, external review, deferred, waived,
active/inactive, query pending, deleted, cancelled, proposed, validation in progress, validated.

Maturity (Stability)

The Maturity category set provides an assessment of the maturity or stability of a requirement, i.e.
the likelihood of it not changing throughout the life of the project (or other defined period). This may
alternatively be expressed as the likely volatility (using an inverse scale). Example categories: High,
medium, low.

Risk Level

The Risk Level category set indicates the assessed risk level in meeting a requirement. Example
categories: critical, high, medium, low, none.

Cost

A Cost category set may be used to provides an estimate of the likely cost of implementing the
requirement. This can either be a specific cost on a continuous scale, or a discrete value from a set
of cost bands.

Product Release

The Product Release category set may indicate the milestone where this requirement is intended to
be met. This is particularly applicable to evolutionary system development with incremental delivery
to the customer or test organization. The categories will be system release identifiers. Alternatively,
this or a separate set may be used to indicate the project phase in which a requirement will be
implemented.

Guidance on Implementing a Categorization Scheme

Each organization should tailor the categories and category sets for their own use, and for use in
specific projects. Modification is likely to include renaming, adding, deleting, merging and splitting of
category sets and categories. Determination of applicable categories should be based on how the
different categories are to be used and their value to the organization or project. It is also likely that
the categorization scheme will need to evolve during the course of the project, to accommodate the
different and changing requirements management needs in the different project phases.

Where a project involves modification of an existing system, or the reuse of existing requirements
and/or components, the categorization scheme may need to accommodate existing categorizations,
if requirements for existing products have already been categorized according to a different
scheme.

The choice of categories for each specific project, however, should be based on a broad
categorization model, extended by project experience. In the absence of this model, the principles
of categorization are likely to degenerate and fall into misuse and chaos, as project copies project,
rather than developing and improving the underlying categorization model.

It is important that the determination of categories for a specific project includes detailed criteria for
the allocation of requirements to categories. Without this, different personnel will almost certainly
interpret the names and definitions differently, resulting in inconsistent assignment.

Further Reading
For further information on related topics in requirements engineering, the following INCOSE
Requirements Working Group articles are suggested. They are available for download from
www.incose.org/rwg/.

INCOSE Insight, Special Issue on 'Requirements -- Sharing The Vision', Winter 1999.

Kar, Pradip and Michelle Bailey, 'Characteristics of Good Requirements', Proceedings of INCOSE,
1996.

Stevens, Richard, and James Martin, 'What Is Requirements Management?', Proceedings of

NCOSE, 1995.

Hooks, Ivy, 'Writing Good Requirements', Proceedings of NCOSE, 1993.

Harwell, Richard, Erik Aslaksen, Ivy Hooks, Roy Mengot and Ken Ptack, 'What Is A Requirement?',
Proceedings of NCOSE, 1993.

Appendix A - What is a Requirement?

The word 'requirement' is used very loosely in both the engineering and wider communities. We
considered many different definitions of 'requirement', all of which we felt to be deficient in some
way. Probably the most common deficiency in existing definitions is that they address requirements
only for a product, disregarding requirements for services and requirements stating how a product
should be developed, which are common, particularly in larger projects. Another deficiency is the
use of the word 'must' in the definition, ignoring the prioritisation of requirements or the existence of
non-mandatory requirements. There were also other problems.

We therefore decided that we needed a broader definition:

A requirement is an expression of a perceived need that something be

accomplished or realized.

Note that this definition is intended to encompass all defined requirements for a project. In particular
it includes the following:

• Product, work, programmatic, service and other requirements (including those commonly
called 'constraints').

• Incorrect requirements, i.e. requirements which are not valid statements of the customer's
needs although they may be perceived as such.

• Poor requirements and poorly expressed requirements.

• The expression of needs in different forms, not necessarily statements in natural language.

• Requirements expressed in technical and non-technical language.

• Wants and desires, noting that these are normally expressed as needs.

• Requirements which may not be binding, or which are prioritised.

Note also that by this definition the requirements discussed here are expressions of need, not the
needs themselves. While this difference may appear subtle, we have found it to be a source of
many misunderstandings when discussing requirements. Apart from those requirements which are
defined, there are likely to be many other needs and expectations which have not been expressed.

In the wider context, the word 'requirement' is used differently by different people and organizations,
often with a much narrow meaning than is used in this paper. For example, in some organizations
'requirements' are limited to mandatory provisions (e.g. 'shalls'), and non-mandatory provisions (e.g.
'shoulds') are considered to be 'guidance'. In others, any provisions which are not feasible,
complete, consistent and testable, for example, are not considered to be 'requirements'.

The formality with which requirements are stated and the style of expression may also vary
considerably between different requirements documents, even in the same project. For example, a
customer requirements document describing user needs and expectations may contain quite
different requirements from the set of technical requirements for a system component. Technical
requirements for a system, subsystem or component are usually (but not always) more disciplined
in their expression, and arguably easier to categorize. They are typically stated in a manner which
facilitates the verification of the requirement, for example, and are rarely ambiguous in meaning.

Appendix B - Requirements Categories and Attributes

The dictionary definition of 'attribute' is 'an inherent characteristic' or 'a word ascribing a quality'.
However, the word 'attribute' is now often used to describe the fields used in requirements
management (RM) tools, where its meaning has been extended to mean any object or value
associated with a requirement. Here, the term 'RMT attribute' (requirements management tool
attribute) refers to this latter meaning.

In an RM tool, requirements are often assigned to one or more categories using RMT attributes. For
example, a high priority requirement may have an RMT attribute called 'Priority', whose value is set
to 'HIGH'. In this case the RMT attribute represents a category set, and the attribute value defines
the category.

Where a category set is non-exclusive, a requirement can be assigned to more than one category in
the set. For example, a requirement may be categorized as both Functional and Interface in the
category set 'Basic Types'. If the RM tool supports 'multi-value' or 'set' attributes, where a number of
values can be assigned to a single attribute, the RMT attribute is likely to represent the category
set, and both categories can be included as values in that attribute. Otherwise, an RMT attribute
may need to be defined for each category in the set. Using the example, the RMT attributes of
'Functional' and 'Interface' would be set to 'true' for the requirement.

Many commonly used RMT attributes do not represent category sets or categories. For example, an
attribute may be used to provide a unique identification number, cross reference number, or
rationale for the requirement. None of these would normally be seen as 'categories'.

***