1. Systems and Software Consortium | 2214 Rock Hill Road, Herndon, VA 20170-4227 Phone: (703)742-8877 | FAX: (703)742-7200 www.systemsandsoftware.org The Requirements Conundrum: Knowledge, Uncertainty, and Change Presented By: Richard Turner Date: February 2007

2. January 2007 2 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

3. January 2007 3 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

4. January 2007 4 Hence the Conundrum! How to resolve the issue and find a way forward?

5. January 2007 5 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

6. January 2007 6 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

7. January 2007 7 Traditions - 2 Traditional Vee assumes reasonably complete requirements Top-down, hierarchical decomposition and requirements allocation is often seen as once- through process Hardware and software lifecycles often in conflict –Hardware driven by materiel and design constraints –Software driven by need for flexibility and performance constraints

8. January 2007 8 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

9. January 2007 9 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)

10. January 2007 10 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?