系分——需求工程-02需求獲取 、需求分析、需求定義

2024-01-31教育

考點: 數據流圖、UML圖(用例圖、狀態圖、類圖、活動圖、時序圖)、需求獲取、需求分析、需求定義(需求規格說明書內容)、需求驗證、需求管理和跟蹤、需求變更(流程)、逆向工程、軟體重構。

建議：通讀教材 :第8章軟體工程;第10章系統分析;第11章軟體需求工程;第12章軟體架構設計;第13章系統設計;

軟體需求 ：是指使用者對系統在 功能、行為、效能、設計約束 等方面的期望。是指使用者解決問題或達到目標所需的條件或能力，是系統或系統部件要滿足合約、標準、規範或其他正式規定文件所需具有的條件或能力，以及反映這些條件或能力的文件說明。

隨著系統規模的擴大，需求分析與定義在整個系統開發過程中越來越重要，直接關系到系統的成功與否。需求分析活動不再僅限於系統開發的最初階段，而是貫穿於系統開發的整個生命周期。於是形成了軟體工程的子領域： 軟體需求工程。

（1）軟體需求工程定義

軟體需求工程 是包括 建立和維護 需求文件的必需的一切活動的過程，可分為 需求開發 和 需求管理 兩大工作。 需求開發 包括需求獲取、需求分析、需求定義、需求驗證 4個階段 ；而 需求管理 包括定義需求基線，處理需求變更和需求跟蹤等方面工作。這兩部份相輔相成。其中需求開發是主線，是目標；需求管理是支持，是保障。

（2）需求分類

需求的層次 (這三個不同層次從目標到具體，從整體到局部，從概念到細節)

（1） 業務需求 ：是指反映企業或客戶對系統 高層次的目標要求 ，通常來自計畫投資人、購買產品的客戶、客戶單位的管理員、市場行銷部門或產品策劃部門等。透過業務需求可以確定計畫檢視和範圍，為以後的開發工作奠定了基礎。

（2） 使用者需求 ：描述的是使用者的具體目標，或使用者要求系統必須能完成的任務。即描述了使用者能使用系統來做什麽。通常采取使用者訪談和問卷調查等方式，對使用者使用的場景進行整理，從而建立使用者需求；

（3） 系統需求 ：從系統的角度來說明軟體的需求，包括 功能需求 、 非功能需求 和 設計約束 等。

1) 功能需求 ：也稱為 行為需求 ，它規定了開發人員必須在系統中實作的軟體功能，使用者利用這些功能來完成任務，滿足業務需要。

2) 非功能需求 （ 效能需求，品質內容 ）：指系統必須具備的內容或品質，又可以細分為軟體品質內容（如可維護性、可靠性、效率等）和其他非功能需求。

3) 設計約束 （ 外界強制規定的 ）：也稱為限制條件或補充規約，通常是對系統的一些約束說明，例如必須采用國有自主智慧財產權的資料庫系統，必須執行在UNIX作業系統之下等。

u 按品質功能部署（從使用者角度出發）

（1)常規需求 。使用者認為系統應該做到的功能或效能，實作越多使用者會越滿意。

（2)期望需求 。使用者想當然認為系統應具備的功能或效能，但並不能正確描述自己想要得到的這些功能或效能需求。如果期望需求沒有得到實作，會讓使用者感到不滿意。

（3)意外需求。 意外需求也稱為 興奮需求 ，是使用者要求範圍外的功能或效能（但通常是軟體開發人員很樂意賦予系統的技術特性），實作這些需求使用者會更高興，但不實作也不影響其購買的決策。

需求分類--【PIECES框架】

PIECES框架是IT計畫系統需求分析時的一個模型，PIECES框架能夠完整、準確、快速地確定資訊系統的需求，確認業務中存在的問題、機會和改進目標。

PIECES框架是系統非功能性需求分類的技術

效能( P reformance ): 用於描述企業當前的執行效率，可以分析當前業務的處理速度。 資訊(I nformation ): 資訊和數據指標用於描述業務數據的輸入、輸出以及處理方面存在的各種問題。

經濟(E conomics [ˌiːkəˈnɒmɪks] ): 經濟指標主要是從成本和收益的角度分析企業當前存在的問題。

控制(Control ): 提高資訊系統的安全和控制水平。

效率(E fficiency ): 提高企業的人、財、物等的使用效率,

服務(S ervice ): 提高企業對客戶、供應商、合作夥伴、顧客等的服務品質。

（3）需求開發-需求獲取方法（特點?優點？缺點？根據描述能區分）

需求獲取 屬於軟體需求工程的需求開發階段，

