[toc]

系统分析师笔记11_软件需求工程

该笔记内容来自《系统分析师教程》第2版。

软件需求工程是包括创建和维护软件需求文档所必需的一切活动的过程，可分为需求开发和需求管理两大工作。

软件需求概述

需求的层次

简单地说，软件需求就是系统必须完成的事以及必须具备的品质。需求是多层次的，包括业务需求、用户需求和系统需求，这三个不同层次从目标到具体，从整体到局部，从概念到细节。

质量功能部署

质量功能部署(Quality Function Deployment，QFD)是一种将用户要求转化成软件需求的技术，其目的是最大限度地提升软件工程过程中用户的满意度。

为了达到这个目标，QFD将软件需求分为三类:常规需求、期望需求和意外需求。

• (1)常规需求。用户认为系统应该做到的功能或性能，实现越多用户会越满意。
• (2)期望需求。用户想当然认为系统应具备的功能或性能，但并不能正确描述自己想要得到的这些功能或性能需求。如果期望需求没有得到实现，会让用户感到不满意。
• (3)意外需求。意外需求也称为兴奋需求，是用户要求范围外的功能或性能，实现这些需求用户会更高兴，但不实现也不影响其购买的决策。意外需求是控制在开发人员手中的，开发人员可以选择实现更多的意外需求，以便得到高满意、高忠诚度的用户，也可以(出于成本或项目周期的考虑)选择不实现任何意外需求。

软件需求

软件需求目前并没有统一的定义，但都包含以下几方面的内容:

• (1)用户解决问题或达到目标所需条件或权能。
• (2)系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或权能。
• (3)一种反映上面(1)或(2)所述条件或权能的文档说明，即需求规格说明。它包括功能性需求及非功能性需求，非功能性需求对设计和实现提出了限制，比如性能要求、质量标准或者设计限制

需求工程

需求工程覆盖了体系结构设计之前的各项开发活动，主要包括分析客户要求、对未来系统的各项功能性及非功能性需求进行规格说明。

需求工程的活动主要被划分为以下几个阶段:

• (1)需求获取。通过与用户的交流，对现有系统的观察及对任务进行分析，从而开发、捕获和修订用户的需求。
• (2)需求分析。为系统建立一个概念模型，作为对需求的抽象描述，并尽可能多地捕获现实世界的语义。
• (3)形成需求规格(或称为需求文档化)。按照相关标准，生成需求模型的文档描述，用户的原始需求说明书作为用户和开发者之间的一个协约，往往被作为合同的附件;软件需求描述规约作为后续软件系统开发的指南。
• (4)需求确认与验证。以需求规格说明为输入，通过用户确认、复审会议、符号执行、模拟仿真或快速原型等途径与方法，确认和验证需求规格的完整性、正确性、一致性、可测试性和可行性，包含有效性检查、一致性检查、可行性检查和确认可验证性。
• (5)需求管理。需求管理包括需求文档的追踪管理、变更控制、版本控制等管理性活动。软件需求开发的最终文档经过评审批准后，就定义了开发工作的需求基线(Baseline)。这个基线在客户和开发者之间构筑了计划产品功能需求和非功能需求的一个约定(Agreement)。需求约定是需求开发和需求管理之间的桥梁。

需求获取

需求获取是一个确定和理解不同的项目干系人的需求和约束的过程。

用户访谈

用户访谈是最基本的一种需求获取手段，其形式包括结构化和非结构化两种。结构化是指事先准备好一系列问题，有针对地进行；非结构化则是只列出一个粗略的想法，根据访谈的具体情况发挥。

最有效的访谈是结合这两种方法进行，毕竟不可能把什么都一一计划清楚，应该保持良好的灵活性。

问卷调查

问卷调查表使系统分析师可以从大量的项目干系人处收集信息，甚至当项目干系人在地理上分布很广时，他们仍然能通过问卷调查表来帮助获取需求。

一张好的问卷调查表要花费大量的时间来进行设计与制作，包括确定问题及其类型、编写问题、设计问卷调查表的格式三个重要活动。

采样

采样是指从种群中系统地选出有代表性的样本集的过程，通过认真研究所选出的样本集，可以从整体上揭示种群的有用信息。

对于信息系统的开发而言，现有系统的文档(文件)就是采样种群。当开始对一个系统做需求分析时，查看现有系统的文档是对系统有初步了解的最好方法。

情节串联板

系统分析师就需要通过情节串联板技术来帮助用户消除盲区，达成共识。

情节串联板的概念

情节串联板通常就是一系列图片，系统分析师通过这些图片来讲故事。在一般情况下，图片的顺序与活动事件的顺序一致，通过一系列图片说明会发生什么。人们发现，通过以图片辅助讲故事的方式叙述需求，有助于有效和准确地沟通。

在情节串联板中可以使用的图片类型包括流程图、交互图、报表和记录结构等。

简单地说，情节串联板技术就是使用工具向用户说明(或演示)系统如何适合企业的需要，并表明系统将如何运转。系统分析师将初始的情节串联板展示给讨论小组，小组成员提供意见。

联合需求计划

为了提高需求获取的效率，越来越多的企业倾向于使用小组工作会议来代替大量独立的访谈。

联合需求计划是一个通过高度组织的群体会议来分析企业内的问题并获取需求的过程，它是联合应用开发的部分。

需求记录技术

