slide1 n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
My Goals For Today PowerPoint Presentation
Download Presentation
My Goals For Today

Loading in 2 Seconds...

play fullscreen
1 / 20

My Goals For Today - PowerPoint PPT Presentation


  • 102 Views
  • Uploaded on

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. My Goals For Today.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

My Goals For Today


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
slide1

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

my goals for today
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
introduction
Introduction

Round the room:

  • Name
  • Current role
  • One thing I’d like to learn about today
  • An issue for me on my project is…
the rationale for focus on requirements industry data 8 000 software projects
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.
typical project management issues concerning requirements
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.
exercise
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
some thoughts concerning management commitment for effective requirements engineering
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
what s needed
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
slide10

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.

slide11

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).
slide12

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

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.

slide14

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.

how can we best support each other in our work environment
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
slide16

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

slide17

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

slide18

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.

slide19

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