Four principles seminar manageware seminar

®

IBM Software Group

Ensuring Project Success:
Four Principles for Effective
Requirements Lifecycle Management
Dr. Keith Collyer
Requirements Product Delivery Team
keith.collyer@uk.ibm.com

© 2008 IBM Corporation

Although we use screenshots from DOORS to illustrate many of the points in this
presentation, DOORS is not the focus.

IBM Software Group | Rational software

Our world is becoming more complex everyday...

162 million 90% 1 trillion
Almost 162 million smart phones Nearly 90% of innovation Soon, there will be 1 trillion
were sold in 2008, surpassing in automobiles is related to connected devices in the world,
laptop sales for the first time. software and electronics constituting an “internet of things.”
systems.


...and the challenge of managing this complexity has never
been greater

48 months $300 billion 42,000
Five years ago, a typical units recalled
manufacturer’s concept-
66% of software products are More than 42,000 defibrillators
through production cycle time
deemed unsuccessful, costing had to be recalled in 2007 due
was 48 months. Within four
the industry nearly $300 billion to faulty software.
years, that time dropped
annually.
to 18 months—with a goal
of reaching a 12 month cycle
within the next year.

Development timescales are tighter than ever before, but the regulations and standards
developers must meet are more stringent than ever.

The cost of failure is increasing at a fantastic rate


4 Principles for Effective Requirements Lifecycle
Management
Recognize the needs of all stakeholders

N

Automate your Use abstraction to
requirements process W E manage complexity

S
Integrate requirements across the lifecycle

We could choose many ways of dividing up the topic of requirements management. We
will use four main principles as our guide.
Recognize the needs of all stakeholders
Understand the problem as much as the solution
Effective requirements writing and requirement document structure
Use abstraction to manage complexity
Requirement decomposition and derivation
The necessity of traceability
Integrate requirements across the lifecycle
Requirements are the primary communication tool across the whole development
lifecycle
RM + Design + Testing + Change + PLM
Automate your requirements process
Apply measures to facilitate process improvement
Use a Requirements Management tool

Principle 1: Recognize the needs of all stakeholders

Avoid Premature Details at Top Levels

Problem Solution

State what the State what the
stakeholders system must do:
want to be able to Function
do: Capabilities

We use many conceptual processes in developing systems. We can think of these
processes as:
Define the problem: Why are we doing this?
Define the solution: What do we need to do?
Design the solution: How are we going to do it?
These processes can occur in parallel, top-down, bottom-up or in a mixed fashion. And
one person's solution can become another person's problem, so systems development is
generally a recursive process.
It is important that the “levels” of development are related – in the sense that the solution
developed must solve the problem stated.


Avoid Premature Details at Top Levels

Problem Solution

Do not design Do not define
the system the design –
avoid How

We use many conceptual processes in developing systems. We can think of these
processes as:
Define the problem: Why are we doing this?
Define the solution: What do we need to do?
Design the solution: How are we going to do it?
These processes can occur in parallel, top-down, bottom-up or in a mixed fashion. And
one person's solution can become another person's problem, so systems development is
generally a recursive process.
It is important that the “levels” of development are related – in the sense that the solution
developed must solve the problem stated.


An Exercise in clear and concise descriptive writing?

The system shall perform at the maximum rating at all
times except that in emergencies it shall be capable of
providing up to 125% rating unless the emergency
condition continues for more than 15 minutes in which
case the rating shall be reduced to 105% but in the
event that only 95% can be achieved then the system
shall activate a reduced rating exception and shall
maintain the rating within 10% of the stated values for a
minimum of 30 minutes.

Don’t attempt to get it right first time – Richard Stevens “if a job’s worth doing, it’s worth
doing badly”
Clear: each statement is clearly understandable and in the appropriate terminology
Consistent: The requirement is consistent with other requirements
Abstract: does not impose a solution on the next layer
Correct: correctly reflects the intent
Individual: each statement is a single traceable element
Testable: each requirement has acceptance criteria and can be validated/verified
Feasible: each requirement is physically and legally possible
Prioritised: each requirement has a priority associated
Justified: each requirement has a rationale explaining how it satisfies input needs


