一、需求获取概述

1.1相关概述

软件需求获取是软件工程的主体。

主要表现为：发现问题->分析问题->解决问题的过程。

需求获取阶段主要产生的文档：1.前景和范围文档 2.用例说明文档

1.2主要内容

1.2.1需求获取的非平凡性

用户和开发人员的背景不同，立场不同

普通用户缺乏概括性、综合性的表述能力

获取的内容主题，然后设计具体的应用环境和场景条件

用户存在认知困境

缺乏用户参与相关涉众进行分析

1.2.2需求获取的活动过程

子活动过程描述

1.2.3需求获取活动的要点

1.获取的内容

2.获取的来源

3.获取的方法

4.获取的过程

5.获取的结果

获取的内容

1.需求 系统期望达到的目标，来源于用户的观点、看法、目标或者问题

2.问题域描述 现实世界的业务运行状况

3.环境与约束 限制解系统部署的环境和条件

获取的内容不是一次得到的，而是逐步积累的

获取的来源※

1.涉众

2.硬数据登记表格、单据、报表等定量文档备忘录、日志等定性文档

3.相关产品

4.重要文档

5.相关技术标准和法规

补充信息系统的四种类型

1.小型系统        涉众有限且明显‘

2.组织级系统        用户不再有限和明显，而且用户之外的其他群体尤其不明显

3.战略信息系统        涉众数量更多而且更加难以确定

4.组织间系统        涉众比组织内系统的涉众更加难以寻找和选择

涉众分析过程——步骤：

1. 涉众识别（发现所有关键类别，识别方法）

2. 涉众描述

3. 涉众评估

4. 涉众代表选择

5. 涉众参与需求开发（软件系统）的参与策略

涉众识别

涉众分析就是为软件系统寻找并理解关键涉众的过程

业务需求

涉众描述

涉众评估（3种）

1.优先级评估 2.风险评估3. 共赢分析

优先级评估

优先考虑涉众的基本特征，尤其是任务特征数值越大，优先级越高

风险评估

化解涉众风险策略

共赢分析

它关联的涉众就在该Issue的问题上和项目整体目标存在冲突

涉众选择

1.代表采样

2.用户替代源 因为业务关系而与用户频繁接触的人

涉众参与策略

敏捷方法——用户参与

建立开发者和用户的直接联系用户参与需求开发和软件系统开发的整个过程

1.2.4硬数据类型

在研究现有系统时，需求工程师获取事实，理解问题域所依赖的文档资料即使硬数据

1.定量硬数据

定量数据：经过仔细设计、具有严格要求的格式化文档。

2. 定性硬数据 定性的硬数据大都采用自然语言进行文本描述，利用起来代价较大，包括3种

整个组织的描述文档业务指导文档业务备忘

1.3获取的方法

1.传统方法

问卷调查、面谈、硬数据分析、文档检查

2.集体获取方法

头脑风暴

3.原型

适用于需求模糊和不确定性较大的情况

4.模型驱动方法

面向目标的方法、基于场景的方法、基于用例的方法

5.认知方法

6.基于上下文的方法

二、确定项目的前景和范围

2.1确定项目前景和范围的活动

系统的业务需求系统的高层解决方案及其功能特性

1.定义项目前景文档 描述产品是用来描述产品的作用，最终的功能。它使所有的涉众都从共同认同的项目前景出发，理解和描述问题域及需求

2.定义项目范围文档 指出当前项目是要解决的产品是长远规划中的哪一部分。它为项目划定了需求的界限。

2.2问题分析

2.2.1明确问题

1.对问题达成共识

2.收集背景资料，判断问题的明确性

3.分析不明确问题，发现问题背后的问题

用鱼骨图列出所有的可能原因

如果用户无法确认，则搜集数据（帕累托图）进行分析

2.2.2发现业务需求

每一个明确、一致的问题都意味着涉众存在一些相应的期望目标，即业务需求。

业务目标要具有第二章所述的各种优秀特性，尤其是要有可验证性（完整性、正确性、可行性、必要性、无歧义）

2.2.3定义解决方案及系统特性

1.确定高层次的解决方案

2.确定系统特性和解决方案的边界

（1）系统特征

具备的功能特征，即系统特性

定义解决方案的边界。

（2）面向对象方法

用例图和上下文图

（3）结构化方法的问题解决方案边界——上下文图(环境图) 也称系统关联图

3.确定解决方案的约束

2.3定义系统边界

系统边界是系统与环境交互的界限

系统边界是需求工程后期阶段需求分析活动的起始模型

将所有问题的解决方案进行综合，就可以得到整个解系统的功能和边界

系统边界的常用技术描述手段是系统用例图和上下文图

2.4项目前景和范围文档

1.业务需求、高层次解决方案和系统特性都应该被定义到项目前景与范围文档之中

