Use of U.S.

DoD visual information does not imply or constitute DoD endorsement

WRITING GOOD REQUIREMENTS TRAINING

Systems Engineering and Integration & Test Discipline Team

T-401-007 Rev. Rev 7 (07/20)

Outline

Edit Master text styles Fourth level

Second level Fifth level
Third level

L3HARRIS WRITING GOOD REQUIREMENTS COURSE T-401-007 2

Requirements Overview

L3HARRIS WRITING GOOD REQUIREMENTS COURSE T-401-007 3

What are requirements?

• Written statements that describe what must be proved to the customer to verify completion of a contract
• Communication to developers what the developed product must be, how it must behave, and how it must
perform
• Provided by customers
– Government (SETA)/Prime/Customer  L3Harris
– L3Harris SE  L3Harris Development Teams
– Including L3Harris subcontractors

Contractual
Written
We design products against the requirements, so we need to understand them
Provable
Indicates acceptable completion of a product

Satisfied by the system or product

Verified through acceptance testing (IADT)

L3HARRIS WRITING GOOD REQUIREMENTS COURSE T-401-007 4

Some different classes of requirements

• Product requirements define characteristics of a deliverable product

• Process requirements describe behavior of the contractor (e.g., in the Statement of Work)
– Example: "The software shall be developed using C++ under a configuration management system." This is often in a
spec, but should be in the statement of work.
• Requirements communicate to developers what the product that they develop must be, how it must behave,
and how it must perform.

This training focuses primarily on product requirements,

but the principles apply universally
L3HARRIS WRITING GOOD REQUIREMENTS COURSE T-401-007 5
Signs and Symptoms of Requirements Problems

• Customer and contractor disagree on interpretation

• TBX list not closing on schedule
• Excessive requirements defects
– Excessive PTRs/DRs against specifications
• Failing performance tests
– Early component level and integration testing can provide clues
• Late lifecycle requirements updates/changes
• Systems and services not meeting user needs
– Inadequate validation
• Project cost and schedule overrun
– Can be detected early
• Dissatisfied customers
• Loss of follow-on work

It all starts with the requirements !

L3HARRIS WRITING GOOD REQUIREMENTS COURSE T-401-007 6

Requirements Quality Weighs Heavily on Program Cost / Success

Edit Master text styles Fourth level

Second level Fifth level
Third level
$$$
$$$
Scenario Omission
Ambiguous $$ $$$
Requirement Systems
$ $$
$ $$
Allocation Engineering &
Error
$

Requirements Software
Analysis Engineering Integration
and Test
Early Defect Correction Provides Significant Cost Avoidance
L3HARRIS WRITING GOOD REQUIREMENTS COURSE T-401-007 7
Requirements Stakeholders

• Users
• Customers
• Developers
• Engineers
• Designers
• Testers
• Managers
• Business Leaders
• Subcontractors
• Field Support Engineers
• Other interfacing systems
• …anyone involved in requirements definition, validation, development, review, verification

L3HARRIS WRITING GOOD REQUIREMENTS COURSE T-401-007 8

Requirements Importance

• Good requirements
– Are key to the development of a quality product that provides value to the customer
– Result from understanding the customer’s real needs
– Are only effective if properly specified and documented

• So why are requirements frequently poorly written?

L3HARRIS WRITING GOOD REQUIREMENTS COURSE T-401-007 9

Some Causes for Poorly Written Requirements - 1

• Lack of training or experience in requirements writing

– Misplaced assumption that everyone understands grammar and sentence structure
– A preference for bullet-point presentation over real sentences leads to incomplete communication
• Inexperience in requirements elicitation
• Insufficient resources dedicated to requirements definition, caused by:
– Underestimating systems engineering resources
– Bad comparisons to historical data (picking poor similar-to program)
– Program cost and schedule issues
– Inadequate time to SRR

L3HARRIS WRITING GOOD REQUIREMENTS COURSE T-401-007 10

Some Causes for Poorly Written Requirements - 2

• Unclear user needs

• Implicit, unrecognized assumptions
• “We know what they want”
• “Everybody knows that…”
– Code for “only I think that, so don’t fact check me”
• Confusion of the commonly understood word …
– Mistaken assumption of common understanding
– A variant of “Everybody knows that”
• Arrogance of expertise
– Refusal to explain
• Fear of exhibiting ignorance
– Reluctance to ask

L3HARRIS WRITING GOOD REQUIREMENTS COURSE T-401-007 11

Structure and Grammar

• Requirements are basically sentences, with grammar and rules

• Understanding sentence structure is important to writing quality requirements
• Use a sentence template for requirements
– INCOSE recommends developing a requirement template
– Best practice: put the requirement template in the SEMP, SDP & HWDP
• SE team should include (or call on outside help for) an expert editor

Grammar matters … Templates can help

L3HARRIS WRITING GOOD REQUIREMENTS COURSE T-401-007 12

Best Practices

• Use the standard requirements management database

• Include all necessary contextual information in the requirement
• Do not rely on paragraph structure in a specification document for context
• Use a glossary (data dictionary) of terms consistently throughout the requirements set
– Avoids the confusion of multiple names for the identical entity
• Thoroughly review and validate the meaning of each requirement
– Use peer reviews!

L3HARRIS WRITING GOOD REQUIREMENTS COURSE T-401-007 13

The Use of “Shall” for Writing Requirements

• When writing a requirement, use “shall” to declare what is mandatory

– The use of any other indicator normally implies that compliance is not mandatory
• Best Practice:
– When writing requirements …
– Always use the imperative “shall” to indicate a requirement
– Use present tense to describe non-requirement activity
– Instead of using “will” with the future tense, use the verb’s present tense
– “The facility will provide power” => “The facility provides power”
– Eliminate otherwise ambiguous verbal auxiliaries
– “Would,” “should,” “might,” “must”
– The use of “must” will be confusing in a requirements set that uses “shall” for what is mandatory
– All “shalls” must be imposed on the correct entity
NOTE:
– When evaluating customer requirements, be aware that real requirements may be expressed in undesirable terms
(should, will, must, etc.)
– Identifying requirements from source data is not the same as following rules for writing good requirements

L3HARRIS WRITING GOOD REQUIREMENTS COURSE T-401-007 14

Write Requirements Using Simple Language

• Avoid excessive wordiness and complex, obscure language

– Leads to confusion and ambiguity
– Can imply additional, unintended requirements
– Can cause contradictions with other requirements
– Can improperly change the scope of the requirement
– Can confuse the intent of the requirement
• Best practice:
– Eliminate unnecessary words in a requirement, reducing the scope to a single, actionable, testable statement without
additional implications.
• Example:
– “While the aircraft is on the ground, the targeting system shall inhibit firing of the laser to prevent inadvertent exposure of
the support crew to laser radiation.” (real requirement!)
– Can you find the problems with the verbiage? (see notes)
– “While the aircraft asserts <weight_on_wheels>, the targeting system shall inhibit the laser.”

L3HARRIS WRITING GOOD REQUIREMENTS COURSE T-401-007 15

Writing Good Requirements Training
Module 1 – Requirements Analysis & Validation

L3HARRIS WRITING GOOD REQUIREMENTS COURSE T-401-007 16

Identifying Requirements

• Analyzing customer requirements demands a different mindset than writing requirements

