How to Successfully Collect, Analyze and Implement User Requirements Gerry Clancy Glenn Berger

Transcription

1 Esri International User Conference San Diego, California Technical Workshops July 24, 2012 How to Successfully Collect, Analyze and Implement User Requirements Gerry Clancy Glenn Berger

2 Requirements Gathering Why are requirements important Putting requirements in context with your project Fundamentals How to examples - COTS based - Web app for visualization Tools Lessons learned References Discussion

3 Why are Requirements Important? They will define if you have a successful project Define what will be built Foundation for acceptance Affect everyone Most difficult errors to fix if found late in project lifecycle Origin of Development Errors Code 7% Other 10% Design 27% Requirements 56%

4 Who Should be involved? Customer - Sponsor, key users, and stakeholders - IT Team! Implementation Team - Business analyst, technical lead, architect - Project Manager, Quality assurance/test specialist Consider using a facilitator

5 Putting Requirements in Context

6 Iterative Approach to Requirements Feedback Feedback Build for some Requirements Build for some Requirements Build for some Requirements Source: Agile & Iterative Development. Craig Larman Release to Customers

7 Agile Iterations Requirements Design Implement Test

8 Requirements Validation Process Business Workflows Detailed Objectives Existing Functional Solution Concept Future Performance Workshops Interfaces Usability Interviews Configuration Security Work from the general to the specific..

9 Requirements Fundamentals It is an art not a science Involve the right people Align requirements gathering with project approach (COTS, Custom, Agile etc.) Overall Plan to spend 20-30% of time on requirements effort In iterative process requirements in every iteration Customer needs to be involved and approve requirements!

10 View Requirements from Multiple Perspectives Business Non-functional Functional Solution (COTS) Concept

11 Business Requirements Requirements should always address a business need Business requirements are usually high level/vision type statements The benefits to the business should be clear - Adding revenue - Cost savings - Automation - Create new products - Support customer service - Integration or streamline processes

12 Non-Functional Requirements Typically focus on how well the system must perform Types of nonfunctional requirements - Interfaces with other systems - Infrastructure - Usability, accessibility - Integration/Interoperability - Operational (e.g., 24/7 uptime) - Performance - Security requirements - Maintenance and system administration - Documentation - Standards

13 Functional Requirements Describe what the system should do from the end user perspective Requirements should - Describe WHAT not HOW - Only contain one requirement - Be unambiguous, measurable, and achievable - Be testable - Map back to the scope of work Requirements form the basis for - Software design and application development activities - Testing and acceptance activities

14 Functional Requirements Requirements must model workflow - Use Case models - Written from a user perspective - Links functional and non-functional requirements - Help traceability throughout the different phases of requirements, design, development, and deployment Use Cases

15 Business Processes, Use Cases, Domain Model Customer requirements need to be placed in context Business Process - Collection of related activities that serve a business need - Can be visualized as a flow chart Use Case - Describes a system from the user s point of view - Described through text as a sequence of events - More granular than business processes - Traceable to functional requirements Domain Model - Defines the entities that participate in the system Editor Sys Admin Update Data Browse and Query Data Create Reports Manage Display Administer Application Administer Data Data Browser

16 Requirements Customer Requirements ID Requirement 32 User must be able to search for images using a point buffer Revised Requirements ID Type Functional Area Requirement Original Requirement 101 F Desktop Client \ Discovery \ Search Filter 102 F Desktop Client \ Discovery \ Search Filter 104 F Desktop Client \ Discovery \ Search Filter User must be able to specify an area of interest by selecting a point feature on the map and inputting a radius (square buffer) User must be able to specify an area of interest by drawing a point on the map and inputting a radius (square buffer) All coordinate entry should support both decimal degree (DD) and degrees/minutes/seconds (DMS) input User must be able to search for images using a point buffer User must be able to search for images using a point buffer User must be able to search for images using a point buffer Business Processes Use Cases Domain Model

17 Requirements Gathering Techniques Solutions Based (COTS) Surveys Blank Slate Reverse Engineering Brainstorming Focus Group Interviews Observations Document Analysis Interface Analysis Prototyping Requirements Workshops

18 A COTS Requirements Approach Leveraging the existing platform Similar to Evolutionary Prototyping Focus on meeting business goals not software engineering - Configures and extends COTS - Reduces developing software Use demonstrations and workshops - Educate the user - How does COTS solve the business problem - What is the COTS workflow

19 COTS First Approach Custom COTS Components COTS system Custom built to meet business goals Custom system, using some COTS elements Orchestrates COTS to meet business goals Emphasis on software development Emphasis on componentbased software development Emphasis on workflows and configuration Design based on detailed functional requirements Design based on detailed functional requirements Design based on business goals and COTS capability Considerable development time / effort Reduced development time / effort Minimized development time / effort Static system Some capability evolves with COTS releases Evolving system with COTS releases Custom Development Configuration

20 Benefits of a COTS First Approach Maximizing commercial off the shelf software in a GIS system Immediate capability continually improving via COTS release cycles Users engaged early to define real requirements Improved communication via demonstration as opposed to interpretation of documentation Users become exposed to system capabilities demystifies technology Accelerated project lifecycle and reduced time to deployment

21 COTS First Approach - Example Modernizing Data Production High Level Business Requirements - Solution should provide the capability to task and manage data production workgroups throughout enterprise - Solution should provide the capability to add new features to the geospatial database using a distributed data editing environment - Solution should provide the capability for access, sharing and use of feature data via web services

