軟體需求分析期末考試

需求基礎

第二章從概念上讓大家理解什么是需求，以及需求的研究目標是什么，研究物件是什么，
1 需求源于哪兩方面？
用戶的痛點和用戶的期望
2 問題域與解系統
對問題域和解系統的理解，放圖：

軟體系統通過影響問題域，能夠幫助人們解決問題，稱為解系統
而需求工程師是問題域和解系統之間連接的橋梁和介面
3 需求的層次性（不考定義，需理解）

業務需求：對應解決方案等一些宏觀性的問題，
用戶需求：問題域的知識，業務流程，ER圖等等，
系統級需求：建立一些細致的模型描述它，
這三步有一個逐步細化的程序，當時老師通過一個例子幫助我們理解，

業務需求比較宏觀，將其分解成用戶需求如下：

最后面對我們要開發的軟體，我們實際上面對的是系統特性（system feature，SF）

4 需求的分類（不考定義，但要了解）
功能需求（Functional Requirement）：
和系統主要作業相關的需求，即在不考慮物理約束的情況下，用戶希望系統所能夠執行的活動，這些活動可以幫助用戶完成任務，功能需求主要表現為系統和環境之間的行為互動，
性能需求（Performance Requirement）：
系統整體或系統組成部分應該擁有的性能特征，例如CPU使用率、記憶體使用率等，
質量屬性（Quality Attribute）：
系統完成作業的質量，即系統需要在一個“好的程度”上實作功能需求，例如可靠性程度、可維護性程度等，
對外介面（External Interface）：
系統和環境中其他系統之間需要建立的介面，包括硬體介面、軟體介面、資料庫介面等等，
約束
進行系統構造時需要遵守的約束，例如編程語言、硬體設施等
軟體需求說明書就是對各種需求一個概括和規整

需求工程程序

需求獲取：輸入的是用戶需求、期望和問題
·需求分析：UML那些東西
·需求規格說明：最主要的是寫好需求規格說明檔案
·需求驗證：要是有問題，就反過頭看到底是哪個階段出問題了，

需求獲取

1 需求獲取中的常見困難
（1）用戶和開發人員的背景不同，立場不同
（2）普通用戶缺乏概括性、綜合性的表述能力
（3）用戶存在認知困境
（4）用戶越俎代庖
（5）缺乏用戶參與

明確問題

解決方案

活動圖

實體

涉眾分析與硬資料采樣

1. 如何進行涉眾分析？不同型別資訊系統，不同的方法

組織級系統（Organization-Wide System）

分析組織內各類人群的互動關系

戰略資訊系統（Strategic Information System）

分析組織內各類人群的互動關系
各種風險/機遇對既有互動關系的影響

組織間系統（Inter-Organizational Systems）

分析組織間的互動關系
分析關系到組織間互動的各類人群在組織內的互動關系

補充：大眾型產品 例如：搜索引擎、電子商務、移動互聯網應用等等

分析產品定位人群（用戶）
產品功能在用戶社會關系網中的關聯作用
分析用戶與社會關系的互動

問題域(Problem domain)”指提問的范圍、問題之間的內在的關系和邏輯可能性空間，軟體工程:在軟體工程中,問題域是指被開發系統的應用領域,即在客觀世界中由該系統處理的業務范圍

2 涉眾分析程序

** 基于涉眾擴展特征進行涉眾優先級的評估**

3. 識別涉眾的方法

簡單方法：先膨脹后收縮(Expand ? Shrink)
經驗方法：檢查串列（Checklist）
經典方法：涉眾網路

簡單方法：先膨脹后收縮(Expand - Shrink)
①膨脹，
在該階段，需求工程師在收集到背景資料后，憑借自己的經驗，盡可能多地列出涉眾類別，越多越好，
②收縮，
在該階段，需求工程師判斷是否有兩類或多類涉眾的立場是一樣的，將一樣的多個類別進行合并，

優點 簡單易用，
如果涉眾群體比較復雜，可能會出現遺漏.

檢查串列：經典串列
用戶: 最終使用和操作產品的人
關注軟體功能，主要資訊來源
客戶: 為軟體系統的開發付費的人
關注經濟上的成本、收益
開發者: 負責實作軟體系統的人
關注技術上的成本和收益，可行的需求
管理者：參與軟體系統開發事務管理的人
投資方管理者 、執行負責人、專案管理者
關注系統的開發行程

優點：容易操作，如果經驗豐富會比較有效
缺點：有些類別太粗，尤其是用戶作為一個類別是遠遠不夠的

