Requirements: Whose job are they anyway?


Published on

Discussion of who does requirements and specifications

Published in: Technology, Business
1 Like
  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Requirements: Whose job are they anyway?

  1. 1. DevConFu, Latvia November2013 Requirements: Who’s job are they anyway? allan kelly Twitter: @allankellynet
  2. 2. Allan Kelly…  Consulting on software development & strategy  Training for Agile Author – Changing Software Development: Learning to be Agile (2008, Wiley) – Business Patterns for Software Developers (2012, Wiley - ISBN: 978-1119999249) – Xanpan: Reflections on agile (work in progress) Chapters in… • Business Analysis and Leadership, Pullan & Archer 2013 • 97 Things Every Programmer Should Know, Henney, 2010 • Context Encapsulation in Pattern Languages of Program Design, vol#5, 2006
  3. 3. 3 Styles of Agile Evolutionary • • • • Incremental • • • • Iterative • • • • Development team work in short iterations Regular releases Requirements emerge as team incorporates feedback and discovers new opportunities Cumulative flow diagrams Development team work in short iterations Minor releases frequent Formal requirements document start development with change request incorporated Burn-up more than burn-down Development team work in short iterations Major releases infrequent Formal requirements document (Salami Sliced) Formal change request process in place Burn-down to completion 4
  4. 4. Who does Requirements where you work?
  5. 5. Hang on! What is a Requirement anyway? And what’s the difference between a Requirement and a Specification?
  6. 6. Requirement or Specification? “A requirement is a stakeholderdesired, or needed, target or constraint” Tom Gilb “A ‘specification’ communicated one or more system ideas and/or descriptions to an intended audience. A specification is usually a formal, written means for communicating information” Competitive Engineering, 2005, p.400 & p. 418
  7. 7. A requirement is a desired relationship among phenomena of the environment of a system, to be brought about by the hardware/software machine that will be constructed and installed in the environment. A specification describes machine behaviour sufficient to achieve the requirement. A specification is a restricted kind of requirement … Specifications are derived from requirements by reasoning about the environment, … These ideas, and some associated techniques of description, are illustrated by a simple example. Michael Jackson & Pamela Zave Deriving Specifications from Requirements: An Example, ACM Press 1995
  8. 8. Requirements & Specification • Specifications derive from Requirements – Requirements come first • A requirement – Is the desired outcome • A specification – Context specific – Contains details
  9. 9. Requirements go In Dev Team – Coders, Testers, etc. … Blue Cards Documents, Stories, User Stories, Cukes, Product Backlog Item, Quantum of Value (QoV) Business Value Increment (BVI) Working Software comes out
  10. 10. Requirements go In Dev Team – Coders, Tester s, etc. … Team need to know what is needed Working Software comes out Specifications be worked out inside if necessary
  11. 11. Requirements go In Working Software comes out Stakeholders don’t always agree Things change
  12. 12. An aside: Evaluation • Who does your evaluation? • What criteria do they use? Please please please! Close the loop!
  13. 13. Keep work flowing! Every 2 weeks…. Development Team Working software Teams will be more effective if arteries are clear
  14. 14. Requirements Engineering The Need Side Requirements go In Stakeholders don’t always agree Things change!
  15. 15. Nature Abhors: A Vacuum! • If you are lucky… – Someone will quietly come forward – They will be competent & passionate – They will double up their existing role • If you are unlucky… – Several people will assume the role – They be be incompetent & passionate – They will stop doing their existing role Grass Creative Commons license from WikiCommons by MarcusObal
  16. 16. Whose job a Requirements? It depends…
  17. 17. Business Analysts Business Partners Product Managers Product Analysts Architects, Developers, Dev Managers, Project Managers, Testers, SMEs, …. Well intentioned amateurs The Professionals Requirements Engineering
  18. 18. Requirements? Professionals Product Managers & Business Analysts Amateurs Subject Matter Experts Domain Experts Developers, Dev Managers, Project Managers, Testers, Architects….
  19. 19. Should developers do Reqs? • Possibly… – small work effort, small team • • • • Are they presentable to customers? Is it best use of their skills? Do they have time? Do they have empathy? – with users/stakeholders?
  20. 20. Architects? • Again: Is it the best use of skills? – Do they have the skills? – Do they have the time? • Generally: No – Architects have empathy with tech not people – Architects represent tech & code – Architects should be foil to Requirements people • Only for systems were technology dominates
  21. 21. And the SME/Domain Expert… • Sometimes • Subject Matter Experts are great for Specs – Know detail • But do they… – Have Big Picture? – Are they too close emotionally?
  22. 22. Rocket Scientists • Combine multiple skill sets – Domain knowledge, probably spent time in field – Technology, probably can code – Probably have a PhD • Probably have another title – BA, Product Manager, Architect, … – Chief Engineer – Just roll with it - Who cares about titles?
  23. 23. So who should? • Requirements Engineers – Business Analysts – Product Managers
  24. 24. Requirements Sub-Species Business Analyst “The answers are in this building” • Works: Corporate • Lives: Canary Wharf • Users • Wants: Happy Stakeholders • Measured by: Cost • Professional Proxy Product Manager “The answers are not in this building” • Works: Product Company • Lives: Silicon Valley • Customers • Wants: Happy Customers • Measure by: Revenue • Professional Customer Note: Plural of Customer is The Market
  25. 25. Product Owner huh? • Scrum Product Owner is the Bastard Child of Business Analyst and Product Managers – Neither one or other • Product Owner as defined by Scrum is a pale imitation of a Product Manager • Product Owner is the really important role – (but Scrum Master gets all the attention) • Product Owner is useful alias for a BA or PM – And others…
  26. 26. When worlds collide! “What’s the difference “A customer has a choice to use another product. A user doesn’t.” Allan Kelly between a user and a customer? The difference is a customer has given you their credit card data.” FT 28 Jan 2013 Worlds are increasingly overlapping • BAs need to pay more attention to out there • Prod Mgrs need to pay more attention to in here • Everyone needs to start with real customers
  27. 27. Feedback   
  28. 28. Take-away 1. Who’s job is it? – Horses for courses • • • • Business Analyst Product Manager Specialist SME Rocket Scientist SME 2. Do NOT tolerate vacuums 3. Product Owner is an alias allan kelly Software Strategy Ltd. Twitter: @allankellynet
  29. 29. Partners: