需求工程包含哪些活动软件开发活动中为什么要重视需求工程

需求工程活动包括（1）需求开发和（2）需求管理两个方面。

需求开发又包括需求获取、需求分析、需求规格说明和需求验证。

原因：（1）需求问题是当前软件开发面临的主要问题（2）需求分析是软件开发中的理论约束，他控制着整个软件开发的工程走向。他是非技术人员和技术人员的工程纽带。

需求获取分四个阶段：获取需求、分析需求、撰写需求文档、验证需求。需求获取到之后要对需求进行分析，将合理的需求整理成文档，最后再以文档为基础对需求进行评审、验证。这个步骤可能需要几次循环，不断地优化需求。

获取需求：也叫捕获需求，需要人为主动地去捕捉。可以通过问卷调查、用户访谈、竞品分析、市场分析等方法获取。

分析需求：将获取到的需求进行过滤、分析、加工、整理，最后筛选出真正有价值的需求。在分析需求的过程会用到很多方法，例如使用SWOT分析法分析产品的优势、劣势、机会、威胁；使用长尾效应分析法分析产品边界，分析核心需求、基本需求、满意需求、期待需求、兴奋需求，哪些需求是产品的头部，哪些需求是产品的尾部，辐射到的用户范围有哪些；使用优先级分析法将需求按重要度、紧急度、影响度进行划分，区分出需求的优先级，先开发哪些，再开发哪些。还有以竞品对比、用户偏好、商业价值等从各方面对需求进行分析，最终才能找出真正有价值的需求。

撰写需求文档：为了便于需求信息的传递和梳理，可以将分析后的需求以文档的形式记录下来，并形成规范，以便于与产品有关的人员之间的沟通。需求文档中要有各模块、页面、功能的说明，各功能的输入、加工和输出信息，以及各种图形内容，以便文档信息更准确的传递。

验证需求：此步骤是论证需求的过程，不是所有经过分析得到的需求都是正确的、合理的，需要通过评审论证以证实需求的正确性和合理性。验证方式可能是会议评审方式，也可能是主要负责人逐条排查的方式。

如果进入下一个阶段，发现有问题怎么办？在需求获取的每个过程都是可逆的，当下一阶段出现问题时，需求分析会回滚到上一阶段。可以从用户、网络、公司内部人员、竞品、行业动态及内心感知等方面获取用户需求，具体介绍如下。

1．直接用户

这是最直接的获取用户需求的方法，用户会通过语言、情绪、动作、表情来表达自己的好恶，如果产品解决不了用户的问题，他们就会用脚投票。用户能明确说出来的都是用户期望解决的需求，这些都属于基本需求。有的需求是用户表达不出的或者根本就没有意识到的，而这种能够引领市场、让产品脱颖而出的需求才是高价值的需求。

2．行业动态

“与天斗，其乐无穷；与地斗，其乐无穷；与人斗，其乐无穷。”做产品要时刻关注行业动态信息，政策环境就属于产品的“天”，市场环境就属于产品的“地”，用户就属于产品的“人”，我们要随时关注政策变化、市场环境变化，这样才能够保证产品的方向是正确的。这里说的“斗”是研究的意思，多研究产品的大环境，才能在第一时间抓住机遇、把控时机。

3．内部人员

一家公司往往只关注一个行业，公司内的同事都是这个行业的精英，对自己所从事的行业有着较深的感悟。例如运营人员大多关注产品与市场之间的关系，客服人员大多关注着产品与真实用户之间的关系，业务人员大多关注产品与潜在客户间的关系……公司内的每个人对产品都有不同的解读和思考，从他们那里可能会找到正确的答案。

4．竞品分析

当我们刚进入一个行业时，最快速的了解产品的方式就是研究竞品。除要研究竞品的功能外，还要研究产品功能背后的逻辑和思想。为什么要这样做，根据什么逻辑，能解决用户什么问题，用户的反应是什么。研究竞品并不是要克隆竞品，要了解市场、行业及用户。我们最好能找到真实的数据，用数据来说话，找出哪些功能是用户最迫切需要的。我们只有更好地了解竞品，才能更好地解决问题，为客户提供更优质的服务。

5．网络信息

调研和获取需求不一定非要与用户面对面地沟通，实际上有很多种方式都可以收集到用户需求，如网站的留言，企业的公众号、微信、微博等，这些窗口都可以作为与用户沟通的渠道。

6．内心感知

“树欲静而风不止”，用户的需求是不断变化的，会因时间、地点、人物角色的不同而不同，每个人看问题的角度都不同，每个人的思想和成长经历也不同。

