软件需求工程
2012-2
科学出版社
康雁 主编
242
401000
本书为读者理解软件需求工程提供了一个新的视角。全书共11章，包括需求概述、需求工程、需求获取、需求分析、基于UML的需求建模技术、需求模式、需求与面向对象软件开发、需求文档、需求验证、软件需求管理与安全需求工程。本书引入CDIO的概念，强调“做中学”，以培养学生的实际动手能力和实践能力；并着重讲述了需求工程中有关安全需求的内容；在介绍软件需求工程领域的经典理论、最新进展和发展方向的同时，也介绍了相关的实用技术和工具。这些原理、技术和工具能够应用在大型工业和商业软件的项目开发中，为软件工业的从业人员提供系统深入的指导。
本书可作为高等院校计算机专业学生、教师以及研究人员的教材和参考书，对于工业和计算机产业的从业人员也具有实用价值。
康雁
前言第1章 需求概述1.1 需求问题的提出1.2 不同项目的需求视图1.2.1 信息系统的需求视图1.2.2 嵌入式系统的需求视图1.2.3 软件产品的需求视图1.3 需求的定义1.3.1 几种主要的需求定义1.3.2 需求定义的一些基本原则1.3.3 优秀需求的特性1.4 需求定义的实践1.4.1 需求定义任务概述1.4.2 问题分析五步法1.4.3 需求定义的要素1.4.4 需求定义的范围1.5 需求的层次和分类1.5.1 软件需求的层次1.5.2 软件需求的分类1.6 需求在总体方案中的位置1.6.1 软件的生命周期1.6.2 需求与其他软件项目过程的关系习题第2章 需求工程2.1 需求工程的定义2.1.1 需求工程的提出2.1.2 需求工程的定义2.2 需求工程的内容2.2.1 需求获取2.2.2 需求分析2.2.3 编写规格说明书2.2.4 需求验证2.2.5 需求管理2.3 需求过程的改进2.3.1 需求工程面临的困难2.3.2 不适当的需求过程引起的风险2.3.3 需求过程的改进2.3.4 需求过程的推荐方法2.4 敏捷需求流程2.4.1 传统开发过程的需求问题2.4.2 敏捷需求流程2.4.3 极限需求流程2.4.4 增量需求流程2.5 需求工程与CDIO2.5.1 CDIO简介2.5.2 需求工程与CDIO习题第3章 需求获取3.1 问题域3.2 问题框架3.2.1 需求式行为问题框架3.2.2 命令式行为问题框架3.2.3 信息显示问题框架3.2.4 简单工件问题框架3.2.5 交换问题框架3.3 多框架问题3.4 确定需求开发计划3.5 需求获取方法3.5.1 面向目标的方法3.5.2 基于场景的方法3.5.3 面向方面的方法3.5.4 面向视点的方法3.5.5 基于知识的方法3.6 需求获取技术习题第4章 需求分析4.1 需求分析和业务建模4.2 建立系统关联图4.3 构建用户接口原型4.4 建立数据字典4.5 结构化分析建模方法4.5.1 数据建模4.5.2 功能建模4.5.3 行为建模4.5.4 结构化分析总结4.6 面向对象建模技术4.6.1 UML的提出4.6.2 UML对用例驱动需求工程的支持习题第5章 基于UML的需求建模技术5.1 项目概述5.1.1 项目背景5.1.2 UML的面向对象分析过程5.2 用例模型分析与设计5.2.1 划分用户群5.2.2 用例模型设计5.2.3 检查用例模型5.2.4 调整用例模型5.2.5 描述用例规约5.3 类图模型设计5.4 动态模型设计5.4.1 状态图模型设计5.4.2 顺序图模型设计5.4.3 活动图模型设计5.5 可视化建模工具5.5.1 Rose界面简介5.5.2 Rose的四种视图简介5.5.3 用Rose生成代码5.5.4 逆向工程习题第6章 需求模式6.1 需求模式构思6.1.1 包含要素6.1.2 基本细节6.1.3 额外需求6.1.4 需求模式分类6.1.5 使用需求模式的优点6.2 领域和设计模式6.2.1 领域6.2.2 设计模式6.3 需求模式间的关系6.3.1 需求模式分类6.3.2 修改需求模式6.3.3 需求模式用例及组6.4 使用和编写需求模式6.4.1 使用需求模式时应注意的问题6.4.2 裁剪需求模式6.4.3 寻找潜在的需求模式6.4.4 如何编写需求模式6.5 需求模式实例6.5.1 信息需求模式实例6.5.2 系统间接口需求模式实例习题第7章 需求与面向对象软件开发7.1 系统需求7.1.1 系统的诞生7.1.2 用例7.1.3 业务建模7.1.4 系统建模7.2 估算7.2.1 基于需求的软件规模估算7.2.2 基于需求的工作量估算7.3 分析7.3.1 抽取和面向对象7.3.2 类和关系7.3.3 序列和事件7.3.4 因果关系和控制7.4 设计7.4.1 设计模式7.4.2 用户和接口设计7.5 编程7.5.1 使用Java实现UML7.5.2 使用MDA工具生成代码7.6 测试7.6.1 测试的原因7.6.2 测试的方法7.6.3 使用JUnit进行测试用例的编写习题第8章 需求文档8.1 为什么需要文档8.1.1 文档在需求工程中的位置8.1.2 文档的作用8.2 文档编写的基本原则8.3 常见需求文档8.3.1 需求文档的分类8.3.2 项目视图和范围文档8.3.3 用户需求文档8.4 软件需求规格说明8.4.1 高质量软件需求规格说明的特性8.4.2 软件需求规格说明模版8.4.3 模版分析与应用8.5 文档写作技巧8.5.1 文档常见错误8.5.2 实用写作技巧习题第9章 需求验证9.1 需求验证9.1.1 需求验证的提出9.1.2 需求验证的目的和任务9.1.3 需求验证的内容9.1.4 需求验证的方法9.2 验证接口和程序9.3 需求评审9.3.1 需求评审的方法9.3.2 需求评审的过程9.3.3 需求评审的实践9.4 测试需求习题第10章 软件需求管理10.1 概述10.1.1 需求开发与需求管理10.1.2 ISO9001中对软件需求管理的要求10.1.3 CMM及CMMI中对软件需求管理的要求10.2 需求管理活动实践10.2.1 需求管理流程中的角色10.2.2 需求基线10.2.3 需求确认10.2.4 需求跟踪10.2.5 需求变更管理10.3 需求风险管理10.3.1 需求风险识别10.3.2 需求风险评估10.3.3 需求风险控制10.4 需求管理工具10.5 CDIO应用案例10.5.1 概述10.5.2 需求确认10.5.3 需求跟踪习题第11章 安全需求工程11.1 安全工程概述11.1.1 安全工程11.1.2 ISSE过程11.1.3 SSE-CMM过程11.2 安全需求的定义11.2.1 安全服务的分类11.2.2 安全需求的分类11.2.3 安全需求的开发过程11.3 安全需求获取11.4 安全风险评估11.4.1 风险评估方法11.4.2 形成风险分析报告11.5 确定安全需求11.5.1 安全需求报告概述11.5.2 安全需求报告撰写说明11.5.3 安全需求的描述方法11.6 CDIO应用案例11.6.1 概述11.6.2 网上书店系统模型及其功能11.6.3 网上书店系统安全需求分析习题参考文献
版权页：插图：第1章 需求概述1.1 需求问题的提出Ac公司由于业务扩展，现有员工数已增长到5000名。原有的工资系统已使用10年以上，最近员工的工资计算一直在出错，因此财务部门最近一直在加班，公司的总经理李云约见了信息技术主管王奇。“我们要建造一个新的工资支付系统，取代早已落伍的旧系统”，李云说道，“新的系统允许员工以无纸化的方式登记时间卡信息，并自动根据员工的工作时间和销售总额（对于有提成的员工）生成用于支付工资的支票。你们小组能在五个月内开发出该系统吗？”“我已经明白这个项目的重要性了”，王奇说，“但在我制订计划前，我们必须收集一些系统的需求。”李云觉得很奇怪，“你的意思是什么？我不是刚告诉你需求了吗？”“实际上，你只说明了整个项目的概念与目标”，王奇解释道，“这些高层次的业务需求并不能为我们提供足够的详细信息以确定究竟要开发什么样的软件，以及需要多长时间。我需要一些分析人员与薪酬金部门专家进行讨论，然后才能真正明白达到业务目标所需的各种功能和用户的要求。”李云此前还从未遇到过与这位系统开发人员类似的看法，他坚持道，“那些专家没有时间与你们详细讨论各种细节，你不能让你的手下的人说明要做的系统吗？”王奇尽力解释从使用新系统的用户处收集需求的合理性，“如果我们只是凭空猜想用户要求，结果不会令人满意。我们只是软件开发人员，而并非部门专家。我们并不能真正明白需要系统做什么。我曾经尝试过，未真正明白这些问题就匆忙开始编码，结果没有人对产品满意。”李云说明了一些业务需求，但他并不能描述用户需求，因为他并不是“工资支付系统”的实际使用者。只有实际用户才能描述此系统必须达成的目标，但他们又不能指出完成这些目标所需的所有具体的功能需求。像这样的对话经常出现在软件开发过程中。要求开发一个新信息系统的客户通常并不懂得从系统的实际用户处得到信息的重要性。通常意义下，客户是指直接或间接从产品中获得利益的个人或组织。软件客户包括提出要求、支付款项、选择、具体说明或使用软件产品的项目风险承担者或是获得产品所产生的结果的人。市场人员在有了一个很不错的新产品想法后，也就自认为能充分代表产品用户的兴趣要求。然而，直接从产品的实际用户处收集需求有着不可替代的必要性。完成的软件通常存在着以下问题：对软件的开发成本和进度的估计不准确、用户对已完成的系统不满意、软件的质量不可靠、软件的可维护程度较低、软件没有适当的文档资料、软件的成本不断提高、软件开发生产的效率较低。软件的发展经历了这么久，为什么依然存在这么多问题？为什么软件的完成总需要这么长的时间？为什么开发成本总居高不下？为什么不能在把软件交付给用户之前发现软件中所有的错误？软件的这些问题与软件本身的特点，以及软件开发和维护的方法不正确有关。但对用户要求没有完整正确的认识就匆忙着手编写程序是许多软件开发工程失败的主要原因之一。只有用户才真正了解他们自己的需要，但许多用户在开始时并不能准确具体地描述他们的需要，软件开发人员需要做大量深入细致的调查研究工作，反复多次地与用户交流信息，才能真正全面、准确、具体地了解用户的要求。对问题和目标的正确认识是解决任何问题的前提和出发点，软件开发同样也不例外。急于求成，仓促上阵，对用户要求没有正确认识就匆忙着手编写程序，这就如同不打好地基就盖高楼一样，最终必然倒塌。Standish［1］在1994年通过对8380个项目的调查发现，在美国，每年用于软件开发的费用在一千多亿美元以上。调查显示，31%的项目在完成之前被取消，52.7%的项目实际所花费的成本为预算成本的189%。其中，导致项目失败的8个最主要原因中有5个都与需求有关。这些可以量化的数据触目惊心，但还有很多机会成本是无法估量的。例如，美国丹佛市的机场由于没能开发出可信赖的处理行李的软件，而每天要耗费10万美金。2008年，Standish又做了一项调查，这一年的数据显示项目成功比率再次下降，按时、在预算内交付、并且完成了应有功能的成功项目只有32%。在过去40多年中，软件开发的状况可描述成一种社会性的苦恼。大规模的软件开发举步维艰，好像陷入困境苦苦挣扎的恐龙。虽然有一些成功的例子，但多数项目在经历一个漫长痛苦的过程后遭到惨败。并且，每一个成功的软件开发项目都有一些不被人注意的漏洞而存在隐忧。为了帮助软件开发组织找到明确的改进方向，Standish集团还针对成功项目总结出了十大成功保证，并针对彻底失败项目总结出了十大败因，如表1.1所示。从表1.1中可以看出，十大成功保证中有三个是直接与需求相关的（加粗表示），累计权重达到37.1%；而十大败因中与需求直接相关的更是高达五个（加粗表示），累计权重高达51.6%，从中可以看到需求问题对项目的影响程度。下面具体给出五个与需求有关的败因描述。（1）不完整的需求。主要是因为需求往往涉及决策者、事务管理层、操作层等不同层面的用户，需要让不同层次的人负责不同的部分，并最终汇总起来。（2）缺乏用户参与。主要是因为在很多的软件项目中，用户缺乏主动参与意识，不能有效地参与到项目中来。另一方面，用户对软件开发项目不感兴趣或是不能理解深奥的技术用语。（3）不切实际的用户期望。主要原因在于软件的无形和成本的不透明，用户很难理解有些需求是技术上无法实现的，或是在当前的费用与时间预算内无法实现的。（4）需求变更频繁。主要是因为用户没有意识到变更对软件项目的负面影响。另一方面，软件人员对变更没有进行有效的分类、统计，而是将所有需求变更当成一个问题来解决。（5）提供了不再需要的需求。最后开发出来的软件中常常存在着几乎没有被使用的功能，因此需要基于业务领域的知识来衡量需求的必要性和充分性。Walker［2］指出了一些作为现代软件管理过程框架理论基础的“基本公理”，即2-8原则：80%的软件成本是由20%的构件消耗的。由此可见需求在软件工程活动中所占的比重。Brooks［3］在1987年的经典文章NoSilverBullet：EssenceandAccidentsofSoft-wareEngineering中充分说明了需求过程在软件项目中所扮演的重要角色：开发软件系统最为困难的部分就是准确说明开发什么。需求的好坏直接关系到软件的成功与否。客户提出的需求是软件系统的源头，它定义了软件系统的意图和目的。如果需求遗漏或完成得不好，不管系统多么完美，系统也是失败的。为了得到有效的需求，需要采用有效的方法与用户广泛地交流。1.2 不同项目的需求视图随着信息化应用的逐渐深入，软件项目在企业、政府等各类组织中所担负的角色也越来越多，应用层面也逐渐丰富。同时，不同的软件项目具有不同的特点，这对需求也带来影响。在此，主要从信息系统、嵌入式系统、软件产品等不同角度说明如何进行相关的需求工作。1.2.1 信息系统的需求视图1.信息系统的本质与分类根据信息系统的定义，权威信息系统是人、数据、过程和接口的组合，它们之间相互作用，支持并改进企业的日常动作，并支持管理人员和用户解决问题和做出决策。这个定义，包含了以下几个要素。（1）支持企业日常动作：也就是对企业流程进行电子化，并且将其固化下来。（2）支持解决问题：信息系统具有解决企业动作中存在问题的使命，这也通常是发起信息系统开发项目的主要原因之一。（3）支持决策：通过有效地获取、加工、处理数据，为管理人员提供决策的支持。当今社会是数据的海洋，充满了生产数据、销售数据、客户数据、日程数据。信息系统的核心作用是：根据应用对数据进行有效处理，从而得出对人们更有价值的信息。在信息工程框架中，将信息系统分为联机事务处理系统、管理信息系统、主管信息系统、决策支持系统、专家系统、办公自动化系统等几种主要的类型。各类信息系统间的关系可分为以下几种。（1）联机事务处理系统是数据的生产者。联机事务处理系统负责对流程进行电子化，在这个过程中，将通过用户输入、系统采集等方式积累大量的数据。（2）管理信息系统是数据的消费者。管理信息系统是为中层管理人员（事务型管理人员）提供服务的，主要是通过查询、分析、统计的手段来完成监督、控制等活动，其核心的载体是报表。（3）主管信息系统、决策支持信息是数据的高级消费者。这两类系统是为高层管理人员（决策型管理人员）提供服务的，其形式与管理信息类似，但将会对数据做更深层次的挖掘。（4）专家系统是个人知识的沉淀，同时也是数据的消费者。（5）办公自动化系统是沟通与协作的直接支持。2.联机事务处理系统联机事务处理系统的核心价值在于实现流程的电子化，许多组织的信息系统建设是从此类系统开始。其相互依赖的核心三元素是人、流程和工具。其中工作流程是一个企业或组织的主线索，体现企业或组织的响应外部客户请求的存在价值，使得为客户创造价值的同时也为自己带来价值。同时流程也是联机事务处理系统需求视图的关键线索。需求人员根据信息系统的目标选择相关的流程，确定系统的目标，然后再将它实现出来。如果想将成熟的软件产品部署到企业/组织中，会涉及系统中内建的流程机制与企业/组织现有业务流程的融合，可能是修改企业的流程以适应软件，也可能是修改软件的内建流程以适应企业。企业对于流程施加的约束如果只是纸质的规定就容易不被遵守，完全由员工的自觉性来决定是否能够按流程规则进行。如果建立电子化的流程，流程则可固化。但是固化流程也会限制灵活性，对业务产生一定的约束，使得不合理的流程带来不良的后果。流程分析（业务事件）是联机事务处理系统的关键线索和主要视图。导致这一结果主要有两个原因：结构化分解过早考虑程序结构和流程分析相对零散。从前面第二节的分析已可看到，结构化分析采用自顶向下的纵向角度而非业务流程的角度，使得需求结构和软件设计脱离开来，割裂了业务流程，使用户无法很好地参与到需求验证中，也易丢失分析需求的线索。流程分析相对零散，流程图的详细程度和流程图间的关系很难限定，使得流程图不能成为有体系的线索。3.管理信息系统组织管理信息系统是从组织竞争战略高度出发，通过开发和有效利用各种信息与智力资源来提高组织竞争优势的信息系统。它是管理信息发展成熟化与现代化的重要标志，也是组织信息管理技术的主要集成，驾驭着组织信息系统的发展方向。组织管理信息系统从网络结构上讲，可以分为组织网络、信息网络、人际网络；从功能效用上讲包括竞争环境监视、市场变化预警、技术动向跟踪、竞争对手分析、竞争策略制定、信息安全保护、管理信息知识库等几个方面；从模块结构上讲，包括管理信息搜集、管理信息分析和管理信息服务三大模块，其中管理信息分析模块处于管理信息系统的核心位置。管理信息系统主要针对组织的现状，分析组织的类型与市场定位走向，详细收集组织内部的基础数据资料。系统针对企业/组织中的中层管理人员，核心是实现数据信息化。企业/组织中的中层管理人员是企业/组织中的执行层，通常管理的是企业/组织中的各种事务。管理活动的本质是计划、控制、组织、协调，在企业/组织的日常动作中产生了大量的数据。管理信息系统根据实际需要对其进行加工和整理，产生对管理活动有价值的信息，并通过针对业务事件、业务实体的一系列查询、统计操作提供对管理活动的支持。对查询、统计的需求分析是管理信息系统的关键线索和主要视图。管理信息系统分析、处理的数据是由联机事务处理系统提供的。在传统的需求实践中工作次序往往有所颠倒，首先分析功能性需求（联机事务处理系统的主体），再分析查询、统计类需求（管理信息系统的主体）。在需求的早期如果只是从查询、统计的格式开始，用户不易提出相关的细节描述，也不易分析得出目的，体现管理理念与需求。整理管理信息系统的关键线索时，可从Why（目的是什么）、What（怎样获得）、How（如何展现）三个层次进行，如表1.2所示。表1.2 管理信息系统需求的要点类别 要点 说明目的 从管理场景出发，借助对管理控制点来理解目的Why 使用部门/职位 了解需求的使用者，以便有针对性地调研相关场景 诸如用户数量、查询频率等非功能性场景描述What 关联实体 以类图或E-R图表示，说明数据的来源关键指标及计算规则 细化推导出关联的字段，以及派生属性的计算方法How 展现形式 以虚拟窗口等形式说明最终的呈现方式输入输出需要 说明是否打印，以什么格式提供等其他信息从管理信息系统响应的用户层次来看，可分为事务管理类和决策管理类。分别响应中层管理人员和高层管理人员的需求。高层管理人员则更侧重于不同维度，特别是从自然属性（如客户的职业、年龄、爱好等）维度进行分析，它是对数据的进一步抽象和整理。事务管理类主要是从业务事件的管理和业务实体情况的基本分解角度展开。它可大致分成四种类型。（1）进度类型：关注于业务事件相关的进度信息，是中层管理人员对业务进程进行管控的有效手段。它通常是按周期或日程（如日、周、月等）生成的以及对前一周期关键活动汇总的关键指标信息。（2）异常信息：业务事件中发生的异常通常是中层管理人员采取相应措施的时机，因此通常也是他们很关注的视角。它是当业务事件在执行过程中出现异常，需要提醒管理者注意时由系统自动生成，例如时间延期的工期报告。（3）常规信息：它是就某一情况为管理者提供详细的数据，通常提供的是针对一个业务实体的信息。（4）需求信息：它是用来按中层管理人员的要求提供相应信息的，通常涉及多个业务实体之间的信息，例如供销存信息等。而决策管理类管理信息系统则会在一个事实（可能是业务实体也可能是业务事件）的基础上，结合其关心的几个不同维度来建模。例如决策管理人员可对销售数据按以下维度进行分析：时间维（销售周期、特定的时间段等）、客户维（某个客户、某类客户等）、产品维（某个产品、某类产品等）、销售人员维（某个销售人员、某个销售小组等），甚至可能对多个维度进行综合分析。有时，这种维度可能是一种自然属性。当基本的数据库操作也不能很好地满足时，常需要对历史数据进行抽取、加工、转换，产生如数据仓库、数据集市的需求。4.其他信息系统（1）决策支持系统：系统针对的是企业的高层管理人员，它解决的是非结构化问题。结构化问题是通过计算机自动得出解决方案的问题，例如安全库存量的判断、现金流预警等。由于这类问题都已经有了历史积累的经验，因此只需将模型或算法实现出来，通过报表呈现给管理人员解决它。在企业/组织中并非所有问题都是可以通过计算机自动获取解决方案，此类问题称作非结构化问题，诸如广告投放、产品定价等都没有现成的模式可以依赖。对于此类问题，系统只能够为其提供一些相应的决策支持，最终的决定还是需要管理人员借助自己的智慧来处理。当然，非结构化问题也可能转换成结构化问题。决策支持系统需求最为关键的地方是决策场景，为管理人员的日常生活进行建模。决策场景是决策支持系统的关键线索和主要视图。可根据用户的关注点将不同的决策场景分组，以便更好地梳理系统的结构。（2）专家系统：对企业/组织而言，专家系统最关键的价值在于实现个人知识到企业知识的转换。对于那些需要经验积累的工作岗位，需要将相关知识转换为计算机可识别并提供的准则。工作场景是专家系统的关键线索和主要视图。系统中相对于具体场景而言不仅只需有数据视图，还要有经验模型、判断模型等。（3）办公自动化：它通常会涉及联机事务处理系统和管理信息系统，另外它有一个很重要的功能部分，就是对协同的支持。企业的流程从串行改为并行可提高工作效率，而并行流程会涉及并行部门、岗位之间的沟通和协作问题，这些协作场景也成为系统的需求线索。例如要设计实现公文流转、审批等功能，若先将这些场景归纳出来，再针对每个场景细化其中的行为需求，就能很好地完成此类系统的需求收集与整理工作。并行工作流是办公自动化系统的关键线索和主要视图，除此外，如日程表、行事历、备忘录等对个人事务的支持也可作为场景整理出来，然后再对其进行相应的行为分析，就能够使需求的整理更完整。1.2.2 嵌入式系统的需求视图除了以电脑为载体的信息系统外，还存在部署在受限设备上的嵌入式系统。嵌入式系统又称嵌入式计算机系统，是以应用为中心，以计算机技术为基础，能够满足应用对功能、性能、体积、成本、功耗等方面要求的专用系统。它的首要功能不是计算，而是受嵌入其中的计算机所控制的一个系统，具有嵌入性和专用性的特点。一个嵌入式系统由硬件和软件两部分组成从最终用户的角度可将嵌入式系统分为以下三类型：面向直接用户、面向特定设备和综合应用。
《软件需求工程》特色：介绍软件需求工程领域的经典理论、最新进展和发展方向，引入“CDIO”的概念，强调“做中学”，介绍相关实用技术和工具，结合典型实例阐述软件需求工程在软件开发中的重要作用，着重介绍软件工程中有关安全需求的部分，内容丰富，便于从事软件开发的专业人士和计算机专业的学生学习和参考。
介绍的还算比较全面，不过程度不够深入，可能只相当于导论性质的入门书，对于想了解了解需求工程的人看看还算可以的，专业的看了就会感觉有点浮于表面了。