My Goals For Today

1. Requirements Gathering: Pragmatic Ways to Meet Real Customer NeedsPMI CVC Professional Development“Saturday Seminar”Dr. Ralph R. Youngralph.young@northropgrumman .comwww.ralphyoung.netMarch 22, 2003

2. My Goals For Today • To provide you at least three (3) ideas for doing something differently for your “Commitment List.” • Create with you an enjoyable time together and a valued learning experience • Ensure a positive startup for the PMI CVC Professional Development “Saturday Seminar” Series! • Consider having a PMI CVC Requirements Email Group

3. Introduction Round the room: • Name • Current role • One thing I’d like to learn about today • An issue for me on my project is…

4. The Rationale for Focus on Requirements(Industry Data: 8,000 software projects) • 53% of industry’s investment on application development projects is a casualty of cost overruns and failed projects. • Major contributing factors include: lack of user input (13%); incomplete requirements (12%); and changing requirements. • Reducing requirements errors is the single most effective action developers can take to improve project outcomes. • There is as much as a 2000:1 cost savings from finding errors in the requirements stage vs. in the maintenance stage of the life-cycle. • Requirements errors are the largest class of errors typically found in a project (41-56% of errors are discovered). • The cost of rework is typically 45% of projects.

5. Typical Project Management Issues Concerning Requirements • There are different ideas and opinions as to what the real requirements are. • We don’t know what the real requirements are, do we? • We initiate other technical work too early—the result: rework (40-50% of costs). • There is lacking an effective mechanism to control changes to requirements and new requirements during the development process. • There is no documented requirements process, or it’s not used, or it doesn’t support the needs of the project and the customer/users. • The customer is anxious to get moving on “the real work.” • There are a variety of “people-related problems” (that can result in a lack of effective teamwork). • Need for more effective communications. People on the project don’t know what each other are doing. • Methods, techniques, tools, mechanisms are not familiar, proven, or effective. • There is no zeal for or commitment to continuous improvement. • Requirements analysts could benefit from more training and knowledge. • A project risk management process is not used effectively to identify, analyze, prioritize, and mitigate project risks.

6. Exercise • Form into groups of 5 • Discuss how management can best support the requirements-related activities on your project or in your organization • Select a spokes-person • Be prepared to report out to the larger group

7. Some Thoughts Concerning Management Commitment for Effective Requirements Engineering • Investment of 8-14% of project costs in the system life-cycle requirements process (the industry average is 3%) • Sponsorship and funding of formal training for requirements analysts and quality improvement for all • Expectations that effective requirements practices are used, projects are successful (meet customer needs and are completed within 15% of budget and planned schedule), and rework is less than 15% • Support for strengthening teamwork, process design and use, continuous improvement, inter-personal skills, good relationships, and a "quality culture" • Sponsorship of an organizational requirements working group to provide a mechanism to share and improve requirements-related activities • Foster effective communication • Avoid blame

8. What’s Needed? • An organizational requirements policy • Senior management support-”sponsorship” (to be characterized and described later) • A requirements process • Designed by performers in your organizations who are concerned with requirements • An organizational “Requirements Working Group” • A requirements process description (narrative) • Investment in the requirements process of 8-14% of total project costs • Recommended methods and techniques for each part of the requirements process • Training for how to address requirements in your organization • An effective automated requirements tool (essential, not optional) • A few useful metrics that are tracked and used • Suggested reading (for more information, advice, suggestions, recommendations, lessons-learned from others) • Effective communication • A way (that is, a mechanism) to control changes to requirements

9. Effect of Requirements Process Investment on Program Costs

10. Effective Project Practices Commit to the approach. Establish and utilize a Joint Team to be responsible for the requirements. • Define the real customer needs. Use a requirements process and continually improve it. Iterate the system requirements and the system architecture repeatedly. Use a mechanism to maintain project communication between and among all engineering groups throughout the development effort. Select familiar methods and maintain a set of work products that collectively comprise the current requirements specification. Perform requirements verification and validation. Provide an effective mechanism to accommodate changes in requirements during system life cycle development. Perform the development effort using known familiar proven industry, organizational, and project best practices.

