Best Practices for Collecting User Requirements

1. Best Practices for Collecting User Requirements Gerry Clancy Glenn Berger

2. Requirements Provide direction for program success

3. Why Requirements are Important? Early mistakes lead to costly fixes

4. Build for Value Requirements evolve over time Standish Group Study Reported at XP2002 by Jim Johnson, Chairman 20% - Often or Always 64% - Rarely or Never

5. Where do Requirements fit? Waterfall implementation Hours Months

6. Where do Requirements fit? Agile implementation

7. Where do Requirements fit? Source: Vikas Thange Blog

8. What Benefits? Increase Productivity Streamline Processes Reduce Costs Business Types of Requirements Meet Goals Derive Benefits Business, Functional/Technical, COTS Performance Usability Quality Operational Standards Infrastructure What NOT how Clear Define workflow Testable Functional Quality of Service “What?” “How Well?” “What Constraints?” Solution Concept Leverage COTS components

9. Implementing an Enterprise GIS Project So how do you get there…. Prioritize workflows Assess business workflows Discuss similar industries Add Details Create a plan Conduct kickoff meeting

10. Kickoff meeting

11. Approach and Agenda Kickoff meeting Smaller working groups

12. Similar industries …what are the GIS Patterns that apply Collect organize and exchange data Turn data into information products Provides a common operating picture Get information into and out of the field Get feedback and make informed decisions Add a spatial component to the decision making process Asset Management Planning & Analysis Operational Awareness Field Mobility Stakeholder Engagement Location Analytics ArcGIS

13. GIS Solutions Meter Data Collection Air Pollution Analysis Campus Navigation Fire Hydrants Building Permit Management Air Quality Sensors Partner Award ARIA Technologies France Valarm California Cityworks Oklahoma GISi Washington SSP Innovations Tennessee CityView Canada Road Construction Planning Work Orders District Planning Wilson Pym May Philippines Isovist New Zealand Trimble Illinois

14. How to collect business needs…

15. Organization overview

16. Focus on the business workflow

18. Water Department

19. So what should be in your GIS Plan?

20. Requirements and Analysis

21. Next Steps – How to add details to your business requirements Evolutionary Refinement of Requirements Product Backlog • Requirements • Who is it for? • What is the result? • Why is it needed? Daily Review Sprint Cycle <30 Days Working Increment Tasks

22. User Story • Simple, brief descriptions of functionality • Primarily from a user (role) perspective • Sized for planning • Testable

23. As a [role], I can [feature] so that [reason]

24. Field Worker Public Citizen Real Estate Manager Data Provider Analyst

25. As a data provider I need to be able to upload my data to the client on a monthly basis, so that I can provide the most up-to-date data for analysis. As a real estate manager, I need to interact with a map to explore new locations. User Stories Simple and concise As an analyst, I need the ability to create a map with pop-ups to build easy-use-maps for management. As a public citizen, I need to interact with a map to see where new permits are allowed and potential site my new business. As a real estate manager, I need interactive map capability on my iPad so that I can travel minimalistic during site visits. As a real estate manager, I need to receive information by clicking on potential sites to better understand the property. As an analyst, I need to the ability to run hurricane models from Provider X and see the results on a map, so that I can better understand the impact on our book of business.

26. User stories facilitate a conversation with the team Development Lead Product Owner Hey! Something to look at, talk about, comment on, react to… The team Stakeholders

27. As an analyst, I need the ability to create a map with pop-ups to build easy-use-maps for management. User Stories As a real estate manager, I need to be able to see a pie chart of surrounding demographics so that I can match consumer demand with product. Progressively decompose your stories As a real estate manager, I need to interact with a map to explore new locations. As a real estate manager, I need to receive information by clicking on potential sites to better understand the property. As a real estate manager, I need interactive map capability on my iPad so that I can travel minimalistic during site visits.

28. User Stories Consider grouping them into themes ~~~~~~~~~~~ ~~~~~~~~~~~~~ ~~~~~~~~ ~~~~~~~~~ ~~~~~~~~~~~ ~~~~~~~~~~~~~ ~~~~~~~~ ~~~~~~~~~ ~~~~~~~~~~~ ~~~~~~~~~~~~~ ~~~~~~~~ ~~~~~~~~~ ~~~~~~~~~~~ ~~~~~~~~~~~~~ ~~~~~~~~ ~~~~~~~~~ ~~~~~~~~~~~ ~~~~~~~~~~~~~ ~~~~~~~~ ~~~~~~~~~ ~~~~~~~~~~~ ~~~~~~~~~~~~~ ~~~~~~~~ ~~~~~~~~~ ~~~~~~~~~~~ ~~~~~~~~~~~~~ ~~~~~~~~ ~~~~~~~~~ ~~~~~~~~~~~ ~~~~~~~~~~~~~ ~~~~~~~~ ~~~~~~~~~

29. Not always about [a user] Capture key concepts As a user interface, I need to look like the following image so that I can be intuitive to use

30. Use Paper Cards Keep them simple and concise

31. Example – Leak Management – Isolation Trace Decomposing work into manageable pieces Most Detailed – Test Case Titles Use Cases Locate by address Locate Leak Locate with Map User Story As a Field Engineer I need to run an Isolation Trace to identify network leaks, and improve the quality of water service to all customers. Pick Trace Starting Point Select from map Configure Options Run Trace Execute Trace Save Trace Field Crew Launch Mobile App Locate Leak Run Isolation Trace Notify Customers Fix Leak Display Trace Results “Trace Map” Summary Report Detail Report

32. Keep user stories visible Focus of daily meetings

33. Requirement Management Tools Licensed and Open Source Microsoft Team Foundation Server (TFS) JIRA

34. Requirements Process Things to avoid • Avoid long lists of requirements • Do not be judgmental • Prepare for conflicting requirements • Avoid requirements that are ambiguous • Avoid requirements that describe HOW (unless you are using COTS approach) • Don’t forget to prioritize • Requirements must have a “reason”

35. Requirements THE most important part of a project • Solid requirements gathering leads to successful projects • Consider solution, COTS capabilities before collecting additional requirements • Involve the right people in the process • Pick a methodology that fits your project • Focus on the level of detail that is appropriate • Important to prioritize and allocate • Invest plenty of time to secure customer approval

36. References • Agile & Iterative Development: A Manager’s Guide by Criag Larman, Addison-Wesley ,2003 • Software Requirements (2nd Edition) by Karl Wiegers, Microsoft Press, 2003 • Use Case Driven Object Modeling with UML by Doug Rosenberg and Matt Stephens, Apress, 2008 • Writing Effective User Cases, A Cockburn, Addison-Wesley, 2001 • Agile Development with ICONIX Process by Doug Rosenberg, Matt Stephens, and Mark Collins, Apress, 2005

37. References www.agilemanifesto.org http://alistair.cockburn.us/ http://www.iconixsw.com/ http://www.pmi.org/default.aspx

38. Where to go From Here? * Repeat Sessions

39. Thanks Gerry Clancy – gclancy@esri.com Glenn Berger – gberger@esri.com