Document Structure

Structure helps:
Understand context
Assess completeness
Identify repetition/conflict
Navigate/search requirements

Small projects can get away with work-item lists as dealing with a few tens of
requirements is within the scope of a human mind.

Larger projects need some structure. Structure helps us to:
Understand the context of requirements by placing similar requirements together in a
hierarchical framework
Assess the completeness of the requirements set, for example by using a template and
highlighting empty sections
Identify repetition/conflict as requirements for similar subjects will be placed close together
Navigate/search requirements by providing a decomposition structure which enables
successive refinement to find necessary information


Structure and Templates

Document
Structure

Boiler-plate
text
Requirement
templates
Project templates

A template may contain different levels of information:
Simple heading structure
Boilerplate text that is always similar for every module based on this template
Requirement templates to help support good requirement writing practices
Project templates combine multiple document templates in a structured fashion, ideally
also including definition of allowed relationships


Attributes

Identification Type

Performance

Priority Status

Attributes are used for several things:
Identification: Any form of label, normally an alphanumeric string (for example an object
identifier)
Classification by type: e.g. functional, non-functional, legal, constraint
Classification by priority: e.g. 1,2,3 or high, medium, low
Status: e.g. approved, validated, rejected, changed. Status attributes should have a
documented state machine
Performance: test results, data rates, any numerical data

PrincipleSoftware Group | Rational software manage complexity
IBM 2: Use abstraction to

Keep information at the right level

Look before you leap!
General rule: Provide as much information as needed – but no more
Avoid design at early stages
Be aware of when you are:
► Defining the problem
► Defining the solution It i s
n't t
Designing the solution solut hat
►
i on i they
the t's t can'
pr ob hat t se
lem they e th
G.K. can' e
Ches t se
e
terton

This relates back to the discussion of problem and solution. It can be very dangerous, and
is certainly inefficient and generally over-restrictive, to create solutions when the problem
is not understood.
Customers often state how they want a problem to be solved, frequently without any clear
view of what the problem actually is. The best response to this tendency is to ask “Why?”
enough times to get to the real (sometimes called “The 5 Whys”)


Building a Requirements Hierarchy

Decomposition
Design-driven

•Transformation Allocation

Many processes are needed to build up requirements sets
Decomposition:
Decompose requirements into parts
Break compound requirements into atomic statements

Design-driven (also called “derived”):
Create new requirements to take into account higher-level design decisions
For example, the design decision to have a separate Engine and Gearbox
leads to the need for those subsystems to interact, and those
interactions are defined by requirements

Transformation:
Turn vague statements into precise statements
Turn problem statements into solution statements
Turn stakeholder-oriented capabilities into system-oriented functions

Allocation:
Allocate requirements to subsystems. Often hand-in-hand with decomposition
E.g. Allocate “car moves” to engine, drive train, steering, ...


Why is Traceability Important?

Why are we building this?

Where is this implemented?

How do I test this?

Can we show these
answers? (Governance)

Traceability information lets us answer important questions asked by stakeholders,
developers, testers, managers, etc.

Necessity: are all the traced lower-level requirements necessary to satisfy the higher-
level? Ensure that there is no gold-plating. Why are we building this?

Sufficiency: are the traced lower-level requirements sufficient to satisfy the higher-level?
Ensure that system developed satisfies requirements. Where is this implemented?

Both the above apply to testing as well as to development. How do we test this?

Impact: what other changes are contingent on those proposed (up, down and
horizontally). Analyze proposed changes. Can we show these answers?

Principle 3: Group | Rational software
IBM Software Integrate RM across the lifecycle

RM across the Enterprise

Corporate
Vision
Board

Portfolio and
Program
Management
Program Managers

Project
Management,
Requirements
Project Managers, Analysts and Management
Requirements Engineers
Requirements
Use, Development
Tools

