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 / 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
Communication / Lists / Product Management / Requirements / Writing
Posted on:
MRD Writing Tips – Ten from Michael Shrivathsan
Michael has posted five (plus five) tips on writing a market requirements document (MRD). Michael has written a good set of tips with detailed explanations and anecdotes. We have re-organized these tips into three general areas of guidance and provide our thoughts.
Communication / Product Management / Requirements / Software requirements specification / Writing
Posted on:
Requirements Documents – One Man’s Trash
…Is another man’s treasure. There are many different ways to document requirements when developing software. And there is a proliferation of requirements documents – MRD, PRD, SRS, FRS and design documents. Everyone has a perspective on what each document represents, and each person on the team has a unique perspective on what questions the document answers.
Product Management / Requirements / Requirements gathering
Posted on:
Product Manager Role Definition
Michael has posted a great definition of the product manager role on his blog, Product Management and Product Marketing – A Definition. He covers a whole host of activities in six seperate areas. Some of the responsibilities, while not product management, are often the responsibility of the product manager. It’s a good real-world assessment of what product managers are often asked to do.
Consulting / Outsourcing / Product Management / Software development
Posted on:
Four Application Development Outsourcing Models
On March 30th CIO magazine published an article titled Do’s and Don’ts of Outsourcing Benchmarks. The article spurred us to write about outsourcing models for product development – it is otherwise unrelated, but interesting. [2015 Edit: The CIO article has been removed, check out these lessons from successes and failures […]
Communication / Product Management / Requirements / Requirements gathering / Software requirements specification
Posted on:
Product management success in the conceptual age
The information age is ending and the conceptual age is beginning. In A Whole New Mind, Daniel Pink proposes that six characteristics of right-brain thinking are key to success in the new economy. Nils Davis realizes that these characteristics are embodied by good product managers today. We will define the conceptual age, review the six characteristics, and see how this applies to product management.
Interaction design / Requirements / Requirements Models / Software development / Software requirements specification / Use Cases / UX
Posted on:
Interaction Design and Structured Requirements
subtitle: Wiegers and Cooper assimilated
Wiegers promotes structured requirements. Cooper touts Interaction Design. Both have great ideas. Both “wave their hands” at parts of the process. In this post, we’ll talk about how to combine the two philosophies to get the best of both worlds.
Agile / Interaction design / Requirements / Requirements gathering / Software requirements specification / UX
Posted on:
Interaction design explained by Alan Cooper
There’s a Clash of the Titans joint-interview posted at FTPOnline between Kent Beck and Alan Cooper called Extreme Programming vs. Interaction Design. It’s 10 pages of back and forth. In short, these icons agree on objectives, and disagree on how to achieve them. They also spend some time (mis)characterizing each other’s positions and defining their own. In this post we will look at how Alan Cooper explains Interaction Design. We would say that he defines interaction design more as a requirements than a design activity.