需求分析常见知识点合集

《需求分析师常见知识合集》一、工具类软件项目需求与设计案例——计时工具系统对于类似word之类的工具类软件，应该如何获取它的需求呢？五维三级需求法应该如何应用呢？该案例以一步一动的方式详细剖析了需求的过程......(一)计时工具系统案例与需求方法简介1)计时工具系统案例与需求方法简介某软件公司的开发项目进度计划总是那么不准确，延期经常出现，更可恨的是项目团队甚至无法给出一个相对比较明确的延迟时间，这给市场的推广会带来很大的影响。

以下是公司领导之间的对话：市场部经理：研发部承诺本月实现的产品功能又没按期交付，这已经是第三回了。

这导致产品上市时间总是不确定，给我们市场和营销人员带来很大的麻烦，你们知道吗？研发部经理：针对这个问题我们花了很多时间来解决，但一直收效不好。

我也在积极想办法，我用过FP模型、WBS方法等....总经理：（打断研发经理的话）这问题靠我们自己闭门造车是不行了，看看能不能借助外脑？我看这样吧，由你（研发经理）负责，请一个这方面的顾问，如果有必要还可以采用信息化手段，采购或研发个工具软件，帮助我们更好地解决该问题....这就产生了一个项目机会，那么对于这类件项目，又该如何抓需求呢？2)五维三级需求法“五维三级需求法”即从广度（五维：因、人、事、物、规）和深度（三级：业务和用户需求、产品需求、功能需求）两个视角分解复杂问题，展开需求分析，获取高质量的需求结果。

1．分析软件的“因”。

任何信息系统项目建设的出发点一定是要解决业务中存在的问题，以期达到某种建设目标，所以应将“因”维（分析业务问题，确定项目目标）作为软件需求分析的起点。

2．分析软件的“人、事、物、规”。

围绕达成“因（项目目标）”的几个关键业务场景，通过“人”维了解组织结构、清晰岗位职责，通过“事”维区分业务场景、梳理业务流程，通过“物”维收集单证报表、获取数据求，通过“规”维分析软件相关系统、明确时间节点等限制条件。

3．形成软件的“业务和用户需求”。

在“因、人、事、物”分析的基础上，分别描述核心业务流程和收集用户需求。

（1）对于存在业务变革的项目，讨论重点在核心业务流程，主要关注业务现在具有怎样的组织、执行怎样的流程、传输怎样的单证，并探讨未来会怎么办。

为了保证需求效果，讨论可一次围绕一个特定业务场景展开，事先草拟好业务流程图当“靶子”，并尽量邀请高层参加。

对于如体制调整等一些短期内无法决策的问题，也应标识出几种可能的变化情况，为后续的系统架构设计指明应考虑适应的变化点。

（2）对于不存在业务变革的项目（如工具软件、局部技术改造类项目），重点在于收集用户提出的各类意见（常以解决方案的形式出现），并挖掘意见背后的真正问题，结合行业最佳实践协商解决方案，形成用户期待软件具有的特性列表。

4．形成软件的“产品（软件）需求”。

任何软件或产品都必须在“时间、成本”等约束下，对“质量和功能”进行折衷，业务和用户需求中的很多事并不一定都要纳入系统中去实现。

因此，在产品（软件）需求阶段重点是在“规”的约束下，协商确定现阶段产品的项目范围和开发任务，如现阶段“到底有哪些岗位使用该系统，用户能够使用系统完成哪些工作，系统怎样帮助用户完成这些工作（自动化程度有多高）？”等等。

本阶段形成的文档名为《用户需求分析说明》，主要采用用例模型来描述。

5．形成软件的“功能需求（需求规格说明）”。

这阶段主要是对产品需求中的每个用例（即用户使用系统完成的一项工作），由系统开发者和具体用户协商，按用例优先级逐个确定其操作界面、操作步骤等，这层次的工作将为具体的物流信息系统开发提供完备的需求规格说明。

本阶段形成的文档名为《用户需求规格说明》，一般采用用例细化描述文档和补充规约（非功能性需求等）来表示。