Developers

Different levels in the enterprise use requirements in different ways and hence have
different needs for RM. It is important that the corporate vision is reflected through all
levels – very few organizations have the understanding, knowledge or tools to do this.
The corporate vision is about satisfying stakeholders (typically shareholders)
The program portfolio defines what must be achieved to meet the vision and high-level
targets such as time and budget.
Projects are created to deliver results to the overall portfolio. This is where Requirements
Management is traditionally seen to start.
The Development organizations consume and produce requirements to actually build
systems


Requirements Definition & Management
Must Be Integrated into the Product Lifecycle
Define Define Product / Product / Run /
Customer Develop Preliminary Detail
Operation System System System Support / Disposal
Needs Reqt’s Reqt’s Concept Definition Definition Deliver Maintain
Build

Business Analysis: Enterprise Architecture, Business Process Mgmt, Product Mgmt, Portfolio Mgmt
Program & Project Management: Cost Accounting, Scheduling, Measurements, Reporting, Risk Mgmt
Requirements Management
Detailed Design and Implementation

Mechanical
Engineering

Electronics
Engineering

Software
Engineering

Integration

Verification and Validation – Test Management

Change and Configuration Management

The important message here is that development is not done in isolated silos, but by
many disciplines working together. The common thread for all this work is requirements.
Requirements Management applies to all aspects of development and across the whole
product lifecycle, even through to disposal.
Requirements are the principle means of communicating between different disciplines and
that they are the only technical information that persists throughout the whole life


Standards Project
Constraints Plan Rev B
Project
Plan Rev A
Stakeholder
Requirements Test
Cases

Use Cases
Modeling
tool

Test
Results
System Test
Requirements Cases

Test Defects
Functional Cases
Modeling Models ICD
ICD
tool ICD Data Synchronized

Sub-System
Sub-System
Sub-System
Requirements
Requirements
Requirements RQM

Potentially Potentially to any Module
Glossary
from any doc

CRs

Change
Design
tool

This slide shows an example information architecture. We build it up by showing the way
requirements flow through levels, then show how additional information is related

Principle 4: Automate your requirements process

Measure the requirements process

CMMI, ITIL and other process assessment frameworks expect measurement
► CMMI needs RM to get to level 2
► Need measurement to understand efficiency and consistency
► Key to continuous process improvement

"In physical science the first essential step in the direction of learning any subject is to find
principles of numerical reckoning and practicable methods for measuring some quality
connected with it. I often say that when you can measure what you are speaking about,
and express it in numbers, you know something about it; but when you cannot measure it,
when you cannot express it in numbers, your knowledge is of a meagre and
unsatisfactory kind; it may be the beginning of knowledge, but you have scarcely in your
thoughts advanced to the state of Science, whatever the matter may be."

Lord Kelvin, 1893

CMMI & ITIL are assessment frameworks used in industry and IT development


Effective Requirements Management realizes quantifiable
savings
and with a tool you are able to measure
Example: how to measure and
results
Development releases consisting of typically 8000
requirements used to take 6 months
Phase 1 - Application of robust process and tool
enforcement reduced this period to 12 Weeks over a
period of 1 year
Phase 2 - Continuous process improvement for a
further 12 months reduced this period to 6 weeks
Over time, defect removal and effectiveness was
55% at phase 1, 88% at phase 2 and still improving
Defects undetected end up with the customer – the
figures represent huge improvements in cost of re-
work, quality and customer satisfaction


Use a Requirements Management Tool
Document structure Attributes Filter to focus

View related information View historical information

Using a requirements management tool gives you many advantages over using standard
office applications:
Information can be viewed in many ways, including document structure
Attributes can be defined to suit the processes in an organization
Filters can be used to focus on specific requirements according to user-defined criteria
Information can be linked in various ways and related information displayed
Historical information is recorded and can be displayed
All these different types of information can be displayed at the same time


Benefits of Effective Requirements Lifecycle Management

Greater Confidence

Ability to manage change

