APPENDIX N EXAMPLE REQUIREMENTS SPECIFICATION

Transcription

1 APPENDIX N EXAMPLE REQUIREMENTS SPECIFICATION

2 Requirements Specification Automated Permit Routing and Analysis System (APRAS) Version: 1.1 Work Order 38: Task 3.1 Requirements Specification Prepared by: Business Analysis and Process Improvement Division Last Updated: April 16, 2012

3 Revision History The first final version of this document is version 1.0. Subsequent updates to the document will be numbered v1.1, v1.2, v1.3, etc. Any significant changes (i.e., the addition of a new section or the removal of an existing section) will be numbered v2.0, v3.0, etc. The table below lists the current version and a high-level description of the document to ensure traceability of document revisions. Date Version Description Author 04/06/ /16/ First draft version distributed to Project Execution Management Team (PEMT) for review and comment. Final draft version with feedback from PEMT review incorporated. Business Analysis and Process Improvement Division Business Analysis and Process Improvement Division Confidential,2012 Page 3

4 Table of Contents 1. INTRODUCTION PURPOSE SCOPE ACRONYMS REFERENCES DOCUMENT OVERVIEW OVERALL DESCRIPTION CONSTRAINTS ASSUMPTIONS BUSINESS REQUIREMENTS GENERAL REQUIREMENTS (GN) PERMIT SUBMISSION (PS) ROUTING (RT) PERMIT PROCESSING (PP) REPORTING (RP) ACCOUNTING (AC) DETAILED CHANGE TRACKING LOG APPENDIX A Confidential,2012 Page 4

5 Requirements Specification 1. Introduction The Automated Permit Routing Analysis System (APRAS) allows North America s Motor Carrier Industry to enter applications for Oversize and Overweight Hauling Permits. It ensures compliant load dimensions and weights for highway and bridge safety limits, issuing permits according to authorized route. The current APRAS is over ten years old and does not afford customers a service that reflects current technological efficiencies and functionality. Current APRAS functionality provides user interfaces that are neither intuitive nor streamlined. The lack of upfront system edits for applications processing is a significant deficiency that other states Departments of Transportation (DOTs) offer to the Motor Carrier Industry. The deficiencies of APRAS and its criticality to the safe and efficient operation of the Motor Carrier Industry in Pennsylvania warrant comprehensive evaluation in order to deliver a system that meets both private industry and needs. The user community has made several requests to add additional or new functionality to APRAS, and the business owners have identified numerous modifications and enhancements that would improve both functionality and customer satisfaction with APRAS. APRAS processed over 467,000 applications for calendar year 2011, and this volume of customers and applications necessitates a system that is flexible, responsive, and aids in mitigating the difficulties experienced by customers as part of the Special Hauling Permit Application process. This deliverable documents the high-level business and system requirements from the study. The business requirements support the business goals and objectives identified in the project charter, and the system requirements support the business requirements. For reference, the business goals and objectives are documented in Appendix A. The study team identified these requirements through documentation analysis, stakeholder interviews, and iterative reviews with team members from Central Office (CO) and the District Offices (DOs). Confidential,2012 Page 5

6 1.1 Purpose The purpose of this document is to record the business requirements that support the business goals and objectives of the APRAS Study Charter. These business requirements express the core needs of the various stakeholders, and will serve as a link between the business goals and objectives of the charter and the solution capabilities (system requirements) that will be needed to accomplish those goals and objectives. The relationships between the business goals and objectives, business requirements, and system requirements will be documented and maintained via the IBM Rational Requisite Pro (ReqPro) tool. 1.2 Scope In Scope The scope of this deliverable is to identify and document high level business and system requirements for an alternative APRAS solution. While determining the requirements, focus was maintained on what was to be accomplished (i.e., the business need) with limited consideration for how that need would be met by the solution (i.e., by what media and mechanism). The study team examined the business processes currently being performed for the administration of APRAS. The team used the functionality of the current APRAS software as a starting point for identifying requirements Out of Scope Project Scope excludes the following: Any system changes or modifications in which the system does not have a direct or indirect connection to the Special Hauling Permit Applications Processing solution; and Any business process or activity not related to the Special Hauling Permit Applications Processing solution. Confidential,2012 Page 6

