软件开发转型-业务需求

软件开发转型-业务需求

1

概述

需求是从系统外部能发现系统所具有的满足于用户的特点、功能及属性等。需求是指明必须实现什么的规格说明。它描述了系统的行为、特性或属性，是在开发过程中对系统的约束。

软件需求工程划分为需求开发和需求管理，其中需求开发可进一步分为问题获取(elicitation)、分析(analysis)、编写规格说明(specification)和验证(verification)四个阶段,

需求开发活动包括以下几个方面： (1) 确定产品所期望的用户类 (2) 获取每个用户类的需求

(3) 了解实际用户任务和目标以及这些任务所支持的业务需求

(4) 分析源于用户的信息以区别用户任务需求、功能需求、业务规则、质量属性、建议解决

方法和附加信息

(5) 将系统级的需求分为几个子系统，并将需求中的一部分分配给软件组件 (6) 了解相关质量属性的重要性 (7) 商讨实施优先级的划分

(8) 将所发现的用户需求编写成规格说明和用例模型

(9) 评审用例和需求规格说明，确保对用户需求达到共同的理解与认识，并在整个开发小组

接受说明之前将问题都弄清楚。 需求管理活动包括以下几个方面：

(1) 定义需求基线(迅速制定需求文档的主体)

(2) 评审提出的需求变更、评估每项变更的可能影响从而决定是否实施它 (3) 以一种可控制的方式将需求变更融入到项目中 (4) 使当前的项目计划与需求一致

(5) 估计变更需求所产生的影响并在此基础上协商新的承诺。

(6) 让每项需求都能与其对应的设计、源代码和测试用例联系起来以实现跟踪 (7) 在整个项目过程中跟踪需求状态及其变更情况。 2 需求管理       确定变更控制过程 建立变更控制委员会 进行变更影响分析 跟踪影响工作产品的每项变更 编写需求文档的基准版本和控制版本 维护变更历史记录 需求工程的推荐方法

项目管理     选择合适的生存周期 确定需求基本计划 协商约定 管理需求风险 需求工程推荐方法

Page 1 of 7

 跟踪需求状态  衡量需求稳定性  使用需求管理工具 需求开发 获取 ➢ 编写前景 ➢ 确定需求开发过程 ➢ 用户群分类 ➢ 选择产品代表 ➢ 确定用例 ➢ 联系会议 ➢ 分析用户工作流程 ➢ 确定质量属性 ➢ 检查问题报告 ➢ 需求重用 2.1

需求获取

分析 ➢ ➢ ➢ ➢ ➢ ➢ ➢ 绘制关联图 创建开发原型 分析可行性 确定需求优先级 为需求建立模型 编写数据字典 应用质量功能调配 编写规格说明书 ➢ 采用软件需求规格说明模版 ➢ 指明需求来源 ➢ 为每项需求注上标号 ➢ 记录业务范围 ➢ 创建需求跟踪能力矩阵 验证 ➢ 审查需求文档 ➢ 依据需求编写测试用例 ➢ 确定合格标准 （1） 编写前景文档：前景文档应该包括高层的产品业务目标，所有的用例和功能需

求都必须遵从能达到的业务需求。项目前景文档中的说明使所有项目参与者对项目的目标能达成共识。

（2） 确定用户类：为避免出现疏忽某一用户群需求的情况，要将可能使用产品的客

户分成不同组别。他们可能在使用频率、使用特性、优先等级或熟练程度等方面都有所差异。详细描述出它们的个性特点及任务状况，将有助于产品设计

（3） 在每个用户类中确定适当的代表：为每类用户至少选择一位能真正代表他们需

求的人作为那一类用户的代表并能作出决策。

（4） 运用需求获取方法对系统的重要部分进行用例开发并设置优先级

（5） 确定用例：从用户代表处收集他们使用软件完成所需任务的描述，编写用例，

描述用户与系统间的交互方式和对话要求。

（6） 召开应用程序开发联系会议：应用程序开发联系会议是范围广的、简便的专题

讨论会，也是分析人员与客户代表之间一种很好的合作办法，可以在会上就已完成的工作或未完成的工作与客户展开讨论，并能由此拟出需求文档的底稿。

（7） 分析用户工作流程：观察用户执行业务任务的过程。画一张简单的示意图（最

好是数据流图）来描绘用户什么时候获得什么数据，并怎样使用这些数据。并与客户讨论此内容。

（8） 确定质量属性和其它非功能需求：在功能需求之外再考虑一下非功能的质量特

点。这些特点包括性能、有效性、可靠性、可用性等，而这些质量属性上客户提供的信息相对来说就非常重要了。

