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 Characteristics

Basic Type Functional, performance, quality factor, environment, interface, constraint, non-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 Importance

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

Importance Key, high, medium, low, nil.

Source and Ownership

Derivation Primary, interpreted, derived.

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 Document)

User Requirements, Functional and Performance Specification, Statement of Objectives, System Specification.

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

Scope global, specifc components, local.

Verification and Validation

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

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 Category Sets

Status Draft, approved, pending approval, internal review, external review, deferred, 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'.

***