软件需求分析期末考试

需求基础

第二章从概念上让大家理解什么是需求，以及需求的研究目标是什么，研究对象是什么。
1 需求源于哪两方面？
用户的痛点和用户的期望
2 问题域与解系统
对问题域和解系统的理解，放图：

软件系统通过影响问题域，能够帮助人们解决问题，称为解系统
而需求工程师是问题域和解系统之间连接的桥梁和接口
3 需求的层次性（不考定义，需理解）

业务需求：对应解决方案等一些宏观性的问题。
用户需求：问题域的知识，业务流程，ER图等等。
系统级需求：建立一些细致的模型描述它。
这三步有一个逐步细化的过程，当时老师通过一个例子帮助我们理解。

业务需求比较宏观，将其分解成用户需求如下：

最后面对我们要开发的软件，我们实际上面对的是系统特性（system feature，SF）

4 需求的分类（不考定义，但要了解）
功能需求（Functional Requirement）：
和系统主要工作相关的需求，即在不考虑物理约束的情况下，用户希望系统所能够执行的活动，这些活动可以帮助用户完成任务。功能需求主要表现为系统和环境之间的行为交互。
性能需求（Performance Requirement）：
系统整体或系统组成部分应该拥有的性能特征，例如CPU使用率、内存使用率等。
质量属性（Quality Attribute）：
系统完成工作的质量，即系统需要在一个“好的程度”上实现功能需求，例如可靠性程度、可维护性程度等。
对外接口（External Interface）：
系统和环境中其他系统之间需要建立的接口，包括硬件接口、软件接口、数据库接口等等。
约束
进行系统构造时需要遵守的约束，例如编程语言、硬件设施等
软件需求说明书就是对各种需求一个概括和规整

需求工程过程

需求获取：输入的是用户需求、期望和问题
·需求分析：UML那些东西
·需求规格说明：最主要的是写好需求规格说明文档
·需求验证：要是有问题，就反过头看到底是哪个阶段出问题了。

需求获取

1 需求获取中的常见困难
（1）用户和开发人员的背景不同，立场不同
（2）普通用户缺乏概括性、综合性的表述能力
（3）用户存在认知困境
（4）用户越俎代庖
（5）缺乏用户参与

明确问题

解决方案

活动图

实例

涉众分析与硬数据采样

1. 如何进行涉众分析？不同类型信息系统，不同的方法

组织级系统（Organization-Wide System）

分析组织内各类人群的互动关系

战略信息系统（Strategic Information System）

分析组织内各类人群的互动关系
各种风险/机遇对既有互动关系的影响

组织间系统（Inter-Organizational Systems）

分析组织间的互动关系
分析关系到组织间互动的各类人群在组织内的互动关系

补充：大众型产品 例如：搜索引擎、电子商务、移动互联网应用等等

分析产品定位人群（用户）
产品功能在用户社会关系网中的关联作用
分析用户与社会关系的互动

问题域(Problem domain)”指提问的范围、问题之间的内在的关系和逻辑可能性空间。软件工程:在软件工程中,问题域是指被开发系统的应用领域,即在客观世界中由该系统处理的业务范围

2 涉众分析过程

** 基于涉众扩展特征进行涉众优先级的评估**

3. 识别涉众的方法

简单方法：先膨胀后收缩(Expand  Shrink)
经验方法：检查列表（Checklist）
经典方法：涉众网络

简单方法：先膨胀后收缩(Expand - Shrink)
①膨胀。
在该阶段，需求工程师在收集到背景资料后，凭借自己的经验，尽可能多地列出涉众类别，越多越好。
②收缩。
在该阶段，需求工程师判断是否有两类或多类涉众的立场是一样的，将一样的多个类别进行合并。

优点简单易用。
如果涉众群体比较复杂，可能会出现遗漏.

检查列表：经典列表
用户: 最终使用和操作产品的人
关注软件功能，主要信息来源
客户: 为软件系统的开发付费的人
关注经济上的成本、收益
开发者: 负责实现软件系统的人
关注技术上的成本和收益，可行的需求
管理者：参与软件系统开发事务管理的人
投资方管理者、执行负责人、项目管理者
关注系统的开发进程

优点：容易操作，如果经验丰富会比较有效
缺点：有些类别太粗，尤其是用户作为一个类别是远远不够的

