软件需求讲义

1、软件需求从谚语开始p中国有句谚语：“好的开始就等于成功的一半”p西方的谚语是：“garbage in, garbage out！” 内容概要p软件需求的基本概念p需求工程与需求工程过程p需求获取与需求分析p需求文档与需求质量验证p软件需求管理软件需求参考书作者：作者：（美）（美）karl e.wiegers 译者：译者： 刘伟琴刘伟琴 刘洪涛刘洪涛 出版社：清华大学出版社出版社：清华大学出版社本书介绍了贯穿整个开发周期的管理需求工程的实用技术，本书介绍了贯穿整个开发周期的管理需求工程的实用技术，包括多种可以促进用户、开发人员和管理层之间有效沟通的方包括多种可以促进用户、开发人员和管理层之间有效

2、沟通的方法。这一版对第一版进行了扩充，提供了新的实例，及作者在法。这一版对第一版进行了扩充，提供了新的实例，及作者在实际工作中遇到的各种实际案例和解决方案。此外，还添加了实际工作中遇到的各种实际案例和解决方案。此外，还添加了新的章节、需求示例文档以及故障诊断指南等。新的章节、需求示例文档以及故障诊断指南等。 第一部分 软件需求的基本概念p需求问题p需求的层次 第1章需求问题p需求是软件项目成败的关键所在p越早发现需求错误，越早改正它，其代价越小p需求的定义p好需求的特征：无歧义、完整、一致、可检验、确定、可跟踪的，正确的，可行的和必要的。 软件开发中的错误观点软件开发中的错误观点p只要掌握了只

3、要掌握了1-2门程序设计语言，进行软件开发就门程序设计语言，进行软件开发就没有问题。没有问题。p只要有最好的开发工具、最好的计算机，一定能做只要有最好的开发工具、最好的计算机，一定能做出优秀的软件。出优秀的软件。p软件需求分析很困难，不管三七二十一，先把软件软件需求分析很困难，不管三七二十一，先把软件做了再说，反正软件是灵活的，随时可以修改。做了再说，反正软件是灵活的，随时可以修改。总之，错误认为：软件就是程序，开发软件就是编写总之，错误认为：软件就是程序，开发软件就是编写程序。程序。 项目失败与成功的原因项目失败与成功的原因*p三种最经常使项目“遇到困难”的因素是：n缺乏用户介入：占所有项目

4、的13%n不完整的需求和规格说明：占所有项目的12%n不断改变的需求和规格说明：占所有项目的12%p三种项目最主要的“成功因素”是：n用户介入：占所有成功项目的16%n高层管理的支持：占所有成功项目的14%n需求陈述清晰：占所有成功项目的12%*standish group ，1994软件开发的目标软件开发的目标p软件开发的目标，简单而言，就是满足用户的需要 。需求在项目中的作用 p未真正明白这些问题就开始编码，结果没有人对产品满意 。p在项目开发中，所有的涉众（stakeholder）都对需求分析阶段备感兴趣。（没有理所当然理所当然的需求）p2-8 原则：举足轻重2-8 原则* p80%的工

5、程活动是由20%的需求消耗的p80%的软件成本是由20%的构件消耗的 *royce，1998 需求错误的代价 requirements timedesigncodingunit testacceptance testmaintenancestage.1-.2.512520在生命周期的不同阶段修复缺陷的相对成本 需求缺陷造成的成本增加p重新进行需求规格说明p重新设计p重新编码p重新测试p改变订单告诉用户将以一个修正后的版本来替代有缺陷的版本。p纠正活动消除由于不准确的特定系统的错误造成的危害，可能涉及到赔偿客户损失。p报废包括对于已经完成的代码、设计和测试，当发现它们是根据不正确的需求进行的时候

6、，这些工作成果不得不被丢弃。p收回有缺陷的软件产品以及相关的用户手册。p产品赔偿或保修的成本。p重新安装新版本的成本。p重新建档的成本。高质量的需求过程带来的好处 p在开发后期和整个维护阶段的重做的工作大大减少了 。p让用户积极参与需求收集过程能使产品更富有吸引力，而且能建立起更加忠实的客户关系 。p用户的参与能弥补用户期望和开发者实际开发之间的“鸿沟”（期望差异）。 p将确定的系统需求明确地分配到各软件子系统，确保软硬件系统功能匹配适当。 p有效的变更控制也能降低需求变更带来的负面影响 。p将需求编写成清晰、无二义性的文档将会极大地有利于系统测试，确保产品质量 。需求定义 ieee 1997

