via Mike Gilpin

It's a real pleasure for me to be able to bring you some insights that emerged from the Forrester Leadership Board's Application Development & Delivery Council during 2010. My colleague Julia Spencer, an Advisor to the council, has written up these insights, which I have pasted in below, but we are inviting you to enter the discussion as well. Thanks, Julia, for bringing us this wisdom and for helping us get a peek inside this exclusive community of application delivery leaders:

From Julia Spencer:

During 2010, the Forrester Leadership Boards’ (FLB) Application Development & Delivery Council (AD&D Council) tackled many issues, including that of defining and managing requirements for more-effective application delivery. As a Council Advisor, I receive many questions about requirements, such as “How do you define a quality requirement?” I’d like to share some best practices revealed during our Member Meetings in Las Vegas, Nevada, and Lisbon, Portugal, and our highly interactive CouncilTel (FLB group discussion) on software requirements.

I’d love your feedback: Which best practices have worked for you? What is missing from the list?

First: What are requirements, and why do they matter?

I have learned that the word “requirements” means different things to different people, and some struggle to define the word altogether.

In Mary Gerush’s report, Exploit The Real Requirements Life Cycle, she cites the International Institute of Business Analysis’ (IIBA’s) Business Analysis Body of Knowledge (BABOK), which defines a requirement as “a condition or capability needed by a stakeholder to solve a problem or achieve an objective.” But it’s not that simple: The BABOK also describes a requirements taxonomy. Business requirements represent high-level enterprise objectives, stakeholder requirements describe how the stakeholders will interact with a solution, and solution requirements describe the functional and nonfunctional capabilities the solution must deliver.

The report also states that the BABOK leaves room for interpretation, recognizing the ambiguity of the term and encouraging readers to take a broad perspective of requirements, stating that: "[They] include but are not limited to past, present, and future conditions or capabilities in an enterprise, and descriptions of organizational structures, roles, processes, policies, rules, and information systems. A requirement may describe the current or the future state of any aspect of the enterprise."

How do poor requirements impact your organization?

Why do we need to improve requirements? Why are they important? During one of this year’s AD&D Council’s in-person member meeting sessions — The Transformation to Business Technology Requires Focus and Simplicity — Mary Gerush led a group discussion on the real cost of poor requirements and how organizations are improving them.

Our research and members stated that:

• Postproduction defect correction is pricey; having to go back and confirm or redefine requirements costs more than getting them right the first time.
• Developers can interpret a requirement incorrectly if it’s not defined well, resulting in a solution that doesn’t solve the business problem.
• Requirements are commonly inflated. Only 60% of delivered functionality may be used, and solutions are often overengineered, resulting in high cost with minimal return on investment.

What makes a good BA?

This is another common client question: What do BAs need to know? What skills do they need? We’ve learned from the Council that:

• Business partners have little patience with BAs that don’t know the business. Strong BAs have both business and technical knowledge.
• BAs can’t just “gather” requirements; this implies there is no real understanding, no analysis, and no discussion with the business to hone the need.
• BAs need to know the right questions to ask. One critical question is: “Does the business partner understand the requirement and the value to the business of that requirement?” BAs need this visibility to author good requirements.
• BAs need the ability to critically analyze and challenge the information provided and to assess the impact of requirements change.

How has the AD&D Forrester Leadership Board addressed their requirements challenges?

A discussion on our FLB exclusive online site identifies lessons learned and best practices. On that thread, one member stated that to define good requirements, he’s learned that it’s important to:

• Include a high-level requirements risk assessment as part of the business case.
• Clearly define the type of BA each project needs based on the project type.
• Disconnect the project sponsor and stakeholders from the technology solution early.
• Ensure the BAs access to the right stakeholders.
• Describe the relationship between business, functional, and technical requirements and where they come into play during the project life cycle.

In addition, some members have:

• Established a business analyst community of practice. All BAs get together on a regular basis to share learnings, ideas, and best practices.
• Created two business analyst organizations. One has very broad experience, and the other has very deep experience.
• Emphasized requirements specificity. For example, if the requirement states “the system needs to respond immediately,” they teach their BAs to eliminate ambiguousness by defining “immediately.” “Is that three seconds or five?”

How are members improving requirements definition?

During our CouncilTel — Requirements Definition: Let’s Get Visual! — the group shared ideas, best practices, and lessons learned on approaches, processes, and tools for requirements definition. Key takeaways include an understanding that:

• BAs can depict requirements in different ways, including the use of documents and spreadsheets (text + data), models and diagrams (context diagrams, use cases, process flows, user stories, scenarios), and wireframes, mockups, and storyboards.
• They are increasingly using more pictorial artifacts — combined with text — to represent requirements.
• BAs are creating artifacts for their own use. The consumer of the BA’s artifact can be the BA herself to help analyze and pull ideas together.
• It’s critical to identify and repair poorly defined requirements definition processes.
• BAs should focus on user experience, and new visualization tools, such as iRise, can help.

During the CouncilTel, we heard directly from clients that they:

• Are creating more pictorial artifacts using tools that support context diagramming, process modeling, and use case diagramming.
• Are using tools that help them create prototypes, visualizations, and simulations. Certain members commented that:

o   They evaluated iRise, and it scared their technical team; they are also looking into Blueprint.

o   They are looking into these tools in the first quarter of 2011.

o   They’re looking into IBM Rational Requirements Composer and other tools over the next year.

o   It’s important to know that a tool adds value and not just overhead. The tool needs to fit the project size.

o   They feel like creating diagrams doubled their work, because they created verbiage in parallel.

• Are cross-training teams on requirements, teaching all teams to be smarter about how they can get results out of IT and find out what is most valuable
• Have found that the most useful pictorial artifacts for:
  • Business stakeholders are workflows and data flows.
  • Designers and developers are use cases.
  • Testers’ preferences vary based on who is doing the testing — internal people need less detail than when you are using an offshore testing team.

After reviewing what our Application Development & Delivery Council learned, shared, and discussed, it appears we have made some progress toward solving the requirements challenge. Do you agree with the statements of the AD&D Council FLB members? And what can you add to this thread about requirements?

For more information about Forrester’s Application Development & Delivery Council, please contact Jeanne Strepacki.

Related Forrester Research:

Find And Grow Great Business Analysts

Business Analyst Assessment Workbook

Harness The Power Of Your Business Analysts

Just Do It: Modernize Your Requirements Practices

Your 2009 Business Analysts: Know Them To Grow Them

Learn More About Your 2009 Business Analysts

Best Practices: Your Ten-Step Program To Improve Requirements And Deliver Better Software

Align BAs And Quality Assurance Professionals To Drive Higher Quality — And Happier Customers

Business Analysts: Seize The Opportunity To Deliver Compelling User Experiences

Case Study: The IRS Got Audited, Leading It To Improve Software Requirements Practices

Right Tools. Write Requirements. Right On!

Exploit The Real Requirements Life Cycle

Thinking Lean: How Much Requirements Documentation Is "Just Enough"?

Upcoming Related Research:

What’s In The Strong BA’s Tool Kit

Say Hello To Your 2011 Business Analysts