• Customer requirements sets are usually incomplete, sometimes inconsistent or defective
• Look beyond merely the “shall” statements
• Scour all customer (e.g., RFP) information seeking requirements
– Technical Requirements Document, CONOPS, meeting minutes, etc.
• Validate everything you learn
– Rewrite the customer requirements using good requirements practices (e.g., for system level)
– Validate your understanding with the customer, get buy-in, document all communications
– Be able to define a solid rationale for each requirement generated
• Conventional (and archaic) wisdom: “Just find the “shalls!”” is bad guidance
– Customers may not write requirements well, but they expect to get their needs met
– The better your initial requirements set represents the customer need, the lower your risk
• Caution:
– The above does not mean you should take on out of scope work
– Nor should you bid proposal costs for additional requirements that the customer does not want

L3HARRIS WRITING GOOD REQUIREMENTS COURSE T-401-007 17

Typical Requirements Sources

• Customer documentation • Stakeholders

– Legacy Specifications – Procurement Program Managers
– SOW – Users
– Request For Proposal (RFP) documents – Operators
– SOO, SOC, SOR, TRD, SRD
– Maintainers
– Compliance documents
– Trainers
• Interaction opportunities – Support providers
– User and customer meetings – External systems
– Milestone reviews
– Interfaces
– Site visits
–
– Logistics
IRAD/Prototype demonstrations
– Working groups (requirements, security, interface, test) – Provisioning
– Utilities
– Security
– Owners/Funders
– Customer Subject Matter Experts (SMEs)
– Your development and support teams

L3HARRIS WRITING GOOD REQUIREMENTS COURSE T-401-007 18

Requirements Types and Analysis Techniques

• Functional (Behavioral) Requirements • Design Constraints

– System Threads – Operations crew size and skill set
– Use Case analysis – Task analysis
– Functional decomposition – Deployment, setup and teardown timelines
– Task Analysis, Packaging trade studies
• Performance Requirements
– Size, Weight and Power (SWAP) limitations
– RF cascade analysis
– a.k.a., SWAP-C (cooling)
– Timeline analysis
– COTS/custom make buy
– RMA analysis
– Architecture trade studies
• Environmental Requirements – Operating system constraints
– Mechanical packaging analysis – Environmental or operational environment
– Thermal, shock & vibration analysis – Security controls
– Transport and storage – Cybersecurity analysis
– COTS selection and packaging analysis
• Compliance
– Safety, Human factors, EMI/EMC

Different requirements types need different analysis techniques & expertise

L3HARRIS WRITING GOOD REQUIREMENTS COURSE T-401-007 19
Compliance Documents

• Compliance documents in an RFP/Contract can include thousands of additional requirements

• Employ appropriate expert assistance early
– Safety, RMA, EMI/EMC, Human Factors, Cyber-security, Logistics, Tech Orders
– These discipline experts can quickly and cost-effectively tailor compliance documents, write the minimum requirements
needed, and produce required contract artifacts
– General SEs cannot do this as effectively and oversights will lead to problems later on
• Discipline experts can …
– Tailor the compliance documents to your program, with customer involvement
– Tailoring can remove entire sections, up to and including most of the requirements
– Identify which areas are already covered by corporate process
– In many cases corporate command media & standard practices satisfy the compliance requirements
– Provide appropriate reports and analysis for each review milestone
– Steer your design team away from trouble
– Provide analysis reports for requirements verification
– Support customer discussions to clarify intent and avoid over-interpretation

L3HARRIS WRITING GOOD REQUIREMENTS COURSE T-401-007 20

Example Compliance Documents

Doc No. Title Expert Discipline

MIL-STD-1472n DOD Design Criteria Standard – Human Engineering Human Factors
MIL-STD-882n System Safety Program Requirements System Safety
MIL-STD-461F Requirements for Electromagnetic Interference EMI/EMC/TEMPEST
Characteristics of Subsystems …
NIST 800-53, et al Risk Management Framework Cybersecurity
MIL PRF 49506 Logistics Management Information Logistics
MIL-HDBK-1791 Transportation in Military Aircraft ME design experts
And dozens more

Without experienced, expert support: thousands of requirements … a nightmare!

But the right experts handle it routinely

L3HARRIS WRITING GOOD REQUIREMENTS COURSE T-401-007 21

For Each Requirement …*

• Identify the Stakeholders

• Determine the requirement context
– Operations, Transport & Storage, Interfaces
• Validate your understanding with appropriate stakeholders
– Challenge assumptions, understand underlying rationale
– Identify and resolve inconsistencies across requirements sources (TRD, ConOps, ICDs, et al)
– Develop and document strong rationale for each requirement
• Determine other contributing factors
– Constraints, Drivers, Risks
• Determine the verification method
– And ensure that there is really a valid way to verify it
• Document the requirement
– Capture in a requirements management tool
– Update requirements traceability
• Get Stakeholder buy-in * Common sense will dictate which
requirements to focus your effort on.
L3HARRIS WRITING GOOD REQUIREMENTS COURSE T-401-007 22
Requirements Analysis Concepts
Customer’s View of the Interpretation of the
Requirements Customer Requirements
SOW System
Requirements Analysis System Level
Level
SOO Requirements
Requirements
SOC Database
Database
SRD/TRD
Other RFP (“System
(“System Spec”
Spec”
Documents or
or A-Spec)
A-Spec)
Analysis
Analysis
•• Stakeholder
Stakeholder Identification
Identification
•• ConOps
ConOps interpretation
interpretation // Threads
Threads //
Use
Use Cases
Cases // User
User Stories
Stories Design to these refined
•• Requirements
Requirements Identification
Identification
•• Disambiguation
requirements!
Disambiguation
•• Decomposition
Decomposition
•• Derivation
Derivation
•• Requirement
Requirement Context
Context
•• Validation
Validation of
of Understanding
Understanding
•• Verification
Verification Approach
Approach

L3HARRIS WRITING GOOD REQUIREMENTS COURSE T-401-007 23

Who does the requirements analysis work?

• Anyone on the team can be assigned as needed – use staff appropriately

• Set up a work flow and assign routine requirements (which is most of them) to junior staff
– Collect customer documents in the standard requirements management database’s Customer Requirements modules
– Create new “A-Spec” module and copy customer requirements down, maintaining links
– Edit for proper wording, split multiple requirements, etc.
– Organize requirements into the specification template outline
– Assign difficult or problematic requirements to discipline experts
– RF performance, mission critical timing, extreme environments
• Do not drag this out!
– Complete the routine requirements analysis early – use junior staff
– Assign experts as required to the remainder
– Have a plan for TBR and TBD completion (recommended prior to CDR)
– Hold the team accountable to due dates

The earlier and better the requirements analysis, the lower the program risk
L3HARRIS WRITING GOOD REQUIREMENTS COURSE T-401-007 24
When the customer does not provide requirements

Customer’s View of the Interpretation of the

Requirements Customer Requirements
SOW
Vague
SOO
SOC
Requirements Elicitation & Analysis
System
System Level
Level
Requirements
Requirements
Database
Database

Goals SRD/TRD
Other RFP
Documents
(“System
(“System Spec”
or
Spec”
or A-Spec)
A-Spec)

Design to these refined

requirements!

Most programs fall between Vague Goals and Good Customer Requirements
L3HARRIS WRITING GOOD REQUIREMENTS COURSE T-401-007 25
When the customer does not provide requirements

Edit Master text styles Fourth level

Second level Fifth level
Third level

L3HARRIS WRITING GOOD REQUIREMENTS COURSE T-401-007 26

Requirements Types

• A required behavior in the customer requirements set might need several system level requirements of
different types to satisfy it
• Example: “Add new addresses to the Address List”
– Satisfied by the following system level requirements:
– Functional (Behavior)
– Upon command, the system shall add new addresses to the neighborhood address list.
– Technology/standards (guidance / constraints)
– The system shall format new addresses in accordance with USPS address standards for formatting and abbreviations.
– Performance (measures)
– On completion of a new address entry by the operator, the system shall store a valid address within 200ms.

