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使用者偏好使用欄位輸入
© Copyright 2024 ExpyDoc
