Published in the Proceedings of the Third International Symposium of the NCOSE, 1993. Prepared by the
Requirements Working Group of the International Council on Systems Engineering, for information purposes only.
Not an official position of INCOSE.
What Is A Requirement?
Richard Harwell
Lockheed Aeronautical Systems Company
86 S. Cobb Drive; Marietta, GA 30063-0685
Erik Aslaksen
University of Technology, Sydney, and
Ewbank Preece Sinclair Knight
PO Box 572, St. Leonards
Sydney, NSW 2065 Australia
Ivy Hooks
Bruce G. Jackson & Assoc., Inc.
17629 El Camino Real, Suite 207
Houston, TX 77058
Roy Mengot
Texas Instruments
PO Box 650311
Dallas, TX 75075
Ken Ptack
PRC, Inc.
Crystal Gateway One, Suite 1211
1235 Jefferson Davis Highway
Arlington, VA 22202
Abstract. Each contract specialist, lawyer, engineer, systems engineer, manager, or anyone else involved in the
transition of vision into product, has his or her own definition of a requirement. With the rare exception, all are
applicable and meaningful - but most are forgotten or ignored in the crunch to produce an effective requirements
document under constrained schedule and funding environments. Yet, the need for effective requirements generation
is probably the number one priority today in product development needs. Rather than approaching this problem from
the theoretical or a priori standpoint, this paper examines the nature of a requirement through a process of
identifying key characteristics and relationships from the viewpoint of the requirements manager/analyst and the
requirements user (design team). It also discusses the importance of determining that requirements convey a need (as
opposed to a directed solution), and ascertaining quality in terms of contextual adequacy.
INTRODUCTION
This is the first of three papers addressing the topic "What is a requirement?". It concentrates on: (1) the use of
characteristics and relationships to analyze and integrate requirements sets, (2) identification of the transition from
requirement to design, and (3) determining quality in terms of completeness, lack of ambiguity, and scope. The
second paper expands on the concept of requirements characteristics to include selected optional characteristics
which may be used by requirements analysts for special purpose needs. The last in the series is an in-depth
examination of "Requirement Structure", providing a means of assisting the requirements analyst in better
understanding the structure of an individual requirement from a linguistic and contextual standpoint.
THE REQUIREMENT ENVIRONMENT
All projects begin with a statement of requirements, whether it be an innovator's simple statement of concept, a
formal DoD System Specification, or a Marketing Analysis. However, the "rush" to convert concepts to products the "real stuff' you can touch and manipulate - often overpowers the requirements development process. This, in
turn, hampers the ability to produce the concept as originally envisioned. Prior papers on this subject range from an
examination of requirements from a micro-specification viewpoint to academic treatises on the theory of
requirement constructs. However, program personnel frequently set aside such treatises as being too difficult to
interpret and apply in the day to day efforts of getting the job done.
This paper establishes a means of identifying the clear-cut characteristics of a requirement which can be used by
both requirements analysts and design teams. These characteristics can help determine the source, applicability,
1
depth, and other factors needed for assessing and implementing an integrated, and coherent, requirements set.
Analysis of assigned characteristics can help a design team identify whether a specific requirement establishes a
quantifiable threshold, if it needs further analysis to determine its impact, or if it can be treated as a goal or customer
desire.
In a specification environment it is a common practice to identify multiple classes of requirements (i.e., functional
requirement, reliability requirement, constraints, etc.) according to a designated specification structure. However, in
a requirements management system environment (database), a specification is simply a "slice" of the database
according to pre-defined attributes. In this environment, requirements classes are treated as a specified characteristic
of a requirement (or as a relationship/attribute to a requirement), rather than as a separate class of requirements.
Therefore, this paper is based on the concept that:
If it mandates that something must be accomplished, transformed, produced, or provided,
it is a requirement - period.
The qualifiers follow - in the form of characteristics and relationships. This allows a requirement to be the focus,
i.e., the key player or authority, for all related information in a requirements management database environment.
Yet, this approach preserves the use of familiar identifiers (albeit in a different format) for use in specification-based
developments. In the latter case, a reliability requirement becomes a requirement having the qualifier reliability as
one of its relationships (other relationships might include radar subsystem, WBS 123 7, MTBF, etc.).
REQUIREMENTS CHARACTERISTICS
Although it may be difficult to find the "right" definition of a requirement that provides us with omnipotent insight
into requirements generation forevermore, we can consistently identify the "fingerprints" of a requirement. There are
nine characteristics in all - three essential characteristics and six optional characteristics, as shown in Tables l and 2,
respectively. As noted in the tables, each of these characteristics has subsets which may be used as deemed
appropriate for each program. (The terms "program" and "project" are synonymous in this paper.) A discussion of
the three fundamental characteristics, with examples, follow.
Requirement Type
The requirement type identifies the source and contractual applicability of a requirement. There are only two
requirements types:
 Primary. Those requirements (whatever their form contract provision, specification, database, market
analysis, etc.) levied on a contractor/producer under force of contract. The identification is unambiguous. If
it is: (1) contractually applicable, or has the force of a contract as in a market analysis, and (2) comes from
a source external to program personnel, it's a primary requirement. An example would be "The payload
shall be transported into orbit in the payload bay".
 Derived. Those requirements (whatever their source internal, supplier, team member, customer, etc.) that
are generated apart from the primary requirements. The identification is unambiguous. If it is not a primary
requirement, it is a derived requirement. An example would be "The payload shall have a diameter of less
than 14 feet" ' The specifying of payload diameter is derived from the payload bay size based on the
original primary requirement. That derivation may have been accomplished by the Contractor's Program
Manager, be the result of a trade analysis, or physical examination of an object. Or it may have been
suggested by the customer's Contracting Officer - but not as an amendment to the contract. It doesn't
matter, it is still a derived requirement with the primary requirement as it's parent for traceability.
The requirement type enables the product team to assess the difficulties associated with changing a requirement. By
definition, if it is a primary requirement, a Contract Change, or perhaps a new market analysis, will be required. But
if it is a derived requirement, the decision to change (as long as the change is within the scope of the "parent"
primary requirement) rests with program management.
With respect to requirements entered into a database, there may be a need to modify the exact customer statement particularly when a specification combines several different requirements into a single sentence. The precise
splitting of such a requirement, including the creation of transitional phrases, does not constitute a derived
requirement because no assumptions or expansions of the primary requirement will have been made. However, each
split-out segment will be a child of the parent (original) primary requirement.
2
Requirement Application
The requirement application identifies the object of a requirement, There are only two requirements applications:
 Product Parameter. A product parameter is a requirement that applies to the product or service to be
developed. The identification is unambiguous. If it directly acts on the product or service, it is a product
parameter. Examples of such requirements would include "The external surfaces of all equipment shall be
painted while", and "The operator training program shall result in a pass rate of not less than 95% for
qualified candidates ".
Product parameters have two primary subdivisions:
 Qualitative - This product parameter contains no measurable requirement. An example would
be "The mixer shall produce a mixture of homogeneous appearance." A qualitative product
parameter usually necessitates further analysis to determine suitable quantifiable criteria; i.e.,
usually necessitates the development of derived requirement(s), with the qualitative product
parameter serving as the parent.
 Quantitative - This product parameter contains a measurable requirement. An example would
be "The mixer shall produce a mixture having a fineness granularity of XYZ within five minutes ".
A quantitative product parameter may have children, but such children would be generated for the
purpose of specifying particular approaches to meeting this measurable requirement.
 Program Parameter. A program parameter is a requirement that applies to the activities associated with
enabling the creation of a product or service, such as conducting traders or holding design reviews. This
also includes contract provisions which define the customer/contractor relationship; e.g., confidentiality,
intellectual property rights, warranties, etc. In short, a program parameter defines activities related to the
technical and administrative management of product development. The identification is unambiguous. If it
does not directly act on the product or service, it is a program parameter. Examples of such requirements
would include "The contractor shall develop a concept of operations " or "The contractor shall conduct
internal design reviews every two weeks. "
Program Parameters have three primary subdivisions:
 Task - Identifies an analysis or other effort to be performed. Examples would include "Prepare a
Systems Engineering Management Plan" or "Perform an analysis of the structural loads on the
bridge pylons'.
 Compliance Evaluation - Identifies the methodology for measuring compliance with parameter.
(There should be a verification program parameter associated with each product parameter.)
 Regulatory - Identifies administrative elements such as "Deliverable data shall be furnished with
unlimited rights to the Government".
Requirement Compliance Level
The requirement compliance level identifies the depth of compliance mandated for a requirement. There are only
three compliance levels:
 Mandatory. Whether a primary or derived requirement, it must be implemented. Such requirements usually
include a "shall" statement in their structure. If it is a primary requirement and is not achievable, then a
contract change or deviation/waiver is necessary. If it is a derived requirement and is not achievable, then a
briefing must be presented to management (or in rare instances, the customer) for lessening of the
requirement. An example might be a directive to use an in-house component, which is not deemed to
conform to a primary requirement. If there are no alternatives to the derived requirement in such an
instance, it is very likely that a higher ordered (parent) primary requirement may not be achievable and will
also need to be changed.
 Guidance. Whether a primary or derived requirement, it is desirable that it be implemented. In general,
