【系统分析师之路】第六章 需求工程记忆敲出Part1

【系统分析师之路】第六章 需求工程记忆敲出Part1

一. 什么是软件需求

干系人或客户对系统的功能，性能，行为，设计约束等方面的期望。
而收集需求就是收集项目干系人对项目的期望的过程。

二. 软件需求的两个维度以及两者之间的联系

软件需求分为：需求开发和需求管理这两个维度。
需求管理可以用来支持需求开发，需求开发形成需求基线，基于需求基线才可以进行各种需求管理活动。
也就是需求开发和需求管理是通过需求基线联系在了一起。
所有的需求管理都是基于需求基线来开展的。

三. 软件需求开发的四个过程

需求开发又可以分为需求收集，需求分析，需求定义和需求验证这四个过程。其中需求定义过程中重要的输出：SRS，也就是系统规格说明书，这个规格说明书经过评审以后，就可以形成项目的基线。
在需求开发的四个过程中，需求收集和需求分析过程比较重要。
需求开发的四个过程不是瀑布式的关系，而应该是演化迭代的关系。
比如在需求分析之后，找出了我们在收集需求中的不足，那么接下来我们再回到需求获取阶段，重新改善并获取需求。

四. 需求的常规分类

需求按照常规方式可以分为三类：业务需求，用户需求，系统需求。而系统需求又包括了功能需求，非功能需求和设计约束。
业务需求是站在整体全局的高度来描述，抽象感越高，就越容易定位为业务需求。从项目管理的角度看，项目章程中说明的项目概要应该就是业务需求。
用户需求是用来描述用户对信息系统的具体期望。
系统需求的关键字是计算机化的需求，也就是咱们开发人员角度看到的需求。开发人员如何去看需求？这个时候可以联想到4+1视图。
功能需求可以通过UML用例来表示，非功能需求往往需要结合场景来说明其具体内容。
其中性能，可用性等就是非功能需求的指标，非功能需求往往可以用具体的数字化的指标来说明。
PIECES框架就是用来描述系统的非功能需求的一个框架。
设计约束更加容易理解，比如用户希望我们在建设信息系统时，会特意要求我们使用什么数据库，什么开发语言，那么这就是设计约束。

五. 需求基线和范围基准

需求基线是经过批准的SRS需求规格说明书，是联系需求开发和需求管理的纽带。
范围基准是经过批准的项目范围说明书，WBS和WBS词典。
虽然书本上没有给出这两个概念的联系与区别，但在我看来，有了需求基线之后，才可以更好的进行项目的变更管理，需求跟踪管理，版本管理和配置管理。而范围基准最主要还是为了防止范围的蔓延，可以使用范围基准作为范围纠偏的参照。

六. QFD对需求的分类

QFD对于项目的需求划分为三个分类：常规需求，期望需求和兴奋需求。
常规需求就是最为普通的需求，包含了客户干系人对信息系统项目最最基本的期待，一般会表现在SRS中。
期望需求就是客户没有明确说明，也没有明确表达的需求，对于这些需求，往往客户是想当然觉得应该要有得，不需要特地说明的，当然还有一种可能就是用户不够专业无法精确地叙述和表达的需求。
期望需求是隐含的需求，往往系统分析师和客户干系人在这里会产生认知上的偏差。
期望需求是系统分析师特别要留意的需求，不管是哪种情况只要对应了期望需求，干系人对咱们的满意程度会大大提高。
意外需求：也叫兴奋需求，这种需求是我们需求避免对应的，也许对应了以后会让客户会让干系人眼前一亮，但客户干系人不会因为你对应了意外的需求而给你增加开发费用。质量镀金就是意外需求。

七. 需求获取的概念和方法罗列

需求获取等同于范围管理中的收集需求。而且两者很多工具与技术也是一样的。
需求获取可以用到的工具和技术有很多种。
需求获取的技术包括了：用户访谈，问卷调查，现场观摩，历史文档分析，联合需求会议，抽样调查等。

