Tutorial:
Requirements Specification Elaboration
Bruno Soares Gonçalves
Instituto de Plasmas e Fusão Nuclear
Instituto Superior Técnico
Lisbon, Portugal
http://www.ipfn.ist.utl.pt
B. Gonçalves | Lisboa , January 11, 2010 | IST
Technical requirements specification
purpose and description
The technical requirements specification is a document
through which a customer expresses his needs (or those
that he is responsible for expressing) and the related
environment and constraints in terms of technical
requirements allowing for potential suppliers to propose
the best technical and programmatic solutions.
The requirements documents organize and communicate
requirements to the customer and other stakeholders and the
technical community.
The intention of the technical requirements specification
is not to assume or refer to specific solutions
2
| Place, Month
2007 || Event
B. Gonçalves |Author’s
Lisboaname
, January
11, xx,
2010
IST
Why focus on requirements?
The hardest single part of building a system is
deciding what to build...
No other part of the work so cripples the
resulting system if done wrong. No other
part is more difficult to rectify later.
Adapted from Brooks, Fredrick P., Jar. “No Silver Bullet: Essence and
Accidents of Software Engineering”. IEEE Computer, 10-19, April 1987
3
| Place, Month
2007 || Event
B. Gonçalves |Author’s
Lisboaname
, January
11, xx,
2010
IST
Technical Requirements
Definition Process
Technical Requirements Definition Process transforms the stakeholder
expectations into a definition of the problem and then into a
complete set of validated technical requirements expressed as
“shall” statements that can be used for defining a design solution for
the Product Breakdown Structure (PBS) model and related enabling
products.
The TS is the technical reference for the qualification of
the design and for the acceptance of the end product.
4
| Place, Month
2007 || Event
B. Gonçalves |Author’s
Lisboaname
, January
11, xx,
2010
IST
Technical Requirements
Definition Process
The process is recursive and iterative and develops the stakeholders’
requirements, product requirements, and lower level product/component
requirements
• e.g., PBS model products such as systems or subsystems and related
enabling products such as external systems that provide or consume
data.
Requirements should enable description of all
• Inputs,
• Outputs
• Required relationships between inputs and outputs.
Technical requirements definition activities apply to the definition of all
technical requirements from the project, and system levels down to the lowest
level product/component requirements document.
5
| Place, Month
2007 || Event
B. Gonçalves |Author’s
Lisboaname
, January
11, xx,
2010
IST
Technical Requirements
definition process
6
| Place, Month
2007 || Event
B. Gonçalves |Author’s
Lisboaname
, January
11, xx,
2010
IST
Requirements Process
7
| Place, Month
2007 || Event
B. Gonçalves |Author’s
Lisboaname
, January
11, xx,
2010
IST
Requirements Analysis
Should result in a clear understanding of:
• Functions: What the system has to do,
• Performance: How well the functions have
to be performed,
• Interfaces: Environment in which the
system will perform, and
• Other requirements and constraints.
8
| Place, Month
2007 || Event
B. Gonçalves |Author’s
Lisboaname
, January
11, xx,
2010
IST
Structure
Requirements should be communicated in a structured manner
to ensure that the customer and technical community are able to:
a) Identify requirements that are derived from other requirements;
b) Organize requirements of different levels of detail into their
appropriate levels;
c) Verify the completeness of the set of requirements;
d) Identify inconsistencies among requirements;
e) Clearly identify the capabilities, conditions, and constraints for each
requirement;
f) Develop a common understanding with the customer of the purpose
and objectives of the set of requirements;
g) Identify requirements that will complete the SyRS.
9
| Place, Month
2007 || Event
B. Gonçalves |Author’s
Lisboaname
, January
11, xx,
2010
IST
Properties of a requirement
Each requirement should possess the following properties:
a) Abstract: Each requirement should be implementation
independent.
b) Unambiguous: Each requirement should be stated in such a
way so that it can be interpreted in only one way.
c) Traceable: For each requirement it should be feasible to
determine a relationship between specific documented customer
statement(s) of need and the specific statements in the definition
of the system given in the SyRS as evidence of the source of a
requirement.
d) Validatable: Each requirement should have the means to prove
that the system satisÞes the requirements.
10
| Place, Month
2007 || Event
B. Gonçalves |Author’s
Lisboaname
, January
11, xx,
2010
IST
Properties of the collection
The collection of requirements should have the following properties:
a) Unique set: Each requirement should be stated only once.
b) Normalized: Requirements should not overlap (i.e, they shall not refer to other
requirements or the capabilities of other requirements).
c) Linked set: Explicit relationships should be defined among individual requirements to
show how the requirements are related to form a complete system.
d) Complete: An SyRS should include all the requirements identified by the customer, as
well as those needed for the definition of the system.
e) Consistent: SyRS content should be consistent and non-contradictory in the level of
detail, style of requirement statements, and in the presentation of material.
f) Bounded: The boundaries, scope, and context for the set of requirements should be
identified.
g) Modifiable: The SyRS should be modifiable. Clarity and non-overlapping
requirements contribute to this.
h) Configurable: Versions should be maintained across time and across instances of
the SyRS.
i) Granular: This should be the level of abstraction for the system being defined.
11
| Place, Month
2007 || Event
B. Gonçalves |Author’s
Lisboaname
, January
11, xx,
2010
IST
System Requirements
Specification outline
12
| Place, Month
2007 || Event
B. Gonçalves |Author’s
Lisboaname
, January
11, xx,
2010
IST
Technical requirements specification:
Content
A technical requirements specification is typically composed of
three major sets of information:
• General information related to the context of the document (e.g.
administrative information, normative documents and informative
documents);
• General information related to the context of the project, the
product or system;
• Technical requirements
13
| Place, Month
2007 || Event
B. Gonçalves |Author’s
Lisboaname
, January
11, xx,
2010
IST
Technical requirements specification:
General information
The specification provides general information related to its context:
• Administrative information: to provide all the information regarding, for
example, the owner, status, identification, distribution list, and management
rule;
• Scope: to define without ambiguity the subject of the TS and aspects
covered, thereby indicating limits of applicability;
• References: to list all the normative (applicable) documents and
standards, with titles, issue revision, and dates that are referred to in the TS;
• Terms, definitions and abbreviated terms: to list the specific terms
and abbreviated terms used in the TS.
14
| Place, Month
2007 || Event
B. Gonçalves |Author’s
Lisboaname
, January
11, xx,
2010
IST
Technical requirements specification:
Context
Also provides general information related to the context of the project,
product or system:
• to provide a clear and rapid understanding of the project and the main
needs or mission statements;
• to give indications of the market as additional information, as well as
information about the context of the project and the objectives (situation
of the project in a larger programme, further developments);
• to provide information on the environment and its constraints;
• to detail the different situations of the product or system life cycle.
15
| Place, Month
2007 || Event
B. Gonçalves |Author’s
Lisboaname
, January
11, xx,
2010
IST
Type of requirements
•
Customer Requirements: Statements of fact and assumptions that define the expectations of the
system in terms of mission objectives, environment, constraints, and measures of effectiveness and
suitability
•
Functional Requirements: The necessary task, action or activity that must be accomplished.
Functional (what has to be done) requirements identified in requirements analysis will be used as the
toplevel functions for functional analysis.
–
•
e.g., “The product shall analyse the surface of Mars and transmit the data so that it is at the disposal of the scientific community”.
Performance Requirements: The extent to which a mission or function must be executed;
generally measured in terms of quantity, quality, coverage, timeliness or readiness. During
requirements analysis, performance (how well does it have to be done) requirements will be
interactively developed across all identified functions based on system life cycle factors; and
characterized in terms of the degree of certainty in their estimate, the degree of criticality to system
success, and their relationship to other requirements.
•
Design Requirements: The “build to,” “code to,” and “buy to” requirements for products and
“how to execute” requirements for processes expressed in technical data packages and technical
manuals.
•
Derived Requirements: Requirements that are implied or transformed from higher-level
requirement.
–
•
E.g., a requirement for long range or high speed may result in a design requirement for low weight.
Allocated Requirements: A requirement that is established by dividing or otherwise allocating a
high-level requirement into multiple lower-level requirements.
16
–
| Place, Month
2007 || Event
B. Gonçalves |Author’s
Lisboaname
, January
11, xx,
2010
IST
E.g., a 100-pound item that consists of two subsystems might result in weight requirements of 70 pounds and 30 pounds for the two lower-
Types of requirements
• Mission requirements, related to a task, a function, a constraint, or an action induced by
the mission scenario.
e.g., “The product shall be designed to be put in its final position after a transfer duration
shorter than 90 days”.
• Interface requirements, related to the interconnection or relationship characteristics
between the product and other items.
e.g., “The product shall dialogue with the ground segment using telemetry”.
• Environmental requirements, related to a product or the system environment during its life
cycle; this includes the natural environments (e.g. planet interactions, free space and dust) and
induced environments (e.g. radiation, electromagnetic, heat, vibration and contamination).
e.g., “The product shall operate within the temperature range from 30 ºC to 50 ºC”.
• Operational requirements, related to the system operability. This includes operational
profiles and the utilization environment and events to which the product shall respond (e.g.
autonomy, control and contingency) for each operational profile.
e.g., “The product shall be designed to accept control of the viewing function from the
ground segment”
17
| Place, Month
2007 || Event
B. Gonçalves |Author’s
Lisboaname
, January
11, xx,
2010
IST
Types of requirements
• Human factor requirements, related to a product or a process adapted to human
capabilities considering basic human characteristics.
• e.g., “The product shall display the information with no more than two windows on the
screen at the same time”.
• (Integrated) logistics support requirements, related to the (integrated) logistics support
considerations to ensure the effective and economical support of a system for its life cycle.
• Physical requirements, that establish the boundary conditions to ensure physical
compatibility and that are not defined by the interface requirements, design and construction
requirements, or referenced drawings. This includes requirements related to mechanical
characteristics, electrical isolation and chemical composition (e.g. weight and dimensional
limits).
• e.g., For example: “The product shall have a mass of (30 ± 0,1) kg”.
• Product assurance (PA) induced requirements, Requirements related to the relevant
activities covered by the product assurance. This can include the following subjects: Reliability,
availability, maintainability, Safety, and Quality assurance.
18
| Place, Month
2007 || Event
B. Gonçalves |Author’s
Lisboaname
, January
11, xx,
2010
IST
Types of technical requirements
• Configuration requirements, related to the composition of the product or its organization.
• e.g., “The product shall have 7 power modules with 2 power outlets per engine”.
• Design requirements, related to the imposed design and construction standards such as
design standards, selection list of components or materials, interchangeability, safety or
margins.
• e.g., “The receiver shall use a phase-lock loop (PLL)”.
• Verification requirements. related to the imposed verification methods, such as compliance
o verification standards, usage of test methods or facilities.
• e.g., “The thermal balance test shall be performed using solar illumination”.
19
| Place, Month
2007 || Event
B. Gonçalves |Author’s
Lisboaname
, January
11, xx,
2010
IST
Functional Requirements
The functional requirements need to be specified for all intended uses of the
product over its entire lifetime.
• Functional analysis is used to draw out both functional and performance
requirements.
Requirements are partitioned into groups, based on established criteria (e.g., similar
functionality, performance, or coupling, etc.), to facilitate and focus the requirements
analysis.
•Functional and performance requirements are allocated to functional partitions
and subfunctions, objects, people, or processes.
• Sequencing of time-critical functions is considered.
•Each function is identified and described in terms of inputs, outputs, and
interface requirements from the top down so that the decomposed functions are
recognized as part of larger functional groupings.
•Functions are arranged in a logical sequence so that any specified operational
usage of the system can be traced in an end-to-end path to indicate the
sequential relationship of all functions that must be accomplished by the system.
20
| Place, Month
2007 || Event
B. Gonçalves |Author’s
Lisboaname
, January
11, xx,
2010
IST
Performance Requirements
Performance requirements quantitatively define how well the system needs to
perform the functions.
Performance requirements draws out by asking the following types of questions:
• How often and how well,
• To what accuracy (e.g., how good does the measurement need to be),
• What is the quality and quantity of the output, under what stress (maximum simultaneous data
requests) or environmental conditions, for what duration,
• At what range of values,
• At what tolerance,
•At what maximum throughput or bandwidth capacity.
Wherever possible, define the performance requirements in terms of
1) Threshold value (the minimum acceptable value needed for the system to carry out its mission)
2) Baseline level of performance desired.
Specifying performance in terms of thresholds and baseline requirements provides the
system designers with trade space in which to investigate alternative designs.
21
| Place, Month
2007 || Event
B. Gonçalves |Author’s
Lisboaname
, January
11, xx,
2010
IST
Interface Requirements
It is important to define all interface requirements for the
system, including those to enabling systems, and the
external interfaces from the boundaries between the
product and the rest of the world.
Types of interfaces include:
• Operational command and control,
• Computer to computer,
• Mechanical,
• Electrical,
• Thermal,
• Data
22
| Place, Month
2007 || Event
B. Gonçalves |Author’s
Lisboaname
, January
11, xx,
2010
IST
Interface Requirements
One useful tool in defining interfaces is the context diagram, which depicts the
product and all of its external interfaces.
Once the product components are defined, a block diagram showing the major
components, interconnections, and external interfaces of the system should be
developed to define both the components and their interactions.
23
| Place, Month
2007 || Event
B. Gonçalves |Author’s
Lisboaname
, January
11, xx,
2010
IST
Reliability Requirements
Ensure that the system (and subsystems, e.g., software and
hardware)
• can perform in the predicted environments and
conditions as expected throughout the mission
• has the ability to withstand certain numbers and types of
faults, errors, or failures
• e.g., withstand vibration, predicted data rates, command
and/or data errors, single-event
24
| Place, Month
2007 || Event
B. Gonçalves |Author’s
Lisboaname
, January
11, xx,
2010
IST
Problems with Requirements
Problems of requirements elicitation can be grouped into
3 categories:
1. Problems of Scope: the requirements may address too
little or too much information.
2. Problems of Understanding: problems within groups
as well as between groups such as users and developers.
3. Problems of Volatility: the changing nature of
requirements.
25
| Place, Month
2007 || Event
B. Gonçalves |Author’s
Lisboaname
, January
11, xx,
2010
IST
Usual causes of
Problems with Requirements
Problems of Scope
• The boundary of the system is ill-defined
• Unnecessary design information may be given
Problems of Volatility
• Requirements evolve over time
Problems of Understanding
• Users have incomplete understanding of their needs
• Users have poor understanding of computer capabilities and limitations
• Analysts have poor knowledge of problem domain
• User and analyst speak different languages
• Ease of omitting “obvious” information
• Conflicting views of different users
• Requirements are often vague and untestable, e.g., “user friendly” and
“robust”
26
| Place, Month
2007 || Event
B. Gonçalves |Author’s
Lisboaname
, January
11, xx,
2010
IST
Benefits of Well-Written
Requirements
27
| Place, Month
2007 || Event
B. Gonçalves |Author’s
Lisboaname
, January
11, xx,
2010
IST
How to Write a Good Requirements
Use of Correct Terms
• Shall = requirement
• Will = facts or declaration of purpose
• Should = goal
Product Requirement
1.The requirement is in the form “product ABC shall XYZ.” A requirement must state “The
product shall” (do, perform, provide, weigh, or other verb) followed by a description of what
must be done.
2.The requirement uses consistent terminology to refer to the product and its lower level
entities.
3.Complete with tolerances for qualitative/performance values (e.g., less than, greater than
or equal to, plus or minus,3 sigma root sum squares).
4.Is the requirement free of implementation? (Requirements should state WHAT is needed,
NOT HOW to provide it; i.e., state the problem not the solution. Ask, “Why do you need the
requirement?” The answer may point to the real requirement.)
5.Free of descriptions of operations? (Is this a need the product must satisfy or an activity
involving the product? Sentences like “The operator shall…” are almost always operational
statements not requirements.)
28
| Place, Month
2007 || Event
B. Gonçalves |Author’s
Lisboaname
, January
11, xx,
2010
IST
How to Write a Good Requirements
Example Product Requirements
• The system shall operate at a power level of…
• The software shall acquire data from the…
• The structure shall withstand loads of…
• The hardware shall have a mass of…
29
| Place, Month
2007 || Event
B. Gonçalves |Author’s
Lisboaname
, January
11, xx,
2010
IST
Example Requirements
Checklist Categories
1. Clarity
2. Completeness
3. Complexity
4. Consistency
5. Constraints
6. Feasibility
7. Functionality/Logic
8. Interfaces
9. Standards
10. TBDs
11. Testability
12. Traceability
Etc.
30
| Place, Month
2007 || Event
B. Gonçalves |Author’s
Lisboaname
, January
11, xx,
2010
IST
Capturing Requirements and the
Requirements Database
At the time the requirements are written, it is important to capture the requirements
statements along with the metadata associated with each requirement.
• The metadata is the supporting information necessary to help clarify and link
the requirements.
31
| Place, Month
2007 || Event
B. Gonçalves |Author’s
Lisboaname
, January
11, xx,
2010
IST
Systems Engineering Process
32
| Place, Month
2007 || Event
B. Gonçalves |Author’s
Lisboaname
, January
11, xx,
2010
IST
Systems Engineering Process
33
| Place, Month
2007 || Event
B. Gonçalves |Author’s
Lisboaname
, January
11, xx,
2010
IST
Requirements Management
Apply to the management of all stakeholder expectations,
customer requirements, and technical product requirements
down to the lowest level product component requirements
The Requirements Management Process is used to:
• Manage the product requirements identified, baselined, and used in the
definition of the WBS model products during system design;
• Provide bidirectional traceability back to the top WBS model requirements;
• Manage the changes to established requirement baselines over the life
cycle of the system products.
34
| Place, Month
2007 || Event
B. Gonçalves |Author’s
Lisboaname
, January
11, xx,
2010
IST
Requirements Management Process
35
| Place, Month
2007 || Event
B. Gonçalves |Author’s
Lisboaname
, January
11, xx,
2010
IST
Requirements Management Process
Involves managing all changes to expectations and
requirements baselines over the life of the product and
maintaining bidirectional traceability between
• stakeholder expectations,
• customer requirements,
• technical product requirements,
• product component requirements,
• design documents,
• test plans and procedures.
36
| Place, Month
2007 || Event
B. Gonçalves |Author’s
Lisboaname
, January
11, xx,
2010
IST
Requirements Management Process
The successful management of requirements involves several key activities:
• Establish a plan for executing requirements management.
• Receive requirements from the system design processes and organize them in a
hierarchical tree structure.
• Establish bidirectional traceability between requirements.
• Validate requirements against the stakeholder expectations, the mission objectives
and constraints, the operational objectives, and the mission success criteria.
• Define a verification method for each requirement.
• Baseline requirements.
• Evaluate all change requests to the requirements baseline over the life of the
project and make changes if approved by change board.
• Maintain consistency between the requirements, and the architecture/design and
initiate corrective actions to eliminate inconsistencies.
37
| Place, Month
2007 || Event
B. Gonçalves |Author’s
Lisboaname
, January
11, xx,
2010
IST
References
• NASA Reference Publication 1370, Training Manual for Elements of Interface
Definition and Control
• NASA Systems Engineering Handbook, NASA/SP-2007-6105, Rev1, 2007
• SYSTEMS ENGINEERING FUNDAMENTALS, SUPPLEMENTARY TEXT
PREPARED BY THE DEFENSE ACQUISITION UNIVERSITY PRESS FORT
BELVOIR, VIRGINIA 22060-5565, January 2001
• IEEE Guide for Developing System Requirements Specifications, IEEE Std 1233,
1998 Edition
• IEEE Recommended Practice forSoftware Requirements Specifications, IEEE
Std 830-1998
• Space engineering Technical requirements specification, ECSS-E-ST-10-06C,
ESA-ESTEC Requirements & Standards Division, 6 March 2009
38
| Place, Month
2007 || Event
B. Gonçalves |Author’s
Lisboaname
, January
11, xx,
2010
IST
Backup slides
39
| Place, Month
2007 || Event
B. Gonçalves |Author’s
Lisboaname
, January
11, xx,
2010
IST
Characteristics of a technical requirement
Performance
a. Each technical requirement shall be described in quantifiable terms.
b. If necessary to remove possible ambiguities of a given performance
requirement the method used to determine the required performance
shall be indicated in the requirement itself.
Justification
a. Each technical requirement should be justified.
b. The entity responsible of the technical requirement shall be identified.
c. The entity responsible of the specification shall define what part of the justification shall be
included in the specification as informative material.
Configuration management and traceability,
a. Each technical requirement shall be under configuration management.
b. All technical requirements shall be backwards-traceable.
c. All technical requirements shall be forward-traceable.
• A technical requirement is traceable when it is possible to trace the history, application, or
location of a requirement by means of recorded identification.
Ambiguity
a. The technical requirements shall be unambiguous.
40
| Place, Month
2007 || Event
B. Gonçalves |Author’s
Lisboaname
, January
11, xx,
2010
IST
Characteristics of a technical requirement
Uniqueness
a. Each technical requirement shall be unique.
Identifiability
a. A technical requirement shall be identified in relation to the relevant function, product or system.
b. A unique identifier shall be assigned to each technical requirement.
c. The unique identifier should reflect the type of the technical requirement.
d. The unique identifier should reflect the life profile situation.
Singularity
a. Each technical requirement shall be separately stated.(not the combination of two or more technical
requirements)
Completeness
a. A technical requirement shall be self-contained. (when is complete and does not require additional
data or explanation to express the need).
Verification
a. A technical requirement shall be verifiable using one or more approved verification methods.
Tolerance
a. The tolerance shall be specified for each parameter/variable. ( range of values within which the
conformity to the requirement is accepted).
41
| Place, Month
2007 || Event
B. Gonçalves |Author’s
Lisboaname
, January
11, xx,
2010
IST