Question for the class: Are there hidden or implied additional requirements here?
L3HARRIS WRITING GOOD REQUIREMENTS COURSE T-401-007 27
Some Examples – 1

• Original requirement:
• “The system shall provide the operator the information needed to access appropriate analysis tools when a
signal is detected.”
– Specify what types of tools are available to select from
– Bound the possible number of “valid” tools – tie to a specific reference for a list of allowable selections.
– Be specific about the desired presentation format to the operator.

• Rewrite as two requirements:

• When a signal alert is received, the system shall determine the applicable signal analysis tools, as defined in
Customer Specification N1234 V123 dated 01-02-13.
• The system shall provide the operator with the determined list of applicable analysis tools for each signal
alert.

L3HARRIS WRITING GOOD REQUIREMENTS COURSE T-401-007 28

Some Examples – 2

• The system shall be able to process incoming messages at a rate of four (4) per second.
– Define or eliminate the general term “process”.
– Replace with a specific interpretation of the scope of the requirement.

• Two Requirements:
– The system shall extract external message parameters from incoming signals of type XXX defined in Customer
Document V2345 V2.2 dated dddd.
– The system shall complete parameter extraction at a rate of at least four (4) messages per second, sustained for a period
of at least 10 seconds within a 60 second interval.

Note that additional technical detail has been added in deriving the new requirements.
L3HARRIS WRITING GOOD REQUIREMENTS COURSE T-401-007 29
Some Examples – 3

• Network analysis shall be performed using a Hewlett Packard Model 8149 analyzer.
– Operational requirement, not system oriented
– The COTS device may be obsolete when you need it
– Make the COTS device a customer-directed requirement, if possible

• The system shall provide network analysis tools, including the ACME Corporation Roadrunner Model, series
Z1P*.

* If the customer insists on a specific asset for use in the delivered product, the requirement must
define a specific asset baseline to preclude changes from “creeping” into the program product
requirements. This permits negotiation of a contract change if the customer-directed equipment is
not available when needed.

L3HARRIS WRITING GOOD REQUIREMENTS COURSE T-401-007 30

Some Examples – 4

• The system shall determine the location of a target transmitter with an accuracy of 0.5 KM and be able to
classify signal emitters at a rate of about 100 per second.

– Compound requirement – split to simple requirements

– Add more control to the test environment:
– Add specifics (ground-based) to add more control to the test environment
– Add customer approved reference data (Spec N5678)

• Two Requirements:
– The system shall determine the location of a ground-based target transmitter to within less than or equal to 0.5KM of its
actual location.
– The system shall classify signal emitters against the classifications defined in Customer Specification N5678 Version VV
dated dddd at rates up to at least 100 emitter classifications per second.

L3HARRIS WRITING GOOD REQUIREMENTS COURSE T-401-007 31

Some Examples – 5

• The system shall operate for 5000 hours without failure.

– Use standard terminology (MTBF)
– Specify the test methodology where applicable
– More control to the test environment
– Customer standards

• When operated in accordance with the requirements of this specification, the system shall have a Mean Time
Between Failures (MTBF) greater than 5000 hours, in accordance with MIL-STD-XYZ, Revision NN dated
dddd.

L3HARRIS WRITING GOOD REQUIREMENTS COURSE T-401-007 32

Some Examples – 6

• Emitter Classification Accuracy shall not exceed 2 errors per 1000.

– Add specifics of definition of classifications
– Add specifics to the performance conditions
– Apply the requirements template and use appropriate subject

• Two Requirements:
– The system shall assign classifications to signals as defined in Customer Classification Guide N3333.
– The system shall classify emitters with no more than 2 errors per 1000 classification operations, averaged over a sample
of 10,000 consecutive classification operations.

Obviously, considerable SME expertise is needed to get these details correct

L3HARRIS WRITING GOOD REQUIREMENTS COURSE T-401-007 33

Some Examples – 7

• The system shall accept valid operator identification numbers from 1 to 9999.
– Use customer defined set of identification numbers
– Include version/date of document

• The system shall accept only valid operator identification numbers as defined in Operations Order 11-3 dated
10 October 2004.

L3HARRIS WRITING GOOD REQUIREMENTS COURSE T-401-007 34

REQUIREMENTS ANALYSIS TECHNIQUES

L3HARRIS
Functional Analysis

• Functional Decomposition
– Begin with the Context Diagram
– Partition the system functionality one level at a time
– Identify the highest level functions
– Requires a good understanding of all external inputs and outputs
– Generally a function will accept an external or intermediate input, transform it into an intermediate or external output
– Decompose to lower layers until sufficient detail available for allocation to the design
• Functional Composition
– Begin by identifying/defining detailed lower level functionality
– Group functions and allocate to the design
• Apply both techniques to improve results
– E.g., use Composition as a sanity check for Decomposition

Functional Composition and Functional Decomposition Alone

Are not sufficient for the complete analysis …
L3HARRIS WRITING GOOD REQUIREMENTS COURSE T-401-007 36
Functional Decomposition: Top Down Analysis

• Begin with a Context Diagram

• Partition the system functionality one layer at a time Satellite ABC
Target Waveform

Target Waveform

• Identify top level functions from the initial requirements set, CONOPS, et al
VHF Emitters

TSARS
– Functions are what the system does, not the system components that will be BCD Agency
Intel Support Data Intel Updates
BCD Agency

developed Tasking Data BDA Reports Battlefield

Commander

• Draw the top level functional block diagram Theater Prime Power
Command

– Name each function with a verb phrase and identifier (e.g., F1, F2, …) Security

– Assign a number or other identifier to each function

• For each function, decide whether to decompose
– Draw the next lower level diagram by decomposing the function into sub-functions
– Name each sub-function with a verb phrase and identifier (e.g., F11, F12, …)
• Iterate until each function is decomposed to your desired lowest level
– There is no rule for when to stop decomposing, and functions may stop at different
levels
– Typically stop when a function’s lowest level maps to a design element that can be
procured or designed and fabricated by a single project team

L3HARRIS WRITING GOOD REQUIREMENTS COURSE T-401-007 37

Use Case Analysis: What is a Use Case?

• Ultimately, every product provides some utility to a consumer: use cases can help analyze
• Use case
– Contract between a stakeholder and the system regarding system behavior
– Also viewed as a User “goal” for the system
– Coherent story regarding how the system behaves during use
– Scenario from the user’s (or client’s) Point Of View
• Use cases reveal functional requirements
– UCs give rise to lower level functional requirements
– Functional requirements are only a subset of all requirements
• With Model Based SE, Use Cases provide requirements allocation to design
• Use cases align well with other modeling methods

Ivar Jacobson (yah-cob-son) first invented “use cases” in 1967, while working for
Ericsson in Sweden. He coined the Swedish term anvendningsfall, which roughly
means “situation of usage” or “usage case” when translated into English.

L3HARRIS WRITING GOOD REQUIREMENTS COURSE T-401-007 38

Use Case Analysis of System Behavior

• Use cases describe system behaviors in response to actor Typical UC Description Template
(stakeholder) stimulus
– Primary stakeholders provide inputs to the system
– System responds – Use Case: <Name>
– Different sequences (scenarios) of behavior can take place, – Actor(s): <>
– Use case collects related scenarios
– Preconditions: <>
• A system may have a few to many use cases
– Post-conditions:<>
– Dependencies: <Other UCs>
– Includes: <other UCs>
– Description: <>
– Scenario: <Main/Sunny Day> 
– Exception/Alternate Scenarios: <Index to
Main Scenario steps>

