EIS_RFP_Section_E_Final.docx

Enterprise Infrastructure Solutions (EIS) Request for Proposals

Section E Inspection and Acceptance

Issued by:

General Services Administration Office of Integrated Technology Services 1800 F St NW Washington, DC 20405

October 2015

Table of Contents

General Services Administration Network Services 2020 Enterprise Infrastructure Solutions

EIS RFP #QTA0015THA3003 Enterprise Infrastructure Solutions EIS RFP #QTA0015THA3003 53 Enterprise Infrastructure Solutions Appendix A Appendix B Appendix C Appendix D Appendix E

Introduction This section describes the inspection and acceptance plan for the following:

· Contractor’s Business Support Systems (BSS)

· EIS Services FAR 52.252-2 Clauses Incorporated by Reference (FEB 1998) This contract incorporates one or more FAR clauses by reference, with the same force and effect as if they were given in full text. Upon request, the Contracting Officer (CO) will make their full text available. The full text of a clause may be accessed electronically at this address: www.acquisition.gov/far.

The clauses in Table E.1.1.1 apply at the contract and order levels, as applicable, depending upon the contract type of the order, or as specifically referenced in the applicable order.

Clauses Incorporated by Reference Table

Test Methodology The contractor shall follow the verification and acceptance test methodology described in this section in developing the verification test plan(s) for:

· Contractor’s Business Support Systems (BSS)

· EIS Services Business Support Systems Verification Testing The contractor shall provide a draft BSS Verification Test Plan (BSS Test Plan) with its proposal and a final BSS Test Plan 30 days after notice to proceed. This plan shall comply with the test methodology for BSS defined in Sections E.2.1.1 – E.2.1.5. The government reserves 21 days from the date of receipt of final plan to accept or reject the plan. If it is rejected, the contractor will be given the opportunity to update the plan based on government comments.

Based on GSA Conexus readiness and other factors, the government may, at its option, offer the opportunity for contractors to perform preliminary testing prior to award, but after submission of proposals. If this opportunity is offered, it will be offered to all contractors who submit a proposal, pending only the contractor’s demonstration of primary security features such as anti-virus protection. Any such preliminary testing shall not replace formal testing post-award. The government offers no guarantees that the GSA Conexus configuration offered as the preliminary system will be identical to the final system used in post-award formal testing. If the government offers such preliminary testing, the government will issue terms and conditions for such testing which the contractor must accept prior to accessing the test system.

The contractor shall provide updates to the BSS Test Plan within 14 days of receipt of government comments. The government reserves 14 days after receipt of the updated plan to accept or reject it. If necessary to gain approval, the contractor may repeat this process.

See section G.2.3 BSS Final Contract Acceptance for final acceptance requirement.

Scope The contractor shall meet the following Inspection and Acceptance requirements:

BSS testing shall verify that all BSS functional, regression and security requirements have been successfully met.

BSS testing shall be performed for all management and operation functions supporting Ordering, Billing, Inventory Management, Disputes, SLA Management and Trouble Ticketing processes described in Section G and Section J.2.

Security testing shall be based on the requirements described in Section G.5.6 BSS Security Requirements. The security requirements acceptance shall be based on:

· Assessment and Authorization (A&A)

· FedRAMP certification (if applicable) BSS testing shall include multiple test cases that are defined in Section E.2.1.3 Test Cases.

BSS testing shall include use cases for quality, utility and customer access features.

The contractor shall allow government representative(s) to observe all or any part of the verification testing.

· If the government so requests, the contractor shall perform tests to ensure continued compliance each time a new service is offered or the contractor modifies features/functionality of the BSS that affect the functional requirements described in Section G and Section J.2.

· If the government requests this retest, the contractor shall provide a BSS Verification Test Results report, including analysis, within seven (7) days after performance of the tests. The government reserves 14 days to accept or reject the test results, in part or in whole. If the government rejects the test results the contractor shall retest until such time the results are acceptable to the government.

The contractor shall perform BSS verification testing according to the accepted BSS Test Plan at a mutually acceptable date with the government.

BSS Test Scenarios Testing Prerequisites Prior to initiating BSS testing, the contractor shall:

Provide written notice to the government that the contractor’s BSS has passed its internal testing and is ready to begin BSS interface testing with GSA Conexus.

Provide a finalized BSS Test Plan that is accepted by GSA.

The purpose of the verification and acceptance testing is to ensure that the contractor’s BSS meets requirements in Section G and Section J.2. The contractor shall support BSS security and functional testing as defined in Section G.5.6 BSS Security Requirements and Section G.5.5.1 BSS Testing.

