軟體需求 (Software Requirements)

Presentation on theme: "軟體需求 (Software Requirements)"— Presentation transcript:

1 軟體需求 (Software Requirements)
系統的描述(descriptions)和規格(specifications)

2 主題 功能性及非功能性需求 (functional and non-functional requirements)
使用者需求(user requirements) 系統需求(system requirements) 軟體需求文件(software requirements document)

3 需求工程 (Requirements Engineering)
建立以下事項的過程 用戶對系統期望提供的服務(services) 系統操作及發展時的限制條件(constraints)

4 何為需求？ 需求可能的範圍 從一個服務或服務限制的高層次抽象(high-level abstract)概念
到細部的數學功能規格(detailed mathematical functional specification)

5 需求需滿足下述二項功能(dual function)
用以簽署合約時投標的基礎(a bid for a contract) 能為大眾所解讀(open to interpretation) 也可以是合約本身的基礎 因此必須被詳細定義 上述兩種情形皆可稱為需求

6 需求摘要 (Requirements Abstraction)
如一公司希望能簽署一個大型軟件開發計畫的合約 需先以非常抽象(sufficiently abstract)的方式定義需求，而不事先定義解決的方法(a solution is not pre-defined) 訂出的需求必須能讓多家承包商參與競標 各自提出能滿足客戶組織需求的方案(client organisation’s needs)

7 一旦一份合約被授予(awarded) 承包商需為顧客撰寫更詳細的系統定義，讓顧客瞭解及驗證(validate)軟體所將提供的功能 此兩種文件統均稱為系統的需求文件(requirements document)

8 需求蒐集 (Requirements Gathering)
Facilitated Application Specification Techniques Software Engineering Group Customer

9 需求種類 (Types of Requirement)
使用者需求(user requirements) 以自然語言(natural language)和圖表(diagrams)說明系統能提供的服務及運作時的限制條件(operational constraints) 使用者需求是專為客戶撰寫的 系統需求(system requirements) 以結構化文件(structured document)更詳細描述系統服務 系統需求為客戶(client)與承包商(contractor)間的合約

10 軟體規格(software specification )
詳細的軟體描述(detailed software description)可用來當作設計和實作的基礎 軟體規格專為開發者(developers)所撰寫

11 定義及規格 (Definition and Specification)

12 需求的讀者 (Requirements Readers)

13 功能性及非功能性需求 ( Functional and Non-Functional Requirements)
說明系統所需提供的服務、系統對特殊的輸入該如何回應以及系統在特殊情況下的行為等 非功能需求(non-functional requirements) 系統提供之服務及功能的限制條件，例如時間上的限制、開發程序上的限制和標準等

14 領域需求(domain requirements)
關於系統應用領域(application domain)及該領域特徵的需求

15 功能的要求 (Functional Requirements)
描述系統服務的功能(functionality) 功能性使用者需求(functional user requirements)可以高階敘述(high-level description)說明系統該做什麼 功能性系統需求(functional system requirements) 則應該詳細描述系統服務

16 功能性需求實例 使用者必須能夠搜尋(search)整個或部分資料庫(databases)
系統應提供適當的檢視器(appropriate viewers)供使用者閱讀文件資料庫(document store)中的文件 每筆文件訂閱單(order)需配置一個唯一的識別碼(unique identifier) (ORDER_ID)，使用者可據此將此文件複製到其帳戶的永久儲存區(permanent storage area)

17 不精準需求 (Requirements Imprecision)
當需求沒有精確的描述就會發生問題 模凌兩可的需求(ambiguous requirements)會被開發者和使用者解讀成不同的意思 對於「適當檢視器 」(appropriate viewers) 使用者的想法(user intention) 對每個不同文件類型所使用的特殊用途檢視器(special purpose viewer) 開發者的解讀(developer interpretation) 提供能夠顯示文件內容(contents of the document)的文字檢視器(text viewer)

18 完整性及一致性需求 (Requirements Completeness and Consistency)
原則上，需求應該是完整(complete)且一致的(consistent) 完整(complete) 應包括所有需求功能(all facilities required)的描述 一致(Consistent) 系統功能描述中不應有衝突(conflicts)或矛盾(contradictions)之處

19 非功能的要求 (Non-Functional Requirements)
定義系統特性(properties)及限制(constraints) 特性如：可靠度(reliability)、回應時間(response time)及儲存需求(storage requirements)等 限制如： I/O裝置功能、系統表達方式等 行程需求(process requirements)也可以指定使用特定的CASE系統、程式語言或開發方法

