軟件需求

前言

　　隨著計(jì)算機(jī)軟件項(xiàng)目的規(guī)模越來越大，競(jìng)爭(zhēng)日趨激烈，軟件開發(fā)組織越來越認(rèn)識(shí)到軟件質(zhì)量的重要性，在這種情況下軟件工程的理念已漸漸深入人心，人們已經(jīng)從中受益?！　≤浖枨笞鳛檐浖こ痰囊粋€(gè)階段，在軟件項(xiàng)目開發(fā)中起著至關(guān)重要的作用。軟件項(xiàng)目要取得成功，最重要的莫過于了解所要開發(fā)的軟件需要解決哪些問題，這就是軟件需求所要解決的問題，因此，軟件需求為軟件項(xiàng)目的成功奠定了基礎(chǔ)。如果軟件開發(fā)人員與客戶不進(jìn)行充分的交流與溝通，沒有就產(chǎn)品的功能性需求和非功能性需求達(dá)成共識(shí)，就匆匆忙忙開始著手編寫代碼，其后果可想而知，很可能不能滿足用戶的需要，從而不得不對(duì)項(xiàng)目進(jìn)行返工，這就造成了人力和物力的巨大浪費(fèi)。如果我們?cè)谲浖?xiàng)日開發(fā)之前，充分地完成軟件需求的相關(guān)活動(dòng)，就可以避免這種情況的發(fā)生?！　”緯且槐痉浅?shí)用的需求工程參考書，書中按照需求工程的各個(gè)階段，即需求獲取階段、需求分析階段、編寫需求規(guī)格說明階段、需求確認(rèn)階段和需求管理階段組織起來，并提供了許多有效技術(shù)，這些技術(shù)為用戶、開發(fā)人員和管理層之間進(jìn)行交流提供了方便。本書作者卡爾?E?威格（Karl E.Wiegers）是需求工程領(lǐng)域的權(quán)威人士，他曾擔(dān)任過軟件開發(fā)人員、軟件經(jīng)理以及軟件過程和質(zhì)量改進(jìn)負(fù)責(zé)人，在長(zhǎng)期的工作中積累了豐富的經(jīng)驗(yàn)。本書第1版曾榮獲軟件開發(fā)效率大獎(jiǎng)，目前已成為參與軟件開發(fā)過程的所有人員必不可少的參考書。本書第2版對(duì)第1版中所提出的最佳實(shí)踐進(jìn)行了許多擴(kuò)充，這一版不僅在每一章中都列舉了大量的實(shí)例并提供了新的案例，而且，作者還根據(jù)自己的親身經(jīng)歷，為完成不同的任務(wù)提供了頗具特色的檢查列表、范例文檔和模板。另外，作者還從自己豐富的職業(yè)生涯中精選出了一些趣聞?shì)W事，增加了技術(shù)書籍的趣味性。相信閱讀本書之后，讀者對(duì)于需求工程一定會(huì)有一個(gè)全面而透徹的理解?！　⒓颖緯g工作的人員還有蘇正泉、米強(qiáng)、張穎、夏紅、谷昀、江峰、徐利生、李宏為、趙琪、姬凌巖?！　∮捎跁r(shí)間倉(cāng)促以及水平有限，錯(cuò)誤之處在所難免，敬請(qǐng)讀者批評(píng)指正。

內(nèi)容概要

