软件需求讲义

1、软件需求,从谚语开始,中国有句谚语：“好的开始就等于成功的一半” 西方的谚语是：“Garbage in, garbage out！”,内容概要,软件需求的基本概念 需求工程与需求工程过程 需求获取与需求分析 需求文档与需求质量验证 软件需求管理,软件需求参考书,作者：（美）karl e.wiegers 译者： 刘伟琴 刘洪涛 出版社：清华大学出版社,软件需求（第2版）,本书介绍了贯穿整个开发周期的管理需求工程的实用技术，包括多种可以促进用户、开发人员和管理层之间有效沟通的方法。这一版对第一版进行了扩充，提供了新的实例，及作者在实际工作中遇到的各种实际案例和解决方案。此外，还添加了新的章节、需求

2、示例文档以及故障诊断指南等。,第一部分 软件需求的基本概念,需求问题 需求的层次,第1章需求问题,需求是软件项目成败的关键所在 越早发现需求错误，越早改正它，其代价越小 需求的定义 好需求的特征：无歧义、完整、一致、可检验、确定、可跟踪的，正确的，可行的和必要的。,软件开发中的错误观点,只要掌握了1-2门程序设计语言，进行软件开发就没有问题。 只要有最好的开发工具、最好的计算机，一定能做出优秀的软件。 软件需求分析很困难，不管三七二十一，先把软件做了再说，反正软件是灵活的，随时可以修改。 总之，错误认为：软件就是程序，开发软件就是编写 程序。,项目失败与成功的原因*,三种最经常使项目“遇到困难

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

4、 原则*,80%的工程活动是由20%的需求消耗的 80%的软件成本是由20%的构件消耗的 *Royce，1998,需求错误的代价,在生命周期的不同阶段修复缺陷的相对成本,需求缺陷造成的成本增加,重新进行需求规格说明 重新设计 重新编码 重新测试 改变订单告诉用户将以一个修正后的版本来替代有缺陷的版本。 纠正活动消除由于不准确的特定系统的错误造成的危害，可能涉及到赔偿客户损失。 报废包括对于已经完成的代码、设计和测试，当发现它们是根据不正确的需求进行的时候，这些工作成果不得不被丢弃。 收回有缺陷的软件产品以及相关的用户手册。 产品赔偿或保修的成本。 重新安装新版本的成本。 重新建档的成本。,高质

5、量的需求过程带来的好处,在开发后期和整个维护阶段的重做的工作大大减少了 。 让用户积极参与需求收集过程能使产品更富有吸引力，而且能建立起更加忠实的客户关系 。 用户的参与能弥补用户期望和开发者实际开发之间的“鸿沟”（期望差异）。 将确定的系统需求明确地分配到各软件子系统，确保软硬件系统功能匹配适当。 有效的变更控制也能降低需求变更带来的负面影响 。 将需求编写成清晰、无二义性的文档将会极大地有利于系统测试，确保产品质量 。,需求定义 IEEE 1997,IEEE软件工程标准词汇表定义需求为： 用户解决问题或达到目标所需的条件或能力。 系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具

6、有的条件或能力。 一种反映上面(1)或(2)所描述的条件或能力的文档说明。,需求定义Thayer, Dorfman. 1997,Merlin Dorfman 和 Richard H. Thayer 提出了一个包容且更为精练的定义： 用户解决某一问题或达到某一目标所需的软件功能。 系统或系统构件为了满足合同、规约、标准或其他正式实行的文档而必须满足或具备的软件功能。,好的需求应具有的特性,无歧义性 完整性 一致性 可检验性 确定性 可跟踪性 正确性 可行性 必要性,无歧义性,产生歧义的原因 同一个词具有多种含义 编写人员会下意识假设所有人对某个主题都具有和自己一样的认知水准 缩写 叙述不够具体

