®

IBM Software Group

© 2008 IBM Corporation

Ensuring Project Success:Four Principles for Effective Requirements Lifecycle Management

Dr. Keith CollyerRequirements Product Delivery Teamkeith.collyer@uk.ibm.com

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

Almost 162 million smart phones were sold in 2008, surpassing laptop sales for the first time.

162 millionNearly 90% of innovation in automobiles is related to software and electronics systems.

90%Soon, there will be 1 trillion connected devices in the world, constituting an “internet of things.”

1 trillion

IBM Software Group | Rational software

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

Five years ago, a typical manufacturer’s concept-through production cycle time was 48 months. Within four years, that time dropped to 18 months—with a goal of reaching a 12 month cycle within the next year.

48 months

66% of software products are deemed unsuccessful, costing the industry nearly $300 billion annually.

$300 billion

More than 42,000 defibrillators had to be recalled in 2007 due to faulty software.

42,000units recalled

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

IBM Software Group | Rational software

4 Principles for Effective Requirements Lifecycle Management

N

W E

S

Automate your requirements process

Integrate requirements across the lifecycle

Use abstraction to manage complexity

Recognize the needs of all stakeholders

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

IBM Software Group | Rational software

Avoid Premature Details at Top Levels

Problem Solution

State what the system must do:

Function

State what the stakeholders

want to be able to do: Capabilities

Principle 1: Recognize the needs of all stakeholders

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.

IBM Software Group | Rational software

Do not define the design –avoid How

Avoid Premature Details at Top Levels

Problem Solution

Do not design the system

Principle 1: Recognize the needs of all stakeholders

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.

IBM Software Group | Rational software

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.

Principle 1: Recognize the needs of all stakeholders

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

IBM Software Group | Rational software

Document Structure

�Structure helps:

�Understand context

�Assess completeness

�Identify repetition/conflict

�Navigate/search requirements

Principle 1: Recognize the needs of all stakeholders

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

IBM Software Group | Rational software

Structure and Templates

DocumentStructure

Boiler-platetext

Requirementtemplates

Project templates

Principle 1: Recognize the needs of all stakeholders

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

IBM Software Group | Rational software

Attributes

Identification

StatusPriority

Type

Performance

Principle 1: Recognize the needs of all stakeholders

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

IBM Software Group | Rational software

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

► Designing the solution

Principle 2: Use abstraction to manage complexity

It isn't that they can't see the

solution it's that they can't see

the problemG.K. Chesterton

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”)

IBM Software Group | Rational software

Building a Requirements Hierarchy

•Transformation Allocation

DecompositionDesign-driven

Principle 2: Use abstraction to manage complexity

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 statementsTurn stakeholder-oriented capabilities into system-oriented functions

Allocation:

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

IBM Software Group | Rational software

Why is Traceability Important?

Can we show these answers? (Governance)

Why are we building this?

Where is this implemented?

How do I test this?

Principle 2: Use abstraction to manage complexity

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?

IBM Software Group | Rational software

RM across the Enterprise

Board

Corporate Vision

Program Managers

Project Managers, Analysts and Requirements Engineers

Developers

Portfolio and Program

Management

Principle 3: Integrate RM across the lifecycle

Project Management, Requirements Management

Requirements Use, Development

Tools

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

IBM Software Group | Rational software

Requirements Definition & Management Must Be Integrated into the Product Lifecycle

Business Analysis: Enterprise Architecture, Business Process Mgmt, Produc t Mgmt, Portfolio Mgmt

Customer Needs

Define Operation

Reqt’s

Develop Concept

Preliminary Definition

Product / SystemBuild

DefineSystemReqt’s

Detail Definition

Product / SystemDeliver

Run / Support / Maintain

Requirements Management

Program & Project Management: Cost Accounting, Scheduling, Measurements, Reporting , Risk Mgmt

Detailed Design and Implementation

Verification and Validation – Test Management

Change and Configuration Management

Integration

SoftwareEngineering

ElectronicsEngineering

MechanicalEngineering

