- 軟件工程案例教程（第2版）
- 魏雪峰
- 19996字
- 2019-11-18 14:55:57
案例一 實驗教學管理系統分析
【任務描述】
信息工程學院的實驗教學管理文檔一直采用紙質文件，每個學期都要產生大量紙質文檔，這些文檔保存不便、填寫麻煩、數據統計分析困難，難以管理。采用結構化方法開發實驗教學管理系統，需要確定系統是否值得開發、調查用戶的需求，主要包括如下內容：
● 系統可行性分析
● 選擇軟件過程模型
● 分析系統需求
【任務分析】
結構化分析一般包括可行性分析、選擇模型、需求分析?？尚行苑治鐾ㄟ^對系統進行問題定義及經濟可行性、技術可行性、法律可行性、用戶使用可行性等方法的分析，確定系統是否值得開發。在需求分析階段需要同用戶進行深入溝通，準確把握用戶需求，可以通過Visio工具建立功能模型、數據模型和行為模型。
【實施方案】
任務1 實驗教學管理系統可行性分析
1.1 調研軟件開發背景
（1）調研用戶工作現狀，分析軟件開發背景。說明項目在什么條件下提出，提出者的要求、目標、實現環境和限制條件。
信息工程學院實驗教學管理一直采用人工管理方式，實驗過程中產生的大量數據都采用紙質文檔記錄，包括實驗報告、實驗室使用記錄、實驗儀器使用記錄、實驗室課表等。隨著學生人數增多和辦學歷史延伸采用紙質文檔的弊端越來越明顯，學校需要印制、保存大量紙質文檔，學生填寫麻煩、容易出錯，數據統計困難、不準確等，不利于管理和決策。我們需要一個管理信息系統使紙質文檔電子化、幫助管理實驗過程中的數據，實現管理規范化。
（2）確定供需雙方。
軟件用戶方：信息工程學院。
軟件開發方：軟件孵化中心。
1.2 問題定義
調研軟件細節，明確問題定義。在初步調研的基礎上，逐步確定將要研發軟件的具體問題。開發人員對用戶提出的開發問題還需要從專業技術方面進行更深層次的細致調研、分析和定義，主要包括：軟件名稱、軟件提出的背景、軟件目標、軟件類型、軟件服務范圍、基本需求、軟件環境、主要技術、基本條件等。
（1）軟件名稱：實驗教學管理系統。
（2）軟件背景：每個學期都會產生大量實驗教學文檔，紙質文檔保存不便、統計分析困難、浪費資源，迫切需要對這些紙質文檔電子化，實現管理規范、節約資源。
（3）軟件目標：能夠實現實驗報告、實驗室使用記錄、實驗儀器使用記錄等文檔電子化，能夠統計人時數、實驗開出率、各類實驗的比率、一學期的實驗總數等數據進行統計分析。
（4）軟件類型：專用軟件。
（5）軟件服務范圍：軟件先在信息工程學院實驗教學中使用，隨后可以擴展到其他院系。
（6）基本需求：能夠對學期、教師、學生、實驗室、實驗課表、實驗報告、實驗室和儀器使用記錄等進行管理，對實驗室使用、實驗開出率、實驗報告成績、實驗人時數等數據進行統計分析。能夠適合多數人同時使用，反應速度快，界面簡潔，易于操作，每天能夠持續工作24小時。
（7）軟件環境：軟件服務器端可以在Windows、Linux、UNIX等平臺下運行，Web服務器Tomcat 6.0，數據庫：MySQL，客戶端采用Chrome或360瀏覽器。
（8）主要技術：軟件開發采用結構化方法。具體為：可以采取訪談和實地調研獲得分析，建模采用Visio工具輔助建立功能模型、數據模型和動態模型；設計采用成熟的B/S體系結構和SSH框架；編程階段采用SVN進行統一管理，測試采用WinRunner和LoadRunner進行功能和性能測試。
（9）基礎條件：軟件由信息工程學院軟件孵化中心開發，開發人員經驗豐富；用戶方是計算機教師和學生，熟悉軟件開發流程方便溝通。
1.3 經濟可行性分析
從投資和預期經濟效益上進行分析經濟上是否可行。包括基本建設投資（如開發環境、設備、軟件和資料等），其他一次性和非一次性投資（如技術管理費、培訓費、管理費、人員工資、獎金和差旅費等）。
（1）軟件孵化中心成立3年，主要人員是軟件工程專業的老師和學生，擁有專業實驗室，配備專門服務器和計算機，軟硬件資源齊全。實驗教學管理系統的開發得到全院師生的支持，調研方便，實驗教學資料齊全。開發經費全部由學院支付，軟件開發人員也是軟件用戶的一部分，可以節省培訓費、差旅費等。
（2）軟件投入使用后每年節約紙張費用3萬元、節約管理費用3萬元，此外還能節約師生填寫時間和管理者統計分析數據時間，提高管理效率。
（3）實驗教學在很多學校都是管理上的難題，如果該系統投入使用效果好，可以推廣到全校、甚至其他院校使用，將獲得更大收益，節約更多資源。
（4）軟件市場前景好，預期收益大，在經濟上可行。
1.4 技術可行性分析
分析現有資源能否滿足軟件開發?，F有資源（如人員、環境、設備和技術條件等）能否滿足此工程和項目實施要求，若不滿足，應考慮補救措施（如需要分承包方參與、增加人員、投資和設備等），最后確定此工程和項目是否具備技術可行性。
（1）信息工程學院軟件孵化中心現有人員15名，其中教師6名，學生9名。中心成立3年來完成各類項目5項，教師經驗較豐富，學生學習能力強，有時間和精力完成項目。
（2）軟件將采用MyEclipse、Tomcat、MySQL等軟件進行開發，這些軟件穩定，應用范圍廣。主要應用JSP、HTML、JavaScript、JavaBean、Servlet、SSH等技術，這些技術已經成熟，很好地適應了交互站點設計和基于Web的數據庫訪問的要求，也能夠實現功能擴充。
（3）軟件開發需要的硬件環境已經具備，軟件環境已經搭建，網絡環境已經配置。
（4）現有資源可以滿足軟件實施要求，具備技術可行性。
1.5 法律可行性分析
分析軟件開發是否違反法律。
政府，無論是中央政府還是地方政府，一般都用法律規定組織可以做什么，不可以做什么。例如：《合同法》《消費者權益保護法》《專利法》《反不正當競爭法》等對所有企業的行為都做了限制。法規的影響不僅僅限于時間和金錢，它還縮小了管理者可斟酌決定的范圍，限制了可行方案的選擇。根據《中華人民共和國計算機軟件保護條例》（1991年6月4日中華人民共和國國務院令第84號發布）可知實驗教學管理系統的開發不存在侵權、違法和責任，在法律上可行。
1.6 用戶使用可行性分析
用戶單位的行政管理和工作制度；使用人員的素質和培訓要求。
從實驗教學管理系統的使用人員來看，可大致分為四類：
（1）學生：信息工程學院的所有學生和全校其他院系的大一學生；
（2）教職工：信息工程學院的有實驗教學任務的老師；
（3）實驗管理人員：實驗室的管理人員和實驗室主任；
（4）院系領導：信息工程學院的領導和其他部分分管實驗教學的領導。
用戶的素質較高，大部分受過或正在接受本科教育，可以在軟件使用前進行培訓。軟件系統友好的界面及簡便的操作方法，能滿足用戶使用該系統的要求。
1.7 結論
鑒于以上分析，實驗教學管理系統投資少，具有較高的經濟效益和社會效益。該項目在經濟、技術、法律和用戶使用上都是可行的，可以立即立項開發。
1.8 可行性分析報告模板
1 引言
本章分為以下幾條。
1.1 標識
本條應包含本文檔適用的系統和軟件的完整標識，（若適用）包括標識號、標題、縮略詞語、版本號和發行號。
1.2 背景
說明項目在什么條件下提出，提出者的要求、目標、實現環境和限制條件。
1.3 項目概述
本條應簡述本文檔適用的項目和軟件的用途，它應描述項目和軟件的一般特性；概述項目開發、運行和維護的歷史；標識項目的投資方、需方、用戶、開發方和支持機構；標識當前和計劃的運行現場；列出其他有關的文檔。
1.4 文檔概述
本條應概述本文檔的用途和內容，并描述與其使用有關的保密性和私密性的要求。
2 引用文件
本章應列出本文檔引用的所有文檔的編號、標題、修訂版本和日期。本章也應標識不能通過正常的供貨渠道獲得的所有文檔的來源。
3 可行性分析的前提
3.1 項目的要求
3.2 項目的目標
3.3 項目的環境、條件、假定和限制
3.4 進行可行性分析的方法
4 可選的方案
4.1 原有方案的優缺點、局限性及存在的問題
4.2 可重用的系統，與要求之間的差距
4.3 可選擇的系統方案1
4.4 可選擇的系統方案2
4.5 選擇最終方案的準則
5 所建議的系統
5.1 對所建議的系統的說明
5.2 數據流程和處理流程
5.3 與原系統的比較（若有原系統）
5.4 影響（或要求）
5.4.1 設備
5.4.2 軟件
5.4.3 運行
5.4.4 開發
5.4.5 環境
5.4.6 經費
5.5 局限性
6 經濟可行性（成本—效益分析）
6.1 投資
包括基本建設投資（如開發環境、設備、軟件和資料等），其他一次性和非一次性投資（如技術管理費、培訓費、管理費、人員工資、獎金和差旅費等）。
6.2 預期的經濟效益
6.2.1 一次性收益
6.2.2 非一次性收益
6.2.3 不可定量的收益
6.2.4 收益/投資比
6.2.5 投資回收周期
6.3 市場預測
7 技術可行性（技術風險評價）
本公司現有資源（如人員、環境、設備和技術條件等）能否滿足此工程和項目實施要求，若不滿足，應考慮補救措施（如需要分承包方參與、增加人員、投資和設備等），涉及經濟問題應進行投資、成本和效益可行性分析，最后確定此工程和項目是否具備技術可行性。
8 法律可行性
系統開發可能導致的侵權、違法和責任。
9 用戶使用可行性
用戶單位的行政管理和工作制度；使用人員的素質和培訓要求。
10 其他與項目有關的問題
未來可能的變化。
11 注解
本章應包含有助于理解本文檔的一般信息（例如原理）。本章應包含為理解本文檔需要的術語和定義，所有縮略語和它們在文檔中的含義的字母序列表。
附錄
附錄可用來提供那些為便于文檔維護而單獨出版的信息（例如圖表、分類數據）。為便于處理附錄可單獨裝訂成冊。附錄應按字母順序（A, B等）編排。
任務2 選擇軟件過程模型
實驗教學管理系統由信息工程學院提出，經過分析符合立項開發的條件，需要根據項目的性質選擇軟件開發模型。軟件開發模型是軟件開發全部過程、活動和任務的結構框架，能清晰、直觀地表達軟件開發全過程，明確規定完成的主要活動和任務，是軟件項目工作的基礎。
實驗教學管理系統主要管理基礎數據、實驗報告、實驗項目、實驗室使用記錄、實驗儀器使用記錄等，需求明確、規模不大、且不復雜，可以采用瀑布模型。瀑布模型各階段過程如下：經過可行性分析，若結論可行則進行需求分析；評審合格輸出需求分析文檔，進入軟件設計，在設計中遇到不合適的地方，回溯到需求分析；軟件設計完成輸出軟件設計文檔，進入軟件實現階段，若實現中出問題可以回溯到軟件設計和軟件需求階段；軟件實現完成后輸出源文件，進入軟件測試；軟件測試完成后輸出源程序、各階段文檔，進入軟件維護階段，維護階段可能回溯到其他任何階段，模型如圖2-1所示。
圖2-1 瀑布模型
采取瀑布模型后可以管理軟件開發進度、消除軟件開發風險、保證軟件質量。采用瀑布模型必須完成以下工作：
（1）每一階段都要完成規定的文檔。沒有完成文檔，就認為沒有完成該階段的任務。
（2）每一階段都要對完成的文檔進行復審，以便盡早發現問題，消除隱患。
任務3 實驗教學管理系統需求分析
3.1 需求獲取
3.1.1 獲取業務需求
信息工程學院的實驗數據如實驗報告、實驗室使用記錄、實驗儀器使用記錄等都采用紙質記錄，造成保存不便，統計檢索速度慢、不準確，管理繁瑣，數據不完整等。實驗教學管理系統能夠實現實驗數據電子化，方便對實驗教學過程中產生的數據進行管理，節約教師學生實驗時間、節約人力物力資源，方便教學管理人員對數據進行統計分析，提高實驗教學管理效率，促進管理規范化、信息化、正規化。
3.1.2 獲取用戶需求
系統主要角色分三類：學生、教師、管理員。
管理員所需主要功能包括：學生管理、教師管理、機構管理、課程管理、課表管理、儀器使用記錄管理、實驗室管理、統計管理、課表管理、管理員管理、注銷等功能。
教師所需主要功能包括：個人信息管理、實驗室使用記錄管理、師生交流、批改報告、實驗報告成績管理、實驗項目管理、注銷等功能。
學生所需主要功能包括：個人信息管理、儀器使用記錄管理、師生交流、實驗報告管理、查看實驗報告成績、注銷等功能。
3.1.3 確定功能需求
（1）學生管理：管理員輸入學生信息保存到學生表，也可以批量導入學生信息；按院系、專業、班級查詢全部的學生，并對選定的學生可以進行查看詳情、更新、刪除等操作；學生可以查看個人信息詳情（包括登錄賬號和密碼）；教師可以查詢所教班級的學生。
（2）教師管理：管理員輸入教師信息保存到教師表，也可以批量導入教師信息；查詢所有教師，對選定的教師可以進行查看詳情、更新、刪除等操作；教師可以查看個人信息詳情（包括登錄賬號和密碼）。
（3）機構管理：管理員輸入院系、專業、班級信息保存到院系表、專業表、班級表。院系中有專業、專業中有班級、班級中有學生。管理員可以按照級別查詢全部的院系、專業和班級，可以查看院系、專業、班級詳情。當管理員進入不同級別的機構時，就可以在對應級別的機構創建、修改相應的機構。管理員只能刪除再無子機構的機構，然后才能刪除父機構，也可以打印當前的數據頁面。
（4）課程管理：管理員輸入課程信息保存到課程表，可以查詢全部的課程，并對選定的課程可以查看詳情，進行更新、刪除等操作，也可以打印當前的數據頁面。
（5）學期管理：管理員添加學期信息保存到學期表，默認新添加的學期為當前學期，也可以查詢學期信息列表、對選定的學期信息進行修改。
（6）課表管理：管理員輸入上課信息（包括上課時間、地點、課程、教師等）保存到課表，也可以批量導入。還可以按實驗室查詢上課時間，修改和刪除上課信息，也可打印課表。
（7）實驗室管理：管理員錄入實驗室信息保存到實驗室表，可以查詢實驗室使用狀態和詳細信息，并可進行修改、刪除等操作。
（8）儀器使用記錄管理：學生在實驗時填寫儀器使用記錄并保存到儀器使用記錄表，教師和學生都可以查看詳情，對于寫錯的記錄，學生可以刪除。教師在上課時間可以查詢班級全部記錄，還可以導出excel表以便于統計。管理員可以按學期和實驗室查詢某個實驗室的學生儀器使用記錄。
（9）實驗室使用記錄管理：教師在實驗時填寫實驗室使用記錄，并可以修改和刪除當前實驗室使用記錄。教師可以查詢本人以往實驗室使用記錄，并可以查看詳情。管理員可以按學期和實驗室查詢教師使用記錄，并可以查看詳情，還可以導出成excel表。
（10）實驗項目管理：教師添加實驗項目信息保存到實驗項目表，也可以修改、刪除實驗項目、查看詳情。管理員按學期、院系、專業、課程、類型查詢實驗項目，可以查看詳情，也可以打印。
（11）統計管理：管理員可以按院系、專業統計實驗項目數、實驗類型統計、實驗人時數統計、實驗室的使用率、實驗開出率等信息。
（12）實驗報告管理：學生填寫實驗報告并保存到實驗報告表，在教師批改之前可以查看詳情、修改、刪除實驗報告。教師可以查詢自己課程下提交的所有實驗報告、查看實驗報告詳情，可以導出所有實驗報告、批改實驗報告，查看實驗報告成績、統計學生成績。學生可以查看教師對本人此次實驗的評語和分數。
（13）密碼修改：學生和教師可以修改自己的密碼并保存到學生表和教師表中。
（14）師生交流：學生可以選擇教師進行交流，保存到留言表；教師可以看到學生的留言，回復學生留言。
（15）注銷：學生、教師、管理員登錄系統后可以進行注銷。
3.1.4 分析性能需求
正確性需求：系統能夠將添加的部門、學生、教師、實驗報告、實驗項目等基本信息準確地保存到數據庫中。實驗相關數據能夠正確讀取，統計信息要準確。
安全性需求：實驗數據應具有高安全性，需要所有用戶登錄后才能訪問數據。用戶10分鐘內不進行任何操作，賬號自動退出系統。
并發能力：系統最少用戶數量20000人，最大業務并發用戶數不低于1000人，系統數據庫應能同時對一定數量（200人）數據信息進行存儲。
處理時間：系統部署后，在硬件條件和支持軟件條件沒有發生變化的情況下，能夠一直保持運行狀態，直到系統被升級或替代。
響應速度：學生、教師和管理員能在0.2秒內登錄系統，并正確進入到用戶界面，所有人員在查詢、修改、添加、刪除信息時能夠在0.5秒內返回執行結果。
數據恢復：系統出現故障時能恢復到最近的正確狀態。
3.1.5 分析其他需求
開放性：具有良好的可擴充性和可移植性。系統遵循主流的標準和協議，提供與學校現正在使用平臺統一的接口。
界面友好：要求操作界面美觀大方，布局合理，色彩搭配和諧。系統針對不同角色的用戶可提供不同的界面內容和界面形式。
一致性要求：軟件系統應該符合主流軟件的標準，快捷鍵、語言、基本操作流程、交互等設置符合主流軟件。
3.2 分析建模
3.2.1 建立功能模型
（1）繪制頂層數據流圖
根據功能描述，找出外部實體，把整個系統看成一個加工，找出每個實體與系統之間的輸入、輸出信息。
實驗教學管理系統中的實體有3個，分別是教師、學生和管理員。教師與系統的交互主要是實驗項目、留言查看與回復、實驗室使用記錄、實驗報告查看與批改、儀器使用記錄查看；學生與系統的交互主要是實驗報告提交及批改查看、留言及查看回復、儀器使用記錄提交與查看；管理員與系統的交互主要是基礎數據的錄入與管理、統計信息、查詢信息等。頂層數據流圖如圖2-2所示。
圖2-2 頂層數據流圖
頂層圖中數據流說明如下。
統計信息：對實驗項目類型及其比率、實驗開出率、實驗室使用情況、實驗人時數、學期實驗數等數據的統計分析，來自系統，流向管理員。
基礎數據信息：包括學期、院系、專業、班級、實驗室、課程、學生、教師、管理員等基本信息，來自系統，流向管理員。
查詢信息請求：查詢學期、院系、專業、班級、實驗室、課程、學生、教師、管理員、儀器使用記錄、實驗室使用記錄、實驗報告、實驗項目等信息，來自系統，流向管理員。
使用記錄：獲得實驗室使用記錄和儀器使用記錄，來自系統，流向管理員。
添加請求：請求添加儀器使用記錄、留言和實驗報告，來自學生，流向系統。
學生查看請求：學生可以請求查看的內容包括儀器使用記錄、留言、實驗報告、實驗報告成績、個人信息等，來自系統，流向學生。
查看結果：系統顯示學生請求查看的信息。
拒絕的請求：不允許學生進行的操作系統給出的拒絕信息。
新增請求：增加實驗室實驗記錄、實驗項目、回復留言的請求，來自教師，流向系統。
教師查詢請求：查詢學生、實驗室記錄、儀器使用記錄、個人信息等信息的請求，來自教師，流向系統。
查詢結果：教師查詢的學生儀器使用記錄、實驗項目、實驗報告、實驗室使用記錄等信息的顯示。來自系統，流向教師。
拒絕的請求：非上課時間查詢學生儀器使用記錄被拒絕，來自系統，流向教師。
（2）繪制0層數據流圖
0層數據流圖是細化了的頂層數據流圖。根據實驗教學管理系統功能，細化頂層加工繪制0層數據流圖。實驗教學管理系統可以細化為6個子加工：基礎數據管理（包括學期、院系、專業、班級、實驗室、學生、教師、課程等）、實驗室記錄管理、實驗項目管理、實驗報告管理、儀器使用記錄管理、留言管理，如圖2-3所示。
圖2-3 0層數據流圖
0層圖的加工和數據流說明如下。
1）加工說明
基礎數據管理：管理員對學期、院系、專業、班級、實驗室、課程、上課安排、學生、教師、管理員等信息進行管理，可以進行新增、修改、查詢、刪除等操作。
實驗室記錄管理：教師添加實驗室使用記錄，可以對其進行修改、查詢、刪除操作。管理員可以查詢、統計。
實驗項目管理：教師添加實驗項目，可以對其進行修改、查詢、刪除操作。管理員可以查詢、統計。
實驗報告管理：學生添加實驗報告并可以查看，在教師批改之前可進行修改、刪除。教師可以查看、批改、導出實驗報告，管理員也可以查看。
儀器使用記錄管理：學生添加儀器使用記錄，可以刪除、查詢。教師和管理員可以查詢、導出。
留言管理：學生可以對指定教師留言，并查看留言和教師的回復。教師可以查看學生給自己的留言并回復。
2）數據流說明
基礎數據信息：基礎數據包括學期、院系、專業、班級、實驗室、課程、上課安排、學生、教師、管理員等信息，來自管理員，流向系統。
統計項目請求：統計實驗項目的請求，來自管理員，流向系統。
項目統計信息：根據實驗類型、課程、學期等條件進行實驗項目統計的信息，來自系統，流向管理員。
統計請求：統計實驗室使用記錄的請求，來自管理員，流向系統。
實驗室記錄：根據管理員的統計條件返回統計信息，來自系統，流向管理員。
統計記錄請求：請求統計實驗儀器使用記錄，來自管理員，流向系統。
儀器記錄統計信息：根據管理員的統計條件，返回統計結果，來自系統，流向管理員。
添加請求：學生添加實驗報告的請求，來自學生，流向系統。
查看請求：學生查看本人的實驗報告和實驗報告成績的請求，來自學生、流向系統。
實驗報告成績：學生本人的實驗報告成績，來自系統，流向學生。
留言請求：學生留言的請求，來自學生，流向系統。
教師的回復：教師對留言的回復信息，來自系統，流向學生。
添加記錄請求：學生添加儀器使用記錄的請求，來自學生，流向系統。
儀器使用記錄：學生查詢本人的儀器使用記錄信息，來自系統，流向學生。
添加項目請求：教師添加實驗項目的請求，來自教師，流向系統。
查詢項目請求：教師查詢實驗項目的請求，來自教師，流向系統。
報告列表：根據教師的查詢條件，返回學生的實驗報告列表信息，來自系統，流向教師。
查詢報告請求：教師請求查看所教課程的實驗報告，來自教師，流向系統。
回復的留言：教師回復學生留言信息，來自教師，流向系統。
查詢記錄請求：教師請求查詢當前上課班級的實驗儀器使用記錄，來自教師，流向系統。
記錄列表：根據教師的查詢條件，返回當前上課班級的學生儀器使用記錄，來自系統，流向教師。
新增實驗室記錄請求：教師新增實驗室儀器使用記錄，來自教師，流向系統。
項目信息：實驗項目的名稱、類型、學時、實驗要求等信息，來自實驗項目管理，流向實驗報告管理。
課程信息：實驗課程的名稱、上課教師等信息，來自基礎數據管理，流向實驗報告管理。
（3）繪制1層數據流圖
對每一個加工繼續細化。如果加工內還有數據流，可將該加工再細分成幾個子加工，并在各子加工之間畫出數據流，形成第1層數據流圖。本書以實驗項目管理、實驗報告管理和實驗儀器使用記錄管理為例。
1）實驗項目管理加工可以細化為添加、刪除、查詢、修改、統計5個子加工，每個子加工都需要與數據存儲實驗項目表進行交互，數據流圖如圖2-4所示。
圖2-4 1層數據流圖——實驗項目管理
① 加工說明
添加：教師填寫實驗項目名稱、類型、學時、目標、內容等信息，驗證合格后保存到實驗項目表中。
查詢：教師可以查看自己課程的實驗項目，選擇一個可以查詢項目詳細信息。
修改：教師查看項目列表，選擇需要修改的項目，讀取原來的內容，進行修改，驗證合格后將項目保存到實驗項目表中。
刪除：教師可以刪除一個或多個項目。
統計：管理員可以統計一門課程的項目數，可按學期、專業統計實驗類型、實驗數量、類型比率等統計。
② 數據流說明
添加項目請求：教師添加實驗項目的請求。
查詢請求：教師查詢本人添加的實驗項目請求。
刪除請求：教師請求刪除選定的實驗項目請求。
修改請求：教師請求修改選定的實驗項目的請求。
添加的項目：教師新增的實驗項目。
刪除的項目：選定的需要刪除的實驗項目。
修改的信息：教師修改后的實驗項目。
統計請求：管理員統計實驗項目的請求，包括根據學期、課程、實驗類型等條件的請求。
項目統計信息：根據管理員輸入的條件，返回統計信息。
項目信息：實驗項目的信息，包括項目名稱、性質、學時、項目要求等。
③ 數據存儲及數據項說明
實驗項目表=項目ID+項目名稱+項目類型+項目目的+項目環境+項目狀態+開課課程+教師ID+開設學期。
項目ID：整型，長度11，不允許為空。
項目名稱：字符類型，長度20，不允許為空。
項目類型：字符類型，長度20，不允許為空。
項目目的：字符類型，長度255，不允許為空。
項目環境：字符類型，長度255，不允許為空。
項目狀態：字符類型，長度11，不允許為空。
開課課程：字符類型，長度11，不允許為空。
教師ID：整型，允許空。
開設學期：字符類型，長度11，不允許為空。
2）實驗報告管理可以細化為批改、導出、成績統計、查看、修改、添加、查看成績7個子加工，每個加工都要同實驗報告表進行交互，為了避免數據流交叉，將實驗報告表出現2次（如果需要也可以出現多次）。與數據存儲相連的數據流可以沒有名稱，其他數據流必須有名稱，如圖2-5所示。
圖2-5 1層數據流圖——實驗報告管理
① 加工說明
添加：學生請求添加實驗報告，按照實驗學期、項目、姓名、班級、實驗室，填寫實驗目的、內容、結論等信息，驗證合格后保存到實驗報告表中。只有已提交的實驗報告，教師才能看到。
查看：學生可以查看所有實驗報告（提交的和未提交的）、教師能查看所有提交的實驗報告。
修改：學生可以查看自己所有的實驗報告，選擇一個查看詳情并請求修改，將修改信息填寫完成后，驗證合格保存到實驗報告表中。
批改：教師能夠查看自己課程的所有學生提交的實驗報告，選擇一個查看詳情進行批改，批改要寫評語和給出實驗成績。
導出：教師可以按實驗項目導出所有學生提交的實驗報告。
成績統計：教師批改完成后可以查看所有學生的成績，統計出及格、不及格、優秀學生人數。
查看成績：教師批改后，學生在實驗報告列表中可以看到實驗成績，通過詳情可以看到教師的評語和成績。
② 數據流說明
批改請求：教師請求批改選擇的實驗報告。
成績：教師錄入的實驗報告成績。
查詢請求：教師查詢實驗報告的請求，請求的條件可根據實驗項目和實驗班級來查詢。學生的查詢請求依據學生本人信息和課程來查詢。
導出請求：教師請求導出一個班的某個實驗項目的所有實驗報告請求。
添加報告請求：學生請求添加實驗報告。
實驗報告：包含課程信息、實驗項目、實驗室、教師、學期、實驗目的、實驗要求、實驗內容、實驗結果等信息的實驗報告。
拒絕信息：教師批改實驗報告后，學生提出請求修改實驗報告被拒絕的信息。
③ 數據存儲及數據項說明
A．實驗報告表=實驗報告ID+學期+課程+實驗項目ID+班級+學生+實驗室+填寫時間+內容+結果+評語+成績+教師ID+批閱時間+實驗報告狀態。
實驗報告ID：整型，長度11，不允許為空。
學期：字符類型，長度11，不允許為空。
課程：字符類型，長度11，不允許為空。
實驗項目ID：整型，長度11，不允許為空。
班級：字符類型，長度11，不允許為空。
學生：字符類型，長度11，不允許為空。
實驗室：字符類型，長度11，不允許為空。
填寫時間：字符類型，長度30，不允許為空。
內容：文本類型，允許空。
結果：文本類型，允許空。
評語：文本類型，允許空。
成績：浮點類型，不允許為空。
教師ID：整型，可以為空。
批閱時間：字符類型，長度20，允許空。
實驗報告狀態：整型，長度11，不允許為空，取值0、1、2。
B．學期表=學期ID+學期名稱+學期狀態
學期ID：整型，長度11，不允許為空，主鍵。
學期名稱：字符類型，長度50，不允許為空。
學期狀態：字符類型，長度11，不允許為空。
C．實驗室表=實驗室ID+實驗室編號+實驗室名稱+實驗室位置+實驗室機器數量+實驗室聯系方式+實驗室狀態
實驗室ID：整型，長度11，不允許為空。
實驗室編號：字符型10，不允許為空，且不允許重復。
實驗室位置：字符型20，允許空。
實驗室機器數量：整型，11位，允許空。
實驗室聯系方式：字符型，20位，允許空。
實驗室狀態：整型，11位，允許空。
D．課程表=課程ID+課程編號+課程名稱+課程類型+課程學分+開設專業+開設學期
課程ID：整型11位，不允許空。
課程編號：字符型，20位，不允許空，唯一。
課程名稱：字符型，20位，允許空。
課程類型：字符型，20位，允許空。
課程學分：浮點型，允許空。
開設專業：整型11位，與專業表關聯。
開設學期：整型11位，與學期表關聯。
E．教師表=教師ID+教師工號+教師姓名+教師職稱+教師密碼+教師性別+教師電話+教師院系
教師ID：整型，11位，不允許空。
教師工號：字符型，15位，不允許空，唯一。
教師姓名：字符型，20位，不允許空。
教師職稱：字符型，20位，不允許空。
教師密碼：字符型，50位，不允許空。
教師性別：字符型，4位，允許空。
教師電話：字符型20位，允許空。
教師院系：整型11位，不允許空，與院系表關聯。
3）儀器使用記錄管理
儀器使用記錄管理可以細化為添加儀器使用記錄、刪除儀器使用記錄、查詢儀器使用記錄、導出儀器使用記錄、統計儀器使用記錄5個子加工，每個子加工都需要與數據存儲實驗儀器使用記錄表進行交互，其數據流圖如圖2-6所示。
圖2-6 儀器使用記錄管理數據流圖
數據存儲及數據項說明如下：
A．班級表=班級ID+班級編號+班級名稱+學生人數+所屬專業
班級ID：整型11位，不允許為空。
班級編號：字符型8位，不允許空。
班級名稱：字符型20位，允許空。
學生人數：整型11位，允許空。
所屬專業：整型11位，與專業表關聯。
B．課表=課ID+周幾+上課時間+單雙周+學期ID+班級ID+實驗室ID+課程ID+教師ID
課ID：整型11位，不允許空。
周幾：字符型15位，允許空。
上課時間：字符型15位，允許空。
單雙周：字符型15位，允許空。
學期ID：整型11位，與學期表關聯。
班級ID：整型11位，與班級表關聯。
實驗室ID：整型11位，與實驗室表關聯。
課程ID：整型11位，與課程表關聯。
教師ID：整型11位，與教師表關聯。
C．儀器使用記錄表=儀器使用記錄ID+儀器使用記錄日期+運行啟動時間+運行終止時間+實際使用時數+儀器使用附件+設備編號+機器IP+項目ID+學生ID+教師ID+班級ID+實驗室ID+學期ID
儀器使用記錄ID：整型11位，不允許空。
儀器使用記錄日期：字符型20位，允許空。
運行啟動時間：字符型15位，允許空。
運行終止時間：字符型15位，允許空。
實際使用時數：浮點型，允許空。
儀器使用附件：字符型20位，允許空。
設備編號：字符型10位，允許空。
機器IP：字符型20位，允許空。
項目ID：整型11位，與項目表關聯。
學生ID：整型11位，與學生表關聯。
教師ID：整型11位，與教師表關聯。
班級ID：整型11位，與班級表關聯。
實驗室ID：整型11位，與實驗室表關聯。
學期ID：整型11位，與學期表關聯。
4）根據自頂向下，逐層分解的原則，對1層圖中全部或部分加工環節進行分解。以修改實驗報告為例。得到修改實驗報告請求后，首先要檢查實驗報告的狀態，如果教師已經批改過，則不允許修改；若沒有批改，則可以修改。修改后的信息要進行檢查，如果有必填項是空白，則不允許提交；信息合格，則保存到實驗報告表中。其數據流圖如圖2-7所示。
圖2-7 修改實驗報告數據流圖
數據加工說明如下。
檢查狀態：系統接收到學生修改請求后，首先檢查實驗報告狀態，若狀態為已經批改，則拒絕修改請求；若未批改，則允許修改。
讀取內容：從數據庫中讀取原來的實驗內容。
檢查：修改的信息是否符合數據要求，不符合則返回不合格的信息，合格進行提交。
提交：將修改后的信息提交到數據庫，保存到實驗報告表。
5）對圖進行檢查和合理布局，主要檢查分解是否恰當、徹底，DFD中各層是否有遺漏、重復、沖突之處，各層DFD及同層DFD之間關系是否正確及命名、編號是否確切、合理等，對錯誤及不當之處進行修改。
修改后和用戶進行交流，在用戶完全理解數據圖的內容的基礎上征求用戶的意見。
3.2.2 建立數據模型
（1）找出所有實體，確定實體屬性。
實驗教學管理系統的主要實體及其屬性如下。
管理員：管理員賬號、管理員密碼、管理員名字、管理員聯系電話。
院系：院系編號、院系名稱、院系聯系電話、院系地址。
專業：專業編號、專業名稱、所屬院系。
班級：班級編號、班級名稱、班級人數、所屬專業。
學生：學生學號、學生姓名、學生性別、學生密碼、所屬班級。
教師：教師工號、教師姓名、教師性別、教師密碼、教師職稱、教師電話、所屬院系。
實驗室：實驗室編號、實驗室名稱、實驗室位置、實驗室機器數量、實驗室聯系方式、開放狀態。
課程：課程編號、課程名稱、課程類型、課程學分、開設專業、開設學期。
實驗項目：項目名稱、項目類型、項目目的、項目環境、項目狀態、開設課程、教師ID、開設學期。
學期：學期名稱。
實驗儀器使用記錄：儀器使用記錄日期、工作內容、運行啟動時間、運行終止時間、使用附件、設備編號、機器IP、實際使用時數、使用人、教師簽名、備注、實驗室、學期。
實驗室使用記錄：實驗室使用記錄日期、工作內容、實驗時間、實驗人數、儀器使用情況、設備編號、機器IP、教師簽名、實驗班級、實驗室、學期。
實驗報告：學期、課程、項目、班級、學生、實驗室、填寫實驗報告時間、實驗內容、實驗結果、教師評論、實驗報告成績、教師ID。
課表：學期、班級、實驗室、課程、教師、周、上課時間、單雙周制。
留言：交流標題、交流內容、交流狀態、教師回復、學生、教師。
（2）確定實體間的聯系，畫出實體聯系圖（E-R圖）。
一個院系可以擁有多個專業，一個專業屬于一個院系，關系是一對多。
一個專業可以擁有多個班級，一個班級屬于一個專業，關系是一對多。
一個班級可以擁有多個學生，一個學生屬于一個班級，關系是一對多。
一個院系可以擁有多個教師，一個教師屬于一個院系，關系是一對多。
一個教師可以教授多門課程，一門課程可以被一個或多個教師所教授，授課與教師的關系是多對一，且授課與課程的關系也是多對一，以授課表為連接，實現教師與課程的關系是多對多。
一個課程可以有多個實驗項目，一個實驗項目屬于一個課程，關系是一對多。
一個實驗項目可以有多個實驗報告，一個實驗報告屬于一個實驗項目，關系是一對多。
一個院系可以有多個實驗室，一個實驗室屬于一個院系，關系是一對多。
一個實驗室可以有多個儀器使用記錄，一個儀器使用記錄屬于一個實驗室，關系是一對多。
一個實驗室可以有多個實驗室使用記錄，一個實驗室使用記錄屬于一個實驗室，關系是一對多。
一個學生可以寫多個留言，一個留言屬于一個學生，關系是一對多。
一個教師可以寫多個留言，一個留言屬于一個教師，關系是一對多。
實體及其聯系如圖2-8所示。
圖2-8 E-R圖
3.2.3 建立行為模型
（1）確定狀態圖的主體，可以是一個系統，也可以是一個對象，本書以實驗報告和實驗項目為例。
（2）確定主題的生存期的各種穩定狀態及順序。
實驗報告的狀態是：創建、保存、完成、查看、批改、導出、刪除。
實驗項目的狀態是：創建、完成、查看、修改、刪除。
（3）確定狀態遷移的事件。
● 實驗報告狀態遷移的事件如下：
創建到保存的事件：暫存。
保存到刪除的事件：選擇刪除。
創建到完成的事件：提交。
保存到完成的事件：提交。
完成到導出的事件：選擇導出。
完成到查看的事件：選擇查看。
查看到批改的事件：進行批改。
批改到完成的事件：繼續批改。
● 實驗項目狀態遷移的事件如下：
創建到完成的事件：提交。
完成到查看的事件：選擇查看。
查看到修改的事件：選擇修改。
修改到完成的事件：確定修改。
完成到刪除的事件：選擇刪除。
（4）繪制狀態圖
實驗報告狀態圖如圖2-9所示。
圖2-9 實驗報告狀態圖
實驗項目狀態圖如圖2-10所示。
圖2-10 實驗項目狀態圖
（5）審核狀態圖，確定每個狀態都可以結束。
3.3 軟件需求規格說明書模板
1 范圍
本章應分為以下幾條。
1.1 標識
本條應包含本文檔適用的系統和軟件的完整標識，也可以包括標識號、標題、縮略詞語、版本號和發行號。
1.2 系統概述
本條應簡述本文檔適用的系統和軟件的用途，它應描述系統和軟件的一般特性；概述系統開發、運行和維護的歷史；標識項目的投資方、需方、用戶、開發方和支持機構；標識當前和計劃的運行現場；列出其他有關的文檔。
1.3 文檔概述
本條應概述本文檔的用途和內容，并描述與其使用有關的保密性或私密性要求。
1.4 基線
說明編寫本系統設計說明書所依據的設計基線。
2 引用文件
本章應列出本文檔引用的所有文檔的編號、標題、修訂版本和發行日期，也應標識不能通過正常的供貨渠道獲得的所有文檔的來源。
3 需求
本章應分以下幾條描述CSCI需求，也就是，構成CSCI驗收條件的CSCI的特性。CSCI需求是為了滿足分配給該CSCI的系統需求所形成的軟件需求。給每個需求指定項目唯一標識符，以支持測試和可追蹤性。并以一種可以定義客觀測試的方式來陳述需求。如果每個需求有關的合格性方法和對系統需求的可追蹤性。在相應的章中沒有提供，則在此進行注解。描述的詳細程度遵循以下規則：應包含構成CSCI驗收條件的那些CSCI特性，需方愿意推遲到設計時留給開發方說明的那些特性。如果在給定條中沒有需求的話，本條應如實陳述。如果某個需求在多條中出現，可以只陳述一次而在其他條直接引用。
3.1 所需的狀態和方式
如果需要CSCI在多種狀態和方式下運行，且不同狀態和方式具有不同的需求的話，則要標識和定義每一狀態和方式，狀態和方式的例子包括：空閑、準備就緒、活動、事后分析、培訓、降級、緊急情況和后備等。狀態和方式的區別是任意的，可以僅用狀態描述CSCI，也可以僅用方式、方式中的狀態、狀態中的方式或其他有效方式描述。如果不需要多個狀態和方式，不需人為加以區分，應如實陳述；如果需要多個狀態或方式，還應使本規格說明中的每個需求或每組需求與這些狀態和方式相關聯，關聯可在本條或本條引用的附錄中用表格或其他的方法表示，也可在需求出現的地方加以注解。
3.2 需求概述
3.2.1 目標
a．本系統的開發意圖、應用目標及作用范圍（現有產品存在的問題和建議產品所要解決的問題）。
b．本系統的主要功能、處理流程、數據流程及簡要說明。
c．表示外部接口和數據流的系統高層次圖。說明本系統與其他相關產品的關系，是獨立產品還是一個較大產品的組成部分（可用方框圖說明）。
3.2.2 運行環境
簡要說明本系統的運行環境（包括硬件環境和支持環境）的規定。
3.2.3 用戶的特點
說明是哪一種類型的用戶，從使用系統來說，有些什么特點。
3.2.4 關鍵點
說明本軟件需求規格說明書中的關鍵點（例如：關鍵功能、關鍵算法和所涉及的關鍵技術等）。
3.2.5 約束條件
列出進行本系統開發工作的約束條件（例如：經費限制、開發期限和所采用的方法與技術，以及政治、社會、文化、法律等）。
3.3 需求規格
3.3.1 軟件系統總體功能/對象結構
對軟件系統總體功能/對象結構進行描述，包括結構圖、流程圖或對象圖。
3.3.2 軟件子系統功能/對象結構
對每個主要子系統中的基本功能模塊/對象進行描述，包括結構圖、流程圖或對象圖。
3.3.3 描述約定
通常使用的約定描述（數學符號、度量單位等）。
3.4 CSCI能力需求
本條應分條詳細描述與CSCI每一能力相關聯的需求?！澳芰Α北欢x為一組相關的需求?？梢杂谩肮δ堋薄靶阅堋薄爸黝}”“目標”或其他適合用來表示需求的詞來替代“能力”。
3.4.1 （CSCI能力）
本條應標識必需的每一個CSCI能力，并詳細說明與該能力有關的需求。如果該能力可以更清晰地分解成若干子能力，則應分條對子能力進行說明。該需求應指出所需的CSCI行為，包括適用的參數，如響應時間、吞吐時間、其他時限約束、序列、精度、容量（大小/多少）、優先級別、連續運行需求、和基于運行條件的允許偏差。部分軟件需求還應包括在異常條件、非許可條件或越界條件下所需的行為，錯誤處理需求和任何為保證在緊急時刻運行的連續性而引人到CSCI中的規定。在確定與CSCI所接收的輸入和CSCI所產生的輸出有關的需求時，應考慮在本文3.5.x給出要考慮的主題列表。
對于每一類功能或者對于每一個功能，需要具體描寫其輸入、處理和輸出的需求。
a．說明
描述此功能要達到的目標、所采用的方法和技術，還應清楚說明功能意圖的由來和背景。
b．輸入
包括：
1）詳細描述該功能的所有輸入數據，如：輸入源、數量、度量單位、時間設定和有效輸入范圍等。
2）指明引用的接口說明或接口控制文件的參考資料。
c．處理
定義對輸入數據、中間參數進行處理以獲得預期輸出結果的全部操作。包括：
1）輸入數據的有效性檢查。
2）操作的順序，包括事件的時間設定。
3）異常情況的響應，例如，溢出、通信故障、錯誤處理等。
4）受操作影響的參數。
5）用于把輸入轉換成相應輸出的方法。
6）輸出數據的有效性檢查。
d．輸出
1）詳細說明該功能的所有輸出數據，例如，輸出目的地、數量、度量單位、時間關系、有效輸出范圍、非法值的處理、出錯信息等。
2）有關接口說明或接口控制文件的參考資料。
3.5 CSCI外部接口需求
本條應分條描述CSCI外部接口的需求。外部接口需求，應分別說明：
a．用戶接口；
b．硬件接口；
c．軟件接口；
d．通信接口的需求。
3.5.1 接口標識和接口圖
本條應標識所需的CSCI外部接口，也就是CSCI和與它共享數據、向它提供數據或與它交換數據的實體的關系。每個接口標識應包括項目唯一標識符，并應用名稱、序號、版本和引用文件指明接口的實體（系統、配置項、用戶等）。該標識應說明哪些實體具有固定的接口特性（因而要對這些接口實體強加接口需求），哪些實體正被開發或修改（從而接口需求已施加給它們）?？捎靡粋€或多個接口圖來描述這些接口。
3.5.2 （接口的項目唯一標識符）
本條（從3.5.2開始）應通過項目唯一標識符標識CSCI的外部接口，簡單地標識接口實體，根據需要可分條描述為實現該接口而強加于CSCI的需求。該接口所涉及的其他實體的接口特性應以假設或“當[未提到實體]這樣做時，CSCI將……”的形式描述，而不描述為其他實體的需求。本條可引用其他文檔（如：數據字典、通信協議標準、用戶接口標準）代替在此所描述的信息。需求也可以包括下列內容：
a．CSCI必須分配給接口的優先級別；
b．要實現的接口的類型的需求（如：實時數據傳送、數據的存儲和檢索等）；
c．CSCI必須提供、存儲、發送、訪間、接收的單個數據元素的特性，如：
1）名稱/標識符；
a）項目唯一標識符；
b）非技術（自然語言）名稱；
c）標準數據元素名稱；
d）技術名稱（如代碼或數據庫中的變量或字段名稱）；
e）縮寫名或同義名；
2）數據類型（字母數字、整數等）；
3）大小和格式（如：字符串的長度和標點符號）；
4）計量單位（如：米、元、納秒）；
5）范圍或可能值的枚舉（如：0～99）；
6）準確度（正確程度）和精度（有效數字位數）；
7）優先級別、時序、頻率、容量、序列和其他的約束條件，如：數據元素是否可被更新和業務規則是否適用；
8）保密性和私密性的約束；
9）來源（設置/發送實體）和接收者（使用/接收實體）；
d．CSCI必須提供、存儲、發送、訪問、接收的數據元素集合體（記錄、消息、文件、顯示和報表等）的特性，如：
1）名稱/標識符；
a）項目唯一標識符；
b）非技術（自然語言）名稱；
c）技術名稱（如代碼或數據庫的記錄或數據結構）；
d）縮寫名或同義名；
2）數據元素集合體中的數據元素及其結構（編號、次序、分組）；
3）媒體（如盤）和媒體中數據元素/數據元素集合體的結構；
4）顯示和其他輸出的視聽特性（如：顏色、布局、字體、圖標和其他顯示元素、蜂鳴器以及亮度等）；
5）數據元素集合體之間的關系。如排序/訪問特性；
6）優先級別、時序、頻率、容量、序列和其他的約束條件，如：數據元素集合體是否可被修改和業務規則是否適用；
7）保密性和私密性約束；
8）來源（設置/發送實體）和接收者（使用/接收實體）；
e. CSCI必須為接口使用通信方法的特性。如：
1）項目唯一標識符；
2）通信鏈接/帶寬/頻率/媒體及其特性；
3）消息格式化；
4）流控制（如：序列編號和緩沖區分配）；
5）數據傳送速率，周期性/非周期性，傳輸間隔；
6）路由、尋址、命名約定；
7）傳輸服務，包括優先級別和等級；
8）安全性/保密性/私密性方面的考慮，如：加密、用戶鑒別、隔離和審核等；
f. CSCI必須為接口使用協議的特性，如：
1）項目唯一標識符；
2）協議的優先級別/層次；
3）分組，包括分段和重組、路由和尋址；
4）合法性檢查、錯誤控制和恢復過程；
5）同步，包括連接的建立、維護和終止；
6）狀態、標識、任何其他的報告特征；
g．其他所需的特性，如：接口實體的物理兼容性（尺寸、容限、負荷、電壓和接插件兼容性等）。
3.6 CSCI內部接口需求
本條應指明CSCI內部接口的需求（如有的話）。如果所有內部接口都留待設計時決定，則需在此說明這一事實。如果要強加這種需求，則可考慮本文檔的3.5給出的一個主題列表。
3.7 CSCI內部數據需求
本條應指明對CSCI內部數據的需求，（若有）包括對CSCI中數據庫和數據文件的需求。如果所有有關內部數據的決策都留待設計時決定，則需在此說明這一事實。如果要強加這種需求，則可考慮在本文檔的3.5.x.c和3.5.x.d給出的一個主題列表。
3.8 適應性需求
本條應指明要求CSCI提供的、依賴于安裝的數據有關的需求（如：依賴現場的經緯度）和要求CSCI使用的、根據運行需要進行變化的運行參數（如：表示與運行有關的目標常量或數據記錄的參數）。
3.9 保密性需求
本條應描述有關防止對人員、財產、環境產生潛在的危險或把此類危險減少到最低的CSCI需求，包括：為防止意外動作和無效動作必須提供的安全措施。
3.10 保密性和私密性需求
本條應指明保密性和私密性的CSCI需求，包括：CSCI運行的保密性/私密性環境、提供的保密性或私密性的類型和程度。CSCI必須經受的保密性/私密性的風險、減少此類危險所需的安全措施、CSCI必須遵循的保密性/私密性政策、CSCI必須提供的保密性/私密性審核、保密性/私密性必須遵循的確證/認可準則。
3.11 CSCI環境需求
本條應指明有關CSCI必須運行的環境的需求。例如，包括用于CSCI運行的計算機硬件和操作系統。
3.12 計算機資源需求
本條應分以下各條進行描述。
3.12.1 計算機硬件需求
本條應描述cSc1使用的計算機硬件需求，（若適用）包括：各類設備的數量、處理器、存儲器、輸入/輸出設備、輔助存儲器、通信/網絡設備和其他所需的設備的類型、大小、容量及其他所要求的特征。
3.12.2 計算機硬件資源利用需求
本條應描述CSCI計算機硬件資源利用方面的需求，如：最大許可使用的處理器能力、存儲器容量、輸入/輸出設備能力、輔助存儲器容量、通信/網絡設備能力。描述（如每個計算機硬件資源能力的百分比）還包括測量資源利用的條件。
3.12.3 計算機軟件需求
本條應描述CSCI必須使用或引人CSCI的計算機軟件的需求，例如包括：操作系統、數據庫管理系統、通信/網絡軟件、實用軟件、輸入和設備模擬器、測試軟件、生產用軟件。必須提供每個軟件項的正確名稱、版本、文檔引用。
3.12.4 計算機通信需求
本條應描述CSCI必須使用的計算機通信方面的需求，例如包括：連接的地理位置、配置和網絡拓撲結構、傳輸技術、數據傳輸速率、網關、要求的系統使用時間、傳送/接收數據的類型和容量、傳送/接收/響應的時間限制、數據的峰值、診斷功能。
3.13 軟件質量因素
本條應描述合同中標識的或從更高層次規格說明派生出來的對CSCI的軟件質量方面的需求，例如包括有關CSCI的功能性（實現全部所需功能的能力）、可靠性（產生正確、一致結果的能力）、可維護性（易于更正的能力）、可用性（需要時進行訪間和操作的能力）、靈活性（易于適應需求變化的能力）、可移植性（易于修改以適應新環境的能力）、可重用性（可被多個應用使用的能力）、可測試性（易于充分測試的能力）、易用性（易于學習和使用的能力）以及其他屬性的定量需求。
3.14 設計和實現的約束
本條應描述約束CSCI設計和實現的那些需求。這些需求可引用適當的標準和規范。
例如需求包括：
a．特殊CSCI體系結構的使用或體系結構方面的需求，例如：需要的數據庫和其他軟件配置項；標準部件、現有的部件的使用；需方提供的資源（設備、信息、軟件）的使用；
b．特殊設計或實現標準的使用；特殊數據標準的使用；特殊編程語言的使用；
c．為支持在技術、風險或任務等方面預期的增長和變更區域，必須提供的靈活性和可擴展性．
3.15 數據
說明本系統的輸入、輸出數據及數據管理能力方面的要求（處理量、數據量）。
3.16 操作
說明本系統在常規操作、特殊操作以及初始化操作、恢復操作等方面的要求。
3.17 故障處理
說明本系統在發生可能的軟硬件故障時，對故障處理的要求。包括：
a．說明屬于軟件系統的問題；
b．給出發生錯誤時的錯誤信息；
c．說明發生錯誤時可能采取的補救措施。
3.18 算法說明
用于實施系統計算功能的公式和算法的描述。包括：
a．每個主要算法的概況；
b．用于每個主要算法的詳細公式。
3.19 有關人員需求
本條應描述與使用或支持CSCI的人員有關的需求，包括人員數量、技能等級、責任期、培訓需求、其他的信息。如：同時存在的用戶數量的需求，內在幫助和培訓能力的需求，還應包括強加于CSCI的人力行為工程需求，這些需求包括對人員在能力與局限性方面的考慮：在正常和極端條件下可預測的人為錯誤，人為錯誤造成嚴重影響的特定區域，例如包括錯誤消息的顏色和持續時間、關鍵指示器或關鍵的物理位置以及聽覺信號的使用的需求。
3.20 有關培訓需求
本條應描述有關培訓方面的CSCI需求。包括：在CSCI中包含的培訓軟件。
3.21 有關后勤需求
本條應描述有關后勤方面的CSCI需求，包括：系統維護、軟件支持、系統運輸方式、供應系統的需求、對現有設施的影響、對現有設備的影響。
3.22 其他需求
本條應描述在以上各條中沒有涉及到的其他CSCI需求。
3.23 包裝需求
本條應描述需交付的CSCI在包裝、加標簽和處理方面的需求。
3.24 需求的優先次序和關鍵程度
本條應給出本規格說明中需求的、表明其相對重要程度的優先順序、關鍵程度或賦予的權值，如：標識出那些認為對安全性、保密性或私密性起關鍵作用的需求，以便進行特殊的處理。如果所有需求具有相同的權值，本條應如實陳述。
4 合格性規定
本章定義一組合格性方法，對于第3章中每個需求，指定所使用的方法，以確保需求得到滿足?？梢杂帽砀裥问奖硎驹撔畔?，也可以在第3章的每個需求中注明要使用的方法。合格性方法包括：
a．演示：運行依賴于可見的功能操作的CSCI或部分CSCI，不需要使用儀器、專用測試設備或進行事后分析；
b．測試：使用儀器或其他專用測試設備運行CSCI或部分CSCI，以便采集數據供事后分析使用；
c．分析：對從其他合格性方法中獲得的積累數據進行處理，例如測試結果的歸約、解釋或推斷；
d．審查：對CSCI代碼、文檔等進行可視化檢查；
e．特殊的合格性方法。任何應用到CSCI的特殊合格性方法，如：專用工具、技術、過程、設施、驗收限制。
5 需求可追蹤性
本章應包括：
a．從本規格說明中每個CSCI的需求到其所涉及的系統（或子系統）需求的可追蹤性。（該可追蹤性也可以通過對第3章中的每個需求進行注釋的方法加以描述）。
注：每一層次的系統細化可能導致對更高層次的需求不能直接進行追蹤。例如：建立多個CSCI的系統體系結構設計可能會產生有關CSCI之間接口的需求，而這些接口需求在系統需求中并沒有被覆蓋，這樣的需求可以被追蹤到諸如“系統實現”這樣的一般需求，或被追蹤到導致它們產生的系統設計決策上。
b．從分配到被本規格說明中的CSCI的每個系統（或子系統）需求到涉及它的CSCI需求的可追蹤性。分配到CSCI的所有系統（或子系統）需求應加以說明。追蹤到IRS中所包含的CSCI需求可引用IRS.
6 尚未解決的問題
如需要，可說明軟件需求中的尚未解決的遺留問題。
7 注解
本章應包含有助于理解本文檔的一般信息（例如背景信息、詞匯表、原理）。本章應包含為理解本文檔需要的術語和定義，所有縮略語和它們在文檔中的含義的字母序列表。
附錄
附錄可用來提供那些為便于文檔維護而單獨出版的信息（例如圖表、分類數據）。為便于處理，附錄可單獨裝訂成冊。附錄應按字母順序（A, B等）編排。
備注：以上描述，可根據軟件項目實際情況進行刪減。