rfp main

السعودية العربية المملكةالهيئة أو الوزارة اسم

المشروع اسم

REQUEST FOR PROPOSALMinistry/Agency of Name

الهجري التاريخ

Ministry/Agency Name e-Service and Portal project – RFP of 18

Table of Contents

1. Introduction................................................................................................4

1.1. Issuing Office..............................................................................................4

1.2. Purpose.........................................................................................................4

1.3. RFP Organization......................................................................................4

1.4. Background.................................................................................................51.4.1. MINISTRY/AGENCY NAME current system services and modules........5

2. Current Situation.................................................................................62.1. Current IT-system(s)................................................................................6

2.2. Current Processes and Modules..........................................................62.2.1. First Process.............................................................................................................6

2.2.2. Second Process.......................................................................................................7

2.2.3. Third Process...........................................................................................................7

2.3. Project Objectives.....................................................................................7

2.4. Business Drivers........................................................................................7

2.5. Business Value Proposition...................................................................8

3. SCOPE OF WORK..................................................................................93.1. Requirements Numbering Scheme....................................................9

3.2. Functional Requirements.......................................................................93.2.1. E-Services Requirements....................................................................................9

1.1.1.1First e-Service.........................................................................................................9

3.2.2. Portal Requirements...........................................................................................10

3.3. Non-Functional Requirements...........................................................103.3.1. Web-Based Application Requirements........................................................10

3.3.2. Data Migration & Transformation Requirements...................................10

3.3.3. GSB Integration Requirements.......................................................................10

3.3.4. Technical Solution Architecture Requirements........................................10

3.3.5. Software Requirements.....................................................................................10

3.3.6. Hardware Requirements...................................................................................11

3.3.7. Development, Test, & Staging Environment Requirements................11

3.3.8. Security Requirements......................................................................................11

3.3.9. Monitoring & Management Requirements.................................................11

3.3.10.Performance & Scalability Requirements...................................................11

3.3.11.Implementation Requirements.......................................................................11

3.3.12.Maintenance & Support Requirements.......................................................11

3.3.13.Change Enablement & Training Requirements........................................11

3.3.14.Operations Requirements.................................................................................11

3.3.15.Quality Assurance & Acceptance Requirements.....................................12

Ministry/Agency Name e-Service and Portal project – RFP Page 1 of 18

4. PROPOSAL FORMAT.........................................................................13

5. Appendices............................................................................................145.1. A: Instructions to Bidder, Proposal Submission and Evaluation 14

5.2. B: Standard Terms & Conditions.......................................................14

5.3. C: Requirements Compliance Matrix for Technical Proposal. 14

5.4. D: Bill of Materials & Information Tables for Technical Proposal 14

5.5. E: Training Information Templates for Technical Proposal.....14

5.6. F: Bidder Project References Templates for Technical Proposal 14

5.7. G: Bill of Materials & Pricing Tables for Financial Proposal.....15

List of TablesTable 1 System Services and Modules...............................................................5

List of FiguresFigure 1 Current IT Systems Diagram Sample..............................................6


DISCLAIMER

THIS DOCUMENT IS A REQUEST FOR PROPOSAL (RFP), AND SHALL NOT BE CON-STRUED IN WHOLE OR PART AS A DIRECT OR INDIRECT ORDER. IT SHALL NOT BE CONSTRUED AS A REQUEST OR AUTHORIZATION TO PERFORM WORK AT THE EX-PENSE OF THE MINISTRY/AGENCY NAME AND/OR THE YESSER PROGRAM. THE INFOR-MATION IN THIS RFP IS INTENDED TO ENABLE THE RECIPIENT TO FORMULATE A PRO-POSAL IN RESPONSE TO THE PROJECT REQUIREMENTS SET FORTH. ALTHOUGH THIS RFP CONTAINS SUCH ENABLING INFORMATION, BIDDERS MUST MAKE THEIR OWN IN-DEPENDENT ASSESSMENTS AND INVESTIGATIONS REGARDING THE SUBJECT MATTER OF THIS RFP. THE MINISTRY/AGENCY NAME DOES NOT GUARANTEE THE ACCURACY, RELIABILITY, CORRECTNESS OR COMPLETENESS OF THE INFORMATION IN THIS RFP. THE BIDDER REMAINS RESPONSIBLE IN RELATION TO IDENTIFYING ANY FURTHER IN-FORMATION THAT IT REQUIRES TO PREPARE THE PROPOSAL. THIS RFP SHALL CON-