7 1.3 Acronyms Table 1 lists the acronyms used within this document. Table 1: Acronym ABAS APRAS BA BGO BMS2 BR CARATS CO CPO DO ECMS EDMS EDRS FEIN GIS ITB PDIF PEMA PEMT PSP RBAC RCRS ReqPro RMS SAP SR TCP US DOT VIN Definition Automated Bridge Analysis System Automated Permit Routing Analysis System Business Analyst Business Goal and Objective Bridge Management System Business Partner Business Requirement Commonwealth Automated Registration and Titling System Central Office Central Permitting Office District Office Engineering and Construction Management System Enterprise Document Management System Emergency Detour Routing System Federal Employer Identification Number Geographic Information Systems Information Technology Bulletins Data Integration Facility Pennsylvania Emergency Management Agency Project Execution Management Team Pennsylvania Department of Transportation Pennsylvania State Police Role Based Access Control Road Condition Reporting System Requisite Professional Road Management System Systems, Applications and Products State Route Traffic Control Plan United States Department of Transportation Vehicle Identification Number Confidential,2012 Page 7

8 1.4 References Table 2 lists the artifacts that served as references for the study team during the creation of this document. Many of the business and system requirements have their origins as part of one of the documents in the table. Additionally, the study s previously issued deliverables are included for congruency. Table 2: Document Title Author/Publisher Location APRAS Online Training Manual Volume 1 Gearing Up APRAS Online Training Manual Volume 2 Using APRAS APRAS Online Training Manual Volume 3 Super Loads WO#38 Deliverable 2.1 APRAS As-Is Interview Documentation WO#38 Deliverable 2.2 APRAS As-Is Process Documentation Pennsylvania Title 75 Vehicle Code Pennsylvania Title 67 Chapter 179 Oversize and Overweight Loads and Vehicles WO#38 APRAS Study Charter Business Analysis and Process Improvement Division Business Analysis and Process Improvement Division Commonwealth of Pennsylvania Commonwealth of Pennsylvania Office of Information Services APRAS Web APRAS Web APRAS Web PCS Site PCS Site Web PA Code PCS Site 1.5 Document Overview The remainder of this document is organized into the following sections: Overall Description high level description of how the requirements contained in this document are presented. This section includes the constraints and assumptions under which the study team operated while documenting the business requirements. Requirements needs of various stakeholders engaged in APRAS. These include both Business and System Requirements. Detailed Change Tracking Log list of specific changes made to this document after initial release. Confidential,2012 Page 8

9 2. Overall Description The business and system requirements contained in this document describe s needs for the replacement and/or enhancement of the current APRAS functionality. The requirements are presented in a table layout with the following columns: ID unique identifier for the business or system requirement Description statement of the need that must be fulfilled for to support the referenced business goal and objective Source the requirements are classified according to the entity that brought the requirement to the attention of the study team. Requirements may be sourced from, including Central and District Office staff, Business Partners such as motor carriers, or represent Policy or Legislative changes Notes comments regarding the requirement 2.1 Constraints This document presents only the over-arching needs of the solution to be implemented for the replacement/enhancement of APRAS and, as such, has been kept to a high-level. Subsequent documents will be created as part of the study to reflect the system requirements that will document the capabilities and characteristics to fulfill those needs. Further analysis will be needed to drive to the level of detail necessary to support the design and implementation of the replacement/enhanced solution Organizational Constraints Identify stakeholders and their needs Policy and Legislative changes Process Constraints None Technical Constraints None 2.2 Assumptions This document has been created under the following assumptions: Requirements are at a high level has provided the necessary resources and references to create complete requirements Key personnel will have time available for meetings, interviews, approvals, and any required followups will make ReqPro available and provide direction regarding standard usage Confidential,2012 Page 9

