ATTACHMENT B – DETAILED STATEMENT OF WORK

A suggested Statement of Work is included below. This attachment outlines the tasks and subtasks that
the City expects the Proposer to include as part of any agreed upon Statement of Work.
Please Note: This outline of tasks is not intended to prescribe an implementation approach or
methodology.

1 List of Deliverables
1.1 Overview of Tasks

The Office of the Assessor-Recorder (ASR) has organized its detailed statement of work into seven (7)
major implementation tasks. A summary of each task is provided below.
1. Task 1 - Project Initiation and Planning: ASR’s expectations regarding the project kick-off and
management.

2. Task 2 – System, Interface, and Data Conversion Design: ASR’s expectations regarding the
developing and detailing of the plans for designing the System to meet the needs of ASR. This
includes the design of the interfaces and data conversion.

3. Task 3 - System Development / Configuration: ASR’s expectations regarding the development

and/or configuration of the System to meet ASR’s needs through execution of the designs
created in Task 2. This includes the development of the interfaces and data conversion.

4. Task 4 – System Testing: ASR’s expectations regarding the testing of the System
developed/configured in Task 3 to ensure that it meets the needs of ASR.

5. Task 5 – Project Training: ASR’s expectations regarding the training of ASR staff in using the
new System.

6. Task 6 – Deployment: ASR’s expectations regarding the deploying of the new System into
production.

7. Task 7 – Implementation Closeout: ASR’s expectations regarding the process of concluding

implementation.

1.2 Sub-tasks and Activities by Task

The preliminary sub-tasks and activities associated with each task are as follows:

RFP# ASR2017-01 Attachment B – Detailed Statement of Work

Property Assessment Solution Page 1 of 38
 Implementation Phase
Task Sub-task Activities
Task 1 - Project  Project Initiation
Initiation and Planning  Project Initiation Planning
 Project Kick Off Presentation
 Project Management Plan
 Project Scope
 Costs/Budget
 Risk Analysis and Management
Sub-task 1 - Project Initiation and Plan
Management Plan  Quality Management Plan
 Project Procurement Plan
 Team Membership
 Project Work Plan and Schedule
 Change Management Plan
 Communication Plan
 Change Request
 Closure
Sub-task 2 – Regular Project Status  Minimum of Bi-Weekly Status
Reporting Report
 System Design Methodology
Sub-task 3 – System Design and  System Design and
Development Strategy Development Strategy
 Managed Pilot Phase Plan
Sub-task 4 – System Implementation  System Implementation Strategy
Strategy
Sub-task 5 – Master Testing Strategy  Master Testing Strategy
Sub-task 6 – Requirements Traceability  Requirements Traceability
Plan Matrix
Task 2 – System, Sub-task 7 – Functional Design  Functional Design Document
Interface and Data Document
Conversion Design Sub-task 9 – Develop Data Conversion  Develop Data Conversion Plan
Plan
Sub-task 9 – Develop Interface  Develop Interface Specifications
Specifications and Design Document and Design Document
Sub-task 10 – System Architecture and  System Architecture
Technical Design  Technical Design Document
Task 3 - System  System Development
Development / Methodology
Configuration Sub-task 11 – System Implementation  Software Configuration
Plan Management
 Change and Release
Management
 Staging Tables
Sub-task 12 – Data Conversion,
 Data Load
Synchronization, and Reporting
 Testing Conversion
Sub-task 13 – System Maintenance,  System Maintenance, Support
Support and Transition Plan and Transition Plan

RFP# ASR2017-01 Attachment B – Detailed Statement of Work

Property Assessment Solution Page 2 of 38
 Implementation Phase
Task Sub-task Activities
Task 4 – System  Unit and Integration Testing
Testing  System Testing
 User Acceptance Testing
Sub-task 14 – Detailed Test Plans  Performance Testing
 System Regression Testing
 Testing Plan

Sub-task 15 – Test Scenarios, Test  Test Scenarios, Test Cases, and

Cases, and Test Scripts Test Scripts
Deliverable 16 – Documented System  Documented System Test
Test Results Results
Task 5 – Project  Property Assessment System
Training User training
 Security administrator training
 Property Assessment System
Supervisor training
 Administrative and management
staff training
Sub-task 17 – Training Plan
 Analyst training
 Power User training
 Trainer training
 Configuration Training
 Constituents/Customer training
 Technical Administrator training
 Report Development training
Sub-task 18 – Training Manuals, Guides,  Training Manuals, Guides, and
and Materials Materials
Sub-task 19 – Documented Evidence of  Documented Evidence of
Successful End-User Training Successful End-User Training
Task 6 - Deployment  City Business Site Readiness
Sub-task 20 – Release Readiness
 Release Readiness Evaluation
Evaluations and Reports
and Report
 Deployment Bill of Materials (for
each implementation Phase)
 Deployment Plan
 System Deployment
Sub-task 21 – Deployment Plans  Production Support
 Production Support Plan Help
Desk Levels
 System Incident and Corrective
Action Reports
Sub-task 22 – System Defect Resolution  System Incident
Reports  Defect Resolution Reports
 Complete Detailed
Sub-task 23 – Complete Detailed
Requirements, Design &
Requirements, Design & Specifications
Specifications
 System Source Code Escrow
Sub-task 24 – System Source Code and Information
Documentation  System Documentation
 Final Acceptance

RFP# ASR2017-01 Attachment B – Detailed Statement of Work

Property Assessment Solution Page 3 of 38
 Implementation Phase
Task Sub-task Activities
Task 7 – Implementation Sub-task 25 – Documented  Documented Implementation
Closeout Implementation Project Closeout Project Closeout

The Proposer shall develop the Project Deliverables in the form and format agreed upon with ASR. This
Attachment identifies what is required to be included in each deliverable.

All Proposer deliverables shall be subject to review by ASR prior to final approval, acceptance, and
payment. Acceptance of deliverables will be communicated formally via a deliverables acceptance form to
be drafted by ASR.

1.3 Detailed Statement of Work

Please Note: All tasks and deliverables described in this section may not apply equally to every possible
variation of proposed system development (COTS, custom developed, etc.) or software delivery (e.g.,
hosted, SaaS, etc.)—the Proposer should adjust their response based on the system and services being
specifically proposed and include appropriate documentation in Template G – Implementation Approach.

1.3.1 Task 1 – Project Initiation and Planning

[Link] Deliverable 1 – Project Initiation and Management Plan

[Link].1 Project Initiation

A Project Initiation meeting or meetings (Project Kick-Off) shall be held to formally notify all Assessor-
Recorder and Proposer team members and stakeholders that the Project has begun and to ensure all
team members have a shared understanding of their roles and the contract requirements. ASR shall
select the location of the Project Kick-Off(s). ASR and the Proposer shall coordinate a mutually agreeable
date and time for the Project Kick-Off meeting to occur no more than 30 calendar days after contract
execution, unless otherwise approved by ASR.
Additionally, as part of Project Initiation, the Proposer shall complete the Deliverables Expectation
Document (DED) and provide it to ASR for review and acceptance (See Attachment E - Sample
Deliverables Expectations Document) to ensure the Proposer fully understands ASR’s expectations for
each deliverable.
[Link].2 Project Initiation Planning

The Proposer shall plan the Project Initiation meeting with ASR Project Manager. The Proposer shall
prepare draft material at least 48 hours in advance of the meeting and work with ASR to develop a shared
agenda.
[Link].3 Project Kick-Off Presentation

The Officer of the Assessor-Recorder Project Manager(s) will finalize the agenda of one or more Project
Kick-Off Presentations and facilitate any questions. The Proposer shall present a portion of the agenda
items at meeting(s) to adequately provide ASR and Proposer team members and Project stakeholders
with an overview of the Project approach and expectations. The Proposer shall present at minimum,
information about the following, which shall later be detailed in the Project Management Plan (Deliverable
2):
1. Project Scope
2. Implementation Strategy and Approach (including data conversion, interface, phases)
3. Change Management

RFP# ASR2017-01 Attachment B – Detailed Statement of Work

Property Assessment Solution Page 4 of 38
 4. Budget/Cost Management
5. Risk Management Strategy
6. Quality Management Strategy
7. Communication and Status Reporting Approach – including performance measurements and
critical success factors
8. Introduction of Proposer key personnel their roles and responsibilities
9. Reporting structure to ASR
10. Overall Project approach and high-level schedule including slated completion of key deliverables
11. Overview of Proposer’s Project management processes including initiating, planning, executing,
controlling, and closing each phase of the contract
12. Next steps
The Proposer shall be prepared to answer questions that arise during the meeting. Any decisions or
agreements from the Kick-off Meeting will be documented by the Proposer and submitted to ASR Project
Manager for review and acceptance. Any proposed changes to the scope and/or requirements must go
through the established ASR change control process.
[Link].4 Project Management Plan

The Proposer shall provide a set of documents that, when taken together, constitute the Property
Assessment Solution Project Management Plan that describes how Project objectives shall be met and
provides a road map for executing the Project. The approach shall be consistent with the Project
Management Institute (PMI) Project Management Methodologies stated in the Project Management Body
of Knowledge (PMBOK) or equivalent. The Proposer shall use ASR’s central repository for all Project
artifacts and required documentation identified in the contract. The Property Assessment Solution Project
Management Plan shall be maintained and kept accessible in the central repository for Project artifacts.
The Property Assessment Solution Project Management Plan shall address the initiating, planning,
controlling, executing, and closing of activities and processes. At a minimum, with the support of ASR
staff, the Proposer shall include the following components in the Plan, as defined, and in accordance with
the contract requirements:
[Link].5 Project Scope

1. Purpose
2. Requirements
3. Deliverables
4. Constraints/Dependencies/Assumptions
5. Work Breakdown Structure
[Link].6 Costs/Budget

1. Breakdown of costs/budget by Deliverable

[Link].7 Risk Analysis and Management Plan

1. Identification of Project risks

2. Assessing the severity and probability of each identified risk
3. Identifying the potential impact of each identified risk, develop risk response plans for each
identified risk, and how a risk will be reassessed once a response is received or put in motion

RFP# ASR2017-01 Attachment B – Detailed Statement of Work

Property Assessment Solution Page 5 of 38
 4. Providing guidance for assessing the efficacy of risk mitigation actions
5. Description of work products and processes for assessing and controlling risks
6. Detailed escalation mechanisms for risks
7. Risk and Issues Log, to be updated weekly
8. Risk and Issue Escalation Plan
9. Issues and Action Item Process that describes how unanticipated issues, action items, and tasks
are assigned to a specific person for action and are tracked to resolution, and documents the
following:
a. Description of Issue and/or Action Item
b. Priority of Issue and/or Action Item
c. Status of Issue and/or Action Item (e.g. open, pending, under investigation, resolved)
d. Plan for resolution
e. Identification of individual responsible for resolution, including anticipated use of ASR staff
or other resources
f. Targeted resolution date
g. Actual resolution dates
h. Resolution action
[Link].8 Quality Management Plan