STITUTE PART OF THE CONTRACT THAT WILL BE SINGED BETWEEN THE MINISTRY/AGENCY NAME AND THE SUCCESSFUL BIDDER.


1.Introduction

1.1. Issuing Office<<This section presents brief information about the ministry/agency which is issuing this RFP. It alsoe provides contact information inside the ministry/agency>>

This Request for Proposal (RFP) is issued for the MINISTRY/AGENCY NAME. The Issuing Officer of the MINISTRY/AGENCY NAME requires all technical questions be submitted by e-mail to [email protected]. For all other issues of this RFP, the sole point of contact is the MINISTRY/AGENCY

NAME Deputy Minister for Finance and Administration.

1.2. Purpose<<This section outlines the purpose of this RFP in terms of what is required from interested bidders.>>

This RFP provides the interested bidders with information to prepare and submit proposals for consideration by MINISTRY/AGENCY NAME to satisfy its requirements for the MINISTRY/AGENCY NAME E-Services & Portal project.

Information provided herein is intended solely to assist Bidders in the preparation of proposals. To the best of MINISTRY/AGENCY NAME's knowl-edge, the information provided is accurate. However, MINISTRY/AGENCY

NAME does not warrant such accuracy, and any variations subsequently determined will not be construed as a basis for invalidating of the RFP. MINISTRY/AGENCY NAME management reserves the right to cancel this Re-quest for Proposal (RFP) at any time.

1.3. RFP Organization<<This section is concered with the organziation of the RFP document in terms of the different sec-tions and subsections composing the document. For each major section of the document, the name and a breif description are provided.>>

This RFP provides the information to enable bidders to submit written pro-posals for the sought solution. The organization of the RFP is as follows:Section 1: IntroductionThis section outlines the RFP’s purpose, its organization, and some back-ground information.Section 2: Current Situation


mailto:[email protected]

This section presents an executive-level overview of the current situation from a business perspective; discussing the services provided by ministry/agency, and what will be the benefits behind implementing the project in question.Section 3: Section TitleBrief description of the information presented by this section.

1.4. Background<<This section presents a breif background information about the ministry/agency submitting this RFP; services they provide, locations, relations with other ministries). This can be an executive Sum-mary-level information about the project and its business drivers such as its relation to the Yesser pro-gram). Also list the trageted services that will be implemented through this bidding process.>>

1.4.1. MINISTRY/AGENCY NAME current system services and modules

<<This table lists a collection of services and procedures (internal and public) that are required to be implemented as e-Services. The table can also list any other existing systems (or data sources) that are related to the services in question.>>

Number Service name ScopePublic/Internal

Table 1 System Services and Modules


2.Current Situation<<This section presents an executive-level overview of the current situation from a business prespec-tive; discussing the services provided by ministry/agency, and what will be the benefits behind impele-menting the project in question. An elaboration on the information presented in the "Background" sec-tion can be included here.>>

<<Existing issues and concers relating to the services in question can also be included on this sec-tion. These might include: lack of experties in specific technologies, dependancies on other ongoing projects (internal and external)…>>

2.1. Current IT-system(s)<<This section outlines details of the existing hardware and software systems that are currently used to render the services in question. Information can include: Operating Systems, Database Manage-ments Systems, Software Applications Technology (.NET/JAVA), Anticipated Configuration End-points, Software Products, and Storage Configurations,>>

<<The ministiry/agency may choose to include a diagram depicting the current systems and setup at their end.>>

Figure 1 Current IT Systems Diagram Sample

<<Existing issues and concers relating to the services in question can also be included on this sec-tion. Theses might include: limited processing power, limited network bandwidth, limited experties in a specific platform>>