L3HARRIS WRITING GOOD REQUIREMENTS COURSE T-401-007 39

HMI CSCI Timing Analysis Example

• A-Spec Requirement: Complete Equipment Command/Response < 2 seconds

• HMI CSCI Requirements
– HMI_52
– Upon the Operator’s command to change the configuration of a device, and unless specified below by an alternative
time period, the HMI CSCI shall [HMI_52] broadcast the request within (TBR_5) 100 milliseconds.
– HMI_222
– Upon notification that the status of a device needs updating, and unless specified below by an alternative time period,
the HMI CSCI shall [HMI_222] display the new status of the device within (TBR_8) 250 milliseconds.

A requirements allocation example:

COTS equipment constraint, COTS performance outside software control
L3HARRIS WRITING GOOD REQUIREMENTS COURSE T-401-007 40
HMI CSCI Timing Analysis Example (cont)

HMI EM H/W Device

CSCI CSCI

Equipment
Configuration 1400 ms includes the time
2 required for the COTS device to
HMI_5
Use Case
Equipment perform the change in
HMI CSCI
Configuration configuration and report the
(100 ms)
Use Case response
EM CSCI
(250 ms)

H/W Device
Equipment Performs
Status Command Allocati
Equipment
Collection o n to CO
Status
Use Case TS
22
HMI_2
EM CSCI
Display
(1400 ms)
Use Case
HMI CSCI
(250 ms)

Question: What if a COTS item requires more than the allocated response time?
L3HARRIS
Pitfall: Aggregation of Worst Cases

Edit Master text styles Fourth level

Second level Fifth level
Third level

L3HARRIS WRITING GOOD REQUIREMENTS COURSE T-401-007 42

Pitfall: Over-specification and over-design

• During proposal
– Can lead to high cost and potential loss
– Challenge all proposal assumptions that increase cost of the design
• During program execution
– Can lead to cost and schedule overruns and increased life cycle costs
• Over-specifying performance
– Specifying requirements to match a preferred design rather than based on actual system need
– Writing VIDs to match a vendor spec sheet rather than the system need
– Don’t artificially increase requirements just because the design provides higher performance
• Holding too much margin
– “Everybody wants to hold a dB” – competing for margin leads to over-design
– Margin should be held and distributed from the system level
• Customers may over-specify requirements without realizing it
– Validate requirements, and try to understand the underlying rationale
– Challenge any seemingly invalid or excessive requirements

L3HARRIS WRITING GOOD REQUIREMENTS COURSE T-401-007 43

MODULE 1 SUMMARY

L3HARRIS
Requirements Do’s

• Quickly establish requirements database/tool and requirements management process

– Organizes the work and gives your team a structure to work in
• Validate all assumptions and changes with appropriate stakeholders
– Customer and internal stakeholders (developers, test, QA, cybersecurity, supply chain)
• Ensure all terminology is acceptable to and understood by appropriate stakeholders – especially the
definitions of requirements indicators
• Ensure all requirements are traceable to the system/customer requirements
• Ensure top level requirements are satisfied at appropriate level (downward traceability)
• Keep the requirements implementation-free
– Specify what shall be done, not how it is done
• Ensure interpretations of requirements are validated at all levels of development
• Ensure that each requirement is verifiable

L3HARRIS WRITING GOOD REQUIREMENTS COURSE T-401-007 45

Requirements Don’ts

• Don’t dally: get the more routine 80% - 90% of requirements work done quickly
– Focus key resources on requirements that need them
– Plan and work off TBx requirements
• Don’t combine requirements using words like: “and,” “or,” “also,” “with,” et al
• Avoid using “etc.,” which opens the way for interpretation
• Avoid terms that invoke possibilities: may, might, could, should, perhaps, and probably.
• Don’t use words that provide escape clauses
– except, if, when, unless, but, et al
• Avoid vague or undefined terms
– To the greatest extent possible, maximum, minimum, state-of-the-art, flexible, user friendly, efficient, several, improved,
adaptable, adequate, simple, et al
• Don’t introduce artificial constraints

L3HARRIS WRITING GOOD REQUIREMENTS COURSE T-401-007 46

Writing Good Requirements Training
Module 2 – Good Requirements Characteristics

L3HARRIS WRITING GOOD REQUIREMENTS COURSE T-401-007 47

EXERCISE 1 – IDENTIFYING REQUIREMENTS

L3HARRIS
STRUCTURE OF REQUIREMENTS STATEMENTS

L3HARRIS
Form of the Requirement Statement

verb auxiliary

[ condition ] [ subject ] shall [ [ qualifier ] action ] [ [ qualifier ] object ]

mode, state, event, action / verb phrase

system, product,
precondition subsystem, etc.

• Multiple conditions can exist

• Condition can optionally be placed at the end (or elsewhere)
• Qualifiers can come before or after the action or object
• Subject is the entity name for the requirements set

L3HARRIS WRITING GOOD REQUIREMENTS COURSE T-401-007 50

Example 1 – No Condition; Always Applies

[ condition ] [ subject ] shall [ [ qualifier ] action ] [ [ qualifier ] object ]

The control system shall prevent engine over-speed.

L3HARRIS WRITING GOOD REQUIREMENTS COURSE T-401-007 51

Example 2 – Unwanted Condition or State (System Level)

[ condition ] [ subject ] shall [ [ qualifier ] action ] [ [ qualifier ] object ]

When an over-temperature condition exists the System shall display

an alarm to the operator.

Written appropriate for the system level

L3HARRIS WRITING GOOD REQUIREMENTS COURSE T-401-007 52

Why Does the Condition Come First?

A poorly written requirement:

“To defuse the bomb, the ordnance disposal

engineer shall cut the red wire, after the green and
white striped wire was cut.”
Unknown English Sketch Comedy

Use careful consideration when choosing where to locate the condition phase
L3HARRIS WRITING GOOD REQUIREMENTS COURSE T-401-007 53
Example 2 – Unwanted Condition or State (Subsystem Level)

[ condition ] [ subject ] shall [ [ qualifier ] action ] [ [ qualifier ] object ]

When an over-temperature condition exists the control system shall send,

within 0.1 second, an over-temperature alarm message to the operator
interface.

Written appropriate for the control system level

L3HARRIS WRITING GOOD REQUIREMENTS COURSE T-401-007 54

Example 3 – Multiple Conditions, Compound Action

[ condition ] [ subject ] shall [ [ qualifier ] action ] [ [ qualifier ] object ]

While in control mode, upon the clock reaching 12 midnight,

the traffic system shall transition to RYRY state and switch to flash mode.

Example of an apparently compound requirement that should not be split …

Tightly coupled actions that must be verified together

L3HARRIS WRITING GOOD REQUIREMENTS COURSE T-401-007 55

Example 4 – Design Constraint

[ condition ] [ subject ] shall [ [ qualifier ] action ] [ [ qualifier ] object ]

The System shall include two GFE 4.9 meter parabolic reflector antennas.

This is implementation, and therefore not desirable, but if mandated by the customer, then it
becomes a requirement on the contract.
L3HARRIS WRITING GOOD REQUIREMENTS COURSE T-401-007 56
Example 5 - Environmental

[ condition ] [ subject ] shall [ [ qualifier ] action ] [ [ qualifier ] object ]

While exposed to the operational environment of Table 10, the System shall
meet the performance requirements of this specification.

Also commonly written with the condition at the end

L3HARRIS WRITING GOOD REQUIREMENTS COURSE T-401-007 57
EXERCISE 2 – REQUIREMENTS STATEMENT STRUCTURE

