in this video i want to introduce a very
popular
if not infamous topic within systems
engineering
requirements now like most things within
systems engineering there is a lot
to cover as well as a lot of nuance that
unfortunately
has to be skipped over in a short video
like this one
therefore we shouldn't treat this as
everything you need to know
but rather we're going to cover a few
important and interesting ideas behind
requirements we're going to talk about
what they are
we'll describe what makes a good
requirement and then we'll briefly show
how they contribute
to the system design process i hope you
stick around for it
i'm brian and welcome to a matlab tech
talk
there is a quote that is probably
misattributed
to albert einstein that goes something
like this
given one hour to save the world i would
spend 55 minutes defining the problem
and five minutes resolving it and even
though this is a bit
exaggerated the idea is that time spent
understanding and agreeing on what the
problem even
is can be more useful than the time
actually solving it
because it ensures that you are solving
the right problem
and we've talked about how the systems
engineering process
is set up to do just this to spend a lot
of time
defining the problem first and this is
where requirements come in
requirements and their associated
constraints and assumptions
are a means for quantifying the problem
to be solved
they are a way to record and describe
what needs to be designed
and they provide how project success
will be determined a requirement
consists
of three things a description of a
particular need
a rationale for why the requirement is
valid and a way to verify that the
system
meets that requirement so in other words
we write
down what the system needs to accomplish
we make sure that what we wrote
is actually worth doing and we make sure
that there will be a way
to prove that the system actually meets
it
we're going to get into the details of
each of these in just a bit but
for now i want to highlight some of the
different types of requirements
so that you can get a feel for the needs
that we may levy on a system throughout
the project
first off we may write requirements that
specify which
functions the system needs to perform
and then there are performance
requirements which describe how well
a system must perform a function and
there are constraint requirements that
cover which parameters
a system shouldn't exceed and
environmental requirements
and human factors and reliability and
safety and so on
they cover every aspect of the design
where you have specific
needs that must be met so let's go
through a few examples with the toaster
that we introduced in the last video
to show you some of the different types
of requirements in action
a functional requirement specifies
functions
so for the toaster we might have the
toaster shall convert electrical energy
into thermal energy this is a
requirement that we can verify
by inspecting the toaster design and
seeing that the function
exists now for a performance requirement
we might say that the toaster shall be
capable of converting up to
100 watts of electrical power into
thermal power
and again this requirement could be
verified by analyzing the design
and ultimately through test once the
toaster is built
a constraint requirement might be
something like the toaster mass
shall be less than five kilograms which
we verify
by analyzing the mass budget early in
the design
and then through inspection by weighing
the actual toaster
so those are three of the requirements
that we claim the toaster must
satisfy and a few different ways to
verify that the design will meet those
requirements
but beyond just the description and the
verification method
we also have to think about their
validity
that is are these requirements valid
and if so what is the rationale for each
of them
there are two broad categories that a
requirement must satisfy in order for it
to be valid
firstly the requirement must be
something that we actually want to levy
on the system
and secondly the requirement must be
written in a way
that conveys the right message
let's dive into both of these we need to
make sure that we are designing and
building the right thing
the thing that the stakeholder actually
wants therefore the requirements have to
specify needs that help achieve the end
goals
for example a good requirement for a
toaster might be that the volume of the
toaster must be less than one cubic foot
and this is valid because we can trace
it back to a stakeholder need
that says that it has to fit on a
standard kitchen countertop
therefore we feel pretty good about
constraining the design
to this size now on the other hand a
requirement that says that the toaster
shall be able to simultaneously toast
10 slices of bread probably isn't valid
i mean it's a perfectly legitimate
requirement we
could create a design that accomplishes
this but it's one that we wouldn't
want to levy on the design for at least
two reasons it doesn't trace back to
meeting any of the stakeholder needs
so there's no higher level requirement
or objective that we can point to
as to why this requirement exists but
worse than that it's probably
inconsistent with the toaster volume
requirement because it complicates our
ability
to meet it this is kind of a silly
example
but inconsistent requirements are
unfortunately
easy to create because two individual
requirements could appear to be valid on
their own
and even trace up to the stakeholder
needs but it's only after looking across
the requirement set
as a whole can we determine if there are
inconsistencies in the definition of the
system
that need to be addressed and finding
this out as part of the requirements
validation effort
is preferred over finding it out after
you've designed
the system now even if we have a valid
rationale for a requirement
and it's technically and
programmatically feasible
and everything is consistent a
requirement still might not be valid
if it's poorly written to understand
what that means
let's go through some examples
a requirement must be clear concise and
unambiguous
that is it conveys a single thought can
only have a single interpretation
and doesn't contain unnecessary
information
for example a poorly written requirement
might be the toaster shall have a
removable crumb tray
and it should weigh less than five
kilograms
this is poorly written because not only
are there two thoughts here
the crumb tray and the weight but it's
not entirely clear
whether it's the tray or the toaster
that has to be below five kilograms
it's better to split this up into two
requirements that are clear
and can each be independently verified
another way a requirement could be
poorly written is if it's unverifiable
and being unverifiable might come from
the use of words like
minimize and maximize and user friendly
to describe the need
i mean you could write a requirement
that says that the toaster shall be
user friendly but verifying that would
be
very subjective
a better approach would be to perform
product research ahead of time where
various design
choices are ranked by the potential
users based on how user friendly it is
and then you write requirements for the
features that are desired
any requirements that you have that
can't be verified
should be removed or revised because you
won't have a way of guaranteeing
that the system meets it in the end
the last sort of requirement pitfall
that i want to discuss here
is that of specifying implementation
requirements
like functions from the last video
typically describe what the system
should do
and what it's constrained by and not
describe how it should be done
for example we have the requirement that
says that the toaster shall be capable
of converting up to 100 watts of
electrical power
into thermal power this defines a
particular aspect of the design
what it has to do it has to convert up
to 100 watts
but how does it do that well the
requirement doesn't say
it could be with coils or some other
heating element
the domain experts within the
engineering team should have the
flexibility to meet that requirement
with an implementation of their choice
now as a quick side note there is a bit
of a gray area in terms of specifying
implementation with a requirement
it's not as straightforward as just
saying don't do it
if a particular implementation is
required
and you don't want flexibility in the
design then
it can be specified as a requirement for
example there might be some government
regulation that says that you can only
use
electric heating coils in a residential
toaster
in which case you would write this as a
requirement
but in general we try to stay away from
forcing a particular implementation
through requirements and just
focus on defining the characteristics
and features
of the design all right once we have
requirements that have been validated
and reviewed
we allocate them to an implementation
that is
we link the requirements to a particular
widget that they define the features of
and conversely the widget design traces
back to the requirements that it
implements
so we're left with a traceability map
that connects
the as designed system with the
requirements
this requirements tracing does at least
three things
it provides a way to audit the
requirement list to determine if
any were missed in the design it
provides a way to audit the
implementation and make sure that there
is a justification for each widget
and it provides a list of requirements
for a particular implementation
that can be used to design a
verification test
which we'll talk more about in the next
video
okay so now that we have a basic
understanding of what requirements are
and how they contribute to the design
process
the last thing i want to talk about in
this video is requirements
hierarchy requirements don't exist as a
single
disconnected entity but are often
grouped and
organized into a hierarchy lower level
or
child requirements refine the needs of
the parent requirement
and at the top level and near the
beginning of the program
we start with the key programmatic
requirements which formalize the
stakeholder needs
and then we flow those down to
functional requirements where we
determine the functions that the system
must accomplish
and then we create performance
requirements at the system level
and then begin flowing them down to
subsystems
and then to components and to parts
until we have a complete
set now your program might call these
levels by different names
but the idea is the same refine the
higher level requirements by writing
more detailed
lower level ones now you might be
thinking wait a second i thought you
said requirements
don't specify implementation then how
can we develop requirements for the
lower levels without
having an implementation well there's a
difference between
forcing an implementation through a
requirement and
defining the needs of a particular
chosen implementation
some design work and implementation
details need to be determined
in order to continue refining the
requirements
so we can think of it as an iterative
approach where the high level
requirements
allow the design team to investigate and
choose
a specific concept to pursue and once we
have a concept we can write
lower level requirements specific to
that concept
which allows the design team to further
refine the implementation
as an example in the last video we
talked about how a toaster could be a
residential toaster
or a commercial toaster or a camping
toaster
the high level needs of the stakeholder
drove us down the path
of creating a residential toaster this
was a concept
that we chose to pursue and once we
decided on this path we were able to
further refine the functional
requirements
we have a functional requirement that
the toaster must manage
and store the mechanical energy that is
generated when the bread
is lowered into the toaster this
requirement
only makes sense to levy on the design
for the residential toaster
so it's implementation specific but it
still
isn't forcing an implementation because
it's not telling us how to manage
and store mechanical energy
we may make a design choice to store the
mechanical energy in a spring
that's an implementation we've decided
on in which case we could write lower
level requirements for the spring that
state performance measures
like the maximum distance the spring can
travel and how much energy it needs to
store
this would give us an idea of what kind
of spring we need to design
or purchase so hopefully you can start
to see the back and forth between
further refining the requirements and
further refining
the design and stacking all of these
parent and child requirements together
forms a hierarchy you can see how spring
length and spring energy storage are
both
child requirements to managing
mechanical energy
and this hierarchy which we've already
alluded to can help us
with the validation effort the rationale
for a requirement could be determined by
showing that it's necessary
in order for the system to meet its
parent requirement
but again validation is more than just
looking at individual requirements
we have to think about validation as a
system and a hierarchy can help us with
that because we can look at the set of
requirements for a component
and determine if they are valid as a
group
we can see that they are complete that
is we're not missing a requirement in
the definition
we can see that they are consistent with
each other so that they don't contradict
or cause others to be infeasible and we
can see that they
are necessary that is we're not removing
flexibility
or forcing an inconsistency by over
constraining the design
okay so that's a quick overview of
requirements and the benefits of a
requirement hierarchy and traceability
however there is a larger story to be
told here
in the next video we're going to expand
on system verification and validation
and show how systems engineering and
requirements help
ensure that we built the right system
and we built it correctly
so if you don't want to miss that or any
other future tech talk videos don't
forget to subscribe
to this channel also check out my
channel if you're interested in other
control theory topics as well
thanks for watching and i'll see you
next time