Alliance Model Procurement Requirements
for State and Local Government Acquisition of
Hardware/Software for Codes Administration and Enforcement

BACKGROUND TO MODEL

In their organizational meeting in the summer of 2001, the members of the National Alliance on Building Regulatory Reform in the Digital Age identified as one of the barriers to getting more jurisdictions to make use of information technology to streamline their building regulatory process as the need to assist states and local governments in developing and using up-to-date procurement requirements for such hardware and software.

The Alliance assigned to their Technology Task Force and to their secretariat, NCSBCS, the task of surveying states and localities regarding best practices in setting procurement requirements for hardware and software used in the administration and enforcement of building codes. With assistance from jurisdictions in Silicon Valley area of California, Florida, Kentucky, Minnesota, New Mexico, New York, Michigan, Oregon, Virginia, and with input from the National Association of State Chief Information Officers, the Alliance compiled a number of sample procurement requirements currently being used across the nation.

From those samples, a model set of procurement documents, including technical requirements, was assembled, distributed to the Technology Task Force for their review, comment, and subsequent posting on the Alliance portion of the NCSBCS website for local and state jurisdictions to consider as they prepare their own requests for proposal for such hardware and software services. In early March 2004, the National Association of State Chief Information Officers (NASCIO) reviewed and approved this document and, together with Alliance members, recommended consolidation into a single model suitable for both state and localities.

While each locality or state may already have their own special formats for RFP’s and may already have procurement technical requirements, it is hoped by the Alliance that this model will supplement and offer some suggested additional language that those jurisdictions will find useful in their solicitations and the conduct of subsequent contract with hardware and software vendors.

INTEROPERABILITY REQUIREMENT

In preparing the original model, the Technology Task Force reviewed the current state of both the hardware and software industry to provide products that are interoperable. From that review, the Task Force determined that at that stage there were no uniformly accepted interoperability provisions for hardware and software that could be used in the administration and enforcement of building codes, but that efforts were underway that could lead to basic interoperability for some building regulatory processes in the near term.

In that regard, it was agreed that, with assistance from the Alliance including its federal partners, actions could be taken to support the more rapid development of at least a first level of interoperability requirements can be included in these model procurement requirements. As noted in the next section, over the fall and winter of 2003, the initial statement of interoperability requirements was developed and incorporated in the "Statement of Interoperability for the Building Regulatory Process, March 2004. This statement and these requirements will be continually refined in the future as more specific interoperability requirements and agreed standards are defined and proven through agreed eXtensible Markup Language (XML) technologies being developed by the Alliance in coordination with the software industry.

ACTIONS TO DEVELOP INITIAL INTEROPERABILITY STATEMENT NOW INCORPORATED IN THIS MODEL

The accompanying initial interoperability statement of March 2004 now incorporated was generated through the September 24, 2003, Summit on Streamlining the Building Regulatory Process Through Interoperability and the subsequent work of the Alliance, the software, building regulatory and construction industries under funding provided by the National Institute of Standards and Technology. 

STEPS TOWARDS YOUR JURISDICTION ACQUIRING HARDWARE AND SOFTWARE TO STREAM LINE YOUR REGULATORY SYSTEM

If your locality or state has not acquired information technology to help enhance the effectiveness and efficiency of your building regulatory process, then there are three steps that you should consider before undertaking such an initiative and develop a request for proposal to acquire such hardware and software.

STEP ONE: SYSTEMS ARCHITECTURE - IS YOUR EXISTING REGULATORY SYSTEM STREAMLINED AND READY TO EFFECTIVELY APPLY INFORMATION TECHNOLOGY TO IT?

One of the first recommendations made to the Alliance by representatives from its member, the National Association of State Chief Information Officers, was don’t attempt to throw IT on top of an ineffective and inefficient building regulatory system. If you do, all you will have accomplished is to put scarce financial and manpower resources into a process that is broken and all you will be doing is to help it break faster.