10 3. Business Requirements The tables in this section list the business requirements that have been identified for the APRAS study. These business requirements are organized into six different tables: General (GN), Permit Submission (PS), Routing (RT), Permit Processing (PP), Reporting (RP), and Accounting (AC). These table titles correspond to the business process areas and are used to organize/categorize the requirement information for the APRAS study, as defined in Table 3. Table 3: Title General (GN) Permit Submission (PS) Routing (RT) Permit Processing (PP) Reporting (RP) Accounting (AC) Description Includes requirements associated with common business and technical considerations such as infrastructure, interfaces, security, and data. Includes requirements associated with the permit application submission process from initializing the application to submitting for it for review. Includes requirements associated with providing usable routes for a submitted permit application. Includes requirements associated with processing a permit application including reviews, approval, or denial. Includes requirements associated with reporting capabilities for both internal and external users. Includes requirements associated with accounting functions such as payment processing and invoicing. Each table includes Business Requirements (BRs) identified by the naming convention, shall. BRs are numbered with a whole number after the category abbreviation (e.g., GN1 ). The subsequent rows consist of one or more system requirements associated with the BR, and are numbered in a sequence that corresponds to the BR number above. (e.g. GN1.01). Each requirement is enclosed in the <> characters as a means to efficiently upload the requirement to the IBM ReqPro tool, which will house the approved requirements per standards. Confidential,2012 Page 10

11 3.1 General Requirements (GN) GN1 < shall provide the capability to maintain and manage the infrastructure for the APRAS solution.> Charter GN1.01 maintain and manage the infrastructure for the permitting solution.> GN1.02 <The system will adhere to all applicable established architecture and development standards.> GN1.03 <The system will adhere to all applicable established security standards.> GN1.04 maintain an audit trail of user activity.> GN1.05 <The system will provide Role Based Access Control (RBAC) for all nonpublic functions.> GN1.06 allow assignment of personnel, contractor personnel, and personnel (both public and private) to roles.> GN1.07 maintain roles and their associated functions.> GN1.08 assign multiple roles to the same user.> GN1.09 add, activate, and deactivate/disable user IDs.> GN1.10 reset user passwords.> GN1.11 <The system will prevent the display of any user s password in readable form.> GN1.12 archive permit information based on predefined criteria.> Requirements review session GN1.13 <The system will provide access to archived permit information.> Requirements review session Confidential,2012 Page 11

12 GN2 < shall provide the capability to maintain a Special Hauling Account.> create a new Special Hauling Account including but not limited to: GN2.01 Company name Company address Company Account Administrator contact information Company contact information address for permit delivery Billing information Bond information> GN2.02 modify a new Special Hauling Account.> GN2.03 GN2.04 assign a Special Hauling Account Administrator.> <The system will provide the ability for a Special Hauling Account Administrator to maintain user accounts.> This may be subject to enterprise security model determination GN3 < shall provide the capability to search existing administrative messages.> GN3.01 <The system will provide a link to view administrative messages related to a denial.> GN3.02 notify carriers of administrative message edits and deletions.> GN3.03 create/search an administrative message. > (CO) GN3.04 <The system will display construction activity in administrative messages.> GN3.05 <The system will provide the capability to display administrative messages upon user access.> Confidential,2012 Page 12

13 <The system will provide the capability to search administrative messages by the following, but not limited to: GN3.06 County State Route (SR) SR and Direction of travel Date Range> GN4 < shall provide an extensive search capability.> (CO) <The system will provide the capability to search by but not limited to the following: GN4.01 Load type District Vehicle type Timeframe Location> GN4.02 search by State Route numbers for but not limited to the following: Administrative messages Permit applications> (DO) GN4.03 search/view recent applications.> GN4.04 <The system will provide a link to view, search, and sort construction information.> GN5 < shall provide a rules engine.> (CO) GN5.01 <The system will provide the capability to extract and report business rules.> (CO) GN6 < shall provide an interface with legacy systems.> GN6.01 sync updates with Roadway Management System (RMS) to include and not be limited to Spoke permits Existing routes Pending routes > (DO) Confidential,2012 Page 13

14 <The system will interface with, but not be limited to, the following: GN6.02 Bridge Management System (BMS2) RMS Commonwealth Automated Registration and Titling System (CARATS) Enterprise Document Management System (EDMS)> (DO) <The system will interface with but not be limited to the following: GN PA Open Plan Road Condition Reporting System (RCRS) Engineering and Construction Management System (ECMS) Emergency Detour Routing System (EDRS) Data Integration Facility (PDIF)> GN6.04 <The system will provide an automated interface with carrier systems for data updates including Load descriptions Equipment information> GN7 < shall provide a common interface for both internal users and business partners.> (CO) GN7.01 <The system will provide access to the video log. > GN7.02 <The system will provide easy to use and understandable screens.> GN7.03 < The system will provide efficient navigation and an economy of screens.> GN7.04 < The system will have consistency in look, feel, and application-wide functionality throughout upgrades and maintenance.> Confidential,2012 Page 14

