Giving a functional spec to developers and testers is not sufficient for creating great software. To a developer, a spec is only the what and not the why. And for a tester, the software requirements specification is neither. Use cases provide the why that explains the intent of the system for the implementation team.
Communicating Intent With Stakeholders
We can build a prototype of what the stakeholders don’t want, and then get feedback and fix it. Or we can review use cases of what we intend to build, confirm that each stakeholder wants it, and build it right the first time.
Four Assumptions of the Apocalypse
Business Analysts often start with four erroneous assumptions when eliciting requirements. 50% of errors in software projects are caused by requirements errors. These four faulty assumptions, presented by James A. Ward, can exacerbate the error-prone process of gathering requirements.
Verify Correct Requirements with Use Cases
The next piece in the puzzle of how and why we apply use cases to product management. Verification of requirement correctness.
Product Managers Play Tug-of-War
63% of product managers report to marketing and 24% report to development. 22% of requirements managers report to marketing with 55% in the development organization. These reporting structures can over-emphasize the needs of new users and super-users, while shortchanging the needs of the majority of users. Product managers will constantly be playing tug-of-war to get time to do the right thing.
Requirement Completeness Validation with Use Cases
In our article, The 8 Goals of Use Cases, the first goal is that our use cases must support requirement-completeness validation. In this article, we explore how to address this goal and how use cases can help. There are many pieces to this puzzle, and this article is one of them.
Extra Features Cause $245,000 Loss
Robin Lowry has posted a story of a demo gone horribly wrong at The Product Management View. In the story, users end up confused by the myriad of features of the software – resulting in a $5,000 sale instead of a $250,000 sale.
The Use Case For Creating Goal-Driven Use Cases
There are 8 reasons we write use cases. Most of the benefits of documenting use cases come from communication, but all of the benefits depend upon the initial creation of the use case. The first step to determining the best way to create the use case is to understand the use case of creating use cases.
Know Thy Customers’ Markets
Michael on Product Management and Marketing has posted the first in his series of product management commandments – Know Thy Customer. He provides five tips on how to know your customer better. We extend his idea to include understanding our customers’ markets, and provide more tips. By analogy, this is the difference between a detective who studies a criminal and a profiler who seeks to understand a class of criminals.