需求工程的推荐方法

需求工程包括需求开发和管理，而需求开发又包括这几个过程：需求获取，需求分析，需求规格说明和需求验证。需求获取和分析包括发现，分类和组织需求、需求的优先级排序、协商需求以及形成需求文档。需求验证的方法包括评价需求、原型设计和生成测试用例。在需求开发之前，还需要有一个知识培训的过程，需求工程也是一个项目工程，因此也包括了项目的管理。对于这些过程，有以下方法可以采用。 需求分析员培训：需求分析员应该具有良好的交流沟通能力，同时理解产品，并掌握了需求工程的技能。

用户培训：用户也应该接受需求工程知识的培训，让他们理解需求的重要性，知道如何准确的描述需求，需求的风险性等。

开发人员培训：开发人员应该对用户的应用领域有一个基础的了解，明白客户的业务活动，术语，产品目标等 需求包括业务需求，用户需求和功能需求以及非功能需求，在需求开发之前，我们需要先定义好需求开发的过程，形成文档，内容包括：需求开发的步骤，每一个步骤如何实现，如何处理意外情况，如何规划开发资源等

需求获取包括以下方法和技能：

项目范围确定：开需求开发前期，我们应该获取用户的业务需求，定义好项目的范围，使得所有的涉众对项目有一个共同的理解。

用户确定：确定用户群和分类，对用户组进行详细描述，包括使用产品频率，所使用的功能，优先级别，熟练程度等等。对每一个用户组确定用户的代言人。对于大型项目，我们需要先确定中心客户组，中心客户组的需求具有高级别的优先级，需要先实现的核心功能。

用例确定：与用户代表沟通，了解他们需要完成的任务，得到用例模型。同时根据用例导出功能需求。用例描述应该采用标准模板。

系统事件和响应：业务事件可能触发用例，系统事件包括系统内部的事件以及从外部接受到信息，数据等等，或者一个突发的任务。

获取方法：召开需求讨论会议，观察用户的工作过程，采用问答式对话，采用诱发式需求诱导等等。检查完善：问题报告和补充需求建议 需求分析是对用户的需求获取之后的一个粗加工过程，需要对需求进行推敲和润色以使所有涉众都能准确理解需求。分析过程首先需要对需求进行检查，以保证需求的正确性和完备性，然后将高层需求分解成具体的细节，创建开发原型，完成需求从需求获取人员到开发人员的过渡。

绘制关联图：关联图确定系统和外部的交互。划分了系统的范围和界限，构建了系统对外的接口。

原型开发：对于敏捷方法，推荐完成一个界面的原型，一个初步的系统实现，通过原型，让所有涉众对开发的项目有了一个初步的映像，同时可以提供对需求的检验。

需求优先级别：采用分析的方法确定产品的功能，用例和单项需求的优先级别，以优先级为基础，确定各项功能和需求都包括在哪个版本中，在项目开发过程中，需求的优先级别根据实际情况进行调整。

需求建模：图形分析模型对需求描述更加抽象。主要可以采用UML的建模分析。

数据字典创建：建立系统中所用到的数据项和结构的定义，数据字典可以使参与项目开发的每一个人都使用统一的定义。

子系统：建立系统的结构，同时将需求分配到各个子系统和模块中。 SRS应该是一个作为涉众对系统的统一理解。

采用SRS模板：定义一种标准模板

本篇文章是对超仔老师课件的笔记整理，对于入门级产品经理应该如何掌握对产品需求分析思路和方法，学习完本课堂能够对这方面的知识体系更加系统性地了解，课件内容是理论和实际例子的结合，实实在在的干货知识通俗易通。对自己近期奔波于各公司的面试有莫大的帮助。

总共有三节课：

第一节主要内容是产品需求内涵的理解；认识需求的分类、层级、规律；学会如何正确地表达一个产品需求。

第二节主要内容是对需求获取的渠道和方式的掌握；学会对记录需求的方式。

第三节主要内容是对需求挖掘使用场景的了解；需求挖掘方法的掌握；需求分析的方法和需求优先级的排序方法的掌握。

一、产品需求分析思路和方法--产品需求

1、产品需求的内涵