八. 用户访谈技术

用户访谈是最为常见的需求获取方式，就是直接找干系人单独或1对2，1对3地聊天，从聊天沟通中去获取需求。
用户访谈的成本往往比较高，它看似简单但在实际工作中使用的话，还是要注意以下的事项才可以。
首先在访谈对象的选取上，最好选择那些有代表性的干系人来做访谈，比如销售，客服等各个职位选取一个有代表性的干系人来做访谈比较好。不同阶层的人都要选到，不然收集上来的需求是有片面性的。
其实在访谈之前对于自己在会议上要问什么问题要有一个充分的准备，条件允许的话，重要的访谈记录要留下议事录，还有可以使用录音等方式，方便以后反复听。
最后在设计问题的时候也要注意问题的开闭原则，懂得什么时候问开放式问题，什么时候用封闭式问题发问，这是一种技巧。值得我们系统分析师在用户访谈之前好好的琢磨。

九. PIECES框架

PIECES框架是获取系统非功能需求分类的一个常用的框架。六个字母分别代表了六个获取需求的维度。以下六个非功能需求需要学会区分。这个知识点需要达到的目标是能够活用。

1. P(Performance)性能：简单来说就是需求的工作效率。这里可以引申出信息系统性能评价章节的内容来了。比如平均无故障时间和平均故障修复时间就可以归类于此类。吞吐量也是性能的一种。
2. I(Information)信息：这里的信息指的是信息的质量。这里主要包括了该需求的输出输出和加工信息。
3. E(Economics)经济：成本效益分析就是对于需求获取的一种方式，如果一个需求在经济上对应不划算，那么该需求或许在是否需要变更的途中，就可以被排除了。
4. C(Control)控制：这里的控制更多的体现在了需求的安全性方面。比如加密和访问控制的需求，应该就可以把这类需求归类于非功能的控制需求。
5. E(Efficiency)效率：企业人，财，物的使用效率。
6. S(Service)服务：跟新系统对接时的容易程度。

十. 问卷调查技术

问卷调查的特点是受众广，如何巧妙的去设计是一个很重要的问题。它最害怕的就是问卷调查的时候数据结果的失真。
首先问卷调查和用户访谈一样，涉及到问题设计。选择有代表性的开放或封闭问题对于需求获取的结果是很有用的。
有些时候往往干系人会背着良心回答问题。但凡出现了这两种情况，那么信息就失真了。
在现实生活中，也会有你填写一个问卷调查表，给你一个小礼物；或者你购买了某商品后，写反馈给红包等。
这些都属于问卷调查的形式，但多多少少都有自己自身的不足。
怎么更好的使用问卷调查技术呢？对策：采用不记名的方式实施问卷调查，采用侧面提问的方式来获取信息都是很好的需求获取的实践。

十一. 需求风险

和其他项目管理过程一样，在收集需求，分析需求，定义需求的时候，会出现各种想象得到也有想象不到的问题，我们把这类问题归类于需求的风险。我能想到的常见的需求风险有：
需求风险的管理其实也是风险管理的很重要的一部分。

1. 无法从干系人这里全面获取需求的风险
2. 对应兴奋需求(质量镀金)而导致的成本增加的风险
3. 未充分识别期待需求而导致质量不足返工的风险
4. 需求没有验证导致后期出现扯皮的风险
5. 需求反复更改变动导致成本增加的风险
6. 公司领导管理层不重视需求工程的风险

• 国内公司不重视的内容：需求分析阶段和质量控制阶段。就像CMMI提出来就是为了节约成本为目的的。这也可以理解为事业环境因素对于收集需求的影响。

十二. 干系人与需求

当涉及到干系人利益冲突，干系人利益博弈的时候，干系人客户往往会阻碍我们收集分析需求，这个时候我们就需要找到能够推动项目前进的关键的项目干系人，因为信息化系统建设本来就是一把手工程，只有一把手才可以K掉任何的阻力。

十三. 其他需求获取技术