Disposal

Principle 3: Integrate RM across the lifecycle

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

IBM Software Group | Rational software

Sub-System RequirementsSub-System

Requirements

System Requirements

Use Cases

Stakeholder Requirements

Standards Constraints

Test Cases

Sub-System Requirements

Functional Models

Test Cases

DefectsTestCases

RQM

Data Synchronized

TestResults

CRs

Potentially to any Module

Change

ICDICDICD

Modeling tool

Modeling tool

Design tool

Project Plan Rev A

Project Plan Rev B

Glossary Potentially from any doc

Principle 3: Integrate RM across the lifecycle

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

IBM Software Group | Rational software

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

Principle 4: Automate your requirements process

"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

IBM Software Group | Rational software

Effective Requirements Management realizes quantifiable savingsand 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

Principle 4: Automate your requirements process

IBM Software Group | Rational software

Use a Requirements Management Tool�Document structure Attributes

View related information View historical information

Filter to focus

Principle 4: Automate your requirements process

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

IBM Software Group | Rational software

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 | Rational software

4 Principles for Effective Requirements Lifecycle Management

N

W E

S

Automate your requirements process

Integrate requirements across the lifecycle

Use abstraction to manage complexity

Recognize the needs of all stakeholders

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

®

IBM Software Group

© 2008 IBM Corporation

Addendum: Avoiding Requirements Writing Pitfalls

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

IBM Software Group | Rational software

Characteristics of a Good Requirement

Unique Individual Identified

Correct Complete

Consistent Clear Verifiable

Traceable Feasible

Positive Modular Design-Free

UniqueIndividualIdentifiedCorrectCompleteConsistentClearVerifiableTraceableFeasiblePositiveModularDesign-Free

Individual each requirement is a single traceable element

Unique each statement is differentIdentified 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 requirementsVerifiable It can be determined that the system meets the

requirement

Traceable Uniquely identified and can be tracked and tracedFeasible 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)

IBM Software Group | Rational software

r572

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

current account balance in less than 5 seconds.”

The challenge is to seek out the user type, end res ult, and success measure in every requirement you

define.

The challenge is to seek out the user type, end res ult, and success measure in every requirement you

define.

Anatomy of a Good Stakeholder Requirement

user typePositive end resultPerformance criteriaMeasurable (but from when?)

IBM Software Group | Rational software

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:

AmbiguityAmbiguity

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.

IBM Software Group | Rational software

Writing Pitfalls to Avoid

� 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:

MultiplesMultiples

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

IBM Software Group | Rational software

Writing Pitfalls to Avoid

� ‘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 ClausesEscape 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.”

IBM Software Group | Rational software

“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 with the required framework of section 3.1.5 to indicate the desired input state.”

Writing Pitfalls to Avoid

� long sentences

� arcane language

� references to unreachable documents

Example:

Improvements:

RamblingRambling

“The user shall receive an output signal in compliance section 3.1.5.”

“The user shall receive the output signal indicating desired input state.”

IBM Software Group | Rational software

Writing Pitfalls to Avoid

� 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 washers.”Improvements:

Mixing RequirementsMixing 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”

IBM Software Group | Rational software

Writing Pitfalls to Avoid

� 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:

DesigningDesigning

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

IBM Software Group | Rational software

Writing Pitfalls to Avoid

� 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:

SpeculationSpeculation

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

IBM Software Group | Rational software

Writing Pitfalls to Avoid

� 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:

VaguenessVagueness

“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.”

IBM Software Group | Rational software

Writing Pitfalls to Avoid

� 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 PossibilitiesSuggestions and Possibilities

Deliberately use the verbs “shall” or “will” to signal a requirement.

Attempt to make each requirement realistic and achievable!

IBM Software Group | Rational software

Writing Pitfalls to Avoid

� 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 ThinkingWishful 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.

IBM Software Group | Rational software

Optional “Questions” Breaker Slide

IBM Software Group | Rational software

© Copyright IBM Corporation 2008. All rights reserv ed. 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.