20 非功能需求可能比功能性需求更關鍵(critical)，若不能符合這些需求系統就會變成無用
產品需求(product requirements) 指定所交付的產品需符合某種特定的運作 例如：執行速度(execution speed)、可靠度(reliability)等

21 組織需求(organisational requirements)
因應組織政策與程序的需求(a consequence of organisational policies and procedures) 例如：使用的行程標準(process standards)、實作需求等 外部需求(external requirements) 系統與開發行程之外在影響因素(factors)所引起的需求 例如：互通需求(interoperability requirements)、法律需求(legislative requirements)等

22 非功能性需求類型 (Non-Functional Requirement Types)

23 非功能性需求實例 產品需求(product requirement) 組織需求(organisational requirement)
4.C.8 須讓APSE和使用者之間所有必要的溝通都能表示成標準的Ada字元集(character set) 組織需求(organisational requirement) 9.3.2 系統開發行程和交付文件須符合XYZCo-SP-STAN-95所定義的行程和交付成果(deliverables) 外部需求(external requirement) 7.6.5 系統除了提供顧客的姓名和參考號碼(reference number)給系統操作員(operator)外，不能公開(disclose)關於顧客的任何個人資訊

24 目標和需求 (Goals and Requirements)
非功能性需求可能不容易精確的陳述，而不精確的需求則難以進行驗證 目標 一般使用者的期望是容易使用(ease of use) 可驗證的非功能性需求(verifiable non-functional requirement) 使用某些可以客觀測試的方法(measure)來描述

25 實例 系統目標(system goal) 系統應該讓有經驗的操作員(experienced controllers)容易使用
系統也應被善加規劃(organized)以致能盡量減少 使用者操作上的錯誤(user errors are minimized)

26 可驗證的非功能需求 (verifiable non-functional requirement)
有經驗的操作員必須能在兩個小時的訓練後即可使用所有系統功能 經訓練後，有經驗的使用者在一天內允許發生的平均錯誤應不超過兩次

27 需求量測 (Requirements Measures)

28 需求互動 (Requirements Interaction)
在複雜系統中不同非功能需求間常相互衝突(conflict) 太空船系統(spacecraft system) 為盡量減輕重量，系統使用的晶片數量需盡量減少 為盡量減少電力消耗(power consumption )，盡量使用低電力的晶片 然而，若使用低電力的晶片可能需要更多數量的晶片，哪個是最關鍵(critical)的需求？ Spacecraft：太空船

29 領域需求 (Domain Requirements)
由應用領域得知，且描述能反應該領域的系統特徵(characteristics)與功能(features) 可能是新的功能性需求(functional requirements)、對現有需求的限制(constraints)或定義特別的運算(specific computations) 領域需求若不能被滿足，系統可能就無法運作

30 圖書館系統的領域需求 ( Library System Domain Requirements)
所有資料庫必須有一個符合Z39.50標準的標準使用者介面 由於版權的限制(copyright restrictions)，有些文件在拿到後需立即刪除(be deleted immediately on arrival) 根據使用者需求，這些文件應在該地的系統伺服器上列印，再以手動方式轉送給使用者，或是繞徑(routed)送到網路印表機列印(routed to a network printer)

31 火車保護系統 (Train Protection System)
火車的減速速率(deceleration)由下列公式計算 Dtrain = Dcontrol + Dgradient 其中Dgradient 為9.81ms2 * compensated gradient/alpha 需要對鐵路系統操作(operation of railway systems)及火車特性(train characteristics)的瞭解 才能理解該需求 Deceleration：減速

32 領域需求問題 (Domain Requirements Problems)
可理解性(understandability) 需求是以某應用領域的語言來表示 開發系統的軟體工程師對這些語言通常都不易理解 喻意性(implicitness) 領域專家(domain specialists)非常熟知他的領域，所以通常不會以很明確的方式來說明領域需求 Implicitness：隱含

33 用戶需求 (User Requirements)
應描述功能性及非功能性需求，以便不具備悉詳細技術知識(detailed technical knowledge)的系統使用者也能瞭解 使用者需求是以自然語言(natural language)、表格(tables)和圖表(diagrams)來定義

