CAJ 008-Robin Goldsmith
Meeting Facts:
Speaker: Robin Goldsmith
Topic: Requirements are simply requirements-or maybe not
Date: 02/21/17
Description:
Many people talk about requirements. They use identical terms and think they have a common understanding. Yet, one says user stories are requirements; another claims user stories must be combined with requirements; and yet another has a different approach. These “experts” seem unaware of the critical inconsistencies of their positions. No wonder getting requirements right remains a major challenge for many projects. Robin Goldsmith analyzes several of the often conflicting, not-so-shared-as-presumed interpretations of what requirements are, reveals likely implications, and challenges not-so-wise conventional wisdom. Robin describes a more appropriate model of REAL business requirements whats that provide value when combined with product/system/software hows. He introduces the powerful Problem Pyramid™ systematic disciplined guide to help you more reliably get requirements right. The structure makes it easier to see where user stories do or do not fit, identifies pitfalls of the “as a <role>” format, and reconciles some of the conflicts between user stories, features, use cases, and requirements.
Bio:
Robin Goldsmith, JD, is author of Discovering REAL Business Requirements for Software Project Success, the forthcoming book Cut Creep—Put Business Back in Business Analysis to Discover REAL Business Requirements for Agile, ATDD, and Other Project Success, numerous articles and featured presentations, and the Proactive Testing, Proactive SQA, REAL ROI, and Beyond the Textbook Software Acquisition methodologies. A subject expert on requirements and testing for TechTarget’s SearchSoftwareQuality.com and a subject expert/reviewer for the IIBA Business Analysis Body of Knowledge (BABOK v2), Robin works directly with and trains business/systems professionals in requirements analysis, quality and testing, software.
Slides:
Video Link: https://youtu.be/pfqqYru4H8Q
Quotes:
Questions:
What do you need to look for to determine if your problem pyramid is focused on the wrong things?
Notes:
How do you convince the teams to break stories into small enough parts?
Excessive trivial proliferation
Real business vs product requirements
Issues with story or acceptance criteria
Either too general or too focused
How to do you link business objectives to software features
Should BABOK include shorthand?
Types of requirements
Business=What=Many ways to accomplish
Product=How=Presumed Business requirements (primary discussion)
Products by themselves provide no value. Products only deliver value as they accomplish the business needs
Much of creep occurs because the requirements don’t actually satisfy the business needs. The real business needs have not been defined adequately. Conventional wisdom values the product requirements over the business requirements
What’s don’t decompose into hows. Hows develop into whats.
Business requirements are high level and must be driven down into lower levels of detail. But that detail doesn’t create a product, but it does allow you to map a product how to the business requirement what