Transcript Chapter 01

Chapter 04
定義需求
學習目標





說明問題陳述(problem statement)的概念
辨別需求類型
說明收集需求的程序
辨別在收集需求時常見的陷阱
需求工作流程


需求工作流程（Requirement Workflow）中的大
部分工作，會出現在專案啟始和細部評估階段。
描繪出系統該有哪些功能的抽象層次是需求工程
（Requirements Engineering）的一部分。
Rational Unified Process（RUP）
需求工程的描述模型
需求的重要性
需求不完整以及缺少使用者參與是導致專
案失敗最主要的兩個原因，兩者的起因都
是因為需求工程失敗所導致的。
 最後當軟體系統取決於一組需求時，有效
的需求工程便會成為軟體開發專案是否成
功的重要關鍵。

定義需求
需求是「該被開發出來的規格」
 基本上有兩種需求：

 功能性需求─系統該提供什麼樣的行為；
 非功能性需求─系統的特性或限制。

需求應該僅說明系統該做什麼(What),系統
該提供那些功能而已，而不是直接說明系
統該怎麼做(How)，如何達到那些功能。
需求模型


UP有一個正規的需求描述方式，它是採用使用案
例模型來說明需求的內容，我們以傳統功能性與
非功能性需求的想法為基礎，再加上需求模型來
加強描述需求的內容。
使用案例模型通常是透過一套UML模塑工具來建
立，如Rational Rose, Microsoft Visio,
ArgoUML,…..
好的需求描述格式

建議用一個非常簡單的格式來描述需求的內容。
每個需求都有一個唯一碼（通常是數字）、一個
關鍵字（Shall）以及一段對功能的描述。
功能性需求 (透過使用案例來描述)

功能性需求是在描述系統應該要做什麼，它
是一段系統功能的描述。例如：
 自動提款機系統會檢查插入的金融卡之有效性。
 自動提款機系統會驗證客戶所輸入的PIN碼。
 自動提款機系統會限制每一張金融卡24小時內
領出之金額不得超過250美元。
非功能性需求
(不適合透過使用案例來描述)

非功能性需求則是指一個系統的限制。例如：
 自動提款機系統會用C++開發。
 自動提款機系統會用256位元的加密方式與銀
行連線。
 自動提款機系統會在3秒內驗證完一張金融卡。
 自動提款機系統會在3秒內驗證完PIN碼。
功能性需求 (透過使用案例來描述)

功能性需求是在描述系統應該要做什麼，它
是一段系統功能的描述。例如：
 數位學習平台要提供教師能掛入數位課程。
 數位學習平台要提供學生選課的功能。
 數位學習平台要提供課程有線上考試的功能。
 數位學習平台可提供追蹤學生學習成果的功能。
非功能性需求
(不適合透過使用案例來描述)

非功能性需求則是指一個系統的限制。
 數位學習平台應有同時提供20使用者同時上線使用
的能力。
 數位學習平台應有持續運作24小時不當機的能力。
 數位學習平台應有對上載的教材有掃毒的功能。
 數位學習平台應能儲存使用者資料10以上。
非功能性需求

非功能性需求通常涉及
 系統的限制:
效能, 標準。
 軟體安全度。
 軟體維護度。
 軟體可靠度。
利用分類表來整理需求

如果有在使用需求管理工具，便能夠整理需求到
一個分類表（Taxonomy）中。
需求屬性

每個需求都有一組屬性來記錄關於需求額外的資訊(描述
資料；Metadata)

每個需求屬性都是一個可描述的名稱以及數值。例如


一個需求可以有一個名為完成日期（dueDate）的屬性，同時這
屬性有一個日期的數值是這需求非得完成的日期。
最常見的需求屬性是要需求的優先順序（Priority），此屬
性的數值是指該需求在所有需求中的優先順序，普遍用來
指定優先順序的是MoSCoW代碼。
MoSCoW代碼
優先順序的屬性
語意
一定要有(Must have)
一定要有的需求，是系統最
基本的需求。
應該要有(Should have)
可刪除的重要需求。基於時
程或經費考量而被刪除。
可能要有(Could have)
可以選擇的需求(有時間或
經費再來發展)。
希望要有(Want to have)
可以等到系統較成熟時再來
開發的需求。
需求類型

商務程序(Business process)

限制(Constraints)

規則(Rules)

績效(Performance)

商務程序(Business process)
描述使用者與系統在互動上的關係。這與資訊系統的領域
知識(domain knowledge)息息相關，一般IT人員來說，商
業模型可能很陌生，而且大多數的IT開發工具都只接受
UML模型而不是商業模型。因此我們需要把領域專家實作
的商業模型轉換為IT人員熟悉的UML模型。
例如: ECP, 出納系統, 電子商務系統