①什么是产品？

所有的人造物都可以是产品，为了满足人们特定的需求而生产出来。汽车是为了让你移动的更快；房子为你遮风挡雨；衣服是让你保暖与遮羞。

②什么是需求？

需求是由个体在生理上或心理上感到某种欠缺而力求获得满足的一种内心状态，它是个体进行各种活动的基本动力。这是需求在心理学上的定义。

③需求的产品的关系

产品是为了人们的需求而被生产出来的，因为需求的驱动，才会使得用户需要产品。互联网产品就是通过互联网技术来满足人类的需求。

互联网产品的形态有：App、Web网页、PC客户端、各种硬件内的软件、AR、VR等等。产品经理所做的工作就是如何设计互联网产品去满足用户的各种需求

④案例分析：中午你饿了，想尽快吃饭，又不想出门，快速填饱肚子是需求，因此诞生了外卖产品。比如：美团外卖、饿了么

⑤理解需求的误区

很多产品在讨论需求的时候，会流于表面，最常见的一个问题就是把解决方案当成了需求，对需求的理解挖掘一定要到心里状态这个程度。

2、需求的分类及层次、规律、拆解用户需求

①需求分类

用户需求：满足用户所想，用户是上帝

商业需求：一切向钱看，商业化是目的，实现产品价值的最大化。

用户需求和商业需求的关系

提供产品必须满足用户需求，你只有满足了用户需求才会对用户产生价值，你才有可能实现你的商业化目的。谈商业需求的前提一定是谈用户需求，只要把用户需求满足好了你的商业需求才有可能得到实现。

案例分析：微信在起步阶段，用户需求高于商业需求仅仅满足用户需求不收取任何费用没有任何广告，最近几年，用户需求满足得很好了，作为一个成熟的产品，要攫取商业利润，商业化信息越来越浓，支付提现要手续费，广告介入，售卖广告位。

②需求层次：马斯洛需求层次理论

(Ⅰ)生理需要：满足日常生活基础所需，如吃穿住用行等；

(Ⅱ)安全需要：如对健康的担心、对贫困的恐惧、对无知的忧心、都是缺乏安全感的表现，在安全感匮乏的同时，则内心驱动会促使去满足获取安全感的需要；

(Ⅲ)社交需要：社交包括友情、爱情、亲情等多个层次；

(Ⅳ)尊重需要：希望可以得到别人的尊重，展现自己，获得人们的认可。尊重与被尊重都存在与社交网络中交流互动中；

(Ⅴ)自我实现需要：最高阶级的需求。如微博加V、知乎。

用户需求：人性七宗罪，在圣经里，人类天生都是罪恶的，所以从生下来开始一生都在赎罪，具体有七宗罪：*欲、贪食、贪婪、懒惰、暴怒、妒忌、傲慢。

③需求层次的规律

规律一：需求层次理论将人类需求从低到高层次划分为5类，只有较低层次的需求得到满足之后，较高层次的需求才会成为新的动力。

规律二：这些需求都是与生俱来的，不会随着社会的变革而变化，即需求是不会变的，变的是满足需求的产品。

规律三：产品最核心的是其解决的需求是否是刚需。马斯洛最底层的生理需求，如生活类的吃穿住行，即为刚需。其上一层次的安全需求，也都是普遍存在的，而越往上，则变得越来越不必要，如自我实现，不再是所有人的必须。

规律四：越底层的东西，越是平淡无奇，使用起来越是不温不火。需要的才打开使用，是一种工具。而其他基于新鲜感的需要，则在使用高峰时则万人空巷；低谷时，则门可罗雀。故基于底层的工具类需求，粘性未必最高，但一定是生存最久的。

④拆解用户需求

一条用户需求可看做是‘目标用户’在‘合理场景’下的‘用户目标’，其实就是在解决‘谁’在‘什么环境’下想要‘解决什么问题’

案例：拆解用户需求

需求一：酷爱音乐，跑步的时候一定要听音乐，而且要听特别感动的音乐

需求二：想知道最近流行什么音乐，不然K歌总觉得自己落后

需求三：不知道听什么，推荐的自己不喜欢