15 <The system will provide access to the following but not limited to: GN7.05 Type 10 maps Manuals Regulations and policies> (DO) GN7.06 <The system will provide the capability to display all application generated errors.> GN7.07 create a.pdf file. > GN8 < shall provide the capability for mobile permitting.> Charter GN8.01 <The system will provide a mobile permitting application.> GN8.02 apply for permits via a mobile application.> GN8.03 view/display an approved permit on a mobile device.> GN8.04 enter and submit a new permit application on a mobile device.> GN9 < shall provide a system with the capability to do mathematical calculations.> GN9.01 <The system will have the ability to add, subtract, multiply, and divide.> GN10 < shall provide the capability to populate data from central permit office forms.> GN10.01 collect and process data from central permit office forms, including but not be limited to: M-936-A M-936-B M-936-P M-936-RA M-937-C M-945-S> Confidential,2012 Page 15

16 GN10.02 pre-populate central permit office forms with data whenever possible.> GN10.03 <The system will reduce redundant data entry for central permit office forms.> Confidential,2012 Page 16

17 3.2 Permit Submission (PS) PS1 < shall provide the capability for an active customer with an account in good standing to submit a permit application.> PS1.01 select carrier address information for a permit application.> PS1.02 validate customer account is in active and unsuspended status prior to submitting a permit application.> This may be subject to enterprise security model determination PS2 < shall provide the capability to search existing permit applications.> search for a permit application by any combination of (but not limited to) the following: PS2.01 Application ID Permit number Account number Application status FEIN/SSN Issuing district Route origin county Route destination county Load serial ID Traversed state routes> PS2.02 identify the sort order returned by a permit application search.> limit a search for permit applications by a date range for: PS2.03 Application dates Move start Move end Issued dates> PS3 < shall provide the capability to clone an existing permit application.> PS3.01 clone a permit application.> Confidential,2012 Page 17

18 PS3.02 change the move start date to a future date on a cloned application.> PS3.03 clone applications with all bond permit information included.> PS3.04 clone spoke permits.> (DO) PS4 < shall provide the capability to create a new permit application.> PS4.01 request multiple permits with identical loads and routes from a single permit application.> PS4.02 identify the type of permit requested on a permit application.> create a new permit application by type including but not limited to: PS4.03 Single Trip Emergency Preliminary superload Final superload Annual > PS4.04 <The system will provide a permit wizard to determine the permit type required based on load dimensions.> Confidential,2012 Page 18

19 enter the permit application information including but not limited to: PS4.05 Anticipated move date Identify willingness to accept alternative route Maximum acceptable additional miles PA Turnpike approval number National Park Service approval number Willingness to accept a crawl speed restriction Permit delivery method (fax or ) Fax vendor Fax to number address Bond permit number for a state road within a county> enter emergency move information including but not limited to: PS4.06 Emergency type Emergency description Date occurred PSP contact information Emergency site information Location of emergency Justification of move> PS4.07 <The system will provide the ability for a business partner to enter searchable internal information without triggering a manual review including but not limited to the following: Invoice number Carrier job notes> PS4.08 request multiple permits with identical loads and routes from a single permit application.> PS4.09 manage Dual Lane transporters.> (CO) PS4.10 relate the permits associated with a Spoke permit.> (CO) Confidential,2012 Page 19