7、pieee软件工程标准词汇表定义需求为：1.用户解决问题或达到目标所需的条件或能力。2.系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力。3.一种反映上面(1)或(2)所描述的条件或能力的文档说明。 需求定义thayer, dorfman. 1997pmerlin dorfman 和 richard h. thayer 提出了一个包容且更为精练的定义： n用户解决某一问题或达到某一目标所需的软件功能。n系统或系统构件为了满足合同、规约、标准或其他正式实行的文档而必须满足或具备的软件功能。好的需求应具有的特性好的需求应具有的特性p无歧义性p完整性p一致性p可检验性p确定

8、性p可跟踪性p正确性p可行性p必要性 无歧义性p产生歧义的原因同一个词具有多种含义编写人员会下意识假设所有人对某个主题都具有和自己一样的认知水准缩写叙述不够具体无歧义性（续）p示例：系统只允许保留5个有效地相关记录和保障计划，它必须包括最新的。系统只允许系统只允许5个有效的相关记录个有效的相关记录最新的相关记录一定包含在上述相关记录中最新的相关记录一定包含在上述相关记录中每个保障计划都被放在其相关记录中每个保障计划都被放在其相关记录中p结论：每个需求都应该只叙述一个主体，在结论：每个需求都应该只叙述一个主体，在一个需求中包含多个主体时，会产生歧义。一个需求中包含多个主体时，会产生歧义。无歧义性

9、（续）p消除歧义的方法对感到模糊的地方刨根问底关键字技术其他技术完整性p不能遗漏任何需求或必要的信息p如果不能确定某项需求，务必用tbd（to be determined，待确定）来标识p项目开发前，必须解决需求中所有的tbd项p每项需求必须完整描述即将交付使用的功能p遗漏需求将很难查出来完整性（续）p防止遗漏的方法n注重用户的任务而不是系统的功能。n将高层需求分解足够细，让用户真正的需求显示出来：“应该、将要、可能” “将、必须”。n务必让所有用户类都提出意见，确保每个用例都至少有一个执行者。n用多种方式表达需求：uml模型、数据流图、判定表 （树）、e-r图等。n跟踪系统需求、业务规则、用

10、例，直至详细的软件功能性需求，确保导出了所有必须的功能。n检查边界值完整性（续）p示例：如果可能的话，应该根据主要法人账号列表在线确认所输入账号的合法性。tbd，尽快确定其必要性，尽快确定其必要性验证成功如何验证成功如何验证失败又该如何验证失败又该如何p修订：修订：当请求者输入账户号码时，系统将根据在线法人账号列表来验证所输入的账号。如果在此列表中查不到该账号，则系统将显示一个出错信息并拒绝订货；否则进入订货流程。一致性p任何一项需求不会与其他需求或更高层次的需求发生冲突p记下每项需求的来源，当发现需求冲突知道该找谁商量p项目开发前，必须解决需求不一致的问题可检验性p需求可以通过合理的方式充分

11、检测p开发人员能够确认软件是否满足用户需求p测试人员能够设计合理的测试方法，检验系统能否正常运行p示例1：用新的系统完成报表自动化处理。p示例2：员工标识号必须在一个有效的范围内。确定性p使得所有人都知道在所有可能可能的条件下系统应该做什么p使用两种不同的需求处理有条件的行为一条： 说明满足条件系统如何另一条：说明不满足条件系统如何确定性（续）p示例：系统1应该每隔5分钟向系统2发送一次新记录。每个每个5分钟的时间起点在哪里，不确定分钟的时间起点在哪里，不确定当无新记录可发时，系统当无新记录可发时，系统1该如何该如何p修订：修订：如果自上次向系统2发送消息以来，5分钟内收到了新记录，则系统1向

12、系统2发送新记录；如果在上述5分钟内没有收到新记录，则系统1向系统2发送“无新记录”的提示消息。可跟踪性p可跟踪的（软件）需求都能找到它的来源p可跟踪的（软件）需求都有它对应的设计单元、实现代码p可跟踪的（软件）需求都有它被正确实现的测试用例p可跟踪的（软件）需求都有一个固定、惟一的标识可行性p需求必须在已知系统和环境的限制范围内能够实施p需要软件开发人员配合，检查技术可行性p忌讳使用“迅速、瞬间、及时”等用词练习题p产品应在不少于每产品应在不少于每60秒的正常周期内提供状态信息。秒的正常周期内提供状态信息。不少于每不少于每60秒，一年如何？秒，一年如何？状态信息有哪些内容，在哪里显示，如何显

