Systems engineering best practices Model-bas ed requirement analysis.pdf

8/12/2019 Systems engineering best practices Model-bas ed requirement analysis.pdf

1/12

IBM Software Thought Leadership White Paper

Systems engineering best practices:Model-based requirement analysisBruce Powel Douglass, Chief Evangelist and Global Technology Ambassador, IBM


2/12

2 Systems engineering best practices: Model-based requirement analysis

Contents

2 The problem with requirements

3 It isnt 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 requirementsThe 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 fix-

tures, to ensure that the system conforms to the requirements

and that the system meets the customers need. After implemen-

tation, significant problems are traced back to poor require-

ments, 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 qualityof 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.


3/12

3IBM Software

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 customers needs.

In fact, during the development effort, problems with require-

ments 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 wouldnt it be better not

to have these defects in the first place? And even more impor-

tantly, wouldnt it be useful to know that implementing the

requirements will truly result in a system that actually meets the

customers needs?

Law of Douglass 71: The best way not tohave defects in the system is not to put themthere in the first place.

All this boils down to two concerns: ensuring that the require-

ments are good (complete, consistent, accurate and correct)

and that they reflect the customers needs. And, the goal is do

thisbeforedesign and implementation are underway.

It isnt obviousImagine youre 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/12


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 understandfrom those requirementswhether 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, mathe-

matically) analyze or simulate them. They dont rely simply

on hundreds or thousands of detailed textual statements about

the house.

Most systems that Im 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 calledverification. Showing that the solution meets the needs

of the customer is calledvalidation. 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.


5/12

5IBM Software

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 interpreta-

tion) and imprecise (difficult to quantify) and cannot be simu-

lated, executed or mathematically analyzed. Text is a great

way to explainwhyyou 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

requirementsThe agile adage of never be more than minutes away from

demonstrating that the work youre doing is right applies

to all work products, not just software source code. Its easy to

understand how youd 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 state-

ment of what kinds of things are, in principle, verifiable; these

are things that you can directly run, either through simulationor 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 beforeyou go design and

construct them.


6/12


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. Usesequence diagramsto 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. Constrainelements of the scenarios to add qualities of services,

such as performance, safety and reliability.

5. Construct a normative (and executable)state machinethat is

behaviorally equivalent to that set of scenarios.

6. Add trace linksfrom 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 byshowing 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.


7/12

7IBM Software

Constructing the executable use caseSome 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 state-

ments of behavior by which the required input output control