本章小结

需求是产品经理口头上出现频次最高的词汇，但需求二字背后的真正含义又有多少人知道。究竟产品需求包括什么，需求如何分类，用户需求和商业需求究竟什么关系，以及需求的正确打开方式是什么，通过本节课能够深刻领悟到

二、产品需求分析思路和方法--需求的来源

1、需求获取的渠道：外部和内部

①外部：

外部获取需求的方式有用户、竞品、市场、合作伙伴

(Ⅰ)用户：产品设计的初衷就是为了满足用户的需求，可通过用户反馈、用户调研获取；

(Ⅱ)竞品：竞品分为两种。一种是用同样的产品功能满足同样用户需求的产品，另一种是用不同的产品功能满足同样用户需求的产品。竞品对用户需求的满足程度、满足方式可以为我们的产品设计带来一定的启示

(Ⅲ)市场：需求和产品常常会受到行业政策调整的影响。如‘净网行动’、‘打车软件专车服务属非法营运’等

（Ⅳ）合作伙伴：合作伙伴在商业模式中扮演着重要的角色

②内部：

内部获取需求的方式有产品数据、老板、同事、自己

(Ⅰ)产品数据：用户在使用时会产生行为数据，这些客观的数据一定程度上会反映出用户需求

(Ⅱ)老板：企业运转的根本目的在于盈利。产品在满足用户需求的同时必须兼顾公司的战略需求。

(Ⅲ)同事：产品、研发、设计、运营、市场、销售、客服是距离用户最近的人，往往最能理解用户抱怨的点也能提出建设性的意见。

(Ⅳ)自己：产品经理应该成为自己产品的重度用户，而且是产品的目标用户，在使用产品的过程中发现用户需求，如此一来更能帮助用户解决问题。

2、需求记录

产品相关人员在获取需求之后，还需要对数据进行一个初步的记录，以便于后面的产品经理对需求进行分析、管理与实现

①需求的记录方式

②需求类型

按产品属性划分：分为idea、新增、优化、Bugfix四种类型；

按产品职能划分：分为功能类需求、运营类需求、数据类需求、设计类需求；

本章小结

需求来源于各方面，产品经理对于需求的把控是检验产品能力的重要一环。现实中往往出现需求很多但都不合理，问题就在需求的来源不对，导致需求的质量不高，因此要把控好需求的来源，提高需求的质量。

三、产品需求分析思路和方法--需求的挖掘

1、了解需求挖掘的使用场景

通常产品规划前期，产品经理需要定位好用户的痛点，为其提出解决方案，并作为产品的核心功能和卖点。比如景区导航的核心功能点是定位和导航，天气预报App的核心功能是天气报道和预报，明确其核心功能后，还需规划其他延伸的功能或相关功能，以增加用户的粘性，推动用户的活跃和转化。

2、掌握需求挖掘的方法

①心里+场景方式就是通过用户在某个环境状态下，对用户每个心里状态进行分析和提出解决方案的过程。

案例分析：墨迹天气是以天气播报为核心功能的，当用户知道天气情况后，他们有哪些心理活动？又下雨了？今天穿多少衣服出门？空气质量是否适合运动、逐一的梳理出用户在这个场景下可能存在的心理状态，针对心理状态列出功能点

②标签+场景是通过对用户的基本认知进行场景化思考，对这个特点的用户在这个场景下需要哪些功能。

案例：keep是针对80后的运动软件，那么我们先列出80后的社交和标签行为，然后选择一个场景逐一考虑是否有新的功能点。

3、需求分析

①需求分析的方法

需求分析分成三个部分：需求筛选、需求透视、需求排序

三者的逻辑：首先筛掉不做的需求，其次对要做的需求进行进一步提炼，最后对提炼好的需求进行优先级排序。下面对这三者做下分析

（i）需求筛选

需求筛选的特点包含真实性、一致性、价值性、可行性；

真实性：这个需求是否可以满足用户的需求；

一致性：有多少用户需要这个需求，覆盖率多大，是否满足产品定位；

价值性：需求能带来多大的价值？需要付出多大成本？；

可行性：需求在现有的资源上是否能实现；

（ii）需求透视