7、,无歧义性（续）,示例：系统只允许保留5个有效地相关记录和保障计划，它必须包括最新的。,系统只允许5个有效的相关记录 最新的相关记录一定包含在上述相关记录中 每个保障计划都被放在其相关记录中,结论：每个需求都应该只叙述一个主体，在一个需求中包含多个主体时，会产生歧义。,无歧义性（续）,消除歧义的方法 对感到模糊的地方刨根问底 关键字技术 其他技术,完整性,不能遗漏任何需求或必要的信息 如果不能确定某项需求，务必用TBD（to be determined，待确定）来标识 项目开发前，必须解决需求中所有的TBD项 每项需求必须完整描述即将交付使用的功能 遗漏需求将很难查出来,完整性（续）,防止遗漏

8、的方法 注重用户的任务而不是系统的功能。 将高层需求分解足够细，让用户真正的需求显示出来：“应该、将要、可能” “将、必须”。 务必让所有用户类都提出意见，确保每个用例都至少有一个执行者。 用多种方式表达需求：UML模型、数据流图、判定表 （树）、E-R图等。 跟踪系统需求、业务规则、用例，直至详细的软件功能性需求，确保导出了所有必须的功能。 检查边界值,完整性（续）,示例：如果可能的话，应该根据主要法人账号列表在线确认所输入账号的合法性。,TBD，尽快确定其必要性 验证成功如何 验证失败又该如何,修订：当请求者输入账户号码时，系统将根据在线法人账号列表来验证所输入的账号。如果在此列表中查不到

9、该账号，则系统将显示一个出错信息并拒绝订货；否则进入订货流程。,一致性,任何一项需求不会与其他需求或更高层次的需求发生冲突 记下每项需求的来源，当发现需求冲突知道该找谁商量 项目开发前，必须解决需求不一致的问题,可检验性,需求可以通过合理的方式充分检测 开发人员能够确认软件是否满足用户需求 测试人员能够设计合理的测试方法，检验系统能否正常运行 示例1：用新的系统完成报表自动化处理。 示例2：员工标识号必须在一个有效的范围内。,确定性,使得所有人都知道在所有可能的条件下系统应该做什么 使用两种不同的需求处理有条件的行为 一条： 说明满足条件系统如何 另一条：说明不满足条件系统如何,确定性（续）,

10、示例：系统1应该每隔5分钟向系统2发送一次新记录。,每个5分钟的时间起点在哪里，不确定 当无新记录可发时，系统1该如何,修订：如果自上次向系统2发送消息以来，5分钟内收到了新记录，则系统1向系统2发送新记录；如果在上述5分钟内没有收到新记录，则系统1向系统2发送“无新记录”的提示消息。,可跟踪性,可跟踪的（软件）需求都能找到它的来源 可跟踪的（软件）需求都有它对应的设计单元、实现代码 可跟踪的（软件）需求都有它被正确实现的测试用例 可跟踪的（软件）需求都有一个固定、惟一的标识,可行性,需求必须在已知系统和环境的限制范围内能够实施 需要软件开发人员配合，检查技术可行性 忌讳使用“迅速、瞬间、及时

