- Forrester Councils
- Councils Overview
- log in
Posted by Mike Gilpin on January 13, 2011
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:
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:
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:
In addition, some members have:
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:
During the CouncilTel, we heard directly from clients that they:
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.
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:
Upcoming Related Research:
What’s In The Strong BA’s Tool Kit
Say Hello To Your 2011 Business Analysts
Lead BT Transformation
Develop customer-obsessed strategies to drive growth »
Forrester's CX Index
Predict how actions to improve CX will affect revenue performance.
Measure the customer experiences that matter most »
Free On-Demand and Live Events
Latest events from Forrester analysts, online and in person. »