13、示？状态信息有哪些内容，在哪里显示，如何显示？p修订：修订：1. 产品将在用户界面的指定区域显示状态信息。产品将在用户界面的指定区域显示状态信息。 1.1 状态信息必须每隔状态信息必须每隔6010秒更新一次。秒更新一次。 1.2 状态信息状态信息 必须保持持续的可见性。必须保持持续的可见性。 1.3 任务执行过程中，状态信息将显示任务的完成百分比。任务执行过程中，状态信息将显示任务的完成百分比。 1.4 任务完成时，状态信息将显示任务完成时，状态信息将显示“已完成（已完成（done）”。 1.5 任务中止时，状态信息将显示任务中止时，状态信息将显示“error”。练习题(续）phtml分析器可

14、以产生分析器可以产生html标记错误报告，帮标记错误报告，帮助助html入门者快速解决错误。入门者快速解决错误。“快速快速”这个词有歧义，是人还是分析器？这个词有歧义，是人还是分析器？ 不可行不可行错误报告有哪些内容，不确定、不可检验错误报告有哪些内容，不确定、不可检验p修订：修订：1. 在在html分析器完全解析完一个文件后，该分析器将生成一个分析器完全解析完一个文件后，该分析器将生成一个 出错报告，其内容包括解析文件过程中所发现的所有出错报告，其内容包括解析文件过程中所发现的所有html错错 误的行号及其文本内容，还包括对每个错误的描述。误的行号及其文本内容，还包括对每个错误的描述。 2.

15、 如果在解析过程中未发现任何错误，将不生成出错报告如果在解析过程中未发现任何错误，将不生成出错报告。练习题(续）p产品应瞬间在文中的显示和隐藏不可打印字符间产品应瞬间在文中的显示和隐藏不可打印字符间切换。切换。“瞬间瞬间”这个需求不可行？这个需求不可行？需求不完整：未声明切换的源头（自动还是外部触发）需求不完整：未声明切换的源头（自动还是外部触发）需求不确定：需求不确定：“不可打印字符不可打印字符”是什么，文中发生变化是什么，文中发生变化的范围有多大的范围有多大p修订：修订：用户在编辑文档时，通过特定的菜单项，可以在显示用户在编辑文档时，通过特定的菜单项，可以在显示和隐藏文中所有控制字符之间进

16、行切换。改变显示方式所需和隐藏文中所有控制字符之间进行切换。改变显示方式所需的时间为的时间为0.1秒或更短。秒或更短。第二章 需求的层次p需求是多层次的，包括业务需求、用户需求、功能需求和非功能需求。p需求路线图：涉众需要 系统的特性建立软件需求 软件需求包括不同的层次 业务需求p内容：表示组织或客户对系统、产品高层次的目 标p来源：投资人、购买产品的客户、市场营销部门、 产品策划部门、实际使用者的管理者p描述方式：前景（视图）和范围文档p示例：为乘坐航空公司航班的乘客购票提供便 利，增加航空公司的客流量，需要开发“网网 上机票预订系统上机票预订系统”。用户需求p内容：描述了用户要求系统、产品

17、必须能完成的 任务p来源：实际使用系统的所有潜在用户p描述方式：用例模型p示例：“机票预订”、“修改预订”、“取消预订”、“机 票查询”功能需求p内容：规定开发人员必须在系统、产品中实现的软件功能p来源：实际使用者、开发人员p描述方式：软件需求规格说明书（srs）p示例：“编辑订单”、“提交订单”、“取消提交”、“计 算费用”、“选择付费方式”等等术语：系统需求p内容：包含多个子系统的产品（即系统）的顶级需求。纯软件产品只包含软件子系统，否则包含既软件又包含硬件子系统p示例：n系统需求：系统能控制实验室设备给整排烧杯加入精确数量的化学药品（即把这项乏味的工作自动化）n软件的功能需求：向硬件发送

18、“移动加药喷头”的信号；读取定位传感器；向硬件发送“开泵”的信号；向硬件发送“关泵”的信号；软件的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面向对象

19、的需求工作流n需求过程的改进第3章 主要软件生命周期模型 p瀑布模型p快速应用开发模型（rad）p快速原型模型p螺旋模型prupp迭代式模型 瀑布模型（waterfall model） 瀑布模型的优点 p客户很容易熟悉该模型。p是一种严格线性的按阶段顺序的、逐步细化的开发模式，消除了软件开发的随意性。p各阶段工作任务明确，要求文档完备性，可方便按阶段设置里程碑，便于项目跟踪p可以严格控制项目进程，使项目管理易于实施。p定义了质量控制过程。运用该过程来确定系统的质量。 瀑布模型的缺点p需求：客户常常难以表达真正的需求，而这种模型却要求严格的阶段性成果，返工困难，变更代价很大p风险：客户要等到开发

20、周期的晚期才能看到程序运行的测试版本，这时若发现大的错误，可能引起客户的惊慌，其后果也可能是灾难性的p效率：因为前后任务的依赖关系，成员不能并行工作，有可能花在等待的时间比开发的时间要长，即所谓的“堵塞状态”适用于一些需求已明确并且变化较少的系统适用于一些需求已明确并且变化较少的系统快速应用开发(rad) 模型 rad模型的优点模型的优点 p采用高效率的开发工具，从而减少了整个产品的开发周期。提高了生产率，降低了成本。p用户能够持续地参与开发，提高了用户参与程度，从而使用户的满意度上升，保证了系统能够满足用户的需要。p工作重点从文档转为构建，所见即所得 。rad模型的缺点模型的缺点 p如果用户

21、不能持续地参与整个生命周期中，最终产品会受到负面影响。p要求系统能适当模块化，如果没有可重用的组件，它的效率就会下降。p盲目应用时，会缺乏成本概念和项目完成的时间限制。项目有永远不能完结的风险。p对于大型的、但可伸缩的项目，rad 需要足够的人力资源以创建足够的rad 组。prad 要求承担必要的快速活动的开发者和用户在一个很短的时间框架下完成一个系统。如果两方中的任何一方没有完成约定，都会导致rad 项目失败。 采用rad模型的项目特征 p系统可模块化（基于组件的结构）和可缩放。p用户能参与到整个生命周期中。p项目开发周期很短通常约60天。p项目团队熟悉问题领域，能熟练使用开发工具。 如果一

22、个项目能够被模块化，使得其中每一如果一个项目能够被模块化，使得其中每一个功能均可以在不到三个月的时间内完成，个功能均可以在不到三个月的时间内完成，即为即为rad候选项。候选项。快速原型模型p原型快速建立起来的可以在计算机上运行的程序，通常选取系统中某个关键功能作为原型。编程测试编程测试分析分析定义需求定义需求设计设计原型原型实施完成实施完成再构造再构造快速原型的基本思想和开发步骤p基本思想基本思想 在投入大量的人力、物力之前，在限定的时间内，用最经济的方法构造一个系统原型，使用户尽早看到系统的概貌，在系统原型的实际运行中与用户一起发现问题，提出修改意见，不断完善原型，使它逐步满足用户要求。p开

23、发步骤开发步骤明确用户基本信息需求建立初始原型（集成原则、最小系统原则）评价原型修改和完善原型快速原型的开发工具p第四代技术p可复用软件构件p形式化规约和原型环境快速原型的类型p抛弃式原型。将开发原型看做是沟通工具，永远也不会将一次式原型引入正式运行环境中。主要解决需求的不确定性，二义性，不完整性等。p进化式原型。会在未来的系统中包含的原型。这种方法能够将最大量的工作投入到正式系统中。p水平原型也称为行为原型，用来探索预期系统的一些特定行为，并达到细化需求的目的。水平原型通常只是功能导航，并未真实实现功能。主要用在用户界面上。p垂直原型也称为结构化原型，实现了一部分功能。主要用在复杂的算法实现

24、上。快速原型的典型应用快速原型的评价p这个原型所实现的功能与你所期望的一致吗？p有遗漏的功能吗？p有多余的功能吗？p你能考虑一下这个原型所没有涉及到的一些出错情况吗？p这些功能导航的逻辑性和完整性如何？p有更简单的方法来完成这一任务吗？快速原型的特点和应用场合p用户积极参与p原型的开发没有严密的阶段性p短期获得测试版本，降低风险应用于以下场合：需求含糊，用户不能标识出详细的输入、处理和输出需求设计方案不明确，开发人员不能确定算法的有效性、操作系统的适应性或人机交互的有效性快速原型的不足p降低风险的同时，引入了其他风险：用户随意无止境的需求变化，因为用户容易产生误解，认为系统很容易被构造和修改如

25、果采用原型基础上继续构造，由于修补过度，软件质量不易于保证开发人员为了快速构造原型，可能会采用不合适的操作系统、语言、算法等，造成后期风险，如系统适应性差、维护困难等快速原型开发的原则p你的项目计划中应包括原型风险。p计划开发多个原型，因为你很少能一次成功。p尽快并且廉价地建立抛弃型原型。p在抛弃型原型中不应含有代码注释、输入数据有效性检查、保护性编码技术，或者错误处理的代码。p对于已经理解的需求不要建立原型。p不能随意地增加功能。p不要从水平原型的性能推测最终产品的性能。p在原型屏幕显示和报表中使用合理的模拟数据。p不要期望原型可以代替需求文档。螺旋模型螺旋模型p是增加了风险分析和规避措施的

26、“原型 + 瀑布”的迭代式开发模型，由于一系列活动和活动间的回溯过程用螺旋线描述，故而得名。p螺旋模型是一种迭代模型，软件开发过程定义成不断上升的螺旋周期，每个周期划分为计划、风险分析、实施和评价四个方面。沿螺线自内向外每旋转一圈便开发出更为完善的一个新的软件版本螺旋模型螺旋模型螺旋模型的优点 p能够及时找到项目存在的风险，避免因为克服不了的困难而造成大的损失。p使用户能够尽早将信息经常反馈给开发人员，保证了产品的正确性和高质量。p可以方便地评估和验证每次迭代的成果；实现从开发到维护的无缝连接。 螺旋模型的缺点 p如果项目本身是低风险的或者规模较小，采用该模型可能产生昂贵的成本。每一次螺旋结束

27、后评估风险的时间及人工耗费都较大。p模型本身比较复杂，开发人员和用户难于掌握。p大量的中间阶段会产生额外的内外部文档。p难以定义每阶段的目标。 采用螺旋模型的项目特征 p适用于大型项目；更适用于内部开发（指没有外包的开发内容）。p用于新功能、新产品或需要采用新技术时。p收益不确定，项目不能确保成功时。p用户不能确定其需求或需求很复杂时。 统一软件过程 （rup）p统一软件过程统一软件过程（rup，rational unified process）是基于面向对象统一建模语言是基于面向对象统一建模语言uml的一种面向对的一种面向对象的软件过程模型。象的软件过程模型。prup遵循了逐步求精的、迭代的

28、开发策略。遵循了逐步求精的、迭代的开发策略。rup是以是以用例用例为驱动，以为驱动，以系统系统构构架架为中心为中心的一个的一个迭代迭代式式的的增量增量过程。过程。prup分成分成初始、细化、构造初始、细化、构造和和移交移交四个阶段，每四个阶段，每个阶段又分成若干次迭代，每次迭代都经过一个个阶段又分成若干次迭代，每次迭代都经过一个核心工作流程。核心工作流程。 统一软件过程 （rup）rup的核心概念 rup的核心工作流（一）的核心工作流（一） p6个核心过程工作流 n商业建模（business modeling ） n需求（requirements）n分析和设计（analysis & d

29、esign） n实现(implementation) n测试（test） n部署（deployment） rup的核心工作流（二）的核心工作流（二）p3个核心支持工作流 n配置和变更管理（configuration & change management） n项目管理（project management） n环境（environment） rup的裁剪 p确定本项目需要哪些工作流。rup的9个核心工作流并不总是需要的，可以取舍。p确定每个工作流需要哪些制品。p确定4个阶段之间如何演进。确定阶段间演进要以风险控制为原则，决定每个阶段要那些工作流，每个工作流执行到什么程度，制品有那些，每

30、个制品完成到什么程度。p确定每个阶段内的迭代计划。规划rup的4个阶段中每次迭代开发的内容。p规划工作流内部结构。工作流涉及角色、活动及制品，它的复杂程度与项目规模即角色多少有关。最后规划工作流的内部结构，通常用活动图的形式给出。 rup的迭代开发模式 多次迭代 rup的优点 p降低了在一个增量上的开支风险。如果开发人员重复某个迭代，那么损失只是这一个开发有误的迭代的花费。p降低了产品无法按照既定进度进入市场的风险。通过在开发早期就确定风险，可以尽早来解决而不至于在开发后期匆匆忙忙。 p加快了整个开发工作的进度。因为开发人员清楚问题的焦点所在，他们的工作会更有效率。p由于用户的需求并不能在一开始就作出完全的界定，它们通常是在后续阶段中不断细化的。因此，迭代过程这种模式使适应需求的变化会