檢查串列：經典串列
領域專家：在問題域中具有豐富知識的專家
關注軟體中的知識，問題域分析
政府力量：法律法規 、長遠規劃、政策意向等
起約束和指導作用
市場力量：組織中的市場部門人員
關注用戶的想法
維護人員：系統的非功能屬性
例如質量

優點：容易操作，如果經驗豐富會比較有效 ；
缺點：有些類別太粗，尤其是用戶作為一個類別是遠遠不夠的

涉眾網路：

1. 從一些比較容易發現的涉眾出發，通常包括客戶、管理者和相關的投資者

2. 由初始涉眾集體討論，列出一個涉眾類別串列

3. 對上一步產生的涉眾類別串列進行分析 ，縮減為一個關鍵涉眾類別串列

4. 由上一步的各個關鍵涉眾類別選擇代表，集中討論，列出新的涉眾類別串列

5. 如果涉眾類別串列趨于穩定，就結束涉眾識別程序 ，否則轉向第2步

優點：適用于復雜情況下的涉眾識別，保障正確性和完備性 缺點：比較麻煩，反復召集涉眾進行討論

涉眾描述

硬資料

什么是硬資料？

1. 實際作業中產生的表格、檔案資料
2. 是一種精化過的知識
3. 可用于獲取事實，理解問題域
   

用例圖

為什么需要用例和場景

需求獲取方法 —— 面談

問題基本上可以分為兩種型別：開放式問題和封閉式問題
開放式問題（Open-Ended）
封閉式問題（Closed）

開放式問題：
被會見者對答復的選擇可以是開放和不受限制的，他們可能答復兩個詞，也可能答復兩段話，
在希望得到豐富（具有一定深度和廣度）資訊時，開放式問題比較合適
例如：
“你覺得把所有的經理都置于一個行內網內怎么樣？”
“請解釋你是如何做進度決策的？”
“對公司中企業對企業電子商務的當前狀態有何看法？”

開放式問題的優缺點：
優點：
讓被會見者感到自在； 會見者可以收集被會見者使用的詞匯，這能反應他的教育、價值標準、態度和信念；
提供豐富的細節； 對沒采用的進一步的提問有啟迪作用； 讓被會見者更感興趣； 容許更多的自發性； 會見者可以在沒有太多準備的情況下進行面談
缺點：
提此類問題可能會產生太多不相干的細節；
面談可能失控；
開放式的回答會花費大量的時間才能獲得有用的資訊量；
可能會使會見者看上去沒有準備，

封閉式問題：
答案有基本的形式，被會見者的回答是受到限制的
例如：
“專案存盤庫每個星期更新多少次？”
“電話中心一個月平均收到多少個電話？”
“下列資訊中哪個對你最有用：（1）填好的客戶投訴單；（2）訪問web站點的客戶的電子郵件投訴；（3）與客戶面對面的交流；（4）退回的貨物，”
“列出頭兩項需要優先考慮的改善技識訓礎設施的事項，”

優點：
節省時間；
切中要點；
保持對面談的控制；
快速探討大范圍問題；
得到貼切的資料
缺點：
使得被會見者厭煩；
得不到豐富的細節；
出于上述原因，失去主要思想；
不能建立和面談者的友好關系，

面談的階段

面談的優點

群體面談和單一面談比較（優缺點）

和一對一的面談相比，有如下優點：
通過集中討論，充分利用了交流時間，因此比一對一面談更加節約時間，有著更低的時間成本，
群體面談往往是在一個集中連續的時間內完成，和一對一面談的間隔性特點相比，能夠加速專案的開發進展，
群體面談中，涉眾方可以直接交流，和一對一面談的以開發者為中介進行交流相比，提高了沖突處理能力，
群體面談的集中討論具有明顯的以用戶為中心的特征，降低了開發者在面談中的主導作用，這里可以提高涉眾的專案參與度，減少開發者主導需求獲取時的弊端，
群體面談集中了所有參與者的智慧，所以常常會有創造性的資訊內容產生

---

和一對一的面談相比，也有如下缺點：
群體面談要求所有參與方都要在一個集中的時間抽出大量時間和精力投入面談，這往往難以實作
群體面談獲得的資訊比和一對一面談要復雜得多，因此對他們的分析是一個不小的技術挑戰，
主持群體面談比主持一對一面談要困難得多

其他方法：

1）調查問卷
2）頭腦風暴

問卷調查相對于面談和群體面談來說更適用于哪方面？
涉眾不易獲取，人多的時候

需求獲取方法—原型

需求獲取方法 —— 觀察和檔案審查

檔案審查（需求獲取最后一部分）

需求分析

初始狀態、終止狀態、狀態、轉移、守護條件、事件、動作

