《软件需求讲义》由会员分享，可在线阅读，更多相关《软件需求讲义（81页珍藏版）》请在金锄头文库上搜索。
1、软件需求从谚语开始p中国有句谚语：“好的开始就等于成功的一半”p西方的谚语是：“Garbage in, garbage out！ ” 内容概要p软件需求的基本概念p需求工程与需求工程过程p需求获取与需求分析p需求文档与需求质量验证p软件需求管理软件需求参考书作者：（美）karl e.wiegers 译者： 刘伟琴 刘洪涛 出版社：清华大学出版社软件需求（第软件需求（第2 2版）版）本书介绍了贯穿整个开发周期的管理需求工程的实用技术 ，包括多种可以促进用户、开发人员和管理层之间有效沟通的 方法。这一版对第一版进行了扩充，提供了新的实例，及作者 在实际工作中遇到的各种实际案例和解决方案。此外，还添
2、加 了新的章节、需求示例文档以及故障诊断指南等。 第一部分 软件需求的基本概 念p需求问题p需求的层次 第1章需求问题p需求是软件项目成败的关键所在p越早发现需求错误，越早改正它，其代价越小p需求的定义p好需求的特征：无歧义、完整、一致、可检验 、确定、可跟踪的，正确的，可行的和必要的 。 软件开发中的错误观点p只要掌握了1-2门程序设计语言，进行软件开发 就没有问题。p只要有最好的开发工具、最好的计算机，一定能 做出优秀的软件。p软件需求分析很困难，不管三七二十一，先把软 件做了再说，反正软件是灵活的，随时可以修改 。总之，错误认为：软件就是程序，开发软件就是编 写程序。项目失败与成功的原因
3、*p三种最经常使项目“遇到困难”的因素是：n缺乏用户介入：占所有项目的13%n不完整的需求和规格说明：占所有项目的12%n不断改变的需求和规格说明：占所有项目的12%p三种项目最主要的“成功因素”是：n用户介入：占所有成功项目的16%n高层管理的支持：占所有成功项目的14%n需求陈述清晰：占所有成功项目的12%*Standish Group ，1994软件开发的目标p软件开发的目标，简单而言，就是满足用户的 需要 。需求在项目中的作用 p未真正明白这些问题就开始编码，结果没有人 对产品满意 。p在项目开发中，所有的涉众（Stakeholder） 都对需求分析阶段备感兴趣。（没有理所当然 的需求
4、）p2-8 原则：举足轻重2-8 原则* p80%的工程活动是由20%的需求消耗的p80%的软件成本是由20%的构件消耗的 *Royce，1998 需求错误的代价 在生命周期的不同阶段修复缺陷的相对成本 需求缺陷造成的成本增加p重新进行需求规格说明p重新设计p重新编码p重新测试p改变订单告诉用户将以一个修正后的版本来替代有缺陷的版本 。p纠正活动消除由于不准确的特定系统的错误造成的危害，可能 涉及到赔偿客户损失。p报废包括对于已经完成的代码、设计和测试，当发现它们是根 据不正确的需求进行的时候，这些工作成果不得不被丢弃。p收回有缺陷的软件产品以及相关的用户手册。p产品赔偿或保修的成本。p重新安
5、装新版本的成本。p重新建档的成本。高质量的需求过程带来的好处 p在开发后期和整个维护阶段的重做的工作大大减少了 。p让用户积极参与需求收集过程能使产品更富有吸引力， 而且能建立起更加忠实的客户关系 。p用户的参与能弥补用户期望和开发者实际开发之间的“ 鸿沟”（期望差异）。 p将确定的系统需求明确地分配到各软件子系统，确保软 硬件系统功能匹配适当。 p有效的变更控制也能降低需求变更带来的负面影响 。p将需求编写成清晰、无二义性的文档将会极大地有利于 系统测试，确保产品质量 。需求定义 IEEE 1997pIEEE软件工程标准词汇表定义需求为：n用户解决问题或达到目标所需的条件或能力。n系统或系统
6、部件要满足合同、标准、规范或其它正式 规定文档所需具有的条件或能力。n一种反映上面(1)或(2)所描述的条件或能力的文档说 明。 需求定义Thayer, Dorfman. 1997pMerlin Dorfman 和 Richard H. Thayer 提出 了一个包容且更为精练的定义： n用户解决某一问题或达到某一目标所需的软件功能。n系统或系统构件为了满足合同、规约、标准或其他正 式实行的文档而必须满足或具备的软件功能。好的需求应具有的特性p无歧义性p完整性p一致性p可检验性p确定性p可跟踪性p正确性p可行性p必要性 无歧义性p产生歧义的原因同一个词具有多种含义编写人员会下意识假设所有人对某
7、个主 题都具有和自己一样的认知水准缩写叙述不够具体无歧义性（续）p示例：系统只允许保留5个有效地相关记 录和保障计划，它必须包括最新的。系统只允许5个有效的相关记录最新的相关记录一定包含在上述相关记录中每个保障计划都被放在其相关记录中p结论：每个需求都应该只叙述一个主体，在 一个需求中包含多个主体时，会产生歧义。无歧义性（续）p消除歧义的方法对感到模糊的地方刨根问底关键字技术其他技术完整性p不能遗漏任何需求或必要的信息p如果不能确定某项需求，务必用TBD（to be determined，待确定）来标识p项目开发前，必须解决需求中所有的TBD 项p每项需求必须完整描述即将交付使用的功 能p遗漏
8、需求将很难查出来完整性（续）p防止遗漏的方法n注重用户的任务而不是系统的功能。n将高层需求分解足够细，让用户真正的需求显 示出来：“应该、将要、可能” “将、必须”。n务必让所有用户类都提出意见，确保每个用例 都至少有一个执行者。n用多种方式表达需求：UML模型、数据流图、 判定表 （树）、E-R图等。n跟踪系统需求、业务规则、用例，直至详细的 软件功能性需求，确保导出了所有必须的功能 。n检查边界值完整性（续）p示例：如果可能的话，应该根据主要法人 账号列表在线确认所输入账号的合法性。TBD，尽快确定其必要性验证成功如何验证失败又该如何p修订：当请求者输入账户号码时，系统将根据在线 法人账号
9、列表来验证所输入的账号。如果在此列表中 查不到该账号，则系统将显示一个出错信息并拒绝订 货；否则进入订货流程。一致性p任何一项需求不会与其他需求或更高层次 的需求发生冲突p记下每项需求的来源，当发现需求冲突知 道该找谁商量p项目开发前，必须解决需求不一致的问题可检验性p需求可以通过合理的方式充分检测p开发人员能够确认软件是否满足用户需求p测试人员能够设计合理的测试方法，检验 系统能否正常运行p示例1：用新的系统完成报表自动化处理 。p示例2：员工标识号必须在一个有效的范 围内。确定性p使得所有人都知道在所有可能的条件下系 统应该做什么p使用两种不同的需求处理有条件的行为一条： 说明满足条件系统
10、如何另一条：说明不满足条件系统如何确定性（续）p示例：系统1应该每隔5分钟向系统2发送 一次新记录。每个5分钟的时间起点在哪里，不确定当无新记录可发时，系统1该如何p修订：如果自上次向系统2发送消息以来，5 分钟内收到了新记录，则系统1向系统2发送新 记录；如果在上述5分钟内没有收到新记录，则 系统1向系统2发送“无新记录”的提示消息。可跟踪性p可跟踪的（软件）需求都能找到它的来源p可跟踪的（软件）需求都有它对应的设计 单元、实现代码p可跟踪的（软件）需求都有它被正确实现 的测试用例p可跟踪的（软件）需求都有一个固定、惟 一的标识可行性p需求必须在已知系统和环境的限制范围内 能够实施p需要软件
11、开发人员配合，检查技术可行性p忌讳使用“迅速、瞬间、及时”等用词练习题p产品应在不少于每60秒的正常周期内提供状态信 息。 不少于每60秒，一年如何？状态信息有哪些内容，在哪里显示，如何显示？p修订：1. 产品将在用户界面的指定区域显示状态信息。1.1 状态信息必须每隔6010秒更新一次。1.2 状态信息 必须保持持续的可见性。1.3 任务执行过程中，状态信息将显示任务的完成百分比。1.4 任务完成时，状态信息将显示“已完成（Done）”。1.5 任务中止时，状态信息将显示“Error”。练习题(续）pHTML分析器可以产生HTML标记错误报告， 帮助HTML入门者快速解决错误。“快速”这个词
12、有歧义，是人还是分析器？ 不可行错误报告有哪些内容，不确定、不可检验p修订：1. 在HTML分析器完全解析完一个文件后，该分析器将生成一个出错报告，其内容包括解析文件过程中所发现的所有HTML错误的行号及其文本内容，还包括对每个错误的描述。2. 如果在解析过程中未发现任何错误，将不生成出错报告。练习题(续）p产品应瞬间在文中的显示和隐藏不可打印字符 间切换。“瞬间”这个需求不可行？需求不完整：未声明切换的源头（自动还是外部触发）需求不确定：“不可打印字符”是什么，文中发生变化的 范围有多大p修订：用户在编辑文档时，通过特定的菜单项，可以在显示 和隐藏文中所有控制字符之间进行切换。改变显示方式所
13、需的 时间为0.1秒或更短。第二章 需求的层次p需求是多层次的，包括业务需求、用户需求、 功能需求和非功能需求。p需求路线图：涉众需要 系统的特性建 立软件需求 软件需求包括不同的层次 业务需求p内容：表示组织或客户对系统、产品高层次的 目标p来源：投资人、购买产品的客户、市场营销部 门、产品策划部门、实际使用者的管理者p描述方式：前景（视图）和范围文档p示例：为乘坐航空公司航班的乘客购票提供便利，增加航空公司的客流量，需要开发“ 网上机票预订系统”。用户需求p内容：描述了用户要求系统、产品必须能完成 的任务p来源：实际使用系统的所有潜在用户p描述方式：用例模型p示例：“机票预订”、“修改预订
14、”、“取消预订”、 “机票查询”功能需求p内容：规定开发人员必须在系统、产品中实现 的软件功能p来源：实际使用者、开发人员p描述方式：软件需求规格说明书（SRS）p示例：“编辑订单”、“提交订单”、“取消提交”、 “计算费用”、“选择付费方式”等等术语：系统需求p内容：包含多个子系统的产品（即系统）的顶 级需求。纯软件产品只包含软件子系统，否则 包含既软件又包含硬件子系统p示例：n系统需求：系统能控制实验室设备给整排烧杯加入精 确数量的化学药品（即把这项乏味的工作自动化）n软件的功能需求：向硬件发送“移动加药喷头”的信号 ；读取定位传感器；向硬件发送“开泵”的信号；向硬 件发送“关泵”的信号；
15、软件的6个质量特征 ISO 9126 软件的非功能性需求（质量 属性）p可靠性p可用性p有效性p可维护性p可移植性 需求规格说明中的非功能需求软件需求（二）需求工程与需求工程过程p主要的软件生命周期模型n瀑布模型n快速应用开发(RAD) 模型n快速原型模型n螺旋模型nRUPn迭代式模型n形式化方法n关于选择生命周期模型的总结p需求工程 n什么是需求工程n需求工程的内容n需求工程过程n需求工程的涉众人员n需求工程的方法n面向对象的需求工程方法n面向对象的需求工作流n需求过程的改进第3章 主要软件生命周期模型 p瀑布模型p快速应用开发模型（RAD）p快速原型模型p螺旋模型pRUPp迭代式模型 瀑布
16、模型（Waterfall Model） 瀑布模型的优点 p客户很容易熟悉该模型。p是一种严格线性的按阶段顺序的、逐步细化的 开发模式，消除了软件开发的随意性。p各阶段工作任务明确，要求文档完备性，可方 便按阶段设置里程碑，便于项目跟踪p可以严格控制项目进程，使项目管理易于实施 。p定义了质量控制过程。运用该过程来确定系统 的质量。 瀑布模型的缺点p需求：客户常常难以表达真正的需求，而这种 模型却要求严格的阶段性成果，返工困难，变 更代价很大p风险：客户要等到开发周期的晚期才能看到程 序运行的测试版本，这时若发现大的错误，可 能引起客户的惊慌，其后果也可能是灾难性的p效率：因为前后任务的依赖关系，成员不能并 行工作，有可能花在等待的时间比开发的时间 要长，即所谓的“堵塞状态”适用于一些需求已明确并且变化较少的系统快速应用开发(RAD) 模型 RAD模型的优点 p采用高效率的开发工具，从而减少了整个产品 的开发周期。提高了生产率，降低了成本。p用户能够持续地参与开发，提高了用户参与程