检查列表：经典列表
领域专家：在问题域中具有丰富知识的专家
关注软件中的知识，问题域分析
政府力量：法律法规、长远规划、政策意向等
起约束和指导作用
市场力量：组织中的市场部门人员
关注用户的想法
维护人员：系统的非功能属性
例如质量

涉众网络：

从一些比较容易发现的涉众出发，通常包括客户、管理者和相关的投资者
由初始涉众集体讨论，列出一个涉众类别列表
对上一步产生的涉众类别列表进行分析，缩减为一个关键涉众类别列表
由上一步的各个关键涉众类别选择代表，集中讨论，列出新的涉众类别列表
如果涉众类别列表趋于稳定，就结束涉众识别过程，否则转向第2步

优点：适用于复杂情况下的涉众识别，保障正确性和完备性缺点：比较麻烦，反复召集涉众进行讨论

涉众描述

硬数据

什么是硬数据？

实际工作中产生的表格、文档资料
是一种精化过的知识
可用于获取事实，理解问题域

用例图

为什么需要用例和场景

需求获取方法 —— 面谈

问题基本上可以分为两种类型：开放式问题和封闭式问题
开放式问题（Open-Ended）
封闭式问题（Closed）

开放式问题：
被会见者对答复的选择可以是开放和不受限制的，他们可能答复两个词，也可能答复两段话。
在希望得到丰富（具有一定深度和广度）信息时，开放式问题比较合适
例如：
“你觉得把所有的经理都置于一个内联网内怎么样？”
“请解释你是如何做进度决策的？”
“对公司中企业对企业电子商务的当前状态有何看法？”

开放式问题的优缺点：
优点：
让被会见者感到自在；会见者可以收集被会见者使用的词汇，这能反应他的教育、价值标准、态度和信念；
提供丰富的细节；对没采用的进一步的提问有启迪作用；让被会见者更感兴趣；容许更多的自发性；会见者可以在没有太多准备的情况下进行面谈
缺点：
提此类问题可能会产生太多不相干的细节；
面谈可能失控；
开放式的回答会花费大量的时间才能获得有用的信息量；
可能会使会见者看上去没有准备。

封闭式问题：
答案有基本的形式，被会见者的回答是受到限制的
例如：
“项目存储库每个星期更新多少次？”
“电话中心一个月平均收到多少个电话？”
“下列信息中哪个对你最有用：（1）填好的客户投诉单；（2）访问web站点的客户的电子邮件投诉；（3）与客户面对面的交流；（4）退回的货物。”
“列出头两项需要优先考虑的改善技术基础设施的事项。”

优点：
节省时间；
切中要点；
保持对面谈的控制；
快速探讨大范围问题；
得到贴切的数据
缺点：
使得被会见者厌烦；
得不到丰富的细节；
出于上述原因，失去主要思想；
不能建立和面谈者的友好关系。

面谈的阶段

面谈的优点

群体面谈和单一面谈比较（优缺点）

和一对一的面谈相比，有如下优点：
通过集中讨论，充分利用了交流时间，因此比一对一面谈更加节约时间，有着更低的时间成本。
群体面谈往往是在一个集中连续的时间内完成，和一对一面谈的间隔性特点相比，能够加速项目的开发进展。
群体面谈中，涉众方可以直接交流，和一对一面谈的以开发者为中介进行交流相比，提高了冲突处理能力。
群体面谈的集中讨论具有明显的以用户为中心的特征，降低了开发者在面谈中的主导作用，这里可以提高涉众的项目参与度，减少开发者主导需求获取时的弊端。
群体面谈集中了所有参与者的智慧，所以常常会有创造性的信息内容产生

和一对一的面谈相比，也有如下缺点：
群体面谈要求所有参与方都要在一个集中的时间抽出大量时间和精力投入面谈，这往往难以实现
群体面谈获得的信息比和一对一面谈要复杂得多，因此对他们的分析是一个不小的技术挑战。
主持群体面谈比主持一对一面谈要困难得多

其他方法：

1）调查问卷
2）头脑风暴

问卷调查相对于面谈和群体面谈来说更适用于哪方面？
涉众不易获取，人多的时候

需求获取方法—原型

需求获取方法 —— 观察和文档审查

文档审查（需求获取最后一部分）

需求分析

初始状态、终止状态、状态、转移、守护条件、事件、动作

书写SRS