L3HARRIS
CHARACTERISTICS OF GOOD REQUIREMENTS

Reference for this section: Guide For Writing Requirements – INCOSE-TP-2010-006-02

L3HARRIS
Some Characteristics of Bad Requirements

• Not Verifiable – can’t be tested

• Erroneous – based on incorrect data or assumptions
• Implementation – specifying implementation (how) instead of requirements (what)
• Operations - describing operational use instead of specifying requirements
• Terminology – using inconsistent and not-agreed-to terms
• Omission – missed requirements
• Excessive – over-specifying requirements
• Ambiguous – using unclear terms
– …shall not… (untestable, avoid usage)
– …shall minimize (maximize, optimize)…
– …shall provide sufficient (adequate)…
– …shall be user-friendly…
• Artificial – unnecessary or unwanted constraints introduced in requirements wording

L3HARRIS WRITING GOOD REQUIREMENTS COURSE T-401-007 60

Weasel Words – to be Avoided

• Example weasel words

– “...shall support...”
– “...shall be able to perform...”
– “...shall be capable of...”
– “...shall provide the capability...”
– “...shall provide the functions necessary to perform...”
– “...shall meet specified performance...”
• Such language indicates inadequate requirements analysis

Weasel words have no place in good requirements writing

L3HARRIS WRITING GOOD REQUIREMENTS COURSE T-401-007 61

INCOSE Characteristics of Good Requirements

• For requirements statements • For requirements sets / specs

• Necessary (C1)1 • Complete (C10)
• Appropriate (C2) • Consistent (C11)
• Unambiguous (C3) • Feasible (C11)
• Complete (C4) • Comprehensible (C13)
• Singular (C5) • Able to be Validated (C14)
• Feasible (C6)
• Verifiable (C7)
• Correct (C8)
• Conforming (C9)
• In-Scope (L3Harris)
• No Implementation (L3Harris)

1 Bold characteristics to be discussed in more detail

L3HARRIS WRITING GOOD REQUIREMENTS COURSE T-401-007 62

INCOSE Characteristics of Good Requirements

• For requirements statements • Defines an essential capability, characteristic, constraint,

or quality factor
• Necessary (C1)
• If removed, the developed entity would be deficient in
• Appropriate (C2)
capability
• Unambiguous (C3)
• Flows down from (is traceable to) a higher level
• Complete (C4) requirement
• Singular (C5)
• Feasible (C6) • Guidance: If the author cannot explain the need for a
• Verifiable (C7) requirement, it may not be Necessary

• Correct (C8)
• Rules:
• Conforming (C9)
• Express each requirement only once
• In-Scope (L3Harris)
• Avoid implementation in the requirement – focus on what,
• No Implementation (L3Harris)
not how

L3HARRIS WRITING GOOD REQUIREMENTS COURSE T-401-007 63

INCOSE Characteristics of Good Requirements

• For requirements statements • Necessary, or Not Necessary?

– On completion of boot up, the system shall display the login
• Necessary (C1)
screen to the operator.
• Appropriate (C2) – The operator shall log in to the system when directed by the shift
supervisor.
• Unambiguous (C3)
• Complete (C4)
• Singular (C5)
• Feasible (C6)
• Verifiable (C7)
• Correct (C8)
• Conforming (C9)
• In-Scope (L3Harris)
• No Implementation (L3Harris)

L3HARRIS WRITING GOOD REQUIREMENTS COURSE T-401-007 64

INCOSE Characteristics of Good Requirements

• For requirements statements • Level of detail and content appropriate to the level of the
entity addressed
• Necessary (C1)
• System level – less detail; more focused on external actors
• Appropriate (C2)
– “The system shall provide an operator alert.”
• Unambiguous (C3)
• Subsystem level – more detail; more internally focused
• Complete (C4) – “The control subsystem shall send an over-temperature
message to the operator interface.”
• Singular (C5)
• Feasible (C6)
• Verifiable (C7) • Rules:
– Address requirement to the appropriate entity
• Correct (C8) – Express requirement at the appropriate level of detail
• Conforming (C9)
• In-Scope (L3Harris)
• No Implementation (L3Harris)

L3HARRIS WRITING GOOD REQUIREMENTS COURSE T-401-007 65

INCOSE Characteristics of Good Requirements

• For requirements statements • Appropriate for the system level?

• Necessary (C1) • When the customer presents valid primary identification,
the ATM shall request secondary identification.
• Appropriate (C2)
• The ATM shall stack cash face up, sorted by denomination.
• Unambiguous (C3)
• The ATM bill stacker shall operate using 24VDC provided
• Complete (C4)
by the main power supply.
• Singular (C5) – Written as a bill stacker requirement, not an ATM system
requirement
• Feasible (C6)
• Verifiable (C7)
• Correct (C8)
• Conforming (C9)
• In-Scope (L3Harris)
• No Implementation (L3Harris)

L3HARRIS WRITING GOOD REQUIREMENTS COURSE T-401-007 66

INCOSE Characteristics of Good Requirements

• For requirements statements • Requirement can only be interpreted in one way

• Necessary (C1) • Guidance:
– Use correct grammar, spelling, punctuation
• Appropriate (C2)
– Use defined terms and acronyms
• Unambiguous (C3) – Use definite articles
• Complete (C4) – Uniformly use agreed language forms
– Avoid adjectives, adverbs and pronouns
• Singular (C5) – Write active voice, single thought sentences
• Feasible (C6) – Express conditions, performance, or constraints in separate sub-
clauses
• Verifiable (C7) – Use tables and figures to clarify text
• Correct (C8) – Use additional sentences (without “shall”) to provide definitions,
clarifications
• Conforming (C9)
• In-Scope (L3Harris)
• No Implementation (L3Harris)

L3HARRIS WRITING GOOD REQUIREMENTS COURSE T-401-007 67

INCOSE Characteristics of Good Requirements

• For requirements statements • Are the following Unambiguous?

• Necessary (C1) • 1. The heater shall be turned on when the boiler
temperature is 2 degrees below the established level.
• Appropriate (C2)
• 2. The control system shall read the temperature set point
• Unambiguous (C3)
from the operator.
• Complete (C4)
• 3. The antenna shall fit easily in the C130 cargo bay.
• Singular (C5)
• 4. On completion of the tranasction, the ATM shall
• Feasible (C6) dispence a receipt to the customer.
• Verifiable (C7) • 5. When the boiler temperature is equal or less than
• Correct SET_POINT_TEMPERATURE minus one degree
(C8)
fahrenheit, the control system shall turn on the heater.
• Conforming (C9) – How could parentheses be used to reduce ambiguity for this
example?
• In-Scope (L3Harris)
• No Implementation (L3Harris)

L3HARRIS WRITING GOOD REQUIREMENTS COURSE T-401-007 68

INCOSE Characteristics of Good Requirements

• For requirements statements • Understandable without the need for other information
• Necessary (C1) • Understandable in its own right without having to
understand a number of others
• Appropriate (C2)
• Guidance:
• Unambiguous (C3)
• Assumes an informed reader
• Complete (C4)
– Understands the program context at the level the requirement
• Singular (C5) is written
• Feasible (C6) • Ok to refer to specific sections of external documents
(ICDs, compliance documents) that are part of the contract
• Verifiable (C7)
• Use additional sentences, tables or graphics to help
• Correct (C8)
ensure complete understanding
• Conforming (C9)
• In-Scope (L3Harris)
• No Implementation (L3Harris)

L3HARRIS WRITING GOOD REQUIREMENTS COURSE T-401-007 69

