system requirements definition and system selection · agenda 1. introductions 2. session objective...
TRANSCRIPT
BerryDunn’s Presentation to Texas Association of Governmental Information
Technology Managers for
Tuesday, April 29, 2014
1:30 – 2:30 PM
System Requirements Definition and System Selection
Presented in Partnership with the City of College Station
2
Agenda
1. Introductions
2. Session Objective
3. Presentation
4. Questions and Discussion
3
Introductions
Chad Snow, PMP
BerryDunn
Senior Manager
Ben Roper CGCIO, MBA
City of College Station
Director of Information
Technology
Erin Provazek
City of College Station
Assistant Director of
Information Technology
4
Session Objective
Discuss the importance of functional and
technical requirements in system
selection/development/replacement projects.
5
Why Document Requirements?
Depending on the industry report, anywhere from
25-75% of software implementation projects fail to
meet user expectations.
One of the most common reason software implementations
struggle is a lack of well defined functional or technical
requirements.
• A “requirement” is a necessary attribute in a system; a statement that
identifies a capability, characteristic, or quality factor of a system in order
for it to have value and utility to a user.
• One of the greatest challenges in developing requirements is not
documenting what the users want; it is helping users identify what they
need.
6
The Role of Requirements
• Document future system needs
• Document future system “wants”
• Used as an input to the process of analyzing current and future
business processes
• A tool to be used in the procurement process to compare vendor
products (COTS)
• Can serve as the basis for demonstration scripts
� Test cases for custom development
• Referenced during implementation
� Requirements traceability matrix
� Test cases and system validation
7
Requirements Gathering Process
Understand the Current (and Future) Environment
• Identify current challenges and unmet business needs
� Future process vision and application scope
• Identify key stakeholders
– Review often and adjust as needed
Getting Started
• Organizational artifacts
� Policy and procedure manuals
� Legislative directives and local ordinances
• End user survey
� What is working well? What needs to change?
8
Requirements Gathering Process (cont.)
Getting Started (cont.)
• Walkthroughs
� Observe current processes firsthand
• Collaboration work sessions
� Discuss current unmet needs and potential future processes
• Document initial set of requirements
� Organize them into smaller, manageable components
• Business area
• Module
• Technical
• Interfaces
9
Requirements Gathering Process (cont.)
Refine Requirements
• Requirements workshops
� Joint Requirements Planning (JRP)
� Joint Application Design (JAD)
• Update and re-distribute requirements to stakeholders for
review
• Finalize and document a process for change control
10
Requirements Gathering Process (cont.)
According to the IEEE (Institute of Electrical and Electronics
Engineers), Software Requirement Specifications should be:
� Correct
� Unambiguous
� Complete
� Consistent
� Ranked for importance
� Verifiable
� Traceable
Requirements Best Practices and Standards:
11
Case Study: City of College Station
• Why ERP Now?
� City business needs have evolved and changed as the City
has grown.
� Departments have identified possible shortcomings in the
existing applications, and in some cases, have had to develop
workarounds to complete work.
� Technology has changed and evolved. Is there a better
solution?
� Reporting and data analysis difficult.
12
Case Study: City of College Station (cont.)
ERP Implementations
• According to Gartner, nearly 50% of all ERP implementations fail to
deliver even one third of their expected business benefits.
� Lack of software fit.
� Unrealistic implementation expectations.
� Lack of executive buy-in and support.
� Propensity to customize software, rather than leverage
standard functionality.
� Lack of ERP implementation expertise.
13
Case Study: City of College Station
• Initiated project to assess options to upgrade, replace or enhance
current enterprise wide applications environment in 2012
• Scope of functional areas included:
� Finance, Procurement, Accounts Payable, Budgeting, Accounts
Receivable, Miscellaneous Billing
� Payroll, Human Resources
� Utility Billing, Work Orders
� Community Development (Permitting, Planning and Zoning,
Code Enforcement)
� Integration to other existing and future systems
14
• Comprehensive Needs Analysis
� First step in stakeholder identification
� Identified Challenges and unmet business needs
• Challenges and unmet business needs was an input to
functional and technical requirements
� Options for future environment
• Business Case
� Pros and Cons for future options
� Justification for moving ahead with competitive
procurement
Case Study: City of College Station (cont.)
15
Case Study: City of College Station (cont.)
• Requirements Gathering Process:
� Stakeholder re-validation
� End user web survey
� Observations and walkthroughs of processes
� Fact finding meetings
• 33 meetings across 26 functional areas
• Requirements Validation Process:
� Preliminary Requirements developed and distributed for end
user review
� Joint Requirements Planning (JRP) sessions held to validate,
confirm requirements
16
Case Study: City of College Station (cont.)
• Requirements Validation Process:
� Preliminary Requirements developed and distributed for end
user review
� Joint Requirements Planning (JRP) sessions held to validate
and confirm requirements
• 30 sessions
• 5,800 individual requirements for 26 functional areas
17
Case Study: City of College Station (cont.)
• Ongoing Role of Requirements:
� Used during procurement
• Request for Proposal
• Demonstrations
� Implementation
• Requirements Traceability Matrix
• Testing
18
Key Takeaways
• Initial planning should include high-level goals for the future
• Identify stakeholders early and reevaluate throughout the
process
• Use several inputs to the requirements gathering process
� Policy and procedure manuals
� Workflow diagrams
� Observation of business processes
• Follow a structured process for documenting requirements
(IEEE or other standard)
• Continue to use requirements as part of procurement
(development – custom developed applications) and
implementation phases
19
Questions and Discussion
Questions and Discussion
20
Thank You
Chad Snow
207-541-2294
Ben Roper
(979) 764-3538
Erin Provazek
(979)-764-3482
21
References
• IEEE Standard 830-1998 Recommended Practice for Software
Requirements Specifications
• Project Management Institute (PMI)
• National Institute of Standards and Technology (NIST)