需求透视包括表面需求、本质需求、产品需求。本质需求是用户想解决的根本问题。获得用户的本质需求更能找出合理的解决方案来解决用户需求；产品需求是依据用户想解决的根本问题，得出更好的解决方案

（iii）需求排序

需求排序的三个基本考虑因素：战略定位、产品定位、用户需求，具体而言可以分为七个维度：相关性、逻辑性、价值性、强度、广度、频率、类型

（Ⅰ）相关性：考察需求与战略地位、产品定位的相关性

（Ⅱ）逻辑性：完成A功能才能进行B功能

案例分析：微信钱包开发战略：绑定yhk—充值—消费—红包—理财通—京东精选—生活缴费

（Ⅲ）价值性：考察需求能创造的企业价值、用户价值的性质与数量

（Ⅳ）强度：考察需求的强弱，三个因素考虑：必要性（不可缺少）、高频次（需求次数多）、持续性（长时间保持足够的需求频次）

（Ⅴ）广度：需求覆盖的目标用户有多少

（Ⅵ）频率：考察需求单位时间内出现的次数

（Ⅶ）类型：依据KANO模型对需求作出分类，考察需求类型。KANO模型认为用户需求可分为基本型需求、期望型需求、兴奋型需求

本章小结

产品的需求的来源于用户、客户、领导，产品经理应该要有自己的一套产品功能规划思路和方法论；对收集到的需求，可以通过“心里+场景”、“标签+场景”这些纬度去判断需求是否符合用户心里和个人特征；紧接着对符合的需求的进行分析、筛选、优先级排序，这项工作是最考验产品能力的，互联网行业瞬息万变，只有利用好手中的资源合理安排需求，才能抓住市场机遇，优先满足用户需求，获取市场流量。

1 问卷调查法， 开发方就用户需求中的一些个性化的、需要进一步明确的需求，通过采用向用户发问卷调查表的方式，达到彻底弄清项目需求的一种需求获取方法。这种方法适合于开发方和用户方都清楚项目需求的情况。因为开发方和建设方都清楚项目的需求，则需要双方进一步沟通的需求就比较少，通过采用这种简单的问卷调查方法就能使问题得到较好的解决

2 会议讨论法 ，开发方和用户方召开若干次需求讨论会议，达到彻底弄清项目需求的一种需求获取方法，这种方法适合于开发方不清楚项目需求（一般开发方是刚开始做这种业务类型的工程项目）但用户方清楚项目需求的情况。因为用户清楚项目的需求，则用户能准确地表达出他们的需求，而开发方有专业的软件开发经验，对用户提供的需求一般都能准确地描述和把握

3 界面原型法 ，开发方根据自己所了解的用户需求，描画出应用系统的功能界面后与用户进行交流和沟通，通过“界面原型”这一载体，达到双方逐步明确项目需求的一种需求获取的方法。这种方法比较适合于开发方和用户方都不清楚项目需求的情况。因为开发方和用户方都不清楚项目需求，因此此时就更需要借助于一定的“载体”来加快对需求的挖掘和双方对需求理解。这种情况下，采用“可视化”的界面原型法比较可取

一、 我们应当如何做需求分析

需求分析不是一蹴而就的，它应当贯穿整个开发周期，不断的分析确认的过程。这就是敏捷开发倡导的需求反馈。敏捷开发认为，需求分析阶段不可能解决所有的需求问题，因此在设计、开发、测试，直到最终交付客户，这整个过程都应当不停地用开发的成果与客户交流，及时获得反馈。只有这样才能及时纠正需求理解的偏差，保证项目的成功。

二、我们应当怎样做需求调研

1初识。

我们对客户提出的需求进行深入理解以后，运用我们专业知识，提出比客户的原始需求更加合理、可 *** 作的解决方案，让客户感觉你说的正是他们想要的。如果能够这样，客户不仅能够欣然接收你提出的方案，而且会感觉你非常专业，你在客户心目中的形象也会无形中提高，使你有更多的机会提出有利于开发的可行方案，降低开发的风险。这毫无疑问会形成一个良性循环，但要做到这一点并不容易，毫无疑问，在与客户接触初期的表现起到了极其关键的作用。

