Sie sind auf Seite 1von 8

Systems engineering best practices: Model-bas ed requirement analysis

2 Systems engineering best practices: Model-based requirement analysis


Contents
2 The problem with requirements
3 It isn t obvious
5 A proposal: Verifiable and validatable requirements
7 Constructing the executable use case
10 Verifying the requirements
11 Validating the requirements
11 So does it really work?
11 Summary
12 About the author
The problem with requirements
The usual perception of the workflow for requirements approval
is that it starts by trapping a group of people in a room for
what can seem like eons until they approve the requirements.
Then the verified requirements are passed to a development
team, which can consist of engineers and others in many
different engineering disciplines, for design and implementation.
In parallel, a testing group writes the verification and validation
plan, which includes the test cases, test procedures and test fixtures,
to ensure that the system conforms to the requirements
and that the system meets the customer s need. After implementation,
significant problems are traced back to poor requirements,
so portions of the design and implementation are
thrown away and redone, resulting in projects that are late
and over budget.
The key problem with this workflow is that the design and
implementation are started and perhaps even finished without
any real assurance about the quality of the requirements. The
actions that determine that the requirements are, in fact,
complete, accurate, consistent and correct are deferred until
implementation is complete. So, if the requirements are flawed,
usually this is not discovered until after implementation, and
unplanned resources and time are spent to fix errors and issues,
which results in late and over-budget projects. Such a discovery
can even happen after a release, which can lead to customer
dissatisfaction, recalls and, occasionally, litigation. This is a
huge cost and one that happens increasingly often as the
complexity of IT systems burgeons and reliance on these
systems continues to rise.
IBM Software 3
The fundamental assumption is that requirements are correct
and complete statements of what the system must do and how
well it must do it. However, this assumption is rarely backed by
evidence. In addition, the assumption also does not take into
account whether the requirements meet the customer s needs.
In fact, during the development effort, problems with requirements
commonly emerge. Requirements can be incomplete,
lacking details about necessary functions or performance.
They are often inconsistent with one set of requirements
subtly violating the specification in another. And requirements
are sometimes just wrong. When such problems are identified,
the discovery typically kicks off a change request effort and an
update to the requirements, resulting in the modification of the
system design and implementation. But wouldn t it be better not
to have these defects in the first place? And even more importantly,

wouldn t it be useful to know that implementing the


requirements will truly result in a system that actually meets the
customer s needs?
Law of Douglass 71: The best way not to
have defects in the system is not to put them
there in the first place.
All this boils down to two concerns: ensuring that the requirements
are good (complete, consistent, accurate and correct)
and that they reflect the customer s needs. And, the goal is do
this before design and implementation are underway.
It isn t obvious
Imagine you re building a house for your family. You engage
an architect who comes back to you after three months with a
657-page specification with statements such as:
?? Indented by 7 meters from the west border of the premises,
there shall be the left corner of the house.
?? The entrance door shall be indented by another
3.57 meters.
?? 2.30 meters wide and 2.20 meters high, there shall be a
left-hand hinge, opening to the inside.
?? As you come in, there shall be two light switches and a
socket on your right, at a height of 1.30 meters.
4 Systems engineering best practices: Model-based requirement analysis
Is this the house you want to live in? How would you know?
The architect might present you with 6500 such requirements
that describe the house, but you, and almost any human, would
be unable to understand from those requirements whether this is
the house you want. For example:
?? Is the house energy efficient?
?? Does the floor plan work for your family or must you go
through a bathroom to get to the kitchen?
?? Is it structurally sound?
?? Does it let in light from the southern exposure?
?? Is the pond behind the house clearly visible?
?? Does it look nice?
Architects build models that support the reasoning necessary
to answer these questions. Then they formally (that is, mathematically)
analyze or simulate them. They don t rely simply
on hundreds or thousands of detailed textual statements about
the house.
Most systems that I m involved with developing are considerably
more complex than a house and have requirements that are both
more technical and abstract. Nevertheless, I still have the same
basic needs: understanding how the requirements fit together
and the reasoning for the emergent properties of the system.
Demonstrating that the implementation meets the stated
requirements, or, in simpler terms, building the system right,
is called verification. Showing that the solution meets the needs
of the customer is called validation. System verification, in the
presence of requirement defects, is an expensive proposition,
largely due to the rework it entails. Implementation defects are
generally easier and less expensive to repair but the scope of the
rework for requirement defects is usually far greater. Research
has shown that, during the development of embedded systems,
more than 50 percent of the cost is spent on the verification of
those systems and that requirement defects heavily contribute
to that cost.
Validation is potentially an even more expensive concern because
not meeting the customer need is usually not discovered until
the system is in the hands of the customer. Requirement defects