注：业务、用户、产品等需求的概念和区别参考推荐阅读16. 需要特别说明两点：一是为了化解需求复杂度，“五维三级需求法”可逐个业务场景的迭代应用。

比如，在应用时可针对一个业务场景，完成一次需求分析过程。

待完成该业务场景下的业务需求、产品需求和功能需求后，再着手另一个业务场景下的需求分析过程；二是五维度中的核心是“因”。

只有准确把握好“因”，才能把握住“人、事、物、规”的变化趋势。

由于“因”常常由上一层次目标所决定，所以软件建设，需将建设目标纳入企业信息化顶层设计的背景中通盘考虑，才能准确到位。

(二)从“因”维确定用户痛点和协商解决方案1)获取甲方用户需求时，首先应访谈谁？怎么约？怎么谈？●首先约谁谈？抓需求，第一个要约见的是甲方的项目负责人。

因为他负责这个项目，有责任和义务去和乙方交流，选择乙方。

至于甲方的其他人员，应该通过甲方项目负责人去协调约见，如果擅自约见，可能会遭到拒绝，并引起甲方的反感。

●约谈对方方式主要有电话、邮件、面谈三种建议先提前一周发邮件约见，再提前半天打电话确认提醒，最后面谈。

一般应在邮件里包含：公司优势和访谈提纲。

公司优势包括以往成功案例、对项目的初步认识等，有利于体现乙方的专业能力和认真态度，加深甲方的认识；访谈提纲可以让甲方有更好地准备，比如在提纲中提到甲方业务规章制度，甲方访谈时就可以事先带一份过来，从而提高访谈的效率。

●访谈地点的选择约甲方普通人员访谈，一般在其办公室即可。

但是约见甲方项目负责人，由于他往往工作很忙，在其办公室一般干扰会很多，如一会儿有人敲门开汇报事情，一会儿有电话打入，导致需求访谈效果不佳。

因此，和甲方项目负责人的访谈地点一般建议选择方便、而且干扰少的地点，如其楼下的咖啡厅或者公司的会议室。

可以开玩笑地和他说：“领导办公室干扰太多了，领导能不能将约好的1小时时间完全给我，我们在楼下的咖啡厅坐坐？”●谈什么？和甲方的项目负责人交谈，是一次体现乙方专业能力，树立甲方信心的极好机会，应该事先做好充足准备。

交流时应注意从甲方的业务视角出发，聚焦甲方业务问题和解决问题的业务模式，避免过于技术视角。

由于甲方项目负责人不可能了解所有业务细节，所以一般访谈时还会和甲方项目负责人协商确定再召开一次业务需求研讨会（多人同时参加的用户代表访谈），会上将各类用户代表召集在一起，讨论业务细节，明确项目范围。

所以，还需协商制定会议计划，明确会议的时间、地点和人员，并通过甲方项目负责人通知相关人员，做好会前准备工作。

2)计时工具系统的“因”维度需求分析一、基本工作步骤“因”维度需求分析一般分为三步骤：1、通过同类方案（竞品）研究法成为领域专家；2、约谈甲方的项目负责人，找到核心痛点，介绍行业内各类解决方案，并与之协商适合甲方的解决方案；3、通过甲方的项目负责人，筹备多用户代表参加的集中访谈，确定会议时间、地点和参与人员。

二、以计时工具系统为例，详解“因”维度需求分析过程（案例背景详见推荐阅读1）1、通过同类方案（竞品）研究法成为领域专家通过前面案例介绍我们知道，负责该项目的需求师必须是工作量预计领域的专家。

如果对于该领域不熟悉，一般采用同类方案（竞品）研究法（详见推荐阅读2）尽快了解业务、掌握行业术语，并对市场上已有解决方案（竞品）的各自特点和利弊展开分析。

2、约谈甲方的项目负责人在该案例中，主要是约谈研发部门经理（为什么先约谈他？详见推荐阅读3），开展用户代表访谈。