(1)高层领导关心的是宏观的目标，因此软件研发目标、宏观统计报表、决策支持功能，我们应该怎样做需求分析,应当与高层领导谈。

(2)中层领导关心的是具体的效益，即软件给各个部门信息化管理方面带来的效益，因此，中层领导是各项业务流程、功能模块的需求决策者。他们关心功能的定义、业务流转的衔接、查询报表的设计，但不太关心一些具体的 *** 作，以及一些具体业务流程的细节。

(3)基层人员是每一项业务流程的 *** 作者，也是软件今后真正的使用者。他们是真正了解你所要开发的软件的业务需求的领域专家，是你进行需求调研的重点对象。但是，基层人员往往受到自身视野的局限，可能只清楚自己工作涉及的十分狭小的一个范围，因此我们需要努力寻找那些业务涉及面广，经验丰富，又有一定大局观的真正的专家。另外 ，他们就是软件今后真正的使用者，让他们参加，会让他们成为今后软件推行的忠实支持者，对其他 *** 作人员的指导者，益处多多。而他们关心的则是每项 *** 作的细节。

俗话说：万事开头难。如果你在项目开始的时候总感觉千头万绪不知如何着手，在这里我给大家的三点建议：

1）树立良好的职业威信；

2）进行详细角色分析，将与会各方代表对号入座；

3）从宏观上制订目标与方案。随后的工作，就是与各方代码建立联系，逐一拜访他们，将需求调研工作一步一步进行下去。

2拜访。

需求调研不是一蹴而就的事情，是一件持续数月甚至数年的工作（假如项目还有后期维护） 。在这漫长的时间里，我们需要依靠客户这个群体的帮助，一步一步掌握真实可靠的业务需求 。不仅如此，技术这东西总有不如意甚至实现不了的地方，我们需要客户的理解与包容，这都需要有良好的客户关系。尽管如此，我们也不能总是期望客户中的所有人都能与我们合作，很多项目都不可避免地存在阻碍项目开展的人。

3研讨会。

(1)由于业务人员自身的局限 ，不可能对所有业务领域的细节全面掌握，往往总是有自己熟悉的部分，也有自己不熟悉的部

分。划分业务组，可以让业务人员分别在自己最熟悉的业务范围内参与讨论，可以有效提高业务讨论的质量；

(2)集中式的业务研讨形式和分散式的业务研讨形式；

(3)有效抑制个性化差异、分模块组织专项研讨会。

4业务研讨

在需求分析过程中，客户存在的最大问题就是提不出正确的需求，这表现为几种形式：

(1)由于对软件不了解，客户提不出需求，不知道软件最终会做成什么样子。这类客户在需求讨论过程中，往往只能描述目前自己手工管理的方式是怎样的，不知道计算机会怎样管理。

(2)能提出一些业务需求，但当软件做出来摆在自己面前时，需求就变了。这类客户，他们能熟练使用电脑，对信息化管理是清楚的。他们提出的业务需求从整体上应当是八九不离十的 。但是，由于没有实物，在软件中的一些具体 *** 作并没有完全想清楚。

(3)能非常详细地提出业务需求，甚至有时候该怎么做的提出来了。这类客户，参与过很多软件信息化建设，甚至有些还是软件开发的半专业人士。但是他们提出的业务需求过于具体 ，甚至怎样实现都说出来了，但这些有时候不是最佳设计方案、可能在技术上难于实现，甚至有些就是过于理想化而不可实现。

   解决办法:

业务领域分析:客户现有的业务流程是什么样的，都有些什么 *** 作？客户在业务中都有些什么事物，什么专用名词，都是怎样定义的，相互之间的关系是什么？客户在每一项 *** 作中的目的是什么，为什么要这样做，他们制作的手工报表都说明了什么问

题？

(1)我们做需求分析，眼界不能仅仅停留在软件本身，应当更开阔一些，应当扩展到跟这个业务有关的那些领域知识中。

(2)在客户提出的所有原始需求中那些与业务实现有关的需求都是无效的需求，它们仅仅只能作为我们的一个参考。