2.2. Current Processes and Modules<<This section presnts a breif introduction about the target processes and services. A listing of the target processes/services is sufficient.>>

2.2.1. First Process

<<This section is intended to present information about a single existing target processe/service. It elaborates on this process/service in the form a "Process Diagram" and descriptive "Narrative". The bidding Ministiry/Agency can use the "5 RFP templates\2 Functional\1 E-Services Requirements.doc"


Microsoft Word document tempate for this purpose.>>

Ministry/Agency Name is providing Service Name to the public through its offices…

2.2.2. Second Process

<<This section is intended to present information about a single existing target processe/service. It elaborates on this process/service in the form a "Process Diagram" and descriptive "Narrative". The bidding Ministiry/Agency can use the "5 RFP templates\2 Functional\1 E-Services Requirements.doc" Microsoft Word document tempate for this purpose.>>


2.2.3. Third Process

<<This section is intended to present information about a single existing target processe/service. It elaborates on this process/service in the form a "Process Diagram" and descriptive "Narrative" (de-scription of the different process/service steps). The bidding Ministiry/Agency can use the "5 RFP templates\2 Functional\1 E-Services Requirements.doc" Microsoft Word document tempate for this purpose.>>


2.3. Project Objectives<<This section is intended to present the objectives behind the project in hand. This is the place where the Ministry/Agency is communicating its governmental and IT objectives to interested bidders. In a normal case, being an active member of the Yesser program and joining the e-Government pro-gram are two of the most important objectives to include..>>

2.4. Business Drivers<<This section is used to present a listing of the business drivers directing this project. The bidding Ministry/Agency can use the points listed below as a starting point..>>

Ministry/Agency Name has identified the following business drivers in sup-port of its objectives:

1. Availability: 24/7 uptime and secure Internet access will maximize Ministry/Agency Name investment.

2. Reduce Ministry/Agency Name operating costs.3. Enhance Ministry/Agency Name content publishing and distribution.


4. Increase Operational efficiencies: by using workflow tools will de-crease cycle time will reduce less efficient habits.

5. Increased productivity: citizen, customers and employees will be empowered to discover, share information and identify people with relevant expertise in real-time.

6. Better access to information and improved decision making: Min-istry/Agency Name Portal will give Ministry/Agency Name decision-makers a single place to access relevant information.

7. Stronger business relationships: Ministry/Agency Name will develop stronger business relationships through deploying this portal. It will provide trusted parties, such as partners and customers, with ac-cess to the Ministry/Agency Name information and services. This makes business easier to transact, while enhancing and quickening the exchange of commercial information.

8. Streamlined business processes: Ministry/Agency Name business processes will be streamlined, as relevant content and applications are delivered through a single web browser interface, reducing the need to access multiple systems. Workflow is also improved in such an automated environment.

9. Content Aggregation and Search: the proliferation of documents and information resources demands that Ministry/Agency Name to ag-gregate content and provide advanced tagging and search capabili-ties. The required portal will bring together contents from disparate sources, displaying results through a single interface. The quality of the taxonomy and categorization processes and having the capabil-ity to find information held in a variety of file formats via keywords and other methods.

2.5. Business Value Proposition<<OPTIONAL: This section is intended to present the business value gained from successfully imple-menting the project in hand. The bidding Ministry/Agency lists down the gains and benefits resulting from implementing this project..>>


3.SCOPE OF WORK<<This section documents the scope of work of this project. It outlines what will be required by inter-ested bidders to succesfully implement the project in hand. Content of this subsection can be in-cluded here in the main RFP document, or it can be compiled into a seprate document.>>

<<A comprehinsive list of the project deliverables is included in this section. To properly facilitate the verification of the delivered solution against the original requirements, each of the below requirements section is required have a section listing all reqired deliverables relating to that section.>>

<<For example the “Change Enablement & Training Requirements” section should include Training Courses and Training material as deliverables, and so forth. The clearer ans more specific these de-liverables are, the easier it is to verify the system against its defined requirements.>>

