一、需求规格说明

1.1需求规格说明概述

需求获取的目标是得到用户的需求——收集需求信息
需求分析的目标是更深刻的理解用户的需求——界定能够让用户满意的解决方案和准则
需求规格说明的目标是定义用户的需求——准确描述其需求和解决方案

需求规格说明文档的撰写流程如下图：

1.2需求规格说明文档 

常见的需求说明文档主要有以下几种：

 项目的前景和范围文档被视为属于用户的文档，主要包括的内容有问题域信息、解决方案、需求，内容较为抽象，具有概括性的特点
招标活动是基于用户需求文档进行的
大多数系统开发项目都是以系统需求规格说明文档为基础签约的

对系统规格说明的细化和详细说明会产生软件需求规格说明文档、硬件需求规格说明文档、接口需求规格说明文档和人机交互文档，都是开发文档。

 需求规格文档的作者和读者有：项目管理者、设计人员和程序员、测试人员、文档编写人员、维护人员、培训人员、律师

需求规格说明文档—— 手段：信息描述语言的3种类别：
非形式化（文本为主）
半形式化（图形为主）
形式化（数学公式为主）

1.3模版的选择与裁剪

大概样式

 

1.4文档写作技巧 （略）

指导原则：
写作是一门艺术
文档化的目标是交流

内容组织：
所有内容位置得当
引用或强化，但不重复

表达方式：
形式依赖于内容
使用系统的表达方式

细节描述：
定义术语表或数据字典时应避免的问题有
术语不一致
“方言”问题
错误术语和冗余术语
避免干扰文本
避免歧义词汇

1.5优秀需求规格说明文档的特性

完备性

标准（当且仅当）
描述了用户的所有有意义的需求，包括功能、性能、约束、质量属性和对外接口。
每一条需求都是完备的。
定义了软件对所有情况的所有实际输入（无论有效输入还是无效输入）的响应。
为文档中的所有插图、图、表和术语、度量单位的定义提供了完整的引用和标记。
正确的前景和范围

一致性

细节的需求不能同高层次的需求相冲突，例如系统需求不能和业务需求、用户需求互相矛盾
同一层次的不同需求之间也不能互相冲突

根据重要性和稳定性分级

建立需求的优先级

可修改

标准
它的结构和风格使得人们可以对其中任一需求进行容易地、完整地、一致地修改，同时还不会影响文档现有的结构和风格

文档的可修改性要求：
有着条理分明并且易于使用的组织方式，包括目录、索引和显式的交叉引用。
没有重复冗余。
独立表达每个需求，而不是和其他需求混在一起。

可跟踪

1.后向跟踪（Backward traceability）
能找到需求的来源，例如和更早期文档的显式关联。
2.前向跟踪（Forward traceability）
能找到需求所对应的设计单元、实现源代码和测试用例等，它要求每个需求都要有唯一的标识或者可供引用的名称

1.6需求规格说明的实践调查

不编写正式的需求规格说明文档的原因：
1.时间压力，用非正式文档替代
2.迭代式开发，每次迭代是完成本次需求的正式需求规格说明，最后在整合成完整版本

在需求获取和需求分析当中，可以采用以下一些手段来保证最终需求集的完备性、一致性和正确性：

• 需求获取
• 需求采集
• 需求表达
• 需求验证

二、需求验证

2.1验证与确认

需求验证主要有两层含义：
1.验证：正确得到需求
2.确认：得到正确的需求

1. 需求验证：以正确的方式建立需求
需求集是正确的、完备的和一致的；
技术上是可解决的；
它们在现实世界中的满足是可行的和可验证的。

2.需求确认：建立的需求是正确的
每一条需求都是符合用户原意的
系统验证：正确的建立系统
系统能够在预期的环境中正确的执行设定的功能。
系统确认：建立的系统是正确的
建立的系统是符合系统需求和系统设计的

验证贯穿于整个软件生命周期，静态分析和测试的两个主要手段

2.2需求验证

需求验证是专指在需求规格说明完成之后，对需求规格说明文档进行的验证活动

方法：需求评审、原型与模拟 测试用例开发手册编制，利用跟踪关系，自动化分析 

2.3需求验证方法

• 评审
• 原型与模拟
• 开发测试用例
• 用户手册编制
• 利用跟踪关系
• 自动化分析

2.3.1评审

由作者之外的其他人来检查产品问题的方法
是主要的静态分析手段
原则上，每一条需求都应该进行评审