failure to implement does not constitute noncompliance so long as it can be demonstrated that a reasonable
degree of implementation was attempted. This is equivalent to specifying a goal or desire on the part of the
customer or management. An example would be "Use Mil-Std-499B as a guide in implementing the systems
engineering process. "
 Information. This unique characteristic is essential when requirements management systems (requirements
databases) are used in lieu of hard copy source documents. By strict interpretation, these "requirements" are
not actually requirements, but are non-binding statements which significantly influence the context,
3
meaning, and understanding of other requirements. An example might be a reference to the customer's
reasoning for specifying a particular approach or requirement.
Priority
This characteristic identifies the relative importance of a requirement in terms of implementation, particularly in
establishing criteria for trade studies. In a cost reimbursable environment, a customer may use priorities to mandate
that certain elements must be completed before a specified ceiling is reached. The priority characteristic may also be
used for establishing the sequence in which specified design or test activities should occur. Unlike the other
characteristics, the values of priority will be dependent on program and company needs.
REQUIREMENT ALLOCATION AND/OR
RELATIONSHIP ASSIGNMENT
Determining the characteristics of a given requirement enables the product team to understand nature of a
requirement. Correspondingly, allocation of a requirement (or assignment of a relationship to a requirement in a
database) enables the product team to visualize and understand the interactive and interdependent nature of a
balanced requirements set. This insight is achieved by being able to scope and group an otherwise disconnected
series of requirements into meaningful structures for analysis and implementation.
After the characteristics are defined, anomalies identified, and decisions made with respect to team handling of the
anomalies (until customer or management resolution), the product team is primarily interested in identifying
requirements applicable to the team components. As with requirements characteristics, definition of the
allocation/relationship assignment process should be approached from the viewpoint of the user. Therefore, the
initial effort is usually the assignment of responsibility (i.e., ownership) of each requirement to the respective team.
As the program progresses, this assignment may change, but a known baseline for performance responsibility will
maintained.
The key in this effort is not the specifics of the allocation (each program has its own needs), nor the process
followed (each company has its own version of the systems engineering process). Rather, the key is establishing an
agreed upon hierarchy of relationships that will enable the teams to examine large quantities of requirements
(potentially hundreds of thousands on some programs) according to program needs. For example, a typical
relationship hierarchy might include the following:
 Product Elements - Segments, subsystems, interface components, etc.
 Keywords - Indices (terms not usually appearing in requirements text such as "affordability", "mission
applicability", etc.), work breakdown structure (WBS) elements, technical budgeting, trade study
references, etc.
 Parent/Child Relationships - Traceability between higher and lower level requirements
 Assignments to Specifications - Identification of the various specifications into which the requirement will
be incorporated
 Test Plan/Test Methods Applicability - Identification of the applicable test plan reference and methods
for demonstrating compliance
 Other Assignments, Observations, and Discriminators.
Particularly when used in conjunction with a requirements management system, these relationships enable product
teams to examine requirements through insights gained by selective groupings. These examinations will help to
further identify anomalies for resolution, but more importantly they can help to integrate the requirements
statements and thus identify before integrated test and evaluation the suitability of a given requirements set to
accomplish the customer's objective.
REQUIREMENT VERSUS DESIGN IMPLEMENTATION
There are two aspects of this issue of "Is it a requirement or is it a design implementation?" The first occurs when
the customer mandates a design solution as a requirement. The other occurs when the product team generates
derived requirements which actually may be design solutions instead of requirements. Both aspects are discussed
below.
4
Requirements - Needs Versus Implementation.
An RFP was released last summer for the development of a requirements management tool. The first requirement
was to "provide a database". The statement is one of implementation and not of need, and it is common to fmd such
statements in requirements documents. Requirements documents should state what is needed, not how it is to be
provided. Yet this is a common mistake made by requirements authors.
Most authors do not intend to state implementation, they simply do not know how to state the requirement correctly.
In the case above, the author of the document continued with many valid requirements  Provide the capability for traceability between requirements (Qualitative product parameter),
 Provide the capability to add attributes to requirements (Qualitative product parameter),
 Provide the ability to sort requirements (Qualitative product parameter) .
Granted, each of these requirements will result in a database type of system, but a separate requirement for a
database was not needed.
There are two major dangers in stating implementation. The one most often cited is that of forcing a design when not
intended. If all the needs can be met without a database, then why state the need for a database. If they cannot be
met another, or better, way, then a database will be the selected design solution.
The second danger is more subtle and potentially much more detrimental. By stating implementation, the author
may be lulled into believing that all requirements have been covered. In fact, very important requirements may be
missing. This may result in the contractor/producer conforming with the requirements document, yet not delivering a
system or product which accomplishes the customer's real intent. For example, providing a database in the above
instance will not be sufficient for someone needing a requirements management tool. It is the capabilities of the
requirements management tool that are needed.
At each level of requirements development the problem of needs versus implementation will occur. At the system
level the requirements must state WHAT is needed. The system designer will determine HOW this can be
accomplished - and then must define WHAT is needed at the subsystem level. The subsystem designer will
determine HOW the need can be met - and then must define WHAT is needed at the component level, and so forth.
Another illustration of how implementation creeps into needs statements is that of a proposed system requirement on
a different program which included the expression "landing in TBD sea state conditions". Since there was no vehicle
design - the vehicle could have landed in water or on land - it was difficult to justify this requirement as written. On
being asked why such a requirement was needed, the author indicated the real concern was about crew rescue. If the
vehicle were to land in the water, rescue by helicopter could only be accomplished under certain sea conditions. In
further discussions, however, it was noted that if the vehicle made a landing on the ground, there would also be a
limited amount of time to reasonably leave the crew inside and unattended - an equal crew rescue concern. The
requirement, therefore, was changed to reflect the real need "time to remove the crew from the vehicle".
To ensure that a requirement statement represents a need and not an implementation, ask WHY the requirement is
needed. If this does not lead to a "real" need statement, then the original requirement statement is probably
appropriate, citing a need rather than implementation.
When Does the Transition Occur From Requirement to Design
Implementation?
The second aspect of the requirements versus implementation concern most often occurs with software
development. Many of the systems engineering and software engineering interface difficulties stem from the fact
that software developers views the continuum from customer requirement to acceptable code as a requirements
process - rather than as a transition from requirement to design to product. Stated in another way, what the systems
engineer may view as a "design solution", the software engineer may view as a lower level "requirement". The same
concern occurs in hardware development as the requirements process progresses to lower and lower levels. A point
is reached when the question must be asked: Is this a requirement or a design solution?" There are no absolute
answers. But establishing a general guideline such as the following is feasible:
 If there are no viable alternatives which can be implemented, other than the statement in question it's highly
probable the statement is a design solution. In effect, it's mandating a solution as discussed above. As such,
it should be removed from whatever requirements document intended and included in a design description
document, a drawing, or code.
 However, even if there is a lack of viable alternatives, when implementation as a design solution is not
feasible without further customer or systems engineering interface, it should continue to be treated as a
requirement (particularly in software development). This is due to the fact that implementation is dependent
5
upon an understanding of the context in which the requirement/solution is to be implemented, and as such,
cannot stand alone as a true design solution.
REQUIREMENT QUALITY
Definition Of Requirement Quality.
The quality of an object or process is often defined as the degree to which it meets specification requirements. It is
sometimes also defined as fitness for purpose. So what is the specification of a requirement, what is its purpose?
Execution of a requirement may be considered to occur as an interface between two processes: The definition
process, in which an intellectual intent (concept) is transformed into a written statement (specification), and the
interpretation process, in which the written statement is transformed into the intellectual input to a process which
produces a set of more detailed (derived) requirements or design description.
The purpose of a requirement is to reproduce in the mind of the reader the intellectual content which was in the mind
of the writer. The quality of a requirement is then the extent to which this takes place.
Two features of this definition emerge :
 The quality of a requirement is not an absolute characteristic - it is only defined relative to the reader.
 The quality of a requirement is not a measurable trait - it can only be inferred a posteriori.
The first of these features is inherent in the nature of a requirement and would be a feature of any definition of
quality. The second feature is a result of the high level of the definition; a much more detailed (and complex)
definition could have been introduced which would be measurable. This is not considered to be a particularly
practical solution. Instead, the approach will be to define some subordinate traits/factors which are more easily
measurable.
Necessary Elements for Requirement Quality.
Completeness. A requirement must be complete in the sense that it provides all the program-specific (i.e. non
common domain) information necessary for the user to carry out the next process step. To understand what this
means, consider the case where the next step is development of derived (i.e. more detailed) requirements. Such a
step consists of analyzing the parent requirements, identifying the options available to satisfy these requirements,
choosing the best option, specifying (i.e. giving new, more detailed/derived requirements), and finally verify that
these derived requirements will collectively achieve the intent of the parents. The crucial activity here is choosing
the best option; the criterion for making that choice is determined by the given requirements. For example, a
requirement for minimum weight will give a different choice than one for minimum cost. Conversely, the absence of
a requirement to differentiate among options for a specific parameter implies that parameter is not a criteria for
completeness. For example, if the requirement says nothing about the color of the equipment, the author of the
requirement does not care and cannot complain if the equipment turns out, say, shocking pink. If the author does
care, then the requirement was not complete.
These examples demonstrate that completeness of a requirement is dependent upon the author's intent. Therefore,
while it is possible to measure or test for completeness, such measurement is only possible in conjunction with the
author.
Lack of Ambiguity. A requirement must be unambiguous in the sense that different users (with similar
backgrounds) would give the same interpretation to the requirement. This has two aspects. On the one hand there is
the aspect of grammatical ambiguousness, i.e. the poorly constructed sentence. On the other hand there is the aspect
of ambiguousness arising from a lack of detail allowing different interpretations.
The first of these can be measured or tested independently of author or user, but the second aspect can be measured
only in conjunction with a set of users, since it depends on what assumptions the user makes automatically, i.e. as a
result of the user's background knowledge.
Scope. A requirement must be properly scoped in the sense of providing a definite amount of information. Poor
requirements in this regard include motherhood statements as "shall use their best efforts", "shall ensure the highest
system integrity", "shall be of a high quality", "shall provide a reliable service", etc. Although scope is intrinsic to
the requirement; measurement of the depth of scope would need a procedure tailored to the program needs.
6
CONCLUSION
The accurate translation of a customer's need by the product team is essential. Identifying requirements
characteristics, determining that the stated requirement conveys a need (as opposed to a directed solution), and
ascertaining contextual adequacy are essential for assessing the accuracy of translation before the product team
proceeds. These criteria enable the analysis team to better understand the customer's intent and to better identify
where disjoints, ambiguities, and conflicts exist early in the program. The objective is to be able to integrate a
collection of requirements (preferably through manipulation in a database using these characteristics and
relationships as "grouping" devices) and to establish their achievability prior to design implementation - rather than
during test and evaluation. In addition, as we learn the effects certain combinations of characteristics and
relationships have on the development process, we can more readily identify potential difficulties and correct them
before we are committed to an approach that may be impracticable.
Table 1. - Essential Requirements Characteristics
CATEGORY
Type
Application
Compliance Level
Priority
CHARACTERISTIC
A. Primary - Usually a contract requirement, but may be a requirement in a precontract document Also may be a requirement established by Marketing or survey
teams as in Commercial applications.
B. Derived - Derived from Primary Requirements or higher level Derived
Requirements
A. Product Parameter - The Product Parameter refers to a requirement which applies
to the product or service to be developed. It may be adjusted for a specific application
or phase. For example, some programs and tools distinguish between a "design" and a
"constraint " parameter. Other programs may need to distinguish between "design,"
"build," and "operate". In any application, subsets may include:
1. Qualitative - Not directly measurable
 Functional (What it does/ A capability of the product)
 Process (Leading to a result / product)
2. Quantitative - Directly measurable.
 Performance
 Design Point (Altitude, endurance, Itemperature, mix-rate, etc.)
 Procedural (Specified sequence of events, specified algorithm)
 Physical (What it is)
B. Program Parameter - The Program Parameter refers to a requirement which is not
directly involved in the development, production, or operation of the product. But
rather pertains to programmatic activity associated with supporting these
aforementioned aspects. There must be a "Compliance Evaluation Program
Parameter" for each product parameter which specifies how accomplishment of the
product parameter can be measured.
1. Task (Perform an analysis, build to a product specification, operate a system, etc.)
2. Compliance Evaluation (Measure compliance with a product parameter. )
3. Regulatory (Administrative, corporate policies/practices, etc.)
A. Mandatory - Typically a "shall" statement - mandates conformance.
B. Guidance (Goal) (Objective) - Typically a "will" statement - accomplishment is
desired/preferred. It is still essential to demonstrate and document why
accomplishment is not achievable, if requirement is not met.
C. Information - Statement supporting or giving insight to a measurable requirement,
the absence of which would lead to a misunderstanding of the associated requirement.
(A practice necessitated by the use of databases in requirements management systems
which will be used by the team in lieu of the source document.)
The particular values of priority will be program and company dependent
7
AUTHOR'S BIOGRAPIHES
Richard Harwell, a Staff Specialist in Systems Engineering at Lockheed Aeronautical Sysirms Company, is the
Principal Investigator of LASCs "Systems Engineering Technologies Development IR&D Project. and developer of
the current LASC Systerm Engineering course. He recently completed an assignment as the Integrated
Requirements/Risk Manager for the Grumman-Boeing-Lockheed AX Team. He has also lead efforts pertaining to
requirements and risk analysis and management, and special systems engineering assignments on numerous other
programs.
Erik Aslaksen is a Principal in the engineering consulting company of Ewbank Preece Sinclair Knight of Sydney,
Australia and a Visiting Professor at the University of Technology, Sydney. He obtained his M.Sc. in Electrical
Engineering form the Swiss Federal Institute of Technology in 1962 and a Ph. D. in Physics from Lehigh University
in 1968. Prof. Aslaksen's experience, gained in the U.S., Switzerland, and Australia, covers fields as diverse as ndcrowave components, power electronics, quantum electronics, and communications and ranges from basic research
to corporate management. In recent years his main interest has been in the area of systems engineering. He is the
author of two textbooks (one with W.R. Belcher) and over forty papers.
Ivy F. Hooks is President and CEO of Bruce G. Jackson & Associates, Inc. Her 20 year NASA career included
management of Space Shuttle Separation Systems and Verification of Shuttle Flight Software. She currently teaches
classes in writing and managing requirements and consults on these subjects.
Roy Mengot has been with TI DSEG technical training for over 10 years, developing, teaching, and consulting on
training for topics in hardware and software tools, microcode development, real time software systems and Systems
Engineering. He has a BS and MS degree in Computer Science from Central Michigan University and has served as
an Army officer. He is currently the course manager for TI DSEG's Systems Engineering Workshop.
Kenneth R. Ptack, Aerospace Systems Engineer Program Manager for PRC Inc. in Crystal City, VA. Leading team
providing system engineering support to the Joint Logistics Commanders and Naval Air Systems Command. This
includes development, integration, and implementation of an overarching systems architecture standardization
program Recently developed a systems requirements management and requirements engineering specification and
handbook, and the IEEE Systems Engineering Management standard.
Copyright 1993, Lockheed Corporation, Bruce G. Jackson & Assoc., Inc., and Ken Ptack.
8
Published in the Proceedings of the Third International Symposium of the NCOSE - Volume 2, 1993. Prepared by
the Requirements Working Group of the International Council on Systems Engineering, for information purposes
only. Not an official position of INCOSE.
Writing Good Requirements
(A Requirements Working Group
Information Report)
Ivy Hooks
Compliance Automation, Inc.
17629 Camino Real, Suite 207
Houston, Texas 77058
Abstract. The primary reason that people write poor requirements is that they have had no training or experience in
writing good requirements. This paper will address what makes a good requirement. It will cover some of the most
common problems that are encountered in writing requirements and then describe how to avoid them. It also
includes examples of problem requirements and how to correct them.
INTRODUCTION
If you or your staff are having problems with writing good requirements, you may benefit from guidance in how to
write good requirements. The college courses you took probably never mentioned the subject of requirements. Even
if you have taken classes in system engineering or program management, you may have had only an introduction to
the subject of writing requirements. If you are using existing specifications for guidance, you may be using poor
examples. The information provided in this paper is used in training people to write good requirements and
generally results in a step function improvement in the quality of requirements.
An important aspect of system engineering is converting user "needs" into clear, concise, and verifiable system
requirements. While this paper primarily discusses system level requirements, it is equally applicable at all lower
levels.
The first section discusses what is a good requirement. This is followed by a discussion of common problems and
how to avoid them. It also includes examples of problem requirements and how to correct them.
GOOD REQUIREMENTS
A good requirement states something that is necessary, verifiable, and attainable. Even if it is verifiable and
attainable, and eloquently written, if it is not necessary, it is a good requirement. To be verifiable, the requirement
must state something that can be verified by examination, analysis, test, or demonstration. Statements that are
subjective, or that contain subjective words, such as "easy", are not verifiable. If a requirement is not attainable,
there is little point in writing it. A god requirement should be clearly stated.
Need. If there is a doubt about the necessity of a requirement, then ask: What is the worst thing that could happen if
this requirement were not included? If you do not find an answer of any consequence, then you probably do not
need the requirement.
Verification. As you write a requirement, determine how you will verify it. Determine the criteria for acceptance.
This step will help insure that the requirement is verifiable.
Attainable. To be attainable, the requirement must be technically feasible and fit within budget, schedule, and other
constraints. If you are uncertain about whether a requirement is technically feasible, then you will need to conduct
the research or studies to determine its feasibility. If still uncertain, then you may need to state what you want as a
goal, not as a requirement. Even is a requirement is technically feasible, it may not be attainable due to budget,
9
schedule, or other, e.g., weight, constraints. There is no point in writing a requirement for something you cannot
afford -- be reasonable.
Clarity. Each requirement should express a single thought, be concise, and simple. It is important that the
requirement not be misunderstood -- it must be unambiguous. Simple sentences will most often suffice for a good
requirement.
COMMON PROBLEMS
The following is a list of the most common problems in writing requirements:
 Making bad assumptions
 Writing implementation (HOW) instead of requirements (WHAT)
 Describing operations instead of writing requirements
 Using incorrect terms
 Using incorrect sentence structure or bad grammar
 Missing requirements
 Over-specifying
Each of these are discussed in detail below.
BAD ASSUMPTIONS
Bad assumptions occur either because requirement authors do not have access to sufficient information or the
information does not exist. You can eliminate the first problem by documenting the information critical to the
program or project, including:
 Needs
 Goals
 Objectives
 Constraints
 Missions
 Operations Concept
 Budget
 Schedule
 Management/Organization
This information then must be made available to all authors. You can create and maintain a list of other relevant
documents and make these easily accessible to each author. If you have automated the process, you can offer
documents on-line and you can filter the information within the documents so that individual authors can get copies
of only the data that they need.
In the second case where information does not exist, the requirement author should document all assumptions with
the requirement. When the requirement is reviewed, the assumptions can also be reviewed and problems quickly
identified. It is also useful to document the assumptions even if the authors were provided the correct information.
You cannot ensure that all authors have read all the information or interpreted it correctly. If they document their
assumptions, you will avoid surprises later.
IMPLEMENTATION
A specification was released for the development of a requirements management tool. The first requirement was to
"provide a data base". The statement is one of implementation and not of need, and it is common to find such
statements in requirement specifications. Specifications should state WHAT is needed, not HOW it is to be provided.
Yet this is a common mistake made by requirement writers. Most authors do not intend to state implementation, they
simply do not know how to state the need correctly.
To avoid stating implementation, ask yourself WHY you need the requirement. In the example cited, it can be seen
that by asking WHY, the author can define all of the needs that the system must meet and will then state the real
requirements, e.g.:
 provide the capability for traceability between requirements
10
 provide the capability to add attributes to requirements
 provide the ability to sort requirements
These requirements state WHAT is needed, not HOW to accomplish it. Each of the above listed requirements might
result in a data base type of system, but the requirement for the data base was not needed.
There are two major dangers in stating implementation. The one most often cited is that of forcing a design when not
intended. If all the needs can be met without a data base, then why state the need for a data base. If they cannot be
met, another, or better way, then a data base will be the solution -- whether or not there was a requirement for a data
base.
The second danger is more subtle and potentially much more detrimental. By stating implementation, the author
may be lulled into believing that all requirements are covered. In fact, very important requirements may be missing,
and the provider can deliver what as asked for and still not deliver what is wanted. Providing a data base will not be
sufficient for someone needing a requirements management tool that need to be stated as requirements.
At each level of requirements development the problem of needs versus implementation will occur. At the system
level the requirements must state WHAT is needed. The system designer will determine HOW this can be
accomplished and then must define WHAT is needed at the subsystem level. The subsystem designer will determine
HOW the need can be met and then must define WHAT is needed at the component level.
To ensure that you have not stated implementation, ask yourself WHY you need the requirement. If this does not take
you back to a real need statement, then you are probably stating a need and not implementation.
The Implementation Trap. If you have been doing design studies at a low level, you may begin to document these
results as high level requirements -- this is the implementation trap. You will be defining implementation instead of
requirements.
An example of this occurred during the definition of the Assured Crew Return Vehicle (ACRV) requirements. An
individual submitted a requirement like this:
 The ACRV System shall enter when sea state is at TBD conditions.
The ACRV had no requirement for a water landing -- that was a design option. The individual had been working
with that design option, and from previous Apollo experience known that crew rescue was possible only in certain
sea sates.
When asked WHY the requirement was needed, the individual stated that the crew could not be left in the module
for a lengthy period of time, thus the landing needed to be where and when sea states could accommodate crew
rescue. He had a valid requirement -- but not the one he had written. Whether the ACRV landed on water or land,
removing the crew within a limited time period was essential. Thus the real requirement was:
 The ACRV System shall provide for crew removal within TBD time of landing.
The question WHY will resolve most implementation requirement errors. Always ask WHY a requirement is needed
to insure that you have not fallen into this lower level requirement trap.
OPERATIONS VS. REQUIREMENTS
This problem is somewhat similar to the implementation problem. The Simplified Aid for EVA Rescue (SAFER)
project provides examples of this problem.
The author intended to write an environment requirement in the SAFER Flight Test Article (FTA) Specification.
The statement was written as a description of operations, not a requirement about the environment.
 The SAFER FTA shall be stowed in the Orbiter Airlock Stowage Bag for launch landing, and on-orbit
stowage.
The real requirement is:
 The SAFER FTA shall be designed for the stowage environment of the Airlock Storage Bag for launch,
entry, landing, and on-orbit, as defined in TBD.
The next requirement again describes the operations and is confusing.
 The SAFER FTA shall be operated by an EVA Crew member wearing EMU sizes small through extra large
without limiting suit mobility.
The statement was rewritten and resulted in a requirement and a design goal. The design goal is needed because no
quantifiable requirement can be written regarding suit mobility.
 The SAFER FTA shall be designed for use with EMU sizes small through extra large.
 The SAFER FTA should not limit EVA crew member mobility.
The danger in stating operations, instead of a requirement is (1) the intent may be misunderstood and (2)
determining how to verify can be a problem.
11
USE OF TERMS
In a specification, there are terms to be avoided and terms that must be used in a very specific manner. Authors need
to understand the use of shall, will, and should:
 Requirements use shall.
 Statements of fact use will.
 Goals use should.
These are standard usage of these terms in government agencies and in industry. You will confuse everyone if you
deviate from them. All shall statement (requirements) must be verifiable, otherwise, compliance cannot be
demonstrated.
Terms such as are, is, was, and must do not belong in a requirement. They may be used in a descriptive section or in
the lead-in to a requirements section of the specification.
There are a number of terms to be avoided in writing requirements, because they confuse the issue and can cost you
money, e.g.
 Support
 But not limited to
 Etc.
 And/Or
The word support is often used incorrectly in requirements. Support is a proper term if you want a structure to
support 50 pounds weight. It is incorrect if you are stating that the system will support certain activities.
 WRONG: The system shall support the training coordinator in defining training scenarios.
 RIGHT: The system shall provide input screens for defining training scenarios. The system shall provide
automated training scenario processes.
The terms but not limited to, and Etc. are put in place because the person writing the requirements suspects that
more may be needed than is currently listed. Using these terms will not accomplish what the author wants and can
backfire.
The reason the terms are used is to cover the unknown. The contractor will not increase the cost in the proposal
because you added these terms. The only way to get the work added is to place an analysis task in the Statement of
Work (SOW) to determine if more items need to be added to the list. In the SOW you can control what effort the
contractor will expend to address these unknowns. If more items are found, you may have to increase the scope of
the contract to cover the additions.
If you have these terms in your requirements specification, the contractor may use them as an excuse for doing
unnecessary work for which you must pay. You cannot win by using the terms in the specification.
The term and/or is not appropriate in a specification. If you use and/or and the contractor does the or he has met the
terms of the contract. Either you want item 1 and item 2 or you will be satisfied with item 1 or item 2. Again, if you
use the term or, then the contractor has met the terms of the contract if he does either item.
REQUIREMENT STRUCTURE/GRAMMAR
Requirements should be easy to read and understand. The requirements in a system specification are either for the
system or its next level, e.g. subsystem. Each requirement can usually be written in the format:
 The System shall provide ........
 The System shall be capable of ........
 The System shall weigh ........
 The Subsystem #1 shall provide ........
 The Subsystem #2 shall interface with .....
Note: The name of your system and the name of each subsystem appears in these locations. If you have a complex
name, please use the acronym, or your document will have many unneeded pages just because you have typed out a
long name many times.
Each of these beginnings is followed by WHAT the System or Subsystem shall do. Each should generally be
followed by a single predicate, not by a list. There are situations where a list is appropriate, but lists are over-used.
Since each item in the list must be verified, unless all items will be verified by the same method and at the same
time, it is generally not appropriate to put items in a list.
12
Requirement statements should not be complicated by explanations of operations, design, or other related
information. This non-requirement information should be provided in an introduction to a set of requirements or in
rationale.
You can accomplish two things by rigorously sticking to this format. First, you avoid the Subject Trap. Second, you
will avoid the Subject Trap. Second, you will avoid bad grammar that creeps into requirements when authors get
creative in their writing.
Subject Trap. A system specification contains requirements for the system, e.g., you may want to require that the
system provide control. A set of requirements might be written that reads as follows:
 The guidance and control subsystem shall provide control in six degrees of freedom.
 The guidance and control subsystem shall control attitude to 2+/- 0.2 degrees.
 The guidance and control subsystem shall control rates to 0.5 +/- 0.05 degrees/second.
The subject trap is created because the author has defined a guidance and control subsystem. Controlling attitude
and rate is a system problem, it requires not only a guidance and control subsystem but also a propulsion subsystem
to achieve these attitudes and rates. Determining what subsystems will be required to accomplish the requirements is
part of the design process The requirements should be written from the system perspective, as follows:
 The system shall provide six degrees of freedom control.
 The system shall control attitude to 2 +/- 0.2 degrees.
 The system shall control rates to 0.5 +/- 0.05 degrees/second.
The author of the original requirements was not trying to define the lower level breakout. He probably comes from a
control background and sees the system from that perspective and hence writes requirements that way. The flow
down of requirements, to all affected segments, elements, and subsystem, will be badly affected if these
requirements are not written correctly.
Bad Grammar. If you use bad grammar you risk that the reader will misinterpret what is stated. If you use the
requirements structure suggested above, you will eliminate the bad grammar problems that occur when authors try to
write complex sentences and use too many clauses.
Another solution is to write requirements as bullet charts. When the content is agreed upon a good writer can
convert the information into a sentence for the specification.
Authors will also try to put all that they know in a single sentence. This results in a long complex sentence that
probably contains more than one requirement. Bullet charts or one good editor can alleviate this problem. The
following requirement contains multiple requirements.
 The ACRV System shall provide special medical life-support accommodations for one ill or injured crew
member consisting of medical life-support and monitoring equipment and the capability of limiting impact
accelerations on that crew member to be not greater than.... for a total impulse not to exceed ....
The requirement needs to be broken into at least four requirements and it could use a lead-in such as:
 The ACRV will be used as an ambulance for an ill or injured crew member. Only one crew member will
accommodate at a time. The following define the unique requirements for this capability.
 ..provide medical life-support accommo-dations for one crew member
 ..provide monitoring equipment for one crew member
 ..limit impact accelerations to the ill or injured crew member to no greater than...
 ..limit total impulse to the ill or injured crew member to ...
UNVERIFIABLE
 Every requirement must be verified.
Because every requirement must be verified, it is important to address verification when writing the requirements.
Requirements may be unverifiable for a number of reasons. The following discusses the most common reason -- use
of ambiguous terms.
Ambiguous Term. A major cause of unverifiable requirements is the use of ambiguous terms. The terms are
ambiguous because they are subjective -- they mean something different to everyone who reads them. This can be
avoided by giving people words to avoid. The following lists ambiguous words that we have encountered.
 Minimize
 Maximize
 Rapid
 User-friendly
13
 Easy
 Sufficient
 Adequate
 Quick
The words maximize and minimize cannot be verified, you cannot ever tell if you got there. The words minimum
and maximum may be used is the context in which they are used can be verified.
What is user-friendly and what is rapid? These may mean one thing to the user or customer and something entirely
different to a designer. When you first begin writing your requirements, this may be what you are thinking, but you
must write the requirements in terms that can be verified. If you must use an ambiguous term in first draft
documents, put asterisks on either side of the term to remind yourself that you are going to have to put something
concrete in the requirement before you baseline the document.
There may be cases where you cannot define, at your level, exactly what is needed. If this is the case, then you
should probably be writing a design goal, not a requirement. You can do this by clearly indicating that your
statement is a goal, not a requirement. Use of the word should, instead of the shall, will denote a design goal.
MISSING
Missing items can be avoided by using a standard outline for your specification, such as those shown in Mil-Std-490
or IEEE P1233, and expanding the outline for your program.
Many requirements are missed because the team writing the requirements is focused on only one part of the system.
If the project is to develop a payload, the writers will focus on the payload's functional and performance
requirements and perhaps skip other important, but less obvious, requirements. The following is a checklist of
requirement drivers you need to consider:
· Functional
· Reliability
· Performance
· Maintainability
· Interface
· Operability
· Environment
· Safety
· Facility
· Regulatory
· Transportation
· Security
· Deployment
· Privacy
· Training
· Design constraints
· Personnel
You will need to develop detailed outlines for your specification for the functional and performance requirements,
and in perhaps other areas.
You may also have a number of requirements that you must include by reference. In particular, those standards that
define quality in different disciplines (materials and processes) or for different projects.
Detailed requirements analysis is necessary to assure that all requirements are covered. There are a number of
approaches to performing requirements analysis and a number of tools for doing this work. Detailed requirements
analysis is beyond the scope of this paper.
OVER-SPECIFYING
The DoD has stated that over-specification is the primary cause of cost overruns on their programs. Over-specifying
is most often from stating something that is unnecessary or from stating overly stringent requirements.
Unnecessary Items. Unnecessary requirements creep into a specification in a number of ways. The only cure is
careful management review and control.
People asked to write requirements will write down everything they can think of. If you do not carefully review each
requirement and why it is needed before baselining the specification, the result will be a number of unneeded
requirements.
Example: The Space Station Training Facility (SSTF) had a requirement for a high-fidelity star field. The author
knew that a new high-fidelity star field was being developed for the Shuttle Mission Simulator (SMS) and assumed
they might as well put the same thing in the SSTF. The crew needs a background to view outside the Space Station,
but there is no need for a high-fidelity star field, since they do not use the stars for navigation.
14
The requirement needs to be written for a visual background for crew orientation. The design process will determine
if using the SMS star field is a cost effective solution or it something simpler is adequate and more cost effective.
Example: A number of SSTF requirements were deleted when their authors were queried as to the need. The need
they stated was that "it would be nice to have". Most program do not have budgets for nice to have items.
Unnecessary requirements can also appear after baseline if you let down your review and control process. In ACRV
a number of requirements were added after the initial baseline that were not needed. One such instance occurred
because of an error in the baseline document.
Example: The baseline document had two requirements:
 The ACRV System shall be capable of operating over a planned operational life of thirty (30) years.
 The Flight Segment shall provide an operational life of 30-years for the flight elements.
The second requirement, for the Flight Segment, was not required since the System requirement was adequate. The
action that should have been taken was to delete the Flight Segment requirement. Instead, two more requirements
were added to require a 30-year operational life of the other two segments.
At least one other requirement was added to ACRV that was a duplicate of an existing requirement. The wording of
the two differed only slightly and their rationale was the same. It requires careful attention to detail to avoid this type
of problem.
Over Stringent. Most requirements that are too stringent are that way accidentally, not intentionally. A common
cause is when an author writes down a number but does not consider the tolerances that are allowable.
Thus, you should not state that something must be a certain size, e.g., 100 ft.2, if it could just as easily be 100 +/- 10
ft.2. You do not need to ask that something deliver a payload to exactly 200 n.m. if greater than or equal to 200 n.m.
is acceptable.
Some of the major horror stories of the aerospace industry deal with overly-stringent requirements. One contractor
was severely criticized for charging $25,000 per coffee pot in airplanes built for the government. But the
requirements for the coffee pot were so stringent, that the plane could have crashed and yet no coffee could spill. It
cost a great deal to develop the coffee pot and to verify that it met its requirements. Each copy had to be built to a
stringent design.
The solution to this problem is to discuss the tolerances allowable for any value and then to write the requirement to
take into consideration those tolerances. Each requirement's cost should also be considered.
AUTHOR'S BIOGRAPHY
Ivy F. Hooks is President and CEO of Compliance Automation, Inc., a woman-owned small business. She has over
thirty years experience, 20 with NASA, where she was the separation integration manager for the Space Shuttle and
also manager of Shuttle flight software verification, and 10 in private industry. For the past eight years, she has
specialized in requirements definition and management, marketing the CAI product Vital Link, as well as
conducting training seminars and performing consulting work for government and industry.
15
Requirements Working Group Information Paper
Presented at the 1996 INCOSE Symposium. 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.
Characteristics of Good Requirements
Pradip Kar
Armament Systems Division
United Defense Limited Partnership
4800 East River Road, MS M239
Minneapolis, Minnesota 55421.
Michelle Bailey
Naval Air Warfare Center, China Lake
Mail code 52C000D
China Lake, California 93555.
Abstract. This paper identifies and documents the major characteristics of well defined requirements for both
individual requirements and aggregates of requirements such as those found in specifications. Characteristics
exhibited by well defined requirements are described. The descriptions are followed by a brief discussion of the
characteristics. A few examples of well defined requirements are provided. Some supporting characteristics of
requirements are also described. These supporting characteristics are not properties of the requirements themselves
but are attributes assigned to individual requirements to assist in managing the requirements through the life cycle.
The paper was written and reviewed by members of the requirements working group of the INCOSE.
INTRODUCTION
It is generally recognized that the development of good requirements is essential to quality product design.
However, it is well known that requirements for many programs in the past have been poorly written. The reasons
for this shortcoming are many and include a lack of clear definition of user need and insufficient time and effort
dedicated to requirements definition. Also there are few examples of well defined requirements for reference.
One of the fundamental problems associated with writing good requirements is that most engineers are not
specifically trained to write requirements. The basics of well defined requirements are clarity, conciseness and
simplicity. Elegant, entertaining prose is not needed. In the words of Albert Einstein, "When you are out to describe
the truth, leave elegance to the tailor". It is clear that to write good requirements, engineers need to develop writing
skills which are not taught in school. They also need good and readily accessible examples of both well and poorly
written requirements.
This paper describes the essential characteristics of well defined requirements. Characteristics of both individual
requirements and aggregates of requirements (as embodied in a specification) are provided. Some examples of well
defined requirements are included in each category. This characterization can be used for
requirements development as well as in requirement reviews and audits for assessing the quality of requirements. It
can also be used in Systems Engineering and management process improvements. The paper also describes a few
supporting characteristics of requirements. These supporting characteristics, while not essential for writing
individual or aggregate requirements, assist in the process of requirements management, specially where the total
population of requirements is large.
DEFINITIONS
The definitions for the following terms used in this paper, are from IEEE Std 1220-1994.
Constraint. A limitation or implied requirement that constrains the design solution or implementation of the
systems engineering process, is not changeable by the performing activity, and is generally non allocable.
Requirement. A statement identifying a capability, physical characteristic, or quality factor that bounds a product or
process need for which a solution will be pursued.
Specification. A document that fully describes a physical element or its interfaces in terms of requirements
(functional, performance, constraints and physical characteristics) and the qualification conditions and procedures
for each requirement.
16
System. The top element of the system architecture, specification tree, or system breakdown structure that is
comprised of one or more products and associated life cycle processes and their products and services.
CHARACTERISTICS OF REQUIREMENTS
The characteristics of requirements are their principal properties. Characteristics may apply to individual
requirements; or to an aggregate of requirements. A well defined, mature set of requirements should exhibit certain
individual and aggregate characteristics. These characteristics are listed below, with synonyms in parenthesis. The
description of each characteristic is followed by a brief discussion of the characteristic and an example of a
requirement displaying the required characteristic.
CHARACTERISTICS OF INDIVIDUAL
REQUIREMENTS
The following paragraphs describe and discuss the desired characteristics of good requirements.
Necessary. The stated requirement is an essential capability, physical characteristic, or quality factor of the product
or process. If it is removed or deleted, a deficiency will exist, which cannot be fulfilled by other capabilities of the
product or process.
Discussion. This is a primary characteristic. In order to be a well defined requirement, the requirement statement
must exhibit this characteristic. There is no room in a specification for unnecessary or "nice to have" requirements
because they add cost to the product. An example of a necessary requirement for a combat vehicle could be "The
vehicle's combat loaded weight shall not exceed 35 Tons". The condition "combat loaded" is defined elsewhere in
the body of the specification. This requirement imposes a major constraint on the design of the vehicle and it is
usually based on transportability, utilizing existing resources. If this requirement is deleted from the specification, a
major need (i.e. transportability) will not be met, even if the vehicle is capable of satisfying every other requirement.
Accordingly, the requirement is necessary.
One good test of necessity is traceability to higher level documentation. In the case of system specifications,
traceability may be checked to user documentation such as the Operational Requirements Document (ORD). If there
is no parent requirement, the requirement may not be necessary.
Concise (minimal, understandable). The requirement statement includes only one requirement stating what must be
done and only what must be done, stated simply and clearly. It is easy to read and understand.
Discussion. During requirements definition there are often many arguments as to what exactly is meant by 'one
requirement'. The answer in most cases requires engineering judgment. An example of this can be the requirement
for an alarm. Within a military system, both a visual and an audible alarm is often required to warn the crew about
abnormal or unsafe conditions. Also, the same alarm is used for multiple conditions, such as high temperature, low
oil pressure and low fuel level. The question here is what constitutes a single requirement? Should there be a single
requirement for the alarm with perhaps a table defining the conditions under which the alarm is activated? An
example of a requirement following this approach can be "The element shall provide a visual and audible alarm
under all conditions listed in Table 3-10. The alarm shall be activated no longer than 1 second after the condition
exists." Is this one requirement? Or should we write a requirement for each condition? Should the visual and audible
parts be separated into two requirements? On the one hand we do not want to write multiple requirements in one
paragraph; on the other we do not want the number of requirements to proliferate without reason. Each requirement
will have to be managed and verified; and has a cost associated with it.
One approach to making a decision on this question is to determine how the requirement will be verified. Obviously
one would like to verify that both the visual and audible alarms work together. So any test or demonstration to verify
the requirement must include both. Therefore, the visual and audible parts should be combined into a single
requirement. Further, if the conditions providing inputs to the alarm can be incorporated into the same test or
demonstration, these should also be included in the same requirement. The conclusion is: this is a requirement for a
single alarm, which can be verified using a single test or demonstration. Accordingly, it is a single requirement.
To be concise, the requirement statements must not contain any explanations, rationale, definitions or descriptions of
system use. The place for these texts are analysis and trade study reports, operational concept documents or user
manuals. A link can be maintained between the requirement text and the supporting analyses and trade studies in a
requirements data base so that if desired, the rationale and explanations can be obtained rapidly.
Implementation free. The requirement states what is required, not how the requirement should be met. A
requirement statement should not reflect a design or implementation nor should it describe an operation. However,
the treatment of interface requirements is generally an exception.
17
Discussion. This characteristic of a requirement is perhaps the hardest to judge and implement. What exactly is
meant by implementation free? At the system level, requirements can be truly abstract or implementation free. An
example of a requirement for a shipboard system at the system level is: "The system shall be capable of engaging
sea skimming anti ship cruise missile (ASCM) targets." This sentence should be followed by expected performance
data (a quantification of what "engaging" means) against specific ASCM targets. It can be seen from the
requirement statement that no specific implementation has been stated, so the system designer is free to pursue
alternative, competing system designs, all capable of fulfilling the requirement.
The system requirements have to be implemented by a system design solution. After the system designer has
performed a trade study between alternatives and selected a candidate solution, the system requirement stated in the
previous paragraph, have to be allocated to the elements defined by the system design. This incremental procedure
of allocating requirements to the next lower level elements, dependent on system design, has led to the remark: "one
level of design is the requirement at the next lower level." In the ASCM example above, let us say that the system
design solution consists of a radar element to detect and track the targets; a command and control element to
perform target recognition, identification, and weapon assignment and control functions; and a missile to engage and
destroy the target. Then there will be three elements below the system level on the system specification tree and the
system requirement will have to be allocated to these three elements. The element requirements will be for a radar, a
command and control and a missile. The allocated requirement for the radar element can be: "In a clear
environment, the radar element shall be capable of detecting 0.1 (meter)2 ASCM targets at ranges of up to 20 KM
with a probability of detection of no less than 0.9 and probability of false alarm of no greater than 10 -6." Note that
the requirement statement reflects the design at the system level (the solution is a radar and associated command and
control; and missile) but implies no specific radar design. This allows the radar designer to pursue alternative radar
designs. The conclusion is that a requirement is implementation free at the level that it is being specified, but is a
result of the design activity at the level above it.
Interface requirements are usually an exception to the implementation free rule. Interface requirements are specified
in interface control drawings or ICDs which describe a specific design of an interface or mating parts. For example
in the case of an electronic interface, the ICD may include part numbers of the interfacing connector(s); pin
assignments for various signals; waveform and timing information; and source and sink impedances on each line. In
this case the requirement must provide complete information so that the two sides of the interface can be designed to
work as specified when connected to each other. Interface requirements are usually specified as a result of an
interface control working group (ICWG) activity. The ICWG is usually chaired by the system integrator and has
members from contractors representing both sides of a specific interface. The ICWG establishes both the data
required to go across the interface and the design implementation of the interface.
Attainable. (achievable or feasible). The stated requirement can be achieved by one or more developed system
concepts at a definable cost. This implies that at least a high level conceptual design has been completed and cost
tradeoff studies have been conducted.
Discussion. This characteristic is a test of practicality of the numerical value or values set forth in a requirement. It
signifies that adequate analyses, studies and trades have been done to show that requirement can be met by one or
more concepts and that the technology costs associated with the concept(s) are reasonable within the cost constraints
of the program.
For example, consider the following requirement for a radar element: "In a clear environment, the radar element
shall be capable of detecting 0.1 (meter)2 ASCM targets at ranges of up to 20 KM with a probability of detection of
no less than 0.9 and probability of false alarm of no greater than 10-6." It is well known that radars operating in the
microwave frequencies are more or less horizon limited due to straight line propagation of electromagnetic waves at
these frequencies. Under the circumstances, required detection ranges which are much beyond the radar horizon,
(the 20 KM range is within the capability of a mast mounted shipboard radar) should be viewed with suspicion
unless it is specified under anomalous propagation conditions.
Complete. (standalone) The stated requirement is complete and does not need further amplification. The stated
requirement will provide sufficient capability.
Discussion. Requirements should be stated simply, using complete sentences. Each requirement paragraph should
state everything that needs to be stated on the topic and the requirement should be capable of standing alone when
separated from other requirements. Many people seem to have trouble specifying a system parameter called growth
completely. Let us examine a basic statement: "The vehicle shall permit growth" as an initial idea in trying to
specify growth. The question is how much growth and in which areas? Remember, the requirement should be
complete and not need amplification elsewhere. Growth is usually provided in new design systems for two reasons:
 Pre Planned Product Improvements (P 3I) and
 Through life growth.
18
Early P3I analysis may indicate the need to fit new equipment into a vehicle, which will need additional space,
power, cabling, cooling and weight margins. Through life growth is system growth due to the addition of new
capabilities in a system to address new requirements which may be imposed during the life cycle of the system but
which were not known during system development. An example of this type of growth is the addition of a whole
new mission such as tactical ballistic missile defense (TBMD) to the Aegis combat system on U.S. Navy ships.
Other types of through life growth are small changes to fix problems and provide minor capability improvements in
response to user need.
Margins must be provided for both types of growth, although it is easier for P 3I growth. A requirement statement,
for example, in the area of weight growth, may then be stated as follows: "The vehicle shall permit 12% weight
growth." This requirement, addresses both how much and in which area, and will permit the vehicle designers to
design the chassis, engine/transmission and the suspension subsystems taking into account the growth margin.
Consistent. The stated requirement does not contradict other requirements. It is not a duplicate of another
requirement. The same term is used for the same item in all requirements.
Discussion. This characteristic of well defined requirements is usually well understood and does not cause much
discussion. However, in a large set of requirements which are not well organized by some clearly defined categories,
it may be hard to spot duplications and inconsistencies. It is therefore important to organize the requirements (say in
accordance with MIL STD 490A) so inconsistencies can be spotted during reviews and audits. It is also important to
maintain a glossary of terms being used on the program because the meaning of some words are domain dependent.
Unambiguous. Each requirement must have one and only one interpretation. Language used in the statement must
not leave a doubt in the reader's mind as to the intended descriptive or numeric value.
Discussion. This is an area where a formal requirements language for systems engineering may ultimately help. The
English language can be unstructured and in some cases the same sentence may mean different things to different
people. What is needed are some standard constructs and some words to avoid. While the following list is
incomplete, it will point the reader in the right direction.
Standard Constructs. One important word that is included in most DOD specification requirements is the word
"shall" for all requirements. It is a statement of imperative need and indicates that the requirement must be verified.
A standard construct for a requirement is therefore: "The system(or element or equipment) shall ...". Other
requirements are stated as a goal in specifications. The goal requirements are not imperatives, and sentences
containing them do not contain the word "shall". An example of a goal requirement is: "The goal is to provide a
maximum range capability of 45 Kilometers."
The word "will" is not used to signify a requirement. It may be used in a sentence containing a statement of fact such
as "vehicle tests will be conducted at government test facilities". They may also be used to indicate that some events
will take place in the future. "Test instrumentation will be provided by the government in 1998."
When a requirement is defined by referencing another standard, use a construct such as "in accordance with" or "as
specified in". An example requirement is "System parts and equipment requiring identification shall be marked in
accordance with MIL STD 130."
Do not use "Minimum" and "Maximum" to state limits. Use "No less than" or "No greater than". This standard
construct avoids the ambiguity associated with the limiting values. The requirement "Gun alignment error in
elevation shall be no greater than 1.5 milliradians" is not vague because it is clear that a 1.5 milliradian error is
permissible. On the other hand, if the requirement was stated as "Gun alignment error in elevation shall be 1.5
milliradians maximum", there would be some ambiguity as to whether the limiting value i.e. 1.5 milliradians was
permissible. This rule does not mean that the words "minimum" and "maximum" cannot be used at all - just do not
use them to state limits. For example a requirement can be stated as "The gun system's maximum range shall be no
less than 25 KM" to convey that the maximum range of the gun system must be equal to or greater than 25 KM.
Words to avoid. Specific words that should be avoided because they are vague and general are "flexible", "fault
tolerant", "high fidelity", "adaptable", "rapid or fast", "adequate", "user friendly", "support", "maximize" and
"minimize" ("The system design shall be flexible and fault tolerant" is an example). Other words that should be
avoided are "and/or", "etc." and "may".
Verifiable. The stated requirement is not vague or general but is quantified in a manner that can be verified by one
of these 4 alternative methods: inspection, analysis, demonstration or test.
Discussion. Verifiability is an important characteristic of a requirement. The verifiability of a requirement should be
considered at the same time that a requirement is being defined. A requirement which is not verifiable is a problem,
both for the customer and the contractor because it involves the acceptability of a system. In order to be verifiable,
the requirement should be stated in measurable terms such as: "The overall length of the system shall be 105+/-0.5
inches" (verifiable by inspection) or "Gun alignment error in elevation shall be no greater than 1.5
milliradians"(verifiable by test).
19
Questions are often asked as to what exactly is the difference between a demonstration and a test; and how to decide
between a demonstration and a test, when planning a verification strategy. The answer to the first question is extent
of instrumentation. A test is fully instrumented while a demonstration involves observation and simple recording of
information such as time. A well known demonstration which is required on many programs is a maintainability
demonstration. The objective of a maintainability demonstration is to verify the maintainability of a system, usually
specified as the mean time to repair (MTTR).
During the demo a trained soldier or sailor (made available by the user community) attempts to repair a series of
artificially induced faults on the system, using the technical documentation and available spare parts. For each fault,
the only measurements are time taken to diagnose the problem, correct the problem and re- test the system for
correct operation. The achieved MTTR is computed from the measured times.
A test, on the other hand, utilizes a large number of instruments. A shipborne missile firing test to determine missile
performance against a target utilizes both shipboard instrumentation and missile borne telemetry to determine not
only the end results but intermediate results as well to determine whether the missile performed to requirements
throughout the flight.
As can be expected, testing is the most expensive and also the most reliable method of verification. Verifying every
requirement by test can be expensive. When determining a verification strategy, trade studies may have to be
performed to decide the optimum strategy. This is where analysis comes in. Analysis is often much cheaper than test
and can be used effectively in a supporting role. For example, computer models of the system can be used to verify
system performance under certain (hard to achieve in real life) conditions, especially after the model has been
validated against test results.
CHARACTERISTICS OF AGGREGATE
REQUIREMENTS
Aggregate requirements are a set of requirements for a system or element that specify its characteristics in totality.
Usually these aggregates are found in specifications. Characteristics of individual requirements are applicable to
aggregates also. The following characteristics are applicable to aggregates.
Complete. The set of requirements is complete and does not need further amplification. The set of requirements has
addressed all categories (see supporting characteristics), and covers all allocations from higher levels.
Discussion. This characteristic addresses the difficult problem of identifying requirements which are necessary but
are missing from the set. There are several approaches to identifying missing requirements. One is to develop the
system operations concept and an associated set of scenarios. Walking through these from cradle to grave: how will
the system be delivered? how will it be deployed? how will it be used, upgraded and disposed of, help to identify
missing requirements. The next step is to walk through the same set of scenarios and play the "what if" game. What
if something goes wrong? This step usually uncovers a whole new set of requirements. Another approach is to
develop a checklist of topics or areas such as a specification outline as given in MIL STD 490A or DOD STD
2167A and verify that requirements exist in each topic area or if they do not, there are good reasons for it. Yet
another is to check the aggregate against a higher level specification (if one exists) to verify that all allocated
requirements have been included in the set. Often we leave out the obvious such as "The ship shall float."
Consistent. The set of requirements does not have individual requirements which are contradictory. Requirements
are not duplicated. The same term is used for the same item in all requirements.
Discussion. This characteristic addresses the problem of identifying unnecessary or conflicting requirements which
are inadvertently included in the set. Assignment of a project unique identification to each requirement, and
thorough reviews should eliminate these requirements.
SUPPORTING CHARACTERISTICS
These are secondary properties or attributes of individual requirements which provide supplementary information
about the requirement, its relationship to other requirements and source documents; and assist in requirements
management. These supporting characteristics are not essential in all cases and if an automated requirement
management tool is used, the tool may generate some or all of these attributes automatically.
Project unique identification. (PUID). The PUID is a unique identifier assigned to a single requirement for
identification and tracking. It may be either numeric or alpha numeric. The PUID assists in identification,
maintaining change history, and provides traceability.
Assigning a PUID is probably a better method to track and maintain requirements on an individual basis than a title
or some such textual description. PUIDs can be purely numeric or alphanumeric. An alphanumeric PUID, in
20
addition to being a unique identifier, can provide information about the requirement. For example, the PUID
SYS0001 clearly shows that the requirement is a system requirement. On the other hand, the numeric PUID can be
automatically assigned to newly formed requirements by many requirement management tools.
Level. This attribute indicates the level at which the specific requirement is applicable in the System Hierarchy. For
example, level I may indicate a top or system level requirement. Level II may be the segment level requirement.
Requirements written at the right level will provide adequate information without constraining the designer's
freedom. While not an essential characteristic, levels can be used to provide statistics on requirements fan out and
verification levels.
Category. Categories are used to classify requirements. There are two major categories:
 Program requirements. These are customer or user requirements imposed on contractors through
contractual vehicles other than specifications. Examples of documents in which program requirements are
listed are the contract itself and the contract statement of work (SOW). Program requirements include:
compliance with federal, state or local laws including environmental laws; administrative requirements
such as security; customer/contractor relationship requirements such as directives to use government
facilities for specific types of work such as test; and specific work directives (such as those included in
Statements of Work and Contract Data Requirements Lists). Program requirements may also be imposed on
a program by Corporate policy or practice.
Program requirements are different from the requirements that have been discussed so far. These are not
requirements imposed on the system or product to be delivered, but on the process to be followed by the
contractor. Program requirements should be necessary, concise, attainable, complete, consistent and
unambiguous. Program requirements are managed in the same manner as product requirements.
 Technical (product) requirements. These are requirements applicable to the product or service to be
delivered. Product requirements are usually listed in specifications or interface control drawings. These are
further classified by these requirement types:
a) Functional. Qualitative requirements describing what the system needs to do without describing them in
quantitative terms. These requirements are usually descriptive and are verified by the summation of the associated
performance requirements. An example of a functional requirement for a radar element is: "The radar element shall
be capable of detecting targets."
b) Performance. These are quantitative requirements of system performance, and are verifiable individually. One
performance requirement associated with the functional requirement example in the previous paragraph can be "In a
clear environment, the radar element shall be capable of detecting 0.1 (meter)2 ASCM targets at ranges of up to 20
KM with a probability of detection of no less than 0.9 and probability of false alarm of no greater than 10-6." In fact
an appropriate paragraph heading for this requirement would be "Target Detection", the function with which it is
associated. There are usually several performance requirements associated with a single functional requirement.
c) Design constraints. These requirements identify the constraints under which the system is required to operate or
exist. Size and weight limitations are included in this category, as are environmental requirements. An example of a
design constraint in the area of weight is "The vehicle's combat loaded weight shall not exceed 35 Tons".
d) Interface. Interface requirements are the definition of how the system is required to interact with external
systems (external interface), or how subsystems within the system interact with each other (internal interface).
Interface requirements are often an exception to the 'implementation free' rule of requirements.
e) Non requirement. In a strict sense this is not a requirement type. Very often some explanatory text is provided in
source documents which are not requirements, but which is maintained in the requirements data base for
completeness and to re- create the original source document, if needed.
Compliance level. There are two levels of compliance:
 Mandatory. This attribute is applicable to all requirements defined in sentences containing the word