　　《軟件需求》(第2版)(Software Requirements)是有關(guān)軟件需求的經(jīng)典教材，本書全面而深入地講述了軟件開發(fā)中一個(gè)至關(guān)重要的問題——軟件需求問題。軟件開發(fā)人員及用戶往往容易忽略溝通的重要性，導(dǎo)致軟件開發(fā)出來后，不能很好地滿足用戶的需要。返工不僅在技術(shù)上給開發(fā)人員帶來巨大的麻煩，并且會(huì)造成人力、物力和資源的浪費(fèi)，還使軟件性能深受影響，所以在開發(fā)早期提高項(xiàng)目需求分析的質(zhì)量，減少重復(fù)勞動(dòng)，通過控制項(xiàng)目范圍的擴(kuò)大及需求變更來達(dá)到按計(jì)劃完成預(yù)定目標(biāo)，是當(dāng)前軟件業(yè)急需解決的問題，也是本書討論的主要內(nèi)容?！　　盾浖枨蟆?第2版)(Software Requirements)介紹了貫穿整個(gè)開發(fā)周期的管理需求工程的實(shí)用技術(shù)，包括多種可以促進(jìn)用戶、開發(fā)人員和管理層之間有效溝通的方法。這一版對(duì)第一版進(jìn)行了擴(kuò)充，提供了新的實(shí)例，及作者在實(shí)際工作中遇到的各種實(shí)際案例和解決方案。此外，還添加了新的章節(jié)、需求示例文檔以及故障診斷指南等?！　”緯鴮?duì)第1版的內(nèi)容進(jìn)行了擴(kuò)展，不僅對(duì)原有的知識(shí)點(diǎn)進(jìn)行了補(bǔ)充，還引入了一些新知識(shí)，以求與時(shí)代發(fā)展同步。

作者簡(jiǎn)介

　　Karl E.Wiegers是需求工程和軟件過程改進(jìn)領(lǐng)域內(nèi)的顧問專家。作為Process Impact公司的首席顧問，他曾舉辦過許多培訓(xùn)講習(xí)班．并多次在行業(yè)大會(huì)上發(fā)表演講。Karl曾兩次榮獲Software Development Productivity Award，這一獎(jiǎng)項(xiàng)是專門為獎(jiǎng)勵(lì)有助于提高生產(chǎn)率的產(chǎn)品和著作而設(shè)立的。

書籍目錄

