編輯推薦
需求工程的優秀實踐,更多的示例,新主題,以及需求文檔範例
如果沒有正式的可驗證的軟件需求及有效管理需求的係統,開發人員開發齣來的程序通常會與客戶需要的程序不一緻。在本書中,Karl Wiegers對其獲奬文章中的優秀實踐進行瞭整理和擴充,這些實踐是所有軟件開發參與者的重要參考依據。
《軟件需求》(第2版)(Software Requirements)可以作為計算機專業及軟件工程專業學生的教材使用,也非常適閤作為項目經理、軟件開發人員的指導性參考書。
內容簡介
《軟件需求》(第2版)(Software Requirements)是有關軟件需求的經典教材,本書全麵而深入地講述瞭軟件開發中一個至關重要的問題——軟件需求問題。軟件開發人員及用戶往往容易忽略溝通的重要性,導緻軟件開發齣來後,不能很好地滿足用戶的需要。返工不僅在技術上給開發人員帶來巨大的麻煩,並且會造成人力、物力和資源的浪費,還使軟件性能深受影響,所以在開發早期提高項目需求分析的質量,減少重復勞動,通過控製項目範圍的擴大及需求變更來達到按計劃完成預定目標,是當前軟件業急需解決的問題,也是本書討論的主要內容。
《軟件需求》(第2版)(Software Requirements)介紹瞭貫穿整個開發周期的管理需求工程的實用技術,包括多種可以促進用戶、開發人員和管理層之間有效溝通的方法。這一版對一版進行瞭擴充,提供瞭新的實例,及作者在實際工作中遇到的各種實際案例和解決方案。此外,還添加瞭新的章節、需求示例文檔以及故障診斷指南等。
本書對第1版的內容進行瞭擴展,不僅對原有的知識點進行瞭補充,還引入瞭一些新知識,以求與時代發展同步。
作者簡介
Karl E.Wiegers是需求工程和軟件過程改進領域內的顧問專傢。作為Process Impact公司的首席顧問,他曾舉辦過許多培訓講習班.並多次在行業大會上發錶演講。Karl曾兩次榮獲Software Development Productivity Award,這一奬項是專門為奬勵有助於提高生産率的産品和著作而設立的。
目錄
第Ⅰ部
分什麼是軟件需求?為什麼要實現軟件需求?哪些人應參與軟件需求
第1章 軟件需求基礎知識
1.1 軟件需求的定義
1.1.1 對需求的不同解釋
1.1.2 需求的層次
1.1.3 不屬於需求的內容
1.2 需求的開發與管理
1.2.1 需求開發
1.2.2 需求管理
1.3 所有項目都有需求
1.4 優秀的團隊遇到糟糕的需求
1.4.1 用戶參與不足
1.4.2 用戶需求擴展
1.4.3 有岐義的需求
1.4.4 鍍金問題
1.4.5 過於抽象的需求
1.4.6 忽略瞭某類用戶
1.4.7 不準確的計劃
1.5 優質需求過程的好處
1.6 優秀需求的特點
1.6.1 需求陳述的特點
1.6.2 需求規格說明的特點
第2章 客戶眼中的需求
2.1 客戶
2.2 客戶與開發人員的閤作夥伴關係
2.2.1 軟件客戶的權利法案
2.2.2 軟件客戶的義務法案
2.3 關於“簽字”
第3章 需求工程的推薦方法
3.1 知識技能
3.2 需求獲取
3.3 需求分析
3.4 規格說明
3.5 需求驗證
3.6 需求管理
3.7 項目管理
3.8 開始新實踐
3.9 需求開發過程
第4章 需求分析員
4.1 需求分析員的職責
4.1.1 需求分析員的工作
4.1.2 需求分析員必備的技能
4.1.3 需求分析員必備的知識
4.2 如何培養需求分析員
4.2.1 從用戶轉為分析員
4.2.2 從開發人員轉為分析員
4.2.3 主題專傢
4.3 營造閤作的氛圍
第Ⅱ部分軟件需求開發
第5章 確定産品前景與項目範圍
5.1 通過業務需求定義前景
5.1.1 相互矛盾的業務需求
5.1.2 業務需求與用例
5.2 前景與範圍文檔
5.3 關聯圖
5.4 保持範圍的適度
第6章 獲取客戶的需求
6.1 需求的來源
6.2 用戶類
6.3 尋找用戶代錶
6.4 用戶代言人
6.4.1 外部的用戶代言人
6.4.2 對用戶代言人的要求
6.4.3 設置多位用戶代言人
6.4.4 如何讓人接受用戶代言人的概念
6.4.5 用戶代高言人應避免的陷阱
6.5 誰來做齣決策
第7章 聆聽客戶的需求
7.1 需求獲取
7.2 需求獲取討論會
7.3 將客戶的意見歸類
7.4 需求獲取中的灃意事項
7.5 尋找遺漏的需求
7.6 如何判斷需求獲取是否已完成
第8章 理解用戶需求
8.1 用例法
8.1.1 用例與使用場景
8.1.2 確定用例
8.1.3 編寫用例
8.1.4 用例與功能性需求
8.1.5 用例的好處
8.1.6 使用用例時應避免的問題
8.2 事什一響應錶
第9章 遵守規則
9.1 業務的規則
9.1.1 事實
9.1.2 約束
9.1.3 動作觸發規則
9.1.4 推論
9.1.5 計算
9.2 在文檔中記錄業務規則
9.3 業務規則和需求
第10章 編寫需求文檔
10.1 軟件需求規格說明
10.1.1 需求的標識
10.1.2 處理不完整性
10.1.3 用戶界麵和軟件需求規格說明
10.2 軟件需求規格說明模闆
10.3 編寫需求文檔的原則
10.4 改進前後的需求示例
10.5 數據字典
第11章 一圖勝韆言
11.1 需求建模
11.2 從客戶需求到分析模型
11.3 數據流圖
11.4 實體—關係圖
11.5 狀態轉換圖
11.6 對話圖
11.7 類圖
11.8 判定錶和判定樹
11.9 最後的提醒
第12章 軟件質量屬性
12.1 質量屬性
12.2 定義質量屬性
12.2.1 對用戶重要的屬性
12.2.2 對開發人員重要的屬性
12.3 性能需求
12.4 用Planguage定義非功能性需求
12.5 屬性的摺中方案
12.6 實現非功能性需求
第13章 通過製作原型減少項目風險
13.1 什麼足原型和為什麼要建立原型
13.2 水半原型
13.3 垂直原型
13.4 廢棄型原型
13.5 演化型原型
13.6 書麵原型和電子原型
13.7 原型評估
13.8 創建原型所帶來的風險
13.9 原型法成功的因素第
14章 設定需求優先級
14.1 為什麼要設定需求優先級
14.2 優先級規則
14.3 優先級的等級
14.4 根據價值、成本和風險來設定優先級
第15章 需求確認
15.1 需求評審
15.1.1 審查過程
15.1.2 需求評審麵臨的睏難
15.2 測試需求
15.3 製定驗收標準
第16章 需求開發麵臨的特殊難題
16.1 維護項目的需求
16.1.1 開始捕獲信息
16.1.2 親身實踐一下新的需求技術
16.1.3 遵循跟蹤鏈
16.2 軟件包解決方案的需求
16.2.1 開發用例
16.2.2 考慮業務規則
16.2.3 定義質量需求
16.3 外包項目的需求
16.4 突發型項H的需求
16.4.1 非正式用戶需求規格說明
16.4.2 現場客戶
16.4.3 盡早地而且要經常地設定優先級
16.4.4 簡單的變更管理
第17章 超越需求開發
17.1 從需求到項日規劃
17.1.1 需求和預估
17.1.2 需求和進度安排
17.2 從需求到設計和編碼
17.3 從需求到測試
17.4 從需求到成功
第Ⅲ部分軟件需求管理
第18章 需求管理的原則和實踐
18.1 需求基綫
18.2 需求管理過程
18.3 需求版小控製
18.4 需求屬性
18.5 跟蹤需求狀態
18.6 評估需求管理的工作量
第19章 變更管理
19.1 管理範圍蔓延
19.2 變更控製過程
19.2.1 變更控製策略
19.2.2 變更控製過程描述
19.3 變更控製委員會
19.3.1 CCB的組成
19.3.2 CCB規章
19.4 變更控製工具
19.5 測量變更活動
19.6 變更需要付齣代價:影響分析
19.6.1 影響分析的過程
19.6.2 影響分析報告模闆
第20章 需求鏈中的聯係鏈
20.1 需求跟蹤
20.2 需求跟蹤動機
20.3 需求跟蹤矩陣
20.4 需求跟蹤工具
20.5 需求跟蹤過程
20.6 需求跟蹤町行嗎?必要嗎?
第21章 需求管理工具
21.1 使用需求管理工具的益處
21.2 需求管理工具的功能
21.3 實現需求管理自動化
21.3.1 選擇適當的工具
21.3.2 改變文化
21.3.3 使需求管理工具服務於自己
第Ⅳ部分實現需求工程
第22章 改進需求過程
22.1 需求與其他項目過程的聯係
22.2 需求和各涉眾組
22.3 軟件過程改進的基本原則
22.4 過程改進周期
22.4.1 評估當前采用的方法
22.4.2 規劃改進活動
22.4.3 建立、實驗並實現新過程
22.4.4 評估結果
22.5 需求工程過程資産
22.5.1 需求開發過程資産
22.5.2 需求管理過程資産
22.6 需求過程改進路綫圖
第23章 軟件需求與風險管理
23.1 軟件風險管理基本原理
23.1.1 風險管理的要素
23.1.2 編寫項目風險文檔
23.1.3 製定風險管理計劃
23.2 與需求相關的風險
23.2.1 需求獲取
23.2.2 需求分析
23.2.3 編寫需求規格說明
23.2.4 需求確認
23.2.5 需求管理
23.3 風險管理是我們的好幫手附錄A 當前需求實踐的自我評估
附錄B 需求和過程改進模型
B.1 軟件能力成熟度模型
B.2 CMMI-SE/SWB.2.1 需求管理過程域
B.2.2 需求開發過程域
附錄C 需求錯誤診斷指南
C.1 根本原因分析
C.2 需求問題的常見現象
C.3 實現解決方案常常會遇到的障礙
附錄D 需求文檔範例
D.1 前景和範圍文檔
D.1.1 業務需求
D.1.2 解決方案的前景
D.1.3 範圍和局限性
D.1.4 業務上下文
D.2 用例
D.3 軟件需求規格說明
D.3.1 介紹
D.3.2 總體描述
D.3.3 係統特性
D.3.4 外部接口需求
D.3.5 其他非功能性需求
D.3.6 附錄A 數據字典和數據模型
D.3.7 附錄B 分析模型
D.4 業務規則
術語錶
結語
精彩書摘
第1章 軟件需求基礎知識
“您好。是Phil麼?我是人力資源部的Maria。我們使用您做的人事管理係統時遇到點問題。有位女職員想把名字改成Sparkle Starlight,可我們在係統裏怎麼都改不過來。能幫幫忙嗎?”
“她嫁瞭一個姓Starlight的人麼?”
“沒有,她沒結婚,隻是改瞭名字。”Maria答道,“所以纔有這樣的麻煩。好像隻有在婚姻狀況改變時纔能改名字。”
“是的。我從來沒想過誰會無緣無故地改名字。我們討論係統的時候您可沒跟我提過這種可能。所以隻能從修改婚姻狀況的對話框進入修改名字的對話框。”
“誰都可以改名字。隻要他願意,隨時都行,這是閤法的。我以為您知道呢。”Maria說,“星期五之前必須搞定,不然Sparlkle就兌換不瞭支票。您能在那之前把這個錯誤改過來麼?”
“這根本就不是錯誤!”Phil反駁道,“我從來不知道您需要這個功能。我正忙著做一個新的性能評估係統。而且我還要對人事管理係統進行一些修改,”(話筒裏傳來翻紙的聲音),“對,這就有一個。月底沒準能改好,這周肯定不行,抱歉。下迴早點兒告訴我,麻煩把問題寫下來。”
“我怎麼跟Sparkle說?”Maria問,“兌不瞭支票她就得賒賬。”
“搞清楚,Maria,這可不是我的錯。”Phil抗議瞭,“如果您當時告訴我要能隨時修改姓名,就不會有今天的事。您不能怪我沒猜到您的想法。”
Maria很生氣卻無可奈何,隻好氣衝衝地說:“好瞭。就是這種事讓我恨透瞭計算機。改好瞭馬上通知我,這總可以吧。”
如果您曾經有過這種客戶經曆,您肯定明白這種連最基本的操作都完不成的軟件多麼讓人煩惱。即便開發人員最終可能會幫您改好,您通常也不願總求助於他。然而,站在開發人員的立場,如果係統完成後纔從用戶那裏得知需要什麼功能,也的確很難接受。已經完全按最初的要求實現瞭係統,卻不得不停下手頭的項目去修改係統以便滿足用戶的新需求,這也是件很討厭的事。
許多軟件問題都源於收集、記錄、協商和修改産品需求過程中的方式不當。前麵Phil和Maria的例子中就有這些方麵的問題,包括信息收集方式不正規,沒有明確提齣想要的功能,假設是未經溝通的錯誤假設,需求的定義不夠充分,以及未經仔細考慮進行需求變更等。
前言/序言
隨著計算機軟件項目的規模越來越大,競爭日趨激烈,軟件開發組織越來越認識到軟件質量的重要性,在這種情況下軟件工程的理念已漸漸深入人心,人們已經從中受益。
軟件需求作為軟件工程的一個階段,在軟件項目開發中起著至關重要的作用。軟件項目要取得成功,最重要的莫過於瞭解所要開發的軟件需要解決哪些問題,這就是軟件需求所要解決的問題,因此,軟件需求為軟件項目的成功奠定瞭基礎。如果軟件開發人員與客戶不進行充分的交流與溝通,沒有就産品的功能性需求和非功能性需求達成共識,就匆匆忙忙開始著手編寫代碼,其後果可想而知,很可能不能滿足用戶的需要,從而不得不對項目進行返工,這就造成瞭人力和物力的巨大浪費。如果我們在軟件項日開發之前,充分地完成軟件需求的相關活動,就可以避免這種情況的發生。
本書是一本非常實用的需求工程參考書,書中按照需求工程的各個階段,即需求獲取階段、需求分析階段、編寫需求規格說明階段、需求確認階段和需求管理階段組織起來,並提供瞭許多有效技術,這些技術為用戶、開發人員和管理層之間進行交流提供瞭方便。本書作者卡爾?E?威格(Karl E.Wiegers)是需求工程領域的權威人士,他曾擔任過軟件開發人員、軟件經理以及軟件過程和質量改進負責人,在長期的工作中積纍瞭豐富的經驗。本書第1版曾榮獲軟件開發效率大奬,目前已成為參與軟件開發過程的所有人員必不可少的參考書。本書第2版對第1版中所提齣的最佳實踐進行瞭許多擴充,這一版不僅在每一章中都列舉瞭大量的實例並提供瞭新的案例,而且,作者還根據自己的親身經曆,為完成不同的任務提供瞭頗具特色的檢查列錶、範例文檔和模闆。另外,作者還從自己豐富的職業生涯中精選齣瞭一些趣聞軼事,增加瞭技術書籍的趣味性。相信閱讀本書之後,讀者對於需求工程一定會有一個全麵而透徹的理解。
參加本書翻譯工作的人員還有蘇正泉、米強、張穎、夏紅、榖昀、江峰、徐利生、李宏為、趙琪、姬淩岩。
由於時間倉促以及水平有限,錯誤之處在所難免,敬請讀者批評指正。
軟件需求(第2版) [Software Requirements] epub pdf mobi txt 電子書 下載 2024
軟件需求(第2版) [Software Requirements] 下載 epub mobi pdf txt 電子書