第三章 软件需求与需求工程

第三章 软件需求与需求工程_第1张图片

3.1 什么是软件需求

软件需求 = 业务知识 + 问题列表 + 其他因素。

业务知识:业务事件,业务实体,业务规则。

问题列表:用户在工作中遇到的困难和障碍,也是软件需要解决的问题。

其他因素:设计约束,非功能性需求等。

3.1.1 需求的三个层次

第三章 软件需求与需求工程_第2张图片

3.1.1.1 业务需求

业务需求是系统的高层次目标要求,即系统的建设目标,这种目标通常体现在两个方面:问题和机会。

业务需求的提出通常是高层管理人员,它是团队努力的方向。但如果业务需求过于夸大,可能会导致不必要的资源浪费。

业务需求是在项目立项阶段整理,也就是需求定义的产物。关于业务需求定义的方法,将在“第四章 需求定义最佳实践”中讲解。

3.1.1.2 用户需求(也叫原始需求)

用户需求是需求捕获的产物,是指用户使用软件需要完成什么任务,怎么完成。通常在业务需求定义的基础上进行调查整理。

用户需求有几个特点:

》零散:用户会提出不同角度,不同层面,不同粒度的需求。

》存在矛盾:由于用户处于企业不同位置,需求具有片面性,不同用户将存在不同观点。

正因如此,我们需要对用户需求进行分析,整理,从而得出更精确的需求说明。

3.1.1.3 软件需求

软件需求就是用户需求整理后的产物。

业务需求是需求定义的产物,用户需求是需求捕获的产物,软件需求是需求分析与建模的产物。

3.1.2 需求的三种类型

软件需求可以分为功能需求,非功能需求和设计约束三种类型。

3.1.2.1 功能需求

功能需求的要点在于如何组织。

对于功能需求的组织形式有以下几种:

》层次结构。在传统方法论中,会以系统-子系统-模块-子模块-功能-子功能的层次结构来组织,这也是一种方法。但它更多是一种程序结构,而非需求结构,它很可能会割裂用户的使用场景。

》RUP方法论中的用例方法。

》敏捷方法论中的用户故事。

》特征驱动开发中的Feature。

笔者建议首选用例方法,详细内容将在“第六章 需求分析与建模最佳实践”中介绍。

3.1.2.2 非功能需求

对于非功能需求最典型的问题有两个:

》信息传递的无效性:在前面的章节也讲到过,许多需求规格说明书中都有“设计原则”这一章,里面写着:高可靠性,高可用性,高扩展性等要求。但没人真正去看它,因为定性描述是没有判断标准的。所以这种就是信息无效传递。将在“第七章 需求描述最佳实践”中说明解决办法。

》忽略了非功能性需求的局部性。有时会看到“所有查询时间都应该小于10秒”。但当用户执行年度查询时,这是不合理的要求,最终也变成摆设。所以要抓住具体的场景来描述。

非功能需求的要点在于保证信息的有效传递和注意其局部性。

3.1.2.3 设计约束

设计约束包括非技术因素的技术选型,预期的软硬件环境和预期的使用环境三大类型。

在收集设计约束时,不能出现遗漏:

》非技术因素决定的技术选型。

》预期的软硬件环境。在整理需求时,应该将这些预期的软硬件环境描述出来,最有效的方法就是部署图,将在“第六章 需求分析与建模最佳实践”中讲述。

》预期的使用环境。

3.1.3 优秀需求的标准

完整性,正确性,无歧义性,必要性,有优先次序,可行性,可验证性。这7个标准可以分为4组。

3.1.2.1 完整性

完整性就是没有遗漏。将来在需求变更时“新需求”占比会较少。但在实际需求活动中,完整性是一个难题。完整性的关键在于以下两个方面:

》用户才是验证需求完整性的合适人选。但是用户往往需求都提不完整,如何对完整性进行验证?问题还是在需求组织结构上。很多人在组织需求时,通常是按照程序结构来梳理,这样做的结构就是用户在验证完整性时遇到障碍,无法直观系统的了解系统是否能满足所有需求。要保证需求的完整性,就必须从业务角度来组织各种需求像,让用户验证需求规格说明书中罗列的主题域,业务事件,业务活动,业务步骤,困难与障碍点是否完整。

