1 / 20

Austin IIBA 20 April, 2012 The Rules of Requirements

Austin IIBA 20 April, 2012 The Rules of Requirements. International Institute of Business Analysis. Scott Sehlhorst. Product management & strategy consultant 8 Years electromechanical design engineering (1990-1997) IBM, Texas Instruments, Eaton

kami
Download Presentation

Austin IIBA 20 April, 2012 The Rules of Requirements

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Austin IIBA20 April, 2012The Rules of Requirements International Institute of Business Analysis

  2. Scott Sehlhorst Product management & strategy consultant 8 Years electromechanical design engineering (1990-1997) IBM, Texas Instruments, Eaton 8Years software development & requirements (1997-2005) > 20 clients in Telecom, Computer HW, Heavy Eq., Consumer Durables 7 Years product management consulting (2005-????) >20 clients in B2B, B2C, B2B2C, ecommerce, global, mobile Agile since 2001 Started Tyner Blain in 2005 Helping companies Build the right thing, right

  3. Why Do We Care… • …About Writing Good Requirements?

  4. Track Record (Standish Group CHAOS Report)

  5. Root Cause Analysis • Failure reasons • What have you seen? • Success factors • What have you seen?

  6. Root Cause Analysis • Failure reasons • Lack of user input • Incomplete requirements • Changing requirements • Lack of exec support • Tech. incompetence • Success factors • User involvement • Exec support • Clear requirements • Proper planning • Realistic expectations

  7. Rules of Requirements • Valuable • Concise • Design Free • Attainable • Complete • Consistent • Unambiguous • Verifiable • Atomic • Passionate • Correct • Stylish

  8. 1. Valuable Requirements

  9. 2. Concise Requirements

  10. 3. Design-Free Requirements • This is really about trust. • The “stack” of problem decomposition alternates between requirements and design. • A business is designed to focus on solving particular problems. • A user designs an approach to solving problems. • A product manager designs a set of target capabilities that (should) help the user and business. • The engineering team designs solutions that embody those capabilities

  11. 4. Attainable Requirements • Can You Build It? • Existing Team • Available Technology • Internal Political Environment • Can You Launch It? • Organizational Dependencies • Legal Restrictions (National, Local, IP)

  12. 5. Complete Requirements • You Cannot Absolutely Determine Completeness • Objective Assessment • Have you identified all of the problems to succeed in the market? • Heuristic Assessment • Have you identified how to completely solve the problems?

  13. 6. Consistent Requirements • Strategic Consistency • Does this requirement work in concert with others to achieve our strategic goals? • Logical Consistency • A requires B • Must have A • Must not have B • Grammatical Consistency • Writing with the same tone, structure, phrasing…

  14. 7. Unambiguous Requirements • Language Introduces Ambiguity • When Writing • Identify the user, the context, the goal • Be precise in language (avoid jargon, symbols) • When Reading • Shared language (e.g. “must” vs. “shall”) • Read The Ambiguity Handbookand you’ll be forever paranoid about misinterpretation of everything you ever write again. Ever.

  15. 8. Verifiable Requirements • Does it Have a Measurable Aspect? • If not, how do you know if you delivered? • Do You Know the Measure of Success? • If not, how do you know what you need to deliver? • Do You Have the Ability to Measure It? • Aha! Time to write another requirement.

  16. 9. Atomic Requirements • Every Requirement Stands on its Own • The Defining Characteristic: • A Requirement Cannot Be Half-Done. It is Either Done, or Not Done.

  17. 10. Passionate Requirements • Be Excited. Be Committed. • Care About • Your Customers & Their Problems • Your Company & Its Strategy • Your Team & Their Enrichment • Your Work & Its Quality • Have Passion • …It Will Show in Your Requirements

  18. 11. Correct Requirements • Are You Focusing on the Correct • Market Segments, Customers, Problems? • Do You Know That These Are the Right Requirements? • Can We Achieve Our Goals Without These Requirements?

  19. 12. Stylish Requirements • Write Consistently • And With Good Style-> • Prioritize Explicitly • Ordered Backlog, not MoSCoW • Write for Your Audience • Use Good Style • The System Must… • Intentional Perspective • Non-Negative • Reference, Don’t Repeat • Gender Indifference • Syntactic Parallelism

  20. Thank You! Scott Sehlhorst http://twitter.com/#!/sehlhorst Twitter https://plus.google.com/110352820346292209511 Google + http://go.tynerblain.com/sehlhorst About Me http://www.slideshare.net/ssehlhorst Slideshare http://tynerblain.com/blog Blog scott@tynerblain.com Email scott.sehlhorst Skype Agile since 2001 Started Tyner Blain in 2005 Helping Companies Build The Right Thing, Right

More Related