The Proposer shall define and document the Proposer’s software quality assurance activities that will be
implemented to ensure the Property Assessment System conforms to all established and contracted
requirements. The plan shall document any software development needs and how the Proposer’s release
activities and processes shall be managed, tracked, and audited (from both a Project management and
configuration control perspective), to ensure the delivered Property Assessment System and components
meet the quality standards and requirements required by the contract. In addition, the plan shall provide a
comprehensive explanation of how the Proposer will integrate its software release process into any ASR
release schedules or processes.
[Link].9 Project Procurement Plan

The Proposer shall define and document a Project Procurement Plan that outlines Proposer’s plans for
securing equipment, subcontractors, and other resources.
[Link].10 Monitoring and Control Plan

The Proposer shall define and document a Monitoring and Control Plan that outlines:
1. Descriptions of the administrative procedures that will be used to develop, monitor, and control the
Project schedule
2. Project monitoring activities, including, but not limited to:
a. Completion of work packages as compared to the Project plan
b. Scope of work being performed
c. Quality of work being performed
d. Costs and expenditures as compared to the plan
e. Feedback of stakeholders and management

RFP# ASR2017-01 Attachment B – Detailed Statement of Work

Property Assessment Solution Page 6 of 38
 f. Cohesiveness of team members
3. Scope, Budget and Schedule Baselines
a. At a minimum, the Proposer shall include and report on
i. Earned value analysis (EVA) as a tool for monitoring Project progress
ii. Burn rate report
iii. Schedule Performance Index
iv. Budget to Actuals
4. Project Status Reports that detail the varying levels and needs of the Project Team for information
regarding the Project, status, and accomplishments; describe the form and format of this reporting:
a. Status meetings (e.g. weekly, monthly)
b. Project reporting (e.g. weekly, monthly)
[Link].11 Team Membership

The Proposer shall define and document their planned Team Membership that is aligned with the
proposed Project Schedule (below). The Proposer shall identify the roles and responsibilities for staffing
all Project activities, including identifying the resources the Proposer and ASR will provide to successfully
fulfill the requirements of the RFP.
[Link].12 Project Work Plan and Schedule

The Proposer shall build out and further define the planned Project schedule as described in Section
Error! Reference source not found.– Work Plan of this document. The Proposer shall deliver a baseline
Project Work Plan and Schedule, including a Work Breakdown Structure (WBS), Gantt chart(s), and a
Project calendar in Microsoft Project. The Proposer shall document any work plan or schedule changes
from the plan submitted with the Proposer’s original proposal. The Proposer shall provide a Project Work
Plan and Schedule to include:
1. Identification of the resources to be provided by ASR, together with the scheduled dates those
resources will be required
2. All City holidays and periods that will be observed by the Proposer staff, periods during which the
City has advised that ASR resources will be unavailable to the Proposer
3. A WBS that encompasses all activities from Project Initiation and Planning to Project Closeout. The
WBS shall define the Project’s overall objectives by identifying all Project tasks and deliverables.
This WBS is the Baseline Project Schedule and shall include:
a. A consolidated view of the activities, activity descriptions, and activity durations assigned
to ASR, the Proposer, and their sub-contractors
b. A fully loaded staffing plan, Proposer, and ASR, including all resources identified to each
Project activity/task
c. A list of deliverables tied to Project milestones
d. A methodology for tracking the actual Project schedule against the baseline Project
schedule
e. Identification and tracking of Deliverable acceptance periods
f. Identify Project Dependencies
4. Identification of all tasks of the Project, and any proposed sequences of phased functionality (as
mutually agreed upon by Proposer and ASR), the duration of the Phases, and the duration of the
Project

RFP# ASR2017-01 Attachment B – Detailed Statement of Work

Property Assessment Solution Page 7 of 38
 5. Identification of the critical path activities of the Project, and the criteria used to identify those
activities
6. Description of corrective action activities to address schedule variances during the life of the
Project; how they are identified and tracked to completion
7. Process, roles, and responsibilities required to making changes to the Project schedule
8. Assignment of resources to the schedule and approach for managing staff and/or equipment
availability to ensure completion of deliverables in accordance with contract terms and on schedule
The Project Work Plan and Schedule, once accepted by ASR, will form the baseline work plan and
schedule for the overall Project. The Proposer shall maintain and update applicable portions of the
Project schedule no less than bi-weekly to reflect the current status of the Project with a comparison
made to the initial (as provided in this response to this RFP) and baseline Project schedules.
The Project Schedule shall be consistent with available ASR resources. These resources will be identified
by ASR and communicated to the Proposer prior to Schedule development. ASR shall have direct
electronic access to the Project schedule as well as all deliverables and working papers for immediate
review and coordination of schedules and plans via an agreed sharing and planning tool (ASR currently
uses SharePoint and other data sharing methods (e.g., shared drives)).
[Link].13 Change Management Plan

The Proposer must detail the approach and plan to meet the complex Change Management needs and
associated tasks that are part of a large scale system implementation Project.
[Link].14 Communication Plan

The Proposer shall define and document the Communication Plan that describes the Proposer’s roles
and responsibilities regarding communications with the Proposer’s immediate Project team,
subcontractors, and ASR including:
1. Communication protocols
2. Communication mode and format
3. Communication content
4. Communication frequency
5. Audiences
[Link].15 Change Requests

The Proposer shall define and document the Property Assessment Solution Change Request approach in
accordance with the requirements of the final contract.
[Link].16 Closure

The Proposer shall define and document the Closure Approach (for any proposed Phases, the
Implementation work, and the Project) in accordance with the requirements of this RFP.

[Link] Deliverable 2 – Regular Project Status Reporting

The Proposer shall be required to provide, at minimum, a Bi-Weekly Status Report. The report shall
address overall Project status against the current and baseline (if different) Project schedule. It shall
cover progress against plans for the previous review period and identify work planned for the next work
period, or longer if circumstances dictate. The periodic Status Report shall address issues and concerns,
action items, and other pertinent information needed by the Proposer or requested by ASR as necessary

RFP# ASR2017-01 Attachment B – Detailed Statement of Work

Property Assessment Solution Page 8 of 38
and applicable to that Project task or phase. The presentation of the Status Reports shall be written
and/or oral. Proposer Project management staff are expected to attend all Status Report meetings unless
otherwise decided by ASR.
The Regular Status Reports shall include a minimum of the following elements:
1. Milestones reached
2. Major tasks accomplished
3. Schedule Performance
4. ASR Approved Scope Changes
5. Risks/problems identified and a detailed report of the planned or completed mitigation thereof
6. Milestones not met on schedule
7. Milestones or critical path items expected to occur during the next month

[Link] Deliverable 3 - System Design and Development Strategy

Prior to the creation of detailed design or the start of any development/configuration, the Proposer shall
develop and provide a comprehensive System Design and Development Strategy document to ASR,
based on the requirements in the contract and interviews with Assessor-Recorder management and
operations staff. The purpose of this strategy document is to demonstrate that the Proposer has a strong
understanding of the Property Assessment System requirements and a well-defined vision of how the
Property Assessment System should be designed, developed, configured, and implemented. This
document shall include all System requirements that have been included in this Scope of Work and
address how they will be designed and developed.
The System Design and Development Strategy should incorporate plans for the first functionality to be
designed, developed, and deployed as a managed pilot phase. The managed pilot phase project will
include data migration and potential interfacing with other systems. ASR will review the pilot experience
and outcomes to ensure the established plans and approach for implementing the system appropriately
address ASR’s holistic needs. Any resulting areas for improvement should be addressed before
beginning full system design and development/configuration.
The Proposer shall provide a System Design and Development Strategy document that includes, at a
minimum, a description of:

1. The business processes and the functionality the Property Assessment System will provide (by
phase, if relevant to the proposed approach)
2. The functionality described in this Scope of Work
3. The functionality and technical specifications included in Template D - Requirements Response
Matrices
4. A breakdown of the functionality by any proposed Phases, including temporary interfaces, data
conversion approach
5. Identification of all functional areas where workflow will be involved, including sufficient detail to
identify the function or user role that initiates the workflow, the function or user role that receives
the workflow, and any processes that occur as a result of the workflow
6. Any initial concepts for screen design, potentially including story boards and the expected flow of
work relative to the screens
7. Managed pilot phase – the design, development, and deployment of a pilot phase to validate
solution and implementation approach

RFP# ASR2017-01 Attachment B – Detailed Statement of Work

Property Assessment Solution Page 9 of 38
[Link] Deliverable 4 - System Implementation Strategy

The Proposer shall document and provide ASR with the System Implementation Strategy. The document
shall include the strategy for the implementation of all proposed property assessment functionality and
any proposed phases to ensure all functionality required of the System is included.
The System Implementation Strategy shall also identify any technical challenges (which, if any, are the
sole responsibility of the Proposer to resolve) and include the deployment schedule of the proposed
functionality.
The Proposer shall provide a System Implementation Strategy document to include, at a minimum, the
following components:
1. Project implementation plan, by property assessment functionality and/or phases
2. Target end-user population included in the Project, by plan timeframe
3. Deployment schedule, by plan timeframe
4. Workflow analysis and documentation aligned with the Property Assessment System Use Case
library
5. Technology components required for the Project, by functionality and/or phases
6. Identification of the source systems to be integrated, by functionality and/or phases. This will
include temporary interfaces if applicable.
7. Identification of technical challenges the Proposer must overcome to implement the system
8. Training Plan

[Link] Deliverable 5 - Master Testing Strategy

The purpose of the Master Testing Strategy is to ensure that the Proposer has identified the major system
testing activities and associated deliverables required to be performed by the Proposer. A separate and
complete set of testing as outlined below shall be required for each module of functionality that will be put
into production (see System Implementation Plan – Deliverable 13). Complete testing to the satisfaction
of ASR shall also be required for every System interface that is built and put into production. The testing
functions of the Project shall be iterative and span the entire length of the Project.

The Proposer shall employ a robust test methodology based on industry standards, such as those set by
one of the following organizations in the execution of the required system testing activities:
1. Software Engineering Institute (SEI), such as the Capability Maturity Model (SEI CMM)
2. International Standards Organization, such as ISO9000
3. Institute of Electrical and Electronics Engineers (IEEE), such as IEEE 829 Standard for Software
and System Test Documentation and related standards
The Proposer shall be responsible for populating the test environment(s) with ASR data necessary to
ensure the validity of the testing for all phases of testing. Assessor-Recorder staff shall not be required to
manually enter data to pre-populate the test environment for any test phase. The Proposer shall use an
automated test management tool suite to manage, assess, track, and perform the required test and
deployment support activities. It is expected that the Proposer shall either utilize a vendor’s product to
support the testing methodology or a Proposer’s existing requirements management tool.
The Proposer shall have a software-based defect tracking system capable of providing an acceptable
level of detail and reporting, as agreed upon with the Assessor-Recorder Project Management staff and,
at a minimum, facilitating the following functions:

RFP# ASR2017-01 Attachment B – Detailed Statement of Work

Property Assessment Solution Page 10 of 38
 1. Capture – Details about each defect will be recorded when the defect is discovered, including a
description, symptoms, sequence of steps to re-create it, type, and severity
2. Review and assignment – Project management shall be able to review all open issues and assign
a priority level and resources responsible for resolution
3. Estimate and resolution – Those assigned to resolve the defect shall be able to record an
estimated duration and delivery date, and provide adequate explanation upon resolution
4. Track status and history – A complete history of each defect shall be maintained so that the life
cycle of each defect can be tracked and reported on
5. Management reporting – The defect tracking system shall provide recurring reports to Project
management throughout the Project

The Proposer shall provide the Master Testing Strategy deliverable, which shall, at a minimum, include:
1. The test methodology to be employed for overall system testing
2. The automated method of populating the test systems with data
3. Identification of the software-based tracking system that will be employed
4. Identified strategies for each type/level of Project testing:
a. Unit and integration testing
b. System testing
c. End-to-end testing
d. User acceptance testing
e. Performance and load testing
f. System regression testing
g. Security testing
h. Test Scripts
5. ASR has a preference for the use of automated testing tools. This will allow for automating the
testing of test scenarios without the need for manually recreating the scenarios for multiple
execution of the test scenario.

[Link] Deliverable 6 - Requirements Traceability Plan

The Proposer shall provide a Requirements Traceability Plan to detail the methodology for tracking the
specific functional, non-functional, and contract requirements of the Project. The Requirements
Traceability Plan shall identify the methods, tools, and technologies used to capture, catalog, and
manage the System requirements to ensure traceability to the Property Assessment System process
workflows, use cases, and detailed requirements throughout the development and deployment process.
The plan shall, at a minimum, include:
1. The process the Proposer will use that identifies how the requirements traceability matrix will be
developed, validated, and maintained throughout the lifecycle of the Project
2. How requirements are validated
3. How any new and approved requirements (if any) are analyzed and managed
4. How ASR team works with the Proposer to ensure traceability of requirements to the delivered
system
5. Identification and implementation of the tool to be used to perform requirements traceability

RFP# ASR2017-01 Attachment B – Detailed Statement of Work

Property Assessment Solution Page 11 of 38
 6. Approach and methodology to track the Project requirements including:
a. Mapping the contract requirements to a unique identifier in the tool
b. Mapping the requirements to the Property Assessment System use cases
c. Mapping the requirements to the individual test events
d. Mapping the requirements to the individual test cases, scripts, and procedures
7. Approach for updating the status of the requirements based on the results of each test event
8. Identification of the requirements by status (e.g. satisfied, waived)
9. Identification of the reports to manage and validate the requirements, including test coverage by
test event

1.3.2 Task 2 – System, Interface, and Data Conversion Design

Detailed and logical system design documents produced by the Proposer shall direct the System
development efforts. The design shall be driven by the outputs of the requirements validation phase
(included in Section [Link] above). These documents provide the framework essential to ensure that the
system is constructed consistently, with appropriate software development methodologies and include all
the functionality required by the contract.
[Link].1 System Design Methodology

The Proposer shall provide a software design approach and methodology to be followed when designing
any new functionality to be developed or to guide the configuration of the existing packaged System
product. The software design methodology document shall also identify the approach to conduct
knowledge transfer and provide hands-on experience for identified ASR staff during the course of the
SDLC. The development of the software design methodology shall consist of the following tasks:
1. Develop a draft Software Design Methodology document that identifies the process to manage
any necessary functionality/capability development and configuration activities based on functional
and technical specifications. The methodology shall clearly define the inputs and outputs for the
design process, define the expected deliverables for the development team, and define the roles
and responsibilities of the design team
2. Review draft software design methodology with the appropriate stakeholders
3. Prepare final software design methodology document

[Link] Deliverable 7 - Functional Design Document

In order to ensure that the Proposer fully understands the System requirements, the Proposer shall
conduct and lead design sessions with appropriate staff from ASR. The Proposer shall conduct Joint
Application Design (JAD) sessions to fully explore and understand existing Property Assessment System
component functionality that the Proposer shall be leveraging for the new system, and to identify any
gaps that the Proposer shall address in order to comply with the requirements identified in this SOW and
the contract. Based upon the outcome of the JAD sessions, the Proposer shall document in detail the
design, development, and configuration actions necessary to fully meet Property Assessment System
requirements.
The Proposer shall lead and facilitate the process for developing the Functional Design Document. This
process should:
1. Provide a detailed description of the business processes and the functionality the Property
Assessment System will provide, including a validation of the functionality described in the Property
Assessment System “Future State” Workflows and Use Cases (Attachment C - Assessor Process

RFP# ASR2017-01 Attachment B – Detailed Statement of Work

Property Assessment Solution Page 12 of 38
 Flows and Attachment D - Assessor Use Cases), as well as the Property Assessment System
response Template D - Requirements Response Matrices
2. Provide a detailed description of all workflows identified during the planning phase of the Project
3. Perform on-site interviews with key ASR stakeholders to understand how the functional
specifications will be translated into software requirements
4. Conduct joint meetings with ASR’s Project team and Subject Matter Experts (SMEs) to validate the
functional specifications
5. Analysis of existing artifacts and working documents/systems to identify legacy business rules,
formulas, and decision support rules embedded in current systems and tools
6. Develop detailed functional specifications
7. Develop functionality groupings and provide a description with a detailed breakdown of functionality
by proposed grouping and any proposed implementation phases
8. Review draft functional specifications with the appropriate stakeholders, allowing time for those
stakeholders to return comments or clarifications
9. Prepare final functional specifications based on updates from appropriate stakeholders
10. When functional specifications are accepted by ASR, update as needed the workflows, use cases,
and requirements
The Proposer shall develop and provide to ASR the Functional Design Document, including at a
minimum:
1. Details on the requirements supported by the proposed Property Assessment System, any existing
ASR system components that may be leveraged to meet requirements, and which System
requirements/components will be newly developed based on a business process gap analysis
2. Business rules definition
3. Reporting capabilities and prebuilt reports
4. User profiles and security role permissions
5. System functionality traceable back to the Requirements Traceability Matrix
6. System overview diagrams illustrating which system components provide what functionality, linking
back to the workflows, use cases, and functional requirements
7. A maintainable list of workflows mapped to business processes and use cases mapped to System
requirements
8. User interface screens for the system
9. Identification of functions or user roles that initiate workflow receives the workflow, and any
processes that occur as a result of the workflow
10. List of assumptions made during the design as well as recommended next steps and required
actions that shall be confirmed by ASR before development/configuration
11. A comprehensive list of functional specifications to implement the functionality required
12. Recommendations on how to close specific gaps that require changes to ASR’s business
processes, including database diagrams, workflow diagrams, process flows, and/or use cases
13. Story Boards with screen mock ups to show how the system will meet business case scenarios.
The Proposer shall support the user review and acceptance process throughout the software
development lifecycle and shall maintain the Functional Specifications and Functional Design Document
throughout the Project—appropriately updating the document when any System design changes occur.

RFP# ASR2017-01 Attachment B – Detailed Statement of Work

Property Assessment Solution Page 13 of 38
ASR acceptance of the initial Functional Design Document is required before system
development/configuration can begin.
[Link] Deliverable 8 - Develop Data Conversion Plan

The Proposer must support the Property Assessment System data conversion processes, including the
design, support, maintenance, test, and execution of data conversion processes to enable the conversion
of Legacy system(s) data into their proposed system. The Proposer must work with ASR to recommend
data conversion strategies and develop a Data Conversion Plan that will facilitate converting the current
data in a seamless and timely manner. The Data Conversion Plan should include a detailed data
roadmap for successful population of data staging tables. These strategies must take into consideration
the impacts on the business processes and staff resources. ASR expects data conversion responsibilities
to be as follows:
1. ASR will be responsible for making the Legacy systems available for data conversion, extracting
data, performing data cleansing, and populating data staging tables
2. The Proposer will be responsible for providing detailed data conversion staging tables aligned with
their proposed system’s data structure and values (the Proposer will not be responsible for the
accuracy of legacy systems data)
3. The Proposer will be responsible for loading the populated staging tables into the proposed
Property Assessment System database and resolving any exceptions. The Proposer will be
responsible for performing all data testing to confirm successful conversion, and provide detailed
reports to ASR
4. ASR will be responsible for the final validation and approval of converted data
To meet current needs and in anticipation of the data conversion efforts, ASR has begun a number of
data initiatives, including developing a future state conceptual data model (Attachment H). ASR expects
the proposed Data Conversion Plan to leverage the conceptual data model and other relevant findings,
tools, and activities (e.g. data dictionary, cleansing activities, etc.).

The Proposer shall provide ASR with the Data Conversion Plan document, and shall provide support,
guidance and knowledge transfer to ASR for data conversion.

[Link] Deliverable 9 - Develop Interface Specifications and Design Document

The Proposer shall develop an Interface Specifications and Design Document that includes, at a
minimum, interface-relevant architecture models and interface management specifications pertaining to
the use of the Proposer’s system. The document shall provide insight on how different integration
technologies can be used together. The Proposer should leverage the City’s Joint System Integration
Plan (Template I) in developing the Interface Specifications and Design Document.
The Proposer shall provide ASR with the Interface Specifications and Design document, and shall
provide support, guidance and knowledge transfer to ASR for integration technologies. The document
deliverable should include:
1. Identifying interface requirements, specifications, and designs that will involve both internal and
external partners and ensuring that the new System is sufficiently scalable and flexible to support
the number of interfaces that will be required. Interface requirements shall also include defining
what communications shall be asynchronous versus synchronous
a. These interface requirements must include specifications regarding the temporary
interfaces that will be necessary for each/any proposed phases of the project.
2. Identifying security requirements, specifications, and designs that shall include encryption,
authentication, data protection, and constraints on performing certain operations

RFP# ASR2017-01 Attachment B – Detailed Statement of Work

Property Assessment Solution Page 14 of 38
 3. Identifying performance requirements, specifications, and designs that may include the expected
response time for system tasks, failover support for systems, and hours of availability
4. Identifying operational requirements, specifications, and designs that may include server needs,
scalability requirements, hosting requirements, monitoring, load balancing, failover, fault recovery,
accounting and metering
5. Identifying the intended methods for confirming successful interfacing between systems, and the
methods of reconciling interfaced data
6. If SOA based, include a centralized electronic catalogue of services to identify, manage, and track
all available services in use and services dependencies on other services
7. Clear identification of why the system uses a service, database link, point-to-point interface, or
other type of integration between data points
A key interface for the Property Assessment System will be with the new Property Tax System that is
currently planned to be simultaneously implemented by the Controller and Treasurer & Tax Collector
offices. The selected Property Assessment System vendor will be expected to collaborate with the Property
Tax System vendor in developing and implementing these interface specifications.

[Link] Deliverable 10 - System Architecture and Technical Design

[Link].1 System Architecture

The Proposer shall develop a System Architecture, which details the SOA model-driven framework being
used across all the domains (e.g. services, trust and security, infrastructure) that enables the
development of service-oriented models to facilitate the interaction and communication of technologies.
This document shall describe the set of technologies that support Property Assessment System
operations, incorporating the industry best practices and standards. It shall detail the design patterns,
information architecture, technology infrastructure and the conceptual, logical and physical architectures
for the targeted baseline System. The architecture document shall include the SOA principles around
SOA layers definition, the service providers/customer definition and the service broker definition.
The Proposer shall provide the System Architecture deliverable that includes the following:
1. Defines a conceptual architecture that will produce a design to fulfill Property Assessment System
stakeholder’s functional expectations
2. Defines a logical architecture model, including defined interfaces, data field definitions, and
validation rules
3. Defines the data architecture model
4. Defines a physical architecture that defines the various interface capabilities of the proposed
system and how they shall be implemented. This shall also include details around the integration
layers, potentially using web services and various other integration technologies
5. The conceptual, logical, and physical architecture shall fulfill functional requirements
6. Provides a detailed list of all the proposed production environment platforms, including Hardware,
OS, Networking, and 3rd party systems/tools/utilities, etc.
7. Describes how the architecture design features ensure that the System can scale as needed for
future transaction volumes, storage requirements, and System usage expansions over the next 10
years
8. Describes how the System will ensure performance based on expected data and user loading,
target source systems and target platforms (including any relevant “failover” design specifications)
9. Describes how the System will meet capacity requirements, including:

RFP# ASR2017-01 Attachment B – Detailed Statement of Work

Property Assessment Solution Page 15 of 38
 o A description of how System capacity and capacity requirements were calculated, including
all formulas and calculations used in capacity planning for ASR
o Descriptions of how capacity utilization will be monitored and capacity thresholds will be
established
o A description of corrective and escalation processes that will be used in the event any
capacity thresholds are reached
10. Describe backup and recovery procedures as well as disconnected operational capability to ensure
that the Property Assessment System can continue to operate in the event of an unexpected
destruction of hardware, software, or communications through System failure, disruption of
connectivity or natural disasters (these procedures and operations may differ depending on the
proposed system delivery model, but shall still be addressed)
o Arrangements for backup hardware or processing sites; off-site data storage; schedule for
creation of backup media; and detailed recovery procedures for all anticipated types of
disasters
o Document proposed escalation plans that specify the necessary points of contact and
decision-making authority at ASR
o Restoration sequencing of the System implemented as a result of this Project/program
11. Defines the details of security and privacy management for the proposed Property Assessment
System, including:
o Security and privacy policies
o Logical security controls (e.g. privacy, user access and authentication, user permissions,
user authorization)
o Technical security controls and security architecture (e.g. communications, hardware,
data, physical access, software, operating system, encryption)
o Security processes (e.g. security assessments, risk assessments, incident response)
o Description of how the System will function in the City networking environment while
adhering to all City security requirements
o The technical approach to satisfy the following, as applicable to the proposed Property
Assessment System and the system delivery model (the Proposer shall indicate items that
do not apply to its proposed delivery model in the assumptions section of Template H –
Project Plan):
 Network segmentation
 Perimeter security
 System security and data sensitivity classification
 Intrusion management
 Monitoring and reporting
 Host hardening
 Remote access
 Encryption
 City-wide active directory services for authentication
 Interface security
 Security test procedures

RFP# ASR2017-01 Attachment B – Detailed Statement of Work

Property Assessment Solution Page 16 of 38
  Managing network security devices
 Security patch management
 Detailed diagrams depicting all security-related devices and subsystems and their
relationships with other systems for which they provide controls
 Secure communications over the Internet

[Link].2 Technical Design Document

The Proposer shall develop the Technical Design Document (TDD) based on outputs from the technical
design sessions conducted with the Proposer and ASR.
The TDD shall provide a complete and comprehensive technical explanation of how the System will
provide the performance, functionality, scalability, supportability, and operations specified in the Scope of
Work and the Functional Design Document (FDD) deliverable, including, as applicable, details of
processes, visual displays and estimates of transaction and data volumes, and including the database
logical and physical model and the associated data dictionary.
The Proposer shall complete the following tasks during the development of the TDD:
1. Based on the FDD, conduct joint meetings with ASR’s Project team and SMEs to validate and
refine the technical design specifications
2. Develop detailed technical design specifications
3. Review draft technical design specifications with the stakeholders, allowing time for those
stakeholders to return comments or clarifications
The Proposer shall provide the Technical Design Document to include a minimum of the elements
described above and the following components:
1. Detailed description of System architecture
2. User Interface Design
3. Data Conversion Design
4. Logical Architecture Diagram
5. Physical Architecture Diagram
6. Excel inventory with details by server and system to be setup (if applicable to the System delivery
model of the proposed System, including all relevant environments)
7. Entity Relationship Diagrams
8. Data Flow Diagrams
9. Data Dictionary
10. Processing controls
11. Processes to manage System installation and configuration
12. Security controls
List of assumptions made during the technical design as well as recommended next steps and required
actions that shall be confirmed by ASR before the development. The Functional Design Document (FDD)
and the TDD shall be the documentation used by the Proposer during System Development.

1.3.3 Task 3 – System Development / Configuration

[Link].1 System Development Activities

RFP# ASR2017-01 Attachment B – Detailed Statement of Work

Property Assessment Solution Page 17 of 38
System development and/or configuration efforts shall be guided by the deliverables accepted by ASR
during the System Design phase. This ensures that the System is developed/configured according to the
documented functional and technical specifications. Unless otherwise agreed to, in writing, by ASR, the
Proposer shall not initiate the System development and/or configuration activities until ASR has formally
accepted the Functional Specifications and FDD and the TDD Deliverables.
The Proposer shall develop/configure each functional module of the Property Assessment System in
accordance with the proposed System Development Strategy.
During System Development, the Proposer shall fully document all software components. This
documentation shall support knowledge transfer to the Assessor-Recorder staff.
[Link].2 System Development Methodology

The Proposer shall document the System Development Methodology for the Property Assessment
System, including but not limited to:
1. A formal process to review, provide feedback and approval on development documentation
submitted to ASR by the Proposer
2. Methodology standards as defined in the previous tasks and strict process guidelines for the
development, configuration, test, and delivery of the new System
3. Standards and processes to manage the early identification and remediation of defects in Project
Deliverables
4. A change methodology process and change control standards, criteria and process for the
development, configuration, test, and delivery of the new System and all work products
5. Secure coding tools and methods and standards
6. The required system development and testing tools (i.e., defect tracking tools, etc.) that have been
identified during the earlier steps
7. Industry best practices for development support, and testing standards

[Link].3 Software Configuration Management

Software Configuration Management includes the identification and maintenance of System software
components and the relationships and dependencies among them. The activities the Proposer shall
perform include:
1. Automatic capture and storage of IT Service to System, System-to-Component and Component-
to-Component relationships
2. Data and work flow diagrams
3. Maintenance of the history of those relationships and any transformation required to appropriately
manage and document (e.g. source control, version control, profiles, security plans) configuration
changes affecting the system and its processing environment
The Proposer may identify and use specific automated tools and infrastructure for Software Configuration
Management, if applicable. If an automated tool is used, the Proposer shall provide read-only access to
designated ASR users. The Proposer shall provide all data from automated configuration management
tools to ASR at the conclusion of the Project in a non-proprietary format.
[Link].4 Change and Release Management

As part of the proposed Property Assessment Solution, the Proposer shall be responsible for Change and
Release Management activities. These include all tasks required to manage and document (e.g. through
impact analysis, version control, library management, turnover management, build management, parallel

RFP# ASR2017-01 Attachment B – Detailed Statement of Work

Property Assessment Solution Page 18 of 38
development) changes to the system and any of the system components being developed. Change and
Release Management also includes all tasks required to appropriately manage and document changes to
the underlying System development environment components. Proposer activities shall include the
following:
1. Library Management—the classification, control, and storage of the physical components of the
System
2. Version Control—the maintenance, tracking, and auditing of modifications to a System’s
components over time, facilitating the restoration of the System to prior development stages
3. Turnover Management—the automated promotion of software changes across different phases
of the life cycle (e.g. development/configuration, unit test, systems test, and production), including
management of the approval process, production turnover, and software migration control

[Link] Deliverable 11 - System Implementation Plan

The Proposer shall develop a System Implementation Plan document that incorporates the final Design
Documents for the overall proposed system implementation. This document shall be developed based on
outputs from the planning and design sessions conducted with the Proposer and Assessor-Recorder
staff. The plan shall at a minimum include detail on the following components:
1. Implementation schedule (for each phase)
2. Points-of-contact to include individual names and contact information for each member of the
implementation team, Proposer, and Assessor-Recorder
3. Major tasks
4. Security and privacy
5. Implementation support
6. Hardware, software, facilities, and materials for all Environments
7. Personnel and staffing requirements
8. Outstanding issues and the mitigation plan for each
9. Implementation impact and organizational change issues
10. Performance monitoring
11. Configuration management interface
12. Risks and contingencies
13. Implementation verification and validation
14. Definitions of the criteria for both success and failure of the System Implementation (for each
Phase, if applicable)
15. Data conversion and integration needs
The Proposer shall provide a System Implementation Plan for the implementation of the Assessor-
Recorder’s functionality. The plan shall include the elements outlined above and the following
components:
1. Assessor-Recorder implementation roadmap(s)
2. Target end-user population included
3. Deployment schedule for the functionality
4. Workflow analysis and documentation aligned with the office’s workflows and use cases

RFP# ASR2017-01 Attachment B – Detailed Statement of Work

Property Assessment Solution Page 19 of 38
 5. Technology components required
6. Identification of the source systems to be integrated

[Link] Deliverable 12 - Data Conversion, Synchronization, and Reporting

The Proposer shall perform the necessary data integration and synchronization work to implement the
System in compliance with the requirements of the Scope of Work and the Data Conversion Plan. The
Proposer shall develop a detailed plan to validate all integration and synchronization routines have been
successful, as well as the accuracy and integrity of all data integrated from the Proposer provided staging
tables.
Data Conversion is divided into the following steps:

Step Data Conversion Activity Responsibility

Data extraction –Data is extracted from the ASR is responsible for legacy data extraction.
legacy systems based on specified The Proposer shall support ASR efforts.
1
selection criteria (parcel number, business
account number, etc.).

Data Purification – Each data element is ASR is responsible for the maintenance and
validated for acceptable data values. purification of data prior to being
Exceptions to the data validation rules are entered/uploaded to a Property Assessment
2 reported during dry runs for correction. Data System staging table. The Proposer shall
that fails purification is not converted into support Assessor-Recorder efforts.
the proposed system, but identified as a
conversion failure further analysis.

Data Merge – Data from all systems are ASR is responsible for the maintenance and
merged together on the basis of identifying purification of data. ASR will then merge all
characteristics (e.g., parcel numbers, owner extracted and purified data into a succinct data
3 accounts, etc.). file to be shared with the Proposer prior to
being entered/uploaded to a Property
Assessment System staging table. The
Proposer shall support ASR efforts.

Data Translation – Data that has The Proposer is responsible for design and
successfully passed the purification process build any/all ETL logic required to translate the
is translated into the proposed Property data from ASR provided data files to the
Assessment System values on the Proposer’s Staging Tables.
proposer-provided data staging tables,
4
converted into the Property Assessment The Proposer is responsible for providing all
System structure and loaded into the Staging Tables, populating the Staging Tables
Property Assessment System database. based on the data file provided by ASR, and
for maintaining the tables once translated and
populated.

Data Load – Data populated onto the The Proposer is responsible for loading all
5 Property Assessment System staging tables populated Property Assessment System
is loaded into the Property Assessment Staging tables into the proposed system
System database. Data that has been database, and managing/tracking the Data

RFP# ASR2017-01 Attachment B – Detailed Statement of Work

Property Assessment Solution Page 20 of 38
 Step Data Conversion Activity Responsibility

loaded is tracked to monitor Data Conversion process and progress, including

Conversion progress. reconciliation of the data migration iterations.

Data Test – Once the data is loaded into the The Proposer is responsible for testing the
Property Assessment System database, the conversion of legacy data from the point of
conversion of data shall be thoroughly populating Property Assessment System
tested and verified as successfully staging tables to completed conversion. The
6 converted, without significant discrepancy. Proposer is responsible to work with ASR to
identify any root-cause issues preventing data
conversion from being fully successful and
conduct any reconciliation necessary to ensure
success.

Data Validation – Once data has been ASR is responsible for the final validation and
tested by the Proposer, ASR will perform approval of converted data. The Proposer shall
final data validation and approval. support Assessor-Recorder staff by providing
7
easy access and issue identification reporting
tools. Issues. identified will be referred back to
the Data Test activity phase for correction

[Link] Deliverable 13 - System Maintenance, Support and Transition Plan

The Proposer shall provide a written plan for the maintenance, support, and transition of the System into
the Production Environment. The Proposer shall provide support, guidance and knowledge transfer to
ASR for integration technologies to be used by the System ongoing. The plan should align with the
proposed delivery model.
The following documentation, at a minimum, shall be prepared by the Proposer and included in the
System Maintenance, Support and Transition Plan provided to ASR:
1. Development of a System support structure and organization, including estimates of the Proposer
and Assessor-Recorder manpower requirements to support operation and maintenance of the
System
2. The skill sets required to operate and maintain the System should be specified, with
recommendations of the skills, knowledge, and abilities required by Assessor-Recorder business
and technical staff
3. System Installation and Administration Manual
4. Documentation of the completed Property Assessment System code, and/or an escrow agreement
regarding the completed code (based on the final negotiated terms and contract with the City).
5. Operating procedures manual, including diagnostic procedures, backup and restore procedures
and disaster recover procedures
6. Maintenance manual, including Information to aid in analyzing and debugging the software, apart
from information already available in other delivered documentation
7. Maintenance and repair policies and procedures
8. Updated system architecture diagrams and inventory (systems, servers, etc.) that clearly identify
what is in pre-production environments and what is in production use
9. Property Assessment System Database Schema (that aligns with ASR’s Conceptual Data Model,
Attachment H)

RFP# ASR2017-01 Attachment B – Detailed Statement of Work

Property Assessment Solution Page 21 of 38
 10. Complete Data Dictionary (leveraging ASR’s current data initiatives and data dictionary)
11. System “Run Book” as defined by ASR
12. Data flow diagrams, system flow diagrams, interface diagrams and relevant workflow diagrams.
The Proposer shall provide a System Maintenance, Support, and Transition Plan to include the
elements defined above.

1.3.4 Task 4 – System Testing

[Link] Deliverable 14 - Detailed Test Plans

The Proposer shall be responsible for the development of all Detailed Test Plans, which includes the
following testing events:
[Link].1 Unit and Integration Testing

The Proposer shall perform Unit and Integration Testing as necessary during the development process.
ASR will require the presentation of Unit and Integration Testing plans and results during scheduled
development review meetings.
[Link].2 System Testing

The System Testing is aimed at proving that the System meets the stated requirements and objectives by
validating the total system in real world scenarios using ASR data. This testing shall be performed by the
Proposer but may be supported by a limited number of Assessor-Recorder power-users (not end-users)
at the sole discretion and to the limit deemed appropriate by ASR.
1. Entry Criteria – The feature set, although largely defined and static, may still not be completely
finalized. All features that have not yet been implemented are prioritized in case postponement of
certain features is desired by ASR. The software has been unit tested, and there is a high level of
confidence the completed software is ready
2. System Test Execution – The System Testing shall utilize Assessor-Recorder data, and shall be
performed by the Proposer or a City approved third party. The System test shall be intended to
demonstrate the critical business functions of the System and the overall effectiveness of the user-
facing aspects. The Proposer shall provide and ASR shall accept the System Testing plan before
it is executed. At a minimum, the Proposer shall incorporate the following activities during System
Testing:
a. Demonstrate Critical Business Function Scenarios (as defined by and approved by ASR)
– data and processes must be fully integrated across functional areas and that integration
fully demonstrated
b. Transaction Testing (as defined by and approved by ASR)
c. Error Message Testing
d. Documentation Testing (as defined by and approved by ASR)
e. Help Systems Testing (as defined by and approved by ASR)
f. Demonstrate the complete sequence of functional business tasks (as defined and
approved by ASR)
g. End-to-end business process testing (as defined by the detailed business requirements
and approved by ASR)
h. Report generation and printing
i. Interface testing (all interfaces included in the module/system)

RFP# ASR2017-01 Attachment B – Detailed Statement of Work

Property Assessment Solution Page 22 of 38
 j. Demonstrate the complete sequence of functional business tasks (as defined and
approved by ASR)
k. Usability/Interface Testing
l. Reliability Testing
m. Performance Testing (stress, load testing)
n. Security Testing
o. System recovery and restoration Testing
p. Regression Testing
q. Integration Testing
r. Integrity Testing
s. Data Testing
t. User Role Testing
u. Data Conversion Validation
3. Exit Criteria – The results of the System Testing are to be presented to ASR for approval before
the development/configuration System status can be promoted to UAT stage for end user testing.
This presentation shall take the form of a live demonstration of System functionality if requested by
ASR. No less than 20 City business days before the start of the System Test phase, ASR shall
define the criteria necessary for ASR approval of test results, including requirements for
presentation of the results to ASR and timeframes for ASR review
[Link].3 User Acceptance Testing

The purpose of User Acceptance Testing (UAT) is to confirm that the System is developed according to
the Assessor-Recorder’s business functionality, performance, and technical requirements and that it is
ready for enterprise deployment and operational use. During UAT, selected Assessor-Recorder end-
users will compare the System’s functionality, features, and performance to the Assessor-Recorder’s
System Requirements Documents, Design documents, and ASR documented UAT exit criteria.
1. Entry Criteria – Prior to moving from System Testing to UAT, the System’s feature set shall be
fully defined and static. The final release version shall have been built from source control. This
final version shall have passed a formal Proposer quality assurance acceptance test, which also
covers “installation” instructions on how to update technical and end user documentation.
Converted ASR data shall be used for UAT
a. Severity Levels – The requirements for release to UAT shall be zero Severity 1 and zero
Severity 2 defects. ASR and Proposer Project managers will meet and mutually agree on
an acceptable level of Severity 3-5 defects in order to move forward. Defect levels of
severity are defined as:
i. Severity 1 - Catastrophic: The defect prevents the System from meeting the
majority of the Assessor-Recorder requirements
ii. Severity 2 - Major - No Work Around: The defect prevents a major function of the
System from meeting ASR’s requirements and there is no effective work around
to meet these requirements
iii. Severity 3 - Major - With Work Around: The defect prevents a major function of the
System from meeting ASR’s requirements, but there is an effective (does not
cause ASR effort in addition to that currently performed for the same function) work
around to meet these requirements

RFP# ASR2017-01 Attachment B – Detailed Statement of Work

Property Assessment Solution Page 23 of 38
 iv. Severity 4 - Minor: The defect prevents a minor function of the System from
meeting ASR’s requirements
v. Severity 5 - Cosmetic: The defect has minimal or cosmetic effect on the System
meeting ASR’s requirements
2. Pre Test – The Proposer shall perform the following activities prior to User Acceptance and
Reliability Testing (UAT):
a. Development of the overall UAT Testing plan and schedule (Proposer/ASR)
b. Build the UAT System release
c. Develop and document the software build instructions for UAT
d. Install and configure the UAT release System components and database(s) on the
designated testing environment
e. Develop and provide the required UAT Testing documentation (e.g. end user guides,
systems administration manuals, user help files) and provide to ASR for approval for use
during UAT activities
f. Load database(s) with complete and validated production-ready datasets (converted ASR
data)
g. Ensure security roles are in the testing environment
h. Develop comprehensive UAT scripts that test each and every requirement as specified in
this SOW in a logical and business process-oriented manner approved by ASR’s Project
Manager
i. Ensure Service Level Requirements are met by system functions (excluding capacity load
testing for transaction volumes)
3. Conduct UAT – There are a number of activities that the Proposer and ASR must perform for the
completion of the UAT. At a minimum, the following activities shall be performed:
a. Identification of the required ASR and Proposer resources to support UAT activities
b. Provide Proposer resources to support UAT activities
c. Development of the defect resolution management plan (Proposer)
d. Review and acceptance of the defect management plan (ASR)
e. Compilation of all relevant converted data needed to permit ASR to validate that the
System meets all functional, operational, performance, and support requirements. This
shall include:
i. The Project statement of work (ASR)
ii. Systems requirements documents (Proposer/ASR)
iii. Software requirements document (Proposer/ASR)
iv. Requirements Traceability Matrix (Proposer)
v. Systems Configuration Management data (Proposer)
vi. End-user documentation (user manuals, systems administration procedures, and
training documents) (Proposer)
vii. ASR Approval UAT Testing plan (ASR)
viii. Compiling and evaluating the UAT Testing results (Proposer)
ix. ASR approval of the UAT results and corrective actions (ASR)

RFP# ASR2017-01 Attachment B – Detailed Statement of Work

Property Assessment Solution Page 24 of 38
 x. ASR acceptance of the overall System and its readiness for production deployment
(ASR)
f. All problem/error reports shall be responded to within two business days by the Proposer.
Any Severity 1 (causing the System to fail to perform a basic business function) problem
shall be responded to within two hours. The acceptability of remedial fixes will depend on
the nature of the problem but shall be solely at ASR’s discretion. When UAT tests are rerun,
the reruns shall be treated as any other UAT test activity and documented accordingly
g. Software shall be feature complete. Changes taking place must be considered by ASR a
low risk to the underlying stability of the software. The software shall have been rigorously
tested by the Proposer’s quality assurance before being provided to ASR, and there shall
be a high level of confidence the software is working as customers will expect
4. Exit Criteria – The requirements for release from UAT are zero Severity 1 and zero Severity 2
identified defects. The default ASR requirement for Severity 3 is zero. However, if actual Severity
3 defects are greater than zero, the designated ASR staff will review the defects and make a
recommendation to ASR whether to release to production or not. The Office of the Assessor-
Recorder, and Proposer Project managers will meet and mutually agree on an acceptable level of
Severity 4-5 defects in order to move forward. Defect levels of severity are as defined above
a. All known problems are to be reviewed by ASR Project Manager and any additionally
designated staff. No outstanding problems should affect overall customer expectations for
the System. Supporting materials such as release notes, user manuals, and training
manuals shall be in final form and shall also been verified by the Proposer’s quality
assurance or other appropriate reviewers. Customer support (if applicable) shall be fully
prepared to support the product at this point
b. The Proposer shall present in person the results of the completed User Acceptance Testing
process to ASR after review by ASR Project Manager. The Proposer shall also prepare a
report detailing any remaining defects of all severities and the expected impacts of each,
and deliver the report at the same time as the presentation. ASR will review the results and
approve or reject the completion of the UAT phase
[Link].4 Performance Testing

The Proposer shall perform Performance Testing. Performance Testing shall include both stress and load
testing to verify System performance. ASR shall provide final acceptance of the proposed system’s
performance.
[Link].5 System Regression Testing

The Proposer shall perform Regression Testing throughout the testing process to verify System integrity
after functional improvements or fixes have been made as a result of System Integration and User
Acceptance test activities. ASR has a preference for using automated scripts, although it is not required.
Regression Testing shall be designed to confirm that fixes have not created any new problems and that
the results are as planned. The results will also define the System baseline configuration to be released
to ASR. The Proposer team shall document all tests performed and provide the results to ASR. It shall be
the responsibility of the Proposer to ensure all automated test scripts have been assessed to ensure their
proper function.
[Link].6 Testing Plan

The Proposer shall provide a Testing Plan that includes the elements outlined above and a detailed
schedule for each of the activities to be completed within the test phase, including the individuals (named
and role) responsible for the completion and or approval of each activity. Activities in the Test Plan shall
include at a minimum:
1. Definition of the Test Phase and Objectives

RFP# ASR2017-01 Attachment B – Detailed Statement of Work

Property Assessment Solution Page 25 of 38
 2. Entrance Criteria for the Test Phase
3. Exit Criteria for the Test Phase
4. Key milestones (i.e. relationship in terms of timeframes days, weeks/ months, to predecessors and
successor tasks) associated with each Testing Phase, including:
a. Test Case Approval
b. Test Environment Readiness
c. Test Start and End dates
d. System Baseline Configuration Established
e. System Development Freeze Date(s)
f. Required Approval Dates for Test Cases, Entrance and Exit Criteria, etc.
g. Regression Testing start and end dates
h. Test Results Review Meeting Completion
i. System Release Promotion Go/No-Go Decision

[Link] Deliverable 15 - Test Scenarios, Test Cases, and Test Scripts

The Proposer shall develop comprehensive Test Scenarios, Test Cases and Test Scripts that test each
requirement in a logical and business process-oriented manner. The Test Scenarios, Test Cases and
Test Scripts will cover all test events defined in Section [Link].6. Development shall occur in consultation
with the relevant ASR SMEs for each area.
To ensure that the System has been thoroughly tested, the Proposer shall provide Test Scenarios, Test
Cases, and Test Scripts as well as data sheets to include all of the elements defined above to ensure
comprehensive test coverage of each and every requirement as specified in this SOW. The Test
Scenarios, Test Cases, Test Scripts, and data sheets shall additionally:
1. Include a catalog of all of the Test Scenarios, Test Cases, and Test Scripts
2. Will be in the form and format specified by ASR
3. Will map to the unique identification numbers assigned to all requirements in the Requirements
Traceability Matrix

[Link] Deliverable 16 - Documented System Test Results

The Proposer shall provide comprehensive Documented System Test Results for each test event
identified in this SOW for ASR review and approval. Test Results shall include all of the test activities
identified above, with the following components for each test event:
1. Test coverage matrix for each test phase identified above (excluding Unit Testing)
2. Completed Systems requirements vs. functionality tested matrix for each phase and for the final
System delivery
a. Defect reports
b. Monthly test issues and mitigation reports
c. Test phase final results report and corrective action(s) plan

RFP# ASR2017-01 Attachment B – Detailed Statement of Work

Property Assessment Solution Page 26 of 38
1.3.5 Task 5 – Project Training
The overall objective of the Property Assessment System training is to provide all staff with the skills,
knowledge, and incentives that will enable them to more efficiently and effectively use Property
Assessment System in the most productive manner. The Property Assessment System training must
provide the following benefits:
1. Encourage adoption of the Property Assessment System
2. Increase collaboration and coordination among programs through use of the Property Assessment
System
3. Provide ASR the ability to efficiently and effectively assume training responsibilities subsequent to
implementation
4. Understand the business reengineering and associated benefits and organizational changes that
must occur as a result of the new System
5. Ensure that all users gain an overall understanding of Property Assessment System functionality
and use
The Proposer shall provide professional-level training staff specializing in business systems training to
work with Office of the Assessor- Recorder staff to develop and implement a Training Plan for the Project,
deliver initial training, develop on-going training curricula and material, develop reinforcement training
material, and evaluate the effectiveness of the Property Assessment System training. ASR shall have
approval over Proposer-provided staffing used for training and over the format/content of the training to
be given.
A “Training Team” consisting of a Proposer’s training specialist, other Proposer staff, and ASR staff shall
participate in various Phases of the Project to gain an understanding of System design and functionality.
The Team shall have direct access to the Project test systems in order to map workflows and copy
system screens, outputs, and other materials needed to produce the documentation necessary for staff
training. The professional training staff shall provide all user training specified in this RFP.
Although ASR staff will participate in decisions on Training Plans and materials, the Proposer is solely
responsible for creating those plans and materials, implementing the Training Plan, and delivering the
training for the duration of the contract. The Proposer shall:
1. Provide effective training on the required knowledge, skills, and abilities necessary to use and
administer the proposed Property Assessment System
2. Provide timely training which ensures transition from training to actual operations and application
to staff work
3. Provide necessary reinforcement training following initial training
4. Ensure that there is easy access to training on the part of trainees
5. Be responsible for the development of user training curricula, schedules, training materials and
training evaluation materials in accordance with the accepted Training Plan
6. Be responsible for assisting ASR with the setup and maintenance of an online training environment
that allows trainees to access the new System
7. Be responsible for conducting face-to-face, hands-on, user training in logical groupings at locations
determined by ASR, and for managing all training planning and logistics in coordination with ASR
8. Develop on-line instruction material for external ASR stakeholders regarding access to the
customer service capabilities and functionality in Property Assessment System
9. Be responsible for coordinating training efforts with ASR’s SMEs who will provide policy and
practice support during the training sessions

RFP# ASR2017-01 Attachment B – Detailed Statement of Work

Property Assessment Solution Page 27 of 38
 10. For those users engaged in UAT, training shall be provided prior to UAT for those users to ensure
a complete understanding of the system prior to testing. For all other users, training shall be
provided “just in time” prior to deployment and must comprehensively address all System
operations as well as security considerations
11. Development of online training, self-pace training materials.
In addition to focusing on the navigation and functional use, the user training shall also focus on how the
System is integrated into the day-to-day work of end users, including any newly introduced business
processes and/or workflows related to ASR’s business processes. To the fullest extent possible, the
training classes shall consist of trainees with similar job duties and materials and the training approach
should reflect a user-specific focus, including the use of user-specific case scenarios. User training
sessions are expected to focus on how staff will utilize the system to meet the objectives of their typical
responsibilities.
User engagement and adoption is critical to the success of the Project. As such, Proposer shall organize
training in an interesting, non-technical manner to keep the trainees’ attention. Innovative training aides,
case studies, scenarios, humor, gamification, and other learning tools that will engage the users and
support information retention are encouraged.
If the implementation of Property Assessment System is delayed after initial training has been completed,
the Proposer shall provide refresher training.

[Link] Deliverable 17 - Training Plan

The purpose of the Property Assessment System Training Plan is to identify the activities and define the
curricula necessary to support Assessor-Recorder staff’s adoption and effective use of the Property
Assessment System. The Proposer’s developed Training Plan shall include the delivery of user training,
as well as the training of Assessor-Recorder staff to assume future on-going training responsibilities. The
Plan document shall state the purpose and scope of the Training Plan that meets the requirements of this
contract, as well as including the following training Curricula components:
The Proposer shall provide a Training Plan that meets the requirements described above and, at a
minimum, the following components to be approved by ASR’s Project Manager:
1. Detailed description of the training model for adult learners
2. Flow diagrams (work flow diagrams, process diagrams, etc.) and detail for the training curriculum
for each functional area and integration into the end-to-end business process
3. Specific training curricula targeted and delivered to the different users in a manner that meets
their specific needs including, but not limited to:
a. Property Assessment System User training – shall focus on hands-on Property
Assessment System usage to enable users to accomplish their day-to-day activities
b. Security administrator training – shall include instruction regarding use of query and
custom reporting tools in order to monitor and research patterns of Property Assessment
System use. This training shall enable security administrators effectively and efficiently
fulfil their job duties to monitor and investigate system access, including, but not limited
to, inappropriate access to records by users, identification of transactions performed by
specific users, inappropriate extracts or downloads of data by users, and other patterns
of use that may require intervention or corrective action
c. Property Assessment System Supervisor training – shall include courses identical to the
Property Assessment System users as well as a separate training course that focuses on
supervisory job functions such as controls and reports
d. Administrative and management staff training – shall have a management-oriented
training course, including but not limited to development of basic dashboards created

RFP# ASR2017-01 Attachment B – Detailed Statement of Work

Property Assessment Solution Page 28 of 38
 from pre-made modular content and an overview of the reporting and analytic capabilities