检查方法	描述
自由方法（Ad-hoc）	没有为检查人员提供系统化的引导
检查清单（Checklist-Based）	以通用的检查清单来引导检查过程
缺陷（Defect-Based）	用于需求文档，根据缺陷的分类来组织和检查场景
功能点（Function Point-Based）	按照功能点来组织和检查场景
视角（Perspective-Based）	按照不同涉众类型的视角来组织和检查场景
场景（Scenario-Based） 常用的方法	对每一个场景，都利用一系列的问题或者细节要求，来引导检查过程。缺陷、功能点、视角都是场景方法的一个特例。
逐步提升（Stepwise Abstraction）	净室软件开发中的一种方法。阅读者描述一些独立代码段的功能，然后将描述的范围逐步扩大，描述的功能抽象逐步提高，直至阅读人员描述了整个评审物件

 2.3.2原型与模拟

用于静态方法力所不及的复杂需求

涉及到复杂的动态行为时
成本较高

2.3.3开发测试用例

为需求类开发测试用例也可以被看成一个有效的需求验证方法
无法测试的需求并非绝对有问题

排斥性需求和全局非功能性需求通常无法定义测试用例

2.3.4用户手册编制

用户手册主要包含以下内容：
1.验证功能需求：对软件系统功能和实现的描述
2.验证项目范围：对系统没有实现的功能的描述
3.验证异常流程需求：问题和故障的解决
4.验证环境与约束需求：系统的安装和启动

2.3.5利用跟踪关系※

业务需求（系统特性）=>用户需求（业务、任务）=>系统需求（分析模型）
逐步细化的关系
如果业务需求和用户需求没有得到后项需求（用户需求和系统需求）的充分支持，那么软件需求规格说明文档就存在不完备的缺陷。软件需求规格说明文档描述的是系统级需求，被用来进行需求验证

系统需求=>用户需求=>业务需求
如果不能依据跟踪关系找到一条系统需求的前项用户需求和前项业务需求，那么该需求就属于非必要的需求

2.3.6自动化分析

2.4问题修正※ 

1.需求澄清
（1）理解偏差：重新进行分析工作
（2）分析遗漏：重新分析和文档化这部分信息
（3）表达不当：重新以合适的方式表达

2.发现缺失需求
重新执行需求获取等一系列工作

3.解决需求冲突
协商解决

4.修正不切实际的期望
项目调整与需求协商

2.5需求验证的实践调查

需求验证是重要的
需求验证是容易被忽视的
需求验证的方法是多样的
评审和原型最为广泛

三、需求管理

3.1需求管理

3.2需求基线

是被明确和固定下来的需求集合，是项目团队需要在某一特定产品版本中实现的特征和需求集合

需求基线的主要描述内容有软件需求（需求基线的关键内容）+和软件需求相关的描述信息 

• 标识符（ID），为后续的项目工作提供一个共同的交流参照。
• 当前版本号（Version），保证项目的各项工作都建立在最新的一致需求基础之上。
• 源头（Source），在需要进一步深入理解或者改变需求时，可以回溯到需求的源头。
• 理由（Rational），提供需求产生的背景知识。
• 优先级（Priority），后续的项目工作可以参照优先级进行安排和调度。
• 状态（Status），交流和具体需求相关的项目工作状况。
• 成本、工作量、风险、可变性（Cost、Effort、Risk、Volatility），为需求的设计和实现提供参考信息，驱动设计和实现工作。

3.3需求跟踪

主要目的是：避免在开发过程或者演化过程中与需求基线不一致或者偏离的风险

需求跟踪是以软件需求规格说明文档为基线，在向前和向后两个方向上，描述需求以及跟踪需求变化的能力。

1.前向跟踪是指被定义到软件需求规格说明文档之前的需求演化过程
向需求的跟踪：说明涉众的需要和目标产生了哪些软件需求
从需求向后回溯：说明软件需求来源于哪些涉众的需要和目标

2.后向跟踪是指被定义到软件需求规格说明文档之后的需求演化过程
从需求向后跟踪：说明软件需求是如何被后续的开发物件支持和实现的
向需求的回溯：说明各种系统开发的物件是因为什么原因（软件需求）而被开发出来的

3.3.1用途

 需求的后向跟踪可以帮助项目管理者：

需求的后向跟踪可以帮助客户和用户：

需求跟踪中针对具体需求的设计方案选择、设计假设条件以及设计结果等信息可以帮助设计人员：