The first step, therefore, is to step back and review your building department’s overall business process. This is a function being conducted today by many state and local government chief information officers in coordination with the heads of the agencies that manage the jurisdiction’s building codes administration and enforcement programs and with input from the jurisdiction’s clients in the construction community. This includes client satisfaction surveys to identify areas from their perspective that need streamlining first.

The National Association of State CIO’s has available on its website (www.nascio.org) several useful tools that can be applied to developing governance and technical architecture domains within an enterprise architecture program. NASCIO is currently working on its next version of the Enterprise Architecture Tool-Kit that will encompass the architecture domains of business, process, data, and application, as well as program management and enterprise application integration.

The Alliance has as one of its later work deliverables the development of model business processes for effective building code administration programs. As these materials are developed, they will be posted on the Alliance’s website.

As a part of your review of your regulatory system, take a look at how that regulatory system needs to interface with other regulatory functions in your jurisdiction, such as zoning and land use, water & sewer, transportation, emergency management, etc., and seek to address an overall IT strategy to link where appropriate the data you are acquiring and managing in your building regulatory system with these regulatory programs as well. Your state, county, city, municipal CIO will be an invaluable resource in this effort.

STEP TWO: WORK WITH YOUR CONSTRUCTION COMMUNITY AND ELECTED OFFICIALS TO BUILD A CONSTITUENCY TO FUND THE ACQUISITION OF INFORMATION TECHNOLOGY

Jurisdictions tend to fund information technology either through a special surcharge on building permits or from general funds that are dedicated for information technology, e-government programs in that state or locality. (See Funding Mechanisms for IT.)

In general, the most successful funding efforts have been those that have actively involved the construction industry as proponents for either general fund or permit surcharge revenue sources. That involvement begins in Step 1 above, where the construction community’s concerns over areas in the building regulatory process needing streamlining are heard and acted upon by the jurisdiction. In Silicon Valley California, the business community was the initiating and driving force behind that region’s early leadership role in the application of information technology to the building regulatory process.

Once a building regulatory system has been evaluated and, where necessary, restructured or realigned, information technology needs to be accurately assessed and a funding source for hardware and software secured, then that jurisdiction is ready to move onto Step 3.

STEP THREE: FOLLOW THESE GENERAL ADMINISTRATIVE AND TECHNICAL REQUIREMENTS RECOMMENDED FOR INCLUSION IN PROCUREMENT DOCUMENT

The model procurement document developed by the Alliance for consideration by local and state government include a number of basic administrative and technical requirements that the Alliance believes are essential to helping to assure an effective procurement and ultimate operation of the acquired hardware or software by the jurisdiction.

Basic administrative requirements:

Basic technical requirements are:

What follows in the remainder of this report is the model procurement document for states and localities to consider. For more information on the content of the models and the work of the Alliance’s Technology Task Force, please contact Carolyn Fitch at NCSBCS at cfitch@ncsbcs.org.

 

STATE AND LOCAL GOVERNMENT PROCUREMENT MODEL: STATE/COUNTY/CITY/MUNICIPAL

SAMPLE PROCUREMENT REQUIREMENTS FOR STATE/COUNTY/CITY/MUNICIPAL GOVERNMENTS TO ACQUIRE HARDWARE AND SOFTWARE FOR USE IN THEIR CODES ADMINISTRATION AND ENFORCEMENT PROGRAMS

(This model is largely based in part upon Fairfax County, Virginia, procurement of February 15, 2002, with modifications to incorporate language for several state procurements and input from the Alliance received August 2003 and March 2004.)

 

SAMPLE COVER PAGE ON JURISDICTION LETTERHEAD

Issue Date:                                                                                   Request for Proposal No.

For: (brief description of what is being procured)

Agency:                                                                       Date/Time of Closing Procurement:

Contract Administrator:

PROPOSAL:

 

Name and Address of Firm:                                   Contact information:

State or local contract license #

Vendor Legally Authorized Signature                    Date

Print Name and Title

 

STATE/COUNTY/MUNICIPAL MODEL - SAMPLE PROCUREMENT REQUIREMENTS

