SYSTEMS ENGINEERING

MOOC 4 REQUIREMENTS AND REQUIREMENTS

ENGINEERING
PART 1

We saw earlier that needs and requirements can be

captured in logical or functional hierarchies. At the
end of this module we look briefly at a tool (called
the requirements breakdown structurethe RBS)
that will assist in developing these hierarchies.
First, however, lets look at the process by which the
needs and requirements are related to each other at
the various levels of a hierarchy.

A functional hierarchy is produced through two

principal processes: elicitation and elaboration.
Elicited elements are able to be directly attributed to
the source and are normally gathered via interview
or workshop. An elicited element could also,
however, be drawn directly from some constraint
(such as a regulation, for example). Elicited elements
are explicitthat is, they are largely given to us
directly by the business or the stakeholders or are
taken directly from come constraint.

Elaboration, on the other hand, involves analysis

which would conclude in some element that is
necessary as a result of the business or stakeholder
intentions. This analysis is either decomposition or
derivation:
Decomposition entails breaking a higher-level
function into those lower-level functions that are
explicitly required by it.
Derivation entails requirements engineers drawing
some inference. That is, business management or the
stakeholders did not state the function directly, but
the derived function is a necessary part of the system
design if one or more of the directly stated functions
are to be met.

The elicitation and elaboration tasks are not for

novicesthat is particularly true for elaboration. To
undertake them properly, requirements engineers (or
business analysts) must understand:
the business,
the application domain,
the specific problem,
the needs and constraints of system stakeholders,
acquisition and project management,
requirements engineering and systems engineering,
and
the technologies and engineering involved.
You can see by this list that such skill sets rarely
happen by accident and must be deliberately
developed.

By way of simple example, consider an upper-level

statement of the mission of a medical centre.
The ACME Medical Centre is to provide a selected
range of Medical Services in a secure and
comfortable environment, in order to attain a
nominated Profit.
The following functions are decomposed (that is, they
are explicit in the statementhere highlighted in red
bold font):
Provide selected range of medical services
Provide a secure environment
Provide a comfortable environment
Attain nominated profit level

The following functions are derived (that is, they

have not been stated explicitly in the statement but
are necessary functions if the explicit functions are to
be achieved):
Provide medical centre infrastructure
Manage medical centre and its services
Support medical services

Needs and requirements can be identified by:

Structured workshops are the most useful for early
designthey are almost certainly the fastest and
most efficient way. Workshops should start with
strawman artifacts that are fine-tuned and
augmented throughout the assigned period.
Workshops should be facilitated where possible to
ensure they run smoothly.
Brainstorming and problem-solving sessions can be
considered to be unstructured structured workshops
and are therefore really only useful early on to assist
in the development of initial artifacts.
Interviews should be considered as one-on-one
workshopsthat is, they should be structured in that
they should start with strawman artifacts, and have
an agenda.
Surveys/questionnaires do not have a great return
rate (somewhere in the vicinity of 10-20%) so they
are not good ways of ensuring that all stakeholder
views are represented but questionnaires are a good
way of ensuring that the widest number of
participants have at least the opportunity to
contribute.
Use cases and operational scenarios are an excellent
way to identify detailed needs and requirements. We
humans are natural story tellers, so it is a useful way
to ask stakeholders to describe their engagement
with the system to be developed.
Similarly, when we are at a sufficiently low level in
the design, simulations, models and prototypes are
useful ways to understand needs and requirements
as well as to conduct various trade studies and
analyses.
The remainder of the activities are relatively low
level and are not really useful until we are well into
Preliminary Design. Such efforts can include:
observation of work studies (time and motion
studies)
participation in work activities
observation of the systems organisational and
political environment ...

 technical documentation review

market analysis
competitive system assessment
reverse engineering
benchmark processes and systems

The entire systems engineering process aims to

produce a system that is both verified against the
documentation produced during the systems
engineering process, and validated against the
original needs and requirements that initiated the
system development in the first case.
So, there are two principal acts:
Verificationwhich ensures that the system at any
stage matches the specifications we have developed
for itthat is, we have built the system right
Validationwhich ensures that the system meets
the original business needs and requirementsthat
is, we have also built the right system.
Often these two associated aims are combined into
the term verification and validation (V&V).

