November 3, 2006. Call in at 12:55 pm Eastern Time Carey Schwaber Analyst Forrester Research Teleconference The Root Of Th...
Theme There’s more to requirements than just requirements management.
Agenda <ul><li>Why requirements practices matter </li></ul><ul><li>Requirements definition offers the most room for improv...
Agenda <ul><li>Why requirements practices matter </li></ul><ul><li>Requirements definition offers the most room for improv...
Business stakeholders are dissatisfied with custom app dev “ Please indicate how much you agree or disagree with these sta...
Business units think IT is unresponsive; IT thinks business units are too demanding Source :  Forrester’s Business Technog...
Requirements quality is a limiting factor on software quality <ul><li>Poor requirements practices alone can doom any appli...
Agenda <ul><li>Why requirements practices matter </li></ul><ul><li>Requirements definition offers the most room for improv...
Definition <ul><li>Requirements definition  is the elicitation and articulation of high-level and low-level requirements. ...
Garbage in, garbage out <ul><li>Requirements definition is the most important part of the requirements process:  </li></ul...
Requirements definition is even more important when outsourcing development <ul><li>When development is conducted by a sep...
The struggle to balance IT and biz responsibilities   <ul><li>Shared responsibilities are too often abdicated responsibili...
Sample business and IT requirements responsibilities Business responsibilities Develop business requirements that do not p...
Requirements come in all shapes and sizes <ul><li>Requirements are everywhere:  </li></ul><ul><ul><li>Existing application...
Requirements definition techniques should,  as well  <ul><li>Discovery meetings </li></ul><ul><li>JAD sessions </li></ul><...
Stock your requirements definition tool kit <ul><li>Train analysts on as wide a variety of requirements definition techniq...
Agenda <ul><li>Why requirements practices matter </li></ul><ul><li>Requirements definition offers the most room for improv...
Requirements change is a reality <ul><li>Better requirements definition practices will help reduce unnecessary requirement...
Sample Division Of Responsibilities Between Business And IT September 2006, Trends  “The Root Of The Problem: Poor Require...
Waterfall processes treat requirements change as the exception <ul><li>Requirements are defined at the beginning of the li...
Iterative processes are built to accommodate requirements change <ul><li>Incremental, iterative development processes cons...
Agenda <ul><li>Why requirements practices matter </li></ul><ul><li>Requirements definition offers the most room for improv...
Definition <ul><li>Requirements management  is the process of tracking requirement status, controlling changes to requirem...
Life without a requirements management tool “ We often hear that requirements have been overlooked. The link between what ...
Guidelines for requirements management tool selection <ul><li>Avoid tools that are too complex: </li></ul><ul><ul><li>Busi...
Evaluation criteria for RM tools <ul><li>High-level feature categories: </li></ul><ul><li>Security </li></ul><ul><li>Audit...
Agenda <ul><li>Why requirements practices matter </li></ul><ul><li>Requirements definition offers the most room for improv...
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 i...
Overview of requirements disciplines <ul><li>For most shops, requirements definition is where the real opportunity for imp...
Different strategies for different problems <ul><li>Pay attention to requirements definition for:  </li></ul><ul><ul><li>I...
Agenda <ul><li>Why requirements practices matter </li></ul><ul><li>Requirements definition offers the most room for improv...
Where do they come from? <ul><li>The business </li></ul><ul><li>Project management </li></ul><ul><li>Testing </li></ul><ul...
Where do they report? <ul><li>The business </li></ul><ul><li>The IT organization </li></ul><ul><ul><li>Business analysis t...
What qualities make them successful?  <ul><li>Communication skills </li></ul><ul><li>Facilitation skills </li></ul><ul><li...
What makes their job so hard — and so important? <ul><li>Business analysts straddle both business and IT: </li></ul><ul><u...
How can they be developed? <ul><li>Exposure, exposure, exposure: </li></ul><ul><ul><li>To requirements definition techniqu...
Thank you Carey Schwaber +1 617/613-6260 [email_address] www.forrester.com
Selected bibliography <ul><li>September 14, 2006, Teleconference “What’s New In Application Development Processes And Meth...
Upcoming SlideShare
Loading in...5
×

Carey Schwaber Analyst Forrester Research

488

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
488
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
11
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Carey Schwaber Analyst Forrester Research

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

    Clipping is a handy way to collect important slides you want to go back to later.

×