(3)还有一些是技术难于实现或者根本就无法实现的需求，我们应当耐心地说服和引导客户，并给他提出一个更加合理的方案。

(4)需求分析不是一种简单的你说我记的收集活动，而是在大量业务分析与技术可行性分析基础上的分析活动。只有建立在这种分析基础上的软件研发，才能保证需求的正确与变更的可控。

5迭代

在第一次的需求分析阶段，我们在一段时期内需要与客户进行反复地讨论，这个过程往往是这样一个反复循环的过程：需求捕获->需求整理->需求验证->再需求捕获······

(1)需求捕获:就是我们与客户在一起开研讨会，讨论需求的活动,客户可能会描述他们的业务流程，这时我们在纸上绘制简单的流程草图，及时地记录下来；客户在描述业务的同时，可能会反复提到一些业务名词，详细询问这些名词的含义，以及它们与其它名词的关系，用类图或者对象图绘制简单的草图；客户在描述业务的同时，还会提出今后的软件希望实现的功能，如能够展示某个报表、能够导出文件，以需求列表的形式记录下来。一个功能，在需求列表中会有多个需求，而每个需求应当能够用 1、2 句话，在 20 个字以内就可以描述清楚 。需求列表是客户提出的最最原始的需求，他不掺杂任何分析设计，是我们的每项功能必须实现的内容。

(2)需求整理:就是在需求研讨会后，需求分析人员对研讨内容的分析和整理的过程。首先，需求分析人员应当通过用例模型，划分整个系统的功能模块，以及各个模块的业务流程。用例模型分析是一个由粗到细的过程，这样一个过程也是符合人类认识世界的思维习惯的一个过程。最先，我们应当对整个系统绘制用例图，设计用例场景，并依次对这些用例进行用例描述、流程分析、角色分析等分析过程。当然，在整体用例分析的同时，我们还应当进行一个整体的角色分析，绘制一个角色分析图，进行一个流程分析，绘制一个流程分析图（可以是传统的流程图、UML 中的行动图，甚至一个简单的示意图，等等）,再在整体用例图的基础上，依次对每个用例绘制用例图。每个用例图中，会更细致地划分出多个用例，并依次进行用例描述、流程分析、角色分析等分析工作。如此这般地不断细化，直到我们认为需求已经描述清楚为止。

(3)领域模型 :是对用户业务领域中相关事物、相互关系、相互行为 *** 作的描述，它是以对象图和类图的形式表达的。需求人员对领域模型的分析，对业务理解的深度，对日后软件的设计，以及软件的功能扩展、升级演化，都起到了至关重要的作用。

(4)需求验证:需求验证工作应当贯穿整个研发周期，并且在不同时期表现出不同的形式。首先，在需求分析阶段，需求验证工作表现为对需求理解是否正确的信息反馈。需求分析人员与客户再次坐在一起，一项一项描述我们对需求的整理和理解，客户则时不时地对一些问题进行纠正，或者更加深入地加以描述。我们则认真地记录，回来整理，并等待下一次的验证。在需求分析后期，我们还可以制作一些简单的原型，更加形象地描述我们对需求的理解，会使我们与客户的沟通更加顺畅。随后的设计开发阶段，我

们则应当以迭代开发的形式进行。每开发完一个迭代周期，将开发的成果与客户反馈。这样做的结果是，客户可以及时地提出我们对需求理解的偏差，或者及时提出对我们设计不满意的地方，使我们存在的问题得到及时地发现与解决。问题及时的解决，使我们修复问题的代价得以降至最小。

6需求捕获

经过深入分析我们会发现，从客户嘴中说出来的需求，只是整个软件需求中的冰山一角，还有两类需求需要我们自己去挖掘：客户嘴中没有说出来的需求 ，和客户压根儿就没有想到的需求

