carey schwaber analyst forrester research

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.


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


Agenda








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)


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


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.


Agenda








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.


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.


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.


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


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


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.


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


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.


Agenda








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”


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.


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.


Agenda








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.


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


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.


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)


Agenda








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


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.


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.


Agenda








Where do they come from?

• The business

• Project management

• Testing

• Customer support

• Development


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


What qualities make them successful?

• Communication skills

• Facilitation skills

• Leadership skills

• Organizational skills

• Detail orientation


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.


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


Carey Schwaber

+1 617/613-6260

[email protected]

www.forrester.com

Thank you


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”

carey schwaber analyst forrester research

Documents

business requirements

requirements quality

requirements process

nonfunctional requirements

fulfillment of requirements

lowlevel requirements

requirements management

business context