SYSTEMS ENGINEERING

MOOC 3 REQUIREMENTS AND REQUIREMENTS

ENGINEERING
PART 1
In the last two modules we introduced systems, the
system life cycle, and systems engineering. In
particular, we looked at the relevance and benefits of
systems engineering.
Before we look at the various systems engineering
activities in more detail in forthcoming modules, in
this presentation we look at what we mean when we
refer to the needs and requirements for a system.
We will also consider in this module how we might
go about developing a set of requirementswe call
that process requirements engineering.

When describing the system, we make the distinction

between needs and requirements:
Needs are generally capabilities stated in the
language of business management or stakeholders at
the business operations levels.
Requirements are formal statements that are
structured and can be validatedthere may be more
than one requirement that can be defined for any
need.

Requirements are generated from needs through a

process of requirements analysis (which is also called
business analysis or mission analysis at the higher
levels).

Needs and requirements exist at a number of levels.

There is an enterprise view (in which enterprise
leadership sets the enterprise strategies and
concepts of operations); a business management
view (in which business management derive business
needs and constraints as well as formalize their
requirements); a business operations view (in which
stakeholders define their needs and requirements);
and a systems view (in which the system is defined in
logical and physical views). Subsequently, of course,
there are the views at the lower-level of the
subsystem and other system elements.

As illustrated here, the enterprise, business

management, and business operations views are in
the problem domain; the system and subsystem (and
lower) views are in the solution domain.
As we discussed in earlier modules, the problem
domain is generally considered to be the
responsibility of those who have ownership of the
problem to be solved, so the descriptions of the
system are predominantly in the language of the
customers business management and business
operations, focusing on what the system needs to be
able to do, how well it should be done, and why
these descriptions are called logical (or often
functional) descriptions. On the other hand, the
solution domain is generally considered to be the
responsibility of those implementing the solution, so
the descriptions of the system in that domain are
predominantly in engineering and physical terms,
focusing on how the problem is to be solvedthat is,
how it will look once it has been implemented. These
latter descriptions are called physical descriptions.

At the highest level, the enterprise has a number of

strategies that will guide its future.
From our perspective, our system has its genesis in
the Concept of Operations (ConOps) which
communicates the leaderships intentions with
regard to the operation of the organisationin terms
of existing systems and systems to be developed.

The Business Needs and Requirements (BNR)

Definition Process begins with the organizations
vision, goals and objectives communicated by the
ConOps.
Business management uses this guidance to define
Business Needs, largely in the form of Preliminary
Life-cycle Concept Documents (PLCD), which capture
the Preliminary Acquisition Concept, Preliminary
Operational Concept (the Preliminary OpsCon),
Preliminary Deployment Concept, Preliminary
Support Concept, and Preliminary Retirement
Concept.

Lets look at those life-cycle concepts in a little more

detail.
The Operations Concept (OpsCon) describes what the
system will do, how well and why (from the
perspective of the user).
The Acquisition Concept describes the way the
system will be acquired including aspects such as
stakeholder engagement, requirements definition,
solicitation and contracting issues, design,
production, and verification.
The Deployment Concept describes the way the
system will be validated, delivered, and introduced
into operations.

The Support Concept describes the desired support

infrastructure and manpower considerations for
supporting the system after it is deployed. A support
concept addresses operating support, engineering
support, maintenance support, supply support and
training support.
The Retirement Concept describes the way the
system will be removed from operation and retired,
including the disposal of any hazardous materials
used in or resulting from the process.
At this early stage, business management prepare
draft, or preliminary concepts, that will be fleshed
out late by stakeholders at the business operations
level.

First, however, the Business Needs contained in the

Preliminary Life-cycle Concepts are elaborated and
formalized into Business Requirements, which are
documented in the Business Requirements
Specification (BRS), which is also called the Business
Requirement Document.
The process by which business needs are
transformed into business requirements is called
mission analysis or business analysis.

Once business management are satisfied that their

needs and requirements are reasonably complete,
they pass them on to the business operations level.
Here, the Stakeholder Needs and Requirements (SNR)
Definition Process uses the ConOps and the other
PLCD as guidance.
Requirements engineers lead stakeholders from the
business operations level through a structured
process to elicit Stakeholder Needsin the form of a
refined OpsCon document and other Life-cycle
Concept Documents (LCD).

Stakeholder needs are then transformed into a

formal set of Stakeholder Requirements, which are
documented in the Stakeholder Requirement
Specification (StRS).
That transformation is guided by a formal process of
requirements analysis.

At the system level, in the System Requirements

Definition Process, the requirements in the StRS are
then transformed by requirements engineers into
System Requirements, which are documented in the
System Requirement Specification (SyRS) (also
referred to as the Solution Requirement Specification
Document, or simply the System Specification).
Note that the figure illustrates that a number of SyRS
may be derived from the StRS. Also note that some
organizations may prepare individual LCD for each of
a number of systems that are developed to meet the
Business Needs.

The process then continues for the system elements.

As we observed earlier, the requirements are now
physical requirements as they relate to the elements
of the system rather than the system itself.