and data transformations of the system are characterized. Its 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 (nomi-

nally 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 forthe 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/12


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 doesnt 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 Im

beating too slowly

and in AAI mode.

:Physician :AAI Pacing mode :Heart

Refractory

Refractory

Pacing

Sensing

disableCurrentFlow()


9/12

9IBM Software

Figure 3 shows a state machine that describes the required behavior.

Figure 3. Pacemaker AAI Mode Use Case State Machine

Pacing

Sensing

Idle

ReleasingCurrenttm(RefactoryhTime)/

enableSensor();

evBeat

tm(PulseRateTime)/

disableSensor();

enableOutput(PulseAmplitude);

tm(PulseWidth)/

disableOutput();

/disableSensor();

disableOutput();

gotoPacing

gotoOff

{}PulseWidth

Nominal: 10msRange: [1 .. 20]

{}

PulseAmplitudeNominal: 20mV

Range: [10 .. 100]

{}

RefactoryTime

Nominal: 150ms

Range: [50 .. 250]

Off

{}

Wait Time derived

from pacing Rate

Nominal: 80 bpm

Range: [40 .. 120]


10/12


Of course, this is a simple model, but it can actually run, which

means that you can then verifythat 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 mustfirst 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 linksthat every requirement allocated to the use

case is represented in at least one scenario along with thenormative 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 input-

output 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 incomingevents 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 notthe 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 youve done is clearly and unambiguously state what a

correctly designedsystem must do. This kind of model is known

as aspecification modeland does not model the design.


11/12

11IBM Software

Validating the requirementsValidation 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 youve 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 require-

ment document, youd have to search, page by page, for some

indication that what you specified would happen. With an exe-

cutable requirement specification, you can simply say I dont

know. Lets 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?Ive consulted on hundreds of projects, almost all of which

were in the systems space, such as aircraft, spacecraft,

medical systems, telecommunications equipment, automobilesand the like. Ive 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 identifiedmany key requirements problems before they were discovered

by downstream engineering. The resulting requirements specifi-

cation 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.

SummaryBuilding a set of requirements is both daunting and necessary.

It is necessary because without it, projects will take longer

sometimes far longerand cost more. Requirement defects

are acknowledged to be the most expensive kind of defects

because they are typically discovered late (when youre supposed

to be done) and require significant work to be thrown away

and redone. It is a daunting task because textalthough expres-

siveis ambiguous and vague, and it is also difficult to demon-

strate 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 SystemsDevelopment.
https://www.youtube.com/watch?v=iNhsR_dh19khttps://www.youtube.com/watch?v=iNhsR_dh19k


12/12

For more informationTo learn more about IBM Rational solutions for modeling

requirements, contact your IBM representative or IBM Business

Partner, or visit the following website: http://www-03.ibm.com/

software/products/us/en/subcategory/SWV30

Additionally, IBM Global Financing can help you acquire the

software capabilities that your business needs in the most

cost-effective and strategic way possible. Well partner with

credit-qualified clients to customize a financing solution to

suit your business and development goals, enable effective

cash management, and improve your total cost of ownership.

Fund your critical IT investment and propel your business for-

ward with IBM Global Financing. For more information, visit:

ibm.com/financing

About the authorBruce Powel Douglass got his doctorate in Neurocybernetics

from the USD Medical School in 1984. Currently, he is the

Chief Evangelist for IBM Rational, and travels 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 pacemakers to next-generation

spacecraft. He has authored the DoDAF profile for the Rational

Rhapsody tool and a safety analysis profile for UML. He speaks

actively in the modeling and real-time communities, speaks atmany conferences and consults.

Copyright IBM Corporation 2013

IBM CorporationSoftware GroupRoute 100Somers, NY 10589

Produced in the United States of AmericaOctober 2013

IBM, the IBM logo, ibm.com, DOORS, Rational, and Rhapsody aretrademarks of International Business Machines Corp., registered in manyjurisdictions worldwide. Other product and service names might be

trademarks of IBM or other companies. A current list of IBM trademarksis available on the web at Copyright and trademark information atibm.com/legal/copytrade.shtml

This document is current as of the initial date of publication and may bechanged by IBM at any time. Not all offerings are available in every countryin which IBM operates.

It is the users responsibility to evaluate and verify the operation of anyother products or programs with IBM products and programs.

THE INFORMATION IN THIS DOCUMENT IS PROVIDEDAS IS WITHOUT ANY WARRANTY, EXPRESS ORIMPLIED, INCLUDING WITHOUT ANY WARRANTIESOF MERCHANTABILITY, FITNESS FOR A PARTICULARPURPOSE AND ANY WARRANTY OR CONDITION OFNON-INFRINGEMENT. IBM products are warranted according to the

terms and conditions of the agreements under which they are provided.

RAW14330-USEN-00

Please Recycle
http://www-03.ibm.com/software/products/us/en/subcategory/SWV30http://www-03.ibm.com/software/products/us/en/subcategory/SWV30http://www.ibm.com/financinghttp://www.ibm.com/financinghttp://www.ibm.com/legal/copytrade.shtmlhttp://www.ibm.com/legal/copytrade.shtmlhttp://www.ibm.com/financinghttp://www.ibm.com/financinghttp://www-03.ibm.com/software/products/us/en/subcategory/SWV30http://www-03.ibm.com/software/products/us/en/subcategory/SWV30http://www.ibm.com/legal/copytrade.shtml

Systems engineering best practices Model-bas ed requirement analysis.pdf

Documents

Transcript of Systems engineering best practices Model-bas ed requirement analysis.pdf