Larry BoldtSVP, Software Services

Technology Builders, Inc. (TBI)

larry@tbi.com 770.937.7881

Managing Requirements at the Object Level

Chicago SPINFebruary 3, 2000

Thinking Outside the Requirements Management “Box”

Topics

The traditional approach to Requirements Management

The object-oriented approach: Why we need to think

outside the Requirements Management “Box”

Getting your organization to think outside the RM “Box”

What is a Requirement?

A Requirement may be many things, including:

A statement of the problem

A negotiated win condition

A statement identifying a capability, physical characteristic, or a quality factor that bounds a product or process need of the proposed solution

Requirements Management Involves . . .

Planning Establishing requirement management standards and

guidelinesOrganizing Staffing projects with personnel who understand and are

charged with their requirement management responsibilities Directing Ensuring that program/project managers lead and direct

project personnel to follow the requirement management standards and process

Controlling Ensuring that a standard change procedure is established and

followed that allows necessary requirement state changes

Tasks & Estimates

DeliverablesComponents

Key Lifecycle Processes

Requirementsdrive the process

Tests

Who does Requirements Management Today ?

Environments

1. Cost of failure is very high or life-threatening

2. Complexity is very high

3. Regulations require extensive documentation

4. Engineering of embedded systems

Industries Military Medical Avionics Telecoms Manufacturing Embedded Systems Financial

Giga Information Group

Who will do Requirements Management Tomorrow?

Trends:1. …increasing recognition among

development teams of the need to mitigate the cost of failing to meet requirements

2. … increasing focus among certain requirements management vendors on understanding the needs of software developers outside of the traditional markets

Giga Information Group

Causes of Project/Product Failures

#1. Failure to meet project or market requirements

#2. Technical complexity

#3. Inaccurate budgeting or planning

#4. Design/implementation errors

Which one are you willing to sacrific

e?

The Goals of Most Projects

1. On time and within budget

2. High level of quality

3. Meets requirements

Requirement Failures Occurred Because . . .

1. Willingness to sacrifice requirements to meet date, cost, and bug counts

(lack of commitment)

2. Failure to gather requirements accurately in the first place

(lack of a shared form)

3. Software drifted away from meeting requirements during the development process

(lack of process)

What the Business Needs . . .

What the customer really needs

The Requirements Management Challenge

What gets lost in the translation?

The Goal of Requirements Management

Common vision among all stakeholders

Informal ProcessProject FocusedDocument Creation Translation & Interpretation One-time Usage Manage DocumentsLimited Change Notification

Traditional Inside the RM “Box” Thinking

Why We Need to Change the RM Process

“Experiences using Formal Methods for

Requirements Modeling.” Easterbrook, et al.

Inadequate requirements

27%

Imprecise terminology

16%

Logical error3%

Undocumented assumptions

30%

Traceability and inconsistency

24%

What the Experts Have to Say ...

“Ever wonder why there are so many buggy e-commerce

sites? It’s a sorry tale of web presence over performance.”

“The mad dash to create e-commerce sites is forcingprudent business practices out the window.”

“The trend is how fast can you get the site up, not didyou test and test again. That’s why we are seeing alot of legal disclaimers on the bottoms of sites.”

“It’s the Ready, Shoot, Aim school of development.”

What if . . .

The requirements specification were treated as a group of integrated, reusable objects instead of a static document?

Requirements could be captured at their source instead of being gathered and translated from one source to another?

Requirements were stored in a central repository where they could be communicated and collaborated on by the entire organization?

All stakeholders were automatically notified any time a requirement changed?

Integrated Process

Manage Objects

Reusability

Document

Generation

TimelyNotification

EnterpriseFocused

Source CaptureImpactAnalysis

Informal ProcessProject focusedDocument Creation Translation & Interpretation One-time Usage Manage DocumentsLimited Change Notification

Outside the RM “Box” Thinking

RequirementElicitation

RequirementAnalysis

RequirementRepresentation

RequirementVerification

RequirementChange

Management

Lifecycle of a Requirement Object

are we doing this task?

is this component supposed to do?

will we integrate this?

can I expect this functionality?