INCOSE Characteristics of Good Requirements

• For requirements statements • Are the following Complete? If not, what information is
lacking?
• Necessary (C1)
• Appropriate (C2)
• 1. The mounting bracket shall be 6.7” wide.
• Unambiguous (C3)
• 2. The traffic simulation shall model traffic intersection red
• Complete (C4)
and green lights.
• Singular (C5)
• 3. The computer system shall communicate via the local
• Feasible (C6) Ethernet LAN.
• Verifiable (C7) • 4. The system shall operate from a 120VAC power supply.
• Correct (C8)
• Conforming (C9)
• In-Scope (L3Harris)
• No Implementation (L3Harris)

L3HARRIS WRITING GOOD REQUIREMENTS COURSE T-401-007 70

INCOSE Characteristics of Good Requirements

• For requirements statements • States a single capability, characteristic, constraint, or

quality factor
• Necessary (C1)
• Appropriate (C2)
• Guidance:
• Unambiguous (C3)
• Conjunctions (and, or) tying multiple phrases together may
• Complete (C4)
indicate a nonsingular requirement
• Singular (C5)
• Although a requirement is itself singular, multiple
• Feasible (C6) conditions may exist
• Verifiable (C7) • A singular requirement may properly include a compound
• Correct (C8) action
– When the surface temperature is equal or greater than
• Conforming (C9) MAX_TEMP, the controller shall remove power to the heating
element and set the over-temperature alert signal.
• In-Scope (L3Harris)
• No Implementation (L3Harris)

L3HARRIS WRITING GOOD REQUIREMENTS COURSE T-401-007 71

INCOSE Characteristics of Good Requirements

• For requirements statements • Are the following Singular? If not, restate them as singular
requirements
• Necessary (C1)
• Appropriate (C2)
• 1. The traffic simulation shall model and analyze vehicle
• Unambiguous (C3)
behavior at intersections, on-ramps, off-ramps and lane
• Complete (C4) closures.
• Singular (C5) • 2. The targeting system shall designate and range targets
• Feasible (C6) up to 10km distant.

• Verifiable (C7) • 3. The targeting system shall acquire, at 10 km or less,

targets meeting characteristics in Appendix IV of this
• Correct (C8) specification.
• Conforming (C9) • 4. While in control mode, upon the clock reaching 12
• In-Scope (L3Harris) midnight, the traffic system shall transition to RYRY state
and switch to flash mode.
• No Implementation (L3Harris)

L3HARRIS WRITING GOOD REQUIREMENTS COURSE T-401-007 72

INCOSE Characteristics of Good Requirements

• For requirements statements • Realizable with acceptable risk, within the applicable cost,
schedule, technical and other contractual constraints
• Necessary (C1)
• Appropriate (C2)
• Guidance:
• Unambiguous (C3)
• Seemingly non-feasible requirements may be the result of
• Complete (C4)
misinterpretation and miscommunication – validation can
• Singular (C5) help
• Feasible (C6) • Validate unrealistic requirements with the customer;
• Verifiable (C7) attempt to get them revised

• Correct • Failing to achieve revision through the validation process,

(C8)
apply the risk process
• Conforming (C9)
• In-Scope (L3Harris)
• No Implementation (L3Harris)

L3HARRIS WRITING GOOD REQUIREMENTS COURSE T-401-007 73

INCOSE Characteristics of Good Requirements

• For requirements statements • Are the following Feasible? Discuss each

• Necessary (C1) • 1. The system shall decode all received messages
accurately.
• Appropriate (C2)
• 2. The system shall launch pigeon carcasses at the speed
• Unambiguous (C3)
of light.
• Complete (C4)
• 3. The system shall permanently retain all downlinked
• Singular (C5) imagery data.
• Feasible (C6) • 4. System operational availability shall be 0.995.
• Verifiable (C7) • 5. The system shall respond instantly to over-temperature
• Correct (C8) alerts.

• Conforming (C9)
• In-Scope (L3Harris)
• No Implementation (L3Harris)

L3HARRIS WRITING GOOD REQUIREMENTS COURSE T-401-007 74

INCOSE Characteristics of Good Requirements

• For requirements statements • Can verify that the completed entity satisfies the
requirement by one of the accepted methods: Inspection,
• Necessary (C1)
Analysis, Demonstration, Test
• Appropriate (C2)
• Unambiguous (C3)
• Guidance:
• Complete (C4)
• To be verifiable, requirement must be measurable
• Singular (C5)
• Common problems to watch for:
• Feasible (C6) – Unclear spec of behavior, conditions, states
• Verifiable (C7) – Imprecise ranges of acceptable performance
– Ambiguous terms used
• Correct (C8) – Not feasible
• Conforming (C9) • Be sure that the requirement actually states what you want
• In-Scope (L3Harris) to be verified
• No Implementation (L3Harris)

L3HARRIS WRITING GOOD REQUIREMENTS COURSE T-401-007 75

INCOSE Characteristics of Good Requirements

• For requirements statements • Are the following Verifiable? Discuss each

• Necessary (C1)
• Appropriate (C2) • 1. The system shall respond to a target detection as OUT-
Of-RANGE for all ranges beyond 10km.
• Unambiguous (C3)
• 2. The system shall ignore all targets with detection
• Complete (C4)
parameters outside the selected parameters.
• Singular (C5)
• 3. When a target is detected, if the target has detection
• Feasible (C6) parameters not matching the currently selected filter, the
• Verifiable (C7) system shall flag the target as NO-TRACK.

• Correct • 4. The system shall not track commercial aircraft.

(C8)
• Conforming (C9)
• In-Scope (L3Harris)
• No Implementation (L3Harris)

L3HARRIS WRITING GOOD REQUIREMENTS COURSE T-401-007 76

INCOSE Characteristics of Good Requirements

• For requirements statements • Requirement statement accurately represents the true

need
• Necessary (C1)
• Appropriate (C2)
• Guidance:
• Unambiguous (C3)
• Validate with the customer / stakeholders
• Complete (C4)
– Statement is based on the correct interpretation of the parent
• Singular (C5) requirement
– Decomposition or derivation used to arrive at the requirement
• Feasible (C6)
correctly applies the appropriate analysis and assumptions
• Verifiable (C7)
• Correct (C8)
• Conforming (C9)
• In-Scope (L3Harris)
• No Implementation (L3Harris)

L3HARRIS WRITING GOOD REQUIREMENTS COURSE T-401-007 77

INCOSE Characteristics of Good Requirements

• For requirements statements • Are the following correct? Discuss each

• Necessary (C1)
• Appropriate (C2) • 1. The computer shall connect to the local 1Mb Ethernet
LAN. (do they even make these anymore?)
• Unambiguous (C3)
• Complete (C4)
• 2. The computer shall connect to the local
• Singular (C5)
10/100/1000BaseT Ethernet network.
• Feasible (C6)
• Verifiable (C7)
• Correct (C8)
• Conforming (C9)
• In-Scope (L3Harris)
• No Implementation (L3Harris)

L3HARRIS WRITING GOOD REQUIREMENTS COURSE T-401-007 78

INCOSE Characteristics of Good Requirements

• For requirements statements • Requirement statement correctly applies the approved

template and style
• Necessary (C1)
• Note: this is a recent practice and many programs have
• Appropriate (C2)
not followed it to date.
• Unambiguous (C3)
• Guidance:
• Complete (C4)
• Programs and organizations should develop a standard
• Singular (C5) template and style guide for writing requirements
• Feasible (C6) • Peer review all requirements and sets of requirements
• Verifiable (C7) • A checklist for the characteristics in this training would be
• Correct (C8) useful

