• Save
Requirements: Whose job are they anyway?
Upcoming SlideShare
Loading in...5
×
 

Requirements: Whose job are they anyway?

on

  • 659 views

Discussion of who does requirements and specifications

Discussion of who does requirements and specifications

Statistics

Views

Total Views
659
Views on SlideShare
602
Embed Views
57

Actions

Likes
1
Downloads
0
Comments
0

3 Embeds 57

http://devconfu.eu 36
https://twitter.com 19
http://www.devconfu.eu 2

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Requirements: Whose job are they anyway? Requirements: Whose job are they anyway? Presentation Transcript

  • DevConFu, Latvia November2013 Requirements: Who’s job are they anyway? allan kelly allan@allankelly.net Twitter: @allankellynet http://www.allankelly.net
  • 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) https://leanpub.com/xanpan 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 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 View slide
  • Who does Requirements where you work? View slide
  • Hang on! What is a Requirement anyway? And what’s the difference between a Requirement and a Specification?
  • 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
  • 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
  • Requirements & Specification • Specifications derive from Requirements – Requirements come first • A requirement – Is the desired outcome • A specification – Context specific – Contains details
  • 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
  • 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
  • Requirements go In Working Software comes out Stakeholders don’t always agree Things change
  • An aside: Evaluation • Who does your evaluation? • What criteria do they use? Please please please! Close the loop!
  • Keep work flowing! Every 2 weeks…. Development Team Working software Teams will be more effective if arteries are clear
  • Requirements Engineering The Need Side Requirements go In Stakeholders don’t always agree Things change!
  • 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
  • Whose job a Requirements? It depends…
  • Business Analysts Business Partners Product Managers Product Analysts Architects, Developers, Dev Managers, Project Managers, Testers, SMEs, …. Well intentioned amateurs The Professionals Requirements Engineering
  • Requirements? Professionals Product Managers & Business Analysts Amateurs Subject Matter Experts Domain Experts Developers, Dev Managers, Project Managers, Testers, Architects….
  • 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?
  • 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
  • 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?
  • 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?
  • So who should? • Requirements Engineers – Business Analysts – Product Managers
  • 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
  • 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…
  • 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
  • Feedback   
  • 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 http://blog.allankelly.net allan kelly Software Strategy Ltd. www.allankelly.net allan@allankelly.net Twitter: @allankellynet
  • Partners: