Ohio Department of Transportation. Division of Engineering. Office of Real Estate. Synergy. Real Estate Business Analysis

Transcription

1 Ohio Department of Transportation Division of Engineering Office of Real Estate Synergy Real Estate Business Analysis Technical System Specification Version 1.00 Revision History Date Version Modified By 2/26/ Initial Draft Cheryl Jacino 3/15/ Define Real Estate Acquisition Process Cheryl Jacino 5/15/ Define Real Estate Technical Cheryl Jacino 5/24/ Update with DoIT Technical Cheryl Jacino 5/29/ Finalize Technical System Cheryl Jacino Page 1 of 8 Wednesday, May 29, 2013

2 0 Table of Contents 0 Synergy Technical System Specification Purpose Author(s) Audience Business Non-Functional Technical Technical Documentation Server Hardware Document Storage Mapping User Security System Security Database Client Side Software Mobile Synergy Non-Functional Synergy System Interfaces... 8 Page 2 of 8 Wednesday, May 29, 2013

3 0 0 Synergy Technical System Specification 0.1 Purpose The System Specification (SRS) is to capture the business requirements for the Real Estate Right of Way System. The purpose of these requirements is three fold: 1) used to select a system to purchase 2) used to identify feature requirements during the system design phase 3) assist ODOT with identifying system compatibility issues The SRS document should also capture the non-functional requirements as well as system conversion requirements. 0.2 Author(s) The Business Analyst is the owner of this document, with assistance from the Business Sponsors, Business Stakeholders, Business Subject Matter Experts, District Subject Matter Experts, and Project Management Office Manager. 0.3 Audience The SRS is a useful tool for Business Users requesting the system to communicate the functions of the system with DoIT and vendors involved in creating the software or system. This document will also serve as a reference for any future development. Page 3 of 8 Wednesday, May 29, 2013

4 0.4 Business A business requirement is a specific, actionable, testable directive that is under the control of the business and supports a business policy. Included in the document of SRS are the high-level lists of requirements that will be broken into features during the Systems Design Phase that follows Business Analysis. There may be more than one feature for each business requirement. System Specifications table includes the following parts: Change? Feature This is a numeric that will be used to track the requirement through all phases of the system development to ensure the requirement is designed, developed, tested, approved, and implemented. includes the title of the process and a definition of what is included in the process. Used to identify the source of the requirement. In this case the requirement is being tracked back to the requirements gathering session. RE-Acquisition-BA stands for Real Estate Acquisition Gathered during Business Analysis. RE-Appraisal-BA stands for Real Estate Appraisal Gathered during Business Analysis. RE-Acquisition-Type-BA stands for Real Estate Acquisition Type Gathering during Business Analysis. RE-Utility-BA stands for Real Estate Utility Coordination Gathering during Business Analysis. RE-Relocation-BA stands for Real Estate Relocation Gathering during Business Analysis. RE-Property-Mgmt-BA stands for Real Estate Property Management Gathering during Business Analysis. RE-Fiscal-BA stands for Real Estate Fiscal Gathering during Business Analysis. RE-Reporting-BA stands for Real Estate Reporting, Records Retention, & Document Handling Gathering during Business Analysis. stands for Real Estate Technical, System Interfaces, and Non-Functional Gathering during Business Analysis. Define the priority within the replacement New System for each requirement. Vendor must meet this requirement. feature of the vendor s system. Detail is captured in a sub-process related to this process. Page 4 of 8 Wednesday, May 29, 2013

