需求分析是軟件計划階段的重要活動，也是軟件生存周期中的一個重要環節，該階段是分析系統在功能上需要“實現什么”，而不是考慮如何去“實現”。需求分析的目標是把用戶對待開發軟件提出的“要求”或“需要”進行分析與整理，確認后形成描述完整、清晰與規范的文檔，確定軟件需要實現哪些功能，完成哪些工作。
一、主要內容
總體上說，需求分析的內容是針對待開發軟件提供完整、清晰、具體的要求，確定軟件必須實現哪些任務。具體分為功能性需求、非功能性需求與設計約束三個方面。
1．功能性需求
功能性需求即軟件必須完成哪些事，必須實現哪些功能，以及為了向其用戶提供有用的功能所需執行的動作。功能性需求是軟件需求的主體。開發人員需要親自與用戶進行交流，核實用戶需求，從軟件幫助用戶完成事務的角度上充分描述外部行為，形成軟件需求規格說明書。
2．非功能性需求
作為對功能性需求的補充，軟件需求分析的內容中還應該包括一些非功能需求。主要包括軟件使用時對性能方面的要求、運行環境要求。軟件設計必須遵循的相關標准、規范、用戶界面設計的具體細節、未來可能的擴充方案等。
3．設計約束
一般也稱做設計限制條件，通常是對一些設計或實現方案的約束說明。
具體而言，本例實驗包括系統的總體需求分析和軟件需求分析，內容詳見實驗步驟。
二、實現平台
系統平台：略
三、具體內容
系統的總體需求分析：
1、獲取用戶需求
系統主要角色：系統管理員、學生、教師
管理員：能夠對本賬號的個人資料進行查閱並修改，在擁有對學生、教師等的用戶賬號密碼進行重置等權限的基礎上，對普通用戶賬號信息擁有超級權限；同時，能夠進行后勤廠商設備管理、以及在不同用戶賬號之間進行信息交流；等等。
學生：除了能夠自身的賬號信息進行修改外，能在賬號通信的前提之下，進行來自上層權限賬號的通信接收；以校園生活主題為維度，學生擁有注銷、設備使用、查閱課程表等的功能需求；等等。
教師：僅作為一個校園生活為主流的教師賬號而言，除卻能對自身的信息進行維護之外，通常都將擁有學生的成績錄入、課程信息的相關通知；教師也將擁有來自學生角色的部分功能，如校園設備使用、接收來自上層權限賬號的通信；等等。
2、確定功能需求
1）、基本信息維護：
對於全局角色而言，學生、教師以及系統管理員在完成登錄之后，可以自選式進行個人信息的基本維護，如出生年月、性別和賬號密碼之類的修改；而對於系統管理員而言，能夠擁有學生和教師賬號密碼重置的超級權限，以防止並解決用戶在使用賬號過程中發生密碼遺忘的問題；等等。
2）、通知推廣以及信息接收：
在設計之初，以學生權限繼承於教師，而教師權限繼承系統管理員的思想維度考慮，系統管理員可以對學生和教師賬號進行通信信息推廣，而學生和教師角色僅能對此進行回應。如果要逆權限進行數據對話，必須通過用戶反饋功能模塊。
3）、設備使用和維護：
校園后勤所涉及的使用設備，均來自校方的企業合作，因此能夠對設備進行維護的，也僅由校方的工作人員，即系統管理員。而設備的使用權，對於各賬號均有效。
4）、教學場所的借閱和維護：
教學場所的統一管理標准完全是以教務處制定，因此校方的系統管理員和對教師的教室申請能夠進行審批等權限，這得在教師主動申請補課或者系統管理員統一排課的前提之下。
5）、學生管理：
學生可以通過登錄，查看自己的各種使用余額，並可以通過網上支付的方式快速充值，無須排隊。
6）、教師管理：
每個教師須注冊自己的賬號，通過賬號可實時查詢自己書籍借閱。與其他的使用情況。
7）、機構管理：
管理員可將學生信息錄入學生表，也可以批量導入學生信息，並可指定搜索學生，查看並修改其信息。
8）、機器管理：
每台連接上此系統的機器，都要與管理數據庫鏈接，並定時發送信息，確保機器穩定運行，並能通過此信息快速定位損壞機器，方便維修。
3、分析性能需求
1）、正確性需求：
在精度需求上，根據實際需要，數據在輸入、輸出及傳輸的過程中要滿足各種精度的需求根據關鍵字精度的不同。如：查找可分為精確查找和泛型查找，精確查找可精確匹配與輸入完全一致的查詢結果，泛型查找，只要滿足與輸入的關鍵字相匹配的輸入即輸出，可供查找。
2）、安全性需求：
只有合法用戶才能登錄使用系統，對每個用戶都有權限設置。對登錄名、密碼、以及用戶重要信息進行加密，保證賬號信息安全。
3）、並發能力： 系統同時處理的request／事務數
4）、處理時間：
系統響應時間應在人的感覺和視覺范圍內(<1 s)，系統響應時間足夠迅速(<5 s)，能夠滿足用戶要求。
5）、響應速度：ＱＰＳ（ＴＰＳ）＝ 並發數／平均響應時間
6）、數據恢復：
系統采用了記錄日志，用於記錄用戶的操作及故障信息，同時本系統采用的B/S模式，結構清晰，便於維護人員進行維護.
4、其他一些需求
1）、開發性：
①.有良好的開發流程和環境
②.有各個技術人員盡責
③.有先進的技術設備
2）、界面友好：
該系統界面設計美觀大方。符合現代人的審美觀，頁面顯示信息清晰明了，操作簡單。
3）、一致性：
當更新操作完成之后，任何多個后續進程或者線程的訪問都會返回最新的更新過的值。
4）、弱一致性：
系統並不保證續進程或者線程的訪問都會返回最新的更新過的值。在系統返回之前需要滿足一定的條件，更新操作完成之后到訪問返回最新值之間的時間窗口稱為不一致窗口。
5）、最終一致性：
弱一致性的特定形式。系統保證在沒有后續更新的前提下，系統最終返回上一次更新操作的值。在沒有故障發生的前提下，不一致窗口的時間主要受通信延遲，系統負載和復制副本的個數影響。DNS是一個典型的最終一致性系統。
軟件需求分析：
1．確定總體目標及組織結構
在對校園生活一體化管理系統進行調研和分析的基礎上,可以畫出新系統的組織結構圖，並列出各部門的崗位角色表，如圖3-1和表3-1所示。
圖3-1 圖書館組織結構圖（略）
| 崗位編號 |
崗位名稱 |
所在部門 |
崗位職責 |
相關業務 |
| 1011 |
教務領導 |
教務處 |
進行學生等用戶數據進行維護 |
信息管理和維護 |
| 1012 |
教職工 |
教務辦公室 |
教授學生 |
發布通知 |
| 1013 |
社團部門人員 |
學院下屬各社團部 |
部門成員管理維護 |
社團內部信息管理和維護 |
| 1014 |
學生 |
各年級班級 |
學習、系統的主要使用人員 |
設備消費者 |
表3-1崗位角色
2．深入領域分析，畫出業務流程圖（略）
3．分析數據流程，畫出數據流圖（略）
4．確定功能需求，完成功能結構圖及點列表
校園生活一體化管理系統的部分性能點列表(性能模型)，如表3-2所示。
| 編號 |
性能名稱 |
使用部門 |
使用崗位 |
性能描述 |
輸入 |
系統響應 |
輸出 |
| 1 |
教務領導及教職人員查詢消費學生信息響應時間 |
教務處、教務辦公室 |
教務領導、 教職工 |
查某在用設備學生<3秒 |
學生姓名、或學號 |
按照輸入的組合條件，進行模糊查詢 |
顯示“學生名字、部門、年級；等等” |
| 2 |
學生使用設備響應時間 |
隸屬各年級班級 |
學生 |
設備響應操作<2秒 |
設備編號、社團編號 |
按照輸入的組合條件，進行查詢 |
顯示“設備在線情況、賬號資金詳細周轉情況” |
| 3 |
發送通知信息響應時間 |
教務辦公室、學院下屬各社團部 |
教職工、社團部門管理人員 |
通知信息發送響應時間<2秒 |
所要接受部門編號 |
按照輸入的組合條件，進行模糊查詢 |
顯示“通知消息發送與否、發送時間” |
表3-2 校園生活一體化管理系統的性能點列表
6．明確處理關系，列出接口列表
校園生活一體化管理系統的部分接口列表，如表3-3 目標系統的接口列表(接口模型)
（略）
3.3.2 業務流程圖
企業投資項目審批過程業務流程圖，如圖3-4所示。
3.3.3 數據流圖及數據字典
| 數據元素編號： |
ID 001 |
| 數據元素名稱： |
學號或職工號 |
| 別名： |
學生與教職工的標識 |
| 簡述： |
學生與教職工在校的唯一識別代碼 |
| 類型及寬度： |
字符型，11位 |
| 取值范圍： |
“00000000001”～“99999999999” |
| 數據流編號： |
D01- 01 |
| 數據結構名稱： |
校園一體化管理 |
| 簡述： |
學生與教職工的各種充值與借閱書籍的行動 |
| 數據流來源： |
學生與教職工 |
| 數據流去向： |
圖書借閱，水電管理 |
| 數據流組成： |
學號或職工號 +（充值金額+使用時長） |
| 數據流量： |
平均100份/小時（僅每學期初） |
| 高峰流量： |
500份/小時（上午9:00 -11:00） |
表3-7 數據流定義
校園生活一體化管理系統的DFD圖，如圖3-7所示。對於校園生活一體化管理系統，需要接收來自用戶的登錄信息，並驗證，驗證過程主要根據用戶權限的正確性，並由用戶檔案確定是否登錄成功情況。
圖3-7 系統的DFD圖
四、需求分析結果
經過開發的研討，加之參與體系化的深入分析，本例滿足目前市場所流行的功能使用性。由此，校園生活一體化管理系統可進入下一階段的研發。
五、需求經驗
經過研發小組初步促成共識，本例實驗心得可總結如下：
(1)應用領域的復雜性及業務變化，難以具體確定，同時，用戶需求所涉及的多因素引起的，比如運行環境和系統功能、性能、可靠性和接口等；
(2)軟件的需求在整個軟件生存周期，常會隨着時間和業務而有所變化。有的用戶需求經常變化，一些企業可能正處在體制改革與企業重組的變動期和成長期，其企業需求不成熟、不穩定和不規范，致使需求具有動態性；
(3)需求分析涉及的人事物及相關因素多，與用戶、業務專家、需求工程師和項目管理員等進行交流時，不同的背景知識、角色和角度等，使交流共識較難；
(4)獲取的需求難以達到完備與一致。由於不同人員對系統的要求認識不盡相同，所以對問題的表述不夠准確，各方面的需求還可能存在着矛盾。難以消除矛盾，形成完備和一致的定義；
(5)需求難以進行深入的分析與完善。需求理解對不全面准確的分析，客戶環境和業務流程的改變。市場趨勢的變化等。也會隨着分析、設計和實現而不斷深入完善，可能在最后重新修訂軟件需求。分析人員應認識到需求變化的必然性，並采取措施減少需求變更對軟件的影響。對必要的變更需求要經過認真評審、跟蹤和比較分析后才能實施；等等。