20 PS4.11 renew spoke permits.> (DO) PS4.12 create a regional permit.> PS5 < shall provide the capability to withdraw a permit application.> (DO) PS5.01 withdraw a permit application in submitted status.> PS5.02 withdraw and clone a permit application in submitted status.> PS5.03 <The system will provide notification to DO/CPO of a withdrawn application currently under manual review.> Requirements Session PS5.04 <The system will remove withdrawn applications from the workflow queue.> Requirements Session. PS6 < shall provide the capability for a business partner to enter a permit application via the internet.> PS6.01 save an in-process permit application as a draft.> PS6.02 delete an in-process permit application.> PS7 < shall provide the capability for business partners to enter load and vehicle information.> PS7.01 search load descriptions by make, model and description.> PS7.02 select a permit application from the load type search results.> PS7.03 save and select a load type and load dimensions as a favorite.> PS7.04 submit an automated request for load description update during the permit application process.> Confidential,2012 Page 20

21 PS7.05 create envelope loads based on load type and dimensions.> (CO) enter load information for a permit application including but limited to: PS7.06 Gross weight Legal weight Total length Total width Total height Load quantity Body width Load serial ID Vehicle length Vehicle width Vehicle height Vehicle weight Front overhang Rear overhang Guide rail serial number> PS7.07 calculate the sum of the axle weights for a permit application.> PS7.08 display an interactive axle spacing diagram within the application.> save and select vehicle information for a permit application from a list of favorites including but not limited to the following: PS7.09 Truck information Trailer Information Equipment type Registration number/vin State Number of axles US DOT number> Confidential,2012 Page 21

22 enter the following permit application data for each axle including but not limited to: PS7.10 Axle number Vehicle number Distance from previous axle Axle weight> enter the following permit application 936-AS data including but not limited to: PS7.11 Manufacturer rated axle capacity Center to center wheel spacing Number of tires on axle Tire width> PS7.12 update license plate information on a submitted permit application.> -Policy PS7.13 identify and record any parts removed or other physical difference in a load.> -D PS8 < shall provide the capability to prereview a permit application prior to submission.> (CO) PS8.01 perform data validation prior to permit application submission.> <The system will provide a pre-screening tool that will validate a permit request prior to submission including but not limited to: PS8.02 Restrictions Information on weight limits for roads and bridge heights Route review> (CO) PS8.03 <The system will display a list of reasons why a manual review is required.> PS9 < shall provide the capability for authorized department personnel to enter a permit application.> (DO) PS9.01 enter comments on a permit application.> Confidential,2012 Page 22

23 PS10 < shall provide the capability to limit fraud and abuse within the permit process.> (DO) PS10.01 limit fraud by comparing a permit application to a prior denied application.> (DO) PS11 < shall provide the capability to request a supplement for an approved permit.> PS11.01 attach supporting documents to a permit application.> PS11.03 complete and attach forms from within the application.> PS11.04 capture data and generate a smart form.> Confidential,2012 Page 23

24 3.3 Routing (RT) RT1 < shall provide the capability to manually route a load.> RT1.01 <The system will provide local road data to support routing.> RT1.02 <The system will provide common road names on the permit.> (CO), RT1.03 alter routes manually.> (CO) RT2 < shall provide the ability to generate a route.> RT2.01 generate a route based but not limited to the following: Beginning and ending street address State entry and exit Other mapped reference> (CO) RT2.02 return an alternate route.> RT3 < shall provide the capability to analyze the route on a permit application.> RT3.01 perform a stand-alone route analysis for a load/route combination without applying for a permit.> RT3.02 <The system will provide a method to review a single load/route and apply the approval across multiple permit requests.> RT3.03 <The system will determine if any date constraints need to be applied to a permit based on requested move date.> RT3.04 notify the carrier that the requested route traverses an urban area.> (CO) RT3.05 perform route analysis for Dual Lane transporters.> (CO) Confidential,2012 Page 24

25 RT3.06 RT3.07 <The system will analyze the requested route for the following to include but not limited to: All posted bridges Posted and bonded roads Temporary restrictions Individual bridge or roadway restrictions Turn restrictions Alternate routes> <The system will perform checks to determine if a load is overweight for bridge analysis including but not limited to steering axle check.> RT4 < shall provide the capability for pre-built and approved routes.> RT4.01 create and save pre-built routes.> (CO) RT4.02 <The system will automatically check for updates and restrictions in saved routes.> RT4.03 notify a permit holder and when an approved route s conditions change. > (DO) RT4.04 preapprove multiple movements over a specified route.> (DO) RT5 < shall provide the capability to build and display a route via a graphic map interface.> (DO) build a route via a graphic map interface that includes but is not limited to the following information: RT5.01 Ramp ID# Road connector information Identified detours Connector roads for creating routes>, RT5.02 <The system will provide a visual map that highlights road construction, has a zoom feature, and gives dates/restrictions on rollover.> Confidential,2012 Page 25

