View
463
Download
5
Category
Tags:
Preview:
DESCRIPTION
Citation preview
TeleconferenceThe Root Of The Problem: Poor RequirementsCarey Schwaber
Analyst
Forrester Research
November 3, 2006. Call in at 12:55 pm Eastern Time
2Entire contents © 2006 Forrester Research, Inc. All rights reserved.
Theme
There’s more to requirements than just
requirements management.
3Entire contents © 2006 Forrester Research, Inc. All rights reserved.
Agenda
• Why requirements practices matter
• Requirements definition offers the most room for improvement
• Choice of development methodology drives attitude toward requirements change
• Requirements management tools increase efficiency
• Determining where to focus your efforts
• The role of the business analyst
4Entire contents © 2006 Forrester Research, Inc. All rights reserved.
Agenda
• Why requirements practices matter
• Requirements definition offers the most room for improvement
• Choice of development methodology drives attitude toward requirements change
• Requirements management tools increase efficiency
• Determining where to focus your efforts
• The role of the business analyst
5Entire contents © 2006 Forrester Research, Inc. All rights reserved.
Business stakeholders are dissatisfied with custom app dev
Agree Strongly agreeSomewhat agreeSomewhat disagreeStrongly disagree Disagree
“Please indicate how much you agree or disagree with these statements aboutapplication software you use that is custom-developed by your IT organization.”
Source: Forrester’s Business Technograhpics® March 2005 United States Technology User Benchmark Study
“New apps or changes toexisting apps are deliveredat expected quality levels”
2% 7% 20% 29% 35% 7%
Base: 418 technology influencers at US companies with more than 500 employees who personally used custom applications developed by their IT organizations
(percentages may not total 100 due to rounding)
“New apps or changes toexisting apps are deliveredin the time frame needed”
3% 9% 20% 31% 30% 7%
Base: 417 technology influencers at US companies with more than 500 employees who personally used custom applications developed by their IT organizations
(percentages may not total 100 due to rounding)
6Entire contents © 2006 Forrester Research, Inc. All rights reserved.
Business units think IT is unresponsive; IT thinks business units are too demanding
Source: Forrester’s Business Technographics® June 2004 North American And European Benchmark Study
= 1, not at all
= 2 = 4
= 3 = 5
= 6, describes my company perfectly
“Business units view the corporate IT group as unresponsive and a barrier.”
“IT views business units as too demanding.”
23% 25% 25% 17% 8% 3%
16% 17% 23% 26% 12% 5%
North America
Europe
30% 25% 24% 13% 6% 1%
23% 18% 34% 16% 6% 3%
North America
Europe
7Entire contents © 2006 Forrester Research, Inc. All rights reserved.
Requirements quality is a limiting factor on software quality
• Poor requirements practices alone can doom any application development initiative.
• No matter how well-architected, well-constructed, or well-tested an application might be . . .
• . . . it is essentially useless if it fails to meet business needs.
8Entire contents © 2006 Forrester Research, Inc. All rights reserved.
Agenda
• Why requirements practices matter
• Requirements definition offers the most room for improvement
• Choice of development methodology drives attitude toward requirements change
• Requirements management tools increase efficiency
• Determining where to focus your efforts
• The role of the business analyst
9Entire contents © 2006 Forrester Research, Inc. All rights reserved.
Definition
► Requirements definition is the elicitation and articulation of high-level and low-level requirements.
► Requirements definition is the process of discovering and documenting what the business needs.
10Entire contents © 2006 Forrester Research, Inc. All rights reserved.
Garbage in, garbage out
• Requirements definition is the most important part of the requirements process:
» How requirements are handled downstream isn’t nearly as important as how they’re defined upfront.
• But requirements definition gets short shrift:
» Shared responsibilities are often abdicated responsibilities.
» Requirements tools targeted management, not definition, until recently.
11Entire contents © 2006 Forrester Research, Inc. All rights reserved.
Requirements definition is even more important when outsourcing development
• When development is conducted by a separate organization, the importance of careful requirements definition only increases.
• One of the most common pitfalls of outsourced development: “They always give us what we ask for, but they never give us what we need.”
• User companies pay for rework resulting from requirements errors; poor requirements practices reduce ROI of outsourcing.
• The business analyst role becomes more important in both environments.
12Entire contents © 2006 Forrester Research, Inc. All rights reserved.
The struggle to balance IT and biz responsibilities
• Shared responsibilities are too often abdicated responsibilities.
• Too little or too much business involvement is a common pitfall.
• Careful articulation of roles and responsibilities goes a long way.
“Our customer’s attitude is that requirements are our
problem.”
“The business usually hands IT a document that
dictates a solution.”
13Entire contents © 2006 Forrester Research, Inc. All rights reserved.
Sample business and IT requirements responsibilities
Business responsibilities
Develop business requirements that do notpresuppose design or implementation details
Prioritize requirements based on relative needand available resources
Provide signoffs only after carefully evaluating allmaterials and ensuring thorough comprehension
Communicate changing business needs, and collaborate with development to determine theimpact of these changes
Understand business goals and business context
Identify and employ appropriate techniques todefine functional and nonfunctional requirements
Communicate about progress toward fulfillmentof requirements
Manage relationships between requirements andother life-cycle artifacts to ensure fulfillment ofrequirements
IT responsibilities
14Entire contents © 2006 Forrester Research, Inc. All rights reserved.
Requirements come in all shapes and sizes
• Requirements are everywhere:
» Existing applications.
» Service interfaces.
» Security standards.
» Prototypes.
» Business process models.
» Business rules.
• Accommodating more formats helps involve more constituents and results in broader coverage of real requirements.
15Entire contents © 2006 Forrester Research, Inc. All rights reserved.
Requirements definition techniques should, as well
• Discovery meetings
• JAD sessions
• Modeling
• Phone, email, or in-person interview
• Prototyping
• Scenarios
• Secondary research
• Shadowing
• Simulation
• Storyboarding
• Surveys
• Use cases
• User stories
• Workshops
16Entire contents © 2006 Forrester Research, Inc. All rights reserved.
Stock your requirements definition tool kit
• Train analysts on as wide a variety of requirements definition techniques as possible.
• Build out a core of techniques, but ensure exposure to a wide range.
• This opens up the analysts’ eyes to the range of possibilities and positions them for future learning.
• Preface all technique training with commentary on situations in which each technique is more or less appropriate.
17Entire contents © 2006 Forrester Research, Inc. All rights reserved.
Agenda
• Why requirements practices matter
• Requirements definition offers the most room for improvement
• Choice of development methodology drives attitude toward requirements change
• Requirements management tools increase efficiency
• Determining where to focus your efforts
• The role of the business analyst
18Entire contents © 2006 Forrester Research, Inc. All rights reserved.
Requirements change is a reality
• Better requirements definition practices will help reduce unnecessary requirements change; they won’t eliminate it altogether.
• Requirements are useful only as long as they correspond with business needs, and business needs are a moving target.
• Choice of development methodology determines ability to accommodate requirements change.
© 2006, Forrester Research, Inc. Reproduction Prohibited
Sample Division Of Responsibilities Between Business And ITSeptember 2006, Trends “The Root Of The Problem: Poor Requirements”
20Entire contents © 2006 Forrester Research, Inc. All rights reserved.
Waterfall processes treat requirements change as the exception
• Requirements are defined at the beginning of the life cycle and presumed to remain constant over time.
• The impact of a requirements change — and the associated costs — increases dramatically as the project progresses and more derivative artifacts are produced.
• Open communication with business stakeholders about the true cost of requirements change to enable informed decision-making is absolutely essential.
• Shorter release cycles make requirements change in a waterfall context less expensive and are a step in the right direction.
21Entire contents © 2006 Forrester Research, Inc. All rights reserved.
Iterative processes are built to accommodate requirements change
• Incremental, iterative development processes consist of a sequence of short release cycles, whereas a waterfall process would have a single long release cycle.
• Each shorter release cycle delivers against a subset of the total inventory of requirements.
• Requirements are revisited at the end of each iteration, and any necessary changes are introduced — without incurring significant costs.
• Specific engineering practices common to iterative methodologies make it easier for the software under development to evolve in parallel with business needs.
22Entire contents © 2006 Forrester Research, Inc. All rights reserved.
Agenda
• Why requirements practices matter
• Requirements definition offers the most room for improvement
• Choice of development methodology drives attitude toward requirements change
• Requirements management tools increase efficiency
• Determining where to focus your efforts
• The role of the business analyst
23Entire contents © 2006 Forrester Research, Inc. All rights reserved.
Definition
► Requirements management is the process of tracking requirement status, controlling changes to requirements, associating requirements with other life-cycle artifacts, and identifying the impact of changes to requirements upon these other assets.
24Entire contents © 2006 Forrester Research, Inc. All rights reserved.
Life without a requirements management tool
“We often hear that requirements have been
overlooked. The link between what we really need to build in the first place and what’s getting
built is missing.”
“Tracing from use cases to test cases manually using spreadsheets is very labor-intensive. That's why we're looking for a requirement
management tool to integrate with our test
management tool.”
25Entire contents © 2006 Forrester Research, Inc. All rights reserved.
Guidelines for requirements management tool selection
• Avoid tools that are too complex:
» Business analysts often revert to old habits when tools are hard to use.
» Be sure not to handicap the tool with overweight processes.
• Make end user comfort your No. 1 selection criteria:
» Let end users — not just managers — drive selection process.
» Focus on support for end users’ preferred means of entry.
» Look at support for generation of other relevant artifacts (e.g., test cases, UML models).
» Insist on live pilots, and let end users work with the tools.
• Adopt tools with an eye toward life-cycle integration:
» Identify desired integration targets early on.
» Make integration part of the POC.
26Entire contents © 2006 Forrester Research, Inc. All rights reserved.
Evaluation criteria for RM tools
High-level feature categories:
• Security
• Auditing
• Requirements capture
• Linking and tracing
• Glossaries
• Workflow
• Collaboration
• Reporting
• Life-cycle integration
Other important characteristics:
• Scalability
• Implementation time and ease of use
• Solution architecture (e.g., underlying database)
27Entire contents © 2006 Forrester Research, Inc. All rights reserved.
Agenda
• Why requirements practices matter
• Requirements definition offers the most room for improvement
• Choice of development methodology drives attitude toward requirements change
• Requirements management tools increase efficiency
• Determining where to focus your efforts
• The role of the business analyst
28Entire contents © 2006 Forrester Research, Inc. All rights reserved.
Where to get started?
“We know we have a problem with requirements, but we can’t tell what type of tool can help
us fix it.”
29Entire contents © 2006 Forrester Research, Inc. All rights reserved.
Overview of requirements disciplines
• For most shops, requirements definition is where the real opportunity for improvement lies.
• Requirements change processes are closely tied to development methodologies, so consider the two as a pair.
• Tools can improve the efficiency of mature requirements management practices.
30Entire contents © 2006 Forrester Research, Inc. All rights reserved.
Different strategies for different problems
• Pay attention to requirements definition for:
» Inaccurate and incomplete requirements.
» Inefficient requirements definition practices.
• Rethink your development methodology for:
» Unmanaged requirement change.
» Scope creep.
• Improve requirements management for:
» Missed requirements.
» Missed requirements changes.
» Missed impact of requirements changes.
31Entire contents © 2006 Forrester Research, Inc. All rights reserved.
Agenda
• Why requirements practices matter
• Requirements definition offers the most room for improvement
• Choice of development methodology drives attitude toward requirements change
• Requirements management tools increase efficiency
• Determining where to focus your efforts
• The role of the business analyst
32Entire contents © 2006 Forrester Research, Inc. All rights reserved.
Where do they come from?
• The business
• Project management
• Testing
• Customer support
• Development
33Entire contents © 2006 Forrester Research, Inc. All rights reserved.
Where do they report?
• The business
• The IT organization
» Business analysis team
» Project management office
» Quality assurance
• Sometimes both
» Business analysts on one side
» Systems analyst on the other
34Entire contents © 2006 Forrester Research, Inc. All rights reserved.
What qualities make them successful?
• Communication skills
• Facilitation skills
• Leadership skills
• Organizational skills
• Detail orientation
35Entire contents © 2006 Forrester Research, Inc. All rights reserved.
What makes their job so hard — and so important?
• Business analysts straddle both business and IT:
» Hybrid creatures expected to have roughly equal knowledge of both areas.
• Business analysts are the conduit of information between business and IT:
» Communicate to IT what the business needs.
» Communicate to the business what’s possible.
• A healthy relationship between business and IT is nearly impossible without a strong corps of business analysts.
36Entire contents © 2006 Forrester Research, Inc. All rights reserved.
How can they be developed?
• Exposure, exposure, exposure:
» To requirements definition techniques.
» To the business and to technology.
» To end users and their experiences with deployed apps.
• Training, training, training:
» Tools vendors (e.g., Borland, Compuware, iRise).
» Service providers (e.g., B2T Training, ESI International).
37Entire contents © 2006 Forrester Research, Inc. All rights reserved.
Carey Schwaber
+1 617/613-6260
cschwaber@forrester.com
www.forrester.com
Thank you
38Entire contents © 2006 Forrester Research, Inc. All rights reserved.
Selected bibliography
• September 14, 2006, Teleconference “What’s New In Application Development Processes And Methodologies”
• September 1, 2006, Trends “The Root Of The Problem: Poor Requirements”
• August 18, 2006, Trends “The Changing Face Of Application Life-Cycle Management”
• February 8, 2006, Best Practices “Performance-Driven Software Development”
• August 11, 2005, Trends “Show, Don’t Tell”
Recommended