访谈目标主要是：明确用户核心痛点，向他介绍行业各类解决方案，并协商该公司适合的解决方案。

以下是访谈的内容实录：（以下对话目标：明确用户核心痛点）需求师：能否介绍一下贵部门当前在工期预计中遇到的问题？研发部经理：我部门各个项目团队给出的项目进度计划总是不太准确，经常出现延期，更可恨的是项目团队甚至无法给出一个相对比较明确的延迟时间，这给市场的推广会带来很大的影响。

有什么好办法吗？（以下对话目标：围绕核心痛点，向用户介绍行业内常见解决方案）需求师：根据我们的研究，对于这类问题，目前业内做法主要是：根据用例包、用例的方式来组织需求，然后将某个用例或子用例作为工作任务分配给开发人员，但在开发时间估计上主要有三种解决方案：一是使用FP、COCOMO模型来估计工作量。

但是要想计算准确，需要很多历史经验值，并且要求前期需求做得非常精细，难度极大；二是自上而下的估计法。

主要由领导或专家指定相应的完成时间。

但由于开发人员未参与时间预计，所以如果到了时间开发人员完成不了，他容易反过来抱怨是领导时间安排不合理；三是自底向上的估计方法。

任务明确后让开发人员反馈工作量及所需的工作天数。

但开发人员容易将时间估计的偏长，而且还是有一些工作任务，由于开发人员经验不足，他反馈的工作量无法按期完成，甚至无法明确要延迟多少天。

（以下对话目标：与用户协商该公司适合的解决方案）研发部经理：三种方法我部门好像都采用过，确实存在你说的问题。

我感觉估算的基础是经验数据，对于不同的开发人员而言其产能是不一致的，甚至对于相同的开发人员而言，不同的任务所需的时间也是不同的，因此关键在于缺乏这种经验数据。

需求师：正是这样，所以我想向你推荐了PSP（个人软件开发过程）的方法来积累经验数据。

举个例子，我在编写技术书籍时，就采用这种思路，对所有的工作过程进行了时间的记录，在半年之后，就积累了许多相关的产能数据，现在给编辑的时间承诺总是能够比较的准确。

研发部经理：哦，难怪你做的承诺都一般很少延误，这种经验能否适用于软件开发的管理呢？需求师：呵呵，这是当然。

PSP是个人软件开发过程，它本来就是为软件开发设计。

它是CMM的创始人提出的，PSP、TSP和CMM分别针对软件开发员、软件开发小组和软件开发组织。

通过PSP的贯彻，就一定能够提高软件开发人员的时间安排、时间估算的能力。

由于统计个人开发时间是件比较繁琐的事，所以需要开发个工具配合它。

研发部经理：好！那我们就开发这么一个工具！3、通过甲方的项目负责人，筹备用户代表集中访谈会（以下对话目标：通过甲方项目负责人，筹备有更多其他用户代表参加的集中访谈会）需求师：太好了，这正是我要建议的！但是由于这款软件涉及到的人员较多，有很多细节需要确认，我们能否在下周召开一次用户代表集中访谈会？请您帮助召集更多的相关人员参加。

研发部经理：当然可以！那我们再商量下会议的时间、地点、主题和需要参加的人员......这样，这次计时工具系统的“因”维度需求分析就大致完成了，回来后需求师还应该整理访谈记录，形成文档（文档模板参见附件1）！(三)采用业务流程模型和特性列表描述业务需求和用户需求1)一图说清业务需求、用户需求、产品（软件）需求和需求规格的关系一、四者的关系如上图所示1、业务需求和用户需求是软件项目需求的起点。

业务需求侧重于和高层探讨业务流程（特别是需要优化的流程，详见推荐阅读1），一般产出物是业务流程图；用户需求侧重于和各类用户代表开展面对面的访谈，一般产出物是汇总访谈结果的需求特性列表；2、这时不论是业务需求、还是用户需求都比较粗糙，需要经过分析处理后，形成软件（产品）需求，才能交付给开发团队使用。