1. Requirements Gathering: Pragmatic Ways to Meet Real Customer Needs Requirements Gathering: Pragmatic Ways to Meet Real Customer Needs PMI CVC Professional Development “Saturday Seminar” Dr. Ralph R. Young ralph.young@northropgrumman.com www.ralphyoung.net March 22, 2003 www.ralphyoung.net

2. Copyright 2002 by Ralph R. Young 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. Copyright 2002 by Ralph R. Young 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. Copyright 2002 by Ralph R. Young 4 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. The Rationale for Focus on Requirements (Industry Data: 8,000 software projects)

5. Copyright 2002 by Ralph R. Young 5 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. Typical Project Management Issues Concerning Requirements

6. Copyright 2002 by Ralph R. Young 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. Copyright 2002 by Ralph R. Young 7 1. Investment of 8-14% of project costs in the system life-cycle requirements process (the industry average is 3%) 2. Sponsorship and funding of formal training for requirements analysts and quality improvement for all 3. 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% 4. Support for strengthening teamwork, process design and use, continuous improvement, inter-personal skills, good relationships, and a "quality culture" 5. Sponsorship of an organizational requirements working group to provide a mechanism to share and improve requirements-related activities 6. Foster effective communication 7. Avoid blame Some Thoughts Concerning Management Commitment for Effective Requirements Engineering

8. Copyright 2002 by Ralph R. Young 8 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 What’s Needed?

9. Copyright 2002 by Ralph R. Young 9 Effect of Requirements Process Investment on Program Costs

10. Copyright 2002 by Ralph R. Young 10 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. Effective Project Practices

11. Copyright 2002 by Ralph R. Young 11 1.Write and iterate a project vision and scope document. 2.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. 3.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. 4.Document the rationale for each requirement (why it is needed). Some Recommended Requirements Gathering Practices

12. Copyright 2002 by Ralph R. Young 12 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. Recommended Requirements Gathering Practices - continued

13. Copyright 2002 by Ralph R. Young 13 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. Recommended Requirements Gathering Practices - continued

14. Copyright 2002 by Ralph R. Young 14 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. Recommended Requirements Gathering Practices - continued

15. Copyright 2002 by Ralph R. Young 15 How Can We Best Support Each Other in Our Work Environment? 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 Consider establishing a set of “Rules of Conduct,” for example:

16. Copyright 2002 by Ralph R. Young 16 Involving Customers Amount of effort User requirements System requirements Architectural design Detailed design & component development Defining results for users Optimizing the cost- benefits Defining what the system must do Deciding on potential changes Customer work Supplier work Provisional & final acceptance Acceptance, integration & verification Qualifying the design Verifying & validating the product Linking deliverables to requirements Storing knowledge from previous projects Informing the enterprise

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

18. Copyright 2002 by Ralph R. Young 18 Benefits of Process Improvement Data derived from an SEI Technical Report, “Benefits of CMM-Based Software Process Improvement,” CMU/SEI-94-TR-13, August 1994. Productivity Increase202% Cycle Time Reduction46% Defect Reduction90% Predictability Error Reduction76% Average time 5 years CATEGORYIMPROVEMENT 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.

19. Copyright 2002 by Ralph R. Young 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. Copyright 2002 by Ralph R. Young 20 “P D C A”