（1）使用者訪談 ：1 對 1-3，有代表性的使用者。使用者訪談是最基本的一種需求獲取手段，其形式包括結構化（指事先準備好一系列問題，有針對地進行）和非結構化（只列出一個粗略的想法，根據訪談的具體情況發揮）兩種，最有效的訪談是結合這兩種方法進行，畢竟不可能事先一一計劃清楚。使用者訪談具有良好的靈活性，有較寬廣的套用範圍，但使用者時間不好安排；談話資訊量大，不好記錄；需要溝通技巧和足夠的領域知識、豐富的應對經驗等；

為了進行有效的使用者訪談，需要在 三個方面 進行組織，分別是 準備訪談 、 主持訪談 和 訪談的後續 工作；

1）準備訪談

確定訪談目的；

確定訪談中應包括哪些使用者；

為訪談準備一些詳細問題；

問題可分為開放式問題和封閉式問題，開放式問題鼓勵使用者討論和說明細節；封閉式問題旨在獲得具體的事實。

2）主持訪談

具體訪談時，一定要準時到達，可能的話，早一點到，訪談過程，要做好幾項工作：

限制訪談時間，時間控制在90分鐘內，如果需要更多時間，應安排下一次，幾次比較短的訪談，比一次馬拉松式訪談效果要好得多。

尋找異常和錯誤情況，要找機會問一些類似，如果。。。那會怎麽樣的問題，有意識地去確定所有特殊的情況，並與使用者深入探討。

深入調查細節；

認真做好記錄

註意措辭，尊重使用者；避免使用IT專業術語；保持談話輕松氣氛；

3）訪談的後續工作

訪談後首要任務是吸收，理解和記錄訪談所獲得的資訊；對於使用者回答不上來，或錯過的問題，不要丟棄或遺忘，準備下一次再問；談話備忘錄要送客戶一份。

（2） 問卷調查 ：使用者多，無法一一訪談。透過精心設計調查表，下發到相關人員手同，讓他們填寫答案，可以有效克服使用者訪談方法中存在的問題，一張好的問卷調查表需要花費大量的時間來進行設計與制作，包括確定問題及其型別、編寫問題、設計問卷調查表的格式三個重要活動。與使用者訪談相比，問卷調查可以在短時間內，以低廉的代價從大量的回答中收集數據；問卷調查允許回答者匿名填寫，大多數使用者可能會提供真實資訊；問卷調查的結果比較好整理和統計。問卷調查最大的不足就是缺乏靈活性 ;其次還有由於雙方未見面，無法從表情等細節獲取隱性的資訊，使用者也無法即時澄清含糊或錯誤的回答；使用者可能心理上不夠重視，反饋資訊不全面；調查表不利於展開回答，不利於了解細節；回答人數可能不及預期，效果打折扣；

較好的做法是使用者訪談與問卷調查相結合，先問卷調查，整理分析的基礎上，小範圍使用者訪談。

提高問卷返還率的方法 ：

向所有解釋問卷的目的，以及如何使用；

說明問卷所有人要回答；

拜托客戶領導督促手下回答並返還；

盡量參加一次企業全體會議，會上回答大家的問題，並解釋這些資訊的用處；

更改問卷中的問題，盡量減少回答問卷所花費的時間；

設定獎勵措施；

（3） 現場觀摩 ：針對較為復雜的流程和操作。想獲取系統某些較為復雜的流程和操作過程，則現場觀摩方法比較合適。對於一些較為復雜的流程和操作而言，是比較難以用語言和文字進行表達的，對於這種情況，可以采用到客戶的工作現場，一邊觀察，一邊聽客戶講解，從而更直觀的了解客戶需求。（只是去觀摩、看，不做）

（4）聯合需求計劃（JRP Joint Requirement Planning）是一個透過 高度組織的群體會議 來分析企業內的問題並獲取需求的過程，各方參與（關鍵使用者代表、系統分析師、開發團隊代表），成本較高。為了提高需求獲取的效率，越來越多的企業傾向於使用小組工作會議來代替大量獨立的訪談，它是聯合套用開發（Joint Application Development，JAD）的一部份。（以會議的形式獲取需求，成本高，獲取需求有效）

JRP原則 ：JRP的的主要意圖是收集需求，而不是對需求進行分析和驗證，實施JRP應把握以下主要原則：

Ø 事先制定議題；

Ø 嚴格按照約定時間進行；

Ø 對議題逐一進行討論；

Ø 會議記錄

Ø 避免術語，盡量通俗易懂，利於交流；

Ø 開發方應該解決沖突的能力：極力避免與各方，尤其是甲方鬧不愉快。就事論事，目的在於解決問題；

Ø 中場休息：本次會議一個上午，中午結束，並無中場休息

Ø 鼓勵取得一致意見；

Ø 保證大家遵守會議決議：即會後應有相關跟進，對作出的決議，產生的問題等及時處理；

JRP一般步驟 ：

Ø 讓與會者互相認識，力求會議在輕松氣氛中進行；

