不清楚你具體需求是什麼，給你一份之前的方案參考看是否有幫助。
1.1 專案目標
在招標人制度最佳化及系統建設專案建設過程中，期望應標機構發揮自身方法論、行業實踐及專業優勢達到如下專案目標：
1) 按照招標人制度最佳化及系統建設專案的要求建設辦公應用系統,與當前辦公系統整合，滿足全員日常辦公需要的功能需求和非功能需求。
2) 按照招標人對移動辦公要求，開發移動辦公模組，實現移動辦公的功能需求和非功能需求。
3) 實現與財務辦公系統、物採系統的接入和整合。
4) 實現業務資料從現有系統到新建系統的平滑過渡，包括移動終端切換、系統後臺切換、資料遷移、新舊系統資料彙總、歷史資料轉換與查詢等。
5) 專案擬建的系統和軟體應完全覆蓋和超越現有系統的功能和效能。在業務上除了滿足當前的業務需要，必須具備一定的前瞻性，系統能夠滿足未來 5 年辦公資訊化需求。
2.1 總體需求
為實現制度最佳化及系統建設專案的穩定性和靈活性，制度最佳化及系統建設專案技術上將
緊密依託 H3 流程引擎開發平臺，透過配置為主，程式碼編寫為輔的開發模式、構建以下模組：
l 入口網站：建設公司網路和內網的入口網站，包括但不限於：入口網站及網站對應的後臺內容管理系統，風格上突出企業特色和企業文化宣貫。
l 工作臺：建設面向全員辦公的工作臺，包括但不限於：全員相關日常辦公流程管理、知識管理、會議管理、任務管理、郵件管理、日程管理及對應的基礎資料管理。
l 合同管理：實現合同管理模組，並在工作臺中進行整合。
l 移動端建設：基於招標人現有移動端 APP，建設面向管理人員審批的移動 APP。基
l 外部系統接入：在工作臺中實現對財務、物採、即時通訊等辦公系統的接入。
l 資料遷移：新系統正式上線後，舊系統的所有資料需要無縫遷移到新系統中。資料包括不限於現有 OA 系統、合同系統、物採系統、財務管理系統的資料。
2.2 制度最佳化及系統建設專案需要完成的業務功能說明
2.2.1 入口網站主要系統功能
2.2.1.1 網路門戶展示
面向外部訪客的入口網站，包括不限於公司簡介、公司新聞、行業動態、產品服務、外部招聘等。風格簡潔明快，體現企業特色。
2.2.1.2 內部門戶展示
面向公司內部員工的入口網站，透過公司新聞、行業動態、內部表彰等形式，突出門戶企業文化的宣貫作用，風格要簡約，重點突出。整合員工工作臺入口。
2.2.1.3 門戶內容管理系統
2.2.2 工作臺主要系統功能
2.2.2.1 流程管理
面向全員的流程整合，實現流程的發起、流轉、歸檔功能。在發起環節支援樣例查詢、
流程引導等便捷操作，降低使用者使用的難度；審批環節支援歷史資料檢索、決策資料展示等輔助決策操作；對跨領域的場景化流程，要透過流程環節的整合展示，便於員工操作。
2.2.2.2 辦公輔助功能
提供便於員工辦公的輔助功能，包括不限於會議管理、任務管理、知識管理、郵件管理、日程管理等。
2.2.2.3 外部系統整合
在工作臺中，整合現有的物採系統、財務管理系統、物資採購系統等，支援功能許可權分配，系統整合在安全的基礎上，突出使用者使用的友好性。支援對及時通訊系統、outLook 的整合。
2.2.3 移動終端主要功能
2.2.3.1 移動 APP 主要功能
基於招標方的面向管理人員的審批 APP，完成用於支援制度最佳化及系統建設專案涉及流程的審批、決策性報表的移動展示。
2.2.4 合同系統主要功能
實現對公司合同全生命週期管理和統計查詢功能。
2.2.5 版本內容
2.2.5.1 1.0 版本內容
完成需求梳理、系統架構、業務規劃，並透過招標方評審；
完成內網路門戶開發；完成工作臺開發；
完成移動端 APP 主要功能；
完成現有流程遷移、修改和新流程開發；完成場景化差旅流程開發；完成部分輔助應用開發。
2.2.5.2 1.1 版本內容
完成合同管理模組開發；實現場景化流程開發；
3.1 功能需求分析要求
投標人根據招標人業務需求，利用投標人在資訊化建設方面的經驗對系統需求進行完善，
並對系統進行功能需求分析和需求管理。投標人輸出的需求分析成果需經過招標人的評審，並根據招標人的要求對輸出成果進行修訂，直至滿足要求。
3.1.1 功能需求分析交付物
制度最佳化及系統建設專案的需求規格說明書，在功能需求說明書提交前根據專案計劃提交頁面示例。
3.2 非功能性處理需求
制度最佳化及系統建設專案應包括但不限於以下的非功能性需求：
3.2.1.1 可靠性、可用性和完整性
系統應至少但不限於滿足以下能力：
l 7 x 24 小時穩定執行。
l 工作日故障恢復時間 2 小時，非工作日故障恢復時間 24 小時；
l 應用崩潰重啟後，關鍵業務狀態可以快速恢復。快速恢復的前提是資料沒有丟失，資料在物理上完整性和業務上的一致性。
3.2.1.2 松耦合結構
要求各個子系統/功能之間耦合度儘可能低，不能因為一個子系統/功能出現問題立刻就擴散到其他子系統/功能，導致對業務服務的大面積故障。
3.2.1.3 標準化外部系統介面處理
為滿足統一辦公需求發展，制度最佳化及系統建設專案需具備與外部應用系統的整合能力。
系統方案需滿足：
l 滿足具備與各外部系統的資料交換能力；
l 滿足具備與各外部系統的應用整合能力。
l 統一的對外應用介面服務能力；
l 介面服務的高安全效能力；
l 介面服務的擴充套件效能力；
l 介面服務的穩定效能力；
l 介面服務的高併發行能力。
3.2.1.4 分散式處理能力
制度最佳化及系統建設專案需要具備分散式處理能力。
應至少但不限於滿足：
l 分散式的資料儲存能力；
l 分散式的計算能力；
l 分散式系統快速部署、備份、快速重建和快速恢復能力；
l 滿足系統服務 7 x 24 小時不間斷能力。
3.2.1.5 業務可擴充套件性
招標方業務處於高速發展的階段，為支援未來的業務開展，需要制度最佳化及系統建設專案提供靈活可擴充套件性。包括但不限於下面的擴充套件性：
l 服務能力的橫向擴充套件性，隨著招標方人員和業務的發展，可以透過增加伺服器數量增強系統的業務處理能力。
l 功能擴充套件性。要求各子系統/模組/功能之間耦合度儘可能低，各子系統/模組/功能之間透過標準化的介面進行資料互動，保障各子系統/模組/功能的高可擴充套件性。
3.2.1.6 高效能要求
投標人提供的總體技術方案應能夠滿足制度最佳化及系統建設專案未來 5 年的業務需要，至少需要支援如下業務規模：
l 支援 1000 人員規模使用，200 人同時線上。
l 在 5 年資料量的基礎上，50 人同時線上壓力下，支援報表內頁面開啟響應時間 5 秒，支援非報表類頁面開啟響應時間 3 秒，複雜頁面開啟響應時間 5 秒。150 人同時線上壓力下，支援報表內頁面開啟響應時間 10 秒，支援非報表類頁面開啟響應時間 5 秒，複雜頁面開啟響應時間 8 秒。
在滿足以上業務規模的前提下，技術方案還應該具備很高的可擴充套件能力，方案涉及的軟硬體均需要具備可橫向擴充套件的能力。
3.2.1.7 資訊保安
制度最佳化及系統建設專案需透過招標人資訊保安部門組織的資訊保安測試。
3.3 概要設計要求
制度最佳化及系統建設專案的概要設計需要滿足以下格式和內容的要求。
3.3.1 概要設計的規範要求
3.3.1.1 概要設計的基本要求
概要設計作為專案的重要文件輸出，必須滿足招標人的規範和要求。包括但不限於：
l 文件及格式要求。文件命名格式要求、修訂歷史要求、文件章節命名和格式要求、各章節格式要求、圖表及說明要求
l 文件評審要求。概要設計文件需要交由招標人專案組進行統一評審，從格式和內容兩方面進行評審，評審不合格的文件需要修訂合格後再評審，直到評審合格。
l 文件版本管理要求。要求所有的文件必須提交到招標人的配置管理庫上進行管理，所有的修訂都要有修訂歷史。
l 原始碼、文件一致性的要求。要求保持原始碼和文件的一致性，任何一邊修改後，需要在同一個版本內修改文件或原始碼。
3.3.1.2 概要設計的內容要求
3.3.1.2.1 程式概要設計要求
要求所有的子系統、模組、類都需要有概要設計。概要設計的內容需要包括：
l 系統，及系統的組成部分。子系統，及子系統的組成部分。
l 類，模組與類的關係。類的主要方法和屬性，主要方法的流程說明。
l 主要業務的整體流程說明
3.3.1.2.2 資料庫程式概要設計要求
要求所有的資料庫表、檢視、儲存過程、包等實體都有概要設計說明，包括但不限於下面的內容：
l 表的說明，及表的欄位屬性的說明，約束屬性的說明，鍵、索引等說明。
l 檢視的說明
l 儲存過程、函式、包的說明
3.3.1.2.3 介面設計詳細說明
要求所有與外部系統和內部系統之間的介面都要有詳細的介面說明，包括但不限於下面的內容：
l 同物採系統的介面詳細說明
l 同財務管理系統的介面詳細說明
l 同移動端 APP 的介面詳細說明
l 同即使通訊系統的介面詳細說明
l 同郵件服務的介面詳細說明
3.3.2 概要設計交付物
制度最佳化及系統建設專案每一個子系統都需要進行概要設計。所有的概要設計文件都需要招標人專案組進行評審，只有評審透過的概要設計才是有效的交付物。
所有的概要設計交付物都必須是有效的，正式的，並已經提交到招標人的配置管理系統進行配置管理。
3.4 程式碼開發要求
3.4.1 符合發行管理平臺的程式碼開發規範
所有程式碼和配置都必須符合程式碼規範約定，包括但不限於：
l 程式碼必須符合招標方的程式碼編寫規範要求；
l 程式碼需完成單元測試，測試通過後才可提交到配置管理庫；
l 招標人專案組會組織程式碼評審，對不符合規範和招標人要求的程式碼將要求投標人進行修改，直到滿足規範要求為止。
3.4.2 符合招標人的版本管理規範
所有的程式碼和配置都必須提交到招標人的配置管理庫中，並按招標人的版本管理規範要求進行相關的操作。包括但不限於：
l 所有程式碼、配置檔案、指令碼檔案、編譯檔案、第三方依賴庫等必須提交到版本控制系統中
l 整合測試的版本必須且僅只能從版本控制系統中獲取。
l 除 H3 流程引擎開發平臺提供的庫外，第三方依賴庫必須經過招標人的確認才可以使用。
l 不得使用盜版和其他未得到授權的原始碼、庫、執行程式。
3.4.3 程式碼開發交付物
需要交付完整的程式碼、配置、指令碼、編譯檔案以及編譯輸出的檔案。所有程式碼開發交付物在交付前都需要招標人評審透過，未透過的評審的程式碼交付物都不是有效的交付物。
所有的程式碼交付物都必須是有效的，正式的，並已經提交到制度最佳化及系統建設專案的配置管理庫進行配置管理。
3.5 整合測試要求
3.5.1 測試工作範圍
按照需求文件中的需求範圍，進行功能測試及效能測試，每輪測試通過後需分別出具具有明確測試結論的功能測試報告和效能測試報告；
投標人進駐現場後，應與招標人商討所測試專案的進展情況，併合理計劃安排各項工作；形成整個測試工作的詳細測試計劃。
根據上述描述的系統要求對軟體系統進行全面測試，至少應從應用系統的功能性、效能、易用性、可靠性、相容性、可擴充套件性和使用者文件等質量特性方面開展測試。
工作包括但不限於：
1） 制定測試計劃，設計測試用例和測試場景，執行測試，報告缺陷，分析測試結果，提交以上所有文件。
2） 功能測試
a) 根據系統《需求說明書》，分析各功能點測試的優先級別。使用者經常使用、關係到系統核心功能、優先級別較高的功能點，測試覆蓋率應達到 100%；
b) 功能測試必須既包括正常輸入和正常業務流程測試，也包括對非法資料輸入和異常處理的測試，且對系統非正常操作的測試用例應占到總數的 20%-30%。
3） 效能測試：
a) 根據《需求說明書》等相關文件，測試在大使用者量、大資料量和長時間連續執行等條件下，系統的響應時間和穩定執行情況。
b) 模擬系統真實環境，測試系統處理高峰資料量的效能指標。
4） 易用性測試：從最終使用者的角度，對系統介面風格一致性、友好性和可用性等方面進行測試。
5） 可靠性測試：對系統在執行過程的持續穩定性，包括系統的容錯能力和對資料的保護能力進行測試。
6） 相容性測試：透過相容性測試，確認應用系統軟體與相關的各種硬體裝置、作業系統、相關支撐軟體以及其他相關應用系統的相容性。
7） 可擴充套件性測試：透過系統可擴充套件性測試，確認應用系統軟體是否可透過開發新的軟體以保證功能的可擴充套件性；是否可透過開發或調整程式以達到效能的可擴充套件性。
8） 使用者文件檢查重點檢查所提交文件的完備性及與實際系統的符合性。
3.5.2 測試標準
投標人應在投標書中列出測試所執行的主要標準。
3.5.3 測試方案
投標人應根據測試工作制定相應的測試方案，完成《制度最佳化及系統建設專案測試方案》，方案內容包括但不限於：
l 測試背景
l 測試標準
l 測試流程
l 採用的測試方法
l 預期的輸出結果
l 參與各方的職責。
3.5.4 測試計劃
投標人需針對每一個系統制定測試計劃，完成《制度最佳化及系統建設專案測試計劃》。測試計劃中需規定被測試的物件、被測試的特性、應完成的測試任務、人員職責及風險等，確定要完成的測試活動，評估完成活動所需要的時間和資源，設計測試組織和崗位職權，進行活動安排和資源分配，安排跟蹤和控制測試過程的活動。
3.5.5 測試用例
投標人需根據測試範圍設計科學合理有效的測試用例及測試指令碼，並對測試用例和指令碼統一管理，要求測試用例具有可重複性、有組織性、可回溯性和可操作性；
3.5.6 測試實施及評估
投標人將獲得的執行結果與預期結果進行比較和分析，記錄、跟蹤和管理系統缺陷，測試後對測試過程進行分析評估，對各系統的缺陷進行分析評估並提出改進意見，最終提交測試報告。
3.5.7 安全測試
3.5.8 測試報告
測試報告和測試結果應包含但不侷限於分析說明測試資料值的範圍（包括動態資料和靜態資料）。陳述經測試證實的系統缺陷和限制，陳述系統質量缺陷產生的原因，說明每項缺陷和限制對效能的影響，並說明全部測得的效能缺陷的累積影響和總影響。同時，對每項缺陷提出改進建議，包含但不侷限如：各項修改可採用的修改方法；各項修改的緊迫程度等。
除過程性報告外，測試方需在測試通過後，出具結論性報告，包括《制度最佳化及系統建設專案功能測試報告》、《制度最佳化及系統建設專案測試效能測試報告》。
3.5.9 測試環境
招標人為測試提供系統工作所需的軟硬體測試環境，投標人將使用招標人指定的測試環境。測試所需專用軟體由投標人提供。
投標人應根據本專案實際情況在投標書向招標人提出測試環境的合理建議。
3.5.10 測試工具
測試工具及測試管理工具由投標人提供。
3.5.11 整合測試交付物
專案測試過程中，投標人必須提交（包含但不限於）下列檔案：
Ø 整體測試規劃
Ø 測試範圍分析
Ø 測試方案
Ø 質量等級和評估標準
Ø 測試用例和測試資料
Ø 測試系統功能測試計劃、測試報告及測試缺陷日誌
Ø 測試計劃、測試報告及測試缺陷日誌；
Ø 進度及測試工作彙報
對於投標人提交的文件，當招標人要求時，要經過招標人組織的評審，對文件進行修訂需要進行重新評審。
3.6 新舊系統遷移、相容性、歷史資料要求
3.6.1 系統遷移的基本要求
為了保障當前辦公系統涉及功能平滑遷移到遷移到制度最佳化及系統建設專案，中標方在專案上線期間，必須按要求完成從現有辦公系統到制度最佳化及系統建設專案的遷移工作。
投標人在技術方案中需要包含從現有辦公系統到制度最佳化及系統建設專案的遷移方案，遷移方案需要滿足下面的條件：
l 遷移過程中、遷移後的所有關鍵資料不丟失，特別是流程資料，歸檔資料。
l 遷移後，正在進行中的流程可以無縫流轉，已完結的流程資料可以查詢。
3.6.2 遷移工作投標人承擔的工作
中標方將承擔遷移主要工作，需要招標人協助和確認的工作，需要體現在遷移方案中。中標方承擔的遷移主要工作包括但不限於下面的工作：
l 制定遷移方案，並提供詳細的實施計劃，所有的遷移方案和實施計劃必須得到招標人的評審透過。
l 開發遷移過程中所需要的全部程式和指令碼。
l 開發遷移過程中所需要的全部相容性功能，滿足招標人對遷移過程中的功能和效能要求。
l 實施遷移過程。
l 保障遷移、及遷移後的系統功能的完整性、一致性的要求的其他事項。
3.6.3 相容性要求
1. 移動終端應用軟體支援自動升級，相容主流 Andriod 版本和 IOS 版本。
2. PC 版相容 Win7、Win10，相容 IE8 及以上、360、chrome、firefox、safari 等主流瀏覽器。
3.7 專案管理要求
3.7.1 入場時間、地點
投標人在收到中標通知書後，五個工作日內專案經理、需求分析師、UI 設計人員入場給招標人提供駐場服務。駐場服務地點為北京，具體地址由招標人指定。
除現場辦公用房和研發、測試所需伺服器外，為完成專案工作所需的其他設施、裝置和物品均由投標人自行解決，包括生活設施、交通設施、通訊裝置、辦公裝置等。
3.7.2 專案計劃管理
1. 專案必須編制進度計劃，要求採用 Project 編制，計劃應當涵蓋完整工作範圍，包括關鍵里程碑、任務責任人資訊；專案計劃採用漸進明細原則，原則上最近 1 個月的任務分解的粒度不大於 5 個工作日，並體現任務之間的依賴關係。
2. 專案計劃應當透過招標人的稽核，在專案管理平臺上釋出並形成基線。
3. 專案經理應當根據實際執行情況對專案計劃進行及時調整，涉及到月度里程碑的調整應向招標方提交變更申請表；
4. 計劃應當每週五更新實際完成的百分比，並將更新結果同步到專案管理平臺；
3.7.3 專案質量管理
1. 招標方將針對關鍵里程碑進行評審應；
2. 專案重大質量問題應當及時向招標人報告。
3.7.4 問題與風險管理
1. 專案應建立問題與風險管理記錄表，記錄問題與風險，評估級別，明確責任人、解決日期。
2. 發現可能影響本專案、或專案群其他關聯專案的關鍵里程碑達成的高級別問題或風險，必須及時向專案管理組報告。
3. 並應當每週五更新。
3.7.5 溝通管理
1. 按規範填寫專案週報，在週報中準確彙報進展、是否延期及延期情況、主要問題及風險；
2. 定期釋出專案週報；
3. 定期召開專案例會，對專案進展、下週計劃，問題及風險進行溝通。
3.7.6 專案週期
專案採用迭代和增量式開發方法，參考週期如下：
3.8 *資源投入和人員資質要求
投標方承諾至少投入 35 個人月來完成本專案，這是本專案投入資源的最低要求，如低於 35 個人月，將視為廢標。另外，由於本專案不是簡單的人員外包專案，所以如果投入資源達到 35 個人月，但沒有完成專案目標，也不能視為專案交付，需繼續投入資源，直至完成專案目標且透過招標方的驗收。投標方需要在招標現場提供工時承諾書。
具體投入專案的專案角色及資質要求見下表，專案經理角色可以和需求分析師/高階.NET 開發工程師人員重合：
投標人需提交本專案的組織結構、所有參與該專案人員的工作職責、常駐工作城市、工作簡歷、工作經驗說明及投入本專案的時間計劃，專案組所有成員提供半年以上的社保記錄證明。參與專案的專案經理、UI 設計師、需求分析師、高階.NET 開發工程師在駐場前需透過招標人的專業面試，如未透過，中標方需立即更換具備足夠技能的人員，直至面試透過；在專案過程中，若招標人認為中標方派駐人員不能勝任專業工作，中標方必須一週內更換人員，直至達到招標人的要求；拒不更換的，招標人有權終止合同。
投標人要保證專案經理、UI 設計師、需求分析師、高階.NET 開發工程師的穩定性,參與專案人員除招標人提出更換要求外，不得更換，如需更換，要徵得招標人同意。投標人專案組成員在專案實施期間不得從事與本專案無關的工作。
3.9 培訓要求
3.9.1 知識轉移要求
投標人需要移交針對本專案的所有成果，並對招標人的研發、測試、運維人員進行系統性培訓，使其快速掌握並勝任相關工作。
投標人根據招標人的技術團隊，量身定做其匹配的知識轉移方案，方案內容包括但不限於程式碼開發、系統部署等階段。以最終到達招標人團隊能夠實現系統的運維和後期開發工作。
3.9.2 使用者培訓要求
投標人需要提供對招標人系統使用者關於系統使用方面的培訓，包括課程設計、教材及課件編寫等。
投標人提供約 5 人天培訓。其他使用者的培訓工作由招標人自行負責。
3.10 技術支援服務要求
投標人需提供技術支援服務方案和服務承諾，投標人在投標書中必須明確承諾達到使用者的服務響應要求：
*系統終驗後 1 年內，系統出現不滿足《制度最佳化及系統建設專案需求規格說明書》中功能和非功能性需求的情況，由投標人負責解決。影響全員辦公的核心功能出現故障，需要在 2 小時內提供現場技術支援服務。
* 系統終驗後一年內，投標人提供一年的 7*24 小時技術支援服務，其中需要提供 7*10 小時的現場技術支援服務。非現場支援服務期間應提供電話服務，1 小時內做出明確響應和安排，電話支援不能解決問題，需要在 2 小時內提供現場技術支援服務，並在後續 1 周內給出針對該問題的徹底解決方案和改進建議。
不清楚你具體需求是什麼，給你一份之前的方案參考看是否有幫助。
1 專案概述1.1 專案目標
在招標人制度最佳化及系統建設專案建設過程中，期望應標機構發揮自身方法論、行業實踐及專業優勢達到如下專案目標：
1) 按照招標人制度最佳化及系統建設專案的要求建設辦公應用系統,與當前辦公系統整合，滿足全員日常辦公需要的功能需求和非功能需求。
2) 按照招標人對移動辦公要求，開發移動辦公模組，實現移動辦公的功能需求和非功能需求。
3) 實現與財務辦公系統、物採系統的接入和整合。
4) 實現業務資料從現有系統到新建系統的平滑過渡，包括移動終端切換、系統後臺切換、資料遷移、新舊系統資料彙總、歷史資料轉換與查詢等。
5) 專案擬建的系統和軟體應完全覆蓋和超越現有系統的功能和效能。在業務上除了滿足當前的業務需要，必須具備一定的前瞻性，系統能夠滿足未來 5 年辦公資訊化需求。
2 專案範圍2.1 總體需求
為實現制度最佳化及系統建設專案的穩定性和靈活性，制度最佳化及系統建設專案技術上將
緊密依託 H3 流程引擎開發平臺，透過配置為主，程式碼編寫為輔的開發模式、構建以下模組：
l 入口網站：建設公司網路和內網的入口網站，包括但不限於：入口網站及網站對應的後臺內容管理系統，風格上突出企業特色和企業文化宣貫。
l 工作臺：建設面向全員辦公的工作臺，包括但不限於：全員相關日常辦公流程管理、知識管理、會議管理、任務管理、郵件管理、日程管理及對應的基礎資料管理。
l 合同管理：實現合同管理模組，並在工作臺中進行整合。
l 移動端建設：基於招標人現有移動端 APP，建設面向管理人員審批的移動 APP。基
l 外部系統接入：在工作臺中實現對財務、物採、即時通訊等辦公系統的接入。
l 資料遷移：新系統正式上線後，舊系統的所有資料需要無縫遷移到新系統中。資料包括不限於現有 OA 系統、合同系統、物採系統、財務管理系統的資料。
2.2 制度最佳化及系統建設專案需要完成的業務功能說明
2.2.1 入口網站主要系統功能
2.2.1.1 網路門戶展示
面向外部訪客的入口網站，包括不限於公司簡介、公司新聞、行業動態、產品服務、外部招聘等。風格簡潔明快，體現企業特色。
2.2.1.2 內部門戶展示
面向公司內部員工的入口網站，透過公司新聞、行業動態、內部表彰等形式，突出門戶企業文化的宣貫作用，風格要簡約，重點突出。整合員工工作臺入口。
2.2.1.3 門戶內容管理系統
2.2.2 工作臺主要系統功能
2.2.2.1 流程管理
面向全員的流程整合，實現流程的發起、流轉、歸檔功能。在發起環節支援樣例查詢、
流程引導等便捷操作，降低使用者使用的難度；審批環節支援歷史資料檢索、決策資料展示等輔助決策操作；對跨領域的場景化流程，要透過流程環節的整合展示，便於員工操作。
2.2.2.2 辦公輔助功能
提供便於員工辦公的輔助功能，包括不限於會議管理、任務管理、知識管理、郵件管理、日程管理等。
2.2.2.3 外部系統整合
在工作臺中，整合現有的物採系統、財務管理系統、物資採購系統等，支援功能許可權分配，系統整合在安全的基礎上，突出使用者使用的友好性。支援對及時通訊系統、outLook 的整合。
2.2.3 移動終端主要功能
2.2.3.1 移動 APP 主要功能
基於招標方的面向管理人員的審批 APP，完成用於支援制度最佳化及系統建設專案涉及流程的審批、決策性報表的移動展示。
2.2.4 合同系統主要功能
實現對公司合同全生命週期管理和統計查詢功能。
2.2.5 版本內容
2.2.5.1 1.0 版本內容
完成需求梳理、系統架構、業務規劃，並透過招標方評審；
完成內網路門戶開發；完成工作臺開發；
完成移動端 APP 主要功能；
完成現有流程遷移、修改和新流程開發；完成場景化差旅流程開發；完成部分輔助應用開發。
2.2.5.2 1.1 版本內容
完成合同管理模組開發；實現場景化流程開發；
3 專案要求3.1 功能需求分析要求
投標人根據招標人業務需求，利用投標人在資訊化建設方面的經驗對系統需求進行完善，
並對系統進行功能需求分析和需求管理。投標人輸出的需求分析成果需經過招標人的評審，並根據招標人的要求對輸出成果進行修訂，直至滿足要求。
3.1.1 功能需求分析交付物
制度最佳化及系統建設專案的需求規格說明書，在功能需求說明書提交前根據專案計劃提交頁面示例。
3.2 非功能性處理需求
制度最佳化及系統建設專案應包括但不限於以下的非功能性需求：
3.2.1.1 可靠性、可用性和完整性
系統應至少但不限於滿足以下能力：
l 7 x 24 小時穩定執行。
l 工作日故障恢復時間 2 小時，非工作日故障恢復時間 24 小時；
l 應用崩潰重啟後，關鍵業務狀態可以快速恢復。快速恢復的前提是資料沒有丟失，資料在物理上完整性和業務上的一致性。
3.2.1.2 松耦合結構
要求各個子系統/功能之間耦合度儘可能低，不能因為一個子系統/功能出現問題立刻就擴散到其他子系統/功能，導致對業務服務的大面積故障。
3.2.1.3 標準化外部系統介面處理
為滿足統一辦公需求發展，制度最佳化及系統建設專案需具備與外部應用系統的整合能力。
系統方案需滿足：
l 滿足具備與各外部系統的資料交換能力；
l 滿足具備與各外部系統的應用整合能力。
l 統一的對外應用介面服務能力；
l 介面服務的高安全效能力；
l 介面服務的擴充套件效能力；
l 介面服務的穩定效能力；
l 介面服務的高併發行能力。
3.2.1.4 分散式處理能力
制度最佳化及系統建設專案需要具備分散式處理能力。
應至少但不限於滿足：
l 分散式的資料儲存能力；
l 分散式的計算能力；
l 分散式系統快速部署、備份、快速重建和快速恢復能力；
l 滿足系統服務 7 x 24 小時不間斷能力。
3.2.1.5 業務可擴充套件性
招標方業務處於高速發展的階段，為支援未來的業務開展，需要制度最佳化及系統建設專案提供靈活可擴充套件性。包括但不限於下面的擴充套件性：
l 服務能力的橫向擴充套件性，隨著招標方人員和業務的發展，可以透過增加伺服器數量增強系統的業務處理能力。
l 功能擴充套件性。要求各子系統/模組/功能之間耦合度儘可能低，各子系統/模組/功能之間透過標準化的介面進行資料互動，保障各子系統/模組/功能的高可擴充套件性。
3.2.1.6 高效能要求
投標人提供的總體技術方案應能夠滿足制度最佳化及系統建設專案未來 5 年的業務需要，至少需要支援如下業務規模：
l 支援 1000 人員規模使用，200 人同時線上。
l 在 5 年資料量的基礎上，50 人同時線上壓力下，支援報表內頁面開啟響應時間 5 秒，支援非報表類頁面開啟響應時間 3 秒，複雜頁面開啟響應時間 5 秒。150 人同時線上壓力下，支援報表內頁面開啟響應時間 10 秒，支援非報表類頁面開啟響應時間 5 秒，複雜頁面開啟響應時間 8 秒。
在滿足以上業務規模的前提下，技術方案還應該具備很高的可擴充套件能力，方案涉及的軟硬體均需要具備可橫向擴充套件的能力。
3.2.1.7 資訊保安
制度最佳化及系統建設專案需透過招標人資訊保安部門組織的資訊保安測試。
3.3 概要設計要求
制度最佳化及系統建設專案的概要設計需要滿足以下格式和內容的要求。
3.3.1 概要設計的規範要求
3.3.1.1 概要設計的基本要求
概要設計作為專案的重要文件輸出，必須滿足招標人的規範和要求。包括但不限於：
l 文件及格式要求。文件命名格式要求、修訂歷史要求、文件章節命名和格式要求、各章節格式要求、圖表及說明要求
l 文件評審要求。概要設計文件需要交由招標人專案組進行統一評審，從格式和內容兩方面進行評審，評審不合格的文件需要修訂合格後再評審，直到評審合格。
l 文件版本管理要求。要求所有的文件必須提交到招標人的配置管理庫上進行管理，所有的修訂都要有修訂歷史。
l 原始碼、文件一致性的要求。要求保持原始碼和文件的一致性，任何一邊修改後，需要在同一個版本內修改文件或原始碼。
3.3.1.2 概要設計的內容要求
3.3.1.2.1 程式概要設計要求
要求所有的子系統、模組、類都需要有概要設計。概要設計的內容需要包括：
l 系統，及系統的組成部分。子系統，及子系統的組成部分。
l 類，模組與類的關係。類的主要方法和屬性，主要方法的流程說明。
l 主要業務的整體流程說明
3.3.1.2.2 資料庫程式概要設計要求
要求所有的資料庫表、檢視、儲存過程、包等實體都有概要設計說明，包括但不限於下面的內容：
l 表的說明，及表的欄位屬性的說明，約束屬性的說明，鍵、索引等說明。
l 檢視的說明
l 儲存過程、函式、包的說明
3.3.1.2.3 介面設計詳細說明
要求所有與外部系統和內部系統之間的介面都要有詳細的介面說明，包括但不限於下面的內容：
l 同物採系統的介面詳細說明
l 同財務管理系統的介面詳細說明
l 同移動端 APP 的介面詳細說明
l 同即使通訊系統的介面詳細說明
l 同郵件服務的介面詳細說明
3.3.2 概要設計交付物
制度最佳化及系統建設專案每一個子系統都需要進行概要設計。所有的概要設計文件都需要招標人專案組進行評審，只有評審透過的概要設計才是有效的交付物。
所有的概要設計交付物都必須是有效的，正式的，並已經提交到招標人的配置管理系統進行配置管理。
3.4 程式碼開發要求
3.4.1 符合發行管理平臺的程式碼開發規範
所有程式碼和配置都必須符合程式碼規範約定，包括但不限於：
l 程式碼必須符合招標方的程式碼編寫規範要求；
l 程式碼需完成單元測試，測試通過後才可提交到配置管理庫；
l 招標人專案組會組織程式碼評審，對不符合規範和招標人要求的程式碼將要求投標人進行修改，直到滿足規範要求為止。
3.4.2 符合招標人的版本管理規範
所有的程式碼和配置都必須提交到招標人的配置管理庫中，並按招標人的版本管理規範要求進行相關的操作。包括但不限於：
l 所有程式碼、配置檔案、指令碼檔案、編譯檔案、第三方依賴庫等必須提交到版本控制系統中
l 整合測試的版本必須且僅只能從版本控制系統中獲取。
l 除 H3 流程引擎開發平臺提供的庫外，第三方依賴庫必須經過招標人的確認才可以使用。
l 不得使用盜版和其他未得到授權的原始碼、庫、執行程式。
3.4.3 程式碼開發交付物
需要交付完整的程式碼、配置、指令碼、編譯檔案以及編譯輸出的檔案。所有程式碼開發交付物在交付前都需要招標人評審透過，未透過的評審的程式碼交付物都不是有效的交付物。
所有的程式碼交付物都必須是有效的，正式的，並已經提交到制度最佳化及系統建設專案的配置管理庫進行配置管理。
3.5 整合測試要求
3.5.1 測試工作範圍
按照需求文件中的需求範圍，進行功能測試及效能測試，每輪測試通過後需分別出具具有明確測試結論的功能測試報告和效能測試報告；
投標人進駐現場後，應與招標人商討所測試專案的進展情況，併合理計劃安排各項工作；形成整個測試工作的詳細測試計劃。
根據上述描述的系統要求對軟體系統進行全面測試，至少應從應用系統的功能性、效能、易用性、可靠性、相容性、可擴充套件性和使用者文件等質量特性方面開展測試。
工作包括但不限於：
1） 制定測試計劃，設計測試用例和測試場景，執行測試，報告缺陷，分析測試結果，提交以上所有文件。
2） 功能測試
a) 根據系統《需求說明書》，分析各功能點測試的優先級別。使用者經常使用、關係到系統核心功能、優先級別較高的功能點，測試覆蓋率應達到 100%；
b) 功能測試必須既包括正常輸入和正常業務流程測試，也包括對非法資料輸入和異常處理的測試，且對系統非正常操作的測試用例應占到總數的 20%-30%。
3） 效能測試：
a) 根據《需求說明書》等相關文件，測試在大使用者量、大資料量和長時間連續執行等條件下，系統的響應時間和穩定執行情況。
b) 模擬系統真實環境，測試系統處理高峰資料量的效能指標。
4） 易用性測試：從最終使用者的角度，對系統介面風格一致性、友好性和可用性等方面進行測試。
5） 可靠性測試：對系統在執行過程的持續穩定性，包括系統的容錯能力和對資料的保護能力進行測試。
6） 相容性測試：透過相容性測試，確認應用系統軟體與相關的各種硬體裝置、作業系統、相關支撐軟體以及其他相關應用系統的相容性。
7） 可擴充套件性測試：透過系統可擴充套件性測試，確認應用系統軟體是否可透過開發新的軟體以保證功能的可擴充套件性；是否可透過開發或調整程式以達到效能的可擴充套件性。
8） 使用者文件檢查重點檢查所提交文件的完備性及與實際系統的符合性。
3.5.2 測試標準
投標人應在投標書中列出測試所執行的主要標準。
3.5.3 測試方案
投標人應根據測試工作制定相應的測試方案，完成《制度最佳化及系統建設專案測試方案》，方案內容包括但不限於：
l 測試背景
l 測試標準
l 測試流程
l 採用的測試方法
l 預期的輸出結果
l 參與各方的職責。
3.5.4 測試計劃
投標人需針對每一個系統制定測試計劃，完成《制度最佳化及系統建設專案測試計劃》。測試計劃中需規定被測試的物件、被測試的特性、應完成的測試任務、人員職責及風險等，確定要完成的測試活動，評估完成活動所需要的時間和資源，設計測試組織和崗位職權，進行活動安排和資源分配，安排跟蹤和控制測試過程的活動。
3.5.5 測試用例
投標人需根據測試範圍設計科學合理有效的測試用例及測試指令碼，並對測試用例和指令碼統一管理，要求測試用例具有可重複性、有組織性、可回溯性和可操作性；
3.5.6 測試實施及評估
投標人將獲得的執行結果與預期結果進行比較和分析，記錄、跟蹤和管理系統缺陷，測試後對測試過程進行分析評估，對各系統的缺陷進行分析評估並提出改進意見，最終提交測試報告。
3.5.7 安全測試
制度最佳化及系統建設專案需透過招標人資訊保安部門組織的資訊保安測試。
3.5.8 測試報告
測試報告和測試結果應包含但不侷限於分析說明測試資料值的範圍（包括動態資料和靜態資料）。陳述經測試證實的系統缺陷和限制，陳述系統質量缺陷產生的原因，說明每項缺陷和限制對效能的影響，並說明全部測得的效能缺陷的累積影響和總影響。同時，對每項缺陷提出改進建議，包含但不侷限如：各項修改可採用的修改方法；各項修改的緊迫程度等。
除過程性報告外，測試方需在測試通過後，出具結論性報告，包括《制度最佳化及系統建設專案功能測試報告》、《制度最佳化及系統建設專案測試效能測試報告》。
3.5.9 測試環境
招標人為測試提供系統工作所需的軟硬體測試環境，投標人將使用招標人指定的測試環境。測試所需專用軟體由投標人提供。
投標人應根據本專案實際情況在投標書向招標人提出測試環境的合理建議。
3.5.10 測試工具
測試工具及測試管理工具由投標人提供。
3.5.11 整合測試交付物
專案測試過程中，投標人必須提交（包含但不限於）下列檔案：
Ø 整體測試規劃
Ø 測試範圍分析
Ø 測試方案
Ø 質量等級和評估標準
Ø 測試用例和測試資料
Ø 測試系統功能測試計劃、測試報告及測試缺陷日誌
Ø 測試計劃、測試報告及測試缺陷日誌；
Ø 進度及測試工作彙報
對於投標人提交的文件，當招標人要求時，要經過招標人組織的評審，對文件進行修訂需要進行重新評審。
3.6 新舊系統遷移、相容性、歷史資料要求
3.6.1 系統遷移的基本要求
為了保障當前辦公系統涉及功能平滑遷移到遷移到制度最佳化及系統建設專案，中標方在專案上線期間，必須按要求完成從現有辦公系統到制度最佳化及系統建設專案的遷移工作。
投標人在技術方案中需要包含從現有辦公系統到制度最佳化及系統建設專案的遷移方案，遷移方案需要滿足下面的條件：
l 遷移過程中、遷移後的所有關鍵資料不丟失，特別是流程資料，歸檔資料。
l 遷移後，正在進行中的流程可以無縫流轉，已完結的流程資料可以查詢。
3.6.2 遷移工作投標人承擔的工作
中標方將承擔遷移主要工作，需要招標人協助和確認的工作，需要體現在遷移方案中。中標方承擔的遷移主要工作包括但不限於下面的工作：
l 制定遷移方案，並提供詳細的實施計劃，所有的遷移方案和實施計劃必須得到招標人的評審透過。
l 開發遷移過程中所需要的全部程式和指令碼。
l 開發遷移過程中所需要的全部相容性功能，滿足招標人對遷移過程中的功能和效能要求。
l 實施遷移過程。
l 保障遷移、及遷移後的系統功能的完整性、一致性的要求的其他事項。
3.6.3 相容性要求
1. 移動終端應用軟體支援自動升級，相容主流 Andriod 版本和 IOS 版本。
2. PC 版相容 Win7、Win10，相容 IE8 及以上、360、chrome、firefox、safari 等主流瀏覽器。
3.7 專案管理要求
3.7.1 入場時間、地點
投標人在收到中標通知書後，五個工作日內專案經理、需求分析師、UI 設計人員入場給招標人提供駐場服務。駐場服務地點為北京，具體地址由招標人指定。
除現場辦公用房和研發、測試所需伺服器外，為完成專案工作所需的其他設施、裝置和物品均由投標人自行解決，包括生活設施、交通設施、通訊裝置、辦公裝置等。
3.7.2 專案計劃管理
1. 專案必須編制進度計劃，要求採用 Project 編制，計劃應當涵蓋完整工作範圍，包括關鍵里程碑、任務責任人資訊；專案計劃採用漸進明細原則，原則上最近 1 個月的任務分解的粒度不大於 5 個工作日，並體現任務之間的依賴關係。
2. 專案計劃應當透過招標人的稽核，在專案管理平臺上釋出並形成基線。
3. 專案經理應當根據實際執行情況對專案計劃進行及時調整，涉及到月度里程碑的調整應向招標方提交變更申請表；
4. 計劃應當每週五更新實際完成的百分比，並將更新結果同步到專案管理平臺；
3.7.3 專案質量管理
1. 招標方將針對關鍵里程碑進行評審應；
2. 專案重大質量問題應當及時向招標人報告。
3.7.4 問題與風險管理
1. 專案應建立問題與風險管理記錄表，記錄問題與風險，評估級別，明確責任人、解決日期。
2. 發現可能影響本專案、或專案群其他關聯專案的關鍵里程碑達成的高級別問題或風險，必須及時向專案管理組報告。
3. 並應當每週五更新。
3.7.5 溝通管理
1. 按規範填寫專案週報，在週報中準確彙報進展、是否延期及延期情況、主要問題及風險；
2. 定期釋出專案週報；
3. 定期召開專案例會，對專案進展、下週計劃，問題及風險進行溝通。
3.7.6 專案週期
專案採用迭代和增量式開發方法，參考週期如下：
3.8 *資源投入和人員資質要求
投標方承諾至少投入 35 個人月來完成本專案，這是本專案投入資源的最低要求，如低於 35 個人月，將視為廢標。另外，由於本專案不是簡單的人員外包專案，所以如果投入資源達到 35 個人月，但沒有完成專案目標，也不能視為專案交付，需繼續投入資源，直至完成專案目標且透過招標方的驗收。投標方需要在招標現場提供工時承諾書。
具體投入專案的專案角色及資質要求見下表，專案經理角色可以和需求分析師/高階.NET 開發工程師人員重合：
投標人需提交本專案的組織結構、所有參與該專案人員的工作職責、常駐工作城市、工作簡歷、工作經驗說明及投入本專案的時間計劃，專案組所有成員提供半年以上的社保記錄證明。參與專案的專案經理、UI 設計師、需求分析師、高階.NET 開發工程師在駐場前需透過招標人的專業面試，如未透過，中標方需立即更換具備足夠技能的人員，直至面試透過；在專案過程中，若招標人認為中標方派駐人員不能勝任專業工作，中標方必須一週內更換人員，直至達到招標人的要求；拒不更換的，招標人有權終止合同。
投標人要保證專案經理、UI 設計師、需求分析師、高階.NET 開發工程師的穩定性,參與專案人員除招標人提出更換要求外，不得更換，如需更換，要徵得招標人同意。投標人專案組成員在專案實施期間不得從事與本專案無關的工作。
3.9 培訓要求
3.9.1 知識轉移要求
投標人需要移交針對本專案的所有成果，並對招標人的研發、測試、運維人員進行系統性培訓，使其快速掌握並勝任相關工作。
投標人根據招標人的技術團隊，量身定做其匹配的知識轉移方案，方案內容包括但不限於程式碼開發、系統部署等階段。以最終到達招標人團隊能夠實現系統的運維和後期開發工作。
3.9.2 使用者培訓要求
投標人需要提供對招標人系統使用者關於系統使用方面的培訓，包括課程設計、教材及課件編寫等。
投標人提供約 5 人天培訓。其他使用者的培訓工作由招標人自行負責。
3.10 技術支援服務要求
投標人需提供技術支援服務方案和服務承諾，投標人在投標書中必須明確承諾達到使用者的服務響應要求：
*系統終驗後 1 年內，系統出現不滿足《制度最佳化及系統建設專案需求規格說明書》中功能和非功能性需求的情況，由投標人負責解決。影響全員辦公的核心功能出現故障，需要在 2 小時內提供現場技術支援服務。
* 系統終驗後一年內，投標人提供一年的 7*24 小時技術支援服務，其中需要提供 7*10 小時的現場技術支援服務。非現場支援服務期間應提供電話服務，1 小時內做出明確響應和安排，電話支援不能解決問題，需要在 2 小時內提供現場技術支援服務，並在後續 1 周內給出針對該問題的徹底解決方案和改進建議。