"shall". These requirements must be verified.
 Goal or objective. These indicate that this level of performance is desired by the customer. They are not
mandatory but need rationale and documentation if they are not met.
Allocated to. Each requirement must be allocated to one or more lower level components. This can be done by
allocating the requirement to a component name or to the name of the specification that will define the component
requirements. Allocation provides insurance that all requirements are flowed down to the next level. It is a basis for
checking that lower level requirements are responsive to the higher level requirement.
Parent PUID. This attribute provides a link to the immediate parent of a derived or lower level requirement. For a
lower level requirement, this PUID will represent the next higher level requirement. This attribute is required to
provide vertical traceability through the specification tree of the system.
21
Source. The top level document, supplied by the user, that is the sources for all program requirements. Each
requirement is traced to this document and to a unique paragraph number. The document can be a specification,
operational requirements document or statement of work. This attribute is required to provide direct traceability for
individual requirements to user documents.
Specification number, specification title, paragraph number and paragraph title. These attributes are important
when searching and printing requirements. They are used to associate requirements with the appropriate document.
Rationale. This attribute provides a link to the data or tradeoff analyses which support the requirement. The
supporting data may include the reason or reasons a requirement is needed; any assumptions made at the time the
requirement was formulated; numbers and locations of analysis or trade study reports which support formulation of
the requirement and its current value or values. In a large system the rationale for every requirement is not readily
available. This attribute provides an index to the rationale for every requirement.
Verification method. This attribute describes and tracks the selected verification method for the requirement. The
alternatives are: inspection, analysis, demonstration and test.
Verification documents. This attribute provides a link to the number, title and paragraph number of the verification
Plan and Procedure (such as a test plan) used to verify the requirement.
Change notices. This attribute records the number and date of specification change notices affecting the stated
requirement. It assists in maintaining the change history associated with this requirement.
Risk. This attribute provides a record of the risk associated with a requirement, if any. A quantitative assessment of
the risk and the date of the assessment is provided.
TPM Parameter. This attribute provides a record of the Technical Performance Measure Parameter in which the
requirement is included (The requirement itself may be a TPM parameter) and the current value of the parameter.
Current status. This attribute provides a record of the current status of the requirement. The alternatives are:
 TBD (to be defined) - this indicates that the value of the requirement has not been defined yet. It is good
