The Requirements
Conundrum:
Knowledge, Uncertainty, and Change
Date: February 2007
Presented By: Richard Turner
Systems and Software Consortium | 2214 Rock Hill Road, Herndon, VA 20170-4227
Phone: (703)742-8877 | FAX: (703)742-7200
www.systemsandsoftware.org
Observations
• Systems are getting more complex…
–
–
–
–
System boundaries are amorphous
Functionality is emergent
Implementation is evolutionary
Technology change is rapid and inevitable
BUT
• Knowledge is still expected to be perfect
–
–
–
–
Sponsors want a “defendable” cost bingo
PMs want a complete, consistent, predictable IMS
Suppliers want specifications
OT&E wants everything, including long term
sustainment
January 2007
2
Observations - 2
• Rock-solid requirements are the basis for
–
–
–
–
–
Size and cost estimates
Schedule estimates
System boundary and interface definition
System architecture
System specialty characteristics (safety, security, -ilities)
BUT
• Requirements is a bad word when software is involved
(W. Royce) Why?
– Software is meant to be flexible to meet evolving user needs
– New needs identified through use
– Trades must be made across the characteristics
January 2007
3
Hence the Conundrum!
How to resolve the issue and find a way forward?
January 2007
4
The Balancing Act
• We are left with two conflicting needs that are
both critical
• Knowledge is necessary for planning,
budgeting, and decision making
• Uncertainty is necessary for flexibility,
emergence, and change
• And, it is a fact that change happens – for good
or ill
January 2007
5
Traditions
• In the past, we have tried
–
–
–
–
Freezing requirements
Establishing Block Upgrades
Buying fancy requirements definition and traceability tools
Verifying the heck out of the system
BUT
• These didn’t always work so well
– Changes learned how to ice skate
– Block upgrades blocked progress
– Tools codified poorly specified requirements and became an
end in themselves
– Verification became a puzzle to solve
January 2007
6
Traditions - 2
• Traditional Vee assumes reasonably complete
requirements
• Top-down, hierarchical decomposition and
requirements allocation is often seen as oncethrough process
• Hardware and software lifecycles often in
conflict
– Hardware driven by materiel and design constraints
– Software driven by need for flexibility and
performance constraints
January 2007
7
Can Agility Help?
• Views requirements in terms of negotiation and
priority rather than specification and
completeness
• Considers change a partner – a chance to
make the product better and the customer
happier
• Evolves solutions rather than creating them by
fiat (or committee)
• Better fit to human talents than organizational
capabilities
January 2007
8
Can Agility Help? - 2
• Spiral methods have made stealthy incursions,
but haven’t conquered
• Tends to operate in a controllable space
• Agility is still mistrusted – mostly because of it’s
seeming “non-predictability”
• Agile requirement capture techniques (e.g.
stories) are seen as inadequate for many
systems
• The world revolves around probability and
certainty (e.g. try to get an “agile” bank loan)
January 2007
9
The Challenge
• New ways of eliciting and documenting requirements
– Requirements that are specific enough for costing but flexible
enough for negotiation
– Requirements that emerge are opportunities and should be
weighed as such in decision making as to their inclusion
– Requirements need to exist within a trade space – particularly
the –ilities and other non-functional needs
– For requirements that can be incomplete up front, we need
architectures and infrastructures flexible and prescient
enough to accommodate the unknowns as they become
known
• What are the concepts, practices and tools that can
enable these?
January 2007
10