业务导向的需求层次结构是保障完整性的关键。

》需求完整性存在不同层面。需求是有层次的,企业中高层,中层,操作员所了解和掌握的信息是不一样的, 在验证需求完整性时,需要采用分层评审的方式 ,不同层次的人员评审与自己相关的需求层次。

3.1.2.2 不失真

需求的正确性和无歧义性就是不失真。

》正确性。要使需求正确,一方面要分层次验证,一方面应该找到直接相关人员进行验证,另一方面,为了避免片面性,还要通过用户调查来补充。更多细节将在“第五章 需求捕获最佳实践”中介绍。

》无歧义性。是指在传递过程中不同的人加入不同的理解。因此光靠文档来传递需求是不充分的,沟通和验证活动能尽量缓解歧义问题。

3.1.2.3 有优先级

需求有时会戴上“高优先级”的面具,实际上只是担心你不实现而已。

所以引导用户从业务角度划分优先级是最关键的。除业务角度外,也要考虑技术角度和项目管理角度。

第三章 软件需求与需求工程_第3张图片

》从必要性的角度评价优先级

满意/不满意模型是需求必要性评价的有效手段。

第三章 软件需求与需求工程_第4张图片

3.1.2.4 技术人员早期参与

需求规格说明书,来源于用户,提供给技术人员,包括开发和测试。所以与技术团队交流,探讨需求规格存在哪些不足,缺少什么信息,是改进需求规格说明书的有效方法。

》可行性,由开发软对重点需求项,及复杂技术解决方案进行验证。

》可验证性,由测试团队验证。

3.2 需求工程解析

第三章 软件需求与需求工程_第5张图片

3.2.1 需求工程的范畴

第三章 软件需求与需求工程_第6张图片

需求工程包括需求开发和需求管理。需求开发是指收集,分析,整理,编写,验证的全过程,重点在于产出高质量的需求规格说明。需求管理是对需求的实现,变化进行追踪的全过程,重点在于确保开发的软件满足需求。

注意,需求定义并不包含在需求工程中,这是因为需求定义通常叫做项目立项,属于项目管理的范畴。将在“第四章 需求定义最佳实践”中介绍。

3.2.2 需求开发工作要点

第三章 软件需求与需求工程_第7张图片

现代软件工程的思想更偏向于多次循环,需求工程也不例外,通常需求获取,需求分析,编写规约,需求验证至少要经历三次循环。

第三章 软件需求与需求工程_第8张图片

对于需求获取,需求分析,编写规约,需求验证这四个活动,将在5-8章中详细介绍,这里只对其核心要点和盲区进行说明。

3.2.2.1 需求获取(需求捕获)

需求捕获是一个主动的过程,而显示中却常常是比较被动的,主要体现在:

》捕获范围不足:只注重用户要实现什么功能,不注重对业务知识的捕获。

》缺乏计划性:捕获过程随意,预先没有对问题,时间,访谈人员进行计划。

》缺乏科学性:捕获过程比较分散,没有做到定向,聚焦,常常把宏观问题和微观问题混在一起。

》捕获对象不明确:很少主动寻找合适的被访谈者,常常是对方主动指定。

》捕获手段不足:通常认为只有用户访谈和调研会是有效手段,但忽略了不同场景下捕获手段的不同组合将有更好的效果。

“第五章 需求捕获最佳实践”中将详细说明需求捕获的策略,方法和工具。

需求捕获活动中,化被动为主动是关键。

3.2.2.2 需求分析

需求分析是需求工程中的核心任务,但在实践中常被忽视,也就是捕获的需求直接整理到需求规格说明书中。

》需求分析是什么。需求分析是业务分析,因此要从业务线索入手,而非程序结构;需求分析是一种分解活动,将按职责划分成不同的主题域,再分解到业务流程,再分解到用例;需求分析是一种提炼与整合活动,将原始需求整合到业务活动中,将业务活动整合到全局业务流程图中;需求分析是一种规格化活动。将在“第六章需求分析与建模最佳实践”中详解。

需求分析就是向下分解+向上提炼,外加一些规格化。

》内容和形式

建模语言越来越流程,但一定要理解:分析是任务,建模是手段。建模的过程就是分析的过程。尽量团队建模;大胆使用草图,而不是一上来就开rose。

需求分析是目标,需求建模是手段。