第Ⅰ部分什么是軟件需求？為什么要實(shí)現(xiàn)軟件需求？哪些人應(yīng)參與軟件需求第1章 軟件需求基礎(chǔ)知識(shí)1.1 軟件需求的定義1.1.1 對(duì)需求的不同解釋1.1.2 需求的層次1.1.3 不屬于需求的內(nèi)容1.2 需求的開發(fā)與管理1.2.1 需求開發(fā)1.2.2 需求管理1.3 所有項(xiàng)目都有需求1.4 優(yōu)秀的團(tuán)隊(duì)遇到糟糕的需求1.4.1 用戶參與不足1.4.2 用戶需求擴(kuò)展1.4.3 有岐義的需求1.4.4 鍍金問題1.4.5 過于抽象的需求1.4.6 忽略了某類用戶1.4.7 不準(zhǔn)確的計(jì)劃1.5 優(yōu)質(zhì)需求過程的好處1.6 優(yōu)秀需求的特點(diǎn)1.6.1 需求陳述的特點(diǎn)1.6.2 需求規(guī)格說明的特點(diǎn)第2章 客戶眼中的需求2.1 客戶2.2 客戶與開發(fā)人員的合作伙伴關(guān)系2.2.1 軟件客戶的權(quán)利法案2.2.2 軟件客戶的義務(wù)法案2.3 關(guān)于“簽字”第3章 需求工程的推薦方法3.1 知識(shí)技能3.2 需求獲取3.3 需求分析3.4 規(guī)格說明3.5 需求驗(yàn)證3.6 需求管理3.7 項(xiàng)目管理3.8 開始新實(shí)踐3.9 需求開發(fā)過程第4章 需求分析員4.1 需求分析員的職責(zé)4.1.1 需求分析員的工作4.1.2 需求分析員必備的技能4.1.3 需求分析員必備的知識(shí)4.2 如何培養(yǎng)需求分析員4.2.1 從用戶轉(zhuǎn)為分析員4.2.2 從開發(fā)人員轉(zhuǎn)為分析員4.2.3 主題專家4.3 營(yíng)造合作的氛圍第Ⅱ部分軟件需求開發(fā)第5章 確定產(chǎn)品前景與項(xiàng)目范圍5.1 通過業(yè)務(wù)需求定義前景5.1.1 相互矛盾的業(yè)務(wù)需求5.1.2 業(yè)務(wù)需求與用例5.2 前景與范圍文檔5.3 關(guān)聯(lián)圖5.4 保持范圍的適度第6章 獲取客戶的需求6.1 需求的來源6.2 用戶類6.3 尋找用戶代表6.4 用戶代言人6.4.1 外部的用戶代言人6.4.2 對(duì)用戶代言人的要求6.4.3 設(shè)置多位用戶代言人6.4.4 如何讓人接受用戶代言人的概念6.4.5 用戶代高言人應(yīng)避免的陷阱6.5 誰來做出決策第7章 聆聽客戶的需求7.1 需求獲取7.2 需求獲取討論會(huì)7.3 將客戶的意見歸類7.4 需求獲取中的灃意事項(xiàng)7.5 尋找遺漏的需求7.6 如何判斷需求獲取是否已完成第8章 理解用戶需求8.1 用例法8.1.1 用例與使用場(chǎng)景8.1.2 確定用例8.1.3 編寫用例8.1.4 用例與功能性需求8.1.5 用例的好處8.1.6 使用用例時(shí)應(yīng)避免的問題8.2 事什一響應(yīng)表第9章 遵守規(guī)則9.1 業(yè)務(wù)的規(guī)則9.1.1 事實(shí)9.1.2 約束9.1.3 動(dòng)作觸發(fā)規(guī)則9.1.4 推論9.1.5 計(jì)算9.2 在文檔中記錄業(yè)務(wù)規(guī)則9.3 業(yè)務(wù)規(guī)則和需求第10章 編寫需求文檔10.1 軟件需求規(guī)格說明10.1.1 需求的標(biāo)識(shí)10.1.2 處理不完整性10.1.3 用戶界面和軟件需求規(guī)格說明10.2 軟件需求規(guī)格說明模板10.3 編寫需求文檔的原則10.4 改進(jìn)前后的需求示例10.5 數(shù)據(jù)字典第11章 一圖勝千言11.1 需求建模11.2 從客戶需求到分析模型11.3 數(shù)據(jù)流圖11.4 實(shí)體—關(guān)系圖11.5 狀態(tài)轉(zhuǎn)換圖11.6 對(duì)話圖11.7 類圖11.8 判定表和判定樹11.9 最后的提醒第12章 軟件質(zhì)量屬性12.1 質(zhì)量屬性12.2 定義質(zhì)量屬性12.2.1 對(duì)用戶重要的屬性12.2.2 對(duì)開發(fā)人員重要的屬性12.3 性能需求12.4 用Planguage定義非功能性需求12.5 屬性的折中方案12.6 實(shí)現(xiàn)非功能性需求第13章 通過制作原型減少項(xiàng)目風(fēng)險(xiǎn)13.1 什么足原型和為什么要建立原型13.2 水半原型13.3 垂直原型13.4 廢棄型原型13.5 演化型原型13.6 書面原型和電子原型13.7 原型評(píng)估13.8 創(chuàng)建原型所帶來的風(fēng)險(xiǎn)13.9 原型法成功的因素第14章 設(shè)定需求優(yōu)先級(jí)14.1 為什么要設(shè)定需求優(yōu)先級(jí)14.2 優(yōu)先級(jí)規(guī)則14.3 優(yōu)先級(jí)的等級(jí)14.4 根據(jù)價(jià)值、成本和風(fēng)險(xiǎn)來設(shè)定優(yōu)先級(jí)第15章 需求確認(rèn)15.1 需求評(píng)審15.1.1 審查過程15.1.2 需求評(píng)審面臨的困難15.2 測(cè)試需求15.3 制定驗(yàn)收標(biāo)準(zhǔn)第16章 需求開發(fā)面臨的特殊難題16.1 維護(hù)項(xiàng)目的需求16.1.1 開始捕獲信息16.1.2 親身實(shí)踐一下新的需求技術(shù)16.1.3 遵循跟蹤鏈16.2 軟件包解決方案的需求16.2.1 開發(fā)用例16.2.2 考慮業(yè)務(wù)規(guī)則16.2.3 定義質(zhì)量需求16.3 外包項(xiàng)目的需求16.4 突發(fā)型項(xiàng)H的需求16.4.1 非正式用戶需求規(guī)格說明16.4.2 現(xiàn)場(chǎng)客戶16.4.3 盡早地而且要經(jīng)常地設(shè)定優(yōu)先級(jí)16.4.4 簡(jiǎn)單的變更管理第17章 超越需求開發(fā)17.1 從需求到項(xiàng)日規(guī)劃17.1.1 需求和預(yù)估17.1.2 需求和進(jìn)度安排17.2 從需求到設(shè)計(jì)和編碼17.3 從需求到測(cè)試17.4 從需求到成功第Ⅲ部分軟件需求管理第18章 需求管理的原則和實(shí)踐18.1 需求基線18.2 需求管理過程18.3 需求版小控制18.4 需求屬性18.5 跟蹤需求狀態(tài)18.6 評(píng)估需求管理的工作量第19章 變更管理19.1 管理范圍蔓延19.2 變更控制過程19.2.1 變更控制策略19.2.2 變更控制過程描述19.3 變更控制委員會(huì)19.3.1 CCB的組成19.3.2 CCB規(guī)章19.4 變更控制工具19.5 測(cè)量變更活動(dòng)19.6 變更需要付出代價(jià)：影響分析19.6.1 影響分析的過程19.6.2 影響分析報(bào)告模板第20章 需求鏈中的聯(lián)系鏈20.1 需求跟蹤20.2 需求跟蹤動(dòng)機(jī)20.3 需求跟蹤矩陣20.4 需求跟蹤工具20.5 需求跟蹤過程20.6 需求跟蹤町行嗎？必要嗎？第21章 需求管理工具21.1 使用需求管理工具的益處21.2 需求管理工具的功能21.3 實(shí)現(xiàn)需求管理自動(dòng)化21.3.1 選擇適當(dāng)?shù)墓ぞ?1.3.2 改變文化21.3.3 使需求管理工具服務(wù)于自己第Ⅳ部分實(shí)現(xiàn)需求工程第22章 改進(jìn)需求過程22.1 需求與其他項(xiàng)目過程的聯(lián)系22.2 需求和各涉眾組22.3 軟件過程改進(jìn)的基本原則22.4 過程改進(jìn)周期22.4.1 評(píng)估當(dāng)前采用的方法22.4.2 規(guī)劃改進(jìn)活動(dòng)22.4.3 建立、實(shí)驗(yàn)并實(shí)現(xiàn)新過程22.4.4 評(píng)估結(jié)果22.5 需求工程過程資產(chǎn)22.5.1 需求開發(fā)過程資產(chǎn)22.5.2 需求管理過程資產(chǎn)22.6 需求過程改進(jìn)路線圖第23章 軟件需求與風(fēng)險(xiǎn)管理23.1 軟件風(fēng)險(xiǎn)管理基本原理23.1.1 風(fēng)險(xiǎn)管理的要素23.1.2 編寫項(xiàng)目風(fēng)險(xiǎn)文檔23.1.3 制定風(fēng)險(xiǎn)管理計(jì)劃23.2 與需求相關(guān)的風(fēng)險(xiǎn)23.2.1 需求獲取23.2.2 需求分析23.2.3 編寫需求規(guī)格說明23.2.4 需求確認(rèn)23.2.5 需求管理23.3 風(fēng)險(xiǎn)管理是我們的好幫手附錄A 當(dāng)前需求實(shí)踐的自我評(píng)估附錄B 需求和過程改進(jìn)模型B.1 軟件能力成熟度模型B.2 CMMI-SE/SWB.2.1 需求管理過程域B.2.2 需求開發(fā)過程域附錄C 需求錯(cuò)誤診斷指南C.1 根本原因分析C.2 需求問題的常見現(xiàn)象C.3 實(shí)現(xiàn)解決方案常常會(huì)遇到的障礙附錄D 需求文檔范例D.1 前景和范圍文檔D.1.1 業(yè)務(wù)需求D.1.2 解決方案的前景D.1.3 范圍和局限性D.1.4 業(yè)務(wù)上下文D.2 用例D.3 軟件需求規(guī)格說明D.3.1 介紹D.3.2 總體描述D.3.3 系統(tǒng)特性D.3.4 外部接口需求D.3.5 其他非功能性需求D.3.6 附錄A 數(shù)據(jù)字典和數(shù)據(jù)模型D.3.7 附錄B 分析模型D.4 業(yè)務(wù)規(guī)則術(shù)語表結(jié)語