Returning to our diagram showing how

requirements engineering assists in the
development of requirements, we can now
work backwards.
Before the customer accepts the system from
the contractor, the delivered system is verified
against the System Specification (the SyRS).

Before the system can be put into service,

however, it must be validated against the
stakeholder needs and requirements (the
StRS) and the business needs and
requirements to ensure that those needs and
requirements are met.

Verification and validation is underpinned by a wellmanaged approach to test and evaluation (T&E),
which aims to support the delivery of a system that is
both verified and validated. There are three major
categories of T&E that are applied to coincide
broadly with the activities of the Acquisition Phase,
the transition between the Acquisition and
Utilization Phases, and the Retirement Phase.
Developmental test and evaluation (DT&E). DT&E
refers to the T&E activities undertaken during the

Acquisition Phase to support the design and

development effort. DT&E activities may also occur
during the Utilization Phase to support activities such
as the development of modifications.

Acceptance test and evaluation (AT&E). AT&E

represents the formal testing conducted to enable
the customer to verify the system and to accept it
from the developer. AT&E effectively forms the
boundary or transition between the Acquisition
Phase and the Utilization Phase and, as such, is an
important contribution to FQR.

Operational test and evaluation (OT&E). Once the

systems is accepted from the developer, OT&E may
be conducted under realistic operational conditions
by operational personnel in order to validate the
capability system. OT&E is normally conducted for a
period of time following acceptance of the system by
the customer from the contractor (that is, after
AT&E) and before introduction into service.

PART 2
Lets now look at the important function of
requirements management.

Requirements management is the process by which

changes to requirements are managed throughout
the system lifecycle.
Requirements change because:
they are derived from the stakeholder need and must
be managed as they are developed
stakeholder requirements change over the life of the
system
the business may change

the environment will no doubt change over the

lifecycle
laws and regulations will change over the life of the
project
It is often the case that more than 50% of a systems
requirements are modified before it is put into
service.
A requirements management tool is generally
necessary to assist in the management of the large
number of requirements.
It is almost impossible to have requirements
traceability without implementing the requirements
in some automated context.

A requirements management tool:

Supports elicitation and allows requirements
engineers to capture requirements as they are
gathered
Once the requirements are captured, the tool should
allow readers to browse the requirement set but also
to retrieve specific requirements and to generate
reports of subsets of requirements based on selected
criteria.
The tool should support forward and backward
traceability to allow investigation of how a higherlevel requirement is achieved as well as to identify
the origin of any lower-level requirement.
Requirements engineers need the support of the tool
to generate good requirements with the appropriate
spelling, punctuation, and use of glossary and
template items.
Requirement sets also need to be delivered in a
variety of formats so it is important that the tool
allows import and export of requirements in various
formats such as word-processing and spread-sheet.
The tool should support change control and change
impact assessment as well as the functional
allocation and functional-to-physical translation.
It is also important that the tool does not enforce any
particular requirements engineering process.

There are a large number of tools that may assist in

requirements engineering, including the context
diagram, functional flow block diagrams (FFBD),
requirements breakdown structure (RBS), and N2
diagrams. Other tools include structured analysis,
data flow diagrams (DFD), control flow diagrams
(CFD), IDEF diagrams, behaviour diagrams, action
diagrams, state/mode diagrams, process flow
diagrams, function hierarchy diagrams, state
transition diagrams (STD), entity relationship
diagrams (ERD), structured analysis and design,
object-oriented analysis (OOA), unified modelling
language (UML), structured systems analysis and
design methodology (SSADM), and quality function
deployment (QFD).
Here we focus on the RBS and the FFBD.

Here we call the requirements framework the

requirements breakdown structure (RBS)also called
the functional hierarchy.
The words are deliberately chosen to differentiate
this structure from the well-known project
management document called the work breakdown
structure (WBS).
The RBS is grouped logically (functionally), whereas
the WBS is structured by physical work packages for...
...the configuration items that will combine to deliver
the system and contains other project-related work.
At the end of Preliminary Design, the logical
groupings of the RBS are then allocated to the
physical groupings of the CIs in the WBS.