（9） 通过检查当前系统的问题报告来进一步完善需求：客户的问题报告及补充需求

为新产品或新版本提供了大量丰富的改进及增加特性的想法，负责提供用户支

Page 2 of 7

持及帮助的人能为需求过程提供极有价值的信息。

（10） 跨项目重用需求：如果客户要求的功能与已有产品很相近，则可查看需求是否

有足够的灵活性以允许重用一些已有的软件组件。 2.2

需求分析

需求分析（ requirement analysis）包括提炼、分析和仔细审查已收集到的需求，以确保所有的stakeholder 都明白其含义并找出其中的错误、遗漏或其它不足的地方。分析员通过评价来确定是否所有的用例和软件需求规格说明都达到了优秀需求说明的要求。分析的目的在于开发出高质量和具体的需求，这样你就能作出实用的项目估算并可以进行设计、构造和测试。

通常，把需求中的一部分用多种形式来描述，如同时用文本和图形来描述。分析这些不 同的视图将揭示出一些更深的问题，这是单一视图无法提供的。分析还包括与客户的交流以澄清某些易混淆的问题，并明确哪些需求更为重要。其目的是确保所有stakeholder 尽早地对项目达成共识并对将来的产品有个相同而清晰的认识。

1)绘制系统关联图:这种关联图是用于定义系统与系统外部实体间的界限和接口的简单 模型。同时它也明确了通过接口的信息流和物质流。

2) 创建用户接口原型:当开发人员或用户不能确定需求时，开发一个用户接口原型—一 个可能的局部实现—这样使得许多概念和可能发生的事更为直观明了。用户通过评价原型 将使项目参与者能更好地相互理解所要解决的问题。注意要找出需求文档与原型之间所有的 冲突之处。

3) 分析需求可行性:在允许的成本、性能要求下，分析每项需求实施的可行性，明确与 每项需求实现相联系的风险，包括与其它需求的冲突，对外界因素的依赖和技术障碍。 4) 确定需求的优先级别:应用分析方法来确定用例、产品特性或单项需求实现的优先级别。以优先级为基础确定产品版本将包括哪些特性或哪类需求。当允许需求变更时，在特定的版本中加入每一项变更，并在那个版本计划中作出需要的变更。给每个需求建立优先级有助于解决冲突，安排阶段交付，并且做出必要的取舍。需求的优先级可以设为三类，①基本的－只有在这些需求上达成一致意见，软件才会被接收；②条件的－实现这些需求将增强产品的性能，但如果忽略这些需求，产品也是可以被接受的；③可选的－一个功能类，实现或不实现均可

5) 为需求建立模型：需求的图形分析模型是软件需求规格说明极好的补充说明。它们能提供不同的信息与关系以有助于找到不正确的、不一致的、遗漏的和冗余的需求。这样的模型包括数据流图、实体关系图、状态变换图、对象类及交互作用图。

6) 创建数据字典：数据字典是对系统用到的所有数据项和结构的定义，以确保开发人员 使用统一的数据定义。在需求阶段，数据字典至少应定义客户数据项以确保客户与开发小组 是使用一致的定义和术语。数据字典可以用术语表代替。 2.3

需求规格说明

无论你的需求从何而来，也不管你是怎样得到的，得到的形式是什么，你都必须用一种统一的方式来将它们编写成可视文档。业务需求要写成前景文档。用户需求要编成用例及用例规约和补充规约。而软件需求规格说明（requirement specification）则包含了软件的功能需求和非功能需求。

1) 采用S R S模板：在组织中要为编写软件需求文档定义一种标准模板。该模板为记录 功能需求和各种其它与需求相关的重要信息提供了统一的结构。模板是很有用的，但有时 要根据项目特点进行适当的改动。

Page 3 of 7

2) 指明需求的来源：为了让所有stakeholder明白S R S中为何提供这些功能需求，要都能追溯每项需求的来源，这可能是一种使用实例或其它客户要求，也可能是某项更高层系统需求、业务规范、政府法规、标准或别的外部来源。

3) 为每项需求注上标号:制定一种惯例来为S R S中的每项需求提供一个独立的可识别的标 号或记号。这种惯例应当很健全，允许增加、删除和修改。作了标号的需求使得需求能被跟 踪，记录需求变更并为需求状态和变更活动建立度量。

4) 记录业务规范:业务规范是指关于产品的操作原则，比如谁能在什么情况下采取什么动作。将这些编写成S R S中的一个独立部分，或一独立的业务规范文档。某些业务规范将引 出相应的功能需求；当然这些需求也应能追溯相应业务规范。