書寫SRS

2 寫SRS的時候有什么要求
·保持陳述句和段落的簡短，
·采用主動語態的表達方式，
·撰寫具有正確的語法、拼寫和標點的完整句子，
·使用的術語與詞匯表中所定義的應該一致，
·需求陳述應該具有一致的樣式，例如“系統必須??”或者“用戶必須??”，并緊跟一個行為動作和可觀察的結果，
·為了減少不確定性，必須避免模糊的、主觀的術語，例如，用戶友好、容易、簡單、迅速、有效、支持、許多、最新技術、優越的、可接受的和健壯的，當用客說“用戶友好”或者“快”或者“健壯”時，你應該明確它們的真正含義并且在需求中闡明用戶的意圖，
·避免使用比較性的詞匯，例如：提高、最大化、最小化和最佳化，定量地說明所需要提高的程度或者說清一些引數可接受的最大值和最小值，當客戶說明系統應該“處理”、“支持”或“管理”某些事情時，你應該能理解客戶的意圖，含糊的陳述句表達將引起需求的不可驗證，

需求驗證

需求驗證的方法

軟體評審會議

審查參與者必須代表三個方面的觀點：

1. ·產品的開發者及其可能的同組成員撰寫需求檔案的分析員，
2. ·先前產品的開發者或用戶領域代表 可能是一個系統工程師、領域專家等
3. ·要根據正在審查的檔案來開展作業的人們 可能包括一個開發人員、一個測驗人員、一個專案經理和一個用戶檔案撰寫人員

·參與者應限制在7個人左右或者更少

需求管理

需求基線

需求變更原因

1 需求理解分歧
2 系統開發實施周期過長
3 客戶業務需求改變
4. 國家政策改變
5. 需求有缺陷

需求變更影響

1 專案成本
2 影響軟體質量及開發進度
3 影響人員的作業狀態
4 影響檔案和代碼的一致性
5 影響開發者和用戶的合作關系

需求變更的成本（同上）

1：專案成本
如果專案有需求變更，那么就需要安排專門的人員進行開發、測驗、部署等作業，這樣就增加了專案的成本，
2：影響軟體質量及開發進度
在一個復雜的軟體系統中，需求之間具有一定的聯系，而相關的需求則構成需求鏈，如果評估變更影響時遺漏了需求鏈中的某些環節，就可能在實施變更程序中引入一些難易察覺的錯誤，這些錯誤將會影響系統的質量，嚴重時可導致系統崩潰，
3：影響人員的作業狀態
如果需求變更頻繁或者需求變更對系統影響比較大，會導致開發、測驗人員在心理上產生抵觸資訊，從而影響其作業狀態，嚴重時可能會導致人員的流失，
4：影響檔案和代碼的一致性
檔案是軟體系統的一個重要組成部分，也是維護系統的重要依據，在處理需求變更的程序中，如果沒有采用規范的流程保證需求變更的評估與實施，會造成檔案跟所開發的軟體系統不一致，系統維護困難，
5：影響開發者與用戶的合作關系
需求變更的實施時用戶和開發者相互協作的程序，開發者和用戶在是否采用變更問題上常常產生分歧，如果沒有恰當的處理，相互之間的信任關系變得越來越差，甚至有合作關系轉變為一種對抗關系，影響專案開發進度，

需求變更控制——基本原則

需求一定要與投入（成本）有顯式的聯系
否則如果需求變更的成本由開發方來承擔，則專案需求的變更就成為必然了，軟體開發方和出資方都要明確這一條：需求變化，軟體開發的投入也要變化，

需求的變更要經過出資者的認可
這樣才會對需求的變更有成本的概念，能夠慎重地對待需求的變更

即使小的需求變更也要經過正規的需求管理流程，否則會積少成多，

精確的需求與范圍定義并不會阻止需求的變更，并非對需求定義的越細，越能避免需求的漸變，這是兩個層面的問題，太細的需求定義對需求漸變沒有任何效果，因為需求的變化是永恒的，并非由于需求細化了，它就不會變化了，

如果開發團隊缺宣告確的需求變更控制程序或采用的變更控制機制無效，抑或不按變更控制流程來管理需求變更，那么很可能造成專案進度拖延、成本不足、人力緊缺，甚至導致整個專案失敗，

當然，即使按照需求變更控制流程進行管理，由于受進度、成本等因素的制約，軟體質量還是會受到不同程度的影響，但實施嚴格的軟體需求管理會最大限度地控制需求變更給軟體質量造成的負面影響，這也正是我們進行需求變更管理的目的所在，

變化不可避免，我們應該怎么辦？