同样的产品在不同时期对用户的价值也不同，如“大哥大”、BB机在20年前风靡全国，而如今它们已经被淘汰在历史的长河中。据说，乔布斯是从不做市场调研的，他只是看镜子中的自己，用心去领悟产品。世上的功夫有很多种，长拳、八仙拳、天罗拳、地煞拳、六星拳等，但我认为最高境界的功夫应该没有招式，即以无招胜有招，套路是固定的，但现实的变化是无穷的，用有招数的套路去应对无穷的变化一定会失败。所以最好的需求获取方式就是用心去领悟，把自己真正融入产品的世界中。

转载以下资料供参考

从广义上理解：需求分析包括需求的获取、分析、规格说明、变更、验证、管理的一系列需求工程。

狭义上理解需求分析指需求的分析、定义过程。

原因

需求分析就是分析软件用户的需求是什么。如果投入大量的人力，物力、财力、时间，开发出的软件却没人要，那所有的投入都是徒劳。如果费了很大的精力，开发一个软件，最后却不满足用户的要求，从而要重新开发过，这种返工是让人痛心疾首的(相信大家都有体会)。比如：用户需要一个for linux的软件，而你在软件开发前期忽略了软件的运行环境，忘了向用户询问这个问题，而想当然的认为是开发for windows的软件。当你千辛万苦地开发完成向用户提交时才发现出了问题，那时候你是欲哭无泪了，恨不得找块豆腐一头撞死。

需求分析之所以重要，就因为他具有决策性、方向性、策略性的作用，他在软件开发的过程中具有举足轻重的地位，大家一定要对需求分析具有足够的重视。在一个大型软件系统的开发中，他的作用要远远大于程序设计。

任务

简言之，需求分析的任务就是解决“做什么"的问题，就是要全面地理解用户的各项要求，并准确地表达所接受的用户需求。

过程

需求分析阶段的工作,可以分为四个方面：问题识别、分析与综合、制订规格说明、评审。

