軟件需求

所属分类:軟件工程及軟件方法學  
出版时间:2004-11   出版时间:清華大學出版社   作者:(美)Karl E.Wiegers   页数:357  

前言

  隨著計算機軟件項目的規模越來越大,競爭日趨激烈,軟件開發組織越來越認識到軟件質量的重要性,在這種情況下軟件工程的理念已漸漸深入人心,人們已經從中受益。  軟件需求作為軟件工程的一個階段,在軟件項目開發中起著至關重要的作用。軟件項目要取得成功,最重要的莫過于了解所要開發的軟件需要解決哪些問題,這就是軟件需求所要解決的問題,因此,軟件需求為軟件項目的成功奠定了基礎。如果軟件開發人員與客戶不進行充分的交流與溝通,沒有就產品的功能性需求和非功能性需求達成共識,就匆匆忙忙開始著手編寫代碼,其後果可想而知,很可能不能滿足用戶的需要,從而不得不對項目進行返工,這就造成了人力和物力的巨大浪費。如果我們在軟件項日開發之前,充分地完成軟件需求的相關活動,就可以避免這種情況的發生。  本書是一本非常實用的需求工程參考書,書中按照需求工程的各個階段,即需求獲取階段、需求分析階段、編寫需求規格說明階段、需求確認階段和需求管理階段組織起來,並提供了許多有效技術,這些技術為用戶、開發人員和管理層之間進行交流提供了方便。本書作者卡爾E威格(Karl E.Wiegers)是需求工程領域的權威人士,他曾擔任過軟件開發人員、軟件經理以及軟件過程和質量改進負責人,在長期的工作中積累了豐富的經驗。本書第1版曾榮獲軟件開發效率大獎,目前已成為參與軟件開發過程的所有人員必不可少的參考書。本書第2版對第1版中所提出的最佳實踐進行了許多擴充,這一版不僅在每一章中都列舉了大量的實例並提供了新的案例,而且,作者還根據自己的親身經歷,為完成不同的任務提供了頗具特色的檢查列表、範例文檔和模板。另外,作者還從自己豐富的職業生涯中精選出了一些趣聞軼事,增加了技術書籍的趣味性。相信閱讀本書之後,讀者對于需求工程一定會有一個全面而透徹的理解。  參加本書翻譯工作的人員還有甦正泉、米強、張穎、夏紅、谷昀、江峰、徐利生、李宏為、趙琪、姬凌岩。  由于時間倉促以及水平有限,錯誤之處在所難免,敬請讀者批評指正。

内容概要

  《软件需求》(第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的例子中就有這些方面的問題,包括信息收集方式不正規,沒有明確提出想要的功能,假設是未經溝通的錯誤假設,需求的定義不夠充分,以及未經仔細考慮進行需求變更等。

后记

結語  軟件項目要取得成功,最重要的莫過于要了解需要解決哪些問題,需求為項目的成功奠定了基礎。如果開發團隊及其客戶沒有就產品功能和特性達成共識,那麼其結果很可能會令人很不愉快,而這是我們都不願意看到,且應該盡量避免的。如果當前的需求實踐並不能使您得到滿意的結果,那麼可以仔細考慮一下本書中提出的哪些技術可能會對您有所幫助,並有選擇地應用這些技術。有效需求工程的重要原則包括︰  客戶代表盡早介入需求工程,並且要有足夠的客戶參與。  迭代地或增量地開發需求。  以各種方式來表示需求,以確保每個人都能理解。  確保需求對所有涉眾的完整性和正確性。  控制需求變更方式。  要改變軟件開發組織的工作方式並不是一件容易的事,因為我們很難證實當前的工作方式不如我們喜歡的方式好,也很難斷定下一次應該嘗試哪種方法。我們很難抽出時間學習新技術、開發改進的軟件過程、試驗並調整過程、以及將它們傳達到組織的其他部門。使涉眾各方確信必須進行變更也是一件很困難的事。但是,如果不改變工作方式,我們就沒有理由相信當前項目將比上一個項目更好  軟件過程改進的成功取決于下面幾個因素︰  清楚地描述組織的痛苦所在。  一次只集中改進少許領域。  目標明確,定義改進活動的計劃。  描述與組織變更相關的人為因素和文化因素。  說服高級經理將過程改進視為業務成功的戰略投資。  當我們定義圖來改進需求工程實踐並開始付諸于行動時,要牢記上述過程改進原則。保留那些適合于組織和團隊的實踐方法。如果我們積極地應用已知的良好實踐,並依靠常識,就可以顯著地改進處理項目需求的方式,並獲得由此帶來的全部優點和益處。另外還應記住,沒有優秀的需求,軟件就像是一個巧克力盒子︰我們決不會知道我們將得到什麼樣的產品。

编辑推荐

需求工程的最佳實踐,更多的示例,新主題,以及需求文檔範例如果沒有正式的可驗證的軟件需求及有效管理需求的系統,開發人員開發出來的程序通常會與客戶需要的程序不一致。在本書中,Karl Wiegers對其獲獎文章中的最佳實踐進行了整理和擴充,這些實踐是所有軟件開發參與者的重要參考依據。《軟件需求》(第2版)(Software Requirements)可以作為計算機專業及軟件工程專業學生的教材使用,也非常適合作為項目經理、軟件開發人員的指導性參考書。

图书封面




    軟件需求下載



用户评论 (总计22条)

 
 

  •     發貨速度挺快,服務也不錯,書也很好,正在看。就是書的紙張質地,太毛糙了,感覺像是盜版的,或者放了好久以後的樣子。。。汗了。。。不過,好在是書籍不影響閱讀。
  •     紙質一般,部分內容有錯誤
  •     這本書不錯,原著外國作者,但此書翻譯得比較好,符合東方人語言習慣。全書內容很全面而且詳細,並配合案例說明,其中還附有標準的需求文檔模板。
  •     唉,這年頭的正版書質量還不如盜版。
  •     層次分明,講解詳盡,適合入門。
  •     比較全面講到需求過程的東西
  •     內容編排比較淺顯,適合初學者。
  •     書寫的真不錯,真在讀。。。。
  •     經典讀物,偶爾參考。
  •     挺好的書,獲益匪淺,贊一個
  •     听說amazon的評價特別牛
  •     是指雖然一般,但內容不錯,翻譯的水平也可以。
  •     適合初級的。只是了解節本知識用。
  •     質量還好,基本屬于入門書籍
  •     軟件需求分析,外國人的中文譯本。
  •     這本書是從代碼大全2的介紹中了解到的,特地買了一本。看了前兩章還不錯,雖說是外國人寫的需求方面的,但國內的情況也是非常相近的。只是覺得知道這本書有點晚,早幾年估計不會像現在這樣做項目那麼痛苦了。
  •     紙張和印刷質量太差,翻開全是刺鼻的味道,讓人喉嚨難受,本來是一本好書,結果卻不想閱讀還是清華大學出版社的 正版不應該是這樣的吧 亞馬遜賣出這樣質量的書 真是台令人失望了
  •     書是很久以前的
  •     軟件需求
  •     不錯,適合軟件開發人員
  •     很不錯的壓縮袋
  •     別人買的,說是不錯

相关推荐图书资源

 

計算機與互聯網 PDF免费下载,軟件工程及軟件方法學PDF免费下载。 计算机教程网 

计算机教程网 @ 2018