3.1. Requirements Numbering Scheme<<Numbering requirements will facilitate referencing a specific functionality througout the different phases of a project. The bidding ministry/agency is encouraged to adopt a numbering scheme when compiling their proposals.

<<Below is a suggested numbering scheme:ReqType-SeqNum where:

ReqType: Corresponds to the requirement type. Values can be ESRV for e-Services, PTRL for Portal, SEC for Security, and so forth.

SeqNum: is a sequence number starting from 1 up to thetotal of number of compiled require-ments.

If the above numbering is deemed complex, the bidding ministry/agency can adopt a more straight forward approach where requirements numbered from 001 up to 999 (or above).>>

3.2. Functional Requirements<<This section is intended to present a listing of the functional requirements. It describes what func-tionality will be required from the propsoed solution. The section focuses mainly on the e-Services re-quirements and the Portal requirements.

3.2.1. E-Services Requirements

<<After diescribing the target processes/services in a previous section, the bidding Ministry/Agency can use this section to outline detailed requirements for each of the target processes/services.>>

<<Each target service is discussed in further details in a separate subsection below. A listing of the target processes/services is sufficient.>>

1.1.1.1FIRST E-SERVICE

<<This section presents detailed requirements for a specific process/service. There can be as many subsections as there are processes/services to be included in the project in hand.>>


<<For the purpose of further elaboration, this section can include sample Sequence Diagrams depict-ing the flow of a process/service. It can also include mentioning of other available services (payment, notification…) that the target service might communicate with.>>

<<The bidding ministry/agency can use the 5 RFP templates\ 3 Non-Functional\ 1 E-Services Re-quirements.doc" Microsoft Word document tempate for this purpose.>>

3.2.2. Portal Requirements

<<This section outlines the functional requirements for utilizing the existing e-Government Portal to

render the e-Services in question. The bidding ministry/agency can use the 5 RFP templates\ 3 Non-

Functional\2 Portal Requirements.doc" Microsoft Word document tempate for this purpose.>>

3.3. Non-Functional Requirements<<Non-functional requirements relating to performance, availabilit, deployment, implemetation, opera-tions and others are listed in the subsequent subsection. Several Microsoft Word templates are avail-able to assist the compilation of these subsections.>>

3.3.1. Web-Based Application Requirements

<<This section provides information about the required Web-Based application. The bidding

Ministiry/Agency can use the "5 RFP templates\ 3 Non-Functional\1 Web-Based Application Require-

ments.doc" Microsoft Word document tempate for this purpose.>>

3.3.2. Data Migration & Transformation Requirements

<<This section provides information about the existing data migration and transformation. The bidding

Ministiry/Agency can use the "5 RFP templates\ 3 Non-Functional\2 Data Migration & Transformation

Requirements.doc" Microsoft Word document tempate for this purpose. >>

3.3.3. GSB Integration Requirements

<<Integration with the GSB is cruical to any e-Government-related e-Service implementation project. The requirements of this integration are included in this section. The bidding Ministiry/Agency can use

the "5 RFP templates\ 3 Non-Functional\3 GSB Integration Requirements.doc" Microsoft Word docu-

ment tempate for this purpose.>>

3.3.4. Technical Solution Architecture Requirements

<<This section provides high-level requirements of the target solution architecture, and how to make it alligned with the existing e-Government Architecture Framework. The bidding Ministiry/Agency can

use the "5 RFP templates\ 3 Non-Functional\4 Technical Solution Architecture Requirements.doc"

Microsoft Word document tempate for this purpose. >>

3.3.5. Software Requirements

<<This section provides requirements relating to Operating Systems, Software Products, Database

Management Systems, and others. The bidding Ministiry/Agency can use the "5 RFP templates\ 3

Non-Functional\5 Software Requirements.doc" Microsoft Word document tempate for this purpose. >>


3.3.6. Hardware Requirements

<<Hardware requirements are included here. The bidding Ministiry/Agency can use the "5 RFP tem-

plates\ 3 Non-Functional\6 Hardware Requirements.doc" Microsoft Word document tempate for this

purpose. >>