在需求获取的过程中，将会产生大量的信息，系统分析师要将这些信息有条理地记录下来，就需要借助一些工具。在信息系统开发实践中，有时候进行需求获取的人员和进行需求分析的人员不是同一个人(团队)，有时候在同一个项目中有多个系统分析师参加需求获取。

因此，需要统一需求记录工具，以便让所有人的获取结果是同一口径的。常用的需求记录工具有任务卡片、场景说明、用户故事和Volere白卡等。

需求分析

需求分析的任务

需求分析的目标是把用户对待开发软件提出的“要求”或“需要”进行分析与整理，确认后形成描述完整、清晰与规范的文档，确定软件需要实现哪些功能，完成哪些工作。

需求分析的方法

在软件工程实践过程中，人们提出了许多种需求分析的方法，其中主要有结构化分析(SA)方法、面向对象的分析 (OOA)方法和面向问题域的分析(PDOA)方法。

结构化分析方法(SA)

SA方法的基本思想是自顶向下，逐层分解，把一个大问题分解成若干个小问题，每个小问题再分解成若干个更小的问题。经过逐层分解，每个最低层的问题都是足够简单、容易解决的。

数据流图（DFD）

DFD是SA方法中的重要工具，是表达系统内数据的流动并通过数据流描述系统功能的一种方法。

DFD还可被认为是一个系统模型，在信息系统开发中，如果采用结构化方法，则一般将DFD作为需求规格说明书的一个组成部分。

状态转换图

数据字典

数据字典是在DFD的基础上，对DFD中出现的所有命名元素都加以定义，使得每个图形元素的名字都有一个确切的解释。

DFD和数据字典等工具相配合，就可以从图形和文字两个方面对系统的逻辑模型进行完整的描述。

面向对象分析方法 (OOA)

用例模型

从用户的角度来看，他们并不想了解系统的内部结构和设计，他们所关心的是系统所能提供的服务，这就是用例方法的基本思想。

用例方法是一种需求合成技术，从获取到的要求和期望中进行整理与提炼，从而建立用例模型。

在00A方法中，构建用例模型一般需要经历4个阶段，分别是识别参与者、合并需求获得用例、细化用例描述和调整用例模型，其中前三个阶段是必需的。

分析模型

分析模型描述系统的基本逻辑结构，展示对象和类如何组成系统(静态模型)，以及它们如何保持通信，实现系统行为(动态模型)。

建立分析模型的过程大致包括定义概念类、确定类之间的关系、为类添加职责、建立交互图等。

需求定义

系统分析师在获取了用户的需求，并进行了详细分析之后，接下来的工作就需要把这些软件需求形成文档，作为系统后续开发的基础，这就是需求定义。

需求定义的方法

需求定义的过程也就是形成需求规格说明书的过程，通常有两种需求定义的方法，分别是严格定义方法和原型方法。

软件需求规格说明书(SRS)

软件需求规格说明书(Software Requirement Specification，SRS)是需求开发活动的产物，编制该文档的目的是使项目干系人与开发团队对系统的初始规定有一个共同的理解，使之成为整个开发工作的基础。

SRS是软件开发过程中最重要的文档之一，对于任何规模和性质的软件项目都不应该缺少。

需求验证

需求评审

需求评审就是需求开发阶段结束前进行的技术评审，此时的产品就是SRS。SRS的评审是一项精益求精的技术，它可以发现那些二义性的或不确定性的需求，为项目干系人提供在需求问题上达成共识的方法。

需求测试

事实上，软件测试应该从需求定义开始，如果在开发过程的早期就开始制订测试计划和进行测试用例的设计，就可以在发生错误时立即检测到并纠正它。这样，就可以防止这些错误进一步“放大”，并且可以减少测试和维护费用。

需求管理

需求管理包括需求文档的追踪管理、变更控制、版本控制等管理性活动。

需求变更

在当前的软件开发过程中，需求变更已经成为一种常态。

需求变更的原因有很多种，可能是需求获取不完整，存在遗漏的需求;可能是对需求的理解产生了误差;也可能是业务变化导致了需求的变化等。

一些需求的改进是合理的而且不可避免，要使软件需求完全不变更，基本上是不可能的。但毫无控制的变更会导致项目陷入混乱，不能按进度完成或者软件质量无法保证。

常见的需求变更策略:

• (1)所有需求变更必须遵循变更控制过程。
• (2)对于未获得批准的变更，不应该做设计和实现工作。
• (3)变更应该由项目变更控制委员会决定实现哪些变更。
• (4)项目风险承担者应该能够了解变更的内容。
• (5)绝不能从项目配置库中删除或者修改变更请求的原始文档。
• (6)每一个集成的需求变更必须能跟踪到一个经核准的变更请求，以保持水平可追踪性。

需求追踪

需求跟踪提供了由需求到产品实现整个过程范围的明确查阅能力。

需求跟踪的目的是建立与维护“需求-设计-编程-测试”之间的一致性，确保所有的工作成果符合用户需求。需求跟踪有两种方式:

• (1)正向跟踪。检查产品需求规格说明书中的每个需求是否都能在后继工作成果中找到对应点。
• (2)逆向跟踪。检查设计文档、代码、测试用例等工作成果是否都能在产品需求规格说明书中找到出处。

在实际项目中，往往采用专门的配置管理工具来实现需求跟踪。