are usually hundreds of times more expensive to repair than


implementation defects because the problems are introduced
early, identified late in the project and require you to throw away
existing work, redesign and re-implement the solution, then
integrate it into the system without breaking anything else.
IBM Software 5
Premise:
You can only verify things that run.
Conclusion:
Build only things that run.
Solution:
Build executable requirements
models to support early
requirements verification.
Figure 1. The core concept
Underpinning most of the difficulties of requirements is the
fact that they are usually captured as textual statements. Textual
statements are ambiguous (subject to more than one interpretation)
and imprecise (difficult to quantify) and cannot be simulated,
executed or mathematically analyzed. Text is a great
way to explain why you want to do something or qualitatively
characterize something, but text is insufficient when you
want to be clear, unambiguous and demonstrably complete.
A proposal: Verifiable and validatable
requirements
The agile adage of never be more than minutes away from
demonstrating that the work you re doing is right applies
to all work products, not just software source code. It s easy to
understand how you d do that with source code (run and test it).
But how do you do that with requirements?
Figure 1 shows the core concept. You start with a basic statement
of what kinds of things are, in principle, verifiable; these
are things that you can directly run, either through simulation
or execution. The conclusion is, then, that you should build such
things when verification is desired. The solution to the problem
is then obvious: build requirements specifications that run
so that you can verify them before you go design and
construct them.
6 Systems engineering best practices: Model-based requirement analysis
If you can build models of the requirements, you can verify and
validate them before handing them off to the design team. The
recommend work flow is:
1. Organize requirements into use cases (user stories work,
as well).
2. Use sequence diagrams to represent the required sequences of
functionality for the set of requirements allocated to the use
case (scenarios).
3. Clearly identify the assumptions of the scenarios and add
other scenarios to deal with situations where they are violated.
4. Constrain elements of the scenarios to add qualities of services,
such as performance, safety and reliability.
5. Construct a normative (and executable) state machine that is
behaviorally equivalent to that set of scenarios.
6. Add trace links from the textual requirements statements to
elements of the use case model:
a. Messages and behavior in scenarios
b. Events (for messages from actors), actions (for messages to
actors and internal behavior) and states (conditions of the
system) in the state machine
7. Verify that requirements are consistent, complete, accurate

and correct.
8. Validate the requirements model with the customer by
showing them the executing models.
When problems are identified with the requirements during this
functional use case analysis, they can be easily and inexpensively
fixed before any design or implementation is thrown away
and redone.
IBM Software 7
Constructing the executable use case
Some people are confused by the fundamental notion of using
a state machine to represent requirements, thinking that state
machines are inherently a design tool. State machines are just
a behavioral specification, and requirements are really just statements
of behavior by which the required input ? output control
and data transformations of the system are characterized. It s a
natural fit.
Consider the set of user stories for a cardiac pacemaker:
?? The pacemaker may be off (not pacing or sensing) or
executing the pacing mode of operation).
?? The cardiac pacemaker shall pace the atrium in Inhibit mode;
that is, when an intrinsic heart beat is detected at or before the
pacing rate, the pacemaker shall not send current into the
heart muscle.
?? If the heart does not beat by itself fast enough, as determined
by the pacing rate, the pacemaker shall send an electrical
current through the heart by means of the leads at the voltage
potential specified by the pulse amplitude parameter (nominally
20mv, range [10..100]mv) for the period of time specified
by the pulse length (nominally 10ms, range [1 .. 20]ms).
?? The sensor shall be turned off before the pacing current is
released.
?? The sensor shall not be reenabled following a pace for
the period of time it takes the charge to dissipate to avoid
damaging the sensor (nominally 150ms, setting range is
[50..250]ms). This is known as the refractory time.
?? When the pacing engine begins, it will disable the sensor and
current output; the sensor shall not be enabled for the length
of the refractory time.
8 Systems engineering best practices: Model-based requirement analysis
A scenario of use is shown in Figure 2.
Figure 2. Pacemaker scenario
enable( )
tm(REFRACTORY_TIME)
enableSensor( )
atrialBeat( )
atrialBeat( )
tm(PACE_TIME)
tm(PULSE_TIME)
enableCurrentFlow( )
atrialPace( )
Heart doesn t beat fast enough
this time, so pacemaker steps in
and paces the heart.
Heart beats on its own fast
enough to avoid triggering the
pace timeout.
User Story:
I want to receive
pacing pulses to my
right atrium if I m

