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
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
Origin of Development Errors
•
Define what will be built
•
Foundation for acceptance
•
Affect everyone
•
Most difficult errors to fix if found
late in project lifecycle
Other
10%
Code
7%
Design
27%
Requirements
56%
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
Feedback
Build for some
Requirements
Build for some
Requirements
Source: Agile & Iterative Development. Craig Larman
Feedback
Build for some
Requirements
Release to
Customers
Agile Iterations
1
2
Requirements
Design
Implement
Test
3
4
5
6
7
8
9
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…..
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
-
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
Update Data
Use Case
-
Browse and
Query Data
Editor
Describes a system from the user’s point of view
Create Reports
Data Browser
Manage Display
•
-
Described through text as a sequence of events
-
More granular than business processes
-
Traceable to functional requirements
Sys Admin
Domain Model
-
Defines the entities that participate in the system
Administer
Application
Administer Data
Requirements
Customer Requirements
ID
Requirement
32
User must be able to search for images using a point buffer
…
…
Revised
ID Type Functional Area
Requirements
Requirement
Original Requirement
101
F
Desktop Client \ Discovery \
Search Filter
User must be able to specify an area of interest by selecting a point User must be able to search for
feature on the map and inputting a radius (square buffer)
images 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 User must be able to search for
on the map and inputting a radius (square buffer)
images 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 for
images using a point buffer
…
…
…
…
…
Business Processes
Use Cases
Domain Model
Requirements Gathering Techniques
Solutions
Based (COTS)
Surveys
Blank Slate
Interviews
Brainstorming
Reverse
Engineering
Focus Group
Document
Analysis
Interface
Analysis
Prototyping
Observations
Requirements
Workshops
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
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
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
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
•
•
•
Business
Requirements
•
•
•
•
IT standards
OS
RDMBS
Network
Track and Manage
Distributed editing
Web Service
sharing and
access
NonFunctional
Requirements
User Engagement and
Demonstrations
•
•
•
•
Resource centers
Template GDB’s
Sample workflows
COTS Capabilities
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
ArcGIS Desktop
ArcGIS Server
Extensions
Logical
Data Model
Multi-User Editing
Environment
User Skill Level
Workflow?
Version
Editing?
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
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
Informal Use Case
Use Case No.: 001
Description: Submit service request
1)
2)
3)
4)
5)
6)
7)
8)
9)
User is prompted for name and contact info.
User can select ‘no’
User is prompted with service types: tree trimming, pot
hole, trash overflow, graffiti or other
If ‘other’ user is prompted for comments
User is prompted to assign priority (H,M,L)
User is prompted to enter location via street
intersection, street address or identification on a map
System provides tracking number to user
User is prompted if they want to be notified
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)
2)
3)
4)
5)
6)
User is prompted for name and contact info into
the ‘Contact Name’ and ‘Contact Number’ fields of
the Submit Service Request form
The ‘Service Types’ field is activated and the user
selects from a drop down: tree trimming, pot hole,
trash overflow or other
User can provide comments in the ‘Service Type
Comments’ field
User is prompted to assign priority (H,M,L) based
on the ‘Service Request Priority’ radio button
User is prompted to enter location via street
intersection, street address or identification on a
map
……..
Use Case No.: 001-01A
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.: 001-02A
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?
Common Tools
§ MS Office
§ Share Point
Planning
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
Deploy
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
-
•
Breakdown into software releases
-
•
From use cases to requirements
From requirements to scope
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
Approved
play well with family, but capable
of looking menacing
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
Thank You
Please complete session evaluation form