Test Scenarios The following table contains a high-level list of BSS Test Scenarios for which the contractor’s BSS must pass the defined acceptance criteria. The contractor shall address the test scenarios based on the functional requirements defined in the relevant portions of Section G and/or Section J.2 (see the “RFP References” column for references).

The scenarios shall address relevant data exchange mechanisms and validation of data exchanged. Each Test Scenario is associated with one or more Test Cases defined in Section E.2.1.3.

· J.2.9 Exchange structured data using the defined direct data exchange methods:

· XML via secure web services

· Pipe, “|”, delimited table via SFTP The contractor shall demonstrate bidirectional exchange of defined data structure that meets the interface specifications as defined in Section G.5.3.2 and Section J.2.9.

· J.2.3 The contractor’s BSS manages the following as specified in Section J.2.3:

· Accept System Reference Data

· Accept and Reply to Central Billed Agency Setup

· Provide Direct Billed Agency Setup The contractor shall demonstrate successful TO Data Management initial setup and updates.

· J.2.4 The contractor’s BSS manages the processing of orders and generation of required acknowledgments and notifications. Order types include:

· New service for each of the services specified in Section C.2, Technical Requirements, that are included in the awardee’s contract

· Service Moves

· Service Disconnects

· Service Feature Changes

· Telecommunications Service Priority (TSP)

· Auto-sold CLINs

· Bulk Orders The contractor shall demonstrate that an authorized government user can place an order using the methods specified in Section J.2.4 and the order populates the fields in the contractor’s ordering system in a way that meets the requirements in Sections G.3, G.5 and J.2.

Using the direct data exchange method defined in Section J.2.4, the contractor shall demonstrate that its ordering system can provide all required CDRLs including:

1) Service Order Acknowledgement

2) Service Order Rejection Notice

3) Service Order Confirmation

4) Firm Order Commitment Notice

5) Service Order Completion Notice

· J.2.4 The contractor’s BSS handles order supplements/updates that impact other, in-progress orders:

· Cancel orders

· Service Feature Changes

· Location changes

· Changes to Customer Want Date

· Changes to administrative data

The contractor shall demonstrate that an authorized government user can place a change or cancel order using the methods specified in Section J.2.4 and the order populates the fields in the contractor’s ordering system in a way that meets the requirements in Sections G.3, G.5 and J.2.

Using the direct data exchange method defined in Section J.2.4, the contractor shall demonstrate that its ordering system can provide all required CDRLs including:

1) Service Order Acknowledgement

2) Service Order Rejection Notice

3) Service Order Confirmation

4) Firm Order Commitment Notice

5) Service Order Completion Notice

· J.2.4 The contractor’s BSS handles orders for administrative changes to the records for previously provisioned services as described in G.3

The contractor shall demonstrate that an authorized government user can place an administrative change order using the methods specified in Section J.2.4 and the order populates the fields in the contractor’s ordering system in a way that meets the requirements in Sections G.3, G.5 and J.2.

Using the direct data exchange method defined in Section J.2.4, the contractor shall demonstrate that its ordering system can provide all required CDRLs including: Service Order Administrative Change

· J.2.4.2.4

Using the direct data exchange method defined in Section J.2.4, the contractor shall demonstrate that its ordering system can provide all required CDRLs including:

1) Service Order Acknowledgement

2) Service Order Completion Notice

· J.2.5

· J.2.6

· J.2.7

· J.2.10 The contractor’s BSS properly manages inventory and billing:

· Generates the inventory of services delivered by the contractor

· Produces output that is consistent with order and billing details

· Generates the detailed billing in accordance with the Billing Invoice (BI) CDRL

· Properly handles usage-based billing

· Calculates billing based on the contractor’s awarded pricing

· Correctly calculates the AGF due to GSA and produces the required AGF CDRLs

· Provides accurate calculation of rounding and proration related to Billing, Taxes, Fees and Surcharges The contractor shall demonstrate that its service inventory management system maintains a complete and accurate inventory of EIS service orders in a way that meets the requirements in G.7 and G.5 and Section J.2 CDIP and is verified and accepted by GSA.

The contractor shall demonstrate that the output of its billing data elements is consistent with the orders entered into its ordering system and that the billing data elements meet the requirements in Sections G.3, G.5 and J.2.

Using the direct data exchange method defined in Sections J.2.5-J.2.7, the contractor shall demonstrate that its ordering system can provide all required CDRLs including:

1) Billing Invoice

2) Billing Adjustment

3) Tax Detail

4) AGF Detail

5) AGF Electronic Funds Transfer Report

6) Inventory Reconciliation

· J.2.6 The contractor’s BSS properly manages all dispute types with appropriate handling for:

· Billing disputes

· Inventory disputes

· SLA disputes

· Dispute tracking and reporting The contractor shall demonstrate that its BSS can accept and issue disputes as well as tracking them to resolution.

Using the direct data exchange method defined in Sections J.2.5-J.2.7, the contractor shall demonstrate that its ordering system can provide all required CDRLs including:

1) Dispute

2) Dispute Report

· J.2.8 The contractor’s BSS properly manages SLA Management:

· SLA Reporting

· SLA Credit Request handling and response The contractor shall demonstrate that its BSS successfully tracks SLAs with associated KPIs as well as reporting SLA performance and providing sufficient information to response to SLA Credit Requests.

Using the direct data exchange method defined in Sections J.2.5-J.2.7, the contractor shall demonstrate that its ordering system can provide all required CDRLs including:

1) SLA Report

2) SLA Credit Request Response

· Monthly Billing Information Memorandum

· Trouble Management Incident Performance Report

· Trouble Management Performance Summary Report The contractor shall demonstrate, via sample reports, that the open-format reports specified are sufficiently detailed and clear so as to meet the government’s requirements.

NOTE: Applies only to testing conducted as part of system changes, not initial BSS development.

The contractor shall demonstrate that its BSS meets regression testing.

The BSS test plan shall include regression testing; however, actual regression testing will not be part of initial test and acceptance.

BSS Test Cases The contractor shall accept, incorporate into the BSS Test Plan, and successfully execute test cases provided for each of the test scenarios above.

The contractor shall accept the following test conditions:

· No testing between the contractor and GSA shall occur until both the contractor’s BSS and GSA Conexus have passed unit testing.

· All testing to be performed on the actual system to be used in delivering service (i.e. special purpose “test systems” shall not be used).

· Unless otherwise specified, all data transfers are to use the mechanism specified in Section J.2 for that data set.

The contractor shall use GSA provided test data for all BSS verification testing unless specified otherwise:

· This data shall be used for testing purposes only.

· No customer “live” data shall be used for testing.

· This data shall be a realistic simulation of actual customer data.

· The test data shall include, in some tests, intentional errors intended to test the contractor’s BSS error handling.

BSS testing shall follow a tiered approach:

· The contractor shall accept multiple test cases for the test scenarios defined in Section E.2.1.2.

· The contractor shall accept, incorporate into the BSS Test Plan, and successfully execute each test case with one or more test data sets.

· In providing test data sets, GSA will group them into Test Subcases:

· Each Test Subcase shall contain data sets intended to test a specific “real world” test case (e.g. a complete and accurate disconnect order)

· Each test subcase shall include at least two complete test data sets BSS functional testing acceptance:

· The contractor’s BSS shall not have completed functional testing until all BSS Test Scenarios (Section E.2.1.2) are passed.

· A test scenario shall not be considered passed until the contractor’s BSS properly handles each associated test case.

· A test case shall not be considered passed until the contractor’s BSS properly handles each associated subcase twice in succession using different data sets.

· A subcase shall not be considered passed until the contractor’s BSS properly handles the data sets following the prescribed actions with no errors or warnings.

BSS security testing acceptance is defined in Section G.5.6 and associated references.

The individual test cases are defined in the tables in the subsections below. Each test case table includes the following headings:

Test Scenario: The associated test scenario from Section E.2.1.2.

Test Case ID: Identification number for the test case.

Test Case Description: Brief title of the test case.

Requirements Reference(s): Where the functional requirements that are being tested can be found.

Prerequisites: Actions that must be completed prior to implementing the test case (in addition to the general prerequisites for all testing).

Government Input(s): Data the government will provide as input to the test case.

Expected BSS Output(s): Expected data or actions from the contractor’s BSS.

Data Set Description: Brief description of the data sets the government intends to provide as part of testing.

Acceptance Criteria: Factors to be checked prior to acceptance of the test results. The table below defines the terms used:

· CDRL contains the required information

· CDRL is clear and readily understood

BSS-TS01: Direct Data Exchange BSS-TS01-01: XML over Secure Web Services

· J.2.9

· Listed as using web services as the transfer mechanism in Section J.2

· Includes data derived from the government input

· Correct technical aspects

· One government data set listed as using web services as the transfer mechanism in Section J.2

