How to Successfully Collect, Analyze and Implement User Requirements - PowerPoint PPT Presentation

About This Presentation
Title:

How to Successfully Collect, Analyze and Implement User Requirements

Description:

... trash overflow, graffiti or other If other user is prompted for comments User is prompted ... User is prompted to enter location via street ... – PowerPoint PPT presentation

Number of Views:136
Avg rating:3.0/5.0
Slides: 49
Provided by: proceedin8
Category:

less

Transcript and Presenter's Notes

Title: How to Successfully Collect, Analyze and Implement User Requirements


1
How to Successfully Collect, Analyze and
Implement User Requirements
  • July 24, 2012
  • 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

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
Release to Customers
Source Agile Iterative Development. Craig
Larman
7
Agile Iterations
1 2 3 4 5 6 7 8 9
Requirements
Design
Implement
Test
8
Requirements Validation Process
Business
Workflows
Detailed
  • Existing
  • Future
  • Interfaces
  • Configuration
  • Functional
  • Performance
  • Usability
  • Security
  • Objectives
  • Solution Concept
  • Workshops
  • Interviews

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 users 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

16
Requirements
Customer Requirements
Revised Requirements



Business Processes
Domain Model
Use Cases
17
Requirements Gathering Techniques
Solutions Based (COTS)
Blank Slate
Surveys
Interviews
Brainstorming
Reverse Engineering
Focus Group
Observations
Requirements Workshops
Prototyping
Document Analysis
Interface Analysis
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 Development
Configuration
20
Benefits of a COTS First Approach
  • Going with the grain
  • 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

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
  • Track and Manage
  • Distributed editing
  • Web Service sharing and access
  • IT standards
  • OS
  • RDMBS
  • Network
  • Resource centers
  • Template GDBs
  • 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
ArcGIS Desktop
Constrained Network Bandwidth
ArcGIS Server
Extensions
Version Editing?
Logical Data Model
Multi-User Editing Environment
Workflow?
Two-way Replication?
User Skill Level
Checkout / Check-In?
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 emailed 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
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
  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-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
30
User Interface Mock-up
31
What Tools Do You Need?
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
    spreadsheetthis 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.
  • Must play well with family, but capable of
    looking menacing

42
Delivered Product for Testing Phase
43
References
  • Esri project methodologies
  • www.esri.com/services/professional-services/method
    ology.html
  • Agile Iterative Development A Managers 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 gt Evaluate Sessions
  • Choose session from planner
  • OR
  • Search for session
  • www.esri.com/ucsurveysessions

45
  • Thank you for attending
  • Have fun at UC2012
  • Open for Questions
  • Please fill out the evaluation
  • www.esri.com/ucsessionsurveys
  • First Offering ID 1794

46
Discussion
47
Thank You
  • Please complete session evaluation form

48
(No Transcript)
Write a Comment
User Comments (0)
About PowerShow.com