beating too slowly


and in AAI mode.
:Physician :AAI Pacing mode :Heart
Refractory
Refractory
Pacing
Sensing
disableCurrentFlow( )
IBM S 9 oftware
Figure 3 shows a state machine that describes the required behavior.
Figure 3. Pacemaker AAI Mode Use Case State Machine Pacing
Sensing
Idle
ReleasingCurrent
tm(RefactoryhTime)/
enableSensor( );
evBeat
tm(PulseRateTime)/
disableSensor( );
enableOutput(PulseAmplitude);
tm(PulseWidth)/
disableOutput( );
/disableSensor( );
disableOutput( );
gotoPacing
gotoOff
{??}
PulseWidth
Nominal: 10ms
Range: [1 .. 20]
{??}
PulseAmplitude
Nominal: 20mV
Range: [10 .. 100]
{??}
RefactoryTime
Nominal: 150ms
Range: [50 .. 250]
Off
{??}
Wait Time derived
from pacing Rate
Nominal: 80 bpm
Range: [40 .. 120]
10 Systems engineering best practices: Model-based requirement analysis
Of course, this is a simple model, but it can actually run, which
means that you can then verify that it is correct and you can use
it to support validation with the customer. You can examine
different sequences of incoming events with different data
values and look at the outcomes to confirm that they are what
you expect.
Verifying the requirements
For the verification of consistency of requirements, you must
first decide what inconsistent means. I believe that inconsistent
requirements manifest as incompatible outcomes in the same
circumstance, such as when a traffic light would be red because
of one requirement but at the same time must also be green to
meet another. Because the execution of the requirements model
has demonstrable outcomes, you can run the scenarios that
represent the requirement and demonstrate that all expected

outcomes occur and that no undesired consequences arise.


For the verification of completeness, you can first demonstrate
with trace links that every requirement allocated to the use
case is represented in at least one scenario along with the
normative state machine. Secondly, the precision of thought
necessary to construct the model naturally raises questions
during its creation. What happens if the system is this state and
then that occurs? What happens if that data is out of range?
How quickly must this action occur? Have all of the scenarios
been created and all of the operational variants been considered?
Answering these questions will result in the addition of new
requirements or the correction of existing ones.
For correctness, I mean that the requirement specifies the
proper outcome for a given situation. Such a specification is
usually a combination of preconditions and a series of inputoutput
event sequences that result in a specified post-condition.
With an executable use case model, you use a test that shows
that, for each situation, you have properly specified the output.
You can do the same scenario with different data values to ensure
that boundary values and potential singularities are properly
addressed. You can change the execution order of incoming
events to ensure that the specification properly handles all
combinations.
Accuracy is a specific kind of correctness that has to do with
quantitative outcomes rather than qualitative ones. For
example, if the outcome is a control signal that maintains an
output that is proportional to an input (within an error range),
you can run test cases to ensure that the specification actually
achieves that. You can execute the transformational logic in
the requirements and formally (mathematically) analyze it if
you wish.
Be aware that this use case model is not the implementation.
Even if the system use case model is functionally correct and
executes properly, it is not operating on the desired delivery
platform (hardware) and has not been optimized for cost,
performance, reliability, safety, security and other kinds of
quality-of-service constraints. In fact, it has not been designed
at all. All you ve done is clearly and unambiguously state what a
correctly designed system must do. This kind of model is known
as a specification model and does not model the design.
IBM Software 11
Validating the requirements
Validation refers to confirming that the system meets the needs
of the customer. Systems that meet the requirements can fail to
provide value to the customer because:
?? The customer specified the wrong thing.
?? The requirements missed some aspect of correctness,
completeness, accuracy or consistency.
?? The requirements were captured incorrectly or ambiguously.
?? The requirements, although correctly stated, were
misunderstood.
The nice thing about the executable requirement model is that
you can demonstrate what you ve specified to the customer, not
as pile of dead trees to be read over a period of weeks but instead
as a representation that supports exploration, experimentation
and confirmation. You might have stated what will happen if
the physician flips this switch, turns that knob and then pushes
that button, but what if the physician pushes the button first?
What has been specified in that case? In a traditional requirement
document, you d have to search, page by page, for some

