2025軟件需求實施建設指南

軟件需求實施建設指南

PAGE\*ROMAN

II

目次

前 言 Ⅱ

范圍 1

規(guī)范性引用文件

1

術(shù)語和定義

1

系統(tǒng)建設原則

1

可行性分析

2

系統(tǒng)建設方式

2

服務商（供方）管理

3

需求分析階段

3

概要設計階段

4

詳細設計階段

4

軟件編碼階段

4

測試階段

5

試運行階段

5

驗收

5

PAGE

1

軟件需求實施建設

范圍

本文件我司軟件項目實施建設過程建立了一個公共框架，此框架包括在含有軟件的系統(tǒng)、獨立軟件產(chǎn)品和軟件服務的獲取、開發(fā)、運行和維護期間需應用的過程、活動和任務。

本文件只適用于我司作為系統(tǒng)和軟件產(chǎn)品及服務的需方。

規(guī)范性引用文件

下列文件對本文件的應用是必不可少的，凡是注日期的引用文件，僅所注日期的版本適用于本文件，凡是不注日期的引用文件，其最新版本（包括所有的修改單）適用于本文件。

GB/T8566-2007 信息技術(shù)軟件生存周期過程

GB/T8567-2006 計算機軟件文檔編制規(guī)范

GB/T9385-2008 計算機軟件需求規(guī)格說明規(guī)范

RB/T028-2020 實驗室信息管理系統(tǒng)管理規(guī)范

RB/T029-2020 檢測實驗室信息管理系統(tǒng)建設指南

術(shù)語和定義

GB/T8566-2007、GB/T8567-2006、GB/T9385-2008中界定的以及下列術(shù)語和定義適用于本文件。

3.2

供方

提供軟件開發(fā)服務的外部單位或集團具備軟件開發(fā)能力的部門。

3.3

需方

特嗨氫能檢測（保定）有限公司所有需求軟件系統(tǒng)的部門。

系統(tǒng)建設原則

合規(guī)性原則：軟件建設應符合GB/T8566-2007，編制的過程文檔應符合GB/T8567-2006、GB/T

9385-2008。

適用性原則：不同業(yè)務、不同規(guī)模的軟件，業(yè)務流程和管理方式差異較大，項目經(jīng)理應基于自身業(yè)務特點、管理需求、信息化現(xiàn)狀和業(yè)務發(fā)展規(guī)劃裁剪本標準不適用的過程、活動、任務。

用戶參與原則：系統(tǒng)用戶應自始至終參與系統(tǒng)建設過程，保證系統(tǒng)建成后能夠切實為系統(tǒng)用戶所接受；系統(tǒng)功能設計應尊重用戶操作習慣，具有較強的易用性。

可擴展性原則：應采用模塊化、分布式的系統(tǒng)設計思路，保證系統(tǒng)應用規(guī)模、處理能力、新需求功能較易擴展，有效降低系統(tǒng)上線后的升級成本。

安全性原則:安全性原則應貫徹系統(tǒng)建設全過程，通過身份驗證、權(quán)限控制、數(shù)據(jù)校驗、審計跟蹤、數(shù)據(jù)加密、數(shù)據(jù)備份、系統(tǒng)日志等技術(shù)手段，確保系統(tǒng)和數(shù)據(jù)的安全。

可行性分析

需求管理

需求管理是項目管理的基石，需求必須是明確的、可行的和確定的。一般情況下，業(yè)務人員提出用戶需求，輸出《業(yè)務需求文檔》。項目經(jīng)理接收、匯總用戶需求，進行詳細的業(yè)務需求調(diào)研及評估，確定需求目標及合理性，輸出《業(yè)務需求報告》，并將需求納入需求池進行管理，規(guī)劃產(chǎn)品藍圖，排布優(yōu)先級與版本規(guī)劃。

可行性分析

可行性分析有助于提前發(fā)現(xiàn)潛在的問題和風險，確定項目的可行性，以便在投入大量資源前進行決策?？尚行苑治觥Ｖ饕梢栽谝韵聨讉€方面進行可行性分析：

技術(shù)可行性，它涉及評估項目所需的技術(shù)和技術(shù)資源是否可行和可用。這包括評估團隊的技術(shù)能力，所需的硬件和軟件資源，以及項目實施的技術(shù)架構(gòu)和工具。如果技術(shù)可行性不被滿足，那么項目的成功實施將面臨很大的挑戰(zhàn)。

經(jīng)濟可行性，它涉及評估醒目的經(jīng)濟效益和投資回報率。

法律可行性，它涉及評估項目是否符合相關(guān)的法律法規(guī)和法律要求。這包括評估項目是否符合知識產(chǎn)權(quán)法、隱私法和數(shù)據(jù)保護法等方面的要求。

運營可行性，它涉及評估項目是否能夠在實際運營中成功的實施和維護。這包括項目的可維護性、可擴展性和可靠性。

時間可行性，它涉及評估項目是否能夠在規(guī)定的時間內(nèi)網(wǎng)。這包括評估項目的進度計劃、資源分配和風險管理。如果項目無法按時完成，那么它可能會導致額外的成本和延遲。

