【软考】信息系统开发基础 - 需求分析与需求工程_软考需求分析方法

一、需求分析入门介绍

1.1 软件需求定义

是针对待解决的问题的特性的描述，所定义的需求，必须可以被验证。
在资源有限时，可以通过优先级对需求 进行权衡。

1.2 需求分析的目的

确定系统必须要完成哪些工作，对目标系统提出，完整、准确、清晰、具体的要求

1.3 谁来做需求分析？

根据项目的复杂情况，需求分析的工作可以由专门的系统分析人员来做，也可以由项目经理带领技术人员完成。

1.4 需求分析为什么重要？

（1）许多大型应用系统的失败，最后均归结到需求分析的失败。
（2）需求分析的输出文档《用户需求分析》即使软件生产周期中的第一个里程碑，又是客户、软件开发人员和项目管理人员三者必须遵守的一根基线，是三者共同工作的基础，是项目Alpha测试和Beta测试的准则，是供方交付产品和需方验收产品的依据。
（3）需求分析要占整个软件开发时间或工作量的30%左右。
（4）需求获取中的错误属于软件开发早期错误，它会在后续的设计和实现中进行发散式传播。

1.5 需求获取为什么难？

（1）用户需求具有动态性
（2）用户需求具有模糊性
（3）开发者和用户要对需求达成完全一致的认识，用户要在需求报告上签字，要承担责任。
（4）中国的国有企业正处于变动期，中国的民营企业正处于成长期，造成需求不成熟、不稳定和不规范，增加了难度系数。

二、需求分类（技术维度）

软件需求是多层次的，需求是用户对新系统在功能、行为、性能等方面的期望。

2.1 业务需求

• 系统高层次目标
  • （反映了企业或客户对系统层次的目标需求）
  • （通常来自项目投资人。购买产品的客户、客户单位的管理人员。市场营销部门或产品策划部门）
• 反映客户高层次的目标要求，通常由项目投资人，客户提出。

2.2 用户需求

• 用户视角
• 用户需求描述的是用户的具体目标，或用户要求系统必须能完成的任务
• 描述了用户能使用系统来做些什么。

2.3 系统需求

• 系统的角度看问题
  • 功能需求
  • 性能需求（非功能性需求）
  • 设计约束

三、需求分类（PM/管理维度）

• 质量功能部署（有点像是KANO模型）
  - 基本需求：用户要求的，必须做
  - 期望需求：用户认为要做，不做不满意（隐性需求）
  - 兴奋需求：用户不认为要做的，一般不做

四、需求分析的步骤

4.1 需求获取与收集

方法：（与用户沟通的方法用哪几种）
（1）用户访谈
（2）问卷调查
（3）采样
（4）情节串联板（获取原型）
（5）联合需求计划（JRP）
（6）会议讨论
（7）电话沟通

注意，没有决策分析，决策分析通常是在规划风险应对的时候，或做项目可行性研究时候使用。

4.2 需求分析

• 检测和解决需求间的冲突
• 发现软件的边界，以及软件与其他环境如何交互
• 详细描述系统需求，以导出软件需求

定位：软件工程中的一个关键过程

可以分为三个阶段：

• 需求提出：使用者提需求
• 需求描述：需求分析师，介入分析
• 需求评审：与用户确认

导出软件需求

4.3 需求定义（编写SRS）

形成需求规格说明书（SRS）

4.4 需求验证

需求评审
需求测试

五、需求状态

5.1 已建议

该需求已被有权提出需求的人建议

5.2 已批准

已用一个确定的产品版本号或创建编码分配到相关的基线中，开发团队已同意实现该项需求该需求已被分析，评估了对项目余下部分的影响（包括成本+对项目其余部分的干扰）

5.3 已实现

已实现需求代码的设计、编码或单元测试

5.4 已验证

eg：测试和检测，审查该需求跟踪与测试用例相符，该需求现在被认为完成，使用所选择的方法已验证了实现的需求

5.5 已删除

