PCT2010 - Requirements Simplified
•
1 gostou•436 visualizações
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.
Recomendados
Mais conteúdo relacionado
Semelhante a PCT2010 - Requirements Simplified
Semelhante a PCT2010 - Requirements Simplified (20)
Mais de ProductCamp Toronto
Mais de ProductCamp Toronto (20)
Último
Último (20)
PCT2010 - Requirements Simplified
- 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
- 4. In 10,000 years our requirements will not be retold around campfires...
- 5. In 10,000 years our requirements will not be retold around campfires... Our Stories will.
- 6. In Lean/Agile (especially XP and Scrum), stories are the requirement gathering tool of choice
- 9. Confession
- 10. I I’m a Hardware Guy
- 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
- 14. Build Out User “Profiles”
- 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
- 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),
- 20. ABC+
- 21. A bsolute B est C ost +
- 22. A bsolute B est C ost + (Plus Factors)
- 23. (Plus Factors) Features or Attributes That a customer will specifically pay for
- 24. Great Places for More • www.infoq.com • www.AgileProductDesign.com • http://innovationgames.com/
- 25. Requirements Simplified Rod Hardman
Notas do Editor
- 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.