BSS-TS01-02: PSV over SFTP

· J.2.9

· Listed as using SFTP as the transfer mechanism in Section J.2

· Includes data derived from the government input

· Correct technical aspects

· One government data set listed as using SFTP as the transfer mechanism in Section J.2

BSS-TS01-03: Error Handling: XML over Secure Web Services

· J.2.9

· No partial import

· One government data set listed as using web services as the transfer mechanism in Section J.2

· One or more XML formatting errors (e.g. missing delimiters)

BSS-TS01-04: Error Handling: PSV over SFTP

· J.2.9

· No partial import

· One government data set listed as using SFTP as the transfer mechanism in Section J.2

· One or more formatting errors (e.g. missing delimiters)

BSS-TS02: Task Order Data Management BSS-TS02-01: Direct Billing Account Setup

· J.2.2

· J.2.3

· Task order associated data as defined in Section J.2.3

· System Reference data as defined in Section J.2.3

· Accurate data based on inputs

· Correct technical aspects

· Sample TO controlled data transferred in the form of a sample TO

· Sample TO associated data transferred in free format (not previously defined) unless the contractor specifies in their proposal that customer registration is to be submitted via their web interface and that interface collects all of the required data

· Sample System Reference data transferred using the mechanism specified in Section J.2

BSS-TS02-02: Central Billing Accounts

· J.2.2

· J.2.3

· Task order associated data as defined in Section J.2.3

· System Reference data as defined in Section J.2.3

· Central Billed Agency Setup (CBAS)

· Accurate data based on inputs

· Correct technical aspects

· Sample TO controlled data transferred in the form of a sample TO

· Sample TO associated data transferred in free format (not previously defined) unless the contractor specifies in their proposal that customer registration is to be submitted via their web interface and that interface collects all of the required data

· Sample System Reference data transferred using the mechanism specified in Section J.2

· Sample CBAS

BSS-TS03: Role Based Access Control BSS-TS03-01: Authorized User Access Verification

· J.2.3

· Sign into BSS

· Access BSS areas to which they are an authorized user

· Exercise the full range of functionality (read/write) permitted for their role

· Access to BSS

· Access BSS areas as authorized

· Exercise assigned functionality

· No security errors displayed

· Role to be tested

· Functionality to be tested

BSS-TS03-02: Unauthorized User Access Denial Verification

· J.2.3.

· Sign into BSS

· Access BSS areas to which they are not an authorized user

· Exercise functionality (read/write) not permitted for their role

· Access to BSS

· Access to specific BSS areas

· Access to specific functionality

· User is shown security error message

· Appropriate errors are displayed

· Role to be tested (may be specified as none if the set is intended to show denial of unauthorized users)

· Functionality to be tested

BSS-TS04: Service Ordering BSS-TS04-01: New Order via Web Interface

· G.5.3.1

· J.2.4

· Service Order Acknowledgment (SOA)

· Service Order Confirmation (SOC)

· Firm Order Commitment Notice (FOCN)

· Service Order Completion Notification (SOCN)

· Accurate data based on inputs

· Correct technical aspects

· A complete SO for one or more services listed in Section C.2 of the contract

· SO to be entered into the contactor’s BSS via the contractor’s web interface as described in Section G.5.3.1

BSS-TS04-02: New Order via Email

· G.5.3.1

· J.2.4

· Service Order Acknowledgment (SOA)

· Service Order Confirmation (SOC)

· Firm Order Commitment Notice (FOCN)

· Service Order Completion Notification (SOCN)

· Accurate data based on inputs

· Correct technical aspects

· SO submitted via a means listed in J.2.4 other than the contractor’s web interface

BSS-TS04-03: Disconnect Order

· J.2.4

· J.2.10.1.1.4.2

· Previously provisioned circuit or service element entered into the contractor BSS

· A circuit or service element (CLIN)

· A feature of a circuit or service element

· Service Order Acknowledgment (SOA)

· Service Order Confirmation (SOC)

· Firm Order Commitment Notice (FOCN) if required based on the requirements described in Section J.2.4

· Service Order Completion Notification (SOCN)

· Accurate data based on inputs

· Correct technical aspects

· A complete SO for the disconnect of a circuit or service element or a feature of a circuit or service element as described in Section G.3 and Section J.2.10.1.1.4.2

BSS-TS04-04: Feature Addition Order

· J.2.4

· J.2.10.1.1.4.2

· Previously provisioned circuit or service element entered into the contractor BSS