5) 创建需求跟踪能力矩阵:建立一个矩阵把每项需求与实现、测试它的设计和代码部分 联系起来。这样的需求跟踪能力矩阵同时也把功能需求和高层的需求及其它相关需求联系起 来了。 2.4

需求验证

验证是为了确保需求说明准确、完整地表达必要的质量特点。当你阅读软件需求规格说 明（S R S）时，可能觉得需求是对的，但实现时，却很可能会出现问题。当以需求说明为依据编写测试用例时，你可能会发现说明中的二义性。而所有这些都必须改善，因为需求说明要作为设计和最终系统验证的依据。客户的参与在需求验证（ requirement verification）中占有重要的位置。

1) 审查需求文档:对需求文档进行正式审查是保证软件质量的很有效的方法。组织一个 由不同代表（如分析人员，客户，设计人员，测试人员）组成的小组，对S R S及相关模型进行仔细的检查。另外在需求开发期间所做的非正式评审也是有所裨益的。

2) 以需求为依据编写测试用例:根据用户需求所要求的产品特性写出黑盒功能测试用例。 客户通过使用测试用例以确认是否达到了期望的要求。还要从测试用例追溯回功能需求以确 保没有需求被疏忽，并且确保所有测试结果与测试用例相一致。同时，要使用测试用例来验 证需求模型的正确性，如对话框图和原型等。

3) 确定合格的标准:让用户描述什么样的产品才算满足他们的要求和适合他们使用的。 将合格的测试建立在使用情景描述或使用用例的基础之上 2.5

需求管理

当你完成需求说明之后，不可避免地还会遇到项目需求的变更。有效的变更管理需要对 变更带来的潜在影响及可能的成本费用进行评估。变更控制委员会与关键的项目风险承担者 要进行协商，以确定哪些需求可以变更。同时，无论是在开发阶段还是在系统测试阶段，还 应跟踪每项需求的状态。建立起良好的配置管理方法是进行有效需求管理（ requirement management）的先决条件。

可以使用版本控制和其它管理配置技术来管理代码和文档，

1) 确定需求变更控制过程：确定一个选择、分析和决策需求变更的过程。所有的需求变 更都需遵循此过程，商业化的问题跟踪工具都能支持变更控制过程。

2) 建立变更控制委员会：组织一个由项目风险承担者组成的小组作为变更控制委员会， 由他们来确定进行哪些需求变更，此变更是否在项目范围内，估价它们，并对此评估作出决 策以确定选择哪些，放弃哪些，并设置实现的优先顺序，制定目标版本。

3) 进行需求变更影响分析：应评估每项选择的需求变更，以确定它对项目计划安排和其 它需求的影响。明确与变更相关的任务并评估完成这些任务需要的工作量。通过这些分析将 有助于变更控制委员会作出更好的决策。

4) 跟踪所有受需求变更影响的工作产品：当进行某项需求变更时，参照需求跟踪能力矩阵

Page 4 of 7

找到相关的其它需求、设计模板、源代码和测试用例，这些相关部分可能也需要修改。这样能减少因疏忽而不得不变更产品的机会，这种变更在变更需求的情况下是必须进行的。 5) 建立需求基准版本和需求控制版本文档：确定一个需求基准，这是一致性需求在特定 时刻的快照。之后的需求变更就遵循变更控制过程即可。每个版本的需求规格说明都必须是 独立说明，以避免将底稿和基准或新旧版本相混淆。最好的办法是使用合适的配置管理工具 在版本控制下为需求文档定位。

6) 维护需求变更的历史记录：记录变更需求文档版本的日期以及所做的变更、原因，还 包括由谁负责更新和更新的新版本号等。

7) 跟踪每项需求的状态：建立一个数据库，其中每一条记录保存一项功能需求。保存每 项功能需求的重要属性，它包括状态（如已推荐的，已通过的，已实施的，或已验证的），这样在任何时候都能得到每个状态类的需求数量。

8) 衡量需求稳定性：记录基准需求的数量和每周或每月的变更（添加、修改、删除）数 量。过多的需求变更“是一个报警信号”，意味着问题并未真正弄清楚，项目范围并未很好地确定下来或是政策变化较大。

9) 使用需求管理工具：商业化的需求管理工具能帮助在数据库中存储不同类型的需求，为每项需求确定属性，可跟踪其状态，并在需求与其它软件开发工作产品间建立跟踪能力联系链。 2.6

项目管理

软件工程管理方法在本质上与项目的需求过程是紧密相关的。项目计划建立在功能基础之上，而需求变更会影响这些计划。因此，项目计划应能允许一定程度的需求变更或项目范 围的扩展。如果刚开始，需求不能确定，可以选择一种软件开发方法生存周期以允许这种 不确定性，并在弄清后逐渐实施。