11. Some Recommended Requirements Gathering Practices • Write and iterate a project vision and scope document. • Initiate a project glossary that provides definitions of words that are acceptable to and used by customers/users and the developers, and a list of acronyms to facilitate effective communication. • Evolve the real requirements via a joint customer/user and developer effort. Focus on product benefits (necessary requirements), not features. Address the minimum and highest priority requirements needed to meet real customer and user needs. • Document the rationale for each requirement (why it is needed).

12. Recommended Requirements Gathering Practices - continued • 5. Provide training for requirements analysts and selected customer/user representatives that explains: • The role of the requirements analyst (e.g., to evolve real requirements working with customers and users, not to invent requirements independently or to “gold plate”). • - How to write good requirements. • - The types of requirements errors and how these can be reduced. • - The value of investing more in the requirements process. • - The project and/or organization’s “Requirements Process.” • - Overview of the methods and techniques that will be used. • - How to use the project’s automated requirements tool. • - The role of validation and verification during requirements definition.

13. Recommended Requirements Gathering Practices - continued 6. Establish a mechanism to control changes to requirements and new requirements. 7. Prioritize the real requirements to determine those that should be met in the first release or product and those that can be addressed subsequently. 8. When the requirements are volatile (and perhaps even when they aren’t), consider an incremental development approach. This acknowledges that some of the requirements are “unknowable” until customers and users start using the system. 9. Use peer reviews and inspections of all requirements work products. 10. Use an industry-strength automated requirements tool. -Assign attributes to each requirement. -Provide traceability. -Maintain the history of each requirement.

14. Recommended Requirements Gathering Practices - continued 11. Use requirements gathering techniques that are known, familiar, and proven in the organization such as requirements workshops, prototyping, and storyboards. 12. Provide members of the project team (including requirements analysts) who are domain/subject matter experts. 13. Evolve a project and organizational approach based on successful use of policy, process, methods, techniques, and tools. Provide a mechanism such as working groups to share information and “best practices” among projects. 14. Establish a continuous improvement ethic, teamwork approach, and a quality culture. 15. Involve customers and users throughout the development effort. 16. Perform requirements validation and verification activities in the requirements gathering process to ensure that each requirement is testable.

15. How Can We Best Support Each Other in Our Work Environment? Consider establishing a set of “Rules of Conduct,” for example: • Respect each person • Share responsibility • Criticize ideas, not people • Keep an open mind • Question and participate • Arrive on time • Keep interruptions to a minimum • Manage by fact

16. Acceptance, integration & verification Informing the enterprise Provisional & final Detailed Storing acceptance design & knowledge from component previous projects development User requirements Involving Customers Supplier work Amount of effort Architectural 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

17. Costs Current process Improved process Process Improvement Current cost Cost of process improvement Downsizing Options depending upon business goals Reduced cost Capability Reduced capability for lower cost Current capability Improved capability at lower cost Source: Merle Whatley, Texas Instruments, Inc.. Rationale for Process Improvement

18. Benefits of Process Improvement Over a five-year period, the Software Engineering Institute (SEI) had discovered that by having processes and a focus on continuous improvement, these results can be achieved. CATEGORY IMPROVEMENT Productivity Increase 202% Cycle Time Reduction 46% Defect Reduction 90% Predictability Error Reduction 76% Average time 5 years Data derived from an SEI Technical Report, “Benefits of CMM-Based Software Process Improvement,” CMU/SEI-94-TR-13, August 1994.

19. Seminar Summary • Management has a huge impact • Developers need to be empowered • Use of effective practices helps • Hopefully, our time together today has given you some ideas • We must change some things to improve what we’re doing

20. “P D C A”