(1)什么是客户嘴中没有说出来的需求：并不是客户故意卖弄官子不愿说出来，而是在客户所在业务领域已经约定俗称，在他们看来已经是天经地义，根本就不用说出来的业务规则。然而 ，作为刚刚涉足该领域的需求人员，他们是不了解这些规则的。如果采用被动的方式去仅仅记录客户说出来的需求，毫无疑问会遗失这部分需求，这就是为什么直到项目后期，软件被研发出来即将交付使用，客户才提出说这不是我想要的软件，并提出大量变更需求的原因。要求我们在需求分析的整个过程，不断进行业务领域知识的学习。在我做需求访谈的初期，我往往不是跟客户谈需求，而是先跟客户谈业务。你们是怎样 *** 作的？都经过些什么流程？谁来完成这些 *** 作的？为什么这样 *** 作？注意，在所有这些问题中，最后一个问题是最重要的。客户业务领域中的所有 *** 作、所有流程都是有它存在的意义的，它体现了其内部的原因与作用。多问为什么，可以让我们深入地理解这些领域知识 。站在客户的视角去思考问题，进而深入地理解客户为什么要提出他们的那些业务需求

(2)另一种就是客户压根儿没有想到的需求：在需求分析阶段，虽然客户压根儿没有想到，但需求分析人员是软件研发领域的专业人员，他们应当在深入理解业务领域与需求的基础上，通过分析提前发现这些需求。作为需求分析人员，他们应当站在客户的角度去思考，我们的软件应当设计成什么样子，每个需求的真实意图是什么。站在这个基础上，再运用专业知识去整理、分析与设计。我前面谈到，客户描述的最原始的需求是编写在需求列表中的，而经过需求分析人员的整理、分析与设计，经过用例分析、领域建模，最终形成产品需求说明书（或称为产品规格说明书）。先在一些非正式的场合单独跟客户聊，产生第一手资料，最后将这些需求在比较正式的场合，如各部门参加的业务讨论会、有用户代表参加的

笔记内容大部分来源于课本《软件工程导论》，侵删

可行性研究是用较小的成本杂较短的时间内确定是否存在可行的解法

而需求分析是回答“系统必须做什么”这个问题

结构化分析方法遵守的准则：

需求获取难的原因：

需求分析的任务

①确定对系统的综合要求

综合任务：

②分析系统的数据要求（重要任务）

常利用图形工具辅助描绘数据结构

③导出系统的逻辑模型

常用数据流图、实体联系图、状态转换图、数据字典和主要的处理算法去描述这个逻辑模型

④修正系统开发计划

需求要：表述清楚、无二义性、尽可能量化

需求分析过程应该建立3种模型：数据模型、功能模型、行为模型

需求分析除了建立分析模型外还应写出软件需求规格说明书

为了把用户的数据要求描述出来，系统分析员需要建立面向问题的概念性数据模型。

数据模型包含3种互相关联的信息：数据 对象 、数据对象的 属性 、数据对象彼此间相互连接的 关系

数据对象：只封装了数据而没有对施加于数据上的 *** 作的引用（数据对象与面向对象范型的不同）

属性：定义了数据对象的本质

联系：数据对象彼此之间相互连接的方式称为联系，也称为关系（包括一对一(1:1)、一对多(1:N)、多对多(N:N)联系）

通常使用实体-联系图（ER图）建立数据模型

ER模型：用ER图描绘的数据模型称为ER数据模型

ER图包含的3中基本成分：实体（矩形框）、关系（连接相关实体的菱形框）、属性（椭圆形或圆角矩形）。

范式：消除数据冗余的程度（第一级范式冗余度最大，第五范式冗余度最小）

范式级别越高，冗余程度越小，拆分越多，大多数场合下第三范式比较实用

状态：任何可以被观察到的系统行为模式（规定了系统对事件的响应方式）

状态图中的状态主要有：初态（只能有1个）、终态（可以有0个或多个）、中间状态

事件：在某个时刻发生的事情，是对引起系统做动作或从一个状态转换到另一个状态的外界事件的抽象

符号：状态图中，初态用实心圆、终态用一对同心圆（内圆为实心圆）、中间状态用圆角矩形表示，状态转换用带箭头的连线表示。

从四个方面验证软件需求的正确性：一致性、完整性、现实性、有效性

以上就是关于需求工程的推荐方法全部的内容，包括:需求工程的推荐方法、产品需求分析思路和方法（笔记整理）、试分析在软件需求分析中与用户沟通的方法有哪些等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！