項目經(jīng)理可通過市場調(diào)研、組織專家評審等方式，對業(yè)務需求進行可行性分析，并輸出《可行性分析報告》

系統(tǒng)建設方式

通用要求

可基于項目規(guī)劃和自身資源情況，選擇以購買或自建方式建設系統(tǒng)軟件。

選擇自建系統(tǒng)時，應確保能有足夠的信息技術(shù)團隊資源，并充分評估自建系統(tǒng)所需面臨的風險如：數(shù)據(jù)庫設計、軟件設計、軟件項目管理、系統(tǒng)維護、持續(xù)改進等。

購買滿足需求的現(xiàn)貨軟件時，應確保供方滿足對此軟件系統(tǒng)的需求，具有有效的文檔，滿足專利

權(quán)、使用權(quán)、擁有權(quán)、擔保權(quán)、和許可權(quán)，具有軟件產(chǎn)品的未來支持計劃。

通過合同購買軟件開發(fā)服務

招標的準備

項目經(jīng)理可通過廠商溝通、產(chǎn)品演示、實際項目考察、征集并評價廠商建議書等活動，初步篩選潛在的服務商。

招標書至少包括項目概況介紹、技術(shù)規(guī)格參數(shù)、項目服務（實施、培訓、技術(shù)支持等）要求、服務商資質(zhì)要求、合同商務條款、投標書編制要求，評標規(guī)則、招投標流程等內(nèi)容。

項目經(jīng)理可根據(jù)服務商的標書、能力評價和其他需要考慮的因素來選擇服務商。

合同簽署

項目經(jīng)理可與服務商一起就合同進行準備和談判，合同應包括項目建設的內(nèi)容、建設周期、驗收標準、售后服務條款、需交付的軟件產(chǎn)品、文檔、服務的費用、保密協(xié)議、知識產(chǎn)權(quán)歸屬、雙方的權(quán)責和義務等。

服務商（供方）管理

供方應提供詳細的項目實施計劃，內(nèi)容包括項目范圍、階段劃分、人員職責、進度計劃、項目里程碑、測試計劃、部署計劃、試運行計劃、驗收計劃及項目質(zhì)量保證計劃等，經(jīng)項目經(jīng)理審核通過后作為項目實施的依據(jù)。

供方應明確項目責任人，項目責任人應每周向我司項目經(jīng)理報告開發(fā)過程中設計變更、開發(fā)進度、預算控制等情況。

開發(fā)過程中，當涉及需求、合同、計劃和關(guān)鍵開發(fā)人員變更時，供方項目負責人應及時向我司項目經(jīng)理提交書面報告并形成《軟件變更單》，如涉及重大調(diào)整時，項目經(jīng)理應組織專家就變更事宜進行論證。

需求分析階段

需求調(diào)研

需方應根據(jù)立項階段的《業(yè)務需求報告》組織會議，同供方一起對業(yè)務需求部門提出的每個系統(tǒng)需求做詳細的需求調(diào)研，并由供方記錄并形成《會議紀要》。

《會議紀要》的主要內(nèi)容有會議時間、會議地點、調(diào)研部門、主持人、記錄人、參與人、會議議題、需求內(nèi)容、需求討論結(jié)果?！稌h紀要》整理完成后需參與人確認簽字。

需求規(guī)格說明書

需求調(diào)研完成后，需方可委托供方人員編寫《需求規(guī)格說明書》，但必須審批供方分析的需求。

系統(tǒng)需求規(guī)格說明書的主要內(nèi)容包括系統(tǒng)的功能與能力；業(yè)務、組織和用戶的需求；應遵守的的標準、規(guī)程；安全、安全保密性、人機工程學（易用性）、接口、運行和維護需求；設計約束和合格性需求。

說明書應是正確、無歧義、完備、一致、可驗證、可修改、可追蹤的。

需求通常使用自然語言來編寫。但自然語言具有固有的不確定性。需方審核使用自然語言編制的需求規(guī)格說明書時應注意識別語言的含糊用法并予以糾正。

需方審核說明書時應注意，說明書不宜含有對軟件設置附件的限制條件或描述任何設計或?qū)崿F(xiàn)的細節(jié)，這些內(nèi)容應當在項目的設計階段進行描述。

概要設計階段

概要設計是把軟件的需求轉(zhuǎn)變?yōu)橐环N體系結(jié)構(gòu)，該體系結(jié)構(gòu)描述其頂層結(jié)構(gòu)并標識各個軟件模塊。此階段應由供方實施人員獨立完成，形成文檔《概要設計說明書》。

概要設計說明書

說明書的主要內(nèi)容包括關(guān)于需求模塊的頂層設計、軟件的外部接口以及軟件的各個軟件部件間的接口的頂層設計、數(shù)據(jù)庫的頂層設計等內(nèi)容。

需方審核說明書時應注意，確保軟件的所有需求都被分配給了其軟件模塊，并得到進一步的細化以便于進行詳細設計。

需方可在此階段要求供方編制用戶操作手冊的最初版本、確定軟件的初步測試需求和進度安排。

