基於校園生活一體化管理系統的需求分析

---

---

        需求分析是軟件計劃階段的重要活動，也是軟件生存週期中的一個重要環節，該階段是分析系統在功能上須要「實現什麼」，而不是考慮如何去「實現」。需求分析的目標是把用戶對待開發軟件提出的「要求」或「須要」進行分析與整理，確認後造成描述完整、清晰與規範的文檔，肯定軟件須要實現哪些功能，完成哪些工做。

1、主要內容

       整體上說，需求分析的內容是針對待開發軟件提供完整、清晰、具體的要求，肯定軟件必須實現哪些任務。具體分爲功能性需求、非功能性需求與設計約束三個方面。

1．功能性需求

       功能性需求即軟件必須完成哪些事，必須實現哪些功能，以及爲了向其用戶提供有用的功能所需執行的動做。功能性需求是軟件需求的主體。開發人員須要親自與用戶進行交流，覈實用戶需求，從軟件幫助用戶完成事務的角度上充分描述外部行爲，造成軟件需求規格說明書。

2．非功能性需求

        做爲對功能性需求的補充，軟件需求分析的內容中還應該包括一些非功能需求。主要包括軟件使用時對性能方面的要求、運行環境要求。軟件設計必須遵循的相關標準、規範、用戶界面設計的具體細節、將來可能的擴充方案等。

3．設計約束

       通常也稱作設計限制條件，一般是對一些設計或實現方案的約束說明。

       具體而言，本例實驗包括系統的整體需求分析和軟件需求分析，內容詳見實驗步驟。

 

2、實現平臺

             系統平臺：略

 

3、具體內容

系統的整體需求分析：

一、獲取用戶需求

      系統主要角色：系統管理員、學生、教師

       管理員：可以對本帳號的我的資料進行查閱並修改，在擁有對學生、教師等的用戶帳號密碼進行重置等權限的基礎上，對普通用戶帳號信息擁有超級權限；同時，可以進行後勤廠商設備管理、以及在不一樣用戶帳號之間進行信息交流；等等。

      學生：除了可以自身的帳號信息進行修改外，能在帳號通訊的前提之下，進行來自上層權限帳號的通訊接收；以校園生活主題爲維度，學生擁有註銷、設備使用、查閱課程表等的功能需求；等等。

     教師：僅做爲一個校園生活爲主流的教師帳號而言，除卻能對自身的信息進行維護以外，一般都將擁有學生的成績錄入、課程信息的相關通知；教師也將擁有來自學生角色的部分功能，如校園設備使用、接收來自上層權限帳號的通訊；等等。

二、肯定功能需求

   1）、基本信息維護：

       對於全局角色而言，學生、教師以及系統管理員在完成登陸以後，能夠自選式進行我的信息的基本維護，如出生年月、性別和帳號密碼之類的修改；而對於系統管理員而言，可以擁有學生和教師帳號密碼重置的超級權限，以防止並解決用戶在使用帳號過程當中發生密碼遺忘的問題；等等。

   2）、通知推廣以及信息接收：

       在設計之初，以學生權限繼承於教師，而教師權限繼承系統管理員的思想維度考慮，系統管理員能夠對學生和教師帳號進行通訊信息推廣，而學生和教師角色僅能對此進行迴應。若是要逆權限進行數據對話，必須經過用戶反饋功能模塊。

  3）、設備使用和維護：

       校園後勤所涉及的使用設備，均來自校方的企業合做，所以可以對設備進行維護的，也僅由校方的工做人員，即系統管理員。而設備的使用權，對於各帳號均有效。

  4）、教學場所的借閱和維護：

      教學場所的統一管理標準徹底是以教務處制定，所以校方的系統管理員和對教師的教室申請可以進行審批等權限，這得在教師主動申請補課或者系統管理員統一排課的前提之下。

  5）、學生管理：

       學生能夠經過登陸，查看本身的各類使用餘額，並能夠經過網上支付的方式快速充值，無須排隊。

  6）、教師管理：

      每一個教師須註冊本身的帳號，經過帳號可實時查詢本身書籍借閱。與其餘的使用狀況。

  7）、機構管理：

     管理員可將學生信息錄入學生表，也能夠批量導入學生信息，並可指定搜索學生，查看並修改其信息。

  8）、機器管理：

      每臺鏈接上此係統的機器，都要與管理數據庫連接，並定時發送信息，確保機器穩定運行，並能經過此信息快速定位損壞機器，方便維修。

三、分析性能需求

  1）、正確性需求：

       在精度需求上，根據實際須要，數據在輸入、輸出及傳輸的過程當中要知足各類精度的需求根據關鍵字精度的不一樣。如：查找可分爲精確查找和泛型查找，精確查找可精確匹配與輸入徹底一致的查詢結果，泛型查找，只要知足與輸入的關鍵字相匹配的輸入即輸出，可供查找。

  2）、安全性需求：

       只有合法用戶才能登陸使用系統，對每一個用戶都有權限設置。對登陸名、密碼、以及用戶重要信息進行加密，保證帳號信息安全。

  3）、併發能力：　系統同時處理的request／事務數

  4）、處理時間：

      系統響應時間應在人的感受和視覺範圍內(<1 s)，系統響應時間足夠迅速(<5 s)，可以知足用戶要求。

  5）、響應速度：ＱＰＳ（ＴＰＳ）＝　併發數／平均響應時間

  6）、數據恢復：

       系統採用了記錄日誌，用於記錄用戶的操做及故障信息，同時本系統採用的B/S模式，結構清晰，便於維護人員進行維護.

四、其餘一些需求

  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圖

 

 

 

 

4、需求分析結果

       通過開發的研討，加之參與體系化的深刻分析，本例知足目前市場所流行的功能使用性。由此，校園生活一體化管理系統可進入下一階段的研發。

 

5、需求經驗

通過研發小組初步促成共識，本例實驗心得可總結以下：

     (1)應用領域的複雜性及業務變化，難以具體肯定，同時，用戶需求所涉及的多因素引發的，好比運行環境和系統功能、性能、可靠性和接口等；

    (2)軟件的需求在整個軟件生存週期，常會隨着時間和業務而有所變化。有的用戶需求常常變化，一些企業可能正處在體制改革與企業重組的變更期和成長期，其企業需求不成熟、不穩定和不規範，導致需求具備動態性；

    (3)需求分析涉及的人事物及相關因素多，與用戶、業務專家、需求工程師和項目管理員等進行交流時，不一樣的背景知識、角色和角度等，使交流共識較難；

    (4)獲取的需求難以達到完備與一致。因爲不一樣人員對系統的要求認識不盡相同，因此對問題的表述不夠準確，各方面的需求還可能存在着矛盾。難以消除矛盾，造成完備和一致的定義；

    (5)需求難以進行深刻的分析與完善。需求理解對不全面準確的分析，客戶環境和業務流程的改變。市場趨勢的變化等。也會隨着分析、設計和實現而不斷深刻完善，可能在最後從新修訂軟件需求。分析人員應認識到需求變化的必然性，並採起措施減小需求變動對軟件的影響。對必要的變動需求要通過認真評審、跟蹤和比較分析後才能實施；等等。