章節(jié)摘錄

　　第1章 軟件需求基礎(chǔ)知識(shí)    “您好。是Phil么？我是人力資源部的Maria。我們使用您做的人事管理系統(tǒng)時(shí)遇到點(diǎn)問題。有位女職員想把名字改成Sparkle Starlight，可我們?cè)谙到y(tǒng)里怎么都改不過來。能幫幫忙嗎？”    “她嫁了一個(gè)姓Starlight的人么？”    “沒有，她沒結(jié)婚，只是改了名字?！盡aria答道，“所以才有這樣的麻煩。好像只有在婚姻狀況改變時(shí)才能改名字。”    “是的。我從來沒想過誰會(huì)無緣無故地改名字。我們討論系統(tǒng)的時(shí)候您可沒跟我提過這種可能。所以只能從修改婚姻狀況的對(duì)話框進(jìn)入修改名字的對(duì)話框。”    “誰都可以改名字。只要他愿意，隨時(shí)都行，這是合法的。我以為您知道呢。”Maria說，“星期五之前必須搞定，不然Sparlkle就兌換不了支票。您能在那之前把這個(gè)錯(cuò)誤改過來么？”    “這根本就不是錯(cuò)誤！”Phil反駁道，“我從來不知道您需要這個(gè)功能。我正忙著做一個(gè)新的性能評(píng)估系統(tǒng)。而且我還要對(duì)人事管理系統(tǒng)進(jìn)行一些修改，”（話筒里傳來翻紙的聲音），“對(duì)，這就有一個(gè)。月底沒準(zhǔn)能改好，這周肯定不行，抱歉。下回早點(diǎn)兒告訴我，麻煩把問題寫下來?！?   “我怎么跟Sparkle說？”Maria問，“兌不了支票她就得賒賬。”    “搞清楚，Maria，這可不是我的錯(cuò)?！盤hil抗議了，“如果您當(dāng)時(shí)告訴我要能隨時(shí)修改姓名，就不會(huì)有今天的事。您不能怪我沒猜到您的想法?！?   Maria很生氣卻無可奈何，只好氣沖沖地說：“好了。就是這種事讓我恨透了計(jì)算機(jī)。改好了馬上通知我，這總可以吧。”    如果您曾經(jīng)有過這種客戶經(jīng)歷，您肯定明白這種連最基本的操作都完不成的軟件多么讓人煩惱。即便開發(fā)人員最終可能會(huì)幫您改好，您通常也不愿總求助于他。然而，站在開發(fā)人員的立場(chǎng)，如果系統(tǒng)完成后才從用戶那里得知需要什么功能，也的確很難接受。已經(jīng)完全按最初的要求實(shí)現(xiàn)了系統(tǒng)，卻不得不停下手頭的項(xiàng)目去修改系統(tǒng)以便滿足用戶的新需求，這也是件很討厭的事。    許多軟件問題都源于收集、記錄、協(xié)商和修改產(chǎn)品需求過程中的方式不當(dāng)。前面Phil和Maria的例子中就有這些方面的問題，包括信息收集方式不正規(guī)，沒有明確提出想要的功能，假設(shè)是未經(jīng)溝通的錯(cuò)誤假設(shè)，需求的定義不夠充分，以及未經(jīng)仔細(xì)考慮進(jìn)行需求變更等。