• Conforming • Customer processes and templates take precedence (but

(C9)
you can negotiate tailoring or adoption of contractor
• In-Scope (L3Harris) format)
• No Implementation (L3Harris)

L3HARRIS WRITING GOOD REQUIREMENTS COURSE T-401-007 79

INCOSE Characteristics of Good Requirements

• For requirements statements • Discuss whether the following meet the Conforming
characteristic
• Necessary (C1)
• Appropriate (C2)
• 1. The system will be transported in C-130 or C-17 aircraft.
• Unambiguous (C3)
• 2. The system shall be capable of detecting target signals
• Complete (C4)
in the frequency range 1.0MHz to 5.0MHz.
• Singular (C5)
• 3. The system s.b.c.o. storage at temperatures from -25
• Feasible (C6) degrees to +125 degrees Fahrenheit.
• Verifiable (C7) • 4. The system shall meet the performance requirements of
• Correct this specification after storage, while properly packed, at
(C8)
temperatures from -25 degrees to +125 degrees
• Conforming (C9) Fahrenheit.
• In-Scope (L3Harris)
• No Implementation (L3Harris)

L3HARRIS WRITING GOOD REQUIREMENTS COURSE T-401-007 80

INCOSE Characteristics of Good Requirements

• For requirements statements • Requirement is within the bounds of the contract

• Necessary (C1)
• Appropriate (C2) • Guidance:
• Unambiguous (C3) • Requirements should not be allowed into the requirements
set unless they are within contractual scope.
• Complete (C4)
• Requirements creep is a common cause of requirements
• Singular (C5)
overrun
• Feasible (C6)
• Things to watch for:
• Verifiable (C7) – “Nice to have”
• Correct – “Hooks” for future capabilities
(C8)
– Customer “desirements”
• Conforming (C9) – Over-specification at lower levels by enthusiastic designers
• In-Scope (L3Harris)
• No Implementation (L3Harris)

L3HARRIS WRITING GOOD REQUIREMENTS COURSE T-401-007 81

INCOSE Characteristics of Good Requirements

• For requirements statements • In-scope or Out-of-scope. Discuss each

• Necessary (C1) • 1. The system shall load onto a C-130 aircraft in 30
minutes.
• Appropriate (C2)
• 2. The operator shall be skill level 5.
• Unambiguous (C3)
• 3. The NSOF facility shall provide electrical power to the
• Complete (C4)
GOES-R Ground System according to the interfaces
• Singular (C5) described in Appendix C. (facility is GFE)
• Feasible (C6) • 4. The GOES-R system shall accept power from the NSOF
• Verifiable (C7) facility according to the interfaces described in Appendix C.

• Correct (C8)
• Conforming (C9)
• In-Scope (L3Harris)
• No Implementation (L3Harris)

L3HARRIS WRITING GOOD REQUIREMENTS COURSE T-401-007 82

INCOSE Characteristics of Good Requirements

• For requirements statements • Requirement statement should not constrain the developer
by specifying implementation details
• Necessary (C1)
• Appropriate (C2)
• Guidance:
• Unambiguous (C3)
• Requirement statement should focus on the “what” is
• Complete (C4)
needed, not on the “how” it is satisfied
• Singular (C5)
• BUT - If the customer mandates a particular
• Feasible (C6) implementation detail, then that is a real requirement
• Verifiable (C7) – Validate that this is actually the customer need
– Test whether other implementations also suffice; if so, negotiate
• Correct (C8) a revision
• Conforming (C9) • Product families may necessitate implementation
• In-Scope (L3Harris) requirements

• No Implementation (L3Harris)

L3HARRIS WRITING GOOD REQUIREMENTS COURSE T-401-007 83

INCOSE Characteristics of Good Requirements

• For requirements statements • Discuss the following

• Necessary (C1)
• Appropriate (C2) • 1. The system GPS receiver shall provide accurate time
and date.
• Unambiguous (C3)
• 2. The system shall include two 24VDC power supplies.
• Complete (C4)
• 3. The system shall operate from an external 220 VAC
• Singular (C5)
power source in accordance with <ICD> paragraph
• Feasible (C6) 3.1.2.6.4.
• Verifiable (C7) • 4. The system shall have an uninterruptible power supply.
• Correct (C8) • 5. On loss of external AC power, the system shall ensure
• Conforming (C9) no loss of critical data.

• In-Scope (L3Harris)
• No Implementation (L3Harris)

L3HARRIS WRITING GOOD REQUIREMENTS COURSE T-401-007 84

EXERCISE 3 – CHARACTERISTICS OF GOOD REQUIREMENTS

L3HARRIS
INCOSE Characteristics of Good Requirements Sets

• For requirements sets / specs • Sufficiently describes the necessary capabilities,

characteristics, constraints, and/or quality factors to meet
• Complete (C10)
the entity needs without needing other information
• Consistent (C11)
• Guidance:
• Feasible (C11)
• Goal is to fully communicate the stakeholder needs using
• Comprehensible (C13) the minimum set of requirements
• Able to be Validated (C14) • Represents a complete definition of the stakeholder
expectations, both explicitly stated as needs and the
implicit expectations not documented
– Implicit needs often reflected in derived requirements
• TBD, TBR and TBS requirements fully resolved

L3HARRIS WRITING GOOD REQUIREMENTS COURSE T-401-007 86

INCOSE Characteristics of Good Requirements Sets

• For requirements sets / specs • Set contains unique, non-conflicting, non-overlapping

requirements, written with consistent language and using
• Complete (C10)
consistent units and measurement systems
• Consistent (C11)
• Feasible (C11)
• Guidance:
• Comprehensible (C13)
• Beware of conflicting stakeholder needs that lead to
• Able to be Validated (C14) requirements inconsistencies
• Using a glossary of terms helps ensure consistency
• Ensure consistency of interface requirements among
participating elements

L3HARRIS WRITING GOOD REQUIREMENTS COURSE T-401-007 87

INCOSE Characteristics of Good Requirements Sets

• For requirements sets / specs • Requirements set is realizable within cost, schedule,
technical and other contractual constraints
• Complete (C10)
• Consistent (C11)
• Guidance:
• Feasible (C11)
• A group of individually feasible requirements may not be
• Comprehensible (C13)
feasible in aggregate as a set
• Able to be Validated (C14)
• Example: An antenna is required to track Geosynchronous
orbits, deploy mounted on the back of a HMMVW and
using its power, and deliver 80dBW EIRP at Ku-band.
Individually, each is feasible, but the set probably is not.

L3HARRIS WRITING GOOD REQUIREMENTS COURSE T-401-007 88

INCOSE Characteristics of Good Requirements Sets

• For requirements sets / specs • As a set, it is clear as to what is expected of the entity and
its relation to the system of which it is a part
• Complete (C10)
• Consistent (C11)
• Guidance:
• Feasible (C11)
• Provide sufficient context in the requirements set for the
• Comprehensible (C13)
overall understanding of the stakeholder audience
• Able to be Validated (C14)
• Organize and catalog the requirements set using a logical
and orderly method.
• Provide rationale in requirements attributes
• Include interface requirements and sufficiently detailed ICD
references

L3HARRIS WRITING GOOD REQUIREMENTS COURSE T-401-007 89

INCOSE Characteristics of Good Requirements Sets

• For requirements sets / specs • Can be proved that the entity developed to meet this set of
requirements will satisfy the true needs
• Complete (C10)
• Consistent (C11)
• Guidance:
• Feasible (C11)
• Must be able to validate both individual requirements and
• Comprehensible (C13)
also the full set
• Able to be Validated (C14)
• Vet the requirements set against test cases that exercise
the system in day in the life scenarios
• Validation must include all requirements, including non-
functional as well as functional
• Ask: “Are we building the right system?”