26 <The system will provide summarized construction information and allow the user to display details including but not limited to: RT5.03 Date Time State Route Number Road name Contractor contact information for roads under construction> Confidential,2012 Page 26

27 3.4 Permit Processing (PP) PP1 < shall provide the capability to perform an automated review on submitted permit application information.> PP1.01 perform an automated review on a submitted permit application.> PP1.02 perform a route analysis on a submitted permit application.> PP1.03 verify a permit application contains all required bond information for identified posted/bonded roads.> PP1.04 <The system will require a manual review for a permit application including but not limited to: Comments Route restrictions Bridge analysis Route crossing urbanized areas> (CO) PP1.05 identify pre-approved multiple movements over a specified route.> PP2 < shall provide the capability to auto-issue a permit application that passes a route analysis and system review.> PP2.01 calculate the fees associated with a permit.> PP3 < shall provide the capability to send a copy of an approved permit to the carrier by the selected mode.> PP3.01 <The system will provide notification to PSP when an emergency permit is issued. > <The system will provide notifications to all affected district Transportation Management Center (TMC) resource accounts when a Superload permit is issued.> PP3.02 <The system will include permit # on the notification subject line.> PSP Confidential,2012 Page 27

28 PP3.03 <The system will generate a permit including but not limited to: Application information Issuing office Carrier information Move begin and end date Permit number Permit date Permit fees Vehicle information Load information Weight breakdown Route information Counties traversed Permit restrictions Route restrictions Bridge restrictions Emergency information (if applicable) Removable parts Comments > PP3.04 provide drivable routes on a permit.> PP3.05 generate and print a tamperproof permit.> (CO) PP3.06 send a copy of an approved permit to the carrier via or fax.> PP3.07 send a paperless (electronic) permit.> PP3.08 <The system will provide the ability for a business partner to reprint an approved permit within the current application. > PP4 < shall provide the capability to auto-deny a permit application.> PP4.01 <The system will provide detailed information concerning denial reasons and application processing errors.> PP4.02 notify the submitter that a permit is denied.> PP4.03 identify the impacted section of roadway or bridge causing a denial in an automated notification.> Confidential,2012 Page 28

29 PP5 < shall provide the capability to review a submitted permit application.> Internal review will include all personnel. (i.e., CO, DO, bureaus, etc.) manage workflow to include but not be limited to the following: PP5.01 Assign a permit application for manual review Assign a permit application for review by multiple Districts Select a permit application for manual review Update a permit application based on a manual review. Manually approve a permit application Manually deny a permit application Manually assign a permit application for another District Office review> PP5.02 assign a review to the affected District Office(s) or District Office Bridge Engineer queue simultaneously.> (CO) PP5.03 <The system will identify permit applications that require a manual review and assign them to only the affected District(s).> (CO) PP5.04 <The system will prevent a required District re-review if unaffected by another District s change.> (DO) PP5.05 <The system will provide a method for routing comments to the affected District.> (DO) PP5.06 manually review a supplement request for an approved permit.> (DO) PP5.07 <The system will process all required reviews before sending approval or denial status notifications to the applicant.> (DO) PP5.08 <The system will display detailed review status for a permit under manual review.> Confidential,2012 Page 29

30 PP5.09 < The system will provide the ability to manage review assignments for multiple queues including but not limited to: District Offices Traffic Unit District Bridge Engineer Construction> (DO) PP5.11 <The system will include bridge simulation software for analysis and reviews, such as Live Load.> (DO) PP5.12 display for reference detailed engineering data for an internal bridge review including but not limited to ABAS data and movement comparison result.> Requirements review session PP5.13 < The system will provide the ability to autorefresh the review queue display.> (DO) PP6 < shall provide the capability to manually approve a permit application.> PP6.01 enter an approval based on the manual review of a permit application.> PP6.02 approve a permit application when all reviews have been completed.> PP6.03 notify the submitter of a manual review approval.> PP6.04 <The system will allow one entity (District) to view, process another Districts queue. > (CO) PP7 < shall provide the capability to manually approve a permit supplement.> PP7.01 notify the submitter of a supplement approval.> PP8 < shall provide the capability to manually deny a permit application.> PP8.01 <The system will provide detailed information concerning denial reasons and application processing errors.> PP8.02 deny a permit application when all reviews have been completed.> Confidential,2012 Page 30