Improved customer/supplier
relations

Visibility of progress/status

Improved Cost / Benefit
Decisions

Greater confidence that objectives are being met. Organizing and tracing requirements
engenders greater reflection on the design process and makes the design rationale more
explicit.
Ability to manage change through impact analysis. Requirements tracing allows the
potential impact of changes to be assessed more rapidly.
Improved customer / supplier relations through better definition and understanding of
contracts, a large part of which are requirements.
Ability to track progress / status particularly in the formative stages of a project. When all
that the project team is doing is writing documents, it is sometimes hard to measure
progress. Effective requirements management puts measurable processes in place.
Ability to save costs through cost / benefit analysis. Again, requirements tracing is a way
of documenting the relationship between benefits (as expressed by the requirements) and
cost (as expressed by the design).

®

IBM Software Group

Addendum:
Avoiding Requirements
Writing Pitfalls

© 2008 IBM Corporation

Using a requirements management tool gives you many advantages over using standard
office applications:
Information can be viewed in many ways, including document structure
Attributes can be defined to suit the processes in an organization
Filters can be used to focus on specific requirements according to user-defined criteria
Information can be linked in various ways and related information displayed
Historical information is recorded and can be displayed
All these different types of information can be displayed at the same time


Characteristics of a Good Requirement

Design-Free
Consistent
Traceable
Complete
Individual
Verifiable
Identified
Feasible
Modular
Positive
Correct
Unique
Clear

Positive Modular Design-Free

Traceable Feasible

Consistent Clear Verifiable

Correct Complete

Unique Individual Identified

Individual each requirement is a single traceable element
Unique each statement is different
Identified each statement has a unique reference for
identification purposed e.g. “PQR 345”
Correct Correctly represents the parent requirement
Complete Express a whole idea or statement
Clear Unambiguous simple language to avoid
confusion and ambiguity
Consistent Not in conflict with other requirements
Verifiable It can be determined that the system meets the
requirement
Traceable Uniquely identified and can be tracked and traced
Feasible Can be accomplished within cost and schedule
Modular Can be changed without excessive impact
Positive Written in the affirmative, not the negative
Design-Free Does not impose a specific solution on design
(i.e., implementation free)


Anatomy of a Good Stakeholder Requirement

“The internet user shall be able to access their
“The internet user shall be able to access their
current account balance in less than 5 seconds.”
current account balance in less than 5 seconds.”

Measurable (but from when?)
Performance criteria
Positive end result
user type

The challenge is to seek out the user type, end result,
The challenge is to seek out the user type, end result,
and success measure in every requirement you
and success measure in every requirement you
define.
define.

r572


Writing Pitfalls to Avoid

… or …
… etc.
… shall include but not be limited to …

Example: “The pilot and/or co-pilot shall also be able
to hear or see a visible or audible
caution/warning signal incase of emergency,
hazard, etc…”

Improvements:

Ambiguity
Ambiguity

Have individual and specific requirements for the pilot and co-pilot.
Create single requirements for visual and audible parts.
Be specific on what emergency or hazard conditions will be reported.



each requirement is a single sentence
conjunctions
…and… , …or…. , …with… , …also…

Example: “The user shall be notified with a low battery
warning lamp light when the voltage drops
below 3.6 Volts and the current workspace
or input data shall be saved.”

Improvements:

Multiples
Multiples

Make separate stakeholder requirements.
“The operator shall be visually notified when the voltage drops
to a level where work cannot continue.”
“The operator shall be able to recover all data after a power
failure.”
Make separate system requirements:
“The system shall provide a low battery warning lamp light
when the voltage drops below 3.6 Volts.”
“The system shall save the current workspace when the
voltage drops below 3.6 Volts.”



‘let out’ clauses
…if… , …but… , …when… , …except…
…unless… , …although….

Example: “The homeowner shall always hear the
smoke detector alarm when smoke is
detected unless the alarm is being tested or
suppressed.”

Improvements:

Escape Clauses
Escape Clauses