indication that what you specified would happen. With an executable


requirement specification, you can simply say I don t
know. Let s try it and found out. This means that the executable
specification supports early validation of the requirements so
that you can have a much higher confidence that the customer
will be satisfied with the resulting product.
So does it really work?
I ve consulted on hundreds of projects, almost all of which
were in the systems space, such as aircraft, spacecraft,
medical systems, telecommunications equipment, automobiles
and the like. I ve used this approach extensively with the
IBM Rational Rhapsody toolset for modeling and
Rational DOORS for managing the textual requirements.
My personal experience is that using these solutions results
in far higher quality in terms of requirements and a shorter
development time with less rework and happier customers.
By way of a public example, I was involved in the development
of the Eaton Hybrid Drivetrain project (see the YouTube video
here https://www.youtube.com/watch?v=iNhsR_dh19k). On this
project, we did this kind of use case functional analysis by
constructing executable use cases, and this analysis identified
many key requirements problems before they were discovered
by downstream engineering. The resulting requirements specification
was far more complete and correct after this work was
done than in previous projects, meaning that the development
team spent less time overall on the project.
Summary
Building a set of requirements is both daunting and necessary.
It is necessary because without it, projects will take longer
sometimes far longer and cost more. Requirement defects
are acknowledged to be the most expensive kind of defects
because they are typically discovered late (when you re supposed
to be done) and require significant work to be thrown away
and redone. It is a daunting task because text although expressive
is ambiguous and vague, and it is also difficult to demonstrate
its quality. However, by building executable requirement
models, the quality of the requirements can be greatly improved
with minimal cost and effort.
For more detail on my approach and specific techniques, you
can find more information in my books, Real Time UML
Workshop for Embedded Systems and Real-Time Agility: The
Harmony/ESW Method for Real-Time and Embedded Systems
Development.
For more information
To learn more about IBM Rational solutions for modeling requirements, contact yo
ur IBM representative or IBM Business Partner, or visit the following website: h
ttp://www-03.ibm.com/software/products/us/en/subcategory/SWV30Additionally, IBM
Global Financing can help you acquire the software capabilities that your busine
ss needs in the most cost-effective and strategic way possible. W e ll partner wit
h credit-qualified clients to customize a financing solution to suit your busine
ss and development goals, enable effective cash management, and improve your tot
al cost of ownership. Fund your critical IT investment and propel your business
for-ward with IBM Global Financing. For more information, visit: ibm.com/financi
ng
About the author
Bruce Powel Douglass got his doctorate in Neurocybernetics from the USD Medical
School in 1984. Currently, he is the Chief Evangelist for IBM Rational, and trav
els the globe to share his knowledge with other developers and modelers. He has
con-tributed to a number of standards, such as UML and SysML, and consulted with
high-tech embedded software developers to build everything from cardiac pacemak

ers to next-generation spacecraft. He has authored the DoDAF profile for the Rat
ional Rhapsody tool and a safety analysis profile for UML. He speaks actively in
the modeling and real-time communities, speaks at many conferences and consults
.
Copyright IBM Corporation 2013IBM Corporation Software Group Route 100 Somers, N
Y 10589Produced in the United States of America October 2013IBM, the IBM logo, i
bm.com, DOORS, Rational, and Rhapsody are trademarks of International Business M
achines Corp., registered in many jurisdictions worldwide. Other product and ser
vice names might be trademarks of IBM or other companies. A current list of IBM
trademarks is available on the web at Copyright and trademark information at ibm.c
om/legal/copytrade.shtmlThis document is current as of the initial date of publi
cation and may be changed by IBM at any time. Not all offerings are available in
every country in which IBM operates.It is the user s responsibility to evaluate a
nd verify the operation of any other products or programs with IBM products and
programs.THE INFORMATION IN THIS DOCUMENT IS PROVIDED AS IS WITHOUT ANY WARRANTY,
EXPRESS OR IMPLIED, INCLUDING WITHOUT ANY WARRANTIES OF MERCHANTABILITY, FITNESS
FOR A PARTICULAR PURPOSE AND ANY WARRANTY OR CONDITION OF NON-INFRINGEMENT . IB
M products are warranted according to the terms and conditions of the agreements
under which they are provided.
RAW14330-USEN-00 Please
Recycle

Das könnte Ihnen auch gefallen