Statement of Work (SOW)

1.000 Project Identification

1.001 PROJECT REQUESTThe purpose of this project is to implement new COTS technology to upgrade the Michigan Geographic Framework (MGF) enterprise Geographic Information System (GIS) data model and system design including data validation and workflow management processes. The project will include a review of business requirements, a system design, data model, software and system implementation, training, maintenance and support. The MGF vision is a central repository following a federated approach to data management that uses a distributed architecture. MGF will include a business layer that partners can send changes of geometries and attributes to and validate against agreed upon business rules. The MGF would coalesce data stewarded from various departmental and external partner data sources following the principles of the State of Michigan Enterprise Information Management (EIM) initiative. The business layer will evaluate/validate the changes and process them accordingly including implementing or triggering workflow if approvals/changes are needed.

Objective 1 – Design and implement the new MGF system architecture and data model including COTS software for data integration, validation and management. The system design will include a business rule engine that manages data validation, including topology, within and across data layers. The Business Rule Engine (BRE) is a software system that executes pre-designed and configured data validation rules to manage data integrity and quality control. This objective includes developing a data model that enables the needed MGF deliverables for external business systems today and into the future.

Objective 2 – Implement workflow management and status tracking by designing and configuring workflow for quality control and approval processing for data coming into the MGF.

Objective 3 – Establish services (Representational State Transfer (REST)/ Simple Object Access Protocol (SOAP)) for business systems to transactional call MGF for data as well as developing ETL processing capabilities that can publish all or some of the MGF data to an external repository for public consumption/redistribution.

Objective 4 – Establish import capabilities to bulk load external data from MGF business partners. This process must be capable of distinguishing between what is new or changed data versus what currently exists and only loading the new or changed information while passing that data through validation and standardization.

Please see Appendix A for more details on the conceptual design and flows for the envisioned system.

1.002 BACKGROUND

The Center for Shared Solutions (CSS) provides an enterprise environment for GIS for State agencies to leverage for their day to day business. This environment includes server-based GIS installations and the management of the MGF which is enterprise-based geospatial datasets that include jurisdictional boundaries, roads, railroads and hydrology as well as many dozens of attributes on those features being maintained.

The Center's mission is to enable State government to more effectively and efficiently serve the citizens, businesses and other governments of the state in the following key areas: Public Safety & Protection, Homeland Security, Economic Development, Environmental Protection, Transportation, Voter Registration & Management, Public Education, Natural Resources Conservation Management, Management & Protection of State Agriculture, Community Health Protection & Management, and Preservation and Promotion of Michigan’s historic heritage.

CSS provides leadership, technical expertise and policy for the acquisition, development, use, dissemination, promotion and sharing of geographic information in the State of Michigan. CSS, through partnerships and collaboration among Federal, State, Regional, Local governments, Non-Profit Organizations, Utilities Companies, Universities and Community Colleges in the acquisition, development, use, and maintenance of geographical information, aims to promote the development, maintenance, management, and wise use of

1

geographically referenced data. CSS additionally promotes the use and development of geospatial data within web and mobile technologies. Lastly, CSS provides GIS Leadership in the State, and supports the Michigan Governor’s Office, Legislature and State agencies' GIS initiatives.

Numerous organizations spend a lot of money and resources using geographic data each year. Yet, they often still do not have the information they need to solve critical problems due to lack of consistent data standards, funds, or jurisdictional control. Often the same information is mapped again and again because little or no coordination exists between organizations. At the State of Michigan, the MGF program is designed to solve this data and communication problem by creating and maintaining a single “official” State base map and master GIS data repository for State business needs. CSS works in partnership with State agencies to manage the MGF environment and provides tools for data stewardship including business rules to maintain data integrity across all of the statewide datasets that encompass the MGF.

The MGF is both a product and a program. As a product, the MGF serves as the digital base map for State government, it aims to provide enough basic reference information that users can associate and locate attribute data for purposes of comparison or geographical correlation. The MGF is designed to contain only those features most agencies need to do their business. As a program, the framework serves as the mechanism for maintaining a statewide base map that is both current and relevant for supporting Michigan’s business applications. The program is designed to keep the base map for Michigan current, both directly and indirectly. Directly, partners provide map and attribute information periodically via their business systems by sending changes that need to be made to the map. Indirectly, the Center for Shared Solutions continues to integrate other more current and accurate GIS work from state and local agencies. The program is also designed to keep the user community always in sync with the current version of the products through the dissemination of change files, metadata, documentation, training, and support. The current agencies directly involved with the MGF data stewardship include DTMB CSS, the Michigan Department of Transportation (MDOT) which currently manages the State trunkline highway (State owned), and Michigan Department of State (MDOS) which manages election geography. Many other agencies such as Michigan Department of Natural Resources (MDNR), Michigan State Police (MSP) (crash location and 911 dispatch), Michigan Tech University (MTU) (for use in RoadSoft, an asset management system), US Census Bureau and Michigan Department of Environmental Quality (MDEQ) leverage the data for their systems. Other participants of the program include local agencies such as county and city governments, and Road Commissions which maintain their own GIS data but often use the framework as a base map. Local agencies also provide feedback for improvement of the data. The data is also published to the public via the State of Michigan GIS Open Data Portal.

CSS has the responsibility for managing the MGF. CSS currently maintains the geospatial data in Oracle Spatial. To maintain the data, CSS and agency partners use a customized Java-based toolset called the MGF Editing Environment (MGFEE). MGFEE was developed as customized tools that integrate with Hexagon’s Aquis Data Editor, which is no longer being upgraded with new software releases. Agency requirements for integrating data with MGF and the vision for expanding data stewardship to authoritative data stewards have led to the need to upgrade the existing MGF data model and technology to manage data validation, topology and workflows for data being integrated into MGF from various systems. The new system will need to be built on a relational database platform but it does not require the use of Oracle Spatial or Oracle SDO topology. CSS is open to any relational database that is supported by the State of Michigan (as outlined in the Environment section) which provides the best and most cost-effective solution for this project.

This RFP is seeking a vendor that can provide COTS software to continue the data management of the MGF but with greater flexibility to integrate source data from authoritative data stewards. The desired solution will enforce business rules designed to ensure data integrity including attribution and spatial topology while at the same time supporting a federated approach to data management where disconnected GIS systems can use technologies like web services to push changes into the MGF on demand as well as request updates. All of this capability is expected to be encapsulated with workflow management to track these changes and allow for an approval process by authorized data stewards. The solution will include workflow management tools to allow the Center for Shared Solutions to administer and manage data integration, review processes, and send notifications across the GIS enterprise. The solution would allow for data management and data validation across multiple business datasets supporting the master enterprise GIS repository.

As stated the solution must support business rules and topology that are integral to the MGF as well as provide CSS the ability to add, edit or delete business rules in the future. MGF currently has business rules in place that will need to be supported by the new system. A few examples of the business rules are listed in Appendix B. More information on the existing MGF, data concepts, and deliverables can be found at the following links:

2

https://www.michigan.gov/cgi/0,4548,7-158-52927_53037_12759_14194---,00.html

The current MGF manages and stores Linear Reference System data. The Michigan Department of Transportation is in the process of implementing ESRI’s Roads and Highways to manage their road network with LRS and their event data. Moving forward, the LRS will be managed using ESRI Roads and Highways. Edits from this environment need to be supported by the business layer including but not limited to changes in the LRS as well as the potential for specific event data to update/change such as route designation (I-94, US-12, M-100 etc.). Changes to MDOT’s authoritative data will be synchronized back to the MGF repository via business rules established through the system implemented from this RFP project.

The Department of Natural Resources is planning to incorporate the State forest roads and trails that they manage into the MGF repository and are evaluating ESRI Roads and Highways for managing a LRS on those centerlines geometries.

CSS currently manages road names and address ranges on the MGF road centerlines. The master MGF repository data model and workflows will need to consider the management of attributes and centerline geometry segmentation for 9-1-1 addressing that need to adhere to National Emergency Number Association (NENA) standards.

The current data layers that make up the MGF can be found on the State of Michigan GIS Open Data Portal at the following link:

http://gis.michigan.opendata.arcgis.com/datasets?q=MGF&sort_by=relevance

Currently all of these GIS data layers are integrated through topology rules in the MGFEE system where coincident geometry between boundary polygon edges and lines maintain their topological relationships throughout the editing processes. These GIS data sets from the Open Data Portal will provide respondents with background on the file formats, attributes and file sizes of data within the current Michigan Geographic Framework.

Today there are, on average, 15,000 transactional edits per year to maintain the statewide road centerlines, LRS and associated boundary edits. This includes edits for approximately 30 to 40 annexations per year. Today there are eight editors maintaining data at various frequencies during the year within the MGFEE system. With the new federated model with distributed editing environment, it is anticipated that there will be more editors from more agencies using their existing data editing tools to maintain data and provide geometry and attribute edits through the proposed new system.

For system scalability estimates, there will be an increase in the number of editors as more state departments provide edits into the system as data stewardship is managed through the authoritative sources within the departments. It is anticipated that over the first three years we could increase to 30 editors and then 50 editors over five years across state departments. However, not all editors would be pushing edits concurrently through the business rules engine. The first phase of this project, during the first year, will be to integrate the existing MGF data with existing data stewards (CSS, MDOT, DNR) and establish business rules and the associated workflows. The first year will also include a pilot to integrate changes from a local jurisdiction via the proposed solution. This first year phase will also include the training for CSS to add future GIS datasets from state departments and configure business rules and workflows.

In a future phase of this project, once the pilot for local data integration has been completed in phase one, the system would provide local jurisdictions, as the authoritative source for specific data features stored in the MGF, with the capabilities to integrate their edits via the solution. The volume of edits would depend on the local jurisdictions that partner with the State to integrate their edits and which data sets and how many features being edited on a daily or weekly basis.

It is the vision for the MGF to be the State geospatial repository for master common data themes following the model of the National Spatial Data Infrastructure (NSDI). Data stewards would provide geometry and attribute edits from their authoritative data to the MGF through workflows and validations using the business rules engine. A data steward would also receive geometry and attribute data from the MGF that is managed by other data stewards, as needed for their workflows and processes.

External systems currently rely upon some existing data model fields that will need to be maintained during a transitional period and need to be considered as part of the initial data model design. A listing of the existing

3

data dictionary for the current MGF annual deliverable can be found in Appendix C. Although the current MGF data is managed in Oracle Spatial, the annual deliverables are still exported into an ArcInfo coverage format based on legacy processes that will be upgraded through the new data model and system design of this project. A number of transportation fields associated with the road centerlines in Appendix A will become events that are managed in Roads and Highways.

1.100 Scope of Work and Deliverables

1.101 IN SCOPEThis project consists of the following scope:

Project Initiation and Management Project Kick-off Meetings Implementation Plan development Software requirements validation and solution configuration specifications

Business Requirements Business Requirements Validation and Software Configuration Specifications System Design GIS Data Model

Software Installation and Configuration Services Implementation

Data Conversion/Migration Interfaces/Integration Testing Production Go-live Performance Warranty Period

Training Documentation Maintenance and Support Knowledge Transfer/Transition Other

Contingency Services – to address scope changes (see details below in Section 1.104, I – J)

A more detailed description of the software, services (work) and deliverables sought for this project is provided in Schedule A, Section 1.104, Work and Deliverables.

1.102 OUT OF SCOPEThe following products / services are out of scope for this RFP:

Hosting Hardware – Any required hardware will be provided by the State of Michigan. Relational Database Software Acquisition – Any required database licensing for the project will be

provided by the State of Michigan

1.103 ENVIRONMENTThe links below provide information on the State’s Enterprise information technology (IT) policies, standards and procedures which includes security policy and procedures, eMichigan web development, and the State Unified Information Technology Environment (SUITE).

4

Contractors are advised that the State has methods, policies, standards and procedures that have been developed over the years. Contractors are expected to provide proposals that conform to State IT policies and standards. All services and products provided as a result of this RFP must comply with all applicable State IT policies and standards. Contractor is required to review all applicable links provided below and state compliance in their response.

Enterprise IT Policies, Standards and Procedures:http://michigan.gov/dtmb/0,4568,7-150-56355_56579_56755---,00.html

State Standard Products and Toolshttp://www.michigan.gov/documents/dit/Data_Technologies_385788_7.pdf

All software and hardware items provided by the Contractor must run on and be compatible with the MDTMB Standard Information Technology Environment. Additionally, the State must be able to maintain software and other items produced as the result of the Contract. Therefore, non-standard development tools may not be used unless approved by MDTMB. The Contractor must request, in writing, approval to use non-standard software development tools, providing justification for the requested change and all costs associated with any change. The MDTMB Project Manager must approve any tools, in writing, before use on any information technology project.

It is recognized that technology changes rapidly. The Contractor may request, in writing, a change in the standard environment, providing justification for the requested change and all costs associated with any change. The State’s Project Manager must approve any changes, in writing, and MDTMB, before work may proceed based on the changed environment. Enterprise IT Security Policy and Procedures:http://www.michigan.gov/documents/dmb/1210.32.pdfhttp://www.michigan.gov/documents/dmb/1325_193160_7.pdfhttp://www.michigan.gov/documents/dmb/1335_193161_7.pdfhttp://www.michigan.gov/documents/dmb/1340_193162_7.pdf

The State’s security environment includes: MDTMB Single Login. MDTMB provided SQL security database. Secured Socket Layers. Internal Network Active Directory SecureID (State Security Standard for external network access and high risk Web systems)

ADA Compliance

The State is required to comply with the Americans with Disabilities Act of 1990 (ADA), and has adopted a formal policy regarding accessibility requirements for websites and software applications.  The State is requiring that Contractor’s solution conform, where relevant, to level AA of the World Wide Web Consortium (W3C) Web Content Accessibility Guidelines (WCAG) 2.0.  Contractor may provide a description of conformance with the above mentioned specifications by means of a completed Voluntary Product Accessibility Template for WCAG 2.0 (WCAG 2.0 VPAT) or other comparable document.  Contractor may consider, where relevant, the W3C’s Guidance on Applying WCAG 2.0 to Non-Web Information and Communications Technologies (WCAG2ICT) for non-web software and content.  Any additional compliance requirements shall be specified in the Statement of Work.

Look and Feel Standard

All software items provided by the Contractor must adhere to the Look and Feel Standards www.michigan.gov/somlookandfeelstandards. 

The State Unified Information Technology Environment (SUITE):Includes standards for project management, systems engineering, and associated forms and templates – must be followed: http://www.michigan.gov/suite

Agency Specific Technical Environment

5

Below is a listing of the current technologies being utilized by CSS to manage the enterprise geospatial environment. These technologies can be leveraged by respondents to provide the best solution at the best value for the State. It is anticipated that ArcGIS version 10.4 or 10.4.1 will be implemented by the time this project is initiated.

Oracle Spatial Database 11CSS currently houses MGF in an Oracle spatial database using the Oracle Topology Model. Oracle SDO Topology is implemented to manage coincidence within the road network and between civil boundaries and water features.

Oracle Map ServerMap Server is used to render the MGF spatial data.

Oracle Workspace ManagerMGF editing uses workspace manager to implement versioned edits by work request via the MGFEE.

Microsoft SQL Server 2014 (Spatial)CSS manages multiple instances of SQL server with ArcGIS SDE enabled. This technology is implemented in support of web application development and desktop GIS users.

ArcGIS Server Standard 10.3 (or latest version)ArcGIS Server is used to provide mapping and editing capability of GIS data in support of web applications. In addition the State also has these Server Extensions

Workflow Manager Data Reviewer Roads and Highways

ArcGIS Desktop 10.3 (or latest version)CSS uses ArcGIS Standard and Advanced Desktop licensing to manage spatial data that is not part of the MGF as well as transform and display MGF data for various GIS business needs. Most State agencies using ArcGIS Desktop to manage their GIS business data. CSS and MDOT also have the Roads and Highways desktop extension.

1.104 WORK AND DELIVERABLES

I. Services and Deliverables To Be Provided

The State seeks to implement an enterprise-based COTS solution to manage data validation, business rules, topology and workflows across a federated GIS framework that will integrate data from State agencies and other public and private partners. This project includes the implementation of a COTS solution, GIS data conversion and migration, training, maintenance and support. For the purpose of preparing proposals, Vendors should contemplate that the system will be installed and in operation by January 31, 2018. These deliverables are not all inclusive. Contractors may propose other deliverables.

The MGF is the State of Michigan’s master dataset for location. To facilitate its growth and maintenance we need an environment where spatial data can be stored and managed under these guiding philosophies:

DTMB houses the MGF environment and facilitates data stewardship Data stewards manage/edit only the spatial assets that are their responsibility Stewards perform data editing within their own GIS systems and promote those edits to MGF Stewards collaborate with DTMB to enhance the environment to support their business needs DTMB acts as the Steward of last resort when needed/required Road segments have linear referencing Hydrography should be modeled after the National Hydrology Dataset (NHD) LRS changes are identifiable and can be shared with all stakeholders of the LRS to update their event

tables. These stakeholders can be both internal and external to the State. Today there are approximately twenty internal systems across state departments that consume LRS changes and no

6

more than five external stakeholders that consume LRS changes. Moving forward, the LRS changes will be identified through the new ESRI Roads and Highways implementation and systems will have options to leverage that technology for updating event tables.

All geometry types can be present within the MGF All geometries support elevation or “z” values Topology needs to be applied to the MGF to ensure data integrity. Rules include, but are not limited to:

o Segments are connected (dangles are identified)o Intersections of features create nodes/pointso Boundaries do not overlap (Parcels cannot share the same area)o Polygon boundaries share edges with other features like roads requiring the need for

maintaining coincidence between different geometries Workflow is utilized for quality control and to track changes Edits implement change date and history tracking allowing for the potential to see the state of the MGF

at any previous point in time beyond the system implementation date.

A. Project Initiation and Management ServicesContractor is responsible for working with the State to initiate and provide planning resources and services to ensure the Solution is ready for go-live production by the target date listed above. This includes all the services detailed in 1.300 Project Plan and 1.400 Project Management in addition to the activities specified below.

Project Kick-off Meetings

Contractor will work with the Client to arrange official project kick-off meetings as follows:

Orientation Meeting – as further defined within Section 1.301; Project Initiation Meeting – a joint presentation by the Contractor to the State Project Team and

stakeholders outlining the proposed approach to the implementation, including but not limited to the following: an overview of the proposed COTS software, project plan, Contractor resources, costs, assumptions, Critical Success Factors (“CSFs”) and risk mitigation plan.

Deliverable(s) Project Kick-off Meetings and Presentations Project Plan as per Section 1.300 Report Templates as per Section 1.302 Project Management as per Section 1.400 Any other deliverable the Contractor deems appropriate

Acceptance CriteriaHigh-level acceptance criteria for Document Deliverables and Software Deliverables are listed in Section 1.501. Any additional or more specific criteria should be identified here.

Bidder: Describe your proposed solution to meet this service, including State roles and Contractor roles

The Bidder must provide a detailed description of how they approach project management and how they will meet the requirements addressed in this section. Bidder must provide details of how they manage their implementation and how they manage transitions from an existing system to their solution.

Although this project does not require the Contractor to be on-site for all work tasks, the Bidder should describe during which tasks they plan to conduct on-site meetings with State staff to ensure a successful implementation.

7

B. Business Requirements The contractor will be responsible for reviewing and validating the business requirements as outlined below with the State as the initial phase of the project. The contractor will be responsible for meeting with the project stakeholders from the State to review and understand the business requirements and objectives of the project as it applies to the long-term goals for the MGF. It is expected that the contractor will then be able to propose the system configuration and data model required to meet the business requirements and provide recommendations based on experience from other projects of this nature.

The primary stakeholder group from the State will include up to four representatives from the management and technical team from the Center for Shared Solutions, up to four representatives from state departments, and a local representative during the pilot for local data integration.

GIS Data Design

The data design component of the Solution will provide the following high level functionality:

Store and manage the official State of Michigan GIS data layers within a federated model; Integrate LRS networks from ESRI Roads and Highways or other LRS systems into the MGF

repository; Integrate National Emergency Number Association (NENA) geometry and attribute standards into the

MGF repository data model; Establish a design to provide role based permissions at geometry and attribute level; Establish a design that include temporality to be able to view, extract, report, etc. by certain dates or

date ranges; Accommodate elevation or “z” values within all capable geometry types; Support MGF standards for location metadata fields; and Track changes and record edit history by users and time stamp.

Bidder:

Respond to each component, identifying whether or not the solution proposed meets the requirement and detailing how this is accomplished.

Business Rules Layer

The Business Rule Layer component of the Solution will provide the following high level functionality:

Allow DTMB CSS staff to add, delete or edit business rules through a COTS solution interface Business rules need to support both permissions, data, and geometry validation (valid shape, known

coordinate system and re-projection, snapping and edge matching etc.) Rules need to support being called from a variety of methods/sources such as web services,

databases, applications, ETL Business rules should be managed in a central repository that allow all MGF subsystems to execute It is preferred that the solution should be able to link individual business rules into a larger business rule It is preferred that the capability exists to create/trigger workflows along with the capability to

disable/enable that functionality through configuration It is preferred that the solution have the capability for an administrator to monitor Rules and review

especially those with exceptions and where possible resolve the issue and continue the process Rules should be accessible through service calls or have an interface/plugin for ArcGIS or web browser

Bidder:

8

Respond to each component, identifying whether or not the solution proposed meets the requirement and detailing how this is accomplished.

Workflow Management

The Workflow Management component of the Solution will provide the following high level functionality:

Capability to configure tasks into a step by step processes for editing, validating and approving of data based on feature type or feature edit type

Send email notifications to users that notify them of a task completed or a task to do Configure to send reminder notifications of tasks due or past due It is preferred that the solution be configurable to send notifications to supervisor of tasks that are past

due by staff Audit ability to see who has processed workflow and how long the process has taken It is preferred that the solution have a workflow dashboard to see status of workflows based on

workflow type and duration with the ability to drill down into the individual workflow and user It is preferred that the solution have the ability to identify why a workflow is failing and if possible

resolve the issue and start the workflow back up It is preferred that the solution have a dashboard allows individual users to see their tasks and

managers can see all tasks based upon system roles If a dashboard is available, it can generate reports in .pdf or Excel format It is preferred that subsystems should be able to create workflow via an API or service call It is preferred that the solution provide the ability to categorize workflow by type of change and priority

and then view in dashboard

The Contractor can propose their own COTS solution for workflow management or implement and configure a workflow management software that is already available at the State of Michigan (ESRI Workflow Manager) and that performs the requirements outlined in Schedule A – Attachment 1.

Bidder:

Respond to each component, identifying whether or not the solution proposed meets the requirement and detailing how this is accomplished.

Below is an estimated project timeline. The Contractor will propose their task timeline based on the work deliverables outlined in this statement of work.

Timeline TasksFebruary 2016 Kick-off Meeting, Project Plan, data gatheringMarch 2016- April 2017 Develop of data model, system design, review and

approvalMay 2017- July 2017 Implementation of COTS solution, data migration,

development of business rules, workflows, initial scenario testing

October 2017 – November 2017 Training and Testing of COTS SolutionDecember 2017 – January 2018 Go-live, Documentation and Knowledge Transfer,

produce MGF version deliverablesYears Two – Five Maintenance and Contingency ServicesOption Years Six-Ten Maintenance and Contingency Services

9

Business Requirements Validation and Solution Configuration Specifications

Based on initial meetings with the project stakeholders to review the business requirements and overall goals of implementing a federated system model for the MGF, the Contractor will be responsible for providing a Requirements Specification Document to ensure that all parties are in agreement with the project requirements prior to the initiation of data model designs, system design and implementation of the solution.

The Contractor is also responsible to meet with State staff during the initial project meetings to review the specified environment requirements (see Section 1.103 above and Attachment A) to ensure that the Solution can be implemented successfully within the State IT environment. Contractor will identify any functional or technical issues that need to be addressed for successful implementation and propose resolutions to be undertaken as part of both the initial software installation and Section E - Implementation Services. As a result, in the Requirements Specification Document the Contractor will outline any necessary configuration details about how the Solution will be set up to provide the State’s requested functionality.

Final System Design

Through input obtained from initial project meetings, data gathering activities, review of solution requirements and overall objectives; the Contractor will develop a System Design Document for the overall solution. Current system data layers, data dictionaries and conceptual MGF Federated Model document can be found in the appendices of this RFP. The system design will include details about the following:

A pictorial representation of the system architecture which includes servers required, databases, software installations.

A description of the software(s) to be included in the design to meet the solution requirements, including which type of relational database, which workflow management software, business rule engine software, and any other proposed software.

A description and diagram of workflows that show the data flow from multiple business systems into the MGF and how MGF provides data back to business systems. The description should include how the business rule layer is initiated to perform validations and how error tracking will be handled for each data source that is integrating to MGF.

A description that outlines the topology rules that will be implemented within the business rule layer A description of the system design considerations to address the solution requirements as outlined in

this RFP

The system design and data model must be developed in a manner that will allow the State to continue to expand the MGF with additional data sets and configure the COTS solution accordingly to implement the business rules, workflows and overall data management needs for new data that is integrated into MGF.

Create Data Model

The Contractor will develop a new data model for MGF. During the initial data gathering meetings with State staff, the Contractor will review data requirements and functionality that will need to be considered when developing the MGF data design. The Contractor will gather information about the current data model, requirements for maintaining existing attributes for dependent systems, requirements for new data, processes and workflows, requirements for business rules, and requirements for the integration of multiple source datasets into MGF.

As part of the data model and system design, the contractor will work with the State to determine the best coordinate system and projection for the system. Considerations will need to be made for:

accuracy and precision needed for the data, performance of data being used in applications and geoprocessing, presentation compatibility with systems such as ArcGIS Online, Google and Bing spatial analysis and needs for various measurement capabilities

The Contractor will provide the State of Michigan with a draft system design and data model. State of Michigan staff will review the draft over a two week period and then the Contractor will facilitate a conference call to

10

discuss feedback from the State of Michigan. The Contractor will then make any agreed upon changes to the data model and provide a final version within 5 business days.

Deliverable(s) Requirements Specification Document Final System Design Document Data Model Design Document Documented Workflow Diagram Other deliverables as proposed by the Contractor

Acceptance Criteria High-level acceptance criteria for Document Deliverables and Software Deliverables are listed in Section 1.501. Any additional or more specific criteria should be identified here.

Bidders: Describe your proposed solution to meet this service, including State roles and Contractor roles

The Bidder must provide a detailed written description of how their proposal meets the business requirements outlined in this section

The Bidder must describe in detail their approach to meeting with the State to review business and solution requirements and gather information from the Project team to validate and finalize all requirements for the project.

The Bidder must describe their approach to data modeling and system design to achieve the desired functionality and that these are vetted with the State’s Project Team.

The Bidder must describe their approach to design system workflows to integrate data from multiple authoritative data sources into the MGF. The description will include how the solution manages workflows and sends notifications as outlined in the workflow management business requirements in this section.

The Bidder must describe how their BRE/tools performs validation checks to meet the requirements outlined in the Business Rule Layer of this section.

The Bidder must describe how their solution manages topological relationships between features that are being integrated with the MGF. It is expected that the business rule layer will be able to perform topology validations on features across multiple geodatabases.

The Bidder must describe the anticipated project timeline to complete the work deliverables outlined in this statement of work. The Bidder must describe if they can complete all tasks by January 31, 2018, and if the timeline will be longer, provide the basis for an alternative timeline. A proposed timeline for this project is found in this Business Requirements section. Please provide a Gantt Chart outlining the project timeline.

Bidder must complete Schedule A, Attachment 1 for response to detailed requirements.

C. SoftwareContractor is responsible to provide COTS software licenses in sufficient quantities to meet MGF business requirements. The MGF architecture requires licensing for a development, user acceptance testing, and production environments. Deliverable(s)

Delivery of COTS software of suitable media Any other deliverable the Contractor deems appropriate

11

Acceptance CriteriaHigh-level acceptance criteria for Document Deliverables and Software Deliverables are listed in Section 1.501. Any additional or more specific criteria should be identified here.

Bidder: Describe your proposed solution to meet this service, including State roles and Contractor roles

Bidder must describe how their software is implemented across the State’s three environments: development, user-acceptance testing, and production. Please indicate any licensing differences based upon those environments. Please indicate what typical hardware requirements are needed for the proposed software.

D. Installation and Configuration Services

Contractor is responsible to install and configure the COTS solution working in cooperation with DTMB CSS staff. This will include possible onsite troubleshooting to rectify COTS configuration and installation within the development, QA and production architecture environments. Specific service activities are described below.

Software Installation

Contractor is responsible to work with DTMB CSS staff to install the specified COTS software modules within the architecture environment specified in Section 1.103 above. Contractor will verify the successful operation of the installed “out of the box” COTS functionality within the DTMB environment using Contractor supplied test data and use cases sufficient to confirm that the software performs without malfunction within this environment.

Configuration (COTS)

Contractor will work with State IT staff to install and verify the COTS Solution software within the specified DTMB CSS Application Development environment. Verification of software functionality will be conducted using Contractor supplied test data and test scripts in the presence of DTMB CSS staff that will be responsible to confirm the successful completion of the verification scripts. Contractor will configure the COTS Solution to meet CSS requirements in accordance with the approved COTS Solution Configuration Plan as detailed above.

Deliverable(s) COTS installation within the DTMB IT environment Configured COTS solution Any other deliverable the Contractor deems appropriate

Acceptance CriteriaHigh-level acceptance criteria for Document Deliverables and Software Deliverables are listed in Section 1.501. Any additional or more specific criteria should be identified here.

E. Implementation

Contractor is responsible to work with DTMB CSS staff to implement the COTS Solution within the State IT environment described within Section 1.103 above. Specific implementation service activities are described below.

Data Conversion / Migration

Contractor will perform data conversion / migration of business data from existing sources for use with the COTS Solution Development environment as follows:

MGF road network and other base map layers (to be determined as part of Project Initiation and Business Requirements Validation). Current MGF data includes:

CountyMCD (twp/city)

12

Village/Census Designated PlacesUnincorporated PlacesHydro lines and polygonsLinear rail featuresRail crossingsBridgesSchool Districts & Intermediate School DistrictsCensus Block Groups and Tracts for both 2000 and 2010State Legislative Districts based on 2000 and 2010 CensusAll roads (including private and tribal roads)Adjusted Census AreaPSAP/ESZPA 425 ZonesInterchangesRoundaboutsBoating Access SitesState Park RoadsUS Bike RoutesCrossoversElection Geography (voter precincts, wards, district libraries, etc.)Point Geography (Addresses, polling locations, school buildings, etc.)

Migration/configuration of existing business rules to COTS solutionProcess to integrate road network features, LRS, and events from Roads and Highways business systems to the MGF

A more detailed matrix of the existing and planned MGF data layers can be found in Appendix D.

Contractor will work with DTMB-CSS staff to migrate data from the Development environment to the Quality Assurance (“QA”) and Production environments to support further project services and deliverables as specified below.

Deliverable(s)

Services to implement the application, including Data conversion Data migration (may include transition of business operations to the new application) Configuration

Acceptance CriteriaHigh-level acceptance criteria for Document Deliverables and Software Deliverables are listed in Section 1.501. Any additional or more specific criteria should be identified here.

Bidder: Describe how your proposed solution meets the Data Conversion/Migration services, include State roles and Contractor roles:

The bidder must describe in detail their proposed approach for converting/migrating the existing MGF data into the new data model.

Interfaces / Integration

Contractor must provide appropriate system interfaces / integration to the following internal and external applications:

13

1. ArcGIS Desktop which is used by most State agencies to manage spatial data. It is anticipated that most of the MGF source data edits will be performed in this environment and that there will be one interface to be used by all ArcGIS Desktop users across all agencies using this software. Business rules available in the interface should be configurable by user.

2. Web applications are readily developed at CSS using the ArcGIS JavaScript API to provide GIS editing capability. This environment is ideal for using a service layer to send requests for editing.

3. SQL Server 2014 is the primary database for spatial data storage and maintenance within the State. CSS would like a system where changes in the database tier can be used to trigger changes in MGF by calling a service layer.

4. ESRI Roads and Highways is used by CSS and MDOT to manage the LRS since this is an extension to ArcGIS it is expected that the overall system communication would be the same but allowances need to be made to account for LRS integration back to the master MGF repository.

Contractor to work with DTMB-CSS staff to achieve knowledge transfer regarding skills required to integrate business applications with MGF.

Deliverable(s)

Services to implement the application, including Configuration Interfaces/Integration

Acceptance CriteriaHigh-level acceptance criteria for Document Deliverables and Software Deliverables are listed in Section 1.501. Any additional or more specific criteria should be identified here.

Bidder: Describe how your proposed solution meets the following Interfaces / Integration scenarios, include State roles and Contractor roles:

1. Systems integration between the MGF Business Rules Layer and Agency ArcGIS editing environments. Editors need to be capable of calling the Business Rules Layer from ArcGIS Desktop to verify edits pass associated business rules including topology and have those edits added to MGF. This process should also handle partial validation/successes as well as failures.

2. Integration between Roads and Highways LRS edits and the MGF Business Rules Layer to confirm that LRS updates can be integrated from Roads and Highways back into MGF framework databases.

3. Local partner integration – ArcMap and other GIS software accessing business rules and pushing changes to MGF

4. Export of MGF data into formats and structures that are currently consumed by business programs. This capability is required to support legacy systems during their transition to new MGF product structures and formats.

Testing

Contractor is responsible to work with State staff to conduct COTS Solution testing, including:

System Testing; and User Acceptance Testing (“UAT”).

Contractor responsibilities with respect to the above testing activities are as follows:

Assist State staff in the development of the test plans;

14

Assist State staff in the establishment and verification of the COTS Test environment; Assist State staff in the migration of MGF data from the Development environment to the Test

environment; Participate in on-site test activities as requested by the State Project Manager; Verify and remedy software defects encountered during testing activities; and Obtain official sign-off from the State upon successful completion of testing activities.

Deliverable(s) COTS Solution UAT plan Any other deliverables that the Contractor deems appropriate

Bidder: Describe how your proposed solution meets the Testing services, include State roles and Contractor roles and timelines for testing:

The Bidder must describe their approach in the development of test plans. As part of this description please address:

System test plan User acceptance test plan System performance test plan Status report from testing Tracking log for issues encountered

The Bidder must describe their understanding of Testing tasks and responsibilities, their planned organization to support the application testing and the management of the application testing.

Production Go-live

Contractor is responsible to work with State staff to migrate the COTS application from the QA environment into the Production environment following the successful completion of UAT activities. Contractor responsibilities with respect to the above testing activities are as follows:

Assist State staff in the establishment and verification of the COTS Production environment; Assist State staff in the migration of MGF data from the Test environment to the Production

environment; Participate in on-site Go-live activities as requested by the State Project Manager; and Obtain official sign-off from the State upon successful completion of Go-live activities.

Deliverable(s) Accepted Production COTS Solution Any other deliverable that the Contractor deems appropriate

Bidder: Describe how your proposed solution meets the Production Go-live services, include State roles and Contractor roles:

Bidder must describe how they will approach assisting the State in moving from the QA environment to the Production Go live environment and stage of this project.

Bidders describe any other key factors related to the implementation of the proposed solution (This should include any additional information that the bidder would want to describe in more detail about their implementation plan as well as any risks during the implementation):

15

Performance Warranty Period

Contractor will provide a 90-day Performance Warranty for the Solution in production, as defined in the Terms and Conditions.

Deliverable(s) Warranty Services as required Any other deliverables that the Contractor deems appropriate

Bidder: Describe how your proposed solution meets the Performance Warranty Period services, include State roles and Contractor roles during the 90 day Performance Warranty period for the proposed solution, including how defects, issues and changes will be communicated and resolved

F. Training

Contractor will provide a Train-the-Trainer solution for State administrative staff at a State facility in Lansing, MI for up to 10 staff members, who will provide training for all other State staff to use and administer the Solution. Contractor shall coordinate with DTMB CSS to establish a date and time to ensure that all participants have an opportunity to attend the training. The Train-the-Trainer session should be designed for minimum of 8 to 24 hours (i.e., 1 to 3 day of training). Vendor will propose the appropriate duration of training and curriculum based on their experience with previous training of their solution. Training will include:

Technical training for State individuals who will be working with the services contractor to configure the applications including but not limited to establishing databases and interfaces, data conversion, customization, and upgrading the customized software;

System administration training for State personnel who will be responsible for ongoing maintenance and administration of the system, including security, installing new releases;

End-User Training for designated State personnel responsible for configuring and executing business rules and addressing error codes

End-User Training for designated State personnel responsible for configuring workflows, and other information associated with notifications ; and

End-User Training for designated State personnel responsible for any reporting within the system

Additionally, Contractor will provide online / web-based access to End-User Training, so that users can access the training as desired and when needed.

Contractor will provide training at no additional cost for all upgrades and new versions to the system that affect end-users.

Deliverable(s) Train-the-Trainer training and associated documentation. The documentation will be for the system as

configured for the State and updates to the documentation will be provided throughout the life of the contract when upgrades and new versions are released.

Online / web-based access to End-User Training Additional training ((e.g. classroom or online / web-based training, training flier, release features, etc.)

at no additional cost for all upgrades and new versions to the system that affect end-user functionality

Training is provided in a variety of formats for product installation, use, and administration for a variety of levels (e.g. basic, advanced, refresher, etc.)

All training manuals, training plans and other documentation provided become the property of the State.

16

Acceptance Criteria High-level acceptance criteria for Document Deliverables and Software Deliverables are listed in

Section 1.501. Any additional or more specific criteria should be identified here.

Bidder: Describe how your proposed solution meets this service, including State roles and Contractor roles:

Please include a description about your typical approach to training for the solution being proposed including duration, number of sessions recommended, delivery style, etc. Please provide details about how the training will be broken out by roles based on the modules of the solution for business rules, workflow management, etc.?

Please also describe the training for the administration of the system such as updating new versions of the software, configuring the software on the servers and in conjunction with the database.

Please describe your experience in providing training on this proposed solution and how efficiencies will be realized based on any existing training plans, manuals, and configuration documentation for this proposed solution.

G. Documentation

Contractor is responsible to provide a complete set of Solution documentation to the State including but not limited to the deliverables specified below. Deliverable(s)

User manuals Technical manuals

1. Copies of the following documentation in electronic PDF format will be provided:a. User and Technical Manuals - On-line and Hard Copyb. Data Element Dictionary c. Operations Manual d. All updates of documentation during the term of the Contract, software license and

maintenance agreement2. The following documentation is provided for all modules and program development:

a. System-wide documentation and specifications b. Baseline End-User training manuals to be used as a basis for “User Manuals” and

online / web-based helpc. Installation procedured. Module configuration documents sufficient for configuration maintenance purposese. Testing scripts and results of any tests performed by Contractorf. Specification documentationg. Production migration

3. The documentation of components, features, and use of the software shall be detailed such that resolution of most problems can be determined from the documentation, and most questions can be answered.

4. All system, operational, user, change, and issue documentation must: be available in electronic format; updated regularly; include unique numerical identifiers for each section, and: be consistent with the most current version of the application(s) and three (3) previous versions.

5. All system, operations, user, change and issue documentation is to be organized in a format approved by the State and that facilitates updating and allows for revisions to the documentation to be clearly identified including the three (3) previous versions.

6. The Contractor must develop and submit for State approval complete, accurate, and timely system, operations, and user documentation.

17

7. The Contractor must notify the State of any discrepancies or errors outlined in the system, operations, and user documentation.

Acceptance Criteria High-level acceptance criteria for Document Deliverables and Software Deliverables are listed in

Section 1.501. Media format(s) for documentation are subject to approval by the State.

Bidder: Describe how your proposed solution meets this service, including State roles and Contractor roles:

Please describe in detail your solution documentation in terms of what is provided with the COTS solution. Is most documentation already developed for the solutions being proposed or do they need to be developed as part of the project?

H. Maintenance and Support Contractor is responsible for providing ongoing maintenance and support of the Solution to the State including but not limited to the deliverables specified below. Contractor is requested to specify any additional maintenance and support features provided in addition to those specified under Deliverables below. The resulting contract will integrate the attached schedule, Schedule C – Maintenance and Support, with this section (Section H – Maintenance and Support). Schedule A includes response and resolution times.

Telephone Technical Support Solution Release Management Support Issue Reporting Mechanism

Deliverable(s) Maintenance of Solution software:

Maintenance is available on an annually renewable contract. Maintenance programs commence at the end of the 90-day warranty period. The software maintenance program includes all future software updates and system enhancements

applicable to system modules licensed without further charge to all licensed users maintaining an annually renewable software support contract.

Support Telephone Support

Support is available from 8 am – 5 pm Eastern Time Monday through Friday inclusive, with escalation as necessary to senior technical/engineering staff, and then to higher management and/or senior management.

A Web-enabled help desk interface is provided at no additional cost. Technical

Remote diagnostic capabilities are provided. Support is provided for superseded releases and back releases still in use by the State. For the first year and all subsequent Contract years, the following services are provided for the

current version and one previous version of any Software provided with the deliverables, commencing upon installation of the deliverables or delivery of the Software:1. Error Correction. Upon notice by State of a problem with the Software (which problem

can be verified), reasonable efforts to correct or provide a working solution for the problem.2. Material Defects. The State will be notified of any material errors or defects in the

deliverables known, or made known to Contractor from any source during the Contract term that could cause the production of inaccurate, or otherwise materially incorrect results; the Contractor shall initiate actions as may be commercially necessary or proper to effect corrections of any such errors or defects.

3. Updates. All new releases and bug fixes (collectively referred to as “Changes”) for any software deliverable developed or published by Contractor and made generally available to

18

its other customers at no additional charge will be provided to the State at no additional charge.

Urgent priority tickets require immediate attention. The Contractor shall acknowledge receipt of a support request within 4 hours. The Contractor must first notify DTMB CSS, as soon as it is known that an Urgent or High priority problem exists. Notification is not to be delayed, pending analysis. Contractor shall resolve the support request as soon as practicable, and no later than 48 hours after Contractor’s receipt of the support request. If the Contractor Resolves the Support Request by way of a work-around accepted in writing by the State, the severity level assessment will be reduced to a Severity Level of Error/Issue/Problem 2. See credits and final resolution expectations in Schedule C – Maintenance and Support Agreement.

High priority tickets require that the Contractor shall acknowledge receipt of a support request within 1 business day, and analyze and provide an initial assessment for all urgent and high priority tickets within 1 business day. The Contractor must first notify DTMB CSS, as soon as it is known that an Urgent or High priority problem exists. Notification is not to be delayed, pending analysis. Contractor shall resolve the support request as soon as practicable, and no later than 5 business days after Contractor’s receipt of the support request, or, where applicable, the State’s written acceptance of a Severity Level 1 Error/Issue/Problem work-around. See credits and final resolution expectations in Schedule C – Maintenance and Support Agreement.

Medium priority tickets require that the Contractor shall acknowledge receipt of a support request within 1 business day, and provide an initial assessment for all low and medium priority tickets within 4 hours of the situation becoming tagged with these priorities. Contractor shall resolve the support request no later than 5 business days, Procedural work-around. Program code correction in a future software release. See credits and final resolution expectations in Schedule C – Maintenance and Support Agreement.

Low priority tickets require that the Contractor shall acknowledge receipt of a support request within 2 business days and provide an initial assessment for all low and medium priority tickets within 4 hours of the situation becoming tagged with these priorities. Contractor shall resolve the support request no later than 5 business days, Procedural work-around. Program code correction in a future software release. See credits and final resolution expectations in Schedule C – Maintenance and Support Agreement.

Definitions of priority (urgent, high, medium, and low): o Urgent: error/issue/problem has potential to effect: productive use, multiple users

affected, loss of data, data corruption, no work-around available.o High: issue/problem directly impacts: primary purpose, productive use is significantly

impacted for single user, work-around generally not available.o Medium: have production but incomplete operation, work-arounds generally available.o Low: mainly cosmetic in nature, work-arounds or configurable options generally available.

Acceptance Criteria High-level acceptance criteria for Document Deliverables and Software Deliverables are listed in

Section 1.501. Contractor agrees to the terms and conditions specified under Deliverables above.

Bidder: Describe how your proposed solution meets this service, including State roles and Contractor roles:

Bidder proposals must include a detailed description of their understanding of the tasks and responsibilities related to all customer service tasks, the planned organizational structure to provide support and the

19

management of that structure.

Bidder must describe what is covered by any annual maintenance licensing costs with the solution.

Please describe what the technology road map is for the proposed COTS solution and how often new versions are released with new functionality.

Please describe how you evaluate what new functionality is added to new software releases and how long it takes for new functionality suggestions to become part of a software release.

I. Knowledge Transfer/Transition

Contractor is responsible to collaborate with State technical staff identified by the Client to ensure that ample opportunity is provided for knowledge transfer during the performance of Solution installation, configuration, application integration, data migration and other implementation service activities. Contractor will work with State IT technical staff to prepare a Solution Transition Plan that will describe how the transfer of responsibility for Solution support will occur as part of the Go-live activity. This task will cover and necessary knowledge transfer required that is not covered under the training deliverable. Knowledge transfer can include specific administrative tasks or database tasks that need to be performed by an individual but it is not necessarily a curriculum item for training. Deliverable(s)

Knowledge transfer to State Staff Solution Transition Plan

Acceptance Criteria High-level acceptance criteria for Document Deliverables and Software Deliverables are listed in

Section 1.501. Contractor proposed approach to knowledge transfer will be monitored for effectiveness during Solution

Implementation activities and may require adjustments. Solution Transition Plan requires State approval.

Bidder: Please describe knowledge transfer process and plan for transition to State staff during the contract period including, but not limited to information required outside of the planned training curriculum.

J. Reserve Bank of Hours/Other Services

Contractor agrees to provide additional services as required to meet requirements stated within this section.

Contingency Services

The State intends to establish a contingency reserve of 4,450 resource hours that may be used to address scope changes encountered during the project. Contractor is responsible to ensure that technical resources are available to address this requirement at agreed upon all-inclusive fixed rates. A SOW must be submitted outlining work to be completed to utilize Contingency hours. SOWs must include details regarding the tasks to be completed, the resources assigned to those tasks, a schedule for completion of the work and pricing by milestone, task, and/or line item. Funds for the contingency hours will be submitted for approval by the State Administrative Board with Contract award recommendation; but will not be added to the Contract value until the SOW is submitted and approved by DTMB Procurement and added to the Contract via a Contract Change Notice.

These contingency services might also include, but are not limited to additional workflows and configurations that need to be implemented in future years beyond the initial implementation.

20

Deliverable(s) Contingency services to meet new requirements (complete cost table with estimated hours in Schedule

B Pricing, Table 4) – Based on SOW submitted for change(s). Bidder to identify resources included in calculation for blended hourly rate.

Acceptance CriteriaContractor agrees to provide additional services upon request from the State. Firm fixed hourly rates for these services are to be provided Table 3 and Table 4 of Schedule B Cost Tables.

II. Requirements

This section defines requirements for the Solution. Contractor is responsible to ensure that a response is provided where indicated below to address these requirements.

A. Solution RequirementsSolution requirements identify what the solution or product must run on or integrate with, including any standards that must be met, security requirements, service levels and interfaces. Technical/general system requirements will also identify the general framework in which the system or product must work, such as: capacity requirements (number of users, concurrent users, number of transactions to be handled, peak usage), documentation, audit, backup and recovery. Solution requirements identify what the product or system must do to enable performance of work tasks and any applicable service levels. These requirements are defined in detail within the attachment specified below.

Bidder must complete Schedule A, Attachment 1 - Solution Requirements and submit with their bid response.

1.200 Roles and Responsibilities

1.201 CONTRACTOR STAFF, ROLES, AND RESPONSIBILITIES

A. Contractor StaffThe Contractor will provide resumes in the attached Personnel Resume templates (Solicitation Instructions, Vendor Questions Worksheet Attachment A) for staff, including subcontractors, who will be assigned to the Contract, indicating the duties/responsibilities and qualifications of such personnel, and stating the amount of time each will be assigned to the project. The competence of the personnel the Contractor proposes for this project will be measured by the candidate’s education and experience with particular reference to experience on similar projects as described in this Statement of Work. The Contractor will provide sufficient qualified staffing to satisfy the deliverables of this Statement of Work.

1. Single Point of ContactThe Contractor will identify a Single Point of Contact (SPOC). The duties of the SPOC shall include, but not be limited to:

supporting the management of the Contract, facilitating dispute resolution, and advising the State of performance under the terms and conditions of the Contract.

The State reserves the right to require a change in the current SPOC if the assigned SPOC is not, in the opinion of the State, adequately serving the needs of the State.

2. Key PersonnelThe contractor must submit a letter of commitment for Key Personnel, signed by the identified resource, stating their commitment to work for the contractor/subcontractor on this project contingent on award of the bid. If the identified personnel are currently assigned to a State project the contractor must provide a letter signed by the State Project Manager releasing the individual from the project upon execution of the contract.

21

The Contractor will provide, and update when changed, an organizational chart indicating lines of authority for personnel involved in performance of this Contract and relationships of this staff to other programs or functions of the firm. This chart must also show lines of authority to the next senior level of management and indicate who within the firm will have prime responsibility and final authority for the work.

All Key Personnel may be subject to the State’s interview and approval process. Any key staff substitution must have the prior approval of the State. The State has identified the following as key personnel for this project:

Project Manager System Architect

Project Manager/Technical LeadThe Contractor will provide a project manager/technical lead to interact with the designated personnel from the State to insure a smooth transition to the new system. The project manager/technical lead will coordinate all of the activities of the Contractor personnel assigned to the project and create all reports required by State. The Contractor's project manager/technical lead responsibilities include, at a minimum:

Manage all defined Contractor responsibilities in this Scope of Services. Manage Contractor’s subcontractors, if any Develop the project plan and schedule, and update as needed Serve as the point person for all project issues Coordinate and oversee the day-to-day project activities of the project team Assess and report project feedback and status Escalate project issues, project risks, and other concerns Review all project deliverables and provide feedback Proactively propose/suggest options and alternatives for consideration Utilize change control procedures Prepare project documents and materials Manage and report on the project’s budget

System ArchitectThe Contractor will provide a system architect to interact with the designated personnel from the State to insure a smooth transition to the new system. The system architect will be responsible for coordinating the activities for the overall system design and data model that will meet the solution requirements outlined in this RFP. The system architect may lead a technical team of Contractor personnel but will be responsible for the development of the system design, data model and implementation. The Contractor's system architect responsibilities include, at a minimum:

Design the MGF repository database model Design the CSS editing environment model Design the MGF Solution including component integration and network communication Develop/model workflows Develop/model business rules

3. Subcontractors If the Contractor intends to utilize subcontractors, the Contractor must disclose the following:

The subcontractor’s legal business name, address, and telephone number; a description of the subcontractor’s organization and the services it will provide; and information concerning the subcontractor’s ability to provide the Contract Activities.

The relationship of the subcontractor to the Contractor. Whether the Contractor has a previous working experience with the subcontractor.  If yes,

provide the details of that previous relationship.

22

A complete description of the work that will be performed or provided by the subcontractor. Of the total bid, the price of the subcontractor’s work. A description of the communication plan between the Contractor, its subcontractor(s) and the

State. The Contractor will provide, and update when changed, an organizational chart indicating

lines of authority for personnel involved in performance of this Contract and relationships of this staff to other programs or functions of the firm. This chart must also show lines of authority to the next senior level of management and indicate who within the firm will have prime responsibility and final authority for the work.

A resume template for Additional Staff is provided in the event Contractor proposes additional personnel.

B. On Site Work Requirements1. Location of Work

Work can be performed remotely at the Contractor’s office, or subcontractor’s office if using subcontractors. For proposed on-site meetings, testing, implementations, training, knowledge transfer, the work is to be performed, completed, and managed at the Center for Shared Solution offices in Lansing, Michigan.

2. Hours of Operation: a. Normal State working hours are 8:00 a.m. to 5:00 p.m. EST, Monday through Friday, with work

performed as necessary after those hours to meet project deadlines. No overtime will be authorized or paid.

b. The State is not obligated to provide State management of assigned work outside of normal State working hours. The State reserves the right to modify the work hours in the best interest of the project.

c. Contractor shall observe the same standard holidays as State employees. The State does not compensate for holiday pay.

3. Travel:a. No travel or expenses will be reimbursed. This includes travel costs related to training provided

to the State by Contractor. b. Travel time will not be reimbursed.

4. Additional Security and Background Check Requirements:Contractor must present certifications evidencing satisfactory Michigan State Police Background checks ICHAT and drug tests for all staff identified for assignment to this project.

In addition, proposed Contractor personnel will be required to complete and submit an RI-8 Fingerprint Card for the National Crime Information Center (NCIC) Finger Prints, if required by project.

Contractor will pay for all costs associated with ensuring their staff meets all requirements.

Bidder must complete Personnel Resume Templates (both key and additional if needed) –Proposal Instructions, Attachment A

1.202 STATE STAFF, ROLES, AND RESPONSIBILITIESAgency should specify State personnel dedicated to project, and identify their associated roles and responsibilities.

The State will provide the following resources for the Contractor’s use on this project: (Agency to add, delete or modify the list below)

Work space Minimal clerical support VPN token Access to copiers and fax machine Other. Specify:_________________

23

The State project team will consist of Executive Subject Matter Experts (SME’s), project support, and a MDTMB and Agency project manager:

Executive Subject Matter ExpertsThe Executive Subject Matter Experts representing the business units involved will provide the vision for the business design and how the application shall provide for that vision. They shall be available on an as needed basis. The Executive SME’s will be empowered to:

Resolve project issues in a timely manner Review project plan, status, and issues Resolve deviations from project plan Provide acceptance sign-off Utilize change control procedures Ensure timely availability of State resources Make key implementation decisions, as identified by the Contractor’s project manager, within 48-hours

of their expected decision date.

Name Agency/Division Title Phone/e-mailMark Holmes DTMB-CSS Geospatial Services

Managerholmesm3@michigan.gov

John Clark DTMB-CSS GIS Solutions Architect clarkj@michigan.govJoshua Ross DTMB-CSS Geo-data Manager rossj@michigan.gov

State Project Manager- (MDTMB and Agency)MDTMB will provide a Project Manager who will be responsible for the State’s infrastructure and coordinate with the Contractor in determining the system configuration.

The State’s Project Manager will provide the following services: Provide State facilities, as needed Coordinate the State resources necessary for the project Facilitate coordination between various external contractors Facilitate communication between different State departments/divisions Provide acceptance and sign-off of deliverable/milestone Review and sign-off of timesheets and invoices Resolve project issues Escalate outstanding/high priority issues Utilize change control procedures Conduct regular and ongoing review of the project to confirm that it meets original objectives and

requirements Document and archive all important project decisions Arrange, schedule and facilitate State staff attendance at all project meetings.

Name Agency/Division TitleMark Holmes DTMB –IT Agency Services Program Manager (IT Manager)

Name Agency/Division TitleCurtis Sharp DTMB Project Manager

MDTMB shall provide a Contract Administrator whose duties shall include, but not be limited to, supporting the management of the Contract.

Name Agency/Division TitleTerry Mead DTMB - Procurement Contract Administrator

1.300 Project Plan

1.301 PROJECT PLAN MANAGEMENT

24

Preliminary Project Plan Contractor will provide a Preliminary Project Plan with the proposal for evaluation purposes, including necessary time frames and deliverables for the various stages of the project and the responsibilities and obligations of both the Contractor and the State.

1. In particular, the Preliminary Project Plan will include a MS Project plan or equivalent (check the SUITE/PMM standard):

a. A description of the deliverables to be provided under this contract.b. Target dates and critical paths for the deliverables.c. Identification of roles and responsibilities, including the organization responsible. Contractor is

to provide a roles and responsibility matrix.d. The labor, hardware, materials and supplies required to be provided by the State in meeting the

target dates established in the Preliminary Project Plan.e. Internal milestonesf. Task durations

2. The Preliminary Project Plan shall include the following deliverable/milestones for which payment shall be made.

a. Payment to the Contractor will be made upon the completion and acceptance of the deliverable or milestone, not to exceed contractual costs of the phase. A milestone is defined as complete when all of the deliverables within the milestone have been completed.

b. Failure to provide deliverable/milestone by the identified date may be subject to liquidated damages.

Note: A Final Project Plan will be required as stated in Schedule A Section 1.301 (C) Project Control. Orientation MeetingUpon 15 calendar days from execution of the Contract, the Contractor will be required to attend an orientation meeting to discuss the content and procedures of the Contract. The Contractor shall present a draft project plan at this meeting for review with the State. The meeting will be held in Lansing, Michigan, at a date and time mutually acceptable to the State and the Contractor. The State shall bear no cost for the time and travel of the Contractor for attendance at the meeting.

Performance Review MeetingsThe State will require the Contractor to attend monthly meetings, at a minimum, to review the Contractor’s performance under the Contract. The meetings will be held by teleconference, as mutually agreed by the State and the Contractor.

Project Control1. The Contractor will carry out this project under the direction and control of MDTMB, Center for Shared

Solutions (CSS).2. Within 15 working days of the execution of the Contract, the Contractor will submit to the State project

manager(s) for final approval of the project plan. This project plan must be in agreement with Schedule A, Section 1.104 Work and Deliverables, and must include the following: The Contractor’s project organizational structure. The Contractor’s staffing table with names and title of personnel assigned to the project. This must

be in agreement with staffing of accepted proposal. Necessary substitutions due to change of employment status and other unforeseen circumstances may only be made with prior approval of the State.

The Contractor’s communication plan with the State and with any subcontractors. This will outline primary contacts and protocols for issue escalation.

The project work breakdown structure (WBS) showing sub-projects, activities and tasks, and resources required and allocated to each.

The time-phased plan in the form of a graphic display, showing each event, task, and decision point in the WBS.

3. The Contractor will manage the project in accordance with the State Unified Information Technology Environment (SUITE) methodology, which includes standards for project management, systems engineering, and associated forms and templates which is available at http://www.michigan.gov/suite a. Contractor will use an automated tool for planning, monitoring, and tracking the Contract’s progress

and the level of effort of any Contractor personnel spent performing Services under the Contract. The tool shall have the capability to produce: Staffing tables with names of personnel assigned to Contract tasks.

25

Project plans showing tasks, subtasks, deliverables, and the resources required and allocated to each (including detailed plans for all Services to be performed within the next 100 calendar days, updated semi-monthly).

Updates must include actual time spent on each task and a revised estimate to complete. Graphs showing critical events, dependencies and decision points during the course of the

Contract.b. Any tool(s) used by Contractor for such purposes must produce information of a type and in a

manner and format that will support reporting in compliance with the State standards.

Bidder’s Response on approach to Project Control:

1.302 REPORTSReporting formats must be submitted to the State’s Project Manager for approval within 10 business days after the execution of the contract resulting from this RFP. Once both parties have agreed to the format of the report, it shall become the standard to follow for the duration of the contract. Review of the reporting formats will take place during the Project Initiation Meeting. Project reports will be reviewed during each monthly Performance Review meeting. The Contractor will be responsible for providing the agreed upon reports at least 48 hours prior to the scheduled Performance Review meeting.

The following topics should be addressed at each monthly meeting:

Weekly Project status Updated project plan Summary of activity during the report period Accomplishments during the report period Deliverable status Schedule status Action Item status Issues Change Control Repair status Maintenance Activity

Bidder’s Response on approach to Reports:

1.400 Project Management

1.401 ISSUE MANAGEMENTAn issue is an identified event that if not addressed may affect schedule, scope, quality, or budget.

The Contractor shall maintain an issue log for issues relating to the provision of services under this Contract. The issue management log must be communicated to the State’s Project Manager on an agreed upon schedule, with email notifications and updates. The issue log must be updated and must contain the following minimum elements:

Description of issue Issue identification date Responsibility for resolving issue. Priority for issue resolution (to be mutually agreed upon by the State and the Contractor) Resources assigned responsibility for resolution Resolution date Resolution description

Issues shall be escalated for resolution from level 1 through level 3, as defined below:

Level 1 – Business leadsLevel 2 – Project ManagersLevel 3 – Executive Subject Matter Experts (SME’s)

26

Bidder’s Response on approach to Issue Management:

1.402 RISK MANAGEMENTA risk is an unknown circumstance or event that, if it occurs, may have a positive or negative impact on the project.

The Contractor is responsible for establishing a risk management plan and process, including the identification and recording of risk items, prioritization of risks, definition of mitigation strategies, monitoring of risk items, and periodic risk assessment reviews with the State.

A risk management plan format shall be submitted to the State for approval within twenty (20) business days after the effective date of the contract resulting from the upcoming RFP. The risk management plan will be developed during the initial planning phase of the project, and be in accordance with the State’s PMM methodology. Once both parties have agreed to the format of the plan, it shall become the standard to follow for the duration of the contract. The plan must be updated bi-weekly, or as agreed upon.

The Contractor shall provide the tool to track risks. The Contractor will work with the State and allow input into the prioritization of risks.

The Contractor is responsible for identification of risks for each phase of the project. Mitigating and/or eliminating assigned risks will be the responsibility of the Contractor. The State will assume the same responsibility for risks assigned to them.

Bidder’s Response on approach to Risk Management:

1.403 CHANGE MANAGEMENTProject Change management: is defined as the process to communicate, assess, monitor, and control all changes to system resources and processes. Project change management should be addressed through the change control process as defined in SUITE.

The State also employs change management in its administration of the Contract.

Contract Change management: If a proposed contract change is approved by the Agency, the Contract Administrator will submit a request for change to the Department of Technology, Management and Budget, Procurement Buyer, who will make recommendations to the Director of DTMB-Procurement regarding ultimate approval/disapproval of change request. If the DTMB Procurement Director agrees with the proposed modification, and all required approvals are obtained (including State Administrative Board), the DTMB-Procurement Buyer will issue an addendum to the Contract, via a Contract Change Notice. Contractors who provide products or services prior to the issuance of a Contract Change Notice by the DTMB-Procurement, risk non-payment for the out-of-scope/pricing products and/or services.

The Contractor must employ change management procedures to handle such things as “out-of-scope” requests or changing business needs of the State while the migration is underway.

The Contractor will employ the change control methodologies to justify changes in the processing environment, and to ensure those changes will not adversely affect performance or availability.

Bidder’s Response on approach to Change Management:

1.500 Acceptance

1.501 CRITERIAThe following is standard acceptance criteria for all document and software deliverables:

Final deliverable acceptance will be provided by the Program Manager for each milestone/cost category upon completion of all tasks, milestones, testing and reviews in accordance with the steps outlined for each deliverable.

27

1.502 FINAL ACCEPTANCESuccessful completion of the Performance Warranty shall be the criterion for final acceptance of the Solution.

LIQUIDATED DAMAGES The parties acknowledge that late or improper completion of the Work will cause loss and damage to the State, and that it would be impracticable and extremely difficult to fix the actual damage sustained by the State as a result. Therefore, Contractor and the State agree that if there is late or improper completion of the Work the State is entitled to collect liquidated damages in the amount of $750.00 per day for each day up to $15,000.00 in total if Contractor fails to remedy the late or improper completion of the Work. The State may waive these damages at its sole discretion.

1.600 Compensation and Payment

1.601 COMPENSATION AND PAYMENT

Method of PaymentThe project will be paid on a firm fixed price deliverables/milestone basis, with firm fixed unit rates for contingency hours. Payment will be tied to deliverable acceptance. The Costs Table(s) attached must be used as the format for submitting pricing information.

Bidder must complete the Cost Table attached in Schedule B.

The selected Contractor will be required to submit an Administrative Fee (see Section 11.3) on all MIDEAL member payments remitted under the Contract. The Bidder should consider Administrative Fee requirements when developing its price proposal.

Extended purchasing program volume requirements are not included, unless stated otherwise.

Travel - The State will not pay for any travel expenses, including hotel, mileage, meals, parking, etc. Travel time will not be reimbursed.

Price Reductions - If Contractor reduces its prices for any of the software or services during the term of this Contract, the State shall have the immediate benefit of such lower prices for new purchases. Contractor shall send notice to the State’s MDTMB Contract Administrator with the reduced prices within fifteen (15) Business Days [or other appropriate time period] of the reduction taking effect. – OR – Contractor shall send updated prices to the State [quarterly/semi-annually].

Statements of Work and Issuance of Purchase Orders Unless otherwise agreed by the parties, each Statement of Work will include:

1. Background2. Project Objective3. Scope of Work4. Deliverables5. Acceptance Criteria6. Project Control and Reports7. Specific Department Standards8. Payment Schedule9. Travel and Expenses

10. Project Contacts11. Agency Responsibilities and Assumptions12. Location of Where the Work is to be performed13. Expected Contractor Work Hours and Conditions

The parties agree that the Services/Deliverables to be rendered by Contractor pursuant to this Contract (and any future amendments of it) will be defined and described in detail in Statements of Work or Purchase Orders (PO) executed under this Contract. Contractor shall not be obliged or authorized to commence any work to implement a Statement of Work until authorized via a PO issued against this

28

Contract. Contractor shall perform in accordance with this Contract, including the Statements of Work/Purchase Orders executed under it.

InvoicingContractor will submit properly itemized invoices to

DTMB – Financial ServicesAccounts PayableP.O. Box 30026Lansing, MI 48909orDTMB-Accounts-Payable@michigan.gov

. Invoices must provide and itemize, as applicable: Contract number; Purchase Order number Contractor name, address, phone number, and Federal Tax Identification Number; Description of any commodities/hardware, including quantity ordered; Date(s) of delivery and/or date(s) of installation and set up; Price for each item, or Contractor’s list price for each item and applicable discounts; Maintenance charges; Net invoice price for each item; Shipping costs; Other applicable charges; Total invoice price; and Payment terms, including any available prompt payment discount.

The State may pay maintenance and support charges on a monthly basis, in arrears. Payment of maintenance service/support of less than one (1) month’s duration shall be prorated at 1/30th of the basic monthly maintenance charges for each calendar day.

Incorrect or incomplete invoices will be returned to Contractor for correction and reissue.

1.602 HOLDBACKReserved

29

Schedule A, Attachment 1, Requirements

Instructions for completing the requirements worksheet

Bidders shall respond to this section within the Word form provided. Bidders shall respond to each requirement (row). Bidders shall not alter the structure or numbering system of the Word form. Failure to comply may result in the dismissal of the proposal.

If a bidder cannot perform one or more of the mandatory functions, the bidder’s proposal may be dismissed in its entirety.

Comments

The requirements include a column for comments. The State of Michigan (SOM) is allowing and encouraging the bidder the option to expand in writing on the functionality of its solution. Comments shall be limited to only those that pertain to the specific requirement. Comments should be clear and direct and be limited to no more than 250 words. Bidders may submit more detailed comments or promotional items separate from this form; however, additional comments and/or promotional materials may not be part of the formal evaluation process.

Definitions

Mandatory - the requirement must be present in the proposed solution, exactly as stated, or the solution may not be considered by the SOM.

Expected - the requirement should be present in the proposed solution, exactly as stated, but the lack of the requirement would not disqualify the solution. However, the lack of one or more expected requirements may reduce a solution’s technical score.

Optional - the SOM would like the requirement to be present in the proposed solution or provided through an alternative approach or future enhancement. Responses to optional requirements may not be considered as points for passing, failing, or meeting a threshold for further consideration. However, the inclusion of optional requirements will contribute to determining the solution providing the best value.

NOTE:The “Mandatory” and “Expected” requirements will become contractual obligations for the company(s) whose response(s) is accepted and signs a contract with the state. Those “Optional” requirements that are offered by the awarded contractor(s) and accepted by the state, will also be included in the contract(s) and made available to state and local users. In the event “Optional” items are purchased by the SOM or local users, these requirements will be incorporated into the project plan along with the “Mandatory” and “Expected” requirements for the purchase, and all ordered items/functions/services will be monitored for compliance as contractual obligations in the same manner regardless of their initial designation in the RFP for evaluation purposes.

Row instructions

Bidder is not to alter.

30

Schedule A, Attachment 1, Requirements Column instructions

Column AThis column indicates a numeric sequence of each function. Bidder is not to alter.

Column BThis column describes the function(s) desired in the parts and maintenance program.

Column CThis column indicates if a particular requirement is Mandatory, Expected or Optional. Bidder is not to alter.

Column DThis column indicates whether a bidder can comply with a particular requirement. Bidder is to enter either “Yes” or “No”.

Column EThis column indicates how a bidder will comply with a particular requirement. Bidder is to enter the appropriate Requirement Response (Req. Response), for each requirement with an 1, 2, 3, 4, 5 as defined below.

1. Currently provided within the standard service.2. Currently provided as an enhancement to standard service at no additional cost.3. Currently provided as an enhancement to standard service at an additional cost detailed

in the cost proposal as part of this RFP.4. Not currently provided but will be added at the additional cost detailed in the cost

proposal as part of this RFP.5. Service will not be provided.

Column FThis column is provided for bidders to provide any additional information related to the solution.

It shall be assumed by the State that a blank cell indicates the requirement is not available.

31

Schedule A, Attachment 1, Requirements

A B C D E F

Req. No. RequirementMandatory (M)Expected (E)Optional (O)

Response (Yes / No)

Response(1,2,3,4,5) Comments

Environment1 MGF data must be stored within a

relational database that supports spatial data types

M

2 The system will implement security and roles to manage access and capabilities to: review, edit data etc.

E

3 A Business Rules Engine must be able to process and validate data going into the MGF system

M

4 The Business Rules Engine may be capable of processing Linear Referencing Data from various sources into ESRI Roads and Highways

O

5 Workflow will be able to track and manage edits and approvals to data changes within the system

E

6 The system will be able to manage addressing data being aggregated from multiple sources adhering to National Emergency Number Association (NENA) standards

E

7 The system will support change management to track edit history and the ability to roll back or undo those edits.

E

8 The system will be capable of processing and storing data with elevation or z values.

E

Database

document.docx Page 32 of 39

Schedule A, Attachment 1, Requirements

A B C D E F

Req. No. RequirementMandatory (M)Expected (E)Optional (O)

Response (Yes / No)

Response(1,2,3,4,5) Comments

9 The system design must include a comprehensive database model M

10 The MGF repository must be capable of storing spatial data of the following types including but not limited to:

Polylines (with or without z) Polygons (with or without z) Points (with or without z) LRS (with or without z) Networks (with or without z)

M

11 The database will be able to utilize system accounts as well as the State of Michigan’s Active Directory for roles and permissions on objects

E

12 The system will provide metadata storage and editing capabilities for all objects in the database

E

Security13 The system will leverage Microsoft’s

Active Directory for permissions and roles of users logged in to the SOM network, external (web) users will use SOM single sign-on (MiLogin).

E

14 Security will be granular enough to control what users can see and access based upon attributes, features, as well as geographic location (County Road Commission could only update county roads within their county)

E

Linear Referencing Systems

document.docx Page 33 of 39

Schedule A, Attachment 1, Requirements

A B C D E F

Req. No. RequirementMandatory (M)Expected (E)Optional (O)

Response (Yes / No)

Response(1,2,3,4,5) Comments

15 The system will be capable of storing multiple LRS networks such as

Roadway centerlineo ID, Begin and End

Mile Hydrography centerline

(NHD)o ID, Length

E

16 Networks will incorporate elevation as part of the geometry E

17 The system must integrate LRS management with ESRI Roads and Highways

M

Change Management18 The system will include a process to

track changes across time to geometry and attributes

E

19 Changes must indicate the editor and approver along with time stamps and comments

M

Conflation

document.docx Page 34 of 39

Schedule A, Attachment 1, Requirements

A B C D E F

Req. No. RequirementMandatory (M)Expected (E)Optional (O)

Response (Yes / No)

Response(1,2,3,4,5) Comments

20 The system must have the tools to load bulk data from external sources and compare that incoming information against what is currently within the repository. This capability must evaluate the geometry and attributes to determine what is new or a change compared to what already exists and integrate it into the appropriate workflow(s). Integrated changes must be checked against all business rules and allow reporting/evaluation of errors before being committed.

M

Workflow21 The system must have workflow

management to request and track changes

M

22 Users of the system will be capable of seeing workflow that they have initiated, approved/declined or in some capacity participated in along with its status.

E

23 Specific workflows will be capable of expanding to illustrate all steps involved, whom (if anyone) has a roll for a specific step along with the current progress.

E

24 A user with the role of workflow manager will be capable of seeing all workflows and be notified when workflows fail and when feasible be capable of restarting the workflow once the failure is resolved.

O

document.docx Page 35 of 39

Schedule A, Attachment 1, Requirements

A B C D E F

Req. No. RequirementMandatory (M)Expected (E)Optional (O)

Response (Yes / No)

Response(1,2,3,4,5) Comments

25 Workflow administrators must be capable of adding, deleting and updating workflows. M

Cartography26 The system’s data model will be

capable of supporting cartographic capabilities of ArcGIS Server for Tile Cache production including but not limited to the following:

Represent centerlines based upon number of lanes

Draw arrows within roadway for one way streets

Draw road over and under correctly regardless of layer order

E

Configuration27 System administrators must have the

capability to add new datasets to the system. As an example a business area is interested in tracking conservation easements so the admin must be able to create a new polygon layer in the system, load it with data, establish workflow, business rules and assign users and roles.

M

28 The system will be capable of communicating adequate error messages (i.e. server logs, error message dialogues, etc.) for proper error diagnostics.

E

Topology

document.docx Page 36 of 39

Schedule A, Attachment 1, Requirements

A B C D E F

Req. No. RequirementMandatory (M)Expected (E)Optional (O)

Response (Yes / No)

Response(1,2,3,4,5) Comments

29 The system must evaluate and maintain spatial tolerance rules to ensure data integrity for all linear features, linear intersections as well as polygonal features.

M

30 The system will be capable of evaluating linear orientation to be in compliance with business rules

E

31 The system will have specific geometries to have well defined spatial relationships such as Township boundaries being coincident and/or wholly contained within Counties. The system will be capable of evaluating and storing geometries with topologic integrity

E

32 It will be possible to rerun topology analysis on demand and produce a topology health report from the system to ensure that topology is being enforced and to identify issues where topology conflicts have arisen. Any identified issues should trigger a workflow.

E

Business Rules Engine BRE33 The system must have a business

rules engine that is external from the repository and application interfaces. This approach must accommodate internal and external partners that do not have the same software capabilities to integrate with MGF

M

34 The BRE will establish service end points for each rule (where feasible) to accommodate system integration and development

E

document.docx Page 37 of 39

Schedule A, Attachment 1, Requirements

A B C D E F

Req. No. RequirementMandatory (M)Expected (E)Optional (O)

Response (Yes / No)

Response(1,2,3,4,5) Comments

35 The BRE will have a web API for integration with web applications as well as a plugin for ArcGIS Desktop, at a minimum

E

36 The BRE will support the creating, editing, deleting and publishing of rules and it is preferred that there is an interactive visual interface in which to accomplish this

E

37 Rules must be capable of verifying incoming data has the correct attribute data types and fall within established domains

M

38 The system must be capable of analyzing topology between incoming data and MGF, the following are example topology rules:

Apply snapping to incoming shape based upon a specific value for each layer

Identify where incoming geometry already exists in MGF

Ensure coincidence when incoming shape is meant to be drawn in the same location as an existing shape

Identify issues with incoming geometry as a result of ends not snapping to existing segments

M

39 The system will be capable of executing attribute business rules across multiple related tables.

E

document.docx Page 38 of 39

Schedule A, Attachment 1, Requirements

A B C D E F

Req. No. RequirementMandatory (M)Expected (E)Optional (O)

Response (Yes / No)

Response(1,2,3,4,5) Comments

40 The BRE must be scalable to allow an administer to add, edit and remove rules as business requires

M

41 The system will be capable of maintaining points at geometric intersections within unique IDs and assigning those IDs to all lines that enter or exit that intersection point

E

document.docx Page 39 of 39