34 自然語言的問題 (Problems with Natural Language)
缺乏明確性(lack of clarity) 要達到精確性(precision)卻又不使文件難以閱讀是很難達到的 需求混亂(requirements confusion) 功能性與非功能性需求傾向混合(mixed-up) 需求合併(requirements amalgamation) 將幾種不同需求一同表示(be expressed together)

35 資料庫要求 (Database Requirement)
4.A.5 資料庫必須能夠支援組態物件(configuration objects)的產生(generation)與控制(control)；亦即資料庫中的物件也是其他物件所組成的群組(grouping)。組態控制機制(configuration control facilities)須允許以不完整的名稱(incomplete name)擷取(access)不同版本群組(version group)中的物件

36 網格編輯器功能 (Editor Grid Requirement)
2.6 網格功能(Grid facilities) 為輔助圖表中的實體(entity)在一個圖表(diagram)上定位(positioning)。使用者可以透過控制台(control panel)中的選項開啟以公分(centimetres)或英吋(inches)為單位的網格功能。網格功能的預設為關閉的。在編輯時使用者可在任何時間開啟或關閉網格功能，也可以任意切換英吋或公分的網格單位。一個網格選項將提供最適大小的檢視(reduce-to-fit view)，但當遇到小型圖表(smaller diagram)，顯示的網格線(grid line)將會減少 Toggled：開關

37 要求問題 (Requirement Problems)
資料庫需求包含概念式(conceptual)及詳盡式(detailed)資訊 概念式(conceptual) 描述組態控制功能(configuration control facilities)的概念 詳盡式(detailed) 包含物件可以使用不完全名稱(incomplete name)來擷取的詳細資訊

38 網格需求(grid requirement)混合(mix)了三種不同的需求
概念性功能需求(conceptual functional requirement) 需要有網格的需求 非功能需求(non-functional requirement) 網格單位 非功能性使用者介面需求(non-functional UI requirement) 網格切換(switch)

39 結構化呈現 (Structured Presentation)
2.6　 網格功能(grid facilities) 編輯器需提供網格功能，亦即在編輯器視窗背景提供水平與垂直的格線。該網格是個被動網格(passive grid)，亦即實體(entity)的對齊(alignment)是由使用者控制 理由(Rationale)：網格可幫助使用者建立整齊的圖表(tidy diagram)，實體間有適當的空間(well-spaced)。雖然主動式網格(active grid)有助於實體自動「卡位」(snap-to)到格線(grid lines)，但此種定位(positioning)方式不夠精確(imprecise)。使用者還是決定實體應該如何放置的最佳人選 規格(Specification)：ECLIPSE/WS/Tools/DE/FS Section 5.6 資源(Source) : Ray Wilson, Glasgow Office Tidy：整齊的

40 細部使用者需求 (Detailed User Requirement)
在設計中加入節點(node) 編輯器需有能讓使用者在設計中加入指定類型(specified type)節點的功能 加入節點的動作順序(sequence of actions)如下 1. 使用者選取欲加入節點的類型 2. 使用者將游標(cursor)移動到圖表中接近節點的位置 (approximate node position)，並指明欲加到該點上的節點符 號(node symbol) 3. 使用者將節點符號拖曳到最終位置 理由(Rationale)：使用者是決定節點應放置在圖表上何處位置的最佳人選。此方法讓使用者直接控制節點類型的選擇及定位 規格(Specification)：ECLIPSE/WS/Tools/DE/FS. Section 3.5.1

41 撰寫需求的準則 (Guidelines for Writing Requirements)
建立一個可用於所有需求的標準格式(standard format) 使用一致性(consistent)的語言(language) 以文字凸顯(text highlighting)的方式強調需求的重要部分 避免使用電腦行話(computer jargon) Jargon：行話;黑話

42 系統需求 (System Requirements)
比使用者需求更詳細的規格(detailed specifications) 為設計系統(design system)的基礎 可當做系統合約(system contract)的一部分 系統需求可以系統模型(system model)來表示

43 需求及設計 (Requirements and Design)
原則上需求應陳述系統該做什麼(what the system should do)；而設計應該描述如何做到(how it does this) 在操作上，需求和設計是無法分割的(inseparable) 系統架構(system architecture)可被設計成用以建構系統需求的結構(structure the requirements) 系統可以和其它系統互動(inter-operate)以產生設計需求(design requirements)