计划的需求已从基线中删除，但包括一个原因说明和做出删除决定的人员。

六、关于需求管理，我有话说

评估优先级的方式、必要性—>可行性—>优先级—>计划
项目需求做优先级排列的维度

6.1 问题1 其他快速评估优先级的方式

Q：如果给需求优先级做排序，除了按照供应商报的人天数着手，以及按照Kano模型之外，是否还有其他快速评估优先级的方式呢？目前现状是，用户的叫声比较大，我们就优先做。或者是对跟某个业务关系好，就优先处理他们的请求。

A：可以从以下角度评估优先级

• 需求投入产出比，投资回报，
• 需求（业务）成熟度（比如流程是不是稳定了）
• 需求清晰度（自己都说不清肯定不行）
• 需求风险（比如相关方是不是都认同）
• 业务投入情况（对方是不是有或者计划把这个需求列为他们的重点工作）

另外需求评审应该有流程，不应该某个人决定， 放到项目级需求来看，比如我在弄部门2020的重点工作项目清单，我也收到了60个项目需求，我怎么判断优先级，其实也是一样的。不过我还有一个可以参考的，就是公司战略方向，甚至我可以先证明资源只能支持10各项目，找各BU总经理排优先级做取舍。

6.2 问题2 需求评审

Q：目前已经在需求模板中，加入了投资回报的描述，用户需要填写对应的需求模板以及投资回报，我们做完评估后，才有可能做实现，但是，如果是优化类需求，似乎直接发出需求模板给他，就不怎么好，这个时候，是跟他调研后，做投资回报记录比较好呢？还是追出邮件让他提供投资回报分析。比较好？

Q：需求评审流程，包括优化类需求不？

A：回答你的问题，得先回答“需求评审”这个模糊的概念，业务活动，他的输入、输出分别是什么？输入的是所有需求，输出的是合理的及不合理的需求清单，针对合理的需求清单，还要输出可行的方案（在哪个系统、哪个模块实现）、实施的人和计划。

具体，要等公司后续，需求评审要评审什么内容，可能要部门达成共识之后，才好确定。输出不管什么形式，本质就是 必要性---->可行性---->优先级---->计划，应该是有顺序的。

回到问题，发现隐藏需求，算判断过这个需求是必要性是合理的。故只完成了“必要性”的评估，就直接提交过了可行性和优先级的评估，直接进入计划执行阶段了。应该结合技术可行性、业务可行性等，先做可行性分析，然后再基于优先级判断的各个维度进行优先级判断（投资回报、难度、周期、资源等综合因素），才是给出计划并执行。目前还不是部门的统一规范，更多是个人经验和感觉。这个需要形成部门、针织公司的统一的信息化规范和制度，才好规范相关需求管理工作，同时也约束业务部门。避免后续你反馈的需求管理过程中的种种问题。

七、业务需求分等级处理实战

业务部门对OA系统提出的业务需求，主要归纳为三类：

7.1 门户需求

通过系统标准功能配置实现，需求分析主要通过系统原型方式，给用户确认，原型直接在测试环境，通过门户标准功能，快速配置实现；

7.2 业务功能需求

相关工具，推荐在线的免费版工具 https://www.processon.com/diagrams 可以快速画用例图、泳道图；按照《需求记录模板》记录概要需求，然后通过UserCase 分析功能点，泳道图描述概要功能逻辑，用例描述文档记录详细业务规则；

7.3 流程类需求

主要弄清楚流程表单”需要记录哪些内容，审批流程如何；
目前整理了一个《流程类需求梳理模板》，由业务提出方按照模板填写；

八、需求分析可分为两个阶段

8.1 阶段一：收集需求

需求的来源有很多，需求的处理方式也不尽相同。有效的收集需求，将收集到的需求去伪存真，是产品设计环节中最重要的一环，如同大厦的地基，地基不坚实，大楼是盖不起来的。而且我们在收集到需求时，要第一时间与用户交流沟通，尽量走到用户中去了解他们的想法，深入了解目标用户在真实环境下的感受，尽可能地挖掘用户的原始需求，充分了解用户真实场景，才能真正更好地服务用户，打造出他所想要的产品。