需求跟踪信息还可以帮助维护人员：

3.3.2内容

需求跟踪实现的具体内容是依赖于项目的跟踪策略的

3.3.3实现方法

 1.矩阵、2.实体关系模型和3.交叉引用

3.4需求变更控制 

需求的变化是正当和不可避免的，包括：
问题发生了改变
环境发生了改变
需求基线存在缺陷

3.5需求管理的实践调查

3.5.1需求变更

变更发生的事件越迟，影响越大
新增（Added）需求影响最大——影响最大的变更类型
缺陷修复是最为频繁的变更类型
范围蔓延是常见的风险因素

3.5.2需求管理工具

通用的文本处理器（Word Processor）和电子表格（Spreadsheet）使用最为广泛

四、需求工程中的过程管理

4.1需求工程中的过程管理

 需求工程具有环境依赖性

环境因素：

• 市场特性 例如，客户定制开发 VS 市场驱动
• 领域特性 例如，成熟领域 VS 不成熟领域，关键性软件 VS 一般应用
• 技术成熟度 高 VS低
• 组织文化 固有习惯
• 项目特性

4.2过程建立（两个步骤：）

• 建立过程框架
• 选择工作组件 

4.2.1建立过程框架

选择一个适用项目的过程模型，进行定制和本地化

26种需求工程的过程模型，3种典型的需求工程的过程模型：

（1）完全线性的过程模型 划分为固定的活动，顺序衔接，运用于需求明确处理、简单应用系统

（2）线性迭代的过程模型：不完全顺序衔接

（3）迭代式的过程模型：复杂的迭代、并发和互相交织的关系

常见三个模板：过程说明模板、活动说明模板、技术说明模板

4.2.2 选择工作组件

1.各个需求工程活动需要使用的实践方法和技术；

2.需要使用的支持工具，包括管理工具、建模工具以及各种实践方法要求的工具；

3.执行过程所需要的资源支持，包括可以重用的资源、文档的模版、错误的检查清单等等； 4.执行过程所需要的项目策略支持、过程指南以及各种工作组件的使用帮助。

4.3过程改进 

PDCA模型（Plan-Do-Check-Action）

 五、需求工程中的项目管理

 5.1需求工程中的项目管理

项目管理：围绕着项目计划而执行的各种项目活动

5.2资源支持 

5.3生命周期规划

（1）瀑布模型

（2）增量模型

优点：采用逐步增量和多次发布的方式减少每一次实现的需求范围，降低需求实现的风险，需要可靠的需求基线。软件的问题域比较复杂，但是业务非常成熟而且需求比较稳定

缺点：需求易变或问题域信息很难一次处理完整时并不适用，不利于用户的有效参与。

 （3）领域模型

 （4）原型模型

优点： 问题域不成熟，业务活动仍然在不断发展和改变 能够很好的解决各种不确定性

缺点： 提高了需求工程阶段的成本，而且易于发生各种原型风险

5.4团队管理 

• 组建需求团队
• 维持需求团队内部的有效沟通

5.5需求风险管理

 风险产生的原因是对未来不利事件的不确定性

包含5个活动※

5.5.1风险管理过程的活动

1.风险识别

• 常用方法是建立风险条目的检查表，逐一比照进行项目的风险识别
• 另一个常用方法是驱动因素分析，建立决策模型，推导出可能的风险
• 工作分解也是常用方法，建立工作分解和网络图，

2.风险分析

风险分析的特征：       不确定性、损失、严重性、期间、优先级

3.制定风险管理计划

包括3各方面： 风险回避/缓解策略、风险监测、风险应急计划

4.风险跟踪

5.风险控制

5.5.2需求风险管理※

风险驱动因素		应对策略
类别	示例	类别	示例
需求复杂性	系统的规模比较复杂 系统的环境比较复杂 涉及的技术比较复杂	需求建模技术	形式化建模技术，例如KAOS 建模方法学，例如UML 特殊技术，例如ERD、DFD
需求稳定性	任务复杂，有着比较大的可变空间 业务领域不稳定 系统需要解决的问题不稳定 业务领域有不确定性 系统需要解决的问题有不确定性 系统的环境约束有不确定性	需求探索技术	迭代式需求开发，例如原型法 协作式需求开发，例如JAD
需求可得性	系统用户的数量众多 缺乏用户参与 需求团队的组织存在缺陷 需求团队地理分散	需求获取技术	面谈、原型、观察等等