The principal benefit of the functional hierarchy is

that it provides a framework within which
requirements can be developed and tracedalso
called requirements flowdown.
The hierarchy is a tree (in maths we call it a directed
graph) in which branches flow from the mission
statement at the top to the lowest level needs and
requirements (which are the leaves of the tree at the
bottom). At each level, we stay at a level of
abstraction that remains within our intuitionsince
wwe can only hold in our working memory half a
dozen key concepts, the framework encourages us to
start with a mission statement within which there are
5 to 7 key concepts. Each of those concepts is
fleshied out as a statement at the next level, leading
to 5-7 goal statements, each of which contains 5-7
concepts, each of which can then be fleshed out as
an objective statement, each of which has 5-7 key
concepts, and so on. The process continues until we
reach the leaves of the tree.

If we look at that tree more formally, we can see that

the addition of a numbering system allows each level
to be associated with the level above and below.

Some general rules for developing the RBS:

The RBS is to be displayed hierarchically. The level of
the RBS illustrated should be such that the portion
displayed should be visible on a single A4 sheet of
paper, at no less than 10-point font.
Naming of RBS elements should be consistent so that
the key-word phrases are verb-based.
The length of the key-word phrases should be...
...consistent (three or four words are normally
sufficient).
Each key-word phrase must be unique (since it must
be fleshed out into a unique requirement).
Elements should be numbered with a hierarchical

numbering system so that parent requirements can

be traced to their children and vice versa.

Here is an example of an RBSin this case, for a

domestic security alarm as part of our house. If we
look across the five elements at the first level we can
see the major functions of the alarm. If we look at
the next level, the RBS shows the functions that
combine to form each parent function at the level
above.
As you can see from this diagram, the RBS is
powerful tool to illustrate the functionality to be
provided by the system.

The hierarchical representation of requirements in

the RBS can be supported by FFBDs to show the flow
between functions.

Some general rules for developing FFBDs:

The FFBDs should be displayed as a hierarchical
elaboration.
The level of the FFBD illustrated should be such that
the portion displayed should be visible on a single A4
sheet of paper, at no less than 10-point font.
As with the RBS, naming of the FFDB elements
should be consistent.
The FFBDs also make use of a hierarchical numbering
system. Where possible, the same numbering system
is to be used in the RBS and the FFBDs.

Here is an example portion of a first draft of an FFBD,

as it has been prepared in a workshop with
stakeholders. Note that the functions have yet to be
formally written and the numbering system has yet
to be appliedit is often best to capture the
functions informally and then formalise them than it
is to try to capture them in some formal template.

10

Note that the FFBDs are very good ways of capturing

the operational scenarios from which the needs and
requirements will be developed.
Unlike the RBS which just show logical relationships,
the FFBDs provide the requirements engineer with
information about the sequencing of functions,
which is of great assistance when identifying
interfaces.

Requirements cannot be managed effectively

without requirements traceability.
Traceability ensures that we know where the
requirement came from, what requirements are
related to it, and what requirements were derived
from it.
Good traceability allows us to identify all
requirements affected by a change, for example.

Broadly, there are two types of traceability: forward

traceability and backward traceability.
Forwards traceability gives us confidence that each
requirement has been addressed in the design.
Backwards traceability allows us to trace from each
requirement back to at least one requirement in the
parent document

Through forward traceability, design decisions can be

traced from any given system-level requirement (a
parent requirement) down to a detailed design
decision (a child requirement).
For each requirement, we must be able to find at
least one child in the subordinate design documents.
If there is more than one child, we must be able to
identify all of them.

11

Backward traceability ensures that additional

requirements (not formally endorsed by the
customer) have not crept (through requirements
creep) into the design.
Any aspect of the design that cannot be traced back
to a higher-level requirement is likely to represent
unnecessary work for which the customer is most
probably paying a premium.
An orphan requirement is out-of-scope.

Well, it has been a bit of a hard slog, but we have

now covered all the basics we need to allow is to look
at the life cycle phases in mode detail. In the next
module, Ian will begin out discussion of the
Acquisition Phase by examining Conceptual Design.

12