Post on 19-Jan-2016
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”