軟體需求分類與需求獲取

需求分類

業務需求：
客戶對於系統的高層次目標要求(high-level objectives) ，定義了專案的遠景和範疇(vision and scope)

• 業務：屬於哪類業務範疇？應完成什麼功能？為何目的？
• 客戶：軟體為誰服務？目標客戶是誰？
• 特性：區別於其他競爭產品的特性是什麼？
• 價值：價值體現在哪些方面？
• 優先順序：功能特性的優先順序次序是什麼？

[例]“圖書資料管理系統”的業務需求
該系統使用計算機實現圖書資料的日常管理，提高工作效率和服務質量
該系統可讓使用者在網路上查詢與瀏覽電子資料，改變原有借閱模式
由於版權的限制，某些電子資料只能瀏覽/列印，但不能下載

使用者需求(User Requirements)：
從使用者角度描述的系統功能需求與非功能需求，通常只涉及系統的外部行為而不涉及內部特性
[例]使用者可以通過Internet隨時查詢圖書資訊和個人借閱情況，並可以快速查詢和瀏覽需要的電子資料：
[功能需求]使用者通過Internet查詢圖書資訊
[功能需求]使用者通過Internet瀏覽個人借閱情況
[功能需求]使用者通過Internet查詢和瀏覽電子資料
[非功能需求]隨時、快速

業務需求與使用者需求的對比

業務需求

• 由於實行學分制管理，學校領導希望用計算機管理學生選課
• 課程資訊維護、選課管理、課程成績登記和查詢等業務全部由手工方式改為計算機應用

使用者需求

• 教務管理員希望能夠增加、修改和刪除學校的課程目錄，並且設定各學期課程的開設資訊
• 學生希望能夠在學期開始之前查詢所有開設課程的詳細資訊，並能夠通過校園網進行選課
• 學生希望在選課期間系統能夠24小時使用，系統使用方便快捷

功能需求(Functional Requirements, FR)：
系統應該提供的功能或服務，通常涉及使用者或外部系統與該系統之間的互動，不考慮系統內部的實現細節

[例]：

• 使用者可從圖書資料庫中查詢或者選擇其中一個子集
• 系統可提供適當的瀏覽器供使用者閱讀館藏文獻
• 使用者每次借閱圖書應對應一個唯一的標識號，它被記錄到使用者的賬戶上

非功能需求(Non-Functional Requirements, NFR)：
從各個角度對系統的約束和限制，反映了客戶對軟體系統質量和效能(quality and performance)的額外要求，如響應時間、資料精度、可靠性等
[例]：

• 系統在20秒內響應所有的請求
• 系統應該每週7天、每天24小時都可使用
• 對一個沒有經驗的使用者而言，經過2小時培訓即可使用系統的所有功能

注意：非功能需求隱含了對可選設計方案的一些關鍵影響

• 體系結構設計(e.g., 體系結構風格選擇)
• 演算法設計(e.g., 排序策略的選擇)

非功能需求的度量
NFR：檢驗起來非常困難，一般採用一些可度量的特性進行描述

約束條件(Constraints)：
系統設計和實現時必須滿足的限制條件，對其進行權衡或調整是相當困難的，甚至是不可能的

例如：

• 系統必須用C++或其他面嚮物件語言編寫
• 系統使用者介面需要採用圖形化介面
• 一個特定應用所消耗的可用計算能力平均不超過50%
• 系統開發過程和交付文件需遵循GB/T 8567-2006標準
• 通訊介面必須符合ISO七層架構

業務規則(Business Rule)：
對某些功能的可執行性或內部執行邏輯的一些限定條件
通常表達為“如果…，那麼…”的形式
通常是一些容易發生變化的功能

例如：

• 如果借書卡型別為“教師”，那麼一次借閱的最大數量為8本
• 如果訂單金額大於10000元，那麼該訂單的折扣為10%
• 如果採購單金額在10萬到50萬之間，那麼需要總經理審批
• 如果開具了藥品A，並且病人年齡在65歲以上或12歲以下，其總劑量不能超過20片
• 如果開具了藥品B，那麼不能同時開具藥品C或D
• 如果開具了檢查專案M和N，那麼就無需開具檢查專案P
• 同一處方中不能開具5種以上的藥物或3項以上的檢查

外部介面需求(External Interface Requirement)：
描述系統與其所處的外部環境之間如何進行互動，包括：
使用者介面需求(UI)，硬體介面需求，軟體介面需求，通訊介面需求
例如：

• “從<某些裝置>讀取訊號”
• “給<其它系統>傳送訊息”
• “以<某種格式>讀取檔案”
• “能控制<某些硬體>”
• “採用<某種型別的>使用者介面”

好的需求應具備的特徵：
完整性：每一項需求都必須將所要實現的功能描述清楚
正確性：每一項需求都必須準確地陳述其要開發的功能
可行性：每一項需求都必須是在已知系統和環境的權能和限制範圍內可以實施的
必要性：每一項需求都應把客戶真正所需要的和最終系統所需遵從的標準記錄下來
劃分優先順序：給每項需求、特性或使用例項分配一個實施優先順序以指 明它在特定產品中所佔的分量
無二義性：對所有需求說明的讀者都只能有一個明確統一的解釋
可驗證性：檢查一下每項需求是否能通過設計測試用例或其它的驗證方法，如用演示、檢測等來確定產品是否確實按需求實現

需求獲取例子：

使用者的想法：（1）現在每個人都在使用多個社交網路服務（SNS-Society Net Service）（電話、簡訊、微博、微信、QQ、人人、LinkedIn 等等），它們均可幫助在人與人之間建立同步或非同步的聯絡；但是每個人使用這些服務的習慣不同，通過哪個 SNS 能在特定時刻最方便的聯絡到某個朋友？（2）如果能夠有一個軟體，可以根據使用者與朋友們的歷史社交記錄，統計分析出每個朋友對 SNS 的使用習慣，從而在該使用者試圖與某個朋友互動時，自動推薦最可能實時聯絡到該朋友的社交網路服務，就最好不過了。
要求：你扮演需求獲取人員，請你的同學（或者你自己）扮演使用者，模擬上述訪問使用者的過程，最終形成需求清單：業務需求、功能需求、非功能需求、約束條件、介面需求等。