3.2.2.3 编写规约

编写规约就是需求分析结果文档化的过程。软件需求规格说明书的要点在于:分享,更新。

第三章 软件需求与需求工程_第9张图片

3.2.2.4 需求验证

需求验证不是签字,细节将在“第八章 需求验证最佳实践”中阐述。

3.2.3 需求管理工作要点

需求管理包括基线管理,变更管理和需求跟踪三个活动。

第三章 软件需求与需求工程_第10张图片

需求管理可以分为四步:统一明确的需求项划分标准,引入基线管理,引入变更管理,引入需求跟踪。下面将逐一讲解。

3.2.3.1 统一明确的需求项划分标准。

》颗粒均匀。即衡量需求工作量的单位是相同的,人天,人月,人周都可以,但是需要统一。

》大小合适。

》完整。最低一级的需求项应该覆盖所有开发任务。

“第六章 需求分析与建模最佳实践”中将具体阐述。

划分出大小合适,颗粒均匀的需求项是需求管理的前提。

3.2.3.2 引入基线管理

基线管理将需求分为两个部分:已经开始开发的需求(baseline),还没安排开发的需求(backlog)。(一个基线内容就是Scrum里的一个冲刺)

第三章 软件需求与需求工程_第11张图片

在划分基线时,通常需要完成三件事:

1 确定优先级,确保高优先级,高风险的需求尽早完成。

2 工作量估算,确保每次迭代的安排是紧凑的。

3 未完成项的合并,每次迭代还是可能有些工作未完成,分配下一次基线时就要考虑进去。

具体将在“第九章 需求基线操作事务”中距离说明。

需求优先级与工作量估算是基线管理的关键。

3.2.3.3 引入变更管理

变更如果简单地转交给开发人员,会使开发团队变成救火队,陷入大量紧急却不重要的工作中 。所以引入变更管理是非常重要的。就需求管理而言,变更管理的重要在于完成业务影响分析,技术影响分析,项目影响分析三方面工作。具体可以参考“第十章 变更管理操作事务”。

》业务影响分析:从业务角度对变更的合理性,优先级,对原有需求的影响进行分析,以便决定是否纳入backlog中。

》技术影响分析:从技术角度对变更的影响范围,工作量进行分析。

》项目影响分析:基于前面的工作量分析,考虑是否对整个项目的进度成本产生较大影响。

变更管理的核心是控制变更的影响,而非消除变更。

3.2.3.4 引入需求跟踪

需求跟踪是一种高阶管理活动,将辅助大量的工作量,因此在前三个活动还不是很顺畅时,不建议引入需求跟踪。我们将在“第十一章 需求跟踪操作事务”中介绍。

3.2.4 需求分析人员的技能组成

需求分析人员必须掌握的技能包括:倾听,交谈,提问的技巧,分析,协调,观察,写作,组织,建模,人际交往和创造能力。这些能力可以概括为业务知识,技术知识,沟通能力三个方面。

第三章 软件需求与需求工程_第12张图片

3.2.4.1 需求分析人员的来源

推荐是以用户背景的人员(甲方需求人员)为核心,以开发人员作为解决方案的选择和技术论证(乙方需求人员),领域专家作为顾问。

但在现实中,更多还是以乙方需求分析人员为主角,这时就要充分发挥用户背景的需求人员作为业务支持。

3.2.4.2 各种能力培养的要点

第三章 软件需求与需求工程_第13张图片

对于沟通能力方面,在“第五章 需求捕获最佳实践”中有很多案例。

3.2.5 SERU模型概述

第三章 软件需求与需求工程_第14张图片

SERU模型分为三个阶段:Subject1-3是需求定义阶段,Event和Report4是理清脉络阶段,User case5是细节填充阶段。

》需求定义阶段:就是项目立项阶段。核心目标在于定义项目目标和范围。主要任务就是划分主题域,并标识出每个主题域中的Event(业务事件)和Report(报表)。

》理清脉络阶段:相当于需求捕获,分析和建模的第一阶段。就是将每个Event(业务事件),每个Report(报表)进行分析,包括事(流程),物(业务实体),人(角色)的分析。

》细节填充阶段,相当于需求捕获,分析和建模的第二阶段。

你可能感兴趣的:(第三章 软件需求与需求工程)