Title: Larry Boldt
1Thinking 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) larry_at_tbi.com 770.937.7881
2Topics
- 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
3What 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
4Requirements 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
5Key Lifecycle Processes
Tests
Tasks Estimates
Requirements
drive the process
Components
Deliverables
6Who 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
7Who 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
8Causes 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
9The Goals of Most Projects
- 1. On time and within budget
- 2. High level of quality
- 3. Meets requirements
Which one are you willing to sacrifice?
10Requirement 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)
11What the Business Needs . . .
What the customer really needs
12The Requirements Management Challenge
What gets lost in the translation?
13The Goal of Requirements Management
Common vision among all stakeholders
14Traditional Inside the RM Box Thinking
Requirements Management
Informal Process Project Focused Document
Creation Translation Interpretation One-time
Usage Manage Documents Limited Change
Notification
15Why We Need to Change the RM Process
Experiences using Formal Methods for
Requirements Modeling. Easterbrook, et al.
16What the Experts Have to Say ...
- Ever wonder why there are so many buggy
e-commerce - sites? Its 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. Thats why we are seeing
a - lot of legal disclaimers on the bottoms of
sites. - Its the Ready, Shoot, Aim school of
development.
17What 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?
18Outside the RM Box Thinking
Requirements Management
Enterprise Focused
Integrated Process
Informal Process Project focused Document
Creation Translation Interpretation One-time
Usage Manage Documents Limited Change
Notification
Timely Notification
Manage Objects
Reusability
Source Capture
Document Generation
Impact Analysis
19Lifecycle of a Requirement Object
Requirement Elicitation
20Things We Need Answers to . . .
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
21Lifecycle Process Relationships
Why? What? How?
Who/ When? If - Then Prove It Manage Change
22Can 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!
23Minimum Technology Requirements
- 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
24Getting 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?
25What 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
26Other 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?
27Why 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
28When 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
29How 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
30Best Practices
- Define requirements as objects
- Make individual owners responsible for
requirement quality - Encourage buy-in from both IT and Business at all
stagesbuild it in - Derive each successive level of requirements from
the previous - Manage change with an iron fist
- Conduct requirement ambiguity reviews
31Starting 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
32Starting 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
33Avoid 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.
34Requirements 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.
35Thinking 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) larry_at_tbi.com 770.937.7881