31 PP8.03 PP8.04 PP9 PP9.01 <The system will display denial information from all affected Districts simultaneously.> notify the submitter of a manual review denial.> < shall provide the capability to manually deny a permit supplement.> notify the submitter of a permit supplement denial.> Confidential,2012 Page 31

32 3.5 Reporting (RP) RP1 < shall provide the capability for end-user reporting.> <The system will provide the following reports for District users including but not limited to: RP1.01 Number of permits processed Permits under investigation Detailed permitting and routing Common components to identify fraudulent or duplicate entries> RP2 < shall provide a consistent source for reporting data.> RP2.01 <The system will produce consistent and accurate data across all reports.> (CO) RP2.02 produce pre-defined reports.> (CO) < The system will provide the following reports for Central Office users including but not limited to: RP2.03 Year-end and monthly reporting Volume of travel over a road segment Projected travel over a road segment Weekly and Monthly Performance metrics (Goal: data is ready so that reports can be produced on the first business day of the month)> (CO) RP2.04 run reports on an as needed basis.> (CO) RP2.05 create an ad-hoc report.> (CO) RP2.06 <The system will provide a data dictionary to support ad-hoc reporting.> Requirements sessions Confidential,2012 Page 32

33 3.6 Accounting (AC) AC1 < shall provide the capability to collect payment for all permit transactions.> (CO) AC1.01 collect permit fees from an escrow account.> (CO) AC1.02 charge permit fees with an invoice.> (CO) AC1.03 <The system will have the ability to process direct payments.> (CO) AC1.04 <The system will have the ability to accept credit card payments.> (CO) AC1.05 track permit fees charged to a customer account.> (CO) AC2 < shall provide the capability to process all permit billing functions.> (CO) (Note: APRAS is not completely connected to SAP, APRAS currently prepares approximately 200 statements per month) AC2.01 <The system will provide a method to process refunds for unused permits.> (CO) AC2.02 suspend applicants for reasons to include but not limited to the following: Non-payment Fraud Violations> (CO) AC2.03 track suspensions for non-payment.> (CO) Confidential,2012 Page 33

34 4. Detailed Change Tracking Log Below is a document history log which details each change that was made to this document, the specific location of the change, which team member made the change, and the date of the change. The table lists the specific details of the changes made to this document and the updated version number. # Section Page Change Date Author Change Description Version Confidential,2012 Page 34

35 5. Appendix A Business Goals and Objectives Reference Goals No. 1. < Document requirements that support a solution to improve the user experience in the processing of Special Hauling Permits for both and its Business Partners.> 2. <Document requirements that support a solution that increases the efficiencies associated with the processing of Special Hauling Permits for both and its Business Partners.> Objectives 1) <Document the needs and requirements for a Special Hauling Permit Application solution that provides a customer interface that utilizes current technologies and formats.> 2) <Document the needs and requirements for a Special Hauling Permit Application solution that provides a customer interface that can be easily modified based upon changing business needs.> 3) <Identify a solution that provides mapping functionality to generate approved application routes.> 1) < Identify a solution for Special Hauling Permit Application Processing that provides more robust user prompts, instructions and informational messages.> 2) < Identify a solution that provides detailed information concerning denial reasons and application processing errors.> 3) <Identify a solution that will reduce the overall number of manually reviewed applications by increasing the rate of system approved or denied applications.> 4) <Identify a solution that provides customers with a monthly billing process that includes the ability for electronic payment.> 5) <Identify a solution that provides robust, user-friendly reporting options.> 6) <Identify a solution that includes either detailed documentation or the ability to extract user documentation/business rules into a user-friendly format.> 7) <Identify a solution that provides a broad range of search capabilities to identify applications.> Confidential,2012 Page 35