2 写SRS的时候有什么要求
·保持语句和段落的简短。
·采用主动语态的表达方式。
·编写具有正确的语法、拼写和标点的完整句子。
·使用的术语与词汇表中所定义的应该一致。
·需求陈述应该具有一致的样式，例如“系统必须⋯⋯”或者“用户必须⋯⋯”，并紧跟一个行为动作和可观察的结果。
·为了减少不确定性，必须避免模糊的、主观的术语，例如，用户友好、容易、简单、迅速、有效、支持、许多、最新技术、优越的、可接受的和健壮的。当用客说“用户友好”或者“快”或者“健壮”时，你应该明确它们的真正含义并且在需求中阐明用户的意图。
·避免使用比较性的词汇，例如：提高、最大化、最小化和最佳化。定量地说明所需要提高的程度或者说清一些参数可接受的最大值和最小值。当客户说明系统应该“处理”、“支持”或“管理”某些事情时，你应该能理解客户的意图。含糊的语句表达将引起需求的不可验证。

需求验证

需求验证的方法

软件评审会议

审查参与者必须代表三个方面的观点：

·产品的开发者及其可能的同组成员编写需求文档的分析员。
·先前产品的开发者或用户领域代表可能是一个系统工程师、领域专家等
·要根据正在审查的文档来开展工作的人们可能包括一个开发人员、一个测试人员、一个项目经理和一个用户文档编写人员

·参与者应限制在7个人左右或者更少

需求管理

需求基线

需求变更原因

1 需求理解分歧
2 系统开发实施周期过长
3 客户业务需求改变
4. 国家政策改变
5. 需求有缺陷

需求变更影响

1 项目成本
2 影响软件质量及开发进度
3 影响人员的工作状态
4 影响文档和代码的一致性
5 影响开发者和用户的合作关系

需求变更的成本（同上）

1：项目成本
如果项目有需求变更，那么就需要安排专门的人员进行开发、测试、部署等工作，这样就增加了项目的成本。
2：影响软件质量及开发进度
在一个复杂的软件系统中，需求之间具有一定的联系，而相关的需求则构成需求链，如果评估变更影响时遗漏了需求链中的某些环节，就可能在实施变更过程中引入一些难易察觉的错误，这些错误将会影响系统的质量，严重时可导致系统崩溃。
3：影响人员的工作状态
如果需求变更频繁或者需求变更对系统影响比较大，会导致开发、测试人员在心理上产生抵触信息，从而影响其工作状态。严重时可能会导致人员的流失。
4：影响文档和代码的一致性
文档是软件系统的一个重要组成部分，也是维护系统的重要依据。在处理需求变更的过程中，如果没有采用规范的流程保证需求变更的评估与实施，会造成文档跟所开发的软件系统不一致，系统维护困难。
5：影响开发者与用户的合作关系
需求变更的实施时用户和开发者相互协作的过程。开发者和用户在是否采用变更问题上常常产生分歧，如果没有恰当的处理，相互之间的信任关系变得越来越差，甚至有合作关系转变为一种对抗关系，影响项目开发进度。

需求变更控制——基本原则

需求一定要与投入（成本）有显式的联系
否则如果需求变更的成本由开发方来承担，则项目需求的变更就成为必然了。软件开发方和出资方都要明确这一条：需求变化，软件开发的投入也要变化。

需求的变更要经过出资者的认可
这样才会对需求的变更有成本的概念，能够慎重地对待需求的变更

即使小的需求变更也要经过正规的需求管理流程，否则会积少成多。

精确的需求与范围定义并不会阻止需求的变更。并非对需求定义的越细，越能避免需求的渐变，这是两个层面的问题。太细的需求定义对需求渐变没有任何效果。因为需求的变化是永恒的，并非由于需求细化了，它就不会变化了。

如果开发团队缺少明确的需求变更控制过程或采用的变更控制机制无效，抑或不按变更控制流程来管理需求变更，那么很可能造成项目进度拖延、成本不足、人力紧缺，甚至导致整个项目失败。

当然，即使按照需求变更控制流程进行管理，由于受进度、成本等因素的制约，软件质量还是会受到不同程度的影响。但实施严格的软件需求管理会最大限度地控制需求变更给软件质量造成的负面影响，这也正是我们进行需求变更管理的目的所在。

变化不可避免，我们应该怎么办？