2.项目合约或抽象的业务用例文档也可以实现类似目的

三、面谈

3.1问题的类型

1.开放式问题面谈前期

开放和不受限制

2.封闭式问题面谈后期

被会见者的回答是受到限制的

补充其他重要的问题类型

（1）探究式问题：目的是深究答复为什么？你能举个例子吗？你能详细描述一下吗？

（2）诱导性问题：引导被会见者按会见者所想来回答，答复有偏向性 “你和其他经理一样，都同意把财产管理计算机化，是吗”

（3）双筒问题：一个问题包含两个独立的内容，效果差 “每天你通常会做什么决策，你是怎样做的？”

（4）元问题：关于面谈本身的问题，对实施需求有很大帮助我的问题看起来相关吗？

3.2问题的组织：面谈结构

三种基础结构※ 金字塔型漏斗型菱形

（1）金字塔结构

如果会见者认为被会见者需要对话题进行预热，可以采用金字塔结构，通过逐步的引导来使得被会见者打开话匣子。

如果会见者发现自己事先对事实的确认存在较大偏差或者被会见者看上去不情愿讨论这个话题，也可以采用金字塔结构。

当想结束讨论这个话题的时候，使用金字塔结构的提问顺序也是有用的。

（2）漏斗结构

漏斗结构为开始一场面谈提供了一种容易而轻松的途径。

当被会见者对这个话题有情绪，并且需要自由表达这些情绪的时候，需要采用漏斗型提问顺序。

或者在会见者事先对事实了解不多时，也应该采用漏斗结构的问题组织方式。

用这种方式组织面谈能得出很多的详细信息，以致于没有必要使用长序列的受限制问题和调查问题。

（3）菱形结构

优点通过各种问题保持被会见者的兴趣和注意力。一旦掌握了如何在正确的时间问正确的问题，就可以多样地选择问题的顺序。

3.3面谈的过程

记录的方式（1）笔录（2）录音和摄像

完成面谈报告

3.4面谈的类型※

1.结构化面谈

安全按照事先的问题和结构来控制面谈

2.半结构化面谈

事先需要根据面谈内容准备面谈的问题和面谈结构，但在面谈过程当中，会见者可以根据实际情况采取一些灵活的策略

3.非结构化面谈

3.5面谈的优点和局限性※

面谈的优点有：开展条件较为简单，经济成本低；

缺点和局限性包括：1.面谈比较耗时，时间成本较高

2.面谈的成功较高的依赖于需求工程师的人际交流能力

3.在会见者不了解被会见者认知结构的情况下，面谈不可能取得令人满意的效果。

补充：群体面谈

四、调查问卷

以文档为主要的交流媒介

适用调查问卷的情况系统的涉众在地理上是分布的；

系统的涉众数量众多，而且了解所有涉众的统计倾向是非常重要的；

需要进行一项探索性的研究，并希望在确定具体方向之前了解当前的总体状况；

为后续的面谈标识问题和主题，建立一个开展工作的基础框架。

头脑风暴

自由思考和自由讨论

包括两个阶段想法产生阶段想法精减阶段

目的是产生出尽可能多的新的想法

五、原型

5.1应用原型的必要性

原型是一个系统，它内化了（capture）一个更迟系统（later system）的本质特征

中间物件

包括书面描绘、场景叙述、情节串联图板、幻灯演示、动画模拟、屏幕快照和程序代码等在内的各种被用来探索和论证软件系统功能的物件都是软件的原型

利用原型的好处有：

1.及时、有力的响应用户需求的变化；

2.帮助控制不完整需求所带来的风险；

3.提高用户在软件开发中的参与程度。

5.2原型的类别

方式1：按照使用方式分类

(1)演示原型（presentation prototype），如Demo 主要被用在启动项目阶段

(2)严格意义上的原型（prototype proper）主要被用在需求分析阶段

(3)试验原型（breadboard prototype）主要被用在构建系统阶段

(4)引示系统原型（pilot system prototype）会被用在系统开发的各个阶段用作最终系统的构建核心，在后续的开发中被不断增强

方式2：按照开发方法分类※

1.探索式（exploratory）以缺陷需求开始继而不断调整和修正需求的原型开发方式称为探索式

2.实验式（experimental）以清晰的用户需求和模糊的实现方法、实现效果、可行性开始，明确需求的可行性和技术实现方案

3.演化式（evolutionary）以清晰的原型化需求和项目积累下来的原型资产为开始被不断传递和不断增强的原型资产将成为最终的软件系统

补充

探索式和实验式方法产生的原型产品又被称为抛弃式原型

演化式原型方法产生的原型产品被称为演化式原型

方式3：按照构建技术分类

水平原型方法（horizontal prototyping）