问题识别：就是从系统角度来理解软件，确定对所开发系统的综合要求，并提出这些需求的实现条件，以及需求应该达到的标准。这些需求包括：功能需求(做什么)、性能需求(要达到什么指标)、环境需求(如机型、 *** 作系统等)、可靠性需求(不发生故障的概率）、安全保密需求、用户界面需求、资源使用需求(软件运行是所需的内存、CPU等)、软件成本消耗与开发进度需求、预先估计以后系统可能达到的目标。

分析与综合： 逐步细化所有的软件功能，找出系统各元素间的联系，接口特性和设计上的限制，分析他们是否满足需求，剔除不合理部分，增加需要部分。最后综合成系统的解决方案，给出要开发的系统的详细逻辑模型(做什么的模型)。

制订规格说明书： 即编制文档，描述需求的文档称为软件需求规格说明书。请注意，需求分析阶段的成果是需求规格说明书，向下一阶段提交。

评审： 对功能的正确性，完整性和清晰性，以及其它需求给予评价。评审通过才可进行下一阶段的工作,否则重新进行需求分析。

方法

需求分析的方法有很多，这里只强调原型化方法，其它的方法如：结构化方法、动态分析法等，从来没用过这些方法在此不讨论。

原型化方法是十分重要的，原型就是软件的一个早期可运行的版本，它实现了目标系统的某些或全部功能。

原型化方法就是尽可能快地建造一个粗糙的系统，这系统实现了目标系统的某些或全部功能。但是这个系统可能在可靠性、界面的友好性或其他方面上存在缺陷。建造这样一个系统的目的是为了考察某一方面的可行性，如算法的可行性、技术的可行性或考察是否满足用户的需求等。如：为了考察是否满足用户的要求，可以用某些软件工具快速的建造一个原型系统，这个系统只是一个界面，然后听取用户的意见，改进这个原型。以后的目标系统就在原型系统的基础上开发。

原型主要有三种类型：探索型、实验型、进化型。

探索型：目的是要弄清楚对目标系统的要求，确定所希望的特性，并探讨多种方案的可行性。

实验型：用于大规模开发和实现前，考核方案是否合适，规格说明是否可靠。

进化型：目的不在于改进规格说明，而是将系统建造得易于变化，在改进原型的过程中，逐步将原型进化成最终系统。

在使用原型化方法时有两种不同的策略：废弃策略、追加策略。

废弃策略：先建造一个功能简单而且质量要求不高的模型系统，针对这个系统反复进行修改,形成比较好的思想，据此设计出较完整、准确、一致、可靠的最终系统。系统构造完成后，原来的模型系统就被废弃不用。探索型和实验型属于这种策略。

追加策略：先构造一个功能简单而且质量要求不高的模型系统，作为最终系统的核心，然后通过不断地扩充修改，逐步追加新要求，发展成为最终系统。进化型属于这种策略。

需求分析20条法则

客户与开发人员交流需要好的方法。下面建议20条法则，客户和开发人员可以通过评审以下内容并达成共识。如果遇到分歧，将通过协商达成对各自义务的相互理解，以便减少以后的磨擦（如一方要求而另一方不愿意或不能够满足要求）。

1、 分析人员要使用符合客户语言习惯的表达

需求讨论集中于业务需求和任务，因此要使用术语。客户应将有关术语（例如：采价、印花商品等采购术语）教给分析人员，而客户不一定要懂得计算机行业的术语。

2、分析人员要了解客户的业务及目标

只有分析人员更好地了解客户的业务，才能使产品更好地满足需要。这将有助于开发人员设计出真正满足客户需要并达到期望的优秀软件。为帮助开发和分析人员，客户可以考虑邀请他们观察自己的工作流程。如果是切换新系统，那么开发和分析人员应使用一下旧系统，有利于他们明白系统是怎样工作的，其流程情况以及可供改进之处。

3、 分析人员必须编写软件需求报告

分析人员应将从客户那里获得的所有信息进行整理，以区分业务需求及规范、功能需求、质量目标、解决方法和其他信息。通过这些分析，客户就能得到一份“需求分析报告”，此份报告使开发人员和客户之间针对要开发的产品内容达成协议。报告应以一种客户认为易于翻阅和理解的方式组织编写。客户要评审此报告，以确保报告内容准确完整地表达其需求。一份高质量的“需求分析报告”有助于开发人员开发出真正需要的产品。

4、 要求得到需求工作结果的解释说明

分析人员可能采用了多种图表作为文字性“需求分析报告”的补充说明，因为工作图表能很清晰地描述出系统行为的某些方面，所以报告中各种图表有着极高的价值；虽然它们不太难于理解，但是客户可能对此并不熟悉，因此客户可以要求分析人员解释说明每个图表的作用、符号的意义和需求开发工作的结果，以及怎样检查图表有无错误及不一致等。

5、 开发人员要尊重客户的意见

如果用户与开发人员之间不能相互理解，那关于需求的讨论将会有障碍。共同合作能使大家“兼听则明”。参与需求开发过程的客户有权要求开发人员尊重他们并珍惜他们为项目成功所付出的时间，同样，客户也应对开发人员为项目成功这一共同目标所做出的努力表示尊重。

6、 开发人员要对需求及产品实施提出建议和解决方案

通常客户所说的“需求”已经是一种实际可行的实施方案，分析人员应尽力从这些解决方法中了解真正的业务需求，同时还应找出已有系统与当前业务不符之处，以确保产品不会无效或低效；在彻底弄清业务领域内的事情后，分析人员就能提出相当好的改进方法，有经验且有创造力的分析人员还能提出增加一些用户没有发现的很有价值的系统特性。

7、 描述产品使用特性

客户可以要求分析人员在实现功能需求的同时还注意软件的易用性，因为这些易用特性或质量属性能使客户更准确、高效地完成任务。例如：客户有时要求产品要“界面友好”或“健壮”或“高效率”，但对于开发人员来讲，太主观了并无实用价值。正确的做法是，分析人员通过询问和调查了解客户所要的“友好、健壮、高效所包含的具体特性，具体分析哪些特性对哪些特性有负面影响，在性能代价和所提出解决方案的预期利益之间做出权衡，以确保做出合理的取舍。

8、 允许重用已有的软件组件

需求通常有一定灵活性，分析人员可能发现已有的某个软件组件与客户描述的需求很相符，在这种情况下，分析人员应提供一些修改需求的选择以便开发人员能够降低新系统的开发成本和节省时间，而不必严格按原有的需求说明开发。所以说，如果想在产品中使用一些已有的商业常用组件，而它们并不完全适合您所需的特性，这时一定程度上的需求灵活性就显得极为重要了。

9、 要求对变更的代价提供真实可靠的评估

有不同的选择。而这时，对需求变更的影响进行评估从而对业务决策提供帮助，是十分必要的。所以，客户有权利要求开发人员通过分析给出一个真实可信的评估，包括影响、成本和得失等。开发人员不能由于不想实施变更而随意夸大评估成本。

10、 获得满足客户功能和质量要求的系统

每个人都希望项目成功，但这不仅要求客户要清晰地告知开发人员关于系统“做什么”所需的所有信息，而且还要求开发人员能通过交流了解清楚取舍与限制，一定要明确说明您的假设和潜在的期望，否则，开发人员开发出的产品很可能无法让您满意。

11、 给分析人员讲解您的业务

分析人员要依靠客户讲解业务概念及术语，但客户不能指望分析人员会成为该领域的专家，而只能让他们明白您的问题和目标；不要期望分析人员能把握客户业务的细微潜在之处，他们可能不知道那些对于客户来说理所当然的“常识”。

12、 抽出时间清楚地说明并完善需求

客户很忙，但无论如何客户有必要抽出时间参与“头脑高峰会议”的讨论，接受采访或其他获取需求的活动。有些分析人员可能先明白了您的观点，而过后发现还需要您的讲解，这时请耐心对待一些需求和需求的精化工作过程中的反复，因为它是人们交流中很自然的现象，何况这对软件产品的成功极为重要。

13、 准确而详细地说明需求

编写一份清晰、准确的需求文档是很困难的。由于处理细节问题不但烦人而且耗时，因此很容易留下模糊不清的需求。但是在开发过程中，必须解决这种模糊性和不准确性，而客户恰恰是为解决这些问题作出决定的最佳人选，否则，就只好靠开发人员去正确猜测了。

在需求分析中暂时加上“待定”标志是个方法。用该标志可指明哪些是需要进一步讨论、分析或增加信息的地方，有时也可能因为某个特殊需求难以解决或没有人愿意处理它而标注上“待定”。客户要尽量将每项需求的内容都阐述清楚，以便分析人员能准确地将它们写进“软件需求报告”中去。如果客户一时不能准确表达，通常就要求用原型技术，通过原型开发，客户可以同开发人员一起反复修改，不断完善需求定义。

14、 及时作出决定

分析人员会要求客户作出一些选择和决定，这些决定包括来自多个用户提出的处理方法或在质量特性冲突和信息准确度中选择折衷方案等。有权作出决定的客户必须积极地对待这一切，尽快做处理，做决定，因为开发人员通常只有等客户做出决定才能行动，而这种等待会延误项目的进展。

15、 尊重开发人员的需求可行性及成本评估

所有的软件功能都有其成本。客户所希望的某些产品特性可能在技术上行不通，或者实现它要付出极高的代价，而某些需求试图达到在 *** 作环境中不可能达到的性能，或试图得到一些根本得不到的数据。开发人员会对此作出负面的评价，客户应该尊重他们的意见。

16、 划分需求的优先级

绝大多数项目没有足够的时间或资源实现功能性的每个细节。决定哪些特性是必要的，哪些是重要的，是需求开发的主要部分，这只能由客户负责设定需求优先级，因为开发者不可能按照客户的观点决定需求优先级；开发人员将为您确定优先级提供有关每个需求的花费和风险的信息。

在时间和资源限制下，关于所需特性能否完成或完成多少应尊重开发人员的意见。尽管没有人愿意看到自己所希望的需求在项目中未被实现，但毕竟是要面对现实，业务决策有时不得不依据优先级来缩小项目范围或延长工期，或增加资源，或在质量上寻找折衷。

17、 评审需求文档和原型

客户评审需求文档，是给分析人员带来反馈信息的一个机会。如果客户认为编写的“需求分析报告”不够准确，就有必要尽早告知分析人员并为改进提供建议。更好的办法是先为产品开发一个原型。这样客户就能提供更有价值的反馈信息给开发人员，使他们更好地理解您的需求；原型并非是一个实际应用产品，但开发人员能将其转化、扩充成功能齐全的系统。

18、 需求变更要立即联系

不断的需求变更，会给在预定计划内完成的质量产品带来严重的不利影响。变更是不可避免的，但在开发周期中，变更越在晚期出现，其影响越大；变更不仅会导致代价极高的返工，而且工期将被延误，特别是在大体结构已完成后又需要增加新特性时。所以，一旦客户发现需要变更需求时，请立即通知分析人员。

19、 遵照开发小组处理需求变更的过程

为将变更带来的负面影响减少到最低限度，所有参与者必须遵照项目变更控制过程。这要求不放弃所有提出的变更，对每项要求的变更进行分析、综合考虑，最后做出合适的决策，以确定应将哪些变更引入项目中。

20、 尊重开发人员采用的需求分析过程

软件开发中最具挑战性的莫过于收集需求并确定其正确性，分析人员采用的方法有其合理性。也许客户认为收集需求的过程不太划算，但请相信花在需求开发上的时间是非常有价值的；如果您理解并支持分析人员为收集、编写需求文档和确保其质量所采用的技术，那么整个过程将会更为顺利。

“需求确认”意味着什么

在“需求分析报告”上签字确认，通常被认为是客户同意需求分析的标志行为，然而实际 *** 作中，客户往往把“签字”看作是毫无意义的事情。“他们要我在需求文档的最后一行下面签名，于是我就签了，否则这些开发人员不开始编码。”

这种态度将带来麻烦，譬如客户想更改需求或对产品不满时就会说：“不错，我是在需求分析报告上签了字，但我并没有时间去读完所有的内容，我是相信你们的，是你们非让我签字的。”

同样问题也会发生在仅把“签字确认”看作是完成任务的分析人员身上，一旦有需求变更出现，他便指着“需求分析报告”说：“您已经在需求上签字了，所以这些就是我们所开发的，如果您想要别的什么，您应早些告诉我们。”

这两种态度都是不对的。因为不可能在项目的早期就了解所有的需求，而且毫无疑问地需求将会出现变更，在“需求分析报告”上签字确认是终止需求分析过程的正确方法，所以我们必须明白签字意味着什么。

对“需求分析报告”的签名是建立在一个需求协议的基线上，因此我们对签名应该这样理解：“我同意这份需求文档表述了我们对项目软件需求的了解，进一步的变更可在此基线上通过项目定义的变更过程来进行。我知道变更可能会使我们重新协商成本、资源和项目阶段任务等事宜。”对需求分析达成一定的共识会使双方易于忍受将来的摩擦，这些摩擦来源于项目的改进和需求的误差或市场和业务的新要求等。需求确认将迷雾拨散，显现需求的真面目，给初步的需求开发工作画上了双方都明确的句号，并有助于形成一个持续良好的客户与开发人ONT>

需求分析包括这些内容

1

、写出系统的任务和特点

2

、要实现的功能模块和作用

3、

系统结构图

4

、采用的数据库

5

、开发运行环境

"需求分析"，是指对要解决的问题进行详细的分析，弄清楚问题的要求，包括需要输入什么数据，要得到什么结果，最后应输出什么。在软件工程当中的"需求分析"就是确定要计算机"做什么"，要达到什么样的效果。

软件需求 = 业务知识 + 问题列表 + 其他因素。

业务知识：业务事件，业务实体，业务规则。

问题列表：用户在工作中遇到的困难和障碍，也是软件需要解决的问题。

其他因素：设计约束，非功能性需求等。

3111 业务需求

业务需求是系统的高层次目标要求，即系统的建设目标，这种目标通常体现在两个方面：问题和机会。

业务需求的提出通常是高层管理人员，它是团队努力的方向。但如果业务需求过于夸大，可能会导致不必要的资源浪费。

业务需求是在项目立项阶段整理，也就是需求定义的产物。关于业务需求定义的方法，将在“第四章 需求定义最佳实践”中讲解。

3112 用户需求(也叫原始需求)

用户需求是需求捕获的产物，是指用户使用软件需要完成什么任务，怎么完成。通常在业务需求定义的基础上进行调查整理。

用户需求有几个特点：

》零散：用户会提出不同角度，不同层面，不同粒度的需求。

》存在矛盾：由于用户处于企业不同位置，需求具有片面性，不同用户将存在不同观点。

正因如此，我们需要对用户需求进行分析，整理，从而得出更精确的需求说明。

3113 软件需求

软件需求就是用户需求整理后的产物。

业务需求是需求定义的产物，用户需求是需求捕获的产物，软件需求是需求分析与建模的产物。

软件需求可以分为功能需求，非功能需求和设计约束三种类型。

3121 功能需求

功能需求的要点在于如何组织。

对于功能需求的组织形式有以下几种：

》层次结构。在传统方法论中，会以系统-子系统-模块-子模块-功能-子功能的层次结构来组织，这也是一种方法。但它更多是一种程序结构，而非需求结构，它很可能会割裂用户的使用场景。

》RUP方法论中的用例方法。

》敏捷方法论中的用户故事。

》特征驱动开发中的Feature。

笔者建议首选用例方法，详细内容将在“第六章 需求分析与建模最佳实践”中介绍。

3122 非功能需求

对于非功能需求最典型的问题有两个：

》信息传递的无效性：在前面的章节也讲到过，许多需求规格说明书中都有“设计原则”这一章，里面写着：高可靠性，高可用性，高扩展性等要求。但没人真正去看它，因为定性描述是没有判断标准的。所以这种就是信息无效传递。将在“第七章 需求描述最佳实践”中说明解决办法。

》忽略了非功能性需求的局部性。有时会看到“所有查询时间都应该小于10秒”。但当用户执行年度查询时，这是不合理的要求，最终也变成摆设。所以要抓住具体的场景来描述。

非功能需求的要点在于保证信息的有效传递和注意其局部性。

3123 设计约束

设计约束包括非技术因素的技术选型，预期的软硬件环境和预期的使用环境三大类型。

在收集设计约束时，不能出现遗漏：

》非技术因素决定的技术选型。

》预期的软硬件环境。在整理需求时，应该将这些预期的软硬件环境描述出来，最有效的方法就是部署图，将在“第六章 需求分析与建模最佳实践”中讲述。

》预期的使用环境。

完整性，正确性，无歧义性，必要性，有优先次序，可行性，可验证性。这7个标准可以分为4组。

3121 完整性

完整性就是没有遗漏。将来在需求变更时“新需求”占比会较少。但在实际需求活动中，完整性是一个难题。完整性的关键在于以下两个方面：

》用户才是验证需求完整性的合适人选。但是用户往往需求都提不完整，如何对完整性进行验证？问题还是在需求组织结构上。很多人在组织需求时，通常是按照程序结构来梳理，这样做的结构就是用户在验证完整性时遇到障碍，无法直观系统的了解系统是否能满足所有需求。要保证需求的完整性，就必须从业务角度来组织各种需求像，让用户验证需求规格说明书中罗列的主题域，业务事件，业务活动，业务步骤，困难与障碍点是否完整。

业务导向的需求层次结构是保障完整性的关键。

》需求完整性存在不同层面。需求是有层次的，企业中高层，中层， *** 作员所了解和掌握的信息是不一样的， 在验证需求完整性时，需要采用分层评审的方式 ，不同层次的人员评审与自己相关的需求层次。

3122 不失真

需求的正确性和无歧义性就是不失真。

》正确性。要使需求正确，一方面要分层次验证，一方面应该找到直接相关人员进行验证，另一方面，为了避免片面性，还要通过用户调查来补充。更多细节将在“第五章 需求捕获最佳实践”中介绍。

》无歧义性。是指在传递过程中不同的人加入不同的理解。因此光靠文档来传递需求是不充分的，沟通和验证活动能尽量缓解歧义问题。

3123 有优先级

需求有时会戴上“高优先级”的面具，实际上只是担心你不实现而已。

所以引导用户从业务角度划分优先级是最关键的。除业务角度外，也要考虑技术角度和项目管理角度。

》从必要性的角度评价优先级

满意/不满意模型是需求必要性评价的有效手段。

3124 技术人员早期参与

需求规格说明书，来源于用户，提供给技术人员，包括开发和测试。所以与技术团队交流，探讨需求规格存在哪些不足，缺少什么信息，是改进需求规格说明书的有效方法。

》可行性，由开发软对重点需求项，及复杂技术解决方案进行验证。

》可验证性，由测试团队验证。

需求工程包括需求开发和需求管理。需求开发是指收集，分析，整理，编写，验证的全过程，重点在于产出高质量的需求规格说明。需求管理是对需求的实现，变化进行追踪的全过程，重点在于确保开发的软件满足需求。

注意，需求定义并不包含在需求工程中，这是因为需求定义通常叫做项目立项，属于项目管理的范畴。将在“第四章 需求定义最佳实践”中介绍。

现代软件工程的思想更偏向于多次循环，需求工程也不例外，通常需求获取，需求分析，编写规约，需求验证至少要经历三次循环。

对于需求获取，需求分析，编写规约，需求验证这四个活动，将在5-8章中详细介绍，这里只对其核心要点和盲区进行说明。

3221 需求获取(需求捕获)

需求捕获是一个主动的过程，而显示中却常常是比较被动的，主要体现在：

》捕获范围不足：只注重用户要实现什么功能，不注重对业务知识的捕获。

》缺乏计划性：捕获过程随意，预先没有对问题，时间，访谈人员进行计划。

》缺乏科学性：捕获过程比较分散，没有做到定向，聚焦，常常把宏观问题和微观问题混在一起。

》捕获对象不明确：很少主动寻找合适的被访谈者，常常是对方主动指定。

》捕获手段不足：通常认为只有用户访谈和调研会是有效手段，但忽略了不同场景下捕获手段的不同组合将有更好的效果。

“第五章 需求捕获最佳实践”中将详细说明需求捕获的策略，方法和工具。

需求捕获活动中，化被动为主动是关键。

3222 需求分析

需求分析是需求工程中的核心任务，但在实践中常被忽视，也就是捕获的需求直接整理到需求规格说明书中。

》需求分析是什么。需求分析是业务分析，因此要从业务线索入手，而非程序结构；需求分析是一种分解活动，将按职责划分成不同的主题域，再分解到业务流程，再分解到用例；需求分析是一种提炼与整合活动，将原始需求整合到业务活动中，将业务活动整合到全局业务流程图中；需求分析是一种规格化活动。将在“第六章需求分析与建模最佳实践”中详解。

需求分析就是向下分解+向上提炼，外加一些规格化。

》内容和形式

建模语言越来越流程，但一定要理解：分析是任务，建模是手段。建模的过程就是分析的过程。尽量团队建模；大胆使用草图，而不是一上来就开rose。

需求分析是目标，需求建模是手段。

3223 编写规约

编写规约就是需求分析结果文档化的过程。软件需求规格说明书的要点在于：分享，更新。

3224 需求验证

需求验证不是签字，细节将在“第八章 需求验证最佳实践”中阐述。

需求管理包括基线管理，变更管理和需求跟踪三个活动。

需求管理可以分为四步：统一明确的需求项划分标准，引入基线管理，引入变更管理，引入需求跟踪。下面将逐一讲解。

3231 统一明确的需求项划分标准。

》颗粒均匀。即衡量需求工作量的单位是相同的，人天，人月，人周都可以，但是需要统一。

》大小合适。

》完整。最低一级的需求项应该覆盖所有开发任务。

“第六章 需求分析与建模最佳实践”中将具体阐述。

划分出大小合适，颗粒均匀的需求项是需求管理的前提。

3232 引入基线管理

基线管理将需求分为两个部分：已经开始开发的需求(baseline)，还没安排开发的需求(backlog)。(一个基线内容就是Scrum里的一个冲刺)

在划分基线时，通常需要完成三件事：

1 确定优先级，确保高优先级，高风险的需求尽早完成。

2 工作量估算，确保每次迭代的安排是紧凑的。

3 未完成项的合并，每次迭代还是可能有些工作未完成，分配下一次基线时就要考虑进去。

具体将在“第九章 需求基线 *** 作事务”中距离说明。

需求优先级与工作量估算是基线管理的关键。

3233 引入变更管理

变更如果简单地转交给开发人员，会使开发团队变成救火队，陷入大量紧急却不重要的工作中 。所以引入变更管理是非常重要的。就需求管理而言，变更管理的重要在于完成业务影响分析，技术影响分析，项目影响分析三方面工作。具体可以参考“第十章 变更管理 *** 作事务”。

》业务影响分析：从业务角度对变更的合理性，优先级，对原有需求的影响进行分析，以便决定是否纳入backlog中。

》技术影响分析：从技术角度对变更的影响范围，工作量进行分析。

》项目影响分析：基于前面的工作量分析，考虑是否对整个项目的进度成本产生较大影响。

变更管理的核心是控制变更的影响，而非消除变更。

3234 引入需求跟踪

需求跟踪是一种高阶管理活动，将辅助大量的工作量，因此在前三个活动还不是很顺畅时，不建议引入需求跟踪。我们将在“第十一章 需求跟踪 *** 作事务”中介绍。

需求分析人员必须掌握的技能包括：倾听，交谈，提问的技巧，分析，协调，观察，写作，组织，建模，人际交往和创造能力。这些能力可以概括为业务知识，技术知识，沟通能力三个方面。

3241 需求分析人员的来源

推荐是以用户背景的人员(甲方需求人员)为核心，以开发人员作为解决方案的选择和技术论证(乙方需求人员)，领域专家作为顾问。

但在现实中，更多还是以乙方需求分析人员为主角，这时就要充分发挥用户背景的需求人员作为业务支持。

3242 各种能力培养的要点

对于沟通能力方面，在“第五章 需求捕获最佳实践”中有很多案例。

SERU模型分为三个阶段：Subject1-3是需求定义阶段，Event和Report4是理清脉络阶段，User case5是细节填充阶段。

》需求定义阶段：就是项目立项阶段。核心目标在于定义项目目标和范围。主要任务就是划分主题域，并标识出每个主题域中的Event(业务事件)和Report(报表)。

》理清脉络阶段：相当于需求捕获，分析和建模的第一阶段。就是将每个Event(业务事件)，每个Report(报表)进行分析，包括事(流程)，物(业务实体)，人(角色)的分析。

》细节填充阶段，相当于需求捕获，分析和建模的第二阶段。

进行有效的需求分析需要：制定计划和方案。要进行有效的需求分析，需要有具体的计划和方案，需要根据目前自己掌握的情况来确定自己的具体工作内容。有了计划和方案，更利于自己高效完成工作，也知道朝着什么方向努力。

进行有效的需求分析需要：收集更多的数据，要进行有效的需求分析，还是需要以更多的数据作为基础，数据量越多，自己分析的结论越接近现实结果，也更利于自己开展接下来的工作，不管是产品方面还是营销方面，都有很大的帮助。

进行有效的需求分析需要：和一线市场接触，和销售人员接触。要进行有效的需求分析，还需要了解市场，了解客户，知道销售人员每一天都要面对的客户群体是什么样的人，知道自己该怎么去研究客户与市场的需求。

进行有效的需求分析需要：找到切入点。要分析需求，还是需要有切入点，针对不同的客户有不同的方法和策略，而切入点也不一样。所以要具体问题具体分析，同时找到客户相对应的切入点。

进行有效的需求分析需要：安排专业的人来负责。专业的事情交给专业的人来完成，效果更好。尤其是进行需求分析的时候，要有效果有效率，还是要依靠专业人士，他们有知识和技巧，还有丰富的经验和阅历。

进行有效的需求分析需要：组建团队。除了专业的人来负责和指挥，还需要有专业的团队，团队一起来分析需求，会更有效。并且团队成员之间彼此互补，互相帮助和提意见，会让需求分析的结果更好一些。

进行有效的需求分析需要：坚持一定的原则，比如真实性、公正公平性、不虚夸等原则，这些原则会让我们的需求分析更有效，也能让我们在过程中树立正确的工作观和价值观，帮助我们尽快实现需求分析。

需求分析就是发现根本性的问题，设计就是从不同的维度去思考解决方案。

三大要素： 动机、担忧、阻碍。

策略： 强化动机；消除担忧；交互路径的设计减少阻碍。

真实需求的三要素：

·场景：环境对人感知能力的影响（噪音、光线等）；对人心理的影响；

·用户：基础属性；个性特征；个人喜好；

·行为：做什么；怎么做；为什么做；什么时候做；

需求价值判断四要素：

·广度：用户群体有多大，数量、覆盖范围；

·频度：使用的频率；

·强度：需求是否强烈；动机是什么；

·时机：与当前产品的规划进度、产品周期的吻合度；时机是否成熟；

11项目成立的理由：

· 起源于一个问题；

· 起源于减少成本；

·起源于外部法规要求；

·起源于业务机会；

·起源于市场和广告；

·支持业务流程。

12项目的目标：

SMART原则(S=Specific、M=Measurable、A=Attainable、R=Relevant、T=Time-bound)

13与项目相关：

成本与收益；技术上的实现问题；问题和机会；干系人有哪些；目标用户；

14项目风险与业务风险：

应对策略：避免、转移、缓解、接受

15项目与其他项目的联系：

外部依赖，需要其它项目的支持；对其他项目的影响；

16产品的价值：

用户价值：为用户解决什么问题；

商业价值：如何盈利

17业务目的： 功能存在的目的-为什么要做这个功能，用户的直接需求

18业务目标： 如何实现目的-产品的功能、如何呈现

外部：

·用户-用户调研（问卷、访谈、焦点小组、用户测试）、论坛反馈；

·竞品-竞品分析：定位、风格、场景等的差异

·市场-法律法规、政策调整、行业分析报告；

·合作伙伴-客户、业务干系人；

内部：

·产品-数据分析、数据埋点；

·老板-商业目的；

·同事-运营、销售、客服、售后等相关人员；

·自己：创意和联想；

优先级分类：

马斯洛需求理论分类：

KANO模型分类

兴奋型需求：情感化设计

期待型需求：与产品自身的定位、产品目标相结合；

基本型需求：可靠性，产品的主要目的；

无差异需求：有没有无感，可删除；

反向需求：增加之后降低用户体验，类似于广告等商业化运营需求。

属性分类：

·功能类；

·运营类；

·内容类；

·交互类；

·视觉类；

·bug类

波士顿矩阵分类：

明星需求：与公司战略一致，也能给用户带来练好的体验，需要优先开发；

金牛需求：与公司战略一致，但是会损害用户体验，一般会是广告等可以带来收入的需求，需要权衡利害关系，适当地加入；

问题需求：与公司战略不一致，但是能给用户带来好的体验。可以增加用户好感度，积极向公司战略靠拢；

瘦狗需求：与公司战略不一致，也会损害用户体验。需要及时撤掉，不再增加投入；

需求过滤的流程：

设计流程

一般流程：

1-业务流程图：搞清楚有哪些任务。

2-任务流程图：每个任务的具体执行路径、 *** 作流程。

3-信息架构图：产品功能点点划分与分层。要满足每个任务的完成。

4-页面流程图：每个页面包含哪些元素，页面之间如何跳转。

5-低保真原型：页面的布局，交互的细节，不同情况/极端情况的应对。

分析要素： who；why；where；when；how；

需要考虑非功能性需求：

可用性；性能（速度、精度、容量）；安全性；可维护性；可拓展性；可靠性；符合法律法规的标准

如何去完善一句话需求？（上） | 人人都是产品经理

进阶教程！高级设计师都应该掌握的15个数据术语 - 优设网 - UISDC

七步掌握业务分析 (豆瓣)

交互设计师眼中的需求分析 | 人人都是产品经理

什么是卡诺KANO模型？

SMART原则_百度百科

四步搞定需求｜需求获取、需求分析

利用波士顿矩阵分析需求

波士顿矩阵

如何做需求分析

以上就是关于需求工程包含哪些活动软件开发活动中为什么要重视需求工程全部的内容，包括:需求工程包含哪些活动软件开发活动中为什么要重视需求工程、获取用户需求的主要方法、如何做好需求分析，需求调研等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！