11、”等用词,练习题,产品应在不少于每60秒的正常周期内提供状态信息。,不少于每60秒，一年如何？ 状态信息有哪些内容，在哪里显示，如何显示？,修订：1. 产品将在用户界面的指定区域显示状态信息。 1.1 状态信息必须每隔6010秒更新一次。 1.2 状态信息 必须保持持续的可见性。 1.3 任务执行过程中，状态信息将显示任务的完成百分比。 1.4 任务完成时，状态信息将显示“已完成（Done）”。 1.5 任务中止时，状态信息将显示“Error”。,练习题(续）,HTML分析器可以产生HTML标记错误报告，帮助HTML入门者快速解决错误。,“快速”这个词有歧义，是人还是分析器？ 不可行 错误报告

12、有哪些内容，不确定、不可检验,修订：1. 在HTML分析器完全解析完一个文件后，该分析器将生成一个 出错报告，其内容包括解析文件过程中所发现的所有HTML错 误的行号及其文本内容，还包括对每个错误的描述。 2. 如果在解析过程中未发现任何错误，将不生成出错报告。,练习题(续）,产品应瞬间在文中的显示和隐藏不可打印字符间切换。,“瞬间”这个需求不可行？ 需求不完整：未声明切换的源头（自动还是外部触发） 需求不确定：“不可打印字符”是什么，文中发生变化的范围有多大,修订：用户在编辑文档时，通过特定的菜单项，可以在显示和隐藏文中所有控制字符之间进行切换。改变显示方式所需的时间为0.1秒或更短。,第二

13、章 需求的层次,需求是多层次的，包括业务需求、用户需求、功能需求和非功能需求。 需求路线图：涉众需要 系统的特性建立软件需求,软件需求包括不同的层次,业务需求,内容：表示组织或客户对系统、产品高层次的目 标 来源：投资人、购买产品的客户、市场营销部门、 产品策划部门、实际使用者的管理者 描述方式：前景（视图）和范围文档 示例：为乘坐航空公司航班的乘客购票提供便 利，增加航空公司的客流量，需要开发“网 上机票预订系统”。,用户需求,内容：描述了用户要求系统、产品必须能完成的 任务 来源：实际使用系统的所有潜在用户 描述方式：用例模型 示例：“机票预订”、“修改预订”、“取消预订”、“机 票查询”

14、,功能需求,内容：规定开发人员必须在系统、产品中实现的软件功能 来源：实际使用者、开发人员 描述方式：软件需求规格说明书（SRS） 示例：“编辑订单”、“提交订单”、“取消提交”、“计 算费用”、“选择付费方式”等等,术语：系统需求,内容：包含多个子系统的产品（即系统）的顶级需求。纯软件产品只包含软件子系统，否则包含既软件又包含硬件子系统 示例： 系统需求：系统能控制实验室设备给整排烧杯加入精确数量的化学药品（即把这项乏味的工作自动化） 软件的功能需求：向硬件发送“移动加药喷头”的信号；读取定位传感器；向硬件发送“开泵”的信号；向硬件发送“关泵”的信号；,软件的6个质量特征 ISO 9126,

15、软件的非功能性需求（质量属性）,可靠性 可用性 有效性 可维护性 可移植性,需求规格说明中的非功能需求,软件需求（二）,需求工程与需求工程过程,主要的软件生命周期模型 瀑布模型 快速应用开发(RAD) 模型 快速原型模型 螺旋模型 RUP 迭代式模型 形式化方法 关于选择生命周期模型的总结 需求工程 什么是需求工程 需求工程的内容 需求工程过程 需求工程的涉众人员 需求工程的方法 面向对象的需求工程方法 面向对象的需求工作流 需求过程的改进,第3章 主要软件生命周期模型,瀑布模型 快速应用开发模型（RAD） 快速原型模型 螺旋模型 RUP 迭代式模型,瀑布模型（Waterfall Model）

16、,瀑布模型的优点,客户很容易熟悉该模型。 是一种严格线性的按阶段顺序的、逐步细化的开发模式，消除了软件开发的随意性。 各阶段工作任务明确，要求文档完备性，可方便按阶段设置里程碑，便于项目跟踪 可以严格控制项目进程，使项目管理易于实施。 定义了质量控制过程。运用该过程来确定系统的质量。,瀑布模型的缺点,需求：客户常常难以表达真正的需求，而这种模型却要求严格的阶段性成果，返工困难，变更代价很大 风险：客户要等到开发周期的晚期才能看到程序运行的测试版本，这时若发现大的错误，可能引起客户的惊慌，其后果也可能是灾难性的 效率：因为前后任务的依赖关系，成员不能并行工作，有可能花在等待的时间比开发的时间要长

17、，即所谓的“堵塞状态”,适用于一些需求已明确并且变化较少的系统,快速应用开发(RAD) 模型,RAD模型的优点,采用高效率的开发工具，从而减少了整个产品的开发周期。提高了生产率，降低了成本。 用户能够持续地参与开发，提高了用户参与程度，从而使用户的满意度上升，保证了系统能够满足用户的需要。 工作重点从文档转为构建，所见即所得 。,RAD模型的缺点,如果用户不能持续地参与整个生命周期中，最终产品会受到负面影响。 要求系统能适当模块化，如果没有可重用的组件，它的效率就会下降。 盲目应用时，会缺乏成本概念和项目完成的时间限制。项目有永远不能完结的风险。 对于大型的、但可伸缩的项目，RAD 需要足够的

18、人力资源以创建足够的RAD 组。 RAD 要求承担必要的快速活动的开发者和用户在一个很短的时间框架下完成一个系统。如果两方中的任何一方没有完成约定，都会导致RAD 项目失败。,采用RAD模型的项目特征,系统可模块化（基于组件的结构）和可缩放。 用户能参与到整个生命周期中。 项目开发周期很短通常约60天。 项目团队熟悉问题领域，能熟练使用开发工具。,如果一个项目能够被模块化，使得其中每一个功能均可以在不到三个月的时间内完成，即为RAD候选项。,快速原型模型,原型快速建立起来的可以在计算机上运行的程序，通常选取系统中某个关键功能作为原型。,快速原型的基本思想和开发步骤,基本思想 在投入大量的人力、

19、物力之前，在限定的时间内，用最经济的方法构造一个系统原型，使用户尽早看到系统的概貌，在系统原型的实际运行中与用户一起发现问题，提出修改意见，不断完善原型，使它逐步满足用户要求。 开发步骤 明确用户基本信息需求 建立初始原型（集成原则、最小系统原则） 评价原型 修改和完善原型,快速原型的开发工具,第四代技术 可复用软件构件 形式化规约和原型环境,快速原型的类型,抛弃式原型。将开发原型看做是沟通工具，永远也不会将一次式原型引入正式运行环境中。主要解决需求的不确定性，二义性，不完整性等。 进化式原型。会在未来的系统中包含的原型。这种方法能够将最大量的工作投入到正式系统中。 水平原型也称为行为原型，用

20、来探索预期系统的一些特定行为，并达到细化需求的目的。水平原型通常只是功能导航，并未真实实现功能。主要用在用户界面上。 垂直原型也称为结构化原型，实现了一部分功能。主要用在复杂的算法实现上。,快速原型的典型应用,快速原型的评价,这个原型所实现的功能与你所期望的一致吗？ 有遗漏的功能吗？ 有多余的功能吗？ 你能考虑一下这个原型所没有涉及到的一些出错情况吗？ 这些功能导航的逻辑性和完整性如何？ 有更简单的方法来完成这一任务吗？,快速原型的特点和应用场合,用户积极参与 原型的开发没有严密的阶段性 短期获得测试版本，降低风险 应用于以下场合： 需求含糊，用户不能标识出详细的输入、处理和输出需求 设计方案

21、不明确，开发人员不能确定算法的有效性、操作系统的适应性或人机交互的有效性,快速原型的不足,降低风险的同时，引入了其他风险： 用户随意无止境的需求变化，因为用户容易产生误解，认为系统很容易被构造和修改 如果采用原型基础上继续构造，由于修补过度，软件质量不易于保证 开发人员为了快速构造原型，可能会采用不合适的操作系统、语言、算法等，造成后期风险，如系统适应性差、维护困难等,快速原型开发的原则,你的项目计划中应包括原型风险。 计划开发多个原型，因为你很少能一次成功。 尽快并且廉价地建立抛弃型原型。 在抛弃型原型中不应含有代码注释、输入数据有效性检查、保护性编码技术，或者错误处理的代码。 对于已经理解

22、的需求不要建立原型。 不能随意地增加功能。 不要从水平原型的性能推测最终产品的性能。 在原型屏幕显示和报表中使用合理的模拟数据。 不要期望原型可以代替需求文档。,螺旋模型,是增加了风险分析和规避措施的“原型 + 瀑布”的迭代式开发模型，由于一系列活动和活动间的回溯过程用螺旋线描述，故而得名。 螺旋模型是一种迭代模型，软件开发过程定义成不断上升的螺旋周期，每个周期划分为计划、风险分析、实施和评价四个方面。沿螺线自内向外每旋转一圈便开发出更为完善的一个新的软件版本,螺旋模型,螺旋模型的优点,能够及时找到项目存在的风险，避免因为克服不了的困难而造成大的损失。 使用户能够尽早将信息经常反馈给开发人员，

23、保证了产品的正确性和高质量。 可以方便地评估和验证每次迭代的成果；实现从开发到维护的无缝连接。,螺旋模型的缺点,如果项目本身是低风险的或者规模较小，采用该模型可能产生昂贵的成本。每一次螺旋结束后评估风险的时间及人工耗费都较大。 模型本身比较复杂，开发人员和用户难于掌握。 大量的中间阶段会产生额外的内外部文档。 难以定义每阶段的目标。,采用螺旋模型的项目特征,适用于大型项目；更适用于内部开发（指没有外包的开发内容）。 用于新功能、新产品或需要采用新技术时。 收益不确定，项目不能确保成功时。 用户不能确定其需求或需求很复杂时。,统一软件过程 （RUP）,统一软件过程（RUP，Rational Un

24、ified Process）是基于面向对象统一建模语言UML的一种面向对象的软件过程模型。 RUP遵循了逐步求精的、迭代的开发策略。RUP是以用例为驱动，以系统构架为中心的一个迭代式的增量过程。 RUP分成初始、细化、构造和移交四个阶段，每个阶段又分成若干次迭代，每次迭代都经过一个核心工作流程。,统一软件过程 （RUP）,RUP的核心概念,RUP的核心工作流（一）,6个核心过程工作流 商业建模（Business Modeling ） 需求（Requirements） 分析和设计（Analysis & Design） 实现(Implementation) 测试（Test） 部署（Deployme

25、nt）,RUP的核心工作流（二）,3个核心支持工作流 配置和变更管理（Configuration & Change Management） 项目管理（Project Management） 环境（Environment）,RUP的裁剪,确定本项目需要哪些工作流。RUP的9个核心工作流并不总是需要的，可以取舍。 确定每个工作流需要哪些制品。 确定4个阶段之间如何演进。确定阶段间演进要以风险控制为原则，决定每个阶段要那些工作流，每个工作流执行到什么程度，制品有那些，每个制品完成到什么程度。 确定每个阶段内的迭代计划。规划RUP的4个阶段中每次迭代开发的内容。 规划工作流内部结构。工作流涉及角色、活

26、动及制品，它的复杂程度与项目规模即角色多少有关。最后规划工作流的内部结构，通常用活动图的形式给出。,RUP的迭代开发模式,多次迭代,RUP的优点,降低了在一个增量上的开支风险。如果开发人员重复某个迭代，那么损失只是这一个开发有误的迭代的花费。 降低了产品无法按照既定进度进入市场的风险。通过在开发早期就确定风险，可以尽早来解决而不至于在开发后期匆匆忙忙。 加快了整个开发工作的进度。因为开发人员清楚问题的焦点所在，他们的工作会更有效率。 由于用户的需求并不能在一开始就作出完全的界定，它们通常是在后续阶段中不断细化的。因此，迭代过程这种模式使适应需求的变化会更容易些。,RUP的缺点,RUP只是一个开发过程，并没有涵盖软件过程的全部内容，例如它缺少关于软件运行和支持等方面的内容 它没有支持多项目的开发结构，这在一定程度上降低了在开发组织内大范围实现重用的可能性。,总结：迭代式模型,在