22 COTS First Approach - Example Business Requirements Track and Manage Distributed editing Web Service sharing and access IT standards OS RDMBS Network Non- Functional Requirements User Engagement and Demonstrations Resource centers Template GDB s Sample workflows COTS Capabilities

23 COTS First Approach - Example High Level Business Requirements Solution should provide the capability to add new features to the geospatial database using a distributed data editing environment Constrained Network Bandwidth Logical Data Model Multi-User Editing Environment ArcGIS Server Workflow? ArcGIS Desktop Version Editing? Extensions User Skill Level Checkout / Check-In? Two-way Replication? Detailed Requirements Solution should provide user the capability to define a checkout replica based on user defined parameters Solution should provide user the capability to synchronize changes from the checkout replica to the parent Solution should guide the user through a semi-automated procedure using WMX to simplify procedure for synchronizing checkout to parent

24 Requirements Workshops Getting at the Real Needs Do your homework! Hold several workshops and keep them short Focus on key requirements early - Architectural Impacts - High business value Included in each iteration and combined with some development or programming Engage various stakeholders and users Potential strategies - User Stories - UI on Paper - Use Cases - Mind Maps

25 Requirements Workshops Removing Uncertainty

26 Requirements Workshop - Example Web Application for Submitting Data Request High Level Business Requirements - Solution should allow anyone in the public to submit a request for service via a web application. - The types of service requests is expected to be along the following lines: - Indicate where a pot hole is located - Indicate if a tree on public lands needs trimming - Indicate if there is a trash or graffiti problem - Solution is expected to streamline the process of how the public provides this information - Solution should not require GIS system expertise

27 Requirements Process Generate Use cases based on workflows - Informal vs. Traditional Allocate use cases to iterations Model initial set of use cases to domain models Mockup GUI Verify with key users Do not be judgmental - Need to prioritize - Break things into manageable units - What can be in the initial phase - What is critical to most end users

28 Informal Use Case Use Case No.: 001 Description: Submit service request 1) User is prompted for name and contact info. 2) User can select no 3) User is prompted with service types: tree trimming, pot hole, trash overflow, graffiti or other 4) If other user is prompted for comments 5) User is prompted to assign priority (H,M,L) 6) User is prompted to enter location via street intersection, street address or identification on a map 7) System provides tracking number to user 8) User is prompted if they want to be notified 9) Upon work order completion user is ed or contacted that issue has been resolved

29 Traditional Use Case Use Case No.: 001 Description: Submit service request Prerequisite: User has access to City Website Outcome: New work order is submitted 1) User is prompted for name and contact info into the Contact Name and Contact Number fields of the Submit Service Request form 2) The Service Types field is activated and the user selects from a drop down: tree trimming, pot hole, trash overflow or other 3) User can provide comments in the Service Type Comments field 4) User is prompted to assign priority (H,M,L) based on the Service Request Priority radio button 5) User is prompted to enter location via street intersection, street address or identification on a map 6).. Use Case No.: A 01A-3) User does not provide comments 01A-4) User is prompted comments are required 01A-5) Work order is not created and user is notified Use Case No.: A 02A-5) User selects On a Map 02A-6) System presents map of city 02A-7) User clicks a location on the map 02A-8) The system closes map

30 User Interface Mock-up

31 What Tools Do You Need? Planning Common Tools MS Office Share Point Common Tools Team Foundation Server (TFS) Enterprise Architect MS Office JIRA Requirements Validation Common Tools Team Foundation Server (TFS) Enterprise Architect Subversion OnTime Implement Project Environment Common Tools ANT Maven Deploy

32 Microsoft Team Foundation Server (TFS)

33 Microsoft Team Foundation Server (TFS)

34 JIRA

35 JIRA

36 Essential Documentation Use cases that describe workflows Detailed list of requirements Traceability matrix - From use cases to requirements - From requirements to scope Breakdown into software releases - Allocate complete workflows Customer must approve!

37 Obtaining Customer Approval Invest plenty of time to secure requirements acceptance - Prepare review materials - Invest in a site visit to present - Do not just deliver a document! Obtain written acceptance before proceeding with design

38 Requirements Gathering Things to Avoid Avoid long lists of requirements contained in a spreadsheet this is only one piece of the process Do not be judgmental You are going to get requirements that are mutually exclusive Avoid requirements that are ambiguous - System must be able to create map outputs Avoid requirements that describe HOW (unless you are using COTS approach) - System will make maps using ArcGIS

39 Lessons Learned Fit requirements process to overall methodology It is an art Do not start with a blank slate Requirements means different things to different people Needs to be very interactive and iterative Involve IT team early Solid requirements gathering lead to successful projects

40 Original Customer Requirement Need dog for companionship and household protection.

41 Requirements Document Submitted to User Dog must be over 30 lbs. Dog must be male. Approved Must play well with family, but capable of looking menacing

42 Delivered Product for Testing Phase

43 References Esri project methodologies - 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

44 Steps to evaluate UC sessions My UC Homepage > Evaluate Sessions Choose session from planner OR Search for session

45 Thank you for attending Have fun at UC2012 Open for Questions Please fill out the evaluation: First Offering ID: 1794

46 Discussion

47 Thank You Please complete session evaluation form

48