1) 选择一种合适的软件开发方法生存周期：如果需求说明在项目早期无法全部确定，则从 最为清晰易懂的需求开始，建立一个健壮的可修改的结构，再逐渐增加补充。实现了部分特 性的产品可作为早期版本发布。

2) 基于需求的项目计划：随着需求细节不断变得清晰、完善，项目开发计划的进度安排 将会不断改变。一开始可以根据前景对开发功能需求所需的工作量作一个估算，建立在不甚完善的需求基础之上的成本、进度安排的估计很不可靠，但随着需求说明的完善，估计也会得到不断改善。

3) 发生需求变更时协商项目约定：当在项目中添加新的需求时，估计一下你是否能在目 前安排下，利用现有资源保质保量完成。如果不能，将项目的实现与管理联系起来，协商一 下新的、切实可行的约定。如果协商不成功则将可能的后果和更新项目风险管理计划联系起来，以反映出对项目成功的新的不利因素。

4) 编写文档和管理与需求相关的风险：采用自由讨论的方法并将与需求相关的项目风险 编写成文档。利用各种方法来减轻或阻止这些风险，实施这些方法并跟踪其发展及效果。 3

与需求有关的风险

下面介绍的风险因素是按需求工程中获取、分析、编写规格说明、验证和管理汇总起来

的，并推荐了一些方法用于降低风险发生的可能性或减轻风险发生给项目带来的影响。 3.1

需求获取

1) 前景：如果团队成员没有对他们要做的产品功能达成一个清晰的共识，则很可能导致项目范围的逐渐扩大。因此最好在项目早期写一份项目前景文档将业务需求涵盖在内，并将其作为新的需求及修改需求的指导。

Page 5 of 7

2) 需求开发所需时间：紧张的工程进度安排给管理者造成很大的压力，使他们觉得不赶紧开始编码将无法按时完成项目，因而对需求一带而过。项目因其规模和应用种类不同（如 信息系统，系统软件，商业的或军事的应用）而有着很大的不同。粗略的统计表明：需求开 发工作应占全部工作量的1 5 %。记录你参与的每个项目中实际需求开发的工作量，这样就能知道所花的时间是否合适并改进将来项目的工作计划。

3) 需求规格说明的完整性和正确性：为确保需求是客户真正需要的，要以用户的任务为中心，应用用例获取需求。根据不同的使用情景编写需求用例，建立原型，使需求对用户来说更加直观，同时获取用户的反馈信息。让客户代表对需求规格说明和分析模型进行正式的评审。

4) 对革新产品的需求：有时容易忽略市场对产品的反馈信息。故要强调市场调查研究，建立原型，并运用客户核心小组来获得革新产品任务的反馈信息。

5) 明确非功能需求：由于一般强调产品的功能性要求，非常容易忽略产品的非功能性的需求。询问客户关于产品性能、使用性、完整性、可靠性等质量特性，编写非功能需求文档 和验收标准，（像在S R S中一样）作为可接受的标准。

6) 客户赞同产品需求：如果不同的客户对产品有不同的意见，那最后必将有些客户会不 满意。确定出主要的客户，并采用产品代表的方法来确保客户代表的积极参与，确保在需求 决定权上有正确的人选。

7) 未加说明的需求：客户可能会有一些隐含的期望要求，但并未说明。要尽量识别并记 录这些假设。提出大量的问题来提示客户以充分表达他们的想法、主意和应关注的一切。 8) 把已有的产品作为需求基线：在升级或重做的项目中需求开发可能显得不很重要。开 发人员有时被迫把已有的产品作为需求说明的来源。“只是修改一些错误和增加一些新特性”，这时的开发人员不得不通过现有产品的逆向工程(reverse engineering)来获取需求。可是，逆向工程对收集需求是一种既不充分也不完整的方法。因此新系统很可能会有一些与现有系统同样的缺陷。将在逆向工程中收集的需求编写成文档，并让客户评审以确保其正确性。

9) 给出期望的解决办法：用户推荐的解决方法往往掩盖了用户的实际需求，导致业务处 理的低效，或者给开发人员带来压力以至做出很差的设计方案。因此分析人员应尽力从客户 叙说的解决方法中提炼出其本质核心。 3.2

需求分析

1) 划分需求优先级：划分出每项需求、特性或使用实例的优先级并安排在特定的产品版 本或实现步骤中。评估每项新需求的优先级并与已有的工作主体相对比以做出相应的决策。 2) 带来技术困难的特性：分析每项需求的可行性以确定是否能按计划实现。成功好象总是悬于一线的，应该运用项目状态跟踪的办法管理那些落后于计划安排的需求，并尽早采取 措施纠正。