8.1.1 还原场景

我们可以从以下场景进行分析：

• 基于什么环境：地铁/办公室/室内/公共场合/走路/夜晚/户外…深入情景周围的细节中去。
• 基于什么用户：具备什么特征，比如身份、收入、区域…
• 基于什么行为：行为或操作流程，比如购物流程、操作习惯、行为认知…

场景分析也就是需要考虑具体什么环境（时间、地点、情境）什么类型用户的什么动机，想达到什么目标，以及人与人的关系。如实地分析记录下来，如果偏差或缺乏信息，之后的分析就会有所偏差。
如果只是单独看用户提出的需求，你很难分析到用户的真实需求，就像有些英语单词一样，你必须放到那个语境下面去了解，才能找到用户背后真实目的。

8.1.2 多问几个为什么

用户需求的传递过程中总是存在着无法完全理解吸收的问题，导致所收集的需求不一定就是用户的真实需求，这时你需要做的是找到需求的提出人，多问几个为什么。这个需求提出人可能是用户，也可能是运营，也可能是技术，你多问几个为什么的时候，也就能挖掘用户背后的需求。

8.1.2 数据分析

数据是客观反映产品的重要指数，也是收集需求的重要来源，前期收集的数据需要是可靠、客观的，而且数据是零散的，在进行数据分析前一定要有明确的中心，划定一个界限，收集同一个框架内的数，同时单独的数据是死的，有对比的数据才有意义。为了避免主观意识的影响，同一份数据可参考其他人员的分析结果。

8.1.4 多和别人沟通/头脑风暴

一个人的力量是有限的，当我们吃不准的这个用户需求时，可以把这个需求拿出来和用户讨论一下，进行头脑风暴一下，人多力量大么，当我们吃不准一个需求的时候，大家都认为的那个结果就是需求分析的结果。

8.2 阶段二：处理需求

处理需求的阶段，也是产品经理将需求进行筛选，梳理业务流程，设计产品架构的阶段。

8.2.1 需求筛选、分类

尽管我们保持严谨的态度收集大量的需求，其中还是有很多需求是“伪需求”，甚至是不合理的，我们第一步就需要将这些需求进行“清洗”，择优去重、去伪存真。

8.2.2 设置优先级

一般来说，从需求类型来看，基本型需求>期望型需求>兴奋型需求；

从需求来源来看，战略性需求（用户提出）>功能性需求（核心功能）>业务性需求（拉活、存留）>体验性需求（提升用户体验）。

需求优先级判断最常用的是用四象限法则去评定优先级，另外可以使用RICE评定方法，KANO模型等。

8.2.3 竞品分析

通过相似竞品的用户定位、功能反推竞品的需求，与自己的需求进行对比；将自己的需求代入竞品中，看流程是否符合逻辑；与竞品进行对比，分析需求的异同。
由于在这个阶段，产品经理不仅要定义目标用户、产品使用场景，还要确定核心功能，产品流程等等，因此通过竞品（如果有）来辅助处理需求是一种很有效的方法。

8.2.4 需求评审

在这个阶段之前，作为产品经理对于产品应该有了一个完整的模型，但仅仅是理论上的模型，确保UI、UE、前端开发、后台开发、测试参与，从产品开发流程的各个角度对需求进行拆解、分析。需求评审可以看作是产品开发的初始化或者预开发。

九、需求分析阶段的三种模型？每个模型用什么图来画？

十、需求分析阶段产生的文档

产生的哪些文档罗列出来？团队中的做需求分析的要交哪些个文档？

需求分析文档：

• SRS文档（System Requirement Specification）——软件需求规格说明书
• E-R图
• 状态转换图
• IPO图（处理算法的描述记录 ）
• 数据规范化文档，也是在需求分析的时候做的哦！
  （数据库系统概论，解决什么问题，研究什么内容?解决冗余的问题，做的事情？）