Ø 列舉問題，逐一討論或按照議程，逐一進行；

Ø 鼓勵大家對新系統暢想，形成清單；

Ø 對清單進行整理，明確優先級，評審、最後形成結論或結議；

當然今天的聯合需求計劃會議並沒有完全按照這樣的步驟，但精神是一致的，哪就是理清需求，解決問題，形成結論，為下一步工作做好鋪墊，精神貫徹就行，具體做法可以加以裁剪。

（5） 情節串聯板 ：通常是一系列圖片，分析人員透過這些圖片來講故事，一般情況下，圖片的順序與活動事件的順序一致，透過一系列圖片來說明會發生什麽，圖片型別包括流程圖、互動圖、報表和記錄結構，簡而言之，情節串聯板技術就是使用工具向使用者說明（或演示），系統如何適合企業的需求，並表明系統將如何運轉。

情節串聯板的型別：被動式、主動式和互動式，復雜程度依次遞增；

被動式是靜態圖片，系統分析師充當系統的角色進行講解和演示；

主動式可以自動播放，描述系統典型場景等；

互動式可以讓使用者體驗系統的行為，可以是拋棄式原型等；

情節串聯板的制作：情節串聯板應該易於建立和修改，不要企圖做得太好太精美，情節串聯板即不是原型，也不是真實事物演示。

（6）收集資料 ：把與系統有關的、對系統開發有益的資訊收集起來。

（7） 參加業務實踐 ：有效地發現問題的本質和尋找解決問題的辦法。（自已去做）

（8） 閱讀歷史文件 ：對收集數據性的資訊較為有用。

（9）抽樣調查 ：降低成本。采樣是指從族群中系統地選出有代表性的樣本集的過程，透過認真研究所選出的樣本集，可以從整體上揭示族群的有用資訊。對於資訊系統的開發而言，現有系統的文件（檔）就是采樣族群。當開始對一個系統做需求分析時，檢視現有系統的文件是對系統有初步了解的最好方法。但是，系統分析師應該檢視哪些型別的文件，當文件的數據龐大，無法一一研究時，就需要使用采樣技術選出有代表性的數據。抽樣能夠提高需求獲取效率，但抽樣往往是由系統分析師來抽的，所以會受到他的主觀因素影響。（一個企業有3萬人，不可能發全，統計也麻煩，可能抽了300人，各族群體均發一些，不是需求抽樣哈。）

一般看丟采樣抽樣這些關鍵字後，一般要和數理統計聯系在一起。

樣本大小 ＝ɑ（啟發式因子）*（可信度系數/可接受的錯誤）2 =ɑ（啟發式因子）*（可信度系數/（1-可信度））2 註：其中 可信度系數 題目給出，可信度越高，可資訊度系數越大； ɑ一般預設取 0.25；但也可以變。比如：已知每張訂中可能有1張存在問題，則啟發式因式=0.1*（1-0.1）

序號	需求獲取方法	特點	優點	缺點
1	使用者訪談	1 對 1-3，有代表性的使用者，比較耗時，成本高。其形式包括結構化和非結構化兩種	使用者訪談具有良好靈活性、有較寬廣的套用範圍	難以安排時間、記錄困難，訪談時間有限，對系統分析師要求較高，需要有足夠領域知識；
2	問卷調查	多方參與，使用者多，無法一一訪談。成本低。	針對很多使用者，代價比較小、結果比較好整理與統計	不靈活
3	現場觀摩	針對較為復雜的流程和操作。	直觀了解客戶需求
4	聯合需求計劃（JRP）	高度組織的群體會議，各方參與，成本高	使用者積參與，提高開發效率、多方參與，討論出需求，可以降低需求獲取時間，特別適合需求不明確、有爭議（歧義）的需求。	以會議的形式獲取需求成本高
5	情節串聯板	一系列圖片，透過這些圖片來講故事	直觀、生動、使用者友好、互動性強，對使用者介面起了早期評審作用	花費時間多，使獲取需求速度大大降低
6	收集資料	把與系統有關的、對系統開發有益的資訊收集起來。
7	參加業務實踐	有效地發現問題的本質和尋找解決問題的辦法。
8	閱讀歷史文件	對收集數據性的資訊較為有用。
9	抽樣調查（采樣）	從族群中系統地選出有代表性的樣本集的過程，樣本數量=0.25*(可信度因子/錯誤率)2降低成本。	加快了數據收過程，提高了效率，降低了開發成本；采用技術采用了數據統計原理，減少數據收集偏差。采樣技術不僅可能用於收集數據，還可以對人員進行采樣，樣本選得好，對數據可靠	采樣技術正因為基於統計學原理，樣本規模的確定依賴於期望的可信度和已有經驗知識，很有大程度上取決於系統分析師的主觀因素和個人的經驗能力，對系統分析師要求較高