practice to use TBDs for requirements which do not have defined values. It can be used to provide metrics
such as the number of requirements which are not yet defined.
 TBR (to be reviewed)- this indicates that a preliminary value is available but needs further review.
 Defined. - This indicates that a final value for the requirement has been obtained through analysis and
trades.
 Approved. - The requirement has been reviewed and approved by the appropriate authorities.
 Verified. - The requirement has been verified in accordance with the verification plan.
 Deleted. - The requirement is no longer applicable to the program.
Standards. The standards or conditions under which a requirement must be met.
SUMMARY
Writing good requirements is difficult, requires careful thinking and analysis, but is not magical. Requirements
which have the characteristics described in this paper will be easier to meet and help insure that the customer gets
what he wants. Time spent up front, carefully defining and articulating the requirements is the first step towards
insuring a high quality product.
ACKNOWLEDGEMENTS
The authors wish to thank Ivy Hooks (Compliance Automation/Vital Link), Beth Simon (McDonnell Douglas
Aerospace), Dave Jones (Texas Instruments); and Allan Ray, John Bangs and Saumya Sanyal (United Defense) for
reviewing the paper and providing useful suggestions and comments.
BIBLIOGRAPHY
1.
2.
3.
4.
Writing Good Requirements, Ivy Hooks: Proceedings of the Fourth Annual Symposium, NCOSE working
Group Papers Volume II.
An Introduction to Systems Engineering, J. Douglas Sailor.
Current System Development Practices using the Hatley/Pirbhai Methods, Derek Hatley, The journal of
NCOSE Volume 1 Number 1 July-September 1994.
Application of the System Engineering process to define requirements for Computer Based design tools,
Benjamin Blanchard, Wolter Fabrycky and Dinesh Verma March 1994.
22
5.
6.
7.
8.
9.
Requirements Management/Traceability: A case Study - NASA's National Launch System, Mary Beth
Pinkerton & Frank R. Fogle, Proceedings of the Second Annual Symposium, NCOSE
Development & implementation of an integrated Systems Engineering environment, R.M. Harwell,
Proceedings of the Second Annual Symposium, NCOSE.
Requirements for Development of Software Requirements, Brian W. Mar, Proceedings of the Fourth
Annual Symposium, NCOSE.
What Is A Requirement? Richard Harwell, Erik Aslaksen, Ivy Hooks, Roy Mengot, Ken Ptack,
Proceedings of the Third Annual International Symposium, NCOSE.
IEEE Std 1220-1994 (Issued February 1995 for trial use).
ABOUT THE AUTHORS
Pradip Kar is the Systems Engineering Manager for the Armament Systems Division of United Defense Limited
Partnership, a partnership of FMC and Harsco corporations. Over the past 14 years he has worked on a number of
engineering development programs such as the Army's Crusader and Bradley Fighting Vehicles, and the Navy's
Aegis and Mk 41 Vertical Launching System programs. Prior to working at United Defense, he was an officer in the
Indian Navy and spent time developing a command and control system. He has been a member of INCOSE since
1992. He has a B.S degree in Electrical Engineering from London University and has done graduate work in
Computer science at the University of Minnesota.
Michelle Bailey is currently a member of the Range Architecture Office, Naval Air Warfare Center Weapons
Division, China Lake, Ca. which has responsibility for major investments within the Navy's West Coast test ranges.
Previous experience includes leading the software development effort on the AIM-9R air to air missile and
subsequently serving as the systems engineer for that effort. Other experience includes working on advanced signal
processing systems and a one year tour in the Pentagon where she wrote the Naval Science and Technology
Requirements. Other publications include the China Lake design process handbook, the China Lake System
Engineer Handbook, "System Engineering for all Engineers" NCOSE 1994 Symposium, and "HWIL Contributions
to Navy Test and Evaluations" SPIE 1996 Symposium.
23