Software from Requirements Brent Haines April 12, 2007 Why Methodology Doesn’t Really Matter

2 Requirements: Critical but wrong What is the “ultimate goal” of a Software Development project? Value for the End User  Whether the reward is monetary (profitable license fees) or intrinsic, we derive value from software that solves real problems for users in a quantifiable way. Identifying the “Real Problem” Defining the Market  The group of people who would derive the most value from your software.  May be quantified by the number of people, businesses who have the problem, or  May be quantified by the amount of money they will spend to solve it. Describing the “Real Problem” Stating the Requirements  Simply put, requirements are a description of the problem(s) that our software will solve.  May be at a very high level (i.e. 2 page list of features), or  May be described at a very detailed level (i.e. 60 page PRD). They are always WRONG. (Or alternatively; they are never completely correct)

3 Design from Requirements Software development invariably follows a common process:* Development Stages 1.Requirements 2.Design 3.Implementation 4.Test 5.Release Conclusions: 1.Software is designed to satisfy a set of Requirements 2.Most bugs are discovered after implementation 3.Requirements are the root source of software defects *Numbers used in this slide are based upon personal experience and do not reflect any commissioned study. Defect Introduction 60-70% 15-20% 10-15% 5-10% <5% Defect Discovery < 5% 5-10% 10-15% 15-50% 40-50% Cost of Remediation Low Medium High Extremely High

4 Why components matter Obsolescence Axiom: All actively developed software will become obsolete over time. “Actively developed” applies to software that is updated to meet new/changing reqs `Obsolescence can be measured by; 1. When it would cost more to revise existing software to the next spec’d release than it would to write to that spec from scratch. 2. When the number of defects introduced is greater than those addressed in a single release. Doomed from Start?  Requirements are always wrong.  Software is designed from requirements  Actively developed software always become obsolete Components  Software becomes obsolete at different rates (usually correlated to the rate of change in or complexity of requirements).  Components isolate software related to function so that it can mature independently  Strong boundaries gives us the ability to redefine / replace function  Loose coupling gives us the ability to remove or control dependencies

5 A case for methodologies Methodologies Provide; Uniform practices that guide development teams Gates or reviews that are designed to catch inadequacies or defects Common metrics for measuring the results of processes within the methodology Standard language for describing and communicating requirements, tasks, and results Framework for providing predictable results Regardless of Specific Methodology, Specific Focus Should be on: People and Interactions, not Processes for the Process’s Sake Creating Working Software, not Documentation Describing it Solving Customer Problems, rather than Satisfying a Contract or Spec

6 Product Vision Product Roadmap Release Plan Iteration Plan Why methodology doesn’t matter Requirements are the Key Even under Agile methodologies…  Product Vision is defined Annually  Product Roadmap is defined bi-Annually  Release plans are defined Quarterly  Iterations plans are defined bi-Weekly Daily Plan

7 Product Vision Product Roadmap Release Plan Iteration Plan Why methodology doesn’t matter Requirements are the Key Even under Agile methodologies…  Product Vision is defined Annually  Product Roadmap is defined bi-Annually  Release plans are defined Quarterly  Iterations plans are defined bi-Weekly Requirements are changing constantly  Product Vision is interpreted broadly and that interpretation changes throughout the year  Product Roadmap will change to reflect new priorities  Release Plans change in response to roadmap changes Daily Plan

8 Why Quarterly Releases Don’t Work Enterprise Software CANNOT Be Released Quarterly for Real Reasons: Customer Churn  Enterprise adoption is expensive (includes planning, testing, analysis,etc) Collateral  Technical publications  Training material and curriculum  Support and Professional Services training Expense  The increase of cost for each new supported version increases geometrically  Support for extensions and customizations becomes untenable  Upgrade paths are impossible to predict and comprehensively test

9 Putting it to Practice Architecture Addresses Product Vision (and beyond) Updated bi-Annually to Annually Defines Components that answer roadmap and vision themes NOTE: Components are not “steps” Communicate key assumptions and risks to product owners Components Designed around a release plan Boundaries (APIs) and dependencies carefully defined and revied Implemented in shorter cycles Independently tested Integrated as part of a product release Communicate key design assumptions, limitations and risks to product owners Implementation / Fulfillment Just get it done Use the “right stuff”: Tools and Languages Protect Core Competency: Implement differentiating functionality, license everything else. Long term plans and designs (one to four year plans, updated annually) Traditional development and review works well API / Dependency definition are medium term efforts (half-year to one year revisions) Implementation is rapid (quarterly efforts at most)

10 Metrics that matter Obsolescence Metrics Value Check [at beginning of at least every other release] (t rewrite – t revision ) / t revision t rewrite is the effort needed to complete a rewrite of the component t revision is the effort needed to perform the proposed revision TARGET: We want a large positive number. Negative numbers or numbers approaching zero indicate that a redesign and rewrite are in order Convergence Check [before every proposed release] (bugs current – bugs previous ) / bugs previous bugs current is the number of bugs sourced to the latest release bugs previous is the number of bugs sourced to the previous release TARGET: We want a small or negative number, indicating that our defect rate is predictable NOTE: The bug count for each release needs to be normalized for scope or duration of project. Efficiency Ratio [after every release] Resources / AverageComplexity Resources the number of man-weeks (or other unit of work) needed to complete the release AverageComplexity each task/iteration in the release is rated 1-5 in terms of complexity. This is the average TARGET: We want the smallest number we can achieve. The number should stay level from release to release