Systems and Software Consortium | 2214 Rock Hill Road, Herndon, VA Phone: (703) | FAX: (703) The Requirements Conundrum: Knowledge, Uncertainty, and Change Presented By: Richard Turner Date: February 2007

January 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 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 Hence the Conundrum! How to resolve the issue and find a way forward?

January 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 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 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

January 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 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 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?