how to successfully collect, analyze and implement user ...€¦ · build for some requirements...
TRANSCRIPT
Technical Workshops |
Esri International User Conference San Diego, California
How to Successfully Collect, Analyze and
Implement User Requirements
Gerry Clancy Glenn Berger
July 24, 2012
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
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
Requirements 56% Design
27%
Other 10%
Code 7%
Origin of Development Errors
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
Putting Requirements in Context
Iterative Approach to Requirements
Build for some Requirements
Build for some Requirements
Build for some Requirements
Feedback Feedback
Release to Customers Source: Agile & Iterative Development. Craig Larman
Agile Iterations
Requirements
Design
Implement
Test
1 2 3 4 5 6 7 8 9
Requirements Validation Process
Business Workflows Detailed
• Objectives • Solution Concept
• Workshops • Interviews
• Existing • Future • Interfaces • Configuration
• Functional
• Performance
• Usability • Security
Work from the general to the specific…..
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!
View Requirements from Multiple Perspectives
• Business • Non-functional • Functional • Solution (COTS) Concept
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
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
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
1
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
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
Update Data
Browse and Query Data
Create Reports
Administer Application
Administer Data
Data Browser
Manage Display
Editor
Sys Admin
Requirements
ID Requirement
32 User must be able to search for images using a point buffer
… …
ID Type Functional Area Requirement Original Requirement
101 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 search forimages using a point buffer
102 F Desktop Client \ Discovery \Search Filter
User must be able to specify an area of interest by drawing a point on the map and inputting a radius (square buffer)
User must be able to search forimages using a point buffer
104 F Desktop Client \ Discovery \Search Filter
All coordinate entry should support both decimal degree (DD) and degrees/minutes/seconds (DMS) input
User must be able to search forimages using a point buffer
… … … … …
Business Processes Use Cases Domain Model
Customer Requirements
Revised Requirements
Solutions Based (COTS)
Focus Group
Blank Slate
Document Analysis
Requirements Gathering Techniques
Prototyping
Interviews
Observations
Interface Analysis
Brainstorming
Requirements Workshops
Reverse Engineering
Surveys
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
COTS First Approach
Custom
Custom built to meet business goals
Emphasis on software development
Design based on detailed functional requirements
Considerable development time / effort
Static system
COTS Components
Custom system, using some COTS elements
Emphasis on component-based software development
Design based on detailed functional requirements
Reduced development time / effort
Some capability evolves with COTS releases
COTS system
Orchestrates COTS to meet business goals
Emphasis on workflows and configuration
Design based on business goals and COTS capability
Minimized development time / effort
Evolving system with COTS releases
Custom Development Configuration
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 – de-
mystifies technology • Accelerated project lifecycle and reduced time to
deployment
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
COTS First Approach - Example
User Engagement and Demonstrations
Non-Functional
Requirements
Business Requirements
• IT standards • OS • RDMBS • Network
• Resource centers • Template GDB’s • Sample workflows • COTS Capabilities
• Track and Manage • Distributed editing • Web Service
sharing and access
Logical Data Model
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
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
Constrained Network Bandwidth
Multi-User Editing Environment
User Skill Level Two-way
Replication?
Extensions Version Editing?
Workflow?
Checkout / Check-In?
ArcGIS Server
ArcGIS Desktop
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
Requirements Workshops Removing Uncertainty
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
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
2
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 emailed or
contacted that issue has been resolved
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.: 001-01A
Use Case No.: 001-02A
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
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
User Interface Mock-up
What Tools Do You Need?
Planning
Project Environment Deploy
Implement
Requirements Validation
Common Tools § MS Office § Share Point
Common Tools § Team Foundation
Server (TFS) § Enterprise Architect § MS Office § JIRA
Common Tools § Team Foundation
Server (TFS) § Enterprise Architect § Subversion § OnTime
Common Tools § ANT § Maven
Microsoft Team Foundation Server (TFS)
Microsoft Team Foundation Server (TFS)
JIRA
JIRA
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!
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
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”
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
Original Customer Requirement
• Need dog for companionship and household protection.
Requirements Document Submitted to User
• Dog must be over 30 lbs. • Dog must be male. • Must play well with family, but capable of looking menacing
Approved
Delivered Product for Testing Phase
References
• Esri project methodologies - www.esri.com/services/professional-services/methodology.html
• 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
Steps to evaluate UC sessions
• My UC Homepage > “Evaluate Sessions”
• Choose session from planner OR
• Search for session
www.esri.com/ucsurveysessions
• Thank you for attending
• Have fun at UC2012
• Open for Questions
• Please fill out the evaluation:
www.esri.com/ucsessionsurveys
First Offering ID: 1794
Discussion
Please complete session evaluation form
Thank You