L3HARRIS WRITING GOOD REQUIREMENTS COURSE T-401-007 90

Validating Requirements

• Requirements exist in a specification for a reason

– Establish valid reasons for the existence of each requirement
• Good Examples of Validation
– Decomposition of parent
– Refinement of parent
– Disambiguation of parent
– Derived through analysis
– Standards compliance
– Adopted as best practice
– Dictated by company standards
• Failed validation
– Copied from parent
– Reworded from parent (with no added value)
– Out of scope

L3HARRIS WRITING GOOD REQUIREMENTS COURSE T-401-007 91

Guidelines

• Use the requirements template

• Include all applicable context in the requirements text
• Eliminate verbiage (excessive wordiness)
• Use “shall” to indicate a requirement unless told otherwise
• Check requirements against the quality attributes
• Validate the requirement before including it in a spec
• Use the Oxford comma
– The System comprises the Management, Comms, Processing, and Fusion Subsystems.
– Not: The System comprises the Management, Comms, Processing and Fusion Subsystems
• INCOSE Rules
– INCOSE has 44 rules (R1-R44) for writing requirements
– Many involve compliance with the above characteristics of good requirements

Requirement statements (and specifications) are not great literature!

Keep them precisely on target to their purpose.
L3HARRIS WRITING GOOD REQUIREMENTS COURSE T-401-007 92
SUMMARY / TAKE AWAYS

L3HARRIS
Takeaway: Requirements Do’s

• Validate all assumptions and changes with appropriate stakeholders

• Agree on the application of requirements indicators (“shall”)
• Ensure all terminology is acceptable to and understood by appropriate stakeholders
• Ensure all requirements are traceable to the customer requirements
• Keep the requirements implementation-free
– Specify what shall be done, not how it is done
• Ensure interpretations of requirements are validated at all levels of development
• Ensure that each requirement is verifiable
• Document the requirements baseline in the Requirements Management tool

L3HARRIS WRITING GOOD REQUIREMENTS COURSE T-401-007 94

 Takeaway: Requirements Don’ts

• Don’t combine requirements using words like: “and,” “or,” “also,” “with,” et al
• Don’t use “etc.,” which opens the way for interpretation
• Don’t use terms that invoke uncertainty or confusion
– may, might, could, should, perhaps, and probably
• Don’t use words that provide escape clauses
– except, if, when, unless, but, et al
• Don’t use vague or undefined terms
– to the greatest extent possible, maximum, minimum, state-of-the-art, flexible, user friendly, efficient, several, improved,
adaptable, adequate, simple, et al
• Don’t introduce artificial constraints
• Don’t introduce unnecessary performance enhancements in the requirements

L3HARRIS WRITING GOOD REQUIREMENTS COURSE T-401-007 95

References

• http://www.jot.fm/issues/issue_2003_07/column7/
• http://www.processimpact.com/articles/qualreqs.html
• http://www.dau.mil/pubscats/pubscats/atl/2005_09_10/turk_so05.pdf
• http://www.reqexperts.com//wp-content/uploads/2015/07/RequirementsExperts_RiskChecklist.pdf
• IEEE Std 1220-2005 Standard for Application and Management of the Systems Engineering Process
• http://www.reqexperts.com//wp-content/uploads/2015/07/RequirementsExperts_RiskChecklist.pdf
• ISO/IEC/IEEEE 15288:2015
• ISO/IEC/IEEE 29148– Software and systems engineering – Life cycle processes – Requirements engineering

L3HARRIS WRITING GOOD REQUIREMENTS COURSE T-401-007 96

APPENDIX. INCOSE RULES FOR WRITING REQUIREMENTS
• REFERENCE - GUIDE FOR WRITING REQUIREMENTS – INCOSE-TP-2010-006-02

L3HARRIS
INCOSE Rules for Writing Good Requirements

• Precision • Concision
– R1 – Use definite articles: “the” not ”a” – R11 – avoid superfluous infinitives (“be able to,” “be capable
– R2 – Use the active voice with the actor clearly identified of”)
– R3 – write at the appropriate layer (system, subsystem, CI) – R12 – use a separate clause for each condition and
– R4 – use only terms defined in the glossary qualification
– R5 – quantify requirements precisely • Non-ambiguity
– R6 – use appropriate units, with tolerances – R13 – Use correct grammar.
– R7 – avoid the use of adverbs – R14 – Use correct spelling.
– R8 – avoid vague terms (relevant, ancillary) – R15 – Use correct punctuation.
– R9 – avoid escape clauses (“so far as possible”) – R16 – Use the logical construct “X AND Y” instead of “both X
– R10 – avoid open ended clauses (etc., including but not limited to) AND Y.”
– R17 – Avoid the use of “X and/or Y.”
– R18 – Avoid the use of “/” except in units

L3HARRIS WRITING GOOD REQUIREMENTS COURSE T-401-007 98

Rules for Writing Good Requirements

• Singularity • Completeness
– R19 – Write a single, simple, single-thought, affirmative, – R26 – Avoid the use of pronouns.
declarative sentence, conditioned and qualified by relevant sub- – R27 – Avoid using headings to support explanation of
clauses. subordinate requirements.
– R20 – Avoid combinators such as “and,” “or,” “then,” “unless,”
“but,” “/,” “as well as,” “but also,” “however,” “whether,”
“meanwhile,” “whereas,” “on the other hand” and “otherwise.”
– R21 – Use an agreed typographical device to indicate the use of
propositional combinators for expressing a logical condition
within a requirement.
– R22 – Avoid phrases that indicate the purpose of the
requirement.
– R23 – Avoid parentheses and brackets containing subordinate
text.
– R24 – Enumerate sets of entities as explicit requirements
instead of using generalizations.
– R25 – When a requirement is related to complex behavior, refer
to the supporting diagram or model rather than a complex textual
description

L3HARRIS WRITING GOOD REQUIREMENTS COURSE T-401-007 99

Rules for Writing Good Requirements

• Realism • Abstraction
– R28 – Avoid using unachievable absolutes such as 100% – R33 – Avoid stating a solution – focus on the problem “what”
reliability or 100% availability. rather than the solution “how.”
• Conditions • Quantifiers
– R29 – State applicability conditions explicitly instead of leaving – R34 – Use “each” instead of “all,” “any” or “both” when universal
applicability to be inferred from the context. quantification is intended
– R30 – Express the propositional nature of a condition explicitly – R35 – Define the range of acceptable values associated with
instead of giving lists of conditions. quantities.
– R36 – Provide specific measurable performance targets.
• Uniqueness
– R37 – Define temporal dependencies explicitly instead of using
– R31 – Classify the requirement according to the aspects of the
indefinite temporal keywords.
problem or system it addresses.
– R32 – Express each requirement once and only once.

L3HARRIS WRITING GOOD REQUIREMENTS COURSE T-401-007 100

Rules for Writing Good Requirements

• Uniformity of Language
– R38 – Define a consistent set of terms to be used in requirement
statements in a glossary – avoid the use of synonyms.
– R39 – If acronyms are used in requirement statements, use a
consistent set of acronyms.
– R40 – Avoid the use of abbreviations in requirement statements.
– R41 – Use a project-wide style guide.
• Modularity
– R42 – Group mutually dependent requirements together.
– R43 – Group related requirements together.
– R44 – Conform to a defined structure or template.

L3HARRIS WRITING GOOD REQUIREMENTS COURSE T-401-007 101