Creating effective Product Requirements documents takes a lot of effort, often undermining whether they actually get done. Much of what is written is rarely implemented and the details are not always static as they change when the team learns what it really wants. This session would sort through what is really needed in a Requirements document focusing on what actually gets done.
1. Requirements Simplified
OR HOW TO GET YOUR ENGINEERS TO SPEND
MORE TIME CREATING WHAT CUSTOMERS
REALLY WANT...
ROD HARDMAN
www.productcamp.org/toronto
May 30, 2010 – Ted Rogers School of Management, Ryerson University
11. Stories
User’s Needs
Product Description
Planning Items
An Mechanism for Conversation
12. Stories:
have a title
a description:
As a [type of user]
I want to [perform some task]
so that I can [reach some goal]
Add Additional details notes,
specifications, or sketches
and acceptance criteria (how do we know
when we’re done?)
13. Title: Look up Dog Parks
As a Dog Owner
I want to Look up Dog Parks
So that I can find a Park in my area for my Dog
15. A collection of stories for a
product is referred to as the
product backlog
The backlog is prioritized such
that the most valuable items
are highest
16.
17.
18. Why Use Stories?
Minimum Viable Description
Develop a Shared understanding - Quickly
How fast can you put a product in front of a customer
Defence - Protect your funding
19. Innovation Games
Luke Holmann
Product Box: Participants imagine that theyʼre selling a vendorʼs product at a tradeshow,
retail outlet, or public market. Participants use plain cardboard boxes, glue, paint, crayons, and other
scraps and knickknacks to design a product box that they would buy.
Prune the Product Tree: A very large tree (representing a system or product)
is drawn on a whiteboard. Thick limbs represent major areas of functionality within the system. The edge
of the tree—its outermost branches—represent the features available in the current release of the
product. Participants write new features on several index cards that are shaped like leaves, and then they
place these feature-leaves onto the tree, revealing which branches (product features) are important to
customers for future improvements
Buy a Feature: Participants see a list of proposed product features and a cost
(expressed as development effort or street-level pricing) associated with each. Each participant “buys” a
desirable feature; participants may also pool resources to buy features too expensive to be purchased
with individual funds.
Luke Hohmann, Innovation Games: Creating Breakthrough Products through Collaborative Play
(Boston: Addison-Wesley, 2007),
In systems engineering and software engineering, requirements analysis encompasses those tasks that go into determining the requirements of a new or altered system, taking account of the possibly conflicting requirements of the various stakeholders, such as users. Requirements analysis is critical to the success of a project.
Systematic requirements analysis is also known as requirements engineering. It is sometimes referred to loosely by names such as requirements gathering, requirements capture, or requirements specification. The term "requirements analysis" can also be applied specifically to the analysis proper (as opposed to elicitation or documentation of the requirements, for instance).
Requirements must be measurable, testable, related to identified business needs or opportunities, and defined to a level of detail sufficient for system design.
Before we begin and get too far along - a Confession:
Now I’ve worked on Software and
with Application Service Providers And
Software as a Service
Product Box: Participants imagine that they’re selling a vendor’s product at a tradeshow, retail outlet, or public market. Participants use plain cardboard boxes, glue, paint, crayons, and other scraps and knickknacks to design a product box that they would buy.
Prune the Product Tree: A very large tree (representing a system or product) is drawn on a whiteboard. Thick limbs represent major areas of functionality within the system. The edge of the tree—its outermost branches—represent the features available in the current release of the product. Participants write new features on several index cards that are shaped like leaves, and then they place these feature-leaves onto the tree, revealing which branches (product features) are important to customers for future improvements
Buy a Feature: Participants see a list of proposed product features and a cost (expressed as development effort or street-level pricing) associated with each. Each participant “buys” a desirable feature; participants may also pool resources to buy features too expensive to be purchased with individual funds.
Absolute Best Cost
is a theoretical product in the category
It barely Powers on, (or runs)
etc. It is minimal Viable product
1:30-2:15 pm (Session 3)
Requirements Simplified – Rod HardmanCreating effective Product Requirements documents takes a lot of effort, often undermining whether they actually get done. Much of what is written is rarely implemented and the details are not always static as they change when the team learns what it really wants. This session would sort through what is really needed in a Requirements document focusing on what actually gets done.