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.
Lists / Product Management / Requirements
Posted on:
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.
Lists / Product Management / Requirements / Requirements Models / Use Cases
Posted on:
The 8 Goals of Use Cases
Why do we write use cases? For the same reasons that our users use our software – to achieve a goal. In our case, we want to assure that we are creating the right software. By looking at this goal in more detail, we can make decisions that drive the best possible use case creation. Lets apply our product management skills to writing better use cases by writing an MRD for use cases
Process Improvement / Product Management / Requirements / Requirements management software / ROI / Software development
Posted on:
Companies Will Waste $1B This Year on Software Tools
Gartner reported that companies spent $3.7 Billion USD on application development tools in 2004, with a 5% annual growth rate. The Standish Group has shown that 40% to 60% of project failures are due to requirements failures. At least 1/3 of the money spent on getting more efficient at coding is being wasted – it should be spent on writing the right software.
Product Management
Posted on:
What is Product Management?
For organizations that don’t already appreciate the value of product management, just trying to explain the role can be very challenging. Usually the “strategic product management” responsibilities are distributed throughout the org. Convincing them that a single person should be a product manager (and not also a marketer, project manager, or designer) is like convincing them to eat gum off a fork.
Product Management / Requirements / Requirements gathering
Posted on:
Brainstorming Stirs the Pot
The Wall Street Journal apparently wrote a critique of brainstorming that questions its value. Bob Sutton (professor, author, etc) responds with an entertaining read. Prof. Sutton critiques the data analysis, the experiment execution, and the people involved. Seems the WSJ messed up on everything except the topic.
Communication / Consulting / Product Management
Posted on:
Guerilla Product Management
*(scroll to the bottom and come back) Guerilla Product Management (pdf) is an article available from Sequent Learning Networks, written by Steven Haines. (Hat tip to brainmates for finding it) Steven’s pdf includes 17 golden rules for achieving product management success(no, we won’t do 17 articles on each of them). […]
Product Management / Requirements / Software requirements specification / Writing
Posted on:
Writing Passionate Requirements
One of the ten big rules of writing a good MRD is writing passionate requirements. What in the world is a passionate requirement [they were all wondering]? When you believe in the product, are committed to the work, and aren’t bored, you can write passionately. The goal of a requirement is to create sustained understanding. A dry document can create understanding, but an engaging document will sustain it.
Product Management / Requirements / Software requirements specification / Writing
Posted on:
Writing Atomic Requirements
One of the ten big rules of writing a good MRD is writing atomic requirements. Just as verifiable requirements must be concretely measurable as having been met or not, so must atomic requirements. If a requirement has multiple elements that can be implemented separately, it is not atomic.