Dr. Ralph R. Young Director of Software Engineering PRC, Inc. young_ralph@prc (703) 556-1030

1. DOORS USER GROUP CONFERENCE Reston, VA September 17, 2001 Effective Requirements Practices http://ralphyoung.net Dr. Ralph R. Young Director of Software Engineering PRC, Inc. young_ralph@prc.com (703) 556-1030

2. Major Industry Problems • We fail to identify the real requirements before we start development efforts. • We don’t manage changes to requirements and new requirements well. • We lack a disciplined project management approach. • Management’s “expectations” are not clear. • We need to invest more in formal training.

3. Effective Requirements Practices • Obtain commitment. • Consider “Partnering Workshops.” • Have and use a “Requirements Policy.” • Define the real customer needs and the real requirements. • Industry experience shows that the “stated requirements” are never adequate. • Consider utilizing a “Joint Team” to be responsible for the requirements. • Use and continually improve a requirements process. • Iterate the system requirements and architecture repeatedly.

4. Effective Requirements Practices (continued) • Control changes to requirements and new requirements. • Select familiar methods. • Maintain effective project communication. • Maintain a set of work products that together describe the requirements. • Perform requirements verification and validation. • Use proven development practices.

5. Actions We Should Consider • Invest more in the requirements process. • Keep our customers involved. • Provide a mechanism to manage requirements changes. • Reduce rework. • Invest in training and effective tools and practices.

7. Acceptance, integration & verification Informing the enterprise Provisional & final Detailed Storing and using acceptance design & knowledge from component previous projects development User requirements Maintaining Customer Involvement Developer work Architectural Amount of effort design System requirements Customer work Defining Defining what Optimizing Deciding Linking Qualifying Verifying results the system the cost- on potential deliverables the & validating for users must do benefits changes to requirements design the product

8. Managing Changes to Requirements • Implement a mechanism to control changes. • “Joint Team” • Provides a single channel • Allows “responsibility” for the requirements • Facilitates communication of impacts • Control requirements “leakage.” • Focus on product benefits rather than features. • A 1/3 change in requirements equates to a doubling of project costs. • Use product releases and versions and an incremental development approach. • Incorporate technology change management.

9. Avoiding Rework • Perform the development effort using known familiar proven industry, organizational, and project best practices. • Calculate the ROI from using effective requirements practices and use the data to encourage the use of better practices. • Reduce requirements errors—the single most effective action developers can take to improve project outcomes.

10. Training for Requirements Analysts/Engineers • Have and use a requirements process. • Use an effective requirements tool. • Write good requirements (use criteria). • Document the rationale for each requirement. • Prioritize requirements. • Don’t make requirements decisions. • Do not “gold plate.” • How to address the most common sources of requirements errors: • Incorrect facts (49%) • Omitted requirements (29%) • Inconsistencies (13%)

11. Where To Go From Here • We must improve! • Each of us can have a positive impact on our industry by doing things a bit differently. • Take three ideas home from this Conference and apply them. • Consider having an organizational or project requirements working group. • Leverage industry, organization, and project experience. • Advise project managers. • Share successes.