of Property Assessment System, as well as use of Property Assessment System for
decision support so that administrative and management staff have an understanding of
what kinds of analysis they can assign Power Users to perform
e. Analyst training – shall focus on hands-on Property Assessment System usage to
generate basic reports and use analysis features and use of Property Assessment
System for decision support for both programs and executive management staff
f. Power User training – These users will perform advanced analysis of the aggregate data.
Power User training shall focus on hands-on use of the business intelligence tools in
Property Assessment System including, but not limited to custom query and development
of specific business area analytics. Proposer shall ensure Power Users are made familiar
with the Property Assessment System data model so that they may perform their job
functions effectively and efficiently. Because most Power Users have specialized analytic
software, training shall include any necessary instruction a Power User will need in order
to transition data from Property Assessment System to analytic software
g. Trainer training – Proposer shall train individuals identified by ASR to become future
trainers so that ASR may effectively and efficiently assume training responsibilities after
Property Assessment System implementation
h. Configuration Training – Proposer shall train individuals identified by ASR to be able to
make configuration so that ASR may effectively and efficiently assume configuration
responsibilities after Property Assessment System implementation
i. Constituents/Customer training – Proposer shall provide on-line training material to
instruct Assessor-Recorder customers regarding accessing their own information through
Property Assessment System and using features to participate in the management of
their services. Customer training shall be developed to be self-service based, online, and
incorporate the development and use of quick reference guides and frequently asked
questions
j. Technical Administrator training – Proposer shall provide technical level training to
instruct Assessor-Recorder Property Assessment System administrators and technical
staff regarding Property Assessment System capabilities, operations, work flow, and
System administration
k. Report Development training. This would include the development of report queries and
ad hoc queries
4. Training Materials Development Plans
a. Detailing the Role of the ‘Training Team’
b. Documentation style standards for the development of training material (e.g. document
format, references, acronyms, font)
c. Plan for review of training material
d. Approach to prototyping and testing training materials with training customers
e. Approach to modifying or adjusting training materials based on the results of the
Evaluation of Training Effectiveness
f. Trouble shooting techniques
5. Training Equipment Plans (including plans for training facilities and equipment)
6. Tracking training results
7. Training Methodology and Delivery Plans:

RFP# ASR2017-01 Attachment B – Detailed Statement of Work

Property Assessment Solution Page 29 of 38
 a. Identification of the training mix including, but not limited to, web-based learning in-
person learning, learning-labs, and informal learning. (Because of the constraints related
to scheduling staff out of the office for multiple training sessions, Proposer shall develop
a training mix that leverages use of online training tools and self-guided learning material
that is supported by in-person training)
b. Identification of plan to motivate and engage Property Assessment System users to learn
about and use the system and complete the training
c. The logistical plan for preparing and delivering the training solution including, but not
limited to:
i. End-user support website
ii. Web-based navigation training
iii. Training enrollment process
iv. Tracking of users’ completion of training
v. Training locations and proximity to ASR
8. Training Schedule and timeline of training development, delivery, and evaluation.
9. Plan for Evaluation of Training Effectiveness
a. Proposer Evaluation of training effectiveness shall be based on the Kirkpatrick/Phillips
model of learning evaluation. A similar evaluation model may be approved by ASR
b. Plan shall include how Proposer will address any deficiencies in the proficiency of the
current cohort of trainees based on the results of the evaluation of training effectiveness
c. Plan shall include how Proposer will modify or adjust training approach based on the
outcomes of the Evaluation

[Link] Deliverable 18 - Training Manuals, Guides and Materials

Proposer shall develop training materials in such a way as to allow for the capability of training to
continue beyond initial deployment. Ownership of delivered and accepted training materials shall transfer
to the City at the time of acceptance.
All training material shall have a consistent look and feel and shall be provided in a soft copy format so
that ASR may easily make modifications to the materials if necessary. All training materials shall be
maintained to reflect the latest version of Property Assessment System and the changes resulting from
evaluations and use during acceptance, testing, and implementation. All training material shall be
maintained on-line.
The Proposer shall be responsible for developing and providing training materials and for training ASR
staff on System operation. The Proposer shall employ professional-level training staff (not technical staff)
to prepare training and user materials. ASR shall have approval over the format/content of the training to
be given. ASR and Proposer staff shall work together to develop the format/content for the training and
user materials that the Proposer shall produce. These materials shall be provided to ASR in both hard
and soft copy. ASR must accept these materials before they are distributed to ASR staff for use.
Training Manuals, Guides, and Materials shall include, but not be limited to:
1. Instructor/Trainer guides shall provide the ability for ASR staff to perform all training activities
initially provided by the Proposer on an ongoing and continuing basis
2. Trainee packages shall provide the trainees exercises and usable examples with which to
practice the lessons provided during formal training (for all user training types, including end
users, power users, administrators, and any others mentioned in the sections above)

RFP# ASR2017-01 Attachment B – Detailed Statement of Work

Property Assessment Solution Page 30 of 38
 3. System user’s manual shall provide non-technical Property Assessment System information as
related to business functions in the explanation of Property Assessment System features,
functions, modules and tools and the detailed procedures for using the proposed Property
Assessment System
a. The System user manual shall be designed for ease of use so that any user, regardless
of his or her function, can readily locate, identify, understand and use the information
b. The manual shall include copies of all screens with instruction on the use and function of
each, including the definition of all data elements. System user manual shall include a
catalog of all reports, forms, letters, and other system-generated documents (generated
either automatically by the system or by the user)
c. The manual shall include workflow diagrams that enable the user to understand the flow
of activities necessary to perform business functions
d. The manual shall include a description of the problems and issues that may arise while
using the Property Assessment System and the procedures for resolution
4. Desk aids shall provide, at a minimum, quick access to solutions and information which users
most frequently need (including Frequently Asked Questions, etc.)
5. User tips which shall be designed as short message reminders about short-cuts, features, and
other relevant information to promote end-user adoption and use of the Property Assessment
System
6. Quick reference guides that provide a concise bundle of condensed notes about various system
functions
7. Cross walks of prior functionality / activities to current functionality / activities

[Link] Deliverable 19- Documented Evidence of Successful End-User Training

Proposer shall provide Documented Evidence of Successful End-User Training at the end of each phase
of training. Evidence shall include at a minimum:
1. Tracking of employee attendance and completion of training courses and modules
2. An evaluation of training effectiveness using an ASR-approved measurement instrument
3. Actions addressing any deficiencies in the proficiency of the current cohort of trainees based on
the results of the evaluation of training effectiveness
4. An action plan to adjust or modify future training based on the evaluation outcomes

1.3.6 Task 6 – Deployment

[Link] Deliverable 20 – Release Readiness Evaluations and Reports

The Proposer shall provide a Release Readiness Evaluation and Report for each release of software
provided to ASR.
The Proposer should assuming ASR will employ a structured Release Management process during the
testing and deployment of System components that will be led by the Assessor-Recorder’s Project
Manager.

[Link].1 City Business Site Readiness

RFP# ASR2017-01 Attachment B – Detailed Statement of Work

Property Assessment Solution Page 31 of 38
The Proposer shall work with ASR Project team to establish minimum site readiness requirements for
each physical business location prior to go-live of each Property Assessment System release to the
production environment. The Proposer shall be responsible for developing site readiness assessment
tools accepted by ASR. Based on the results of the site assessments performed by ASR, the Proposer
shall prepare a site assessment report addressing the site or sites affected for review and acceptance by
ASR Project Manager or other designated staff.

[Link].2 Release Readiness Evaluation and Report

The Proposer shall develop a Release Readiness Evaluation and Report. The report shall consist of an
updated Release Readiness notification and updated documentation to describe all required System
operational activities—including guidance on System maintenance and enhancement practices, tools,
and approaches. The report must encompass System functionality from a remote user’s perspective, an
ASR business user’s perspective, and from an information technology and system
operations/Administrator perspective.
The Proposer shall provide a Release Readiness Evaluation and Report for each release of software
provided to ASR. The Release Readiness Evaluation and Report shall include an overall assessment of
the state of the software being considered for release and an analysis (in writing) as to whether it meets
the exit criteria contained in the appropriate Test Plan as well as the Release Criteria documented below.
1. Release Test Coverage Matrix and Results
2. Release Functionality
3. Release Interfaces and Data Stores
4. Release Hosting Requirements, if applicable
5. Release Support and Maintenance Requirements
6. Release Test Strategy and Plan
7. Release regression test results
8. Release Report of defects or punch list
9. Site Readiness Report
10. Data Migration Readiness
11. Change Readiness Assessment
12. Detailed Step-by-Step Cutover Plan
13. Roll-Back Considerations, if any
Additionally, for each completed functionality set to be deployed, the Proposer must provide
documentation in the form of “step-by-step manuals.” This documentation shall include the following types
of information:
1. For a business user audience –
a. A list of all included documentation and its use (i.e., use, configuration, administration, etc.)
b. A description of how to use the System based on user roles and responsibilities
c. A description of all screens and how they are interrelated
d. A list of prebuilt reports and their descriptions
e. A description of the key data tables, elements, and their contents
f. A description of all help and navigation functions and how to use them, including
informational graphics and story boards

RFP# ASR2017-01 Attachment B – Detailed Statement of Work

Property Assessment Solution Page 32 of 38
 g. A description and diagram of the workflows
2. For a technical user audience –
a. A complete list of error messages, their descriptions, and how to resolve the errors
b. How to troubleshoot common System problems
c. How to perform ASR-specific system maintenance functions
d. A listing of all logs and how to interpret them
e. Key System capacity management considerations
f. Key security management functionality
g. Documented process for creating, changing, or deleting user Property Assessment System
accounts
h. Documented process for managing user roles & privileges
i. Contact information for receiving support
j. Where to find disaster recovery and business continuity information related to the System
k. A listing of interfaces and how to troubleshoot communications problems
l. System flow diagrams, data flow diagrams, system interface diagrams, and workflow
diagrams

[Link] Deliverable 21 - Deployment Plans

The Proposer shall provide a detailed Deployment Plan that documents all the activities (Proposer, ASR,
and any identified supporting contractors) that need to be accomplished to successfully migrate the new
Property Assessment System release from a pre-Production environment to the Production environment.
The Plan shall provide a detailed schedule of activities with key “go-no go” decision points identified
throughout the deployment process (including any data conversion steps necessary for go-live). In addition,
the plan shall detail a back-out and recovery process to be triggered in the event the release to production
fails.
[Link].1 Deployment Bill of Materials (for each implementation Phase)