它仅仅实现选定功能所有层次中的某些特定层次建立的原型产品称为水平原型（horizontal prototype）要把注意力集中在概括性需求和工作流问题上，处理范围较大，但并未实现所涵盖的功能

垂直原型方法（vertical prototyping）它会触及到选定功能实现的所有层次建立的原型产品称为垂直原型（vertical prototype）要保证真实实现它的各种功能，考虑所有技术细节

补充

需求获取中使用的绝大部分原型都是水平原型。

需求获取水平原型关注的常见层次：人机交互、功能与任务和实现

方式4：按照介质分类

方式5：按照表现分类

故事版是交互性介于静态画面和动态程序之间的一种原型表现形式，它能够表现场景式的互动。

5.3.原型方法过程

（1）确定原型需求

（2）原型开发

（3）原型评估

（4）原型修正

5.3.1原型的需求内容

原型的需求内容可以从三个纬度上分析：外观（Look and Feel）、角色（Role）和实现

1)角色是指原型物件在用户工作中的价值，也就是说它为什么是对用户有用的。原型物件到底能够帮助用户完成什么样的工作

2)外观是指用户对原型物件的具体感觉体验，即用户在使用原型物件时会看到什么、听到什么和感觉到什么

3)实现是指原型物件完成功能的细节技术和方法

5.3.2原型开发

5.3.3原型评估

（1）可以创建一些脚本来指导评估者的体验活动（2）创造一个无偏见的环境，让评估人员畅所欲言（3）务必要让合适的人从恰当的角度来评估原型（4）观察评估人员使用原型的过程（5）需要获取的评估者反馈

5.3.4原型修正

一方面要依据评估人员的反馈另一方面也要考虑事先的原型调整计划

5.4原型方法的风险

最大优点：能够尽早解决系统开发中的不确定性，从而减少软件项目失败的风险

缺点：复杂性使它在减少风险的同时也引入了新的风险

1.最大的风险是成本失控。原型开发工作投入太多的工作，使得开发团队消耗了过多的时间和过大的成本。

2.第二个风险是给客户造成错误印象。涉众看到了一个正在运行的原型，得出产品几乎已经完成的结论，从而提出快速交付产品的不当要求。

3.第三个风险是用户可能会被原型所表现出来的非功能特性蒙蔽了眼睛，从而忽略了它们更应该重视的功能特性。

4.第四个风险是在澄清不确定性的同时也可能会掩盖一些用户假设，这些将会无从发现

六、观察和文档审查

6.1观察的情境适用性

观察法提供了除语言交流以外的交流形式。

（1）采样观察：

（2）民族志：长期、浸入式的观察方法。

（3）话语分析：

（4）协议分析：对用户任务的观察。

（5）任务分析：专门针对人机交互行为进行的观察。

6.2观察方法的应用

采样观察民族志

采样观察

民族志

6.3文档审查方法的应用

文档审查是传统的专门针对文档进行的需求获取活动。它的主要获取对象包括相关产品（原有产品或竞争产品）的需求规格说明、硬数据和客户的需求文档（委托开发的规格说明、招标书）

七、需求分析概述

7.1需求分析的根本任务

建立分析模型，达成开发者和用户对需求信息的共同理解

将复杂的系统分解成为简单的部分以及它们之间的联系，确定本质特征

分析的活动主要包括识别、定义和结构化，它的目的是获取某个可以转换为知识的事物的信息

依据共同的理解，发挥创造性，创建软件系统解决方案

7.1.1建立分析模型

建模方法抽象分解投影

两个世界与三种模型

（1）计算世界与计算模型（不适合需求建模）

需求分析阶段不适宜建立形式化的计算模型

（2）问题世界与业务模型（不适合需求建模）

使用了业务描述的方式，具有非形式化特征

非形式化特征使得它不适合于进行需求建模

（3）软件分析模型

介于计算模型和业务模型二者之间的模型形式使用了计算模型的组元形式在组元的表现上采用了业务模型的表现方式

模型的描述（3要素）语法：语义：语用：

模型、模型语言与表示法

需求建模

先依据获取的问题域信息建立初步的模型。

然后分析用户需求，对模型进行调整，得到一个中间形式的模型形式。

最后，对调整后的模型进行逻辑推理和验证，如果符合预期的期望，那么它就是最终的解决方案模型。

7.2建立解决方案

7.2.1常用需求分析技术

7.2.2需求分析技术的发展过程

7.3需求分析方法

（1）传统分析 没有方法 (1950’s) 依赖个体才智,依据个人习惯缺乏结构、不可重复、不可测量,冗长、混乱、偏颇、无结构等等

（2）结构化分析 传统结构化分析 (late 1960’s),现代结构化分析 (late 1970’s) 以数据流动为中心，以DFD为核心技术，辅助ERD… 信息工程 (late 1980’s) 以数据知识结构为基础，ERD为核心技术，辅助DFD，STD, FDD,…