44 自然語言規格的問題 (Problems with NL Specification)
意義不明確(ambiguity) 需求的撰寫者與讀者對該需求應有相同的解讀。然而，因為自然語言的本質上具模糊性(ambiguous)，難以達到對需求有相同的解讀 過於彈性(over-flexibility) 在規格中，同一件事可能會有許多不同的說法 缺乏模組化(lack of modularisation) 自然語言的結構並不適合建構系統需求的結構(structure system requirements)

45 NL規格的替代方法 (Alternatives to NL Specification)

46 結構化語言規格 (Structured Language Specifications)
使用自然語言的限制格式(limited form)可用以表示需求 它可消除模糊(ambiguity)與彈性(flexibility)所造成的問題，並且可讓規格有某種程度的統一性(uniformity) 通常最好以表單方式(forms-based)來表示

47 表單式規格 (Form-Based Specifications)
功能或實體的定義(definition of the function or entity) 輸入的描述(description of inputs and where they come from ) 輸出的描述(description of outputs and where they go to) 指明需要的其它實體(indication of other entities required) 任何可能的前置及後置條件(pre and post conditions (if appropriate) 任何可能的副作用(side effects (if any))

48 表單式劑量計算規格 (Form-Based Compute Dose Specification)

49 表格化規格 (Tabular Specification)
用以補自然語言的不足 當需定義某個動作的若干個可行方案時特別有用(possible alternative courses of action)

50 表格化規格 (Tabular Specification)

51 圖形化模型 (Graphical Models)
當要表示狀態改變(state change)或描述一序列行動(sequence of actions)時，圖形模式是最有利的工具

52 序列圖表 (Sequence Diagrams)
用以表示當用戶與系統互動(interaction)時的一序列事件(sequence of events) 從該圖表的上到下(top to bottom)可讀出該行動的順序(order of actions) Example：從ATM提領現金的流程 驗證卡(validate card) 處理請求(handle request) 完成交易(complete transaction)

53 ATM提款的序列圖 (Sequence Diagram of ATM Withdrawal)

54 介面規格 (Interface Specification)
大部分的系統需其他系統一起運作(operate)，因此操作介面(operating interfaces)的規格需為需求的一部分 三種類型的介面 程序介面(procedural interfaces) 交換的資料結構(data structures that are exchanged ) 資料表示(data representations) 正規表示法(formal notations)是種有效(effective)定義介面規格的技術

55 PDL式的需求定義 (PDL-Based Requirements Definition)
需求可以利用比程式語言更具彈性(flexibility of expression)的語言來定義其操作性(defined operationally) 最適用於以下兩種情行 當操作(operation)是以一連串的動作(sequence of actions)來表示，且其順序很重要時 當需規格化硬體和軟體介面(interface)時

56 程式設計語言 (Program Design Language，PDL)

57 ATM的部分規格 (Part of an ATM Specification)

58 PDL缺點 PDL的描述能力可能不足以(not be sufficiently expressive)用容易理解的方式來描述系統功能
表式符號(notation)只對有程式語言知識的人容易理解 需求可視為設計規格(design specification)而非可幫助使用者瞭解系統的模型

59 PDL介面描述 (PDL Interface Description)

60 需求文件 (Requirements Document)
需求文件是系統開發者所需要的正式文件(official statement) 它需包含需求的定義(definition)和規格(specification) 它不是一份設計文件(design document)，它應盡可能說明系統「做什麼」(What)；而非「如何做」(How)

61 需求文件的用戶

62 需求文件的需求 (Requirements Document Requirements)
說明外部系統行為(specify external system behaviour) 說明實作限制(specify implementation constraints) 易於變更(easy to change) 當作維護的參考工具(serve as reference tool for maintenance) 記錄系統生命週期的所需的是先考量(如預測可能的改變) (record forethought about the life cycle of the system i.e. predict changes) 描述對未預期事件的反應(characterise responses to unexpected events) Forethought：事先的考慮

63 IEEE需求標準 (Requirements Standard)
簡介(introduction) 一般描述(general description) 特定需求(specific requirements) 附錄(appendices) 索引(index)

64 需求資料架構 (Requirements Document Structure)
簡介(introduction) 詞彙(glossary) 使用者需求定義(user requirements definition) 系統架構(system architecture) 系統需求規格(system requirements specification) 系統模型(system models) 系統演進(system evolution) 附錄(appendices) 索引(index)

65 參考資料 Ian Sommerville, Software Engineering, 7th ed., Addison-Wesley，2004.