· Service Order Acknowledgment (SOA)

· Service Order Confirmation (SOC)

· Firm Order Commitment Notice (FOCN)

· Service Order Completion Notification (SOCN)

· Accurate data based on inputs

· Correct technical aspects

· A complete SO for the addition of a feature to a circuit or service element as described in Section G.3 and Section J.2.10.1.1.4.2

BSS-TS04-05: Move Order

· J.2.4

· J.2.10.1.1.4.2

· Previously provisioned circuit or service element entered into the contractor BSS

· One SO for the disconnect of the circuit or service element at the old location

· Second SO for the installation of the identical circuit or service element at the new location

· Service Order Acknowledgment (SOA)

· Service Order Confirmation (SOC)

· Firm Order Commitment Notice (FOCN)

· Service Order Completion Notification (SOCN)

· Accurate data based on inputs

· Correct technical aspects

· A pair of complete SOs for the move of a circuit or service element from one valid location to another as described in Section G.3 and Section J.2.10.1.1.4.2

· SO for the disconnect from the old location

· SO for the installation of the identical service at the new location

BSS-TS04-06: TSP Order

· J.2.4

· Service Order Acknowledgment (SOA)

· Service Order Confirmation (SOC)

· Firm Order Commitment Notice (FOCN)

· Service Order Completion Notification (SOCN)

· Accurate data based on inputs

· Correct technical aspects

· A complete SO with a TSP code for one or more services listed in Section C.2 of the contract

BSS-TS04-07: Auto-Sold CLINs

· J.2.4

· Service Order Acknowledgment (SOA)

· Service Order Confirmation (SOC)

· Firm Order Commitment Notice (FOCN)

· Service Order Completion Notification (SOCN)

· Accurate data based on inputs

· Correct technical aspects

· A complete SO that includes Auto-Sold CLINs for one or more services listed in Section C.2 of the contract

BSS-TS04-08: Task Order Unique CLINs (TUCs)

· J.2.4

· TO Data defines one or more TUCs

· Account Management data loaded into contractor BSS

· Service Order Acknowledgment (SOA)

· Service Order Confirmation (SOC)

· Firm Order Commitment Notice (FOCN)

· Service Order Completion Notification (SOCN)

· Accurate data based on inputs

· Correct technical aspects

· A complete SO containing Task Order Unique CLINs (TUCs) for one or more services listed in Section C.2 of the contract

Reserved BSS-TS04-10: Bulk Orders

· J.2.4

· Service Order Acknowledgment (SOA)

· Service Order Confirmation (SOC)

· Firm Order Commitment Notice (FOCN)

· Service Order Completion Notification (SOCN)

· Accurate data based on inputs

· Correct technical aspects

· A SO including at least 20 line items for services listed in Section C.2 of the contract

· SO data provided via a delimited text file or MS Excel file

BSS-TS04-11: Error Checking: Missing Info

· J.2.4

· Service Order Acknowledgment (SOA)

· Service Order Rejection Notice (SORN)

· Accurate data based on inputs

· Correct technical aspects

· SO missing one or more required data elements for one or more services listed in Section C.2 of the contract

BSS-TS04-12: Error Checking: Invalid Info

· J.2.4

· Service Order Acknowledgment (SOA)

· Service Order Rejection Notice (SORN)

· Accurate data based on inputs

· Correct technical aspects

· SO orders with one or more invalid data information for one or more services listed in Section C.2 of the contract

· Invalid data can include improperly formatted data or data that is inconsistent with the TO or Account Management data

BSS-TS05: Supplements to In-Progress Orders BSS-TS05-01: Cancel Orders

· J.2.4

· J.2.10.1.1.4.3

· Service Order (SO) for a cancellation of the previous order with all required data elements as described in Section J.2.4 issued prior to completion of the previous order

· Service Order Acknowledgment (SOA)

· Updates to Service Order Confirmation (SOC) if required

· Updates to Firm Order Commitment Notice (FOCN) if required

· Service Order Completion Notification (SOCN)

· Accurate data based on inputs

· Correct technical aspects

· A complete SO for one or more services listed in Section C.2 of the contract

· A second SO canceling the first Service Order as defined in Section J.2.10.1.1.4.3

· The Cancel Order may be issued before or after the deadline described in Section G.3

BSS-TS05-02: Service Feature Change

· J.2.4

· J.2.10.1.1.4.3

· Service Order (SO) for a service feature change to the previous order with all required data elements as described in Section J.2.4 issued prior to completion to previous order

· Service Order Acknowledgment (SOA)

