Guidelines and Procedures in the Acceptance of Outsourced and In-house Developed Application System(s)

February 19, 1999 REVENUE MEMORANDUM ORDER NO. 22-99 TO : All Internal Revenue Officials and Employees Concerned SUBJECT : Guidelines and Procedures in the Acceptance of Outsourced and In-house Developed Application System(s) I. BACKGROUND The Systems Standard and Technology Management Division (SSTMD) of the Information Planning and Quality Service (IPQS) shall be responsible for the acceptance of Outsourced and In-house Developed Applications of the Bureau. In order to ensure conformance with industry-accepted technology, the SSTMD shall establish the criteria and guidelines to standardize the acceptance of application systems, whether outsourced or developed in-house. II. OBJECTIVES This order is issued to: 1. Set the guidelines and procedures in the acceptance of outsourced and in-house developed applications. 2. Ensure that outsourced and in-house developed applications meet the requirements identified in the contract and conform to existing acceptable standards and acceptance criteria specified by the Bureau. 3. Define the roles and responsibilities of designated personnel that shall be responsible for the acceptance and signing of the Acceptance Certificate/s of the said application system(s). III. DEFINITION OF TERMS 1. Application Systems a program or group of programs designed for a particular functionality. 2. Outsourced Applications : Third party developed applications developed for a particular function or requirement for the Bureau. Packaged (off-the-shelf) pre-designed application(s), whether customizable or non-customizable. Upgrades new-version releases of an existing packaged application(s) and other system tools. 3. In-house Developed Applications all applications that shall be developed by the Bureau. 4. Acceptance Advice a document, signed by the ff: Reviewers, Expert Users and Chief-SSTMD that states that a product meet the relevant acceptance criteria and should be accepted. 5. Rejection Advice a document, signed by the ff: Reviewers, Expert Users and Chief-SSTMD that states that a product does not meet the relevant acceptance criteria and should be rejected. llcd 6. Acceptance Certificate a document, signed by the ff: ACIR-ISDS, ACIR-IPQS, System Owner and Chief-SSTMD that states that a product conforms to relevant acceptance criteria and is officially accepted. IV. ROLES AND RESPONSIBILITIES A. Outsourced Applications 1. System Owner shall: a. Negotiate with third-party counterpart to resolve disputes elevated by the Project Lead. b. Identify expert users that will work hand-in-hand with the reviewer regarding functionality. c. Sign Acceptance Certificate. 2. Project Lead , ISOS/ISDS shall: a. Provide project work plan. b. Notify the reviewer and provide him/her with a suitable working environment. c. Provide the necessary documentation (e.g., System Definitions, Technical and Functional Specifications Reports, Test Conditions, Test Data, etc.) d. Coordinate with vendors and SSTMD to resolve all issues raised. e. Submit regular status report(s) to concerned Service Head. f. Coordinate with vendor on the conduct of training for end users of the application system being developed. g. Oversee the preparation, routing and distribution of certificates. h. Sign Acceptance Certificate. 3. Division Chief , SSTMD shall: a. Review the acceptance work plan submitted by the reviewer. b. Supervise the conduct of acceptance testing. c. Monitor the status of issues raised and ensure that they are addressed properly. d. Coordinate with the Project Lead, ISOS/ISDS and the vendor regarding issues raised. e. Sign Acceptance/Rejection advice. 4. Expert Users shall: a. Perform acceptance testing on the functional aspects of the application being tested. b. Log all issues found during the acceptance testing. c. Coordinate with the reviewer regarding acceptance testing. d. Sign Acceptance/Rejection Advice. 5. Reviewer , SSTMD shall: a. Prepare and submit acceptance test work plan to the Division Chief, SSTMD. b. Perform technical acceptance testing. c. Log all issues found during acceptance testing. d. Monitor the status of issues raised and ensure that they are properly resolved. e. Prepare Acceptance/Rejection Advice/Certificate. f. Sign Acceptance/Rejection Advice. B. In-house Developed Applications 1. System Owner shall: a. Resolve disputes between SSTMD and Development Team elevated by the Project Lead. b. Identify expert users that will work hand-in-hand with the reviewer regarding functionality. c. Sign Acceptance Certificate. 2. Project Lead shall: a. Provide project work plan. b. Provide the necessary documentation (e.g., System Definitions, Technical and Functional Specifications Reports, Test Conditions, Test Data, etc.) c. Oversee the acceptance procedure of a specific application system being developed. d. Oversee the preparation, routing and distribution of certificates. cdll e. Coordinate with the Training Division on the conduct of training for the users of the application system being developed. f. Sign Acceptance Certificate. 3. Division Chief , SSTMD shall: a. Review the acceptance work plan submitted by the reviewer. b. Supervise the conduct of acceptance testing. c. Monitor the status of issues raised and ensure that they are addressed properly. d. Coordinate with the Project Lead, ISOS/ISDS and the vendor regarding issues raised. e. Sign Acceptance/Rejection Advice. 4. Expert Users shall: a. Perform acceptance testing on the functional aspects of the application being tested. b. Log all issues found during acceptance testing. c. Coordinate with the reviewer regarding acceptance testing. d. Sign Acceptance/Rejection Advice. 5. Reviewer , SSTMD shall: a. Prepare and submit acceptance test work plan to the Division Chief, SSTMD. b. Perform technical acceptance testing. c. Log all issues raised during acceptance testing. d. Monitor the status of issues raised and ensure that they are resolved properly. e. Prepare Acceptance/Rejection Advice/Certificate. f. Sign Acceptance/Rejection Advice. V. GUIDELINES A. Outsourced Applications 1. Acceptance of third party developed applications shall cover the following development phases: a. Functional Specifications Report (FSR) b. Technical Specifications Report (TSR) c. Detailed Design (DD) d. Programming (PROG) e. System Test (SYSTEST) 2. Packaged Applications and Upgrades shall cover System Test and review of necessary documentation (i.e., FSR, TSR, User's Manual, Test Conditions) 3. The Evaluation Criteria Checklist for a particular development phase (Attachment A) shall be the reviewer's guide in acceptance testing. 4. The latest version of Technical, Data and Documentation Standards shall be applied on Oracle or SQL-based applications. 5. Completeness checking for system documentation shall be guided by the System Documentation Standards for Outsourced Applications (Attachment B). 6. Issues raised shall be classified as Major or Minor using the Severity Matrix (Attachment C) and shall be logged using the Discrepancy Log Sheet (Attachment D). 7. Logged issues shall be addressed within seven (7) working days upon submission. 8. The Project Lead shall notify the reviewer of all resolved issues. Re-testing shall be completed within seven (7) working days upon receipt of notice. 9. All major and minor issues raised during the course of the acceptance testing shall be resolved before a particular phase can be signed off. However, if only minor issues are left, a product can still be signed off; provided said minor issues are listed in the Conditions List (Attachment F) and attached with the Product Acceptance Certificate (Attachment E). These minor issues shall be elevated as major issues if they are kept unresolved in the next phase. 10. Sign off of a particular development phase shall be supported by a signed Product Acceptance Certificate together with the following attachments: a. Product Acceptance Advice (Attachment G) b. Conditions List (if accepted with minor conditions) c. Accomplished Evaluation Criteria Checklist d. Memorandum stating the warranty period, as agreed upon by both parties, of minor issues listed in the Conditions List 11. Acceptance Testing for the next phase shall not be started unless the previous phase has been signed off. 12. The Project Lead shall be responsible for the issuance of a completely signed Product Acceptance Certificate, providing one set of said documents to the following: - Office of the DCIR-ISG - ACIR ISDS/ISOS - Systems Development Division - System Owner - Systems Standard and Technology Management Division B. In-house Developed Applications 1. In-house Developed Applications shall cover the following phases: a. Functional Specifications Report (FSR) b. Technical Specifications Report (TSR) c. Detailed Design (DD) d. Programming (PROG) e. System Test (SYSTEST) 2. The reviewer shall be provided with the following: Inventory of all modules where the critical ones are identified Project work plan 3. For SYSTEST, the reviewer shall be provided an updated copy of the following: Complete Test Cycle Plan (Critical Path, Test Data, Expected Results, Cycle Definitions, etc.) Testing Conditions 4. The Evaluation Criteria Checklist (Attachment A) for a particular development phase shall be the reviewer's guide during acceptance testing. 5. Reviewers shall review the documents in detail, and shall log all discrepancies found in the Discrepancy Log (Attachment D), classifying said issues into minor or major (see Severity Matrix, Attachment C). 6. To avoid default, the seven (7) working days turnaround shall be strictly followed by both the reviewers and SDD in resolving issues. 7. The SDD shall prepare and maintain the working environment for acceptance testing. 8. The Project Lead shall schedule a regular status meeting with the reviewer, expert user and SDD to discuss logged issues and to ensure that said issues, specifically major ones, are resolved/closed before sign off. 9. The reviewers shall conduct the re-testing of resolved issues. 10. All major and minor issues raised during the course of the acceptance testing shall be resolved before a particular phase can be signed off. However, if only minor issues are left, a product can still be signed off; provided said minor issues are listed in the Conditions List (Attachment F) and attached with the Product Acceptance Certificate (Attachment E). These minor issues shall be elevated as major issues if they are kept unresolved in the next phase. 11. After thorough testing, the reviewer(s) and expert user(s) shall recommend the acceptance/rejection of an application. VI. PROCEDURES 1. The Project Lead shall advise IPQS-SSTMD for the conduct of acceptance testing. 2. Reviewer shall perform completeness checking on documents submitted. 3. During the SYSTEST Phase, reviewer shall perform hands-on testing on installed applications. 4. Reviewer shall log and classify issues/discrepancies that are found/determined. 5. Reviewer shall transmit the list of issues/discrepancies to Project Lead for resolution. 6. Project Lead shall inform the reviewer on resolutions/actions taken on issues raised. 7. If all major issues are closed, the reviewer(s) and expert user(s) shall recommend the acceptance of the application being tested on condition that minor issues will be resolved within the agreed warranty period. Otherwise, the reviewer(s) and expert user(s) shall recommend for a rejection. 8. Reviewers shall prepare the Product Rejection Advice or Product Acceptance Advice/Certificate, as the case may be, for the Project Lead. 9. The Project Lead shall route said documents to designated signatories and shall furnish all concerned offices one set of the completely signed certificate. VII. SEPARABILITY CLAUSE An agreement shall be drafted by SSTMD, SDD and the System Owner to resolve concerns/issues that may arise which are not addressed/covered by this memorandum order. VIII. REPEALING CLAUSE All other revenue issuance(s) and/or portion(s) thereof that are inconsistent herewith are hereby revoked and/or amended accordingly. IX. EFFECTIVITY This order takes effect immediately. (SGD.) BEETHOVEN L. RUALO Commissioner of Internal Revenue ATTACHMENT A Evaluation Criteria Checklist Acceptance Testing Functional Specifications Report Criteria Answer Documentation Yes No N/A Reference 1. Do the key processes in the organization contribute to the successful completion of the system? 2. Has a survey on successful organizations that use the same packaged application been performed? 3. Are there process improvements reflected in the system requirements if there is an imminent business process reengineering? 4. Has the following information and documentation been obtained: a. Procedural and Data flows? b. Manual procedures? c. Reports and Screen formats? d. Input forms/screens? e. Frequency of use? f. Interface with existing systems? 5. Have all the information in using the system been identified? 6. Does the reviewer understand: a. How the system actually work? b. Behavior of the system? c. The problem that may arise in using this application, if any? d. The key personnel and their functions? 7. Have the key factors that will ensure the success of the new system been identified? 8. Does the system provide means for performance measurements? 9. Have projections for future volumes been prepared? 10. Have the minimum and optimum performance requirements been identified, including: a. Turnaround or Response Time? b. Maximum downtime allowable? c. Contingency backup procedures? 11. Have all security and control requirements been identified? 12. Will the system include a complete audit trail? 13. Does the control design extend to all manual and automated procedures and include: a. File maintenance? b. Processing controls? c. Output/Distribution controls? 14. Does the system require interfaces with other systems? 15. Does the system identify controls to ensure that transactions shared with other systems will be reflected in the same accounting period for all systems concerned? 16. Have the following system controls been established to prevent unauthorized access to data and other system resources: a. Access on software facilities b. Data classification procedures c. Password administration procedures d. Security violation monitoring and follow-up procedures 17. Have the entire business cycle and requirements been considered? 18. Has the ability to cope with the changing business conditions been considered in the design, for example: a. Revised organization structure? b. Expansion into new services? c. Abandonment of existing services? d. Changing physical locations? e. Personnel changes? 19. Has the impact of the new system to the organization been defined? 20. Has the proper consideration been given to changing existing numbering or coding system? 21. Has all new numbering or coding systems been fully defined? 22. In case of data conversions, does the system avoid relying on large amount of historical data before conversion? 23. Related to the above question, does the system avoid being dependent on major physical moves before conversion? 24. Have all forms, reports, screens, etc., been: a. Discussed with the personnel who will use them? b. Designed in a clear, simple standard format? c. Designed to address the key factors required for a new system? 25. Does the design of all screens and reports consider the limitation of the productivity aids or other software that will be used to produce the screens and reports during the implementation proper? 26. Has the impact of the system on personnel, operating procedures and non-recurring conversion procedures been identified? 27. Have the data requirements been defined in detail, and have the sources and all necessary calculations for all elements been identified? 28. If a central dictionary has been established to control all data elements, does it specify for each of the following elements: a. Its attributes? b. Its purpose or use? c. Where it is used (files, records, programs, reports, screens, etc.)? d. The meaning of all code values? 29. Have the functional specifications been issued and discussed in detail with the users? 30. Have all points been resolved to the user's satisfaction? 31. Is there a written evidence of user's acceptance of the: a. Screen formats? b. Forms formats? c. Report formats? d. Functional processing? 32. Have the users been informed that the functional specifications may be modified as a result of the technical specification? 33. Have all areas of potential risk been identified and reviewed? 34. Is there a good systems overview available that describes: a. What the system will do? b. What inputs will be required? c. What outputs will be available? d. How the system will be controlled? 35. Has all documentation been prepared in accordance to any existing documentation standards or practices and has it been organized in a neat and orderly fashion? 36. For packaged applications, have the modifications required for customization been identified and verified as practical? 37. Have the following been reviewed to be Y2K-complaint: a. Input forms/screens? b. Report layouts? Acceptance Testing Technical Specifications Report Criteria Answer Documentation Yes No N/A Reference 1. Has an overall system flowchart, which includes all manual processes, been prepared? 2. Has the processing of all system functions been identified as manual, batch or on-line? 3. Have all interfaces with other systems been designed, including: a. Manual interfaces? b. Shared databases? c. Shared files? d. Shared processing? e. Shared hardware resources? f. Shared communication network? g. Proper control? 4. Have all system software products to be used in the proposed system been identified? a. Data management system? b. File access method? c. Teleprocessing monitor? d. Application program generators and others productivity aids? e. Report writer? 5. Do the technical architecture and program design consider the characteristics and limitations of the system software, productivity aids, and programming language to be used? 6. Can all system functions be identified with a particular module or group of modules? 7. Has the processing that will be performed and how it will be performed been closely defined for each module? 8. Are common functions performed in common modules? 9. Have all key fields been identified? 10. Have the contents of all key fields been defined? 11. Does the design of the vendor's software include a method for recovering data which is lost during: a. Batch runs? b. On-line runs? 12. If the system has on-line updating, does the vendor software or the design remove the effects of partially completed transactions following the failure of: a. The entire on-line system? b. Individual on-line transactions? 13. If the answer to either (a) or (b) in the previous question is "no", are there adequate procedures to detect and remove the effect of incomplete transactions? 14. Have adequate fallback procedures been provided for the critical business functions to be automatic? 15. Have alternate approaches been considered and documented? 16. Have productivity aids or support software been incorporated where appropriate? 17. Does the design meet the security and privacy requirements specified for the system? 18. Has the approach to conversion been documented, with the sources of data and all additional resources required clearly identified? 19. Have all programs required for the conversion been identified and designed to the same level of detail as the production programs? 20. Were the specific hardware and software requirements defined in sufficient detail? 21. Have the minimum run times (i.e., run times excluding contention for resources) of all major batch runs been estimated? 22. Have the minimum response times (i.e., response times excluding contention for resources) for the high volume and other critical on-line transaction been estimated? 23. Have the hardware and communications network resource requirements been estimated? 24. Has due consideration been given to the effects of hardware and communications network resource contention on response and run times? 25. Has due consideration been given to the effects of peak processing periods? 26. Can the projected growth in volume or in functions be accommodated on the proposed equipment? 27. Have typical causes of long response and run times been considered? Some cases of which are: a. Lengthy database searches b. Single threaded (serially reusable) resources c. Excessive program-to-task linkages d. Excessive task-to-task linkages e. Excessive program or task sizes 28. Have all pertinent computations been reviewed and tested? 29. Is the documentation of the system design, in both its functional and technical aspects, organized in accordance to acceptable systems development practices standards? 30. Does the documentation represent a building block for future development of the system? 31. Do reviewers have a clear understanding of: a. Why the system is required? b. What it must do? c. How it will work? 32. Does the proposed design use technology beyond the organizations technical capability? 33. Has the system been design according to the identified requirements? 34. Has all the required testing programs or tools been identified and/or designed? 35. Has the technical specifications report been issued and discussed in detail with the development group? 36. For packaged applications, have the prerequisites for the packaged been established, including: a. Hardware requirements? b. Systems software? c. Network, etc.? 37. Have the skill levels and sophistication of the personnel who will use the application software package been considered? 38. For packaged applications, has the availability of local support and backup been considered? 39. For packaged applications, has the ease of future upgrades or expansions been considered? 40. For packaged applications, has compatibility with the current and future equipment and software been considered? 41. For packaged applications, can the system be maintained, modified and enhanced without depending on the supplier? 42. Have the effect and elapsed time to install the package been identified? 43. Is the packaged documentation comprehensive, detailed, consistent and well presented? 44. For packaged applications, has the vendor submitted a certificate of Y2K-compliance? Acceptance Testing Detailed Design Criteria Answer Documentation Yes No N/A Reference 1. Have all management-approved modifications to the preliminary systems design been incorporated into the system? 2. Have the functional and technical specifications been updated and reviewed with users? 3. Have the scope and objectives of the system remained the same? 4. If the answer to question 3 above is "no", have the changed project scope and objectives been communicated to and agreed upon by the project team? 5. Have detailed formats been prepared for all reports (including audit trail and control reports), screens, formats, etc.? 6. Have detailed specifications and formats been prepared for all files, databases and records? 7. If a central dictionary to control all data elements has been established, does it specify the following: a. Its attributes? b. Its purpose or use? c. Where it is used (files, records, programs, reports, screens, etc.)? d. The meaning of all code values? 8. Have detailed specifications of all work units been prepared and documented in accordance with common system development practices? 9. Have all unit and system interfaces been checked in detail from both sides of the interface? 10. Have operating schedules, run times, response times and equipment requirements been updated to reflect systems modifications and volume changes? 11. Have clerical work units been designed to the same level of detail as that of computer work units? 12. Has the cost/benefit analysis been updated to reflect all the system design changes made during detailed design? 13. Have all changes been identified for the following: a. Installation costs? b. Continuing costs? c. Intangible costs? 14. Has a common test data been established? 15. Have the structure and content of the test data base been communicated to all analysis and programmers? 16. In preparation for the programming segment: a. Has the work program for the programming segment been reviewed and finalized? b. Has an effective programming organization been defined? c. Have arrangements been made to provide effective supervision of the programming activity? d. Have testing standards been prepared to ensure that programs are adequately tested at the unit testing level? e. For the batch testing of on-line transactions: 1) Will a simulated terminal facility be used? 2) If not, have adequate plans been made for the documentation of tests performed interactively? f. Have arrangements for scheduling of performance tuning for individual programs been made? Acceptance Testing Programming Criteria Answer Documentation Yes No N/A Reference 1. Has the analyst reviewed the source code to ensure that it: a. Conforms to acceptable format, indentation and naming conventions? b. Have adequate comments? c. Is well organized and structured? 2. Have all coding units been subjected to a formal review meeting? 3. Has the project team resolved all review points? 4. Have effective test data and test conditions been developed? 5. Is proper control being exercised over the number of test runs? 6. Has the analyst reviewed the test results? 7. Is a programmer analyzer / optimizer being used to review program code efficiency? 8. Has results of performance tuning been submitted by the development team? 9. Does the person responsible for the technical portion of the system understand the methods and techniques being used? 10. Have all programming work units been coded and been tested? 11. Has all documentation been prepared in accordance with systems development practices standards and has it been organized in a neat and orderly fashion? 12. Have the following been reviewed to be Y2K-complaint: a. Database design / structure? b. Data structure? c. Computations? Acceptance Testing System Test Criteria Answer Documentation Yes No N/A Reference 1. Has a prototype of the system been prepared? 2. Has the prototype been tested in accordance with the actual operational procedures? 3. Has the testing environment been controlled? 4. Have test samples and documents been used represent the actual operational documents? 5. Have business test plans and cycles been prepared? 6. Have business test conditions been subjected to regression test? Integration test? 7. Have normal business test conditions been implemented successfully? 8. Has a test for abnormal conditions which fall under the following been performed: a. Taxpayer error b. Clerical error c. Procedural errors d. Diskette/transmission errors e. Double posting f. Misposting g. Batch failure h. Abnormal sequence of events i. Timing errors 9. Has the system been subjected to "Closed loop" test, whereby abnormal conditions are brought back to normal process? 10. Does the system work with the standard function keys? Are these keys enabled/disabled appropriately? 11. Does the system include process for fastpathing? 12. Does the system display appropriate messages? 13. Does the system provide an appropriate on-line help? 14. Does the system provide an appropriate "List of Values"? 15. Does the system provide appropriate validations? 16. Does the system provide appropriate security measures? 17. Does the system provide an appropriate print screen facilities? 18. Does the system work with the following: a. Data Traffic Architecture b. Audit Trails 19. Have interfaces with other systems been considered? 20. Has the system been subjected to "Closed loop" test, whereby abnormal conditions are brought back to normal process? 21. Have all business functions been tested? 22. Were expert users and computer operations personnel fully involved in the testing? 23. Were all errors or discrepancies noted on the discrepancy logs and did the project team clear all points? 24. Can the reviewers operate the system successfully? 25. Were the test results thoroughly reviewed and accepted by the project team and reviewers before conversion? 26. Were reviewers able to fill out input forms and screens successfully and accurately? 27. Were all corrections tested to ensure that previously tested functions still operate properly? 28. Has the ease of installing the system been considered? 29. Has the system test model been developed for future maintenance? 30. Have the following documents been prepared? a. User Manual b. Technical Manuals for Maintenance 31. Has a final estimate of performance and resource requirements been prepared? 32. Have interfaces with existing systems been checked? 33. Have Y2K and leap year rollover tests been performed? ATTACHMENT B System Documentation Standards 1. Functional Specifications Report 1.1 System Overview 1.2 Input Forms 1.2.1 Inventory of forms 1.2.2 Form Layout 1.2.3 Definition of forms 1.3 Screens 1.3.1 Introduction - Screen 1.3.2 Menu Hierarchy 1.3.3 Inventory of Conversations 1.3.4 Conversations of Flow 1.3.5 Screens Layout 1.3.6 Definition of Screens 1.4 Reports 1.4.1 Introduction 1.4.2 Inventory of Reports 1.4.3 Report Layout 1.4.4 Definition of Report 1.5 Business Process Flow 2. Technical Specifications Report 2.1 Introduction 2.2 Logical Database Design 2.2.1 Entity Relationship Diagram 2.2.2 List of Entities and their Attributes 2.3 Physical Database Design 2.3.1 Inventory of Tables 2.3.2 Table Definitions 2.3.3 View Definitions 2.4 Inventory of Programs 2.5 Online Programs 2.5.1 Introduction 2.5.2 Overall Flow 2.5.3 Cross Reference to Functional Specifications 2.5.4 Inventory of Online Programs 2.5.5 Module Definitions Module Data Summaries 2.6 Batch Programs 2.6.1 Introduction 2.6.2 Overall Flow 2.6.3 Cross Reference to Functional Specifications 2.6.4 Inventory of Batch Programs by Job 2.6.5 Module Definitions Module Data Summaries 2.7 Report Program 2.7.1 Introduction 2.7.2 Overall Flow 2.7.3 Cross Reference to Functional Specifications 2.7.4 Inventory of Reports 2.7.5 Module Definitions Module Data Summaries 2.8 Values of Codes Tables 3. Programming 3.1 Source Code (on tape) 3.2 Module Version Matrix 4. File Directory (including where the above FSR and TSR does are found) ATTACHMENT C Bureau of Internal Revenue Technology Management Division Acceptance Testing ATTACHMENT D Bureau of Internal Revenue Technology Management Division Discrepancy Log ATTACHMENT E Philippine Tax Computerization Project Bureau of Internal Revenue Product Acceptance Certificate Date: _________ To: <DCIR-ISG> We, the undersigned, agree that the deliverable of the product indicated below and delivered by <Vendor/Consulting Firm> performs to an acceptable standard and meets the requirements identified in the Contract and relevant Acceptance Criteria. It is further agreed that the contractual responsibilities of <Vendor/Consulting Firm> under the contract for the deliverable of this product have either been completed where no attached conditions exists, or will be completed once the conditions listed in the attachment have been resolved to the mutual agreement of the BIR and <Vendor/Consulting Firm>. Acceptance Category: Fully acceptable [ ] Accepted with attached minor conditions [ ] Signed by: ____________________ ____________________ <System Owner> <Project Lead> ____________________ ____________________ Role Role ____________________ ____________________ Date Date ____________________ ____________________ <ACIR-IPQS> <ACIR-ISDS> ____________________ ____________________ Role Role ____________________ ____________________ Date Date ATTACHMENT F Conditions List ATTACHMENT G-1 Philippine Tax Computerization Project Bureau of Internal Revenue Product Acceptance Advice Date: _________ To: <ACIRS> We, the undersigned, agree that the deliverable of the product indicated below and delivered by <Vendor/Consulting Firm> performs to an acceptable standard and meets the requirements identified in the Contract and relevant Acceptance Criteria. Description Of Product: Acceptance Category: Fully acceptable [ ] Accepted with attached minor conditions [ ] Signed by: ____________________ ____________________ <TMD Reviewer> <TMD Reviewer> ____________________ ____________________ Role Role ____________________ ____________________ Date Date ____________________ ____________________ <Expert User> <Chief, SSTMD-IPQS> ____________________ ____________________ Role Role ____________________ ____________________ Date Date ATTACHMENT G-2 Philippine Tax Computerization Project Bureau of Internal Revenue Product Rejection Advice Date: _________ To: <ACIRS> We, the undersigned, agree that the deliverable of the product indicated below and delivered by <Vendor/Consulting Firm> did not perform to an acceptable standard and failed to meet the requirements identified in the Contract and relevant Acceptance Criteria. Description Of Product: Signed by: ____________________ ____________________ <TMD Reviewer> <TMD Reviewer> ____________________ ____________________ Role Role ____________________ ____________________ Date Date Noted by: ____________________ ____________________ <Expert User> <Chief, SSTMD-IPQS> ____________________ ____________________ Role Role ____________________ ____________________ Date Date ATTACHMENT H LOG FRONT SHEET