”The homeowner shall hear the alarm when smoke is detected.”
“The homeowner shall be able to suppress the sound generated by
the fire alarm when the alarm is in ‘Test’ mode.”



long sentences
arcane language
references to unreachable documents

Example: “Provided that the designated input signals
from the specified devices are received by
the user in the correct order where the
system is able to differentiate the
designators, the output signal shall comply
Improvements: with the required framework of section 3.1.5
to indicate the desired input state.”
Rambling
Rambling

“The user shall receive an output signal in compliance section 3.1.5.”
“The user shall receive the output signal indicating desired input
state.”



mix user, system, design, test, installation
high level mixed with database design,
software terms, technical terms

Example: “The user shall be able to view the currently
selected channel number which shall be
displayed in 14pt Swiss type on an LCD
panel tested to Federal Regulation Standard
567-89 and mounted with shockproof rubber
Improvements: washers.”

Mixing Requirements
Mixing Requirements

“The user shall be able to view the currently selected channel
number.”
“The system shall display the selected channels on an LCD Panel.”
“The LCD Panel shall be shockproof mounted.”
“The LCD Panel shall be tested to Federal Regulation Standard 567-
89”



specify design envelope for level required
name components, materials, software
objects, fields, records in stakeholder or
system requirements
Example: “The antenna shall be capable of receiving
FM signals, using a copper core with nylon
covering and a waterproof hardened rubber
shield”

Improvements:

Designing
Designing

“The antenna shall be capable of receiving FM signals.”



wish lists
vague about which stakeholder is speaking
…usually… , …generally… , …often… ,
…normally… , …typically…
Example: “The alarm system will probably have to
operate over normal phone lines.”

Improvements:

Speculation
Speculation

“The alarm system shall operate over the household’s standard
telephone line.”



qualitative terms
user friendly, highly versatile, flexible
to the maximum extent, approximately, as
much as possible, minimal impact.
Example: “The user shall be provided with a user-
friendly front-end.”

Improvements:

Vagueness
Vagueness

“The user shall be guided through the system with navigation aids and
dialog displays.”
“The user shall be guided to the next step with labeled instructions.”
“The user shall be provided with context sensitive help display.”



suggestions will be ignored by developers
may, might, should, ought, could,
perhaps, probably

Example: “The network manager may be provided
with possible network contention points and
should instantaneously re-route the traffic.”

Improvements:

Suggestions and Possibilities
Suggestions and Possibilities

Deliberately use the verbs “shall” or “will” to signal a requirement.
Attempt to make each requirement realistic and achievable!



ask for the impossible
100% reliable, safe, handle all failures,
fully upgradeable, run on all platforms

Example: “The network manager shall handle all
unexpected errors without crashing the
system and be fully capable of managing
future network configurations.”

Improvements:

Wishful Thinking
Wishful Thinking

It is impossible to handle all unexpected errors! One needs to
limit and enumerate the requirement to known error types.
There is no way to predict future network configurations much
less manage them.


Optional “Questions” Breaker Slide


© Copyright IBM Corporation 2008. All rights reserved. The information contained in these materials is provided for informational purposes only, and is provided AS IS without warranty of any
kind, express or implied. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, these materials. Nothing contained in these materials is intended to, nor
shall have the effect of, creating any warranties or representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use
of IBM software. References in these materials to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates. Product release dates and/or
capabilities referenced in these materials may change at any time at IBM’s sole discretion based on market opportunities or other factors, and are not intended to be a commitment to future product
or feature availability in any way. IBM, the IBM logo, Rational, the Rational logo, and other IBM products and services are trademarks of the International Business Machines Corporation, in the
United States, other countries or both. Other company, product, or service names may be trademarks or service marks of others.

Four principles seminar manageware seminar

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (19)

Destacado

Destacado (6)

Similar a Four principles seminar manageware seminar

Similar a Four principles seminar manageware seminar (20)

Más de Manageware

Más de Manageware (20)

Último

Último (20)

Four principles seminar manageware seminar