3) 不熟悉的技术、方法、语言、工具或硬件平台：不要低估了学习曲线中表明的满足某项需求所需要的新技术的速度跟进情况。明确那些高风险的需求并留出一段充裕时间从错误 中学习、实验及测试原型。 3.3

需求规格说明

1) 需求理解开发人员和客户对需求的不同理解会带来彼此间的期望差异，将导致最终产品无法满足客户的要求。对需求文档进行正式评审的团队应包括开发人员，测试人员和客户。训练有素且颇有经验的需求分析人员能通过询问客户一些合适的问题，从而写出更好的规格说明。模型和原型能从不同角度说明需求，这样可使一些模糊的需求变得清晰。

2) 时间压力对T B D的影响：将S R S中需要将来进一步解决的需求注上T B D记号，但如果

Page 6 of 7

这些T B D并未解决，则将给结构设计与项目的继续进行带来很大风险。因此应记录解决每项T B D的负责人的名字，如何解决的以及解决的截止日期。

3) 具有二义性的术语：建立一本术语和数据字典，用于定义所有的业务和技术词汇，以 防止它被不同的读者理解为不同的意思。特别是要说明清楚那些既有普通含义又有专用领域 含义的词语。对S R S的评审能够帮助参与者对关键术语、概念等达成一致的共识。 4) 需求说明中包括了设计：包含在S R S中的设计方法将对开发人员造成不必要的限制并妨 碍他们发挥创造性设计出最佳的方案。仔细评审需求说明以确保它是在强调解决业务问题需 要做什么，而不是在说怎么做。 3.4

需求验证

1) 未经验证的需求：审查相当篇幅的S R S是有些令人沮丧，正如要在开发过程早期编写测 试用例一样。但如果在构造设计开始之前通过验证基于需求的测试计划和原型测试来验证需 求的正确性及其质量，就能大大减少项目后期的返工现象。在项目计划中应为这些保证质量 的活动预留时间并提供资源。从客户代表方获得参与需求评审的赞同（承诺），并尽早且以尽可能低的成本通过非正式的评审逐渐到正式评审来找出其存在的问题。

2) 审查的有效性：如果评审人员不懂得怎样正确地评审需求文档和怎样做到有效评审，那么很可能会遗留一些严重的问题。故要对参与需求文档评审的所有团队成员进行培训，请 组织内部有经验的评审专家或外界的咨询顾问来讲课、授教以使评审工作更加有效。 3.5

需求管理

1) 变更需求：将前景文档作为变更的参照可以减少项目范围的延伸。用户积 极参与的具有良好合作精神的需求获取过程可把需求变更减少近一半。能在早期发现需求错误的质量控制方法可以减少以后发生变更的可能。而为了减少需求变更的影响，将那些易于变更的需求用多种方案实现，并在设计时更要注重其可修改性。

2) 需求变更过程：需求变更的风险来源于未曾明确的变更过程或采用的变动机制无效或不按计划的过程来做出变更。应当在开发的各阶层都建立变更管理的纪律和氛围，当然这需 要时间。需求变更过程包括对变更的影响评估，提供决策的变更控制委员会，以及支持确定 重要起点步骤的工具。

3) 未实现的需求：需求跟踪能力矩阵有助于避免在设计、结构建立及测试期间遗漏的任 何需求。也有助于确保不会因为交流不充分而导致多个开发人员都未实现某项需求。

4) 扩充项目范围：如果开始未很好定义需求，那么很可能隔段时间就要扩充项目的范围。 产品中未说明白的地方将耗费比预料中更多的工作量，而且按最初需求所分配好的项目资源 也可能不按实际更改后用户的需求而调整。为减少这些风险，要对阶段递增式的生存期制定 计划，在早期版本中实现核心功能，并在以后的阶段中逐步增加实现需求。 3.6

风险管理是你的好助手

项目管理人员可以运用风险管理来提高对造成项目损失的条件的警惕，在需求获取阶段 要有用户的积极参与。精明的管理者不仅要能认识到它能带来风险的条件，而且将它编入风险清单，并依据以往项目的经验估计其可能性和影响。如果用户一直没有参与，风险危害值将会扩大以至危害项目的成功。周期性的风险跟踪能使管理人员保持对风险危害变化的了解，对那些并未得到完全控制的风险能得到高层管理人员的注意。他们要么开始采取一些修正措施，要么不管风险，依旧按原业务决策思路进行。即使不能控制项目可能遇到的所有风险，风险管理也能使你看清形势，做出的决策是有所依据。

Page 7 of 7