· Updates to Service Order Confirmation (SOC) if required

· Updates to Firm Order Commitment Notice (FOCN) if required

· Service Order Completion Notification (SOCN)

· Accurate data based on inputs

· Correct technical aspects

· A second SO describing a service feature change to the first Service Order as defined in Section J.2.10.1.1.4.3

BSS-TS05-03: Location Change

· J.2.4

· J.2.10.1.1.4.3

· Service Order (SO) for a location change to the previous order with all required data elements as described in Section J.2.4 issued prior to completion to previous order

· Service Order Acknowledgment (SOA)

· Updates to Service Order Confirmation (SOC) if required

· Updates to Firm Order Commitment Notice (FOCN) if required

· Service Order Completion Notification (SOCN)

· Accurate data based on inputs

· Correct technical aspects

· A second SO describing a location change to the first Service Order as defined in Section J.2.10.1.1.4.3

BSS-TS05-04: Change to Customer Want Date

· J.2.4

· J.2.10.1.1.4.3

· Service Order (SO) for a change to the Customer Want Date for the previous order with all required data elements as described in Section J.2.4 issued prior to completion of the previous order

· Service Order Acknowledgment (SOA)

· Updates to Service Order Confirmation (SOC) if required

· Updates to Firm Order Commitment Notice (FOCN) if required

· Service Order Completion Notification (SOCN)

· Accurate data based on inputs

· Correct technical aspects

· A complete SO for one or more services listed in Section C.2 of the contract

· A second SO describing a change to the Customer Want Date for the first Service Order as defined in Section J.2.10.1.1.4.3

· The Customer Want Date Change Order may be issued before or after the deadline described in Section G.3

BSS-TS05-05: Change to Administrative Data

· J.2.4

· J.2.10.1.1.4.3

· Service Order (SO) for a change to the administrative data for the previous order with all required data elements as described in Section J.2.4 issued prior to completion of the previous order

· Service Order Acknowledgment (SOA)

· Updates to Service Order Confirmation (SOC) if required

· Updates to Firm Order Commitment Notice (FOCN) if required

· Service Order Completion Notification (SOCN)

· Accurate data based on inputs

· Correct technical aspects

· A second SO describing a change to the administrative data for the first Service Order as defined in Section J.2.10.1.1.4.3

BSS-TS06: Administrative Change Orders BSS-TS06-01: Administrative Change Order

· J.2.4

· One or more previously provisioned orders

· Service Order Administrative Change (SOAC)

· Accurate data based on inputs

· Correct technical aspects

· A complete administrative change order for a change to the administrative data for a previously provisioned service as described in Section G.3

BSS-TS07: Rapid Provisioning & Self-Provisioning Orders BSS-TS07-01: Rapid Provisioning Orders

· G.5.3.1

· J.2.4

· Service Order Acknowledgment (SOA) if provisioning requires more than 24 hours

· Service Order Completion Notification (SOCN)

· Accurate data based on inputs

· Correct technical aspects

· A complete SO for one or more services subject to rapid provisioning as defined in Section G.3

BSS-TS07-02: Self-Provisioning Orders

· G.5.3.2

· J.2.4

· Subject to rapid provisioning as defined in Section G.3

· Available for self-provisioning as defined in Section G.3 and Section C.2

· Service Order Acknowledgment (SOA) if provisioning requires more than 24 hours

· Service Order Completion Notification (SOCN)

· Accurate data based on inputs

· Correct technical aspects

· Service Order (SO) with all required data elements as described in Section J.2.4 for one or more services that are subject to rapid provisioning as defined in Section G.3 and that are available for self-provisioning as defined in Section G.3 and Section C.2

BSS-TS07-03: Self-Provisioning Orders: Error Checking

· G.5.3.2

· J.2.4

· Populated via Contractors Portal with one or more missing or invalid data elements as described in Section J.2.4

· Service Order Rejection Notice (SORN)

· User is shown error message indicating failure

· Accurate data based on inputs

· Correct technical aspects

· Appropriate errors are displayed

· Service Order (SO) with all required data elements as described in Section J.2.4 for one or more services that are subject to rapid provisioning as defined in Section G.3 and that are available for self-provisioning as defined in Section G.3 and Section C.2

· SO to be provided via Contractors Portal

BSS-TS08: Inventory and Billing BSS-TS08-01: Inventory Reconciliation

· J.2.7

· One or more previously provisioned orders

· Accurate data based on inputs

· Correct technical aspects

BSS-TS08-02: Billing