3.3.7. Development, Test, & Staging Environment Requirements

<<This section provides information about the development, testing, staging, and production hard-

ware/software environment. The bidding Ministiry/Agency can use the "5 RFP templates\ 3 Non-Func-

tional\7 Development, Test, & Staging Environment Requirements.doc" Microsoft Word document tempate for this purpose.>>

3.3.8. Security Requirements

<<Security requirements are included here. These requiremtns are alligned with the e-Government

Architecture Framework. The bidding Ministiry/Agency can use the "5 RFP templates\ 3 Non-Func-

tional\8 Security Requirements.doc" Microsoft Word document tempate for this purpose. >>

3.3.9. Monitoring & Management Requirements

<<The bidding Ministiry/Agency can use the "5 RFP templates\ 3 Non-Functional\9 Monitoring & Man-agement Requirements.doc" Microsoft Word document tempate for this purpose. >>

3.3.10. Performance & Scalability Requirements

<<The bidding Ministiry/Agency can use the "5 RFP templates\ 3 Non-Functional\10 Performance & Scalability Requirements.doc" Microsoft Word document tempate for this purpose.>>

3.3.11. Implementation Requirements

<<The bidding Ministiry/Agency can use the "5 RFP templates\ 3 Non-Functional\11 Implementation Requirements.doc" Microsoft Word document tempate for this purpose.>>

3.3.12. Maintenance & Support Requirements

<<The bidding Ministiry/Agency can use the "5 RFP templates\ 3 Non-Functional\12 Maintenance & Support Requirements.doc" Microsoft Word document tempate for this purpose.>>

3.3.13. Change Enablement & Training Requirements

<<The bidding Ministiry/Agency can use the "5 RFP templates\ 3 Non-Functional\13 Change Enable-ment & Training Requirements.doc" Microsoft Word document tempate for this purpose.>>

3.3.14. Operations Requirements

<<The bidding Ministiry/Agency can use the "5 RFP templates\ 3 Non-Functional\14 Operations Re-quirements.doc" Microsoft Word document tempate for this purpose.>>


3.3.15. Quality Assurance & Acceptance Requirements

<<Quality Assuracne and Acceptance requirements are included in this section. The bidding

Ministiry/Agency can use the "5 RFP templates\ 3 Non-Functional\15 Quality Assurance & Accep-

tance Requirements.doc" Microsoft Word document tempate for this purpose.>>


4. PROPOSAL FORMAT<<The bidding Ministiry/Agency can use the "5 RFP templates\ 3 Non-Functional\Proposal Format.-doc" Microsoft Word document tempate for this purpose.>>

<<Content of this section can be included here in the main RFP document, or it can be com-piled into a seprate document.>>

This section provides the requirements for Bidders to prepare and sub-mit…


5. Appendices<<For ease of reference, content of these appendcies are compiled into separate documents than tha main RFP document..>>

The following are the appendices in support of the RFP.

5.1. A: Instructions to Bidder, Proposal Submission and Evaluation

Appendix A provides the information to Bidders regarding proposal review process, content and format, evaluation, and communications.

5.2. B: Standard Terms & Conditions

Appendix B provides Ministry/Agency Name project standards terms and conditions in Arabic.

5.3. C: Requirements Compliance Matrix for Technical Proposal

The bidders are required to fill-in this sheet in its entirety; this table will be used to guide the evaluation process of the technical proposal.

5.4. D: Bill of Materials & Information Tables for Technical Proposal

Appendix D provides all the software and hardware information tables for the Technical Proposal that need to be provided by Bidders.

5.5. E: Training Information Templates for Technical Proposal

Appendix E provides the information template for training courses to be provided by Bidders for the Technical Proposal.

5.6. F: Bidder Project References Templates for Technical Proposal

Appendix F provides the templates for Bidders’ references in support of their Technical Proposals.


5.7. G: Bill of Materials & Pricing Tables for Financial Proposal

Appendix G provides all the pricing table templates for the Financial Pro-posal that need to be used and filled by Bidders with all required financial data and information.


rfp main

Travel