后記

結(jié)語　　軟件項(xiàng)目要取得成功，最重要的莫過于要了解需要解決哪些問題，需求為項(xiàng)目的成功奠定了基礎(chǔ)。如果開發(fā)團(tuán)隊(duì)及其客戶沒有就產(chǎn)品功能和特性達(dá)成共識(shí)，那么其結(jié)果很可能會(huì)令人很不愉快，而這是我們都不愿意看到，且應(yīng)該盡量避免的。如果當(dāng)前的需求實(shí)踐并不能使您得到滿意的結(jié)果，那么可以仔細(xì)考慮一下本書中提出的哪些技術(shù)可能會(huì)對(duì)您有所幫助，并有選擇地應(yīng)用這些技術(shù)。有效需求工程的重要原則包括：　　客戶代表盡早介入需求工程，并且要有足夠的客戶參與?！　〉鼗蛟隽康亻_發(fā)需求?！　∫愿鞣N方式來表示需求，以確保每個(gè)人都能理解?！　〈_保需求對(duì)所有涉眾的完整性和正確性?！　】刂菩枨笞兏绞健！　∫淖冘浖_發(fā)組織的工作方式并不是一件容易的事，因?yàn)槲覀兒茈y證實(shí)當(dāng)前的工作方式不如我們喜歡的方式好，也很難斷定下一次應(yīng)該嘗試哪種方法。我們很難抽出時(shí)間學(xué)習(xí)新技術(shù)、開發(fā)改進(jìn)的軟件過程、試驗(yàn)并調(diào)整過程、以及將它們傳達(dá)到組織的其他部門。使涉眾各方確信必須進(jìn)行變更也是一件很困難的事。但是，如果不改變工作方式，我們就沒有理由相信當(dāng)前項(xiàng)目將比上一個(gè)項(xiàng)目更好　　軟件過程改進(jìn)的成功取決于下面幾個(gè)因素：　　清楚地描述組織的痛苦所在?！　∫淮沃患懈倪M(jìn)少許領(lǐng)域?！　∧繕?biāo)明確，定義改進(jìn)活動(dòng)的計(jì)劃?！　∶枋雠c組織變更相關(guān)的人為因素和文化因素。　　說服高級(jí)經(jīng)理將過程改進(jìn)視為業(yè)務(wù)成功的戰(zhàn)略投資?！　‘?dāng)我們定義圖來改進(jìn)需求工程實(shí)踐并開始付諸于行動(dòng)時(shí)，要牢記上述過程改進(jìn)原則。保留那些適合于組織和團(tuán)隊(duì)的實(shí)踐方法。如果我們積極地應(yīng)用已知的良好實(shí)踐，并依靠常識(shí)，就可以顯著地改進(jìn)處理項(xiàng)目需求的方式，并獲得由此帶來的全部?jī)?yōu)點(diǎn)和益處。另外還應(yīng)記住，沒有優(yōu)秀的需求，軟件就像是一個(gè)巧克力盒子：我們決不會(huì)知道我們將得到什么樣的產(chǎn)品。

編輯推薦

需求工程的最佳實(shí)踐，更多的示例，新主題，以及需求文檔范例如果沒有正式的可驗(yàn)證的軟件需求及有效管理需求的系統(tǒng)，開發(fā)人員開發(fā)出來的程序通常會(huì)與客戶需要的程序不一致。在本書中，Karl Wiegers對(duì)其獲獎(jiǎng)文章中的最佳實(shí)踐進(jìn)行了整理和擴(kuò)充，這些實(shí)踐是所有軟件開發(fā)參與者的重要參考依據(jù)?！盾浖枨蟆?第2版)(Software Requirements)可以作為計(jì)算機(jī)專業(yè)及軟件工程專業(yè)學(xué)生的教材使用，也非常適合作為項(xiàng)目經(jīng)理、軟件開發(fā)人員的指導(dǎo)性參考書。

圖書封面

圖書標(biāo)簽Tags

無

評(píng)論、評(píng)分、閱讀與下載

---

    軟件需求 PDF格式下載

---