（3）面向对象分析（1990‘s）以对象为中心，以UML（类图）为核心技术以全面思想革新为理想，以承继结构化技术为现实

7.4前期需求阶段的建模与分析

1.面向目标的分析（Goal Oriented Analysis通过关注前期需求阶段—项目的前景与范围定义活动进行目标分析）

2.面向问题域的分析（Problem Domain Oriented Analysis 面向问题域，关注问题的理解和建模）

3.领域分析 （代价不菲）

4.企业建模

7.5需求分析的活动

需求分析子活动有：

（前期）背景分析；问题分析；目标分析；业务分析；确定系统边界；

（后期）需求建模；需求细化；确定需求优先级和需求协商。

背景分析；问题分析；目标分析；业务分析；确定系统边界是以问题域为关注点的分析，属于前期需求阶段的分析活动建立前景和范围

其他需求分析子活动发生在获得需求信息之后，是后期需求阶段的分析活动。

7.5.1需求分析的活动

需求细化

需求细化的根本，是将从问题域和业务任务角度描述的用户需求转换为从软件和技术角度描述的系统级需求。

（1）需要将用户需求细化用户需求以任务为单位的，但一个任务完成可能需要多次交互。

（2）需要补充隐含因素将从问题域信息补充到系统需求中，这些需要补充的信息就是隐含因素。

（3）非功能需求也需要随着功能需求的细化而细化

（4）会发现新的细节需求这些细节往往是用于约束和限定解决方案的手段。

（5）在足够具体时停止。

确定需求优先级

1.需要确定优先级的情况：

2.确定优先级的常用方法

1）累计投票：按需求得到的总分值确定优先级（2）区域划分：评价优先级的常见特征：

需求协商

需求协商活动包括对目标冲突的处理，也包括对需求细节冲突的处理。涉众之间的人际互动是关键。

软件需求管理(二) 需求获取相关推荐

需求管理之需求优先级的排序-需求优先级分析方法论-波士顿矩阵和KANO模型
无论是在大公司还是在小公司,我们总会遇到事多人少的情况.想开发的需求很多,空闲的开发资源很少.需求都堆积成山了,拼命加班也完不成所有的事情.所以我们需要用到需求排序的一些方法论需求优先级分析方法论- ...
需求管理二：需求的建模与跟踪
(原创文章,欢迎转载,请注明出处) 上回说到需求分析的一些内容.这回我总结总结我对需求建模和跟踪方面方法. 需求也是有模型的,有很多UML语言支持需求的建模,它不是UML的标准视图,而是扩展的视图.我 ...
创业期的软件开发管理(二)
接上文创业期的软件开发管理(一) 软件队伍技术主管决策者对软件开发可能一知半解,他们会想当然地认为软件开发过程比较"简单":从市场上找一个技术带头人,然后组建一个开发队伍,其余 ...
linux文件需求管理,CaliberRM 需求管理系统
Borland CaliberRM™ 2006 是适用于整个软件交付过程管理的突破性解决方案. 设计用于捕获和管理业务.技术.功能和运营要求,CaliberRM 支持跨组织股东的有效协作,从而确保项目 ...
需求管理工具_DOORS和Reqtify — 需求管理和需求追溯工具
IBM Engineering Requirements Management DOORS(原名 IBM Rational DOORS) 可实现对整个产品的全生命周期需求管理,覆盖从需求.到设计以及测 ...
DOORS和Reqtify—需求管理和需求追溯工具
这里写自定义目录标题 IBM Rational DOORS可实现对整个产品的全生命周期需求管理,覆盖从需求.到设计以及测试阶段.是一款具有广泛使用的企业级专业需求管理工具.DOORS可以将项目开发过程 ...
互联网产品设计:产品需求管理之需求收集
需求收集是进行产品需求管理的第一步.需求收集得到的各种用户需求素材是产品需求的唯一来源.可以说需求收集的质量影响着产品最终的质量. 1.需求收集目的需求收集的目的在于:通过以市场为导向的客户需求收集 ...
linux 内核 mtd读取,MTD坏块管理(二)-内核获取Nandflash的参数过程
MTD坏块管理机制中,起着核心作用的数据结构是nand_chip,在此以TCC8900-Linux中MTD的坏块管理为例作一次介绍. MTD在Linux内核中同样以模块的形式被启用,TCC_MTD_I ...
中小企业的需求管理软件都有哪些
本文将盘点国内外10个适合中小企业的需求管理软件:1.PingCode:2.Worktile:3.Modern Requirements:4.Jama Software:5.Visure:6.Rati ...

软件需求管理(二) 需求获取

一、 需求获取概述