is this request being fulfilled?

Why

What

How

When

Where

Things We Need Answers to . . .

Lifecycle Process Relationships

Why?

What?

How?

Project Management Process

Test Management Process

Component & Configuration Management Process

Risk Management Process

Identify & Evaluate Needs

Derive & Analyze System Requirements

Design & Allocate Solutions

Requirements Management Process

TIME

Who/When?

If - Then

Prove It

ManageChange

Can Technology Help?

How do we record and use requirements today?

Paper

Verbal agreements

We could . . .

Use word documents

Build databases - Access, Excel, SQL Server,

Oracle

The process remains a manual one in all cases!

Team/Collaboration Support Locking/Sharing Collaboration/Discussion Version control/Tracking Baselining

Lifecycle Support Dependency/Relationship

traceability Lifecycle Integration (test,

design & project objects)

Requirements Capture Descriptive text Attributes Reuse External References

Requirements Publishing

Individual & Standard reports

Online & batch hard-copy generation

Web publishing

Minimum Technology Requirements

Getting Your Organization Out of the “Box”

Who is involved in the requirement management

process?

At what phases of the lifecycle do you capture and

document requirements?

How and where do you document and maintain your

requirements?

How do you manage changes to requirements?

How much time do you spend writing and publishing

requirements documents?

What are the Alternatives?

Do Nothing Keep process manual and labor intensive Use word processing files and E-mail as

documentation Hope nothing in the process breaks!

Do Something Develop a strategy to improve the process Automate where we can Minimize system and user change

Think Outside the “Box” Develop a new process Improve cycle times (make it a goal) Partner with the business (provide 2-way feedback -

goal sharing) Centralize the dissemination of project related

information

Other Questions We Need to Answer . . .

Why do we need requirements management?

What are the alternatives?When should requirements management

be used?How can we accomplish this?

Why do We Need Requirements Management?

To Visualize the Business Document agreement of what the business

wants to accomplish Remove ambiguity Enable the “Big Picture” view of the business

To Focus Resources Right resource/Right application Manage customer expectations Control project expense

Doing the right things right the first time

When Should Requirements Management be Used?

Business projects needing control over customer-

driven agreements deliverables that customers consider critical

IT all planned, budgeted deliverables all development and infrastructure projects for budget planning

How Can We Accomplish This?

Pilot the ProcessDefine the customer organizationRecruit key business executive sponsorMeet all the requirements and exceed them if

possible Document the experience Determine needs and ROI

Cost avoidance for rework & delays

Best Practices

Define requirements as objects Make individual owners responsible for

requirement quality Encourage buy-in from both IT and

Business at all stages…build it in Derive each successive level of

requirements from the previous Manage change with an iron fist Conduct requirement ambiguity reviews

Starting Tomorrow . . .

Guidelines for Writing Quality Requirements Write in a style readable by all audiences Write requirements in a casual language as

opposed to a formal language (e.g., computer language)

Keep sentences and paragraphs short Avoid ambiguity (multiple

meanings/interpretations Write requirements at a consistent level

Starting Tomorrow . . .

Guidelines for Reviewing Requirements Do you understand the requirement?

- Unambiguous- Complete- Testable- Modifiable

Is the requirement valid?- Correct- Necessary- Feasible

Does the set of requirements make sense?- Consistent- Traceable- Prioritized

Avoid Ambiguous Terms

support minimize maximize optimize rapid user-friendly easy simple often usually

large intuitive robust state-of-the-art improve efficient flexible and/or etc.

Requirements as objects provides ...

Visibility clearer elicitation, analysis and communication

Reusability versioning and baselining of requirements within a software

project that has multiple releases. Testability

verification and validation on an individual level. Traceability & Replaceability

tracing from inception to deployment. Stakeholders immediately know what components need to be changed or replaced.

Maintainability & Security Each requirement has its own individual change history and

level of security.

Larry BoldtSVP, Software Services

Technology Builders, Inc. (TBI)

larry@tbi.com 770.937.7881

Managing Requirements at the Object Level

Chicago SPINFebruary 3, 2000

Thinking Outside the Requirements Management “Box”