PART 2
We have talked about needs and requirements and
how we use business and requirements analysis to
translate between them at the various levels. Let us
now look at that process in a little more detail. Lets
start with some definitions that will assist.
First, we have to recognize that terms such as system
and system element are level-specific, so we need a
term that can apply at any level and to any single
thing at that level, whether an enterprise, business
unit, system, system element (which could be a
human or organisation), or process.

So we define an entity as:

An entity is a single thing to which a need or
requirement refers: an enterprise, business unit,
system, system element (which could be a product,
process, human, or organisation).
A need can then be defined as the result of a formal
transformation of one or more concepts for an entity
into an agreed-to expectation for that entity to
perform some function or possess some quality
(within specified constraints).

So what then is a requirement?

A requirement is the result of a formal
transformation of one or more needs into an agreedto obligation for an entity to perform some function
or possess some quality (within specified
constraints). It is common to refer to two major
categories of requirement.
The first is a functional requirementsomething that
the system should do or provide.
The remaining types of requirements are called nonfunctional requirementswhich refer to some...

...property, quality or attribute that the system must

possess, a condition the system must meet, or a
constraint under which it must operate or be
developed.

One type of requirement that is commonly included

as a non-functional requirement is a constraint.
A constraint is some restriction or bound: under
which the system should operate, or on the way in
which the system is to be developed.
As I said, constraints are most commonly included in
the category of non-functional requirements, but
sometimes they are listed separately.

Requirement statements should not be written in

isolation but should be supported by:
Performance, verification, and rationale statements
supporting each requirement.
Definitions of other systems with which the system
must integrate and to which it must interface.
Information about the application domain within
which the system must operate.
Requirement statements have the same structure
and follow the same rules, regardless of the level at
which they are written. It should be noted, however,
that the requirements in the BRS and the StRS are
not as formal as those in the SyRS.

Lets look in a little more detail at performance

requirements, verification requirements and
rationale statements. First, performance
requirements.
Having decided what the system must do, the
designer must now determine how well the system is
to perform each of those functional requirements.
A good discipline is to ensure that, every time a
functional requirement is articulated, at least one
corresponding performance statement is made.
Most of the operational functions will have obvious
performance parameters associated with them such
as speed, accuracy, endurance, and acceleration.

The definition of functional and performance

requirements is not complete until verification
requirements are also included.
Every time a functional requirement is articulated
(with appropriate performance statement(s)), it is
good practice for a corresponding verification
statement to be made.
It is often difficult to write verification requirements
for system-level functions, but the discipline of doing
so is important since there is little point in stating a
requirement for a function without consideration of
how the function is to be tested. An additional
benefit of adhering to the discipline at this stage is
that test plans become much easier to write because
the tests required at any level can be considered
within a framework provided by an aggregation of
the verification requirements at that level.

The rationale for a requirement is the reason why the

requirement exists.
The rationale may record the design decision(s)
leading to the requirements, the assumptions behind
it, or something as simple as the logic behind the
selection of the numbers in the statement (for
example, why they have been rounded to two
decimal places).
A requirement should not be accepted unless the
rationale is well understood.

As well as these broad categories, an adjective is

often included to describe the nature of the
requirement.
So, reference is often made to operational
requirements, stakeholder requirements,
environmental requirements, interface requirements,
system requirements, regulatory requirements,
safety requirements, design requirements, and many
more other categories of requirements.

In general, a requirement should be a statement of

what a system should do, rather than how it should
do it.
However, this is often too simplistic in practice,
because:
it may be essential that the system should perform a
function in a particular way (for example, for
interoperability, to meet extant standards, etc)
a specific statement is often less easily confused than
an abstract statement of the problem
the specifiers of the system are often the domain
expertsthey are therefore best placed to state how
the system should be developed and how it should
operate

So why do we need requirementswell there are a

number of reasons.
First, we need to be able to define a scope for the
project. How else would we know what the system is
to do?
Then, we need to ensure that everyone involved has
had input and the various points of view have been
reconciled.
We also need to be able to justify any expenditure of
funds or effort based on the need to achieve an
endorsed set of requirements.
We need to be able to report on progress.
And, finally, we need to be able to tell when we are
finished (or when the contractor is finished).

Lets now look at some other major definitions. We

have used some of these terms already in a general
sensehere we define them more precisely.

A user is someone who is involved in using the

system once it has been developed. Strictly speaking
users are part of the system (as are materials,
facilities, data, software and hardware). Users are
sometimes called actors. Users include operators,
maintainers, etc.
The customer is the organisation that is paying for
the system to be developed.
The acquirer is the entity acquiring the system.
Because the users are normally too busy with
operational tasks, the do not have time (or the
expertise) to acquire new systems. Large customer
organisations will therefore most likely have a
separate acquisition organisation.

The developer is the entity responsible for

developing the products that make up a system
(software, hardware, documentation, and so on).
The contractorthe organisation within which the
development is conducted, normally under contract
with the customer. The customer could have an inhouse developer, but most organisations outsource
development to a contractor.
A stakeholdersomeone who has a right to
influence the requirements (often, someone affected
by the system). Users are invariably stakeholders.
Other stakeholders may include management,
clients, the public, and so on.

