需求分析 | 人人都是产品经理----iamsujie需求分析_百度百科
所谓&需求分析&，是指对要解决的问题进行详细的分析，弄清楚问题的要求，包括需要输入什么数据，要得到什么结果，最后应输出什么。可以说，在当中的“需求分析”就是确定要计算机“做什么”，要达到什么样的效果。可以说需求分析是做系统之前必做的。在软件工程中，需求分析指的是在建立一个新的或改变一个现存的时描写新系统的目的、范围、定义和功能时所要做的所有的工作。需求分析是软件工程中的一个关键过程。在这个过程中，员和软件工程师确定顾客的需要。只有在确定了这些需要后，他们才能够分析和寻求新系统的解决方法。需求分析阶段的任务是确定软件系统功能。在软件工程的历史中，很长时间里人们一直认为需求分析是整个软件工程中最简单的一个步骤。但在近十年内，越来越多的人认识到，需求分析是整个过程中最关键的一个部分。假如在需求分析时分析者们未能正确地认识到顾客的需要的话，那么最后的软件实际上不可能达到顾客的需要，或者软件项目无法在规定的时间里完工。
需求分析特点
需求分析是一项重要的工作，也是最困难的工作。该阶段工作有以下特点：
需求分析供需交流困难
在中，其它四个阶段都是面向软件技术问题，只有本阶段是
面向用户的。需求分析是对用户的业务活动进行分析，明确在用户的业务环境中软件系统应该&做什么&。但是在开始时，开发人员和用户双方都不能准确地提出系统要&做什么？&。因为软件开发人员不是用户问题领域的专家，不熟悉用户的业务活动和业务环境，又不可能在短期内搞清楚；而用户不熟悉计算机应用的有关问题。由于双方互相不了解对方的工作，又缺乏共同语言，所以在交流时存在着隔阂。
需求分析需求动态化
对于一个大型而复杂的软件系统，用户很难精确完整地提出它的功能和性能要求。一开始只能提出一个大概、模糊的功能，只有经过长时间的反复认识才逐步明确。有时进入到设计、编程阶段才能明确，更有甚者，到开发后期还在提新的要求。这无疑给软件开发带来困难。
需求分析后续影响复杂
需求分析是软件开发的基础。假定在该阶段发现一个错误，解决它需要用一小时的时间，到设计、编程、测试和维护阶段解决，则要花2.5、5、25、100倍的时间。
因此，对于大型复杂系统而言，首先要进行。开发人员对用户的要求及现实环境进行调查、了解，从技术、经济和社会因素三个方面进行研究并论证该软件项目的可行性，根据可行性研究的结果，决定项目的取舍。
需求分析任务
需求分析的任务是通过详细调查现实世界要处理的对象，充分了解原系统工作概况，明确用户的各种需求然后在此基础上确定新系统的功能。确定对系统的综合要求，虽然功能需求是对软件系统的一项基本需求，但却并不是唯一的需求，通常对软件系统有下述几方面的综合要求。
1.功能需求
2.性能需求
3.可靠性和可用性需求
4.出错处理需求
5.接口需求
7.逆向需求
8.将来可能提出的要求
需求分析数据要求
任何一个软件本质上都是信息处理系统，系统必须处理的信息和系统应该产生的信息很大程度上决定了系统的面貌，对软件设计有深远的影响，因此，必须分析系统的数据要求，这是软件分析的一个重要任务。分析系统的数据要求通常采用建立数据模型的方法。
复杂的数据由许多基本的数据元素组成，数据结构表示数据元素之间的逻辑关系。
利用数据字典可以全面地定义数据，但是数据字典的缺点是不够直观。为了提高可理解性，常常利用图形化工具辅助描述数据结构。用的图形工具有层次方框图和Warnier图。
需求分析逻辑模型
综合上述两项分析的结果可以导出系统的详细的逻辑模型，通常用、E-R图、状态转换图、和主要的处理算法描述这个逻辑模型。
需求分析修正计划
根据在分析过程中获得的对系统的更深入的了解，可以比较准确地估计系统的成本和进度，修正以前定制的开发计划。
需求分析传统方法
- 面向过程（自上向下***）
- 信息工程（数据驱动）（数据流分析结构化分析方法）
- 面向对象（对象驱动）
需求分析步骤
⑴首先调查组织机构情况
包括了解该组织的部门组成情况，各部门的职能等，为分析信息流程作准备。
⑵然后调查各部门的业务活动情况
包括了解各个部门输入和使用什么数据，如何加工处理这些数据，输出什么信息，输出到什么部门，输出结果的格式是什么。
⑶协助用户明确对新系统的各种要求
包括信息要求、处理要求、完全性与完整性要求。
⑷确定新系统的边界
确定哪些功能由计算机完成或将来准备让计算机完成，哪些活动由人工完成。由计算机完成的功能就是新系统应该实现的功能。
⑸分析系统功能
⑹分析系统数据
⑺编写分析报告
需求分析常用类型
⑴跟班作业
通过亲身参加业务工作来了解业务活动的情况。这种方法可以比较准确地理解用户的需求，但比较耗费时间。
⑵开调查会
通过与用户座谈来了解业务活动情况及用户需求。座谈时，参加者之间可以相互启发。
⑶请专人介绍
对某些调查中的问题，可以找专人询问。
⑸设计调查表请用户填写
如果调查表设计得合理，这种方法是很有效，也很易于为用户接受的。
⑹查阅记录
即查阅与原系统有关的数据记录，包括原始单据、账簿、报表等。
通过调查了解了用户需求后，还需要进一步分析和表达用户的需求。
分析和表达用户需求的方法主要包括自顶向下和自底向上两类方法。
需求分析详细分析
从广义上理解：需求分析包括需求的获取、分析、规格说明、变更、验证、管理的一系列。
狭义上理解需求分析指需求的分析、定义过程。
需求分析原因
需求分析就是分析软件用户的需求是什么。如果投入大量的人力，物力、财力、时间，开发出的软件却没人要，那所有的投入都是徒劳。如果费了很大的精力，开发一个软件，最后却不满足用户的要求，从而要重新开发过，这种返工是让人痛心疾首的(相信大家都有体会)。比如：用户需要一个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）创意和求实 毋庸质疑的，每个人都会为自己的一个新的Idea而激动万分，特别是当这个Idea受到一些根本不知道你原本要干嘛的人的惊赞时。但是请注意，当你激动得意的时候，你可能已经忘了你原本是在描述一个需求，而不是在策划一个创意、创造一个概念。很多刚开始做需求分析的人员都或多或少的会犯这样的错误，陶醉在自己的新想法和新思路中，却违背了需求的原始客观性和真实性原则。 永远别忘了：需求不是空中楼阁，是实实在在的一砖一瓦。
（2）解剖的快感 几乎所有搞软件的人，做需求分析的时候，一上来就会把用户告诉你的要求，完完整整的作个解剖，切开分成几个块，再细分成几个子块，然后再条分缕析。可是当用户迷惑的看着你辛辛苦苦做出来的分析结果问你：我想作一个数据备份的任务，怎么做？这时，你会发现，需要先后打开三个窗口才能完成这个任务。 永远别忘了：***是必需的，但最终的目的是为了更好的组合，而不是为了***。
（3）角度和思维 经常听到这样的抱怨：“用户怎么可以提出这样苛刻的要求呢？”。细细一了解，你会发现，用户只不过是要求把一个需要两次点击的功能，改成只有一次点击。这样会导致需要改变需求、改变编码、甚至重新测试，增加工作量。可是，如果换个角度来想想，这个功能，开发的时候只用了几次、几十次，可是用户每天都要用几百次甚 至几千次几万次，改动一下就减少了一半的工作量，对他来说，这样的需求难道会苛刻吗？ 永远别忘了：没有任何需求是不对的，不对的只是你的需求分析。试着站在用户的思维角度想想，你的需求分析就会更加的贴近用户，更加的合理。软件应该是以人为本的。
（4）程序员逻辑 从程序员成长为是一个普遍的轨迹，但并不是一个好的程序员就必然能成为一个好的系统分析员。一些程序员的固化逻辑，使得他们在做需求分析的时候往往钻进了一些牛角里面。比如说1/0逻辑（或者是说黑白逻辑），认为不是这样就是那样，没有第三种情况。可实际情况往往是，在一定的时候是这样，其它时候是那样。又比如穷举逻辑，喜欢上来就把所有一二三可能的情况列举出来，然后一个一个分别处理，每个占用三分之一的时间；可是实际的情况往往是，三分之一的情况占了99%的比例，其它两种情况一年都不会遇到一次。实际中还有很多这样的例子，不一一列举了。 永远别忘了：需求分析和程序设计不尽相同，合理、可行是才是重要的。跳出程序设计的圈子，站在系统的角度上来看问题，你的结论会截然不同。
需求分析案例
（1）需求分析报告的编写目的
本需求分析报告的目的是规范化本软件的编写，旨在于提高软件开发过程中的能见度，便于对软件开发过程中的控制与管理，同时提出了本铁路的软件开发过程，便于程序员与客户之间的交流、协作，并作为工作成果的原始依据，同时也表明了本软件的共性，以期能够获得更大范围的应用。
（2）产品背景明细
软件名称：铁路售票系统
（3）缩写及缩略语
铁路售票应用系统软件：基本元素为构成铁路售票及相关行为所必须的各种部分。
需求：用户解决问题或达到目标所需的条件或功能；系统或系统部件要满足合同、标准，规范或其它正式规定文档所需具有的条件或权能。
需求分析：包括提炼，分析和仔细审查已收集到的需求，以确保所有的风险承担者都明其含义并找出其中的错误，遗憾或其它不足的地方。
模块的独立性：是指软件系统中每个模块只涉及软件要求的具体的子功能，而和软件系统中其他的模块的接口是简单的。
本工程描述：
（1）软件开发的目标：
完善铁路，使之能跟上时代的发展。同时通过实践来提高自己的动手能力。
（2）应用范围：
理论上能够实现于铁路部门的售票系统，其目的在于在原有的系统基础使得铁路售票实名化，以期实现完善日常生活中铁路售票的各种缺陷。
企业信用信息产品需求文档 - 产品经理@唐杰
标签：产品需求文档
,,,,,,,,,,
,,,,,,,,,,
,,,,,,,,,,,,,,,需求管理_百度百科
假定生产要素的供给为既定的条件下对总需求的调整和控制。根据的国民收入均衡分析，由于社会总就业量取决于总需求和总供给的均势，如果在短期内生产技术、资本设备的数量和质量、劳动力的数量和技能等不变，即假定总供给不变，则经济调节的重点就应在总需求一边。按照的说法，在通常的情况下，经济中的有效需求是不足的。所以，充分就业状态下的国民收入均衡不可能自行实现，而只有通过对总需求，即对有效需求的管理，才能实现充分就业均衡。
需求管理简介
需求管理（Requirement management）是完整管理模式中的一环，同其他特性诸如完整性、一致性等不可分割，彼此相关而成一体。一套需求管理应当是已知系统需求的完整体现，每部***决方案都是对总体需求一定比例的满足（甚至是充分满足），仅仅解决部分需求是没有意义的。对关键需求的疏忽很可能是灾难性的，试想一架飞机的安全设计不过关将会带来什么样的后果。不同的需求组合起来，构成了一套完整的需求模型。用户需求决定了系统设计所要解决的问题，所要带来的结果。可以说，需求管理指明了系统开发所要做和必须做的每一件事，指明了所有设计应该提供的功能和必然受到的制约。 需求管理的过程，从需求获取开始贯于整个，力图实现最
需求管理相关图片
终产品同需求的最佳结合。通过对需求管理在项目进程中实施的不同任务进行分析，我们可以看出需求管理所起的作用。[1]
需求管理本就是一个动态的过程，离开了能动的、变化的系统进程而空谈需求管理，无异于纸上谈兵。
需求管理恰如裁缝的量体裁衣，它直接关系到最终产品的成型。仅从字面出发，如果一个产品满足了客户需求，那它无疑就是成功的。需求管理的过程，从开始贯穿整个项目始终，力图实现最终产品同需求性的最佳结合（参见1）。
需求管理能够确证：
●我们确知客户的需求是什么（质量）；
●满足客户需求的最佳解决办法（统一性）；
著名学者Crosby对于质量的定义是&同需求保持统一&。从这个意义上说，需求管理正是从质量出发以确定需求。每个人都应当始终明白他们所做的具体任务其意义何在。然而，在一个产品的生命周期里，其需求性是能动的，是处于变化之中的。
对于系统工程没有严格统一的定义，因此很难找到足够的数据以说明系统工程所起的作用。有些致力于研究需求分析的组织认为，一项开发计划应当至少将8-15%的资源投入到系统工程方面。如果低于这一标准，将很可能导致无法对客户群做出准确把握。如果该项开发计划含有许多创新或实验的成分，那么这一百分比还应当适度提高。
需求管理概述
需求管理定义需求
（Define Requirement） 在项目进展过程中，如何区分用户需求与需求分析中需求定义呢？
当完成用户需求调查后，首先对《用户需求说明书》进行细化，对比较复杂的用户需求进行分析，以帮助软件开发人员更好地理解需求。例如采用的Rose工具进行需求的建模分析。如果使用工具进行建模分析，对需求分析人员的要求比较高。需求定义过程中通常会出现的问题有内容失实、遗漏、含糊不清和前后描述不一致。
当完成需求的定义及分析后，需要将此过程书面化，要遵循既定的规范将需求形成书面的文档，我们通常称之为《需求分析说明书》。
邀请同行专家和用户（包括客户和最终用户）一起评审《需求规格说明书》，尽最大努力使《需求规格说明书》能够正确无误地反映用户的真实意愿。需求评审之后，开发方和客户方的责任人对《需求规格说明书》作书面承诺。具体的同行评审详见需求评审章节。
需求管理需求确认
(Requirement Validate) 需求确认是需求管理过程中的一种常用手段，也是需求控制的五一节之一；确认有两个层面的意思，第一是进行系统需求调查与分析的人员与客户间的一种沟通，通过沟通从而对需求不一致的进行剔除；另外一个层面的意思是指，对于双方达成共同理解或获得用户认可的部分，双方需要进行承诺。
需求管理建立状态
(Establish Requirement State) 何谓需求状态；顾名思义，状态也就是一种事物或实体在某一个时刻或点所处的情况，此处要讲的需求状态是指用户需求的一种状态变换过程。
为什么要建立需求状态？在整个生命周期中，存在着几种不同的情况，在需求调查人员或系统分析人员进行需求调查时，客户存在的需求可能有多种，一类是客户可以明确且清楚的提出的需求；一类是客户知道需要做些什么，但又不能确定的需求；另一类是客户本身可以得出这类需求，但需求的业务不明确，还需要等待外部信息。还有是客户本身也说不清楚的。
对于这些需求，在开发进展的过程中，存在著以下几种情况:
有可能要取消的
有的因为不明确而可以后延的，同时可能转化为被取消的需求
与客户经过沟通或确认的，此处有两种情况，一类是确认双方达成共识，另一种情况是还需要再进一步沟通的。
下面是一个简单的状态例子：
CLOSED：经过确认，双方认可并达成共识；
OPEN:双方确认，但没有达成共识的需求；
待定：客户提出需求，但双方没有经过沟通或确认；
需求管理需求评审
(Requirement Review) 对工作产品的评审有两类方式，一类是正式技术评审，也称同行评审，另一类是非正式技术评审。对于任何重要的工作产品，都应该至少执行一次正式技术评审。在进行正式评审前，需要有人员对其要进行评审的工作产品进行把关，确认其是否具备进入评审的初步条件。
需求评审的规程与其它重要工作产品（如系统设计文档、）的评审规程非常相似，主要区别在于评审人员的组成不同。前者由开发方和客户方的代表共同组成，而后者通常来源于开发方内部。
有人问：需求评审究竟评审什么？要细到什么程度？怎么样进行？
严格地讲，应当检查需求文档中的每一个需求，每一行文字，每一张图表。评判需求优劣的主要指标有：正确性、清晰性、无二义性、一致性、必要性、完整性、可实现性、可验证性、可测性。如果有可能，最好可以制定评审的。
需求评审面临的困难及对策如下：
需求评审的一个通病是“虎头蛇尾”。需求评审的确乏味，也比较费脑子。刚开始评审时，大家都比较认真，越到后头越马虎。当需求文档很长时，几乎没人能够坚持到最后。会议主持人事先要强调需求评审的重要性：认真评审一小时可能会避免将来数十天的“返工”，让大家足够重视。评审组长还要设法避免大家在昏昏沉沉中评审。如果评审时间比较长，建议每隔两小时休息一次。另外，如果系统比较大，也可以细分成不同的部分分别进行，严格控制每一次评审的文档规模及持续时间。
需求评审涉及的人员可能比较多，有些时候让这么多人聚在一起花费比较长的时间开会并不容易（例如有些人可能出差在外，有些人可能事务缠身）。没有必要把所有事情挤在一块做，需求开发是循序渐进的过程，需求评审也可以分段进行。这样每次评审的时间比较短，参加评审的人员也少一些，组织会议就比较容易。对于需求的工作产品《需求规格说明书》，我们可以标明几种文档状态，如草稿状态，评审状态，初始状态等。只有进入评审状态时，我们可以用不同的方式来对文档进行评审。但当其评审状态转化为初始状态时，需要进行严格的正式的同行评审。
开评审会议时经常会“跑题”，导致评审效率很低。有时话匣子一打开后关不上，大家越扯越远，结果评审会议变成了聊天会议。主持人应当控制话题，避免大家讨论与主题无关的东西。对于自主研发的产品，由于需求评审人员大部分是开发人员，大家会不知不觉地谈论软件“如何做”。由于需求是否“可实现、可验证、可测试”本来就属于需求评审的范畴，所以强制大家“只谈做什么，不谈怎么做”几乎是不可能的。那么，在需求的评审会上，需要允许开发人员谈如何做，但不需太细，适而可止。同时，评审会必须明确一位评审组长，对时间与问题进行控制。
开评审会议时经常会发生争议。适当的争议有利于澄清问题，比什么东西都一致赞成要好。然而当争议变为争吵时就坏事了。争吵不仅对评审工作没有好处，而且会无意中伤害同事们的感情。同时也解决不了问题。所以，在评审会的过程中，我们要尽可能的是在阐述事实与证据，而并不是从你心底要如何地说服别人。
人们在很多时候分不清楚自己究竟是“坚持真理”还是“固执己见”。毫不妥协或者轻易妥协都不是好办法。我们应当养成良好的习惯：不要一棍子打死异己的观点，尝试着让自己站在他人的立场思考问题，这样你会找到比较满意的***。试著从不同的角度去看同样的问题。
{项目名称}评审报告_需求
工作产品。版本号
名称，标识符，版本，作者，时间
工作产品标识号
第几次评审
工作产品存放路径
评审人员名字
工作单位或部门
问题记录及处理意见
【 】 工作产品合格，“无需修改”或者“需要轻微修改但不必再审核”。
【√】 工作产品基本合格，需要作少量的修改，之后通评审组长检查即可。
【 】 工作产品不合格，需要作比较大的修改，之后必须重新对其评审。
需求管理需求承诺
（Requirement Consent） 什么是需求承诺，是指开发方和客户方的责任人对通过了同行评审的需求阶段的工作产品，作出承诺，同时该承诺具有商业合同的同等效果。 需求承诺如下：
XXX项目需求文档_《XXX需求说明书》，版本号：X.X.X,是建立在XXX与XXX双方共同对需求理解的基础之上，同意后续的开发工作根据该工作产品开展。如果需求发生变化，双方将共同遵循项目定义的“变更控制规程”执行。需求的变更将导致双方重新协商成本、资源和进度等。
不少人会草率地??面签字吗，反正已经评审过了，我就签吧。但他将来变更需求时可能会表示不瞒：“不错，我是签字了，但是我并没有阅读文档。是你们要我在文档上签字的，我是相信你们才这么做的。”为了避免发生此类纠纷，人们在作出承诺之前务必要认真阅读文档，一定要明白签字意味着什么。
需求管理需求跟踪
(Requirement Track) 为什么要进行？在整个开发过程中，进行需求跟踪的目的是为了建立和维护从用户需求开始到测试之间的一致性与完整性。确保所有的实现是以用户需求为基础。对于需求实现是否全部的覆盖。同时确保所有的输出与用户需求的符合性。
需求跟踪有两种方式，正向跟踪与逆向跟踪：
正向跟踪：以用户需求为切入点，检查《用户需求说明书》或《需求规格说明书》中的每个需求是否都能在后继工作产品中找到对应点。
逆向跟踪：检查设计文档、代码、等工作产品是否都能在《需求规格说明书》中找到出处。
正向跟踪和逆向跟踪合称为“双向跟踪”。不论采用何种跟踪方式，都要建立与维护《需求跟踪》。需求跟踪矩阵保存了需求与后续开发过程输出的对应关系。矩阵单元之间可能存在“一对一”、“一对多”或“多对多”的关系。见下表：简单的需求跟踪矩阵示例。
需求规格说明书V1.0
设计文档V1.2
标题或标识符
标题或标识符
代码文件名称
　测试用例标识或名称
简单的需求跟踪矩阵示例1
使用需求跟踪矩阵的优点是很容易发现需求与后续工作产品之间的不一致，有助于开发人员及时纠正偏差，避免干冤枉活。
很多人有这样的误解：如果依照“需求开发－系统设计－编码－测试”这样的顺序开发产品，由于每一步的输出就是下一步的输入，所以不必担心设计、编程、测试会与需求不一致，因此可以省略需求跟踪。那么，需要指正的是，按照严格线性顺序的开发模型并不能保证各个开发阶段的工作产品与需求保持一致。需求开发包括获取分析需求，需求定义，从所有方面核查和验证需求。因为开发者是人而不是机器。而且，大多数开发人员也都深有体会。
生活中“以讹传讹”的例子，想必大家都很熟悉。学生甲在精工实习时被机器弄破了手指，于是到医院包扎。同学乙路过医院时看到甲的手血迹斑斑，以为甲的手指被机器割断，于是将这个坏消息告诉同学丙。丙急忙转告同学丁，说甲的手被机器割断，正躺在医院里。丁十万火急地告诉全班同学，大家陷入悲痛之中，都以为“甲的胳膊被机器割断了，正躺在医院里，人快不行
需求管理相关图片
由于人们的表达能力、理解能力不可能完全相同，人与人之间的协作很难达到天衣无缝的境界。而使用需求追溯的本身也是一种传递的过程。
需求追溯本身并不是一件复杂的事，而是我们的本身一种理念在支配著我们。也许就有人认为这本身就是在浪费时间，主要麻烦是，当需求或工作产品发生变更时，开发人员要及时更新需求跟踪矩阵。然而没想到的事，如果后来再花时间来做同样的事的时候，将会付出更多。也时也就丢去了本身做这件事的意义。
需求管理变更控制
(Requirement Change Control) 需求变更通常会对项目的进度、人力资源产生很大的影响，这是开发商非常畏惧的问题。也是必须面临与需要处理的问题。作为软件项目，特别在外地实施的项目而言，需求发生若干次变更似乎是不可避免的。需求发生变更的起因主要有：
随着项目生命周期的不断往前推进，人们（包括开发方和客户方）对需求的了解越来越深入。原先的提出的需求可能存在著一定的缺陷，因此要变更需求。
市场业务需求发生了变化，原先的需求可能跟不上当前的市场业务发展，因此要变更需求。由于市场变化而导致需求发生变更，开发商大可不必为此烦恼，应当高兴才对。倘若市场静如死水，那么开发商吃了“上一顿”就没有“下一顿”。正因为市场在变化，才会产生更多商机，聪明的开发商才会有活干，有钱赚。
如果在项目开发的初始阶段，开发人员和用户没有搞清楚需求或者搞错了需求，到了项目开发后期才将需求纠正过来，导致产品的部分内容需要重新开发。毫无疑问，这种需求??方工作失误造成的，双方应当好好反省，认真学习需求开发和管理的方法，避免再犯相似的错误。
总的而言，人们提出需求变更，本就是出于能够使产品更加符合市场或客户需求，出发点本身是好的。但对于开发小组而言，需求的变更则意味着要需要重新进行估计，调整资源、重新分配任务、修改前期工作产品等，而作为开发商，需要增预算与投资，开发组要为此付出较重的代价。假定每次需求都被接受的话，那么这个项目将会成为一个连环式的工程。
需求变更控制的动机是：
如果需求变更带来的好处大于坏处，那么允许变更，但必须按照已定义的变更规程执行，以免变更失去控制。
如果需求变更带来的坏处大于好处，那么拒绝变更。
当然，好处与坏处并不是主观的，而是通过客观的分析与评价而得出的。
对于需求的变更，在某一个程度上来说，也就是项目的范围进行了变化。而需求同时又是项目进行的基础。是非常得要的基石。通常对于需求的变更需要客户与开发方共同参与，包括负责人及市场人员。当然，我们需要根据变更的内容来灵活运用。
需求变更控制过程中最难办的事情是莫过于“拒绝客户提出的需求变更请求”。客户会想当然地以为变更需求是他的权利，因为他付钱给开发方。通常情况下开发方是不敢得罪客户的，但是无原则地退让将使开发小组陷入困境。怎么解决这个问题呢，通常情况下，每一类“游戏”都有一定的游戏规则，那么我们事先也需要建立“游戏规则”。
如果事先没有“游戏规则”的话，开发方的负责人需要一些社交技巧来减缓矛盾。例如首先承认客户提出的需求变更请求是合理的，再阐述己方的难处，最后建议在开发该产品新版本时修改需求。这种方式比直接拒绝有效得多，既不得罪客户，又为自己争取了余地。
另外还有一种方法，可以将变更需求先进行记录，并通知给客户，当其需求变化在开发组不能接受的范围时，可以通过市场进行相关的协调。
需求变更本是正常的，并不可怕，可怕的是需求的变更得不到控制。
需求管理管理原因
避免失败就是一个很充分的理由.提高项目的成功率和需求管理所带来的其他好处同样也是理由.Standish Group 的 CHAOS 报告进一步证实了与成功项目关系最大的因素是良好的需求管理.
理解需求管理的第一步就是对什么是需求管理达成共识.Rational 把需求定义为&(正在构建的)系统必须符合的条件或具备的功能&.电气和电子工程师学会使用的定义与此类似. 著名的设计师 Merlin Dorfman 和 Richard H. Thayer 提出了一个包容且更为精练的定义,它特指软件方面 - 但不仅仅限于软件:
&可定义为: 用户解决某一问题或达到某一目标所需的软件功能. 系统或系统为了满足合同,规约,标准或其他正式实行的文档而必须满足或具备的软件功能.
由于需求是正在构建的系统必须符合的事务,而且符合某些需求决定了项目的成功或失败,因此找出需求是什么,将它们记下来,进行组织,并在发生变化时对它们进行追踪,这些活动都是有意义的. 换句话说,需求管理就是：一种获取,组织并记录系统需求的系统化方案,以及一个使客
需求管理相关图片
户与项目团队对不断变更的系统需求达成并保持一致的过程.
这个定义与 Dorfman 与 Thayer 以及的&软件需求工程&的定义相似.需求工程包括获取,分析,规定,验证和管理软件需求,而&软件需求管理&则是对所有相关活动的规划和控制.这里介绍的以及 IBM Rational提出的需求管理定义包括了所有这些活动.它们的区别主要在于这里选用了&管理&这个词,而不是&工程&.管理这个词更合适用来描述所有涉及到的活动,并且它准确地强调了追踪变更以保持涉众与项目团队之间共识的重要性.
对那些不熟悉&引出&这个词的人来说,它可定义为团队用来获取或发现涉众请求,确定请求后隐藏的真正需要,以及为满足这些需要对系统提出的一组适当需求.
需求管理问题 一个目的在于确保系统符合人们对其期望的流程面临着哪些困难呢 当它真正在实际项目实施时,困难就暴露出来了.图 1 显示了年对开发人员,经理和人员所做的一次调查结果.该图显示了经历过最常提到的需求相关难题的受访者比例.
需求管理需要原因
简单地说,系统开发团队之所以管理需求,是因为他们想让项目获得成功.满足项目需求即为成功打下了基础.若无法管理需求,达到目标的几率就会降低. 以下最近收集的证据很有说服力: Standish Group 从 1994 年到 2001 年的 CHAOS Reports 证实,导致项目失败的最重要的原因与需求有关. 2001年,Standish Group 的CHAOS Reports报导了该公司的一项研究,该公司对多个项目作调查后发现,百分之七十四的项目是失败的,既这些项目不能按时按预算完成.其中提到最多的导致项目失败的原因就是&变更用户需求&.
需求管理与需求有关的问题:
需求不总是显而易见的,而且它可来自各个方面. 需求并不总是容易用文字明白无误地表达. 存在不同种类的需求,其详细程度各不相同. 如果不加以控制,需求的数量将难以管理. 需求相互之间以及与流程的其他可交付工件之间以多种方式相关联. 需求有唯一的特征或特征值.例如,它们既非同等重要,处理的难度也不同. 需求涉及众多相关利益,这意味着需求要由跨职能的各组人员来管理. 需求发生变更. 需求可能对时间敏感. 当这些问题与需求管理和处理技能不足以及缺乏易用工具等情况一同出现时,许多团队都对管理好需求不抱希望了.IBM Rational 已经开发出指导团队提高需求管理技能和流程的专业技术,并使用相应的工具使得上述的流程和专业技术得以实现.
从上述的分析可以看出,需求的捕获是需求管理的基础和前提.在这里,将介绍一种为业界所广泛采用并经验证的需%E4%BE%8B%E6%A8%A1%E5%9E%8B target=&_new& class=innerlink&用例模型. 用例模型是系统既定功能及系统环境的模型,并作为客户和开发人员之间的契约.
用例模型用作分析,设计和测试活动的基本输入.用例是贯穿整个系统开发的一条主线.同一个用例模型即为需求程的结果,可当作分析设计工作流程以及测试工作流程的输入使用.参与者(Actor)和用例(UseCase)是用例模型中的主要元素. 下图显示了自动取款机系统用例模型的一部分:
客户身份验证
数据库服务器
(from )系统维护
信函打印机
打印对帐单
用于显示包含参与者和用例的用例模型示例.系统建模有许多种方法,每种建模方法可以满足不同的目的.然而,用例模型最重要的作用是将系统行为传达给客户或最终用户.可能与该系统交互的用户和任何其他系统都是参与者.由于参与者代表了,它们协助界定系统并提供十分明确的系统用途说明.编写用例依据参与者的需求来进行.这样就确保该系统成为用户期望得到的系统.
参与者和用例都是通过将客户需求及潜在用户当作重要的信息查找到的.找到这些用例和参与者后,应对它们作简要说明.在详细说明这些用例之前,客户应该用例模型以核实所有的用例和参与者都已经找到,并且它们可以提供客户所需要的东西. 在迭***发环境中,您可以选择用例的子集以便在每个迭代中详细描述.参与者和用例找到后,需要详细说明每个用例的事件流.这些说明指出系统与参与者交互的方式以及在各个独立用例中系统执行的有关操作.
最后,对已完成的用例模型(包括用例说明)进行复审,开发人员和客户使用该模型对系统应执行的操作达成一致意见.
需求管理管理模型
在需求管理的流程中,需求的捕获手段固然重要,但在需求的捕获和需求最终成型的过程中,我们会面临各种和需求相关的信息和资料(也可以把这些信息笼统地称做&需求&),如何发现这些信息之间的关系并有效组织,更为关键. 需求类型 在中,我们采用一种金字塔方式的管理办法,来组织和管理我们获取的信息乃至最终的需求.
为了建立一个真正满足客户需求的系统,项目团队首先必须确定系统要解决的问题.然后,团队必须确定涉众,从中获得业务和用户需要,对其进行描述,并区分它们的优先级.从这一组高层期望或需求出发,对产品或系统特性集达成一致意见.而后,由产品特性来抽取软件需求,在我们的模型中,软件需求是以用例模型的方式来描述.从测试的角度来看,测试项一定来自于软件需求,即软件需求中确定了哪些需求项,测试就要根据这些需求项来制定和实现.
系统越大越复杂,出现的需求类型就越多.一个需求类型不过是指需求的一个类.通过确定需求类型,团队可以把大量需求组织成意义明确且更容易管理的组.在一个项目中建立不同类型的需求有助于团队成员对变更请求进行分类,并使相互之间的沟通更为清楚明确.从上述的分析中我们可以看到,通常,一类需求可以细分即***成其他类型的需求.这里,我们就把需求***为几种类型,并在他们
探究需求管理的本质
之间建立相应的关联.业务规则和前景声明包括高层次的需求,团队可以从中导出用户需要,特性和产品需求类型.用例和其他建模形式驱动设计需求,该需求可***为软件需求,并可以用分析来说明.测试需求源于软件需求,它被***为具体的测试过程.如果既定项目中有成百上千个,甚至上万个需求实例时,对需求进行分类可以使项目更容易管理.上述的这些需求类型同时保存在对应的RUP文档和数据库中
需求预测模型
1.主观判断预测。主观判断预测涉及利用主观判断和直觉，适用于数据有限或无历史数据的情况，例如引入新产品。主观判读预测技术包括调研和类比技术等。
2.时间序列预测。其基本假设是未来需求仅由过去需求决定。时间序列预测技术包括但不限于简单移动平均.
和加权移动平均。
3.因果预测。因果预测假设一个或多个因素与需求相关，而因果关系可用来估计未来的需求。
需求管理应用类型
通过定义需求类型,以及他们之间的关系,我们就建立了一个需求管理模型的框架.当然,我们建立这样的一个模型,是为了方便我们使用需求,为了达到这一目的,我们还需要在此基础上添加相应的内容. 需要对各种需求类型添加它们的属性,以便于对需求进行查询等管理手段.比如,可以针对用户需要,确定该需要的必要性,优先级,确定性等属性.在实际的项目中,就可以确定这些属性的值,而后根据这些实际属性值来安排项目的进度表等.或是在项目进度紧急时,确定哪些需求是可以延期完成,而哪些是必须完成的,等等.
需求的追踪性 其次,可以根据不同需求的导出情况,在不同的需求之间建立追踪关系.譬如,用户需要决定了要构建产品的特性,产品的特性又决定了产品的软件需求,等.在这些不同类型的需求之间建立关联,一旦其中的某些需求发生变化,就可以确定它可能带来的影响,从而制定相应的策略.
需求管理工作流程
工作流明细简介
需求管理问题分析
问题分析可以通过了解问题及涉众的最初需要,并提出高层解决方案来实现.它是为找出&隐藏在问题之后的问题&而进行的推理和分析.问题分析期间,将对&什么是面临实际问题&和&谁是涉众&等问题达成一致.而且,您还要从业务角度界定解决方案,以及制约该解决方案的因素.您应该已经对项目进行过商业理由分析,这将便于您更好地预计能从构建中的项目中得到多少投资回报.
需求管理理解涉众
需求来自各个方面,比如来自客户,合作伙伴,最终用户或是某领域的专家.您需要掌握如何准确判断需求应来源于哪方面,如何接近这些来源并从中获取信息.提供这些信息主要出处的个人在本项目中称为涉众.如果您正在开发一个在您公司内部使用的,那么在开发团队中应包括具有最终用户经验和业务领域的人员.通常讨论将在业务模型这一级上展开,而不是在系统这一级上展开.如果正在开发一个要在市场上出售的产品,那么您可以充分调动营销人员,以便更好地了解该市场中用户的需要. 获取需要的活动可使用这样一些技巧:访谈,集体讨论,概念,问卷调查和竞争性分析等.获取结果可能是一份图文并茂的请求或需要列表,并按相互之间的优先级列出.
需求管理定义系统
定义系统指的是解释涉众需求,并整理为对要构建系统的意义明确的说明.在的初期要确定以下内容:需求构成,文档格式,语言形式,需求的具体程度(需求量及详细程度),需求的优先级和预计工作量(不同人在不同的实践中通常对这两项内容的看法大不相同),技术和管理风险以及最初规模.系统定义活动还可包括与最关键的涉众请求直接联系的初期原型和设计模型.系统定义的P&
需求管理项目规模
为使项目高效运作,应仔细根据所有涉众的需求确定优先级,并对项目规模进行管理.有的开发人员仅仅重视所谓的&复活节彩蛋&(即开发人员感兴趣或觉得有挑战性的特性),而不是及早将精力投入降低或提高应用程序构架稳定性方面,这已使太多的项目蒙受损失.为确保尽早解决或降低项目中的风险,应以递增的方式开发系统.要慎重选择需求,以确保每次增加都能缓解项目中的已知风险.要达到目的,您需要和项目的涉众协商每次迭代的范围.通常,这要求具备管理项目各个阶段的期望结果的良好技能.
除了控制开发过程本身,您还需控制需求的来源,并控制项目可交付工件的外观. 改进系统定义 系统的详细定义应能让涉众理解,同意并认可.它不仅需要具备所有功能,而且应符合法律或法规上的要求,符合可用性,可靠性,性能,可支持性和可维护性.感觉构建过程复杂的系统就应该有复杂的定义,这是一种常见的错误看法.这会给解释项目和系统的目的造成困难.人们可能印象深刻,但他们会因不甚理解而无法给出建议.应该致力于
了解您制作的系统说明文档的读者.您可能常会发现需要为不同的读者准备不同的说明文档.
我们认为用例方法是传达系统目的和定义系统细节的一种行之有效的方法,它常与简单的可视化原型结合使用.用例有助于为需求提供一个环境,利用它可生动地说明系统使用的方式.
系统详细定义的另一个构件是说明系统采用的测试方式.测试计划及要执行测试的定义将会说明要核实哪些系统功能.
需求管理需求变更
定义需求时无论怎样谨慎小心,也总会有可变因素.变更的需求之所以变得难以管理,不仅是因为一个变更了的需求意味着要花费或多或少的时间来实现某一个新特性,而且也因为对某个需求的变更很可能影响到其他需求.应确保赋予需求一个有弹性的结构,使它能适应变更,并且确保使用可追踪性链接可以表达需求与开发生命周期的其他工件之间的依赖关系.管理变更包括建立,确定需要追踪的重要依赖关系,建立相关项之间的可追踪性,以及变更控制等活动.
需求管理任务
可以说需求是一种模型，是产品的早期雏形，通过进行需求分析，我们可以对最终产品做出优化。需要始终保持注意的是，需求性是始终处于变化之中的。需求管理需要完成的任务包括：
●明确需求并达成共识；
●建立关联；
●根据不同需求设计相应解决办法；
●提出设计方案；
●监控和解决可能出现的问题以及需要做出的改变；
●控制不同开发任务的开展；
●对最终产品做出评测；
●监控可能出现的重复开发；
●提出项目实施时间表；
●确定最终用户界面。
有时候我们所进行的需求分析只停留于分析本身，而没有进一步去思索我们为什么要进行需求分析。需求性是项目开发的源头，只有进行认真的需求分析，我们才能做到对症下药、量体裁衣，才能才设计开发中去伪存真，不断改进。&需求之需求&正是强调了贯穿始终的需求分析的重要。离开了能动的、变化的系统进程而空谈需求管理，无异于纸上谈兵。需求管理所产生的效益或许并不明显，或许要日后才能体现，但是无序的，没有经过精心策划的需求管理是不可能产生效益的。
以下篇幅分别介绍需求管理在系统工程中的不同应用。
需求管理需求共识
首先，用户需求通过非术语的形式进行表述，这种表述应当使每一位开发者明确自己的职责所在，并且清楚知道不同开发工作之间的关联。这里的&用户&泛指在实际应用环境中每一位可能使用最终产品的人。如果一个产品不能满足客户所需，那么设计方案再出色也无济于事，许多方案有很高的水准却最终不能获得成功，其原因正在于此。可以把产品功能说得天花乱坠，但却无法改变用户需求决定最终产品基本模式的事实。
进行迭代需求管理
需求管理的首要任务在于使开发人员和用户双方对于需求都有一个明确的认识。因此用来进行需求分析的语言组织应当使所有相关人员，包括用户，都能够理解，都能够进而对整个项目有一个整体把握，并明确每一个人在项目中所起的作用。因而需求管理需要解决的第一位也是最基本的任务就是明确需求，并使所有相关人员达成共识。
根据需求设计解决办法
我们在进行系统设计时，应当首先建立一个需求模型，但不能是为了建模而建模，需求模型实际是最终产品的抽象化表现。需求模型的建立使我们在明确需求的基础上更进一步，使我们知道我们将要生产何种产品，该产品都具有那些功能。同时，创建需求模型的过程也使开发者明确自己的工作如何同整个项目有机地结合在一起。建立需求模型应当充分研究不同类型、不同架构建模方式的可行性，切忌主观武断。
需求管理系统优化
任何设计都应以考虑用户需求为优先，用户需求的满足程度即成为衡量设计优劣的标准。在一个项目设计周期中，开发人员经常会面临选择，以提炼需求，决定开发的优先次序，并在不同的实施方案中作出选择。这些选择必须考虑到收益与付出地平衡比例，这种选择的重要性尤其在建立需求模型的后期凸现出来。基本需求在这时都已明确，而实施方案还未敲定，为了使用户的基本需求得到落实，一定程度的开销用于搭建不同构架的需求模式是合理的。假使我们已经有了一套翔实的需求分析，我们甚至不必将每一套方案都付诸实行，就可以成功地对系统设计进行优化。
面对不同的可行性而需要作出选择时，我们也必须参照收益与付出的比例关系。例如，在被要求提供计划书时（Request for Proposal），我们应当尽量做到每一份计划书的提供都物有所值。
需求管理方案设计
明确需求后，开发人员就可以进行方案设计。通过对用户需求和设计方案之间所存在关联性进行分析比较，我们就能够对设计方案进行评估。
需求管理修改
方案的设计不可能是一成不变的，经常会有方案设计同需求相悖的情况。如果我们无法准确把握用户需求同方案设计之间的关系，我们就无法在需要对方案进行必要修改时正确判断。优秀的需求分析应当非常精确细致地对用户需求作出描述，同时也应该最大程度地给予方案设计者充分发挥的余地。
需求管理任务划分
一个大的开发项目可能涉及20-30组不同的开发队伍，人员包括技术工程师、师以及具体项目主管等等，而每一个模块都有它自己的开发工具和开发语言。
主持一个大项目的开发并不是件容易的事，总体项目主管的首要任务是对开发项目进行任务划分，将整体开发任务细化为多个子模块，从而使这些子模块能够平行开发而无需太多的干预。总体项目主管可以将细化的不同模块的需求分析交给不同的开发队伍，对于开发进程的监控只需参照需求的解决情况，对于具体的开发细节则不必过问太多。
不同的开发队伍会使用不同的开发语言和开发工具，会使用不同的符号和标记。相反，作为总体项目主管所使用的语言、符号和标记等则必须简单易懂，以使所有的开发人员都等理解。换言之，总体项目主管应当使用自然语言，或只涉及少量的，简单的术语和专用词汇。
需求管理产品测试
需求的满足情况是决定最终产品成败的判定基础，对最终产品的测试评估必须以产品所试图解决的需求为标准。下图标示了不同的开发阶段所对应的测试需求。
这里有一个需求、产品和测试系统之间的关系问题，确定需要进行的测试属于总体开发主管的工作范畴，虽然具体工作并非都要由开发主管来亲自完成。
需求管理重复开发
对于总体开发主管而言，针对方案设计的修改是一项经常性的工作（因为修改而造成的影响则应当尽可能减小）。在进行项目开发时，随着开发进程的深入，各种修改的建议和问题的报告是屡见不鲜的，每解决一个问题，就是将产品同其需求性的结合又完善了一步。存在问题正是需求性尚未满足的表现。
方案设计的完善和需求性的满足是同步的，因此真正的用户对于产品的评价和建议尤其具有重要意义。在那些一步到位的中，真正用户无法左右开发进程；但在一个能够进行重复设计、重复开发的产品生命期中，开发人员应当及时搜集用户对于产品的反馈信息，并将这些信息结合到下一步的开发工作中去。如下图所示，用户反馈同产品开发是统一的。
需求管理辅助
在有些地方，需求管理被作为一个技术问题来处理，需求管理所针对的对象只是产品，而同项目管理所涉及的问题例如进程安排或等无关。实际上，项目管理涉及三方面问题：进程安排、资源分配和质量管理（同需求的统一）。
试想以下三种情况：
●一场高水准的音乐会，预算合理，演出时间却晚了两天。
●质量优良的小轿车，交货及时，然而造价是市价的两倍。
●一套系统，完全满足了用户需求，但在开发过程中使用非法劳工。
这三种情况虽然都满足了用户所需，然而缺乏实际意义，因此都以失败告终。
&我付了钱，但这不是我想要的&，没有用户愿意这么说。要避免出现这种情况，在进行项目管理和财务预算时，也必须以需求管理为基础。仅仅完成了一件设计并不意味着工作的结束，只有这件设计充***决了需求，它才具有里程碑般的意义。同样的，一件产品只有在测试和实际操作中完全满足了需求，已经完全准备好了投入到下一阶段的运营，才意味着这件产品在本阶段工作的结束。
开发进程中的每一块里程碑都意味着需求的解决又前进了一步，这样的每一块里程碑也都是委托商付款的重要参照，产品开发的整个进程都可以通过需求管理进行监控。
里程碑构造机制的基本方法之一就是，一项需求的满足就意味着一块里程碑的确立。我们应当对用户需求、针对需求而进行的以及每个子模块的开发进程之间的关联做到心中有数。
通过我们对需求管理实际应用的分析，几个关键因素凸现出来。首先，需求管理在开发周期中是自始至终存在的。注意：不要把它简单理解为&需求周期&，需求管理必须始终保持更新，它构成了技术管理的基础。
其次，需求管理同项目管理是密不可分的。如果我们把每一个需求的解决看作一个里程碑，并以此出发对整个开发进程进行监控，我们就应该对整体开发工作进行精密细致的划分，从而将需求分析具体化。
需求管理工具
需求管理所用到的工具必须能够处理和应用于本文所提到的各种需求，应当有助于我们分析需求，确定相应开发和支持工具以处理相关信息，进而处理系统相应模块。系统工程师始终致力于用简单的工具将需求形象化的展现出来，常用的工具比如附有标注说明的系统发布工具以及相关数据库等。
需求管理涉及到一系列复杂的对象，其任务面向很广，关系到整个设计开发的方方面面。其使用的工具应当提供如图列举的一些功能：
需求管理总结
本文论述围绕于需求管理工程。需求管理是开发工作有效进行的确证。很明显需求管理是一种很高层次的系统行为，涉及整个开发过程和产品本身。
需求管理首先要针对需求做出分析，随后应用于产品并提出方案。需求分析的模型正是产品的原型样本，优秀的需求管理提高了这样的可能性：它使最终产品更接近于解决需求，提高了用户对产品的满意度，从而使产品成为真正优质合格的产品。从这层意义上说，需求管理是产品质量的基础。
．SPASVO[引用日期]
企业信用信息