Your SlideShare is downloading. ×
0
PCT2010 - Requirements Simplified
PCT2010 - Requirements Simplified
PCT2010 - Requirements Simplified
PCT2010 - Requirements Simplified
PCT2010 - Requirements Simplified
PCT2010 - Requirements Simplified
PCT2010 - Requirements Simplified
PCT2010 - Requirements Simplified
PCT2010 - Requirements Simplified
PCT2010 - Requirements Simplified
PCT2010 - Requirements Simplified
PCT2010 - Requirements Simplified
PCT2010 - Requirements Simplified
PCT2010 - Requirements Simplified
PCT2010 - Requirements Simplified
PCT2010 - Requirements Simplified
PCT2010 - Requirements Simplified
PCT2010 - Requirements Simplified
PCT2010 - Requirements Simplified
PCT2010 - Requirements Simplified
PCT2010 - Requirements Simplified
PCT2010 - Requirements Simplified
PCT2010 - Requirements Simplified
PCT2010 - Requirements Simplified
PCT2010 - Requirements Simplified
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

PCT2010 - Requirements Simplified

1,922

Published on

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 …

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.

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,922
On Slideshare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

  • 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.

  • Transcript

    • 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
    • 2. Welcome to Hell
    • 3. In 10,000 years our requirements will not be retold around campfires...
    • 4. In 10,000 years our requirements will not be retold around campfires... Our Stories will.
    • 5. In Lean/Agile (especially XP and Scrum), stories are the requirement gathering tool of choice
    • 6. Confession
    • 7. I I’m a Hardware Guy
    • 8. Stories User’s Needs Product Description Planning Items An Mechanism for Conversation
    • 9. 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?)
    • 10. 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
    • 11. Build Out User “Profiles”
    • 12. 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
    • 13. 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
    • 14. 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),
    • 15. ABC+
    • 16. A bsolute B est C ost +
    • 17. A bsolute B est C ost + (Plus Factors)
    • 18. (Plus Factors) Features or Attributes That a customer will specifically pay for
    • 19. Great Places for More • www.infoq.com • www.AgileProductDesign.com • http://innovationgames.com/
    • 20. Requirements Simplified Rod Hardman

    ×