情节串联版：构造一系列图片，然后用图片去讲故事。这个让人莫名的想到了原型化开发方法。
现场观摩：针对的是较为复杂的流程工作，想把复杂的流程搞清楚，亲力亲为是必须的。换位思考一下，不身临其境的去体验用户流程中用户的痛点，怎么可以开发出能够解决客户与干系人问题的信息系统呢。
阅读历史文档：获取数据型的东西。这个其实就可以理解为组织过程资产在项目需求收集阶段的活用。
联合需求会议JRP：需要召集各方干系人一起参与的一个会议。也是成本最高的一种获取需求的工具与技术。
抽样调查分析：抽样的目的就是为了找有代表性但成本又低的方法。这里涉及到可信度系数：它是数学维度的东西。
###十四. 联合需求开发会议和相关工具的比较
联合需求开发会议：会议的参与人数在6-18人，召开时间1-5小时，开会之前提前分发资料，会开始前要破冰，要发挥群体创新技术和群体决策技术。是适用于软件领域的引导式研讨会。
焦点小组：需要有主持人，参加人数控制在6-10人，与一对一的用户访谈相比，更加容易获取到真正有价值的需求
引导式研讨会：邀请各方专家来参加，跨职能，需要在会议上达成一致的意见。
引导式研讨会的典型实例是软件行业的联合应用开发（JAD）和制造行业的质量功能展开（QFD）。在敏捷开发中，用户故事（User Story）也是引导式研讨会的具体应用。
德尔菲：专家参与，背靠背匿名投票，避免专家之间相互影响。
名义小组：需要头脑风暴，需要使用投票的方式排序选择需求方案。专家是面对面发表意见，然后在通过投票等方式决策。
联合需求开发是引导式研讨会的一种，它也是重点强调需要达成意见的一致。

十五. 需求定义

找到需求以后，还要解决相应的问题，解决需求获取和分析过程中产生的相应的冲突。它有两种定义的方法：一个是严格定义法，一个是原型法。原型法不同于严格定义法的地方是原型法强调多轮迭代定义需求，定义完成需求后，就形成了需求规格说明书。

十六. 需求验证的概念

它包括了两个方面，一个是需求评审，另一个是需求测试。
需求评审：正式评审和非正式评审。
需求测试就是使用设计好的测试用例来做一些验证型的工作。它不是真正意义上运行的测试，而是使用测试用例进行一些验证和辅证的工作。
它的作用就是验证我们开发方向对不对，而不是验证具体需求对于不对。
需求验证中需求的签名确认是非常重要但也是比较难实施的地方。毕竟签名就代表需要对需求附负责，所以在现实中，愿意配合我们验证需求的客户，是少中又少。
需求验证的内容也可以放到范围确认的时候去进行验收。

十七. 需求跟踪矩阵

需求具有以下的特点：可跟踪，可验证。如果不满足这些特点的需求，那么就可能有问题了。
需求跟踪矩阵可以表示用户原始需求，软件产品需求和下游实现的需求这三者之间的关系。
跟踪可以分为正向跟踪，也可以有逆向跟踪。从用户的原始需求到下游工作产品的需求跟踪是正向的跟踪；同理从下游产品回溯到初始需求的就是逆向跟踪。
通过需求跟踪矩阵，我们可以发现需求是否有遗漏的情况，也可以判明我们的系统中是否有质量镀金的情况发生。

十八. 需求管理的内容

建立需求基线，建立需求跟踪能力链，保证用户原始需求与产品实现功能的一致性。

十九. 需求的六种状态

需求的六种状态分别是：新增加，已完成，已批准，已取消，已分配，已推迟。
发生变更申请的时候，需求状态为：新增加
需求已经对应完成，并通知了相关干系人后：已完成
一个需求提出来后，作为变更被CCB否决了：已取消
一个需求提出来后，被CCB决策要做了：已批准
一个需求没有在预定的时间做完：已推迟
一个需求被CCB决策做了以后，给它分配了资源并决定由谁来做：已分配