We have discussed needs and requirements. Let us

now turn to requirements engineering.

As illustrated here, requirements engineering is the

formal process through which we move from the
enterprise strategies to the system requirements,
first by formally translating the business
requirements into stakeholder requirements and
then the stakeholder requirements into system
requirements.

We saw earlier why we need requirements. We need

requirements engineering to ensure that we can get
those requirements.
We need to be able to guarantee that we have a
complete set of requirements that are unambiguous,
complete, and non-conflicting.
We must be able to trade off functionality for cost
which implies that we understand the required
functionality, priorities, and costs.
We need to be able to manage changes in
requirements for a wide variety of reasons.
PART 3
Before we leave requirements, it is common to
consider two additional aspects of requirements and
requirements engineering.
First, there are certain characteristics we desire from
a well-formed requirement. Second, we often
append to the requirement statement one or more
attributes which will help us manage the
requirement statement and the set of statements.
Lets look first at the characteristics of a well-formed
requirement.

Desirably, to be useful, each requirement statement

should exhibit all of the following characteristics:
Necessary. The requirement must be necessary in
that the system could not function in the desired way
without this requirement. It also follows that a
requirement cannot be necessary if it cannot be
traced back to a higher-level requirement (and the
associated need).
Singular. A requirement cannot be a combination of
two or more requirementsthat is the...

10

... requirements set must be normalized so that

requirements do not overlap. This also implies that
the requirement is concise and clear.
Correct. That the requirement must be correct is
axiomatican incorrect requirement will result in a
system that does not meet the real requirements.
Unambiguous. All readers of the requirement should
come to the same understanding of what the
requirement is sayingthere can be only one
interpretation. This is difficult, particularly in English,
where one statement can have more than one
meaning.
Feasible. A requirement must be achievable using
existing technologies and manufacturing.

Additionally, a requirement statement must be:

Appropriate to Level. Each requirement must be
appropriate to the level at which it is stated. That is,
for example, if it is a system-level statement, it
should not refer to sub-system properties.
Complete. The requirement must stand alone and
should not need further explanation.
Conforming. Each requirement must conform to a
standard formal structure as defined by the
organisation, or perhaps in accordance with an
external standard.
Verifiable. Each requirement must be verifiable, in
that it can be proved that the system meets or
possesses the requirement. Verification may be by
one or more means.

To support analysis and management, requirements

should be allocated a number of attributes. There
can be many attributes attached to a requirement
here we identify a small number of the major
attributes:
Unique identifier. Each requirement must be able to
be identified as a unique statement.
Short title. It is useful to give the requirement a
unique short title, which makes it easy to refer to the
content of the requirement as well as making it
simpler to display in graphical format such as in the
RBS.
Priority. Requirements are often stated in terms of

11

their importance to individual stakeholders. The

priority of each requirement provides some design
space within which to work during requirements
analysis and negotiation.
Risk. Each requirement contributes to overall system
risk in its own way.
Source. The originator (person, organization,
document, or process) must be recorded to ensure
that all requirements can be justified.

Rationale. A rationale must be recorded for each

requirement to record the reason for its existence.
Rationale is essential to guide subsequent design.
History. This portion identifies any changes that are
made to the requirement throughout the design
process.
Relationship to other requirements. The relationship
with other requirements must be identified to assist
in forward and backward traceability.
Other information. Each requirement should be
stored with the date of raising, the status (proposed,
reviewed, accepted, rejected), and comments.

Finally, it is often useful to add a type attribute so

that the requirements can be considered n various
logical groupings that are useful in their
management.
Examples include such types as input, output,
external interfaces, reliability, availability,
maintainability, accessibility, environmental
conditions, ergonomic, safety, security, facility,
transportability, training, documentation, testing,
and so on.

Finally in this module, we make brief reference of

what we call emergent properties of a system. That
is, we have to recognise that when we develop a
system it will have certain properties that are those
that are possessed by the system as a whole but are
not obvious in any of the elements or
interconnections. These properties therefore only
emerge after all the individual system elements have
been integrated. These emergent properties cannot
be exhibited by elements of the system in isolation
because they depend on interactions between those
elements, including interaction with their
environment.

12

Examples of emergent properties are:

maintainability, reliability, usability, security, and so
on.
Perhaps the bicycle is one of the best examples of a
system that possesses emergent properties since it
can only perform its principal function when all
system elements, including the rider, have been
integrated. If any one of the major subsystems is
removed, the system cannot function.

We are interested in emergent properties because

they must be defined from the top downthey
cannot be obtained by specifying requirements for
individual system elements and then hoping that the
desired properties will exist on integration. That is,
for example, we must start by saying the system is
safe and then decide how the constituent system
elements contribute to that safety rather than make
all the elements safe and hope that the resulting
system is therefore safe.
Of course we also must consider the possibility of the
completed system exhibiting emergent properties
that were not considered as part of its design and, in
some cases, may be undesirable in the completed
product.

In this module, we have discussed requirements

the levels at which they exist and the relationship
between them at each of those level. We looked at a
number of definitions and then finished with an
introduction to requirements engineering. In the next
module, we will look in more detail how to create
and validate a set of requirements.

13