In preparation for System deployment, the Proposer shall ensure that the system can be assembled and
installed in the proposed environment. For proposed “Hosted” and “SaaS solutions, not all of the
below items may be relevant—in that situation, the Proposer shall deliver products and services
as contracted and agreed with ASR. The specific items that the Proposer shall deliver will be
documented in a Deployment Bill of Materials. The Bill of Materials shall contain all the information
required to assemble the system and supporting infrastructure in order to place the new System into
production. The Proposer shall include the following components in the Deployment Bill of Material (for
each phased release if applicable, or for the entire System when fully completed):
1. A list of all components comprising the System
2. A list of all executables necessary to make the System operational
3. All technical documentation including specifications, installation guides, systems administration
manuals, and test plans
4. Level 1 and Level 2 help desk scripts (or any variation of scripts as agreed upon with ASR in the
final contract)
5. Site-specific installation procedures (On-premise only)

RFP# ASR2017-01 Attachment B – Detailed Statement of Work

Property Assessment Solution Page 33 of 38
 6. Standard and customizable features including a 'how to customize' guide
7. A list of all COTS software required by the System to make it operational including database
engines, operating systems (and associated releases or service packs), compilers, configuration
management software, editors, testing software and integration engines (as applicable, depending
on the proposed solution delivery model)
8. A detailed list of all hardware requirements including a hardware configuration layout. (On-premise
only)
9. A list of support functionality required to make the System operational including LAN/WAN
connectivity, Internet/Intranet connectivity
[Link].2 Deployment Plan

The Proposer shall incorporate the above bill of materials as part of a detailed Deployment Plan that
documents all the activities to be performed by the various Project participants (e.g. Proposer, ASR,
and/or any identified third parties) to successfully migrate the new System to ASR’s production
environment.
The Proposer shall provide a Deployment Plan to include the elements described above and the
following components:
1. The specific time frame and activities associated with the full functionality roll-out of each
functionality grouping, any other proposed Property Assessment System phases, and the overall
complete roll-out of all functionality into the production environment
2. All critical resources (Proposer, ASR, and/or any identified third parties) have been identified and
are available to support deployment activities
3. Key resources needed to support critical or new technologies have been identified. A developed,
documented and accepted Communication Plan and command structure that define the decision
process and any “go / no go” decision events
4. Communications have been developed, documented, and provided to stakeholders informing them
of the deployment process and status
5. Contingency plans are in place to deal with System Deployment issues that may arise
6. A detailed back-out and recovery Process has been documented that will be triggered if the release
to production fails. The back-out and recovery process shall ensure that the old System is
maintained and restored if necessary and all data remains available to ASR users with no impact
to their job function or activities
[Link].3 System Deployment

The Proposer shall deploy the Property Assessment System in accordance with the Deployment Plan
deliverable. The Proposer shall track and monitor progress towards the Deployment Plan deliverable and
identify, escalate, and resolve issues and risks in accordance with the Project Management Plan.
[Link].4 Production Support

The Proposer shall provide software support following the deployment of functionality in any/all proposed
phases, including providing ASR with a Production Support staffing plan. The staffing plan shall include
the proposed organizational structure, roles and responsibilities and estimated level of effort for the
Proposer and ASR to support the deployed software.
If ASR requests support through established processes and channels (e.g., help desk referral, Property
Assessment System Administrator request, etc.), the Proposer shall provide support services that include
the following:
1. Property Assessment System Software troubleshooting

RFP# ASR2017-01 Attachment B – Detailed Statement of Work

Property Assessment Solution Page 34 of 38
 2. Managing service tickets (entering, updating status, coordinating testing or fixes with ASR Project
team members, etc.)
3. Recommendations and advise on any administration tasks required by the proposed Property
Assessment System software
4. Performance tuning
5. Recommendations for the design and development of minor system enhancements (e.g., custom
alerts, reports, etc.)
[Link].4.1 Production Support Plan Help Desk Levels
The Production Support Plan shall include the scope of production support services documented in the
Property Assessment System Technical Requirements (Template D - Requirements Response Matrices),
agreed upon with ASR, and documented in the contract. Production support may include any, all, or any
combination of Help Desk support levels, including:
1. Level 1 – This is the initial support level responsible for basic customer issues. The goal of Level
1 support is to gather the customer’s information and to determine the customer’s issue by
analyzing the symptoms and figuring out the underlying problem. Level 1 will typically handle
straightforward and simple problems while using a knowledge management tool. The goal for
Level 1 is to generally handle 80% of the user problems before finding it necessary to escalate
the issue to a higher level

2. Level 2 – This is a more in-depth technical support level than Level 1, and the staff are more
experienced and knowledgeable with the use of the system. Support is often provided for bug
fixes, custom reports, etc., which require configuration and/or technical expertise. If new
problems are encountered and resolved that have not previously been documented in a
knowledge management tool, Level 2 support resources are often responsible to develop and
post instructions in the knowledge management tool

3. Level 3 – This level represents an escalation to Proposer personnel responsible for the support
of the software (or hardware, if applicable). Level 3 support resolves complex issues related to
configuration and/or technical issues with the software. As is the case with Level 2 support, new
problems that are encountered/resolved and have not previously been documented in a
knowledge management tool are the responsibility of Level 3 support resources to develop and
post instructions in the knowledge management tool

The Proposer will use a help desk issue management software suite to collect and track all issues
submitted to the Proposer for production support. The Proposer will additionally provide ASR with an
export (in excel or other format specified) of the contents of the help desk issue management software
suite used by the Proposer’s Production Support staff to import into ASR’s Help Desk software tool.

[Link].5 System Incident and Corrective Action Reports

The Proposer shall document all incidents and defects that occur during System Deployment that are part
of the defined system scope and communicate with ASR within a reasonable, agreed upon time frame.
The System Incident Report must contain the priority of the incident as identified in the final contract’s
Service Level Requirements, a description of the incident, incident resolution status, and the proposed
course of action for remedying all open incidents.

[Link] Deliverable 22 - System Defect Resolution Reports

All within scope defect resolution requests that occur during the sign off period must be documented and
communicated with ASR within a reasonable, agreed upon time frame. The Defect Resolution Report

RFP# ASR2017-01 Attachment B – Detailed Statement of Work

Property Assessment Solution Page 35 of 38
must contain the description of the maintenance request, resolution status, and the proposed course of
action for remedying all open defect resolution requests.
All changes and fixes will be implemented based on a mutually agreed upon schedule. Changes will go
through all phases of testing by the Proposer and ASR. The Proposer shall document the test results and
provide them to ASR for approval before a decision is made to put a new release into production. At the
conclusion of any Property Assessment System changes, the Proposer shall update all required system
documentation as appropriate and provide it to ASR.
The Proposer shall provide System Incident and Defect Resolution Reports to ASR that include the
elements described above.

[Link] Deliverable 23 - Complete Detailed Requirements, Design & Specifications

After each completed implementation of a functionality set, and upon final Property Assessment System
delivery, the Proposer shall assemble, update, and provide an updated Complete System Design,
Requirements, and Specifications document to ASR. The document components shall include at a
minimum:
1. Updated Functional Requirement in the Functional Design Document (see Deliverable 9)
2. Updated Technical Specification in the Technical Design Document (see Deliverable 12)

[Link] Deliverable 24 - System Source Code and Documentation

[Link].1 System Source Code Escrow Information

Prior to delivery of the complete system to ASR (as specified in any final contract with the Proposer), the
Proposer shall place all Property Assessment System source in a “single beneficiary” escrow account.
The Proposer shall provide ASR with complete written documentation on the escrow account, including:
1. Account history report, reflecting the specific code version in escrow
2. Audit rights and procedures
3. Release conditions
4. Release process
5. Software installation instructions
6. Use rights for Released materials
Further details regarding ASR’s escrow expectations are included in the terms and conditions (Attachment
I - Professional Services Sample Template (Form P-600))

[Link].2 System Documentation

At the completion of the Project, the Proposer shall conduct a review with ASR and identify any
documentation that must be updated as a result of changes during the 90 day Sign Off period. The sign
off period shall start after ASR’s final acceptance of the proposed Implementation activities. The Proposer
shall update the documentation and provide it to ASR for review and Final Acceptance.
The following documents shall be updated and provided to ASR at the completion of the Project:
1. Functional Specifications and Design Documentation
2. System Architecture

RFP# ASR2017-01 Attachment B – Detailed Statement of Work

Property Assessment Solution Page 36 of 38
 3. Technical Design Documentation
4. System Interfaces Documentation (Integration with other systems)
5. Data Architecture and Data Dictionary
6. System Configuration Documentation
7. System Operations Documentation
8. Data Management and Synchronization Plan
9. Test Cases and Test Scripts
10. Any and all Help Desk scripts developed for Production support
11. Training Manuals, End-User Guides, and Materials
12. System Administration Documentation
13. System Maintenance Documentation
14. Entity Relationship Diagram
The Proposer shall also transfer all finalized required documentation to ASR. The format and transfer
medium will be at the discretion of ASR. The Proposer shall provide the following documentation to ASR:
1. Declaration of Original Work (DOW): Written declaration stating that Proposer has delivered a
satisfactory license to all software in the System, including COTS Software as required by the
contract, signed by an appropriate legal representative of Proposer
2. Statement of known System limitations, defects, issues that could impact operations, and/or
existing System workarounds
[Link].3 Final Acceptance

The Proposer shall provide production support for 90 days (or the time period agreed upon in the Service
Level Requirements in the final contract) before Final Acceptance. The period after full deployment and
prior to Final Acceptance is intended to stabilize the System and minimize the impact of any early System
issues. The Proposer’s Project Team shall:
1. Closely monitor the newly deployed System and user activity
2. Assign appropriate resources to resolve issues
3. Rapidly detect and escalate issues as required and quickly resolve and communicate resolution
4. Provide onsite support during the first roll close
Prior to Final Acceptance the Proposer and ASR will jointly assess the status of the implementation and
review the status of outstanding issues and adherence to SLRs. The purpose of the assessment will be to
provide written verification in the Documented Implementation Closeout and Final Acceptance that the
Property Assessment System operates as expected.

1.3.7 Task 7 –Implementation Closeout

The purpose of Implementation Closeout activities is to identify the conclusion of the Implementation
Project and gather the required approver signatures. This document will signify that all required
deliverables for the Implementation Project have been completed and approved with the date of approval
for each deliverable indicated. The document shall also list the status of each of the Exit Criteria.

[Link] Deliverable 25 – Documented Implementation Project Closeout

RFP# ASR2017-01 Attachment B – Detailed Statement of Work

Property Assessment Solution Page 37 of 38
The Proposer shall provide Documented Implementation Project Closeout to include, at a minimum,
the elements described above and the following components:
1. ASR validation that all exit criteria have been met for the Implementation Project, inclusive of any/all
proposed phases of delivered functionality
2. ASR validation that all deliverables for contracted requirements, functionality, and system
capabilities have been provided, accepted, and placed in the Project Artifact repository
3. ASR validation of the Requirements Traceability Matrix
4. ASR validation of the complete and accurate Configuration Management
5. ASR validation of the complete and accurate management of defect and issue tracking

RFP# ASR2017-01 Attachment B – Detailed Statement of Work

Property Assessment Solution Page 38 of 38