Transcript No Slide Title

Thinking Outside the Requirements Management “Box”
Managing Requirements
at the Object Level
Chicago SPIN
February 3, 2000
Larry Boldt
SVP, Software Services
Technology Builders, Inc. (TBI)
[email protected] 770.937.7881
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 guidelines
Organizing
 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
Key Lifecycle Processes
Tests
Tasks &
Estimates
Requirements
drive the process
Deliverables
Components
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
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
Giga Information Group
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
Traditional Inside the RM “Box”
Thinking
Informal Process
Project Focused
Document Creation
Translation & Interpretation
One-time Usage
Manage Documents
Limited Change Notification
Why We Need to Change the RM
Process
Imprecise
terminology
16%
Logical error
3%
Undocumented
assumptions
30%
Traceability and
inconsistency
24%
Inadequate
requirements
27%
“Experiences using Formal Methods for
Requirements Modeling.” Easterbrook, et al.
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 forcing
prudent business practices out the window.”
“The trend is how fast can you get the site up, not did
you test and test again. That’s why we are seeing a
lot 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?
Outside the RM “Box” Thinking
Informal Process
Project focused
Document Creation
Translation & Interpretation
One-time Usage
Manage Documents
Limited Change Notification
Lifecycle of a Requirement Object
Requirement
Elicitation
Requirement
Verification
Requirement
Change
Management
Requirement
Representation
Requirement
Analysis
Things We Need Answers to . . .
Why
are we doing this task?
What
is this component supposed to
do?
How
will we integrate this?
When
can I expect this functionality?
Where
is this request being fulfilled?
Lifecycle Process Relationships
Requirements Management Process
Why?
What?
How?
Identify & Evaluate Needs
Derive & Analyze System Requirements
Design & Allocate Solutions
TIME
Who/
When?
Project Management Process
If - Then
Risk Management Process
Prove It
Test Management Process
Manage
Change
Component & Configuration Management Process
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!
Minimum Technology Requirements
Requirements Capture

Descriptive text

Attributes

Reuse

External References
Requirements Publishing

Individual & Standard
reports

Online & batch hardcopy generation

Web publishing
 Team/Collaboration Support
 Locking/Sharing
 Collaboration/Discussion
 Version control/Tracking
 Baselining
 Lifecycle Support
 Dependency/Relationship
traceability
 Lifecycle Integration (test,
design & project objects)
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 Process



Define the customer organization
Recruit key business executive sponsor
Meet 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
 large
 minimize
 intuitive
 maximize
 robust
 optimize
 state-of-the-art
 rapid
 improve
 user-friendly
 efficient
 easy
 flexible
 simple
 and/or
 often
 etc.
 usually
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.
Thinking Outside the Requirements Management “Box”
Managing Requirements
at the Object Level
Chicago SPIN
February 3, 2000
Larry Boldt
SVP, Software Services
Technology Builders, Inc. (TBI)
[email protected] 770.937.7881