5 8 Non-Functional Non-functional requirements are also known as supplemental requirements. These requirements describe the qualities the system must have and are not directly related to the functionality of the application solution. 8.1 Technical These are the recommended ODOT approved Technical. Anything outside these guidelines will require approval by ODOT Department of Information Technology Technical Documentation RE The vendor will provide an installation and configuration document for the system software and database schema. RE The vendor should provide a diagram of the hardware architecture. RE The vendor should provide a diagram of the software architecture including all plugins, batch processes, worker processes, and other processes in the diagram. RE The vendor should provide a diagram of the database schema including the core product database schema and interfaces with various ODOT systems and databases Server Hardware RE The vendor must be compatible with Windows 2008 or newer IIS 7 RE The vendor must use currently supported products and tools. RE The vendor s system must be scalable. RE The vendor must provide a diagram of the server hardware and software architecture. RE The vendor s system should support server virtualization. RE The vendor s system should function within a load balanced environment on all tiers Document Storage RE The vendor s system must not store documents in the database. RE The vendor s system should keep documents stored on a file or network share, with a UNC path stored in the database. Page 5 of 8 Wednesday, May 29, 2013

6 8.1.4 Mapping RE RE The vendor s system should work with ESRI ArcServer and product family. The vendor s system should work with MS Bing Maps User Security RE RE RE RE The vendor s system should use Active Directory and LDAP user security protocol. The vendor s system should be able to access multiple Active Directory domains. The vendor s system should support the creation of user groups which the user will be a member, each group will have unique access and privileges within the system, such as User, Super User, Administrator, and Read Only. The vendor s system should support ODOT employees and non-odot employees System Security RE RE The vendor s system must pass an ODOT security scan which reports potential security threats and vulnerabilities within web software. The vendor should follow OWASP secure code practices Database RE RE RE The vendor s system should use Oracle 11g or SQL Server The vendor must provide interface capabilities for ODOT s current database architecture; Oracle 11g, SQL Server 2008, Sybase IQ and Sybase OLTP. The vendor s system should have the ability to interface with other databases outside of the core product. Page 6 of 8 Wednesday, May 29, 2013

7 8.1.8 Client Side Software RE Re RE RE The vendor s system must run with Microsoft s Internet Explorer 9 or Mozilla FireFox 5.0. Vendor must provide a list of all Plug-ins and specify any version specific requirements for Plugin s. The vendor s web components should use SSL encryption. The vendor is discouraged from using Plug-ins and will be subject to ODOT s approval of all Plug-ins Mobile RE The vendor must provide a list of mobile configurations that are compatible with the system. Page 7 of 8 Wednesday, May 29, 2013

8 8.2 Synergy Non-Functional RE Desired system is a single Web based Enterprise system with all users sign-on through the internet. RE The new system will accommodate the additional function of signon by outside consultants. RE These requirements are based on current Laws and procedures which can be found on ODOT Office of Real Estate Manuals. When the Laws and procedures change it is necessary to change the requirements and any affected forms and Synergy system procedures to conform to the Law. RE Total number of users both Central Office staff, District staff, and consultants will total approximately 300. The current estimate is that there will be approximately 75 concurrent users in the system RE Users will connect by internet from business, personal computers, tablets, ipads, and mobile phones. RE Solution must have capacity to store data for ODOT Projects and related parcels in active status until the project and all related parcels are closed. Appropriation can take years to complete which means the data can reside in active status for multiple years. There are known cases that have taken 10 years in appropriation. RE Vendor will provide a data conversion document. RE Vendor must provide documentation of response time based on existing client response times. RE Vendor will convert data from existing database to Vendor s database. RE Vendor s system should store archival documents in the form of PDF s or JPEGs with index pointing to storage location. RE Vendor s system should keep active documents is a form available to be retrieved and manipulated within the application. RE hours of operation are 24 hours a day 7 days a week. If scheduled down time is required the system needs to be available from 6:00 AM to 12:00AM (midnight) 7 days a week. 8.3 Synergy System Interfaces RE Accounting interface to pull updates into Real Estate system. RE Ellis interface to pull updates into Real Estate system. RE CES for pulling updates from Contract s task order agreements. RE TIMS interface to provide data. GIS must be compatible with ESRI system. Page 8 of 8 Wednesday, May 29, 2013