my goals for today

Requirements Gathering: Pragmatic Ways to Requirements Gathering: Pragmatic Ways to

Meet Real Customer NeedsMeet Real Customer Needs

PMI CVC Professional Development“Saturday Seminar”

Dr. Ralph R. Young

ralph.young@northropgrumman .com

www.ralphyoung.net March 22, 2003

http://www.ralphyoung.net/



Copyright 2002 by Ralph R. Young 2

My Goals For TodayMy 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


IntroductionIntroduction

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


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 RequirementsThe Rationale for Focus on Requirements(Industry Data: 8,000 software projects)(Industry Data: 8,000 software projects)


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 Typical Project Management Issues Concerning RequirementsRequirements


ExerciseExercise

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


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 communication7. Avoid blame

Some Thoughts Concerning Management Some Thoughts Concerning Management Commitment for Effective Requirements EngineeringCommitment for Effective Requirements Engineering


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?What’s Needed?


Effect of Requirements Process Effect of Requirements Process Investment on Program CostsInvestment on Program Costs


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 projectcommunication between and among

all engineering groups throughout thedevelopment 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 Effective Project PracticesPractices


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 Some Recommended Requirements Gathering PracticesGathering Practices


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 Recommended Requirements Gathering Practices - continuedPractices - 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.



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.



How Can We Best Support Each Other in How Can We Best Support Each Other in Our Work Environment?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:


Involving CustomersInvolving Customers

Am

oun

t of

effo

rt

Userrequirements

Systemrequirements

Architecturaldesign

Detaileddesign &componentdevelopment

Definingresults

for users

Optimizingthe cost-benefits

Defining whatthe system

must do

Decidingon potential

changes

Customer work

Supplierwork

Provisional& finalacceptance

Acceptance,integration &verification

Qualifying the

design

Verifying& validatingthe product

Linkingdeliverables

to requirements

Storingknowledge from

previous projects

Informing theenterprise


Rationale for Process ImprovementRationale for Process Improvement

Capability

Costs Current process Improved process

Currentcost

Current capability

Reducedcost

Reduced capability for lower cost

Improvedcapabilityat lower cost

Cost of process improvement

Source: Merle Whatley, Texas Instruments, Inc..

Dow

nsiz

ing

Process Improvement

Options depending upon business goals


Benefits of Process ImprovementBenefits 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 Increase 202%

Cycle Time Reduction 46%

Defect Reduction 90%

Predictability Error Reduction 76%

Average time 5 years

CATEGORY 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.


Seminar SummarySeminar 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


““P D C A”P D C A”

my goals for today

Documents