若軟件系統(tǒng)需要安裝測試服務器，需方可在此階段要求供方提供服務器詳細參數(shù)。

詳細設計階段

詳細設計是對軟件的每個軟件模塊進行詳細設計，軟件模塊應細化到更低級別，這些級別包含能被編碼、編譯、測試的軟件單元。此階段由供方開發(fā)人員獨立完成，形成文檔《詳細設計說明書》。

詳細設計說明書

說明書的主要內(nèi)容包括軟件模塊的詳細設計，關(guān)于軟件外部接口、軟件部件之間以及軟件單元之間的接口的詳細設計，數(shù)據(jù)庫的詳細設計等內(nèi)容。

需方審核說明書時應注意確保來自這些軟件部件的所有軟件需求都被分配到軟件單元。

需方可在此階段要求供方更新用戶操作手冊、規(guī)定要測試的軟件單元、軟件集成的測試需求和進度安排。

軟件編碼階段

開發(fā)計劃

需方應在此階段要求供方根據(jù)《詳細設計說明書》制定詳細的《開發(fā)計劃》，并交由需方審核。開發(fā)計劃的主要內(nèi)容包括功能模塊分類、軟件單元/接口、負責人、計劃開始時間、計劃結(jié)束時間、完成狀態(tài)等內(nèi)容

需方審核開發(fā)計劃時，應注意每一個軟件單元、接口、數(shù)據(jù)庫都在開發(fā)計劃中。

測試方案

需方應要求供方開發(fā)人員，開發(fā)程序的同時開發(fā)用于測試每一個軟件單元、數(shù)據(jù)庫、集成的測試規(guī)程和數(shù)據(jù)并形成文檔《測試方案》。

測試方案的主要內(nèi)容包括測試范圍、質(zhì)量目標、測試策略、測試資源、測試用例、測試計劃、質(zhì)量風險等內(nèi)容。

軟件整改項清單

為保證開發(fā)質(zhì)量，需方可在此階段時跟進、監(jiān)督供方工作，并提出整改優(yōu)化意見，形成文檔《軟件整改項清單》。

清單主要內(nèi)容包括功能模塊分類、優(yōu)化問題描述、提出人、提出時間、責任人、計劃完成時間、狀態(tài)。功能模塊分類、優(yōu)化問題描述、提出人、提出時間、任務狀態(tài)字段由需方填寫，責任人、計劃完成時間由供方填寫。

清單中的整改項內(nèi)容在供需雙方達成共識后由需方填寫，需方應追蹤、督促供方保質(zhì)保量完成整改項，整改項經(jīng)需方測試完成后由需方關(guān)閉。

需方可在此階段要求供方及時更新用戶操作手冊。

若此系統(tǒng)需部署正式服務器環(huán)境，需方應在此階段要求供方提供詳細的服務器參數(shù)。目前我司無服務器機房，只可申請使用股份云服務器。

測試階段

需方可可根據(jù)但不限于《測試方案》文檔同供方一起針對系統(tǒng)的每一個需求進行測試，測試結(jié)果由供方形成文檔《測試報告》，交由需方審核。

《測試報告》中應包含軟件需求的測試覆蓋率、與預期結(jié)果的符合程度、運行和維護的可行性等內(nèi)容。

此階段時需方應跟進、監(jiān)督供方工作，并提出整改優(yōu)化意見，更新《系統(tǒng)整改項清單》。

試運行階段

上線試運行方案

為保證軟件投入試運行時可正常使用，需方應要求供方提供《上線試運行方案》，經(jīng)需方評審通過后方可進入試運行階段。

方案的主要內(nèi)容包括上線時間、基礎數(shù)據(jù)、接口準備情況、系統(tǒng)部署步驟、各項任務負責人、備用方案等內(nèi)容。

培訓

供方在發(fā)布試運行軟件前，應對需方用戶進行培訓。

需方可要求供方編制《培訓計劃》、《培訓課件》，以線上直播、線下實操的方式對系統(tǒng)用戶進行培訓并發(fā)布《用戶操作手冊》，需方應將培訓資料進行留存。

在此階段供需雙方應根據(jù)用戶請求對用戶提供協(xié)助和咨詢，并將問題記錄歸檔。

系統(tǒng)用戶在試運行期間，若發(fā)現(xiàn)系統(tǒng)B?G或整改項，需方可向供方提出整改要求，如涉及重大調(diào)整時，項目經(jīng)理應組織供方和專家進行評審并更新《系統(tǒng)優(yōu)化項清單》。

對于軟件的每次發(fā)布，供方都應進行測試，需滿足整改需求后方可發(fā)布，并且備份低版本軟件。

若需方條件允許，應進行線上線下并行測試運行，驗證并確認軟件系統(tǒng)可以正常運行。

試運行結(jié)束后，供方應編制《試運行報告》，詳述各軟件模塊試運行情況并交由需方審核。

驗收

供方應以雙方簽署的合同、項目實施方案等有關(guān)規(guī)定為依據(jù)向需方提供《驗收方案》，需方評審通過后進入