PART I - FUNCTIONAL AND TECHNICAL REQUIREMENTS

  1. Purpose of the Request for Proposal and Scope of Contract
  2. The purpose of this Request for Proposal (RFP) is to solicit proposals from qualified and experienced Offerors who can provide a software solution (commercial off-the-shelf – COTS, or customized) to replace several existing computer systems with an integrated solution that builds on the (insert jurisdiction’s data model, systems and architecture) and provides for new features to keep up with changing business needs. (Describe how this procurement fits into the overall e-gov vision of the jurisdiction.)

    Replacement of the following components and the financial processes that support them are expressly covered under the terms and conditions of this RFP:

    (Provide following information, perhaps in easy to read table form that gives: Name of Component/Platform it operates on (Mainframe, Internet, etc.)/Primary Agency responsible for that component

    The scope of work includes the following:

    1.1  Describe the new system for which you are purchasing the software/hardware; answering the following questions:  What is it supposed to do?  What system does it replace?

Example: (Name of Jurisdiction) envisions a new system that will significantly simplify the permitting and complaint management processes. The system will be expected to meet the increasing demands of customers to make the permitting and complaint management processes simpler to understand, more convenient to use, more efficient and more predictable. The system is also expected to greatly expand public access to the permitting and complaint processes by using web-enabled technologies. The system will also interface with the (county/city/municipality’s) GIS and (insert any other databases, e.g. a land development enterprise database.) This system also will incorporate the acquisition and use of interoperable hardware and software. The new system will consist of the following modules:

(List modules you are procuring, e.g. Permitting, Plan Review and Inspections, and then go onto briefly describe including what you want each of these new or replacement systems to do. Detail performance requirements needed such as:

        1.2  Describe other services needed such as to replace an existing software system.

Examples of items to specify regarding the replacement system:

The replacement system will enable the jurisdiction to (for complaints management module):

        1.3  Jurisdiction’s preferences regarding COTS software solution, e.g. Jurisdiction
        prefers a COTS software solution, which includes all of the desired functions specified
        in this document. (Jurisdiction) will consider custom-built software. Vendors may bid
        total system solution individually. In lieu of a single solution, the Offeror may propose a
        COTS solution(s) that addresses a subset of the requirements that must be
        successfully integrated with other vendor products to meet all the requirements of this
        RFP. The Offeror may also propose partnerships, which broaden the functionality and
        interoperability of their own product. All responses submitted by a team of vendors
        must clearly designate the prime contractor/integrator responsibility.

The new system must comply with State of _____________ and ______________ County legal and regulatory requirements and follow the (Jurisdiction’s Information Technology Department’s) standards (Such as):

Jurisdiction anticipates a web-enabled software solution.

Licenses for database management system, operating system software, and hardware to support the proposed solution may be acquired under the scope of this contract using contract amendments after award. Nothing, herein, however, shall be taken to require the (jurisdiction) to procure database management system, operating system software, hardware or other components through the successful Offeror.

Any additional development support requested by the jurisdiction will be awarded to the selected vendor by negotiated contract amendment based on vendor qualifications, capabilities, technical approaches, and rate structures resulting from this RFP. The additional work will be awarded on a task-by-task basis subject to available funding.

2.    Background

    (Insert description of your state or locality, the jurisdiction’s agencies involved in this software/hardware related existing software systems in jurisdiction that impact or may impact scope of this RFP. This may well go on for several pages).

    The following is a description of the main (state/county/city/municipal) agencies, related jurisdictions, and existing software systems involved in the scope of this RFP.

    (Depending on the solicitation and structure of your jurisdiction, this may include a large number of local or state agencies. Fairfax County procurement gives you an example

3.    Strategic Information Technology Direction of the Jurisdiction

        (This provides overall philosophy and framework for what you are soliciting) A sample
        statement is as follows:

        "The (State/City/County) of ______________ is committed to the use of new
        technology to meet end-user requirements that will enable the workforce to provide
        better and faster service at reduced cost. The following (insert number) initiatives
        address different aspects of the County’s objective to provide effective, efficient and
        customer-oriented access to data and services for constituents and for customers
        within the government itself.

        (Insert your own list of initiatives. Fairfax County, VA, for example has the following
        listed and described: E-Government; Customer Relationship Management System;
        Geographic Information System; and Enterprise Technology (data) Center for
        Modernization.)

4.  Tasks to be Performed (Specific to your procurement)

4.1  Proposal

4.2  Work Plan

(Requires that the successful Offeror must submit a work plan to the jurisdiction for their review, approval and where necessary modification. The work plan is the first deliverable under this procurement. Work plan should identify necessary resources and subtasks. As an example, depending on the work being done, the plan would include life cycle activities, data conversion, milestone reviews, system installation, training and ongoing customer support.

Require a Gantt Chart to illustrate each of the major tasks. Chart should include month by month planning schedule and include a listing of key activities, deliverables, and dates. Also you may want to specify software package you want Gantt Chart and Work Plan submitted on.)

4.3  Systems Life Cycle

(Jurisdiction may want to require successful Offeror to work with the jurisdiction’s staff and be responsible for all of the phases of the system life cycle. Among other items, this may include: analysis of system requirements, development of systems design and program specifications, coding and testing system enhancements and new applications, technical training and user support, installation of hardware, applications software, and data conversions. List required documentation of the above items).

4.4  Software Considerations

The successful Offeror(s) will be responsible for the development of all software involved in the new system. The proposed solution could be a COTS, a modified COTS, or a custom developed package. Customized software must include detail design and programming code.

The successful Offeror(s) must clearly identify and price all software, including third party packages necessary for operation of the system.

All software provided must be on electronic media capable of being used by existing (jurisdiction) hardware or hardware proposed as part of the proposed system. All software quoted should be for the latest publicly available version or release. The vendor must agree to furnish or escrow the readable source code and object (executable) code for all modules licensed for use by the (jurisdiction). This may be done with a national escrow company or with the (jurisdiction) itself. The vendor must agree to maintain release upgrades in like manner. In the case of vendor dissolution or cessation support by the vendor, all code held in escrow would become property of the (jurisdiction).

4.5 Integration with Other Systems (Interoperability)

The successful Offeror(s) must implement the required interfaces with other systems as detailed in this RFP. These interfaces must support available open and agreed-upon XML-based interoperability technologies.

4.6 Data Conversion/Data Migration

The successful Offeror(s) will assist in performing all related data tasks to make sure that legacy data is successfully migrated to the new system. These tasks will include:

The successful Offeror(s) must perform the analysis of the data that needs to be converted/migrated, prepare and submit a plan for the conversion/migration, and provide utilities and programs to achieve the conversion/migration. Data conversion/data migration requirements are listed in this RFP.

4.7 Acceptance Tests

The (jurisdiction) requires that testing be an integrated part of the entire implementation life cycle. Testing must follow the (jurisdiction) Application Life Cycle Standards (ALCS). The successful Offeror(s) must submit a test plan that complies with the testing requirements specified in the General Requirements of this RFP.

After system installation and configuration, a reliability test shall be performed which represents as closely as possible, the normal daily workload of the included divisions and other departmental personnel as deemed appropriate. Those departments shall jointly make the final determination as to whether the system passes the reliability test procedure.

4.8 Documentation

The successful Offeror(s) must provide the documentation specified in the General Requirements this RFP.

4.9 Nonproprietary Training

The successful Offeror(s) will be responsible for three types of training:

The deliverables related to this task include:

(Jurisdiction) staff to be trained includes users from different agencies and staff responsible for technical support from Department of Information Technology (insert name of IT department). Offeror(s) must propose a training plan that specifies the required training for train-the-trainer staff and the technical staff supporting the application. Scheduling of the training will need to be closely coordinated with County staff to coincide with the installation of the software.

4.10 Implementation Assistance

The successful Offeror(s) will provide the (jurisdiction) on-site implementation assistance. Implementation assistance will be composed of, but not limited to, the following activities:

4.11 Disaster Recovery Methods and Procedures

The successful Offeror(s) must describe its disaster recovery plans for the proposed system. These methods should be able to preserve the integrity of applications and data, and provide immediate system and data recovery with minimum downtime possible according to the industry standards. At a minimum the system should include:

4.12 Commercial Off-the-Shelf-Software Considerations

The following considerations and responsibilities shall apply to the successful Offeror(s) if the solution submitted includes COTS packages.

4.13 Hardware Considerations

The successful Offeror(s) will provide the software. Vendors should include the hardware component specifications that are most effective to utilize the proposed system software. The (jurisdiction) has a strong desire for vendors to comply with existing (jurisdiction) standard hardware and software. Vendors must justify any exceptions. The total cost of using non-standard technology will be considered in evaluating such proposals. Information relating to the communications capacity of the proposed system must be provided by the vendor (e.g., how many concurrent users will generate what levels of communication traffic). The vendor must document any additional network wiring, disk space, hardware or software required to implement the proposed solution.

 

 

SAMPLE OF GENERAL REQUIREMENTS (Extracted from Fairfax County, Virginia, Procurement Requirements)

The general requirements apply to the Permit, Plan Review and Inspection Module and the Complaints Management Module. These requirements describe general GUI and database requirements, querying and reporting requirements, as well as other non-functional requirements.

 

No.

Description

5.1 Standards

1.

Be compatible with the following County standards:

2.

Be compatible with the full range of the County’s desktop machines.

3.

Be compatible with Windows 98/NT Workstation/Windows 2000/Windows XP.

4.

Be capable of conforming to interoperability standards as standards are developed or endorsed by the Alliance for Building Regulatory Reform in the Digital Age.

5.2 System Design

5.

All concurrent users must be able to be logged on at all times.

6.

Be self-contained such that all functions described on the requirements must be accessible from within the same executable.

7.

The system must be self-contained in its own workspace (i.e. if forms are placed off the initially defined workspace, horizontal and/or vertical scroll bars must appear allowing the forms to be scrolled within view).

8.

Allow staff to automatically transition to other system functions/screens/databases via tool bar/menu/icon selection without having to return to a main menu.

9.

Allow user preference for the way forms are opened, either cascaded or centered in the workspace.

10.

Include an option to close all currently opened forms.

11.

Include an option to cascade all currently opened forms.

12.

The system must have resizable and scrollable forms.

13.

Include a menu item that arranges all icons within the workspace.

14.

Utilize tabs to keep forms self-contained, as opposed to using multiple, separate windows to perform all available functions. Tabs must also group related data.

15.

Have the ability to export data items to a variety of file formats (i.e. Word, Excel, and Access). Please list supported file formats.

16.

Provide the ability to export interoperable data packages from the system using available XML interoperability standards.

17.

Have word-wrap features like a traditional word processor (i.e. Microsoft Word) when entering text.

18.

Be able to "cut and paste" text both from and to word-processing packages.

19.

Be easy to navigate for those users who are familiar with the Windows 98 environment.

20.

Have a similar "look and feel" in terms of navigation, use etc. on all system modules.

21.

Provide a Database Administration Module to allow a System Administrator to control security, maintenance of tables, backups, maintenance of reports, screens, etc.

22.

Allow reports created by users (e.g. Reports created using Crystal Reports) to be added to the system menus or toolbars by the system administrator.

23.

During data entry for records, automatically copy (fill in) common information that was previously entered, with the ability to override manually, to the current data entry screen. This will eliminate dual data entry.

24.

The system must have the ability to populate date fields with the current date, city and state based on an entered zip code, etc.

25.

Allow users to enter up to 600 characters of comments.

26.

Provide a clear (reset) button that removes all data from all fields on the current screen.

27.

Allow users to view the history (i.e. all modifications made) of any record.

28.

The system database model must contain the data fields needed to satisfy all business needs.

29.

The system must support record use/time stamping.

30.

Alert users in real time of all address changes that occur.

31.

Ability to create employee electronic signatures for electronic approvals (sign-offs).

32.

Allow staff to electronically approve plan reviews and permit applications.

33.

System must track the location of records/plans for all cases.

34.

Retrieval capability of 35 years of data prior to the need to access archived records. (i.e. system robust enough to hold 35 years of data).

5.3 Printing

35.

Allow the user to direct printouts to LAN printers on an NT network.

36.

Support printing of mailing labels.

37.

Generate a variety of documents that will be issued to County customers. The County must have the option of utilizing pre-printed forms, or the system must have sufficient graphics capability to provide appealing documents (e.g. permits, inspection requests cards, certificates of occupancy, license cards, etc.)

5.4 Editing/Validation

38.

Allow users to edit data input in accordance with previously established access rights.

39.

System ability to modify, add, delete fields needed to manage specific information required for each discipline.

40.

Provide sufficient editing, coding, and validation routines to minimize data entry errors and enforce data entry consistency.

41.

Provide range check editing for numeric fields.

42.

Use pick-lists, drop-down boxes, or other easy-to-use options to assist users in correctly entering data.

43.

Provide users with the ability to import data packages into the data-entry system via available
XML interoperability standards.

44.

Display adequate error messages if user is entering wrong data.

45.

Display adequate error messages if user is executing invalid transactions.

46.

During data entry, ensure that all mandatory data items are captured and must automatically display error conditions to the user.

47.

Provide spell-checking capabilities on fields requiring text entry. Allow users to customize the dictionary to include industry specific jargon.

5.5 User Help

48.

Support comprehensive context sensitive "Help" for all screens and functions.

49.

The software must include a comprehensive user’s manual documenting all operations of the software. Manuals must include sample reports, screen illustrations and instructions, and provide a step-by-step training aid to teach non-technical operations and administrative personnel to operate the software.

50.

The user’s manual must be available on-line including a table of contents, index, search capability, and hypertext links.

51.

Support customization of on-line help with local procedures and editing instructions without having to modify system programs.

52.

Enable the users to access help information without exiting the active transaction.

5.6 Performance Requirements

53.

End to end, online response time for the central data processing system must satisfy the following performance requirements during normal processing periods:

  • No greater than 1 second 80% of the time for character data
  • No greater than 2 seconds 95% of the time for character data
  • No greater than 3 seconds 97% of the time for character data
  • No greater than 3 seconds for graphic data on magnetic storage
  • No greater than 15 seconds for graphic data on optical storage
54.

End to end, online response time for the central data processing system must satisfy the following performance requirements during peak processing periods:

  • No greater than 2 second 80% of the time for character data
  • No greater than 4 seconds 95% of the time for character data
  • No greater than 5 seconds 97% of the time for character data
  • No greater than 5 seconds for graphic data on magnetic storage
  • No greater than 20 seconds for graphic data on optical storage

5.7 Security

55.

Support the establishment, monitoring, and enforcement of appropriate system security capabilities. The proposed system will maintain the integrity and validity of information through the use of its own security features, network security features, DBMS security features, etc.

56.

The system’s Database Administration Module must provide for the development of user accounts and provide user and password protection. Multiple levels of user security must be available that provide for read-only access, read-write access, and update access. Database administration functions should provide the ability to selectively "lock" certain database tables.

57.

Allow the system administrator to enforce unique passwords per user and to have user passwords expire after a specified number of days.

58.

Enable the system administrator to easily create new security levels (including the ability to create, store and assign user groups having similar access capabilities) and/or modify the existing ones.

59.

The system must be capable of displaying only those modules and pull-down menus that the user is authorized to access, as defined in the Database Administration Module. Based on a user’s ID and password, pull-down menus must be custom displayed at the user’s workstation. If changed, the user’s pull-down menus must also change.

60.

The system must only display buttons on the toolbar that the user has access to perform.

61.

Provide automatic notification to system administration when a user’s access to authorized modules or functions is inactive for a user-defined specified period.

62.

Support full auditing capabilities and accountability for all transactions processed through the system.

63.

Capture user transaction history (i.e. transaction name, user ID, time stamp, etc.).

64.

Provide reports of attempted security violations by users.

65.

Provide screen level security.

66.

Display adequate error messages if user is attempting to access transactions without the proper authority.

67.

Provide adequate security functions to handle web-based transactions without compromising the integrity of the system.

68.

Provide secure capabilities to handle financial/confidential information on web-based transactions.

5.8 Maintenance

69.

Provide a maintenance agreement itemized by each system component with estimated costs.

5.9 Testing/Training Environment

70.

Include system testing/training environments, independent from the production system, to be used for system testing, enhancement and analysis without affecting the production environment.

71.

Provide the capability to refresh the test/training environments with new copies of the production files.

72.

Provide the capability to refresh the test/training environments with a limited number of records if needed because of storage constraints.

5.10 Documentation

73.

Provide complete technical documentation, including but not limited to: Data structure, data dictionary, table description, installation procedures, troubleshooting guides, backup and recovery procedures, program descriptions, screen descriptions, etc.

74.

Provide user manuals and user documentation describing all procedures and screens.

5.11 Imaging

75.

The system must include a comprehensive image capture, assignment and display capability. Third party scanning hardware must be directly interfaced to the successful Offeror(s) system, eliminating the need for middleware scanning software.

76.

Capability of scanning simple plans into the system for on-line permit review and commentary. Also, include the ability to calculate distances for required setback limits.

77.

Capability of relating scanned documents to corresponding records.

5.12 Queries

78.

Capability of retrieving, displaying (and/or printing) and updating relevant permit, inspection, review information and complaints and litigation information.

79.

Capability to perform a query by any data field or multiple data fields for virtually every screen in the system.

80.

Allow the user to sort the rows returned from a query by a selected list of field. The system must also allow the user to select any of these rows and load them into a data entry screen.

81.

The system must allow for at least the following query methods:

  • Start – to search records that are greater than or equal to the specified search criteria
  • Match – to search records with fields having values that begin with the specified search criteria
  • Exact – to search records with fields that exactly match the specified search criteria

5.13 Acceptance Tests

82.

Provide a test plan and test cases that demonstrates through an acceptance process and/or stress tests that the software functions as required in the County’s technical environment and that the software meets the County’s technical requirements.

83.

Describe what Fairfax County resources will be required to accomplish all required tests. Describe number of staff required as well as their skills.

84.

Test response time and system performance to simulate number of concurrent users performing add, retrieve, and update transactions. Simulation should be equivalent to 200 concurrent users. Find breaking point if any (See performance requirements in section 5.6).

85.

Test backup and recovery features.

86.

Provide a tool to keep track of the test results and resolution of problems reported.

87.

Perform a final acceptance test that must use Fairfax County production data and include report generation. The final acceptance test will exercise all functionality, interfaces and components. To this end, the new system will be loaded with training record data from the legacy system. The Offeror must describe their preferred approach to accomplish this task as well as experience with similar situations.

88.

Document the results of the final acceptance test in a report to the Department of Information Technology (DIT) prior to final payment being made by the County.

  1. Requirements

(Insert here a functional overview of all of the desired services (e.g., permitting, plan review, etc.)

Fairfax County, Virginia, and other jurisdictions reviewed, divided requirements into use cases and related functional requirements. (Non-functional requirements were detailed in Section 5 of this model.)

The use cases provide a high level view of the specific business processes by capturing in words what a flow chart would normally convey. The proposed system must be able to implement these cases, the different scenarios associated with them, and other supporting functions to provide an integrated environment.

The functional requirements are tables that immediately follow the use case. They describe additional functionalities and are intended to supplement the use cases by detailing requirements that were not captured in the corresponding use case. The proposed system must be able to provide the functions described in these requirements.

 

Part II – Administrative Requirements

(This section of a procurement document contains all of the technical proposal section instructions and business proposal section instructions. The business proposal will include sections on: submission of proposal, pricing, contract completion and renewal, payments, late proposal, period that proposal remains valid, basis for award, and other contracting boiler plate mandated by general procurement requirements of the locality or state.)

 

Part III – Appendices

(Your jurisdiction has standard contracting general conditions and instructions to bidders that go in this section. You also may wish to include pricing schedule for the work being bid. Three sample pages from Fairfax County, Virginia, follows.)

 

APPENDIX

 

Pricing Schedule

Pricing Summary Form

Permitting & Inspection Services and Complaints Management

Vendor: __________________________________

Note: This Pricing Summary Form is intended to supplement the detailed cost proposal(s) required pursuant to Part II, Section 2 of this RFP. It serves as a summary of the detailed information to be provided in accordance with Section 2.1.

Permitting, Plan Review, and Inspections Module

ITEM

Direct Labor (hours)

Direct Labor Hourly Rate (dollars)

Labor Overhead (hours)

Labor Overhead Hourly Rate (dollars)

* Other Costs (dollars)

Total

(dollars)

Software Development and Implementation

Analysis and Requirements

           

System Design

           

System Development

           

System Testing

           

Training

           

Documentation

           

Implementation Assistance

           

Licenses

           

Maintenance & Technical Support

           

Subtotal

           

Reports

Ad-Hoc Reporting tool

           

Standard Reports

           

Customized Reports

           

Subtotal

           

Integration with Other Systems

Subtotal

           

Data Conversion

ISIS mainframe

           

Fairfax County Licensing Application

           

Non-Residential Use Permits Application

Fire Prevention Databases

           

Subtotal

           

 

 

Travel and Other Costs

Travel/subsistence costs

           

Other Costs if any (specify)

           

Subtotal

           

Total (Permitting, Plan Review and Inspections Module)

           

Complaints Management Module

ITEM

Direct Labor (hours)

Direct Labor Hourly Rate (dollars)

Overhead Labor (hours)

Overhead Labor Hourly Rate (dollars)

* Other Costs (dollars)

Total

(dollars)

Software Development and Implementation

Analysis and Requirements

           

System Design

           

System Development

           

System Testing

           

Training

           

Documentation

           

Implementation Assistance

           

Licenses

           

Maintenance & Technical Support

           

Subtotal

           

Reports

Ad-Hoc Reporting tool

           

Standard Reports

Customized Reports

           

Subtotal

           

Integration with Other Systems

Subtotal

           

Data Conversion

Complaints Management Paradox database

           

Subtotal

           

Travel and Other Costs

Travel/Subsistence Costs

           

Other Costs if any (specify)

           

Subtotal

           

Total (Complaints Management System)

           

Grand Total

           

* Specify other costs associated with this amount.

 

 

NAME OF OFFEROR: _______________________________________

ADDRESS:_________________________________________________

E-MAIL ADDRESS: __________________________________________

Name and addresses of both service and fiscal representatives (Key Personnel) who would handle this account.

           Service Representative:                                                                
           Telephone Number:                                                                      

Fiscal Representative:                                                                   
Telephone Number:                                                                       
E-mail address:                                                                            

A detailed description of cost elements must be submitted as part of the business proposal.

The following documents which are included in this Solicitation shall be incorporated by reference in the resulting contract and become a part of said contract:

    A.   County of Fairfax Acceptance Agreement (Cover Sheet, DPSM32)

  1. Functional & Technical and Administrative Requirements, Pages 1 through 78
  2. Appendix A (General Conditions and Instructions to Bidders)
  3. Appendix B (RFP Checklist, BPOL Form, COG Rider, SBE Schedule, Subcontractor’s Notification Form)
  4. Appendix C (Table of Conformance)

   F.   Appendix D (Listing of Potential Subcontractors)


                                                
Typed name and title

                                                
Signature

                                               
Date of Submission