《软件需求讲义-第一部分综述》由会员分享，可在线阅读，更多相关《软件需求讲义-第一部分综述（68页珍藏版）》请在金锄头文库上搜索。
1、软件需求 从谚语开始 p中国有句谚语：“好的开始就等于成功的一半” p西方的谚语是：“Garbage in, garbage out！” 内容概要 p软件需求的基本概念 p需求工程与需求工程过程 p需求获取与需求分析 p需求文档与需求质量验证 p软件需求管理 软件需求参考书 作者：黄国兴 周勇 出版社：清华大学出版社 软件需求工程软件需求工程 本书着重介绍了软件需求工程的基本概念、基本理论和实 际应用技术。内容涵盖了需求工程中的每个重要步骤，提供了 一些检查表和比较简单易懂的需求过程模型和建模实践。 软件需求参考书 作者：（美）karl e.wiegers 译者： 刘伟琴 刘洪涛 出版社：清华
2、大学出版社 软件需求（第软件需求（第2 2版）版） 本书介绍了贯穿整个开发周期的管理需求工程的实用技术 ，包括多种可以促进用户、开发人员和管理层之间有效沟通的 方法。这一版对第一版进行了扩充，提供了新的实例，及作者 在实际工作中遇到的各种实际案例和解决方案。此外，还添加 了新的章节、需求示例文档以及故障诊断指南等。 参考教材 作者： 张海藩 编著 出版社：清华大学出版社 软件工程导论（第软件工程导论（第4 4版）版） 本书是在吸取了国内外有关教材的精华，并结 合编者多年来进行软件工程的教学及软件开发实践 的经验、体会的基础上编写的，软件工程领域的经 典教材，尤其结构化的软件建模方法值得借鉴。
3、参考教材 作者：邝孔武，王晓敏 编著 出版社：清华大学出版社 信息系统分析与设计信息系统分析与设计 本书是在吸取了国内外有关教材的精华，并结合编者多 年来的教学及软件开发实践的经验、体会的基础上编写的， 通过典型案例，展示了使用面向对象方法和结构化方法进行 软件建模的具体思路和步骤。 参考教材 作者：蔡敏，徐慧慧，黄炳强 编著 出版社：人民邮电出版社 UMLUML基础与基础与RoseRose建模教程建模教程 本书是在吸取了国内外有关教材的精华，并结合编者多 年来的教学及软件开发实践的经验、体会的基础上编写的， 通过4个综合性的案例，展示了使用UML和Rose进行软件建模 的具体方法和步骤。 参
4、考教材 4.4.软件工程软件工程 Software Engineering, 6th Edition 作者：（英）Ian Sommerville 出版社：机械工业出版社（影印版 ） 本书是英国著名软件工程学家 Ian Sommerville 系统介绍软件工 程理论的力作，以要求极高的一类 系统为实例，精辟透彻地阐述了软 件工程的内涵。 参考网站 www.sei.cmu.edu 卡内基梅大学软件工程研究所 http:/www.cetus-links.org/ 对象技术和构件技术 链接 Rational公司 http:/www.omg.org OMG(Object Management Group
5、) 1. 软件工程java实现 software engineering with java mcagraw-hill Stephen R.Schach 袁兆山 机械工业出版社 1999-9-1本书介 绍经典的和面向对象的软件工程，强调理论、抽象和设计相结合，重视对 软件工程学有指导作用的重要概念。 2. 软件工程概论 清华大学 殷人坤 3. 软件工程导论 清华大学 张海藩 (第四版) 4. Java面向对象编程指南 韩柯 电子工业出版社 5. 面向对象的系统分析与设计 （uml） 清华大学出版社 6. Uml系统分析设计与应用案例 人民邮电 7.编写有效用例 机械工业 8 . Ood启思录
6、人民邮电 9 .重构改善既有代码的设计（中文版） Refactoring: Improving the Design of Existing Code 作者：美Martin Fowler/著 译者：侯捷 熊 节/译 出版社：中国电力出版社 2003年8 参考书 10. 设计模式: 可复用面向对象软件的基础 design patterns:elements of reusable object-oriented software Addsion Wesley/Person publisher author: Erich Gamma 李英军 机械工业出版社 2000-9-1 软件工程的重要概念就是
7、可复用。近几年来“模式”给出了“软件可复用” 的漂亮解决方案。所谓模式一词来源于城市建筑领域，“每一个模式描述 了一个在我们周围不断重复发生的问题以及该问题的解决方案的核心。 这样，你就能多次使用该方案而不必做重复劳动。”这种思想应用在面向 对象设计领域，指的是总结软件设计中遇到的各类问题，并提出设计的 解决方案。 有经验的设计者知道，不是解决任何问题都要从头开始。这 本书的目的就是将面向对象软件的设计经验作为设计模式记录下来，每 一个设计模式系统地命名、解释和评价了面向对象系统中一个重要的和 重复的设计。 参考书 11.敏捷软件开发：原则、模式与实践 Agile Software Devel
8、opment: Principles, Patterns, and Practices 原出版社： Pearson Education 作者：美Robert C. Martin/著 邓辉译 清华大学出版社 2003年9月 1.讲述在预算和时间要求下，软件开发人员和项目经理如何使用敏 捷开发完成项目。 2.使用真实案例讲解如何用极限编程来设计、测试、量构和结对编 程 3.包含了极具价值的可多次使用的C+和JAVA源代码。 4.重点讲述了如何使用UML和设计模式解决面向客户系统 参考书 12.与熊共舞：软件项目风险管理 Waltzing With Bears: Managing Risk on S
9、oftware Projects 书中，作者展示了风险管理的益处风险管理使企业可以积极地 迎接风险使管理不致陷于盲目使项目能够以最小代价应对风险 使责权划分更加明确使子项目的失败不致影响全盘。 13. 软件工程思想 电子 林锐 14. 软件工程36计 金樽和 机械工业出版社 15. Uml核心建模技术 参考书 第一部分 软件需求的基本概念 p需求问题 p需求的层次 第1章需求问题 p需求是软件项目成败的关键所在 p越早发现需求错误，越早改正它，其代价越小 p需求的定义 p好需求的特征：无歧义、完整、一致、可检验、 确定、可跟踪的，正确的，可行的和必要的。 软件开发中的错误观点 p只要掌握了1-
10、2门程序设计语言，进行软件开发就 没有问题。 p只要有最好的开发工具、最好的计算机，一定能做 出优秀的软件。 p软件需求分析很困难，不管三七二十一，先把软件 做了再说，反正软件是灵活的，随时可以修改。 总之，错误认为：软件就是程序，开发软件就是编写 程序。 项目失败与成功的原因* p三种最经常使项目“遇到困难”的因素是： n缺乏用户介入：占所有项目的13% n不完整的需求和规格说明：占所有项目的12% n不断改变的需求和规格说明：占所有项目的12% p三种项目最主要的“成功因素”是： n用户介入：占所有成功项目的16% n高层管理的支持：占所有成功项目的14% n需求陈述清晰：占所有成功项目的
11、12% *Standish Group ，1994 软件开发的目标 p软件开发的目标，简单而言，就是满足用户的需 要 。 需求在项目中的作用 p未真正明白这些问题就开始编码，结果没有人对 产品满意 。 p在项目开发中，所有的涉众（Stakeholder）都 对需求分析阶段备感兴趣。（没有理所当然的需 求） p2-8 原则：举足轻重 2-8 原则* p80%的工程活动是由20%的需求消耗的 p80%的软件成本是由20%的构件消耗的 *Royce，1998 需求错误的代价 在生命周期的不同阶段修复缺陷的相对成本 23 需求的重要性 p重要性 Davis A. M.研究发现，在需求阶段检查和修 复一
12、个错误所需的费用只有编码阶段的1/5到 1/10，而在维护阶段做同样的工作所需付出的代 价却是编码阶段的20倍。 p结论 在软件开发过程中，必须极早、有效地发现和 解决与需求相关的问题。 需求缺陷造成的成本增加 p重新进行需求规格说明 p重新设计 p重新编码 p重新测试 p改变订单告诉用户将以一个修正后的版本来替代有缺陷的版本。 p纠正活动消除由于不准确的特定系统的错误造成的危害，可能涉 及到赔偿客户损失。 p报废包括对于已经完成的代码、设计和测试，当发现它们是根据 不正确的需求进行的时候，这些工作成果不得不被丢弃。 p收回有缺陷的软件产品以及相关的用户手册。 p产品赔偿或保修的成本。 p重新
13、安装新版本的成本。 p重新建档的成本。 高质量的需求过程带来的好处 p在开发后期和整个维护阶段的重做的工作大大减少了 。 p让用户积极参与需求收集过程能使产品更富有吸引力，而 且能建立起更加忠实的客户关系 。 p用户的参与能弥补用户期望和开发者实际开发之间的“鸿 沟”（期望差异）。 p将确定的系统需求明确地分配到各软件子系统，确保软硬 件系统功能匹配适当。 p有效的变更控制也能降低需求变更带来的负面影响 。 p将需求编写成清晰、无二义性的文档将会极大地有利于系 统测试，确保产品质量 。 需求定义 IEEE 1997 pIEEE软件工程标准词汇表定义需求为： 1.用户解决问题或达到目标所需的条件
14、或能力。 2.系统或系统部件要满足合同、标准、规范或其它正 式规定文档所需具有的条件或能力。 3.一种反映上面(1)或(2)所描述的条件或能力的文档 说明。 需求定义Thayer, Dorfman. 1997 pMerlin Dorfman 和 Richard H. Thayer 提出了一个包容且更为精练的定义： n用户解决某一问题或达到某一目标所需的软件功能。 n系统或系统构件为了满足合同、规约、标准或其他正 式实行的文档而必须满足或具备的软件功能。 好的需求应具有的特性 p无歧义性 p完整性 p一致性 p可检验性 p确定性 p可跟踪性 p正确性 p可行性 p必要性 无歧义性 p产生歧义的原
15、因 同一个词具有多种含义 编写人员会下意识假设所有人对某个主 题都具有和自己一样的认知水准 缩写 叙述不够具体 无歧义性（续） p示例：系统只允许保留5个有效的相关记录 和保障计划，它必须包括最新的。 系统只允许5个有效的相关记录 最新的相关记录一定包含在上述相关记录中 每个保障计划都被放在其相关记录中 p结论：每个需求都应该只叙述一个主体，在 一个需求中包含多个主体时，会产生歧义。 无歧义性（续） p消除歧义的方法 对感到模糊的地方刨根问底 关键字技术 其他技术 完整性 p不能遗漏任何需求或必要的信息 p遗漏需求将很难查出来 p如果不能确定某项需求，务必用TBD（to be determin
16、ed，待确定）来标识 p项目开发前，必须解决需求中所有的TBD项 p每项需求必须完整描述即将交付使用的功能 完整性（续） p防止遗漏的方法 n注重用户的任务而不是系统的功能。 n将高层需求分解足够细，让用户真正的需求显示 出来：“应该、将要、可能” “将、必须”。 n务必让所有用户类都提出意见，确保每个用例都 至少有一个执行者。 n用多种方式表达需求：UML模型、数据流图、 判定表 （树）、E-R图等。 n跟踪系统需求、业务规则、用例，直至详细的软 件功能性需求，确保导出了所有必须的功能。 n检查边界值 完整性（续） p示例：如果可能的话，应该根据主要法人 账号列表在线确认所输入账号的合法性。 TBD，尽快确
