Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

Functional requirements: Thinking Like A Pirate

5.054 visualizaciones

Publicado el

This talk was at OpenSourceBridge 2010: We covered professional services in open source and writing functional requirements to support your projects.

Publicado en: Tecnología, Empresariales
  • Sé el primero en comentar

Functional requirements: Thinking Like A Pirate

  1. 1.   Functional Requirements        Think Like A Pirate Amye Scavarda - Bill Fitzgerald - June 2 - OpenSourceBridge
  2. 2. Howdy! <ul><li>Bill is:  </li></ul><ul><li>  </li></ul><ul><ul><li>Founding Partner of FunnyMonkey.com </li></ul></ul><ul><ul><li>Author of Drupal for Education </li></ul></ul><ul><ul><li>Really involved in making better websites for education </li></ul></ul><ul><ul><li>  </li></ul></ul><ul><li>bill@funnymonkey.com  </li></ul><ul><li>@funnymonkey </li></ul><ul><li>Amye is: </li></ul><ul><ul><li>Founder of Function createfunction.com </li></ul></ul><ul><ul><li>Makes open source website development hurt less for clients, developers and designers </li></ul></ul><ul><li>[email_address] </li></ul><ul><li>@msamye </li></ul>
  3. 3. And You Are? <ul><li>Developers? </li></ul><ul><li>Project Managers? </li></ul><ul><li>Owners? </li></ul><ul><li>Designers? </li></ul><ul><li>Freelancers? </li></ul><ul><li>People in companies of over 300 people? </li></ul><ul><li>We'll be taking questions on Google Moderator here: http://goo.gl/mod/wfYI  </li></ul><ul><li>But just ask us stuff. </li></ul>
  4. 4. Why We're Talking Like Pirates <ul><li>Except we're not actually talking like pirates.  </li></ul><ul><li>  </li></ul><ul><li>  </li></ul><ul><li>We're talking like people who run professional services and development companies based in open source.  </li></ul>
  5. 5. What We're Doing Here: <ul><ul><li>Introducing Functional Requirements in a professional services setting </li></ul></ul><ul><ul><li>Discussing a few models of functional requirements  </li></ul></ul><ul><ul><li>Giving you a checklist for your own functional requirements </li></ul></ul><ul><ul><li>Telling stories about how we came around to writing functional requirements in Agile. </li></ul></ul>
  6. 6. Because we like being able to make a living <ul><li>Running a professional services company in open source is an awesome model.  </li></ul><ul><li>Except for: </li></ul><ul><li>Timetracking is a pain. </li></ul><ul><li>Billing for your time is a pain.  </li></ul><ul><li>Being a consultant is a pain. </li></ul><ul><li>But this is a model for how to do the thing you love and not be a starving artist. </li></ul>
  7. 7. Managing This Is A Bear <ul><li>  </li></ul>Photograph by John Eastcott and Yva Momatiuk
  8. 8. Hours Worked  = Hours Paid <ul><li>  </li></ul><ul><li>  </li></ul>
  9. 9. What are these function-whatsits? <ul><ul><li>A way to know when your projects are finished </li></ul></ul><ul><ul><li>A way to mark out a good roadmap for what  your client wants  </li></ul></ul><ul><ul><li>An example of good business practices  </li></ul></ul>
  10. 10. What are they not? <ul><li>They're not: </li></ul><ul><ul><li>A substitute for people who care about what they're doing </li></ul></ul><ul><ul><li>A substitute for operations support </li></ul></ul><ul><ul><li>A substitute for creativity and listening </li></ul></ul><ul><ul><li>The Holy Grail of Project Awesomeness </li></ul></ul>
  11. 11. Your Treasure Map <ul><li>We've established our motivations: running a successful business, doing work that matters, getting our people paid, getting our clients what they wanted. </li></ul><ul><li>Your motivations may be different from ours. </li></ul><ul><li>We'll walk through a few different models. </li></ul>
  12. 12. <ul><li>Commonly referred to as SRS: Software Requirements Specifications. This is the management-approved, 15 different signatures for change control documents.  </li></ul><ul><li>  </li></ul><ul><li>These include:  </li></ul><ul><ul><li>Scope </li></ul></ul><ul><ul><li>Referenced Documents,  </li></ul></ul><ul><ul><li>Requirements (including all CSCI requirements)  </li></ul></ul><ul><ul><li>Qualification Provisions </li></ul></ul><ul><ul><li>Requirements Traceability </li></ul></ul><ul><ul><li>Notes </li></ul></ul>Shall  - Will  - Must:
  13. 13.   Series of Checklists <ul><li>Lists for: </li></ul><ul><ul><li>Discovery </li></ul></ul><ul><ul><li>Development Environment </li></ul></ul><ul><ul><li>Design Phases </li></ul></ul><ul><ul><li>Wireframes </li></ul></ul><ul><ul><li>Builds </li></ul></ul><ul><ul><li>Client Signoff </li></ul></ul><ul><ul><li>Launch </li></ul></ul><ul><ul><li>Post-Launch Support </li></ul></ul>
  14. 14.   Hieroglyphics <ul><li>Your documentation and roadmap as a graphic novel:  </li></ul>
  15. 15. Turning this: David Rees - www.mnftiu.cc
  16. 16. Into this: Rebeka Sedaca - http://www.boxesandarrows.com/view/comics-not-just-for
  17. 17. Answering the Big Questions <ul><ul><li>Legacy Systems? </li></ul></ul><ul><ul><li>How Does This Development Support Their Long Term Goals? </li></ul></ul><ul><ul><li>How Did Current Systems Come to Be? </li></ul></ul><ul><ul><li>What Would Happen If Nothing Got Done? </li></ul></ul><ul><li>  </li></ul><ul><li>My personal philosophy is not to undertake a project unless it is manifestly important and nearly impossible. </li></ul><ul><li>Edwin Land (Polaroid camera inventor) </li></ul>
  18. 18. Tools <ul><ul><li>Client Intake Surveys </li></ul></ul><ul><ul><li>Stakeholder Interviews </li></ul></ul><ul><ul><li>Existing Technical Documentation </li></ul></ul><ul><ul><li>Existing End User Training Documentation </li></ul></ul><ul><ul><li>Organization Charts: who does what </li></ul></ul>
  19. 19. How to make something that works for you: <ul><li>Written Requirements Doc </li></ul><ul><li>Wireframes </li></ul><ul><li>Milestones and Time Estimates </li></ul><ul><li>Identified Communication Leads </li></ul><ul><li>(a ticket system that works) </li></ul>
  20. 20. Answering the Immediate Timeframes <ul><ul><li>Why is this project happening now? </li></ul></ul><ul><ul><li>What other pieces are tied to this project?  </li></ul></ul><ul><ul><li>What pieces are your project anchors?  </li></ul></ul><ul><li>  </li></ul><ul><li>Beware the time-driven project with an artificial deadline. </li></ul><ul><li>M. Dobson  </li></ul>
  21. 21. Answering the Long-Term Goals <ul><li>Who is this system designed to support?  </li></ul><ul><li>For how long? </li></ul><ul><li>Are there any plans to replace this system in the future? With what?  </li></ul>telegraph.co.uk neospiel.co.uk
  22. 22. Creating a Scope of Work <ul><ul><li>What can we do now?  </li></ul></ul><ul><ul><li>Is it the best thing we can do now? </li></ul></ul><ul><ul><li>What can we do not-right-now, but later? </li></ul></ul><ul><ul><li>The importance of wireframes </li></ul></ul>
  23. 23. Outlining Your Process <ul><li>Communicating with Lead Stakeholders  </li></ul><ul><li>Having the 'What Does Agile Mean' conversation with your clients... Or not. </li></ul>
  24. 24. Marking Red Flags Ahead of Time <ul><ul><li>What issues are a technical challenge for your team? (What do you mean by this COBOL thing?) </li></ul></ul><ul><ul><li>What issues are a technical challenge for the client? (We can't even spell HTML) </li></ul></ul><ul><ul><li>What kind of security does this particular project need to have?  </li></ul></ul><ul><ul><li>What kind of bandwidth support? </li></ul></ul>
  25. 25. Both Sides <ul><li>How Projects are Like a Tug of War </li></ul><ul><li>  </li></ul><ul><li>  </li></ul><ul><li>  </li></ul><ul><li>  </li></ul><ul><li>  </li></ul><ul><li>  </li></ul><ul><li>Each Side Has To Pull Equally </li></ul>http://www.johannthedog.com http://www.johannthedog.com
  26. 26. That Tricky Open Source Thing You Do <ul><li>What happens when your product changes?  </li></ul><ul><li>  </li></ul><ul><li>What happens when your team changes course?  </li></ul>
  27. 27. Wrapping it All Up <ul><li>Using this as a guiding document for the rest of your project </li></ul><ul><li>  </li></ul><ul><ul><li>With yourself </li></ul></ul><ul><ul><li>With your team </li></ul></ul><ul><ul><li>With your stakeholders </li></ul></ul>
  28. 28. Thanks! <ul><li>Google Moderator has questions. </li></ul><ul><li>But we're sure you do too. </li></ul><ul><li>  </li></ul><ul><li>  </li></ul><ul><li>Amye Scavarda: http://createfunction.com </li></ul><ul><li>  </li></ul><ul><li>Bill Fitzgerald: http://funnymonkey.com/blog </li></ul>

×