限制(Constraints)

收集需求(Requirements)
使用者的經驗與技能會限制系統的需求。
主要使用者只要有欄位可直接輸入資料即可, 但一般使用者卻希 望能
供下拉式的選單供選擇。

分析(Analysis)
法律、契約或產業標準可能會嚴格限制系統的規格。
存貨系統必須遵循會計原則的限制，在存入貨物之後也必須同時告知
會計部門，準備付款事宜。

設計(Design)
系統所採用的Program Language、DB、Middleware…，都會限制到
系統資料欄位的型態、資料的交換或通訊協定。

實作(Implementation)
實作部份的限制經常與cost相關。
在倉庫中欲採用RFID技術，但隔壁變電所產生太太干擾，先要發大
筆經費來解決干擾的問題。

規則(Rules)
限制(Constraints)是強制性的，通常很難改變，但規則
(rules)是原則性問題，較有協議的空間。
在分析階段規則是討論的重點，企業再造就是經由系統
分析過成來修改原先的規則，來達到企業流程精簡的目
的。像電子化流程，就可大幅簡化傳統紙本流程的時間
與成本，但必須接受電子簽章的應用。
需求訪談的技巧
訪談 (key man)
 問卷 (無互動性)
 研討會 (發散, 不易達到共識)

個案研究 – 存貨控制系統

需求來至問題陳述, 存貨控制系統的問題成陳述可包含
四個段落:
接收、儲放、訂單履行與運送。
個案研究的問題陳述

接收


儲放


倉儲員會為每種產品查詢正確位置，將產品放到該位置，然後依據位置及
數量更新存貨。當產品放到正確位置時，儲放工作人員會通知上司，並將
收貨單據交給應付帳款部門。
履行訂單


收貨員藉由比對購買訂單及貨物中的產品接收前來的貨物。進貨文件將傳
給其上司進行檢驗。這些產品可能是來自被取消的訂單、退貨或進貨。產
品由貨車上卸下來，然後放入儲存區。
其他公司員工經由找出訂單所要求的產品來填寫訂單。當他們把訂單填寫
完畢後，他們會把訂單放到辦事員桌上。辦事員會更新存貨，以反映該產
品已為訂單而移出的事實。這裡可能會有一到兩天的遲延，在重新訂購程
序及儲放層次導致嚴重的問題。他們也會通知訂單處理部門該訂單已填好。
運送

當訂單填好後，產品會被包裝好並準備運送。運送員會聯繫運送人員，安
排運送時間，並將文件交給辦事員。當訂購貨物被運送時，辦事員也會通
知訂單處理部門，同時更新存貨以反映該產品已被實際送出的事實。
存貨控制系統

確定需求
 使用者(Users)：使用者對系統的用途有期待。
 資源(Resources)：資源係以系統為了支援系統
行為所建立、使用、刪除的資料方式呈現。
 功能(Functionality)：功能係指系統所支援的行
為。
使用者(Users)

•
•
•
•
商務程序(Business process)
你的工作責任為何？
有許多人負責相同的工作嗎?
如果他們的工作不同，請說明如何不同及其原因。
系統該提供甚麼功能才能確保你的工作能順利完成。

限制(Constraints)
有法律、契約或產業標準會嚴格限制你的工作嗎?

規則(Rules)
有政治或程序決定你必須如何完成工作嗎?

績效(Performance)
有多少人會使用到這個部份的系統功能。
系統的速度要多快才不會阻礙到你的工作。
•
•
避免初期的陷阱

陷阱#1：做出假設

陷阱#2：複製現有的實作

陷阱#3：對需求的錯誤偏好
陷阱#1：做出假設
訪談過程中客戶無意作了假設性的陳述， 如:
“他們使用存貨管理系統” .. 假設分析師已經知道他們是誰?
所以分析師需隨時對客戶的陳述提出質疑與問題。
陷阱#2：複製現有的實作
採用不同的技術將現有資訊系統更換至不同平台，如將
傳統Windows的資訊系統轉換至Web-based平台。
不可只看原先系統的操作手冊就來開發新的平台，還是要
重新與客戶確立需求。因為不同平台的特性也會影響需求。
像說傳統Windows環境提供物件拖拉移動或複製的功能，但
Web-based平台則無法提供這種操作功能。
傳統Windows系統須每部電腦安裝Client, Web-based系統則
不用。
陷阱#3：對需求的錯誤偏好
不要只聽一個人的意見與需求，因為不同的使用者會有不同
的需求偏好，可綜整後提出使用者都能接受的方案。
A使用者喜歡使用下拉式選單,
B使用者喜歡使用Check Box選單,
C使用者偏好使用欄位輸入