《軟件需求》學(xué)習(xí)筆記
前幾天讀了Karl E.Wiegers《軟件需求》，書的內(nèi)容寫得非常好。我這里談?wù)勛x了此書之后的一些感受。概括起來包括以下幾點(diǎn)：
一、需求層次
二、需求開發(fā)（需求工程方法、需求來源、如何獲取需求并給出一些指導(dǎo)方法）
需求分析過程：
1、 需求收集：
定義項目的視圖和范圍。
學(xué)習(xí)與了解本行業(yè)的知識，這樣與用戶比較容易溝通。
訪問有潛力的用戶,對用戶進(jìn)行分類并找各自合適的代表，找出新軟件產(chǎn)品的用戶需求。注意與用戶溝通技巧。
對目前市場上競爭產(chǎn)品進(jìn)行研究，進(jìn)行功能提取與解決方案分析，寫成文檔。
收集了用戶在使用現(xiàn)有系統(tǒng)過程中所遇到問題的信息，還接受了用戶關(guān)于系統(tǒng)改進(jìn)的想法。
市場調(diào)查和用戶問卷調(diào)查。
觀察正在工作的用戶，預(yù)見用戶在使用當(dāng)前系統(tǒng)時所遇到的問題，并能分析新的系統(tǒng)可有效支持工作流程與功能。
2、 需求分析：
繪制關(guān)聯(lián)圖
創(chuàng)建開發(fā)原型
確定需求優(yōu)先級
為需求建立模型
編寫數(shù)據(jù)字典
3、 編寫規(guī)格說明書
采用軟件需求規(guī)格說明模版，可以采用CMMI中的需求規(guī)格說明模版。
正確的、完整的表達(dá)所描述的需求。
4、 需求驗證
對需求進(jìn)行審查
用測試用例來驗證需求
三、需求管理方法以及常用需求管理工具管理需求。
需求層次
1、 軟件需求層次：
層次
內(nèi)容描述
呈現(xiàn)方式
業(yè)務(wù)需求
組織機(jī)構(gòu)或客戶對系統(tǒng)、產(chǎn)品高層次的目標(biāo)要求。
項目視圖與范圍文檔中予以說明
用戶需求
用戶使用產(chǎn)品必須要完成的任務(wù)
Use Case
功能需求
必須實(shí)現(xiàn)的軟件功能
需求規(guī)格說明文檔中功能需求說明
非功能需求
系統(tǒng)展現(xiàn)給用戶的行為和執(zhí)行的操作等，包括產(chǎn)品必須遵從的標(biāo)準(zhǔn)、規(guī)范和合約；外部界面的具體細(xì)節(jié)；性能要求；設(shè)計或?qū)崿F(xiàn)的約束條件及質(zhì)量屬性。
需求規(guī)格說明文檔中非功能需求說明
2、 軟件需求各組成部分之間的關(guān)系，實(shí)際上也就是業(yè)務(wù)需求、用戶需求、功能需求、非功能需求等之間的關(guān)系。
需求開發(fā)
3、優(yōu)秀需求具有的特性
7大特性，多注意優(yōu)先級與可驗證性，因為這兩點(diǎn)在項目中實(shí)際關(guān)注的比較少。
1）完整性
2）正確性
3）可行性
4）必要性
5）劃分優(yōu)先級
給每項需求、特性或使用實(shí)例分配一個實(shí)施優(yōu)先級以指明它在特定產(chǎn)品中所占的分量。如果把所有的需求都看作同樣重要，那么項目管理者在開發(fā)或節(jié)省預(yù)算或調(diào)度中就喪失控制自由度。
6）無二義性
7）可驗證性
檢查一下每項需求是否能通過設(shè)計測試用例或其它的驗證方法，如用演示、檢測等來確定產(chǎn)品是否確實(shí)按需求實(shí)現(xiàn)了。如果需求不可驗證，則確定其實(shí)施是否正確就成為主觀臆斷，而非客觀分析了。
4、需求工程的結(jié)構(gòu)（需求開發(fā)與需求管理）
1. 需求開發(fā)，分為四個步驟
A) 問題獲取
B) 分析
C) 編寫規(guī)格說明
D) 驗證(評審，編制測試用例)
2. 需求管理，即需求追蹤、變更控制等
5、需求工程推薦方法
知
識
技
能
培訓(xùn)需求分析人員
培訓(xùn)用戶代表和管理人員
培訓(xùn)應(yīng)用領(lǐng)域的開發(fā)人員
匯編術(shù)語
需
求
管
理
確定變更控制過程
建立變更控制委員會
進(jìn)行變更影響分析
跟蹤影響工作產(chǎn)品的每項
編寫需求文檔的基準(zhǔn)版本
維護(hù)變更歷史記錄
跟蹤需求狀態(tài)
衡量需求穩(wěn)定性
使用需求管理工具
項
目
管
理
選擇合適的生存周期
確定需求的基本計劃
協(xié)商約定
管理需求風(fēng)險
跟蹤需求工作
需
求
開
發(fā)
獲 取
編寫項目視圖與范圍
確定需求開發(fā)過程
用戶群分類
選擇產(chǎn)品代表
建立核心隊伍
確定使用實(shí)例
召開應(yīng)用程序開發(fā)
聯(lián)系（J A D）會議
分析用戶工作流程
確定質(zhì)量屬性
檢查問題報告
需求重用
分 析
繪制關(guān)聯(lián)圖
創(chuàng)建開發(fā)原型
分析可行性
確定需求優(yōu)先級
為需求建立模型
編寫數(shù)據(jù)字典
應(yīng)用質(zhì)量功能調(diào)配
（Q F D）
編寫規(guī)格說明書
采用軟件需求規(guī)格說明模版
指明需求來源
為每項需求注上標(biāo)號
記錄業(yè)務(wù)規(guī)范
創(chuàng)建需求跟蹤能力矩陣
驗 證
審查需求文檔
依據(jù)需求編寫測試用例
編寫用戶手冊
確定合格的標(biāo)準(zhǔn)
需求工程注重應(yīng)用“最佳方法”。不要想著把所有這些方法都用于你的下一個項目。而應(yīng)該考慮將其中的一些方法推薦到你的需求工具箱中。不管你的項目處在開發(fā)的哪個階段，你都可以馬上開始應(yīng)用某些方法，譬如變更管理的處理。其它如需求獲取等可以在你的下一個項目開始時付諸應(yīng)用。當(dāng)然其它一些方法也可能并不適合你目前的項目。
6、需求來源、需求收集方法
軟件需求可以來自方方面面，這取決于所開發(fā)產(chǎn)品的性質(zhì)和開發(fā)環(huán)境。需從不同用戶代表和來源收集需求，這說明了需求工程是以相互交流為核心的性質(zhì)。下面是幾個軟件需求的典型來源。
1）. 訪問并與有潛力的用戶探討為找出新軟件產(chǎn)品的用戶需求，最直截了當(dāng)?shù)姆椒ㄊ窃儐査麄儭?/div>
2）. 把對目前的或競爭產(chǎn)品的描述寫成文檔
文檔可以描述一種所必須遵循的標(biāo)準(zhǔn)或產(chǎn)品所必須遵循的政府或工業(yè)規(guī)則。
3）. 系統(tǒng)需求規(guī)格說明
一個包含軟、硬件的產(chǎn)品需要一個高檔次的系統(tǒng)需求規(guī)格說明以介紹整個產(chǎn)品。系統(tǒng)需求的子集被分配到每個軟件子系統(tǒng)中（Nelsen 1990） 。附加的詳細(xì)軟件功能需求將從有關(guān)軟件
的系統(tǒng)需求里獲得。
4）. 對當(dāng)前系統(tǒng)的問題報告和增強(qiáng)要求指導(dǎo)用戶和提供技術(shù)支持的工作人員是最有價值的需求來源。他們收集了用戶在使用現(xiàn)有系統(tǒng)過程中所遇到問題的信息，還接受了用戶關(guān)于系統(tǒng)改進(jìn)的想法。
5）. 市場調(diào)查和用戶問卷調(diào)查
調(diào)查有助于從廣大有潛力的用戶那里獲得大量定量的數(shù)據(jù)，務(wù)必調(diào)查相關(guān)的用戶并詢問一些能產(chǎn)生反響的好問題。
6）. 觀察正在工作的用戶
對當(dāng)前系統(tǒng)的用戶和將來系統(tǒng)的有潛力的用戶，分析員觀察“日常工作”以獲得經(jīng)驗，這些經(jīng)驗?zāi)芴峁┖苡袃r值的信息。分析員可通過觀察用戶與所關(guān)聯(lián)的任務(wù)環(huán)境的工作流程來預(yù)見用戶在使用當(dāng)前系統(tǒng)時所遇到的問題，并能分析新的系統(tǒng)可有效支持工作流程的方面（McGraw and Harbison 1997; Beyer and Holtzblatt 1998） 。比起僅僅簡單地詢問用戶，并記下用戶在處理任務(wù)時的步驟來說，直接觀察用戶的工作流程可以對他們的活動有更正確的理解。分析員必須抽象和總結(jié)用戶的直接活動，以確保所獲得的需求具有普遍性，而不僅僅代表單個用戶。一個富有技巧的分析員還可以為改進(jìn)用戶的當(dāng)前事務(wù)處理過程提出一些見解。
7）. 用戶任務(wù)的內(nèi)容分析
通常通過開發(fā)具體的情節(jié)（s c e n a r i o）或活動順序（有時稱作“情節(jié)” ） ，可以確定用戶利用系統(tǒng)需要完成的任務(wù)，分析員由此可以獲得用戶用于處理任務(wù)的必要的功能需求。這是使用實(shí)例方法的精髓。
7、需求開發(fā)活動指導(dǎo)方針
對于需求開發(fā)沒有一個簡單的、公式化的途徑。下面列出了1 4個步驟，你可以利用它們指導(dǎo)你的需求開發(fā)活動。
1）. 定義項目的視圖和范圍
2）. 確定用戶類（比如市場人員、財務(wù)人員、生產(chǎn)人員等）
3）. 在每個用戶類中確定適當(dāng)?shù)拇?/div>
4）. 確定需求決策者和他們的決策過程
5）. 選擇你所用的需求獲取技術(shù)
6）. 運(yùn)用需求獲取技術(shù)對作為系統(tǒng)一部分的使用實(shí)例進(jìn)行開發(fā)并設(shè)置優(yōu)先級
7）. 從用戶那里收集質(zhì)量屬性的信息和其它非功能需求
8）. 詳細(xì)擬訂使用實(shí)例使其融合到必要的功能需求中
9）. 評審使用實(shí)例的描述和功能需求
10）. 如果有必要，就要開發(fā)分析模型用以澄清需求獲取的參與者對需求的理解
11）. 開發(fā)并評估用戶界面原型以助想像還未理解的需求
12）. 從使用實(shí)例中開發(fā)出概念測試用例
13）. 用測試用例來論證使用實(shí)例、功能需求、分析模型和原型
14）. 在繼續(xù)進(jìn)行設(shè)計和構(gòu)造系統(tǒng)每一部分之前，重復(fù) 6 ~ 1 3步
8、編寫軟件需求規(guī)格說明
可以用三種方法編寫軟件需求規(guī)格說明：
用好的結(jié)構(gòu)化和自然語言編寫文本型文檔。
建立圖形化模型，這些模型可以描繪轉(zhuǎn)換過程、系統(tǒng)狀態(tài)和它們之間的變化、數(shù)據(jù)關(guān)系、
邏輯流或?qū)ο箢惡退鼈兊年P(guān)系。
編寫形式化規(guī)格說明，這可以通過使用數(shù)學(xué)上精確的形式化邏輯語言來定義需求。
由于形式化規(guī)格說明具有很強(qiáng)的嚴(yán)密性和精確度，因此，所使用的形式化語言只有極少數(shù)軟件開發(fā)人員才熟悉，更不用說客戶了。雖然結(jié)構(gòu)化的自然語言具有許多缺點(diǎn)，但在大多數(shù)軟件工程中，它仍是編寫需求文檔最現(xiàn)實(shí)的方法。包含了功能和非功能需求的基于文本的軟件需求規(guī)格說明已經(jīng)為大多數(shù)項目所接受。圖形化分析模型通過提供另一種需求視圖，增強(qiáng)了軟件需求規(guī)格說明。
9、減少項目風(fēng)險的方法
可以利用軟件原型這種技術(shù)減少客戶對產(chǎn)品不滿意的風(fēng)險。一個軟件原型是所提出的新產(chǎn)品的部分實(shí)現(xiàn)。使用原型有三個主要目的：
明確并完善需求 原型作為一種需求工具，它初步實(shí)現(xiàn)所理解的系統(tǒng)的一部分。用戶對原型的評價可以指出需求中的許多問題，在你開發(fā)真正產(chǎn)品之前，可以最低的費(fèi)用來解決這些問題。
探索設(shè)計選擇方案 原型作為一種設(shè)計工具，用它可以探索不同的用戶界面技術(shù)，使系統(tǒng)達(dá)到最佳的可用性，并且可以評價可能的技術(shù)方案。
發(fā)展為最終的產(chǎn)品原型 作為一種構(gòu)造工具，是產(chǎn)品最初子集的完整功能實(shí)現(xiàn)，通過一系列小規(guī)模的開發(fā)循環(huán)，你可以完成整個產(chǎn)品的開發(fā)。
軟件原型的典型應(yīng)用：
拋 棄 型
演 化 型
水平
澄清并精化使用實(shí)例和功能需求
查明遺漏的功能
探索用戶界面方法
實(shí)現(xiàn)核心的使用實(shí)例
根據(jù)優(yōu)先級，實(shí)現(xiàn)附加的使用實(shí)例
開發(fā)并精化We b站點(diǎn)
垂直
證明技術(shù)的可行性
實(shí)現(xiàn)并發(fā)展核心的客戶/服務(wù)器功能層和通信層
實(shí)現(xiàn)并優(yōu)化核心算法
需求管理
10、需求管理的策略、主要活動
需求管理的策略：包括變更控制，需求跟蹤（跟蹤矩陣、需求狀態(tài)跟蹤如 已建議，已批準(zhǔn)，已實(shí)現(xiàn)，已驗證，已刪除）和變更的影響分析。
需求管理的主要活動：
11、常見的需求管理工具
RequisitePro
CaliberRM
DOORS
這里推薦幾個開源需求管理工具: JRequisite、reqheap
本站僅提供存儲服務(wù)，所有內(nèi)容均由用戶發(fā)布，如發(fā)現(xiàn)有害或侵權(quán)內(nèi)容，請
點(diǎn)擊舉報。
