增员需求分析

㈠ 如何做需求分析

随着技术的不断发展和用户对网站功能性的需求不断提高，如今网站项目的设计已经不能再仅仅简单地利用静态Html文件来实现，与前几年网站设计由一两名网页设计师自由的创作相比，网站项目的设计和开发越来越像一个软件工程，也越来越复杂，网站项目的设计和开发进入了需要强调流程和分工的时代，建立规范的、有效的、健壮的开发机制，才能适应用户不断变化的需要，达到预期的计划目标。

网站项目管理（WPM）的含义为Web-based Project Management，即以Web 应用程序为主要表现方式的架构来进行的项目设计及管理，这样的架构中包含了浏览器、网络和Web

服务器等关键主体，主要体现在网站设计、以浏览器为客户端的Web应用程序开发（例如信息类网站、网上商店、虚拟邮局、客户关系管理。）等项目管理中。

按照笔者的经验，网站项目管理可以分为以下l六个阶段进行控制：
1. 需求分析及变更管理
2. 项目模型及业务流程分析
3. 系统分析及软件建模
4. 界面设计、交互设计及程序开发
5. 系统测试和文档编写
6. 客户培训、技术支持和售后服务

需要说明的是，这些阶段虽然具有一定的延续性，但是并非完全隔断的，例如需求变更管理和测试工作、文档编写都是贯穿整个项目过程的，许多工作时交叉进行或同时进行的。

（一）如何做好需求分析及变更管理？

业务员与客户进行的沟通，撰写需求分析报告是项目展开的基础。项目是以客户的需求为中心，而不是为技术而迁就需求。

一：让客户畅所欲言，罗列出所有的需求

让用户将所有的想法尽可能的阐述清楚，并把所有的要求罗列出来，不要遗漏。这时候不应该害怕“勾引”起客户的潜在需求而增加设计开发的工作量，从而被今后客户无止境的变更拖入泥潭，直接明白地跟客户把问题和要求一条条地列出来，把条理、归纳、分析先都扔到一边去，将用户最原始、最完整的要求准确地记录下来就完成了第一步的工作。

很明显，假如客户的需求做的都不完整，随时可能会产生意想之外的变更，甚至这个变更会破坏已经做的模型及结构，那么这个项目从开始就注定了会失败；比如站点所有的功能都实现了，本地测试起来也没有什么问题了，但是你却不知道客户的系统是要承受每天100万独立IP的访问，而你原来想当然的以为了不起就是1万独立IP访问的访问流量，稍微有经验的开发人员都会明白这样的设计是个灾难，无论是应用服务器、数据库还是程序全部要重新开发！

二：透过现象分析潜在的需求

很多情况下客户并非专业人士，在他们滔滔不绝的描述中不能指望他们帮助我们整理出重点和技术难关，这需要我们去为客户进行分析、归纳和整理，尤其是客户谈的不多却又是技术上实现难度和强度很高的地方特别值得注意。

客户往往对需求的概念是非常模糊的，大多时候给出的需求都是笼统而且尺度难以控制的，这就要求业务人员在倾听了客户的详细说明以后，帮助客户进行整理和分析，同时预测客户在开发过程中变更及今后应用中可能进行修改升级的潜在需求。

比如在为客户设计办公自动化系统的时候，也许就要为客户预留将来与他们的业务单位进行交互的通道；在设计邮件系统的时候要考虑可能会需要广告管理服务器；设计网络电子商店时今后增加库存产品进销存统计分析等等；限于时间财力的考虑，客户通常能够接受分阶段实施的开发过程，在需求分析时，提早为客户设想到今后的需求变更除了使项目开发更加顺利以外，也为今后业务的进一步深入打下了更好的基础。

笔者曾负责一个大型新闻网站的设计，当客户拿着将近五十页厚的一本设计要求报告时，我发现有四十页的内容对程序开发来说都是重复的，而在其中一页的角落却画了个“搜索其他网站相关新闻”的按钮，并且没有做任何说明，仅仅这10个字所完成的工作量完全顶的上其他整整四十页重复赘述所做的工作，客户完全不知道这个要求引发的问题实际就是一个搜索引擎的开发，通过协商，客人同意了修改成站内搜索的引擎。

三：利用自然的语言描述项目模型

在业务员与客户进行沟通和调查时撰写的需求分析，尽可能用自然的语言进行描述，虽然客户的水平和资历有所不同，但是最自然的描述能够使项目开发的各个成员都能清楚地理解需求含义，不至于在理解上产生偏差。对客户而言，这样的模型描述最接近真实，容易参与修订，并能以此为测试和验收的依据。

请比较以下两份关于需求的描述，
“用户在访问首页的时候可以在点击‘客户通道’按钮，弹出填写‘用户名’和‘密码’的窗口，输入正确后在新窗口打开客户通道的首页，在该页显示所有可操作的功能的导航条和最新的导读新闻链接列表 。”

“站点分为公开和加密两种状态，通过身份验证机制使特有的用户可以访问到加密信息，并提供不同于普通用户的功能。”

前段描述我们就很容易想象的出来设计完成的网站是什么样子，而后一段的描述可能会做出无数不同的版本，造成对需求理解的歧意。

四：利用示意图和图表将用户的需求表现出来

需求分析无论文字上怎么样表述都还是抽象的，对客户而言理解毕竟是困难的，将基本确定的需求制作出示意图是最直观有效的。

制作示意图可以有很多种方式，用PowerPoint或Visio制作流程示意，用Html文档制作界面示意都是可行的，最简单利用画图和Word表格方式也完全可以，关键是利用示意图将客户的需求和即将开始设计的系统体现起来，在进行系统分析和程序开发之前，双方对今后要完成的产品就能够有直观的认识，换言之，就是在产品还没有真正进入开发阶段的时候，双方就对工作的结果达成统一的意见，这将大大地减轻需求变更所带来的困扰，同时客户更容易地参与到项目的开发过程，保证项目往正确的方向进行。

在RUP中有这样的描述：

利用电影、卡通、图片、表格和动画片等制作示意图开始，告诉我们用户是谁，要发生什么事情，如何发生。

以用户友好的方式帮助收集并改进用户需求。

鼓励更有创造性、更加创新的设计解决方案。

鼓励团队复审，并避免所有人都不希望出现的特征。

确保以可理解、直观的方式实施特征。

使访谈过程变得轻松，避免出现访谈没有结果的现象。

简单地说，制作示意图就是使用工具向用户 (主角) 说明（有时是动画演示）系统如何适应组织的需要，并表明系统将如何运转。协调员将初始示意板展示给小组，小组成员提供意见。之后，在举办研讨班期间，示意板也进行“实时”演进。所以，您需要一种可以轻松更改示意板的画图工具。为了避免分散注意力，一般最好使用简单的工具，比如图表、白板或PowerPoint。

五：什么人要看需求分析报告

项目经理、系统分析员、开发经理、交互设计师、测试人员、文档人员包括客户代表都应该看需求分析，并进行共同的讨论，达成一致的意见。

我们经常会遇到业务人员辛辛苦苦谈下来的项目，对开发人员来说却是难以实现的，而技术人员设计的产品却常常得不到客户的认可，甚至发生纠纷，因此参与项目开发的人员都应该对这份需求有统一清晰的认识，并根据自己的工作对需求提出意见，通过与客户的沟通修订，最终确定项目实现的目标。

例如：

项目经理通过需求分析才能组建所需要的团队包括配置工作环境，制定开发周期。
开发周期的限制和功能上的要求可能会影响到程序员采用什么样的语言和工具进行编写；
操作用户的技能水平将影响到交互设计师进行前台设计时做到什么样的精度；
界面设计人员根据项目的性质和定位确定表现方式。
测试人员了解测试环境和条件后才能对项目质量进行跟踪和检测；

通过下表，我们可以看的出不同角色根据需求的变更所进行的工作流程：

六：建立需求变更日志，制作新版本的需求分析报告

尽管我们费了许多功夫在需求分析进行了最大可能的努力，但几乎可以肯定的是，这份需求分析在开发过程中一定会发生变化，也许是出自客户的遗漏，也可能是在开发过程中被激发出来的，这种变更有时是如此的频繁和琐碎，以至于往往不能将变更及时反馈到项目的各个角色中，那么做好需求变更日志就显得非常重要。

在需求分析后面附上变更日志，并将修改后的需求分析制作成新版本，保留每次更改过的版本，而不是覆盖，这样就比较容易地跟踪到需求变更过程中所带来的工作调整。

在新版本的需求分析中，将变更多部分用特殊方式表明出来，并在日志中记录变更多重的明细。

关于需求分析和变更管理可以参照下图示意：

七：本阶段重点工作角色

在需求分析和变更管理的过程中，工作量最大的角色为客户代表、业务员和项目经理。

客户代表提出需求，业务员帮助整理和分析，项目经理对整个项目进行评估。

在实际工作中，很多项目失败的起因都和需求分析有关。 客户代表和业务员通常并非从事技术开发的专业人员，在讨论需求的时候往往对项目的技术难度、工作量、时间进度把握不准确，这时候需要项目经理或技术人员进行参谋。

为了降低项目的风险，提高工作效率，有必要设计规范的需求管理计划书，帮助客户代表和业务员更好的完成任务。

以下提供一份需求管理计划的模板可作为参考：

八：总结

根据笔者的经验，要尽快做好需求分析掌握以下要点，也许能事半功倍：

仔细聆听，罗列客户的所有要求；
将需求进行分析，确认可操作的系统模型；
利用最自然的语言将系统进行描述，使每个开发人员不会产生歧意；
迅速确定网站的用户角色；
比如访客、会员、重要客户、前台管理员、网站管理员、业务员等；
分析确定每个角色的权限及可操作的功能；
比如会员可以查看特别信息、修改个人信息、退出登陆等；
前台管理员能够登录管理系统，能够发布编辑修改信息，能够审查会员资格等；
网站管理员可以更改栏目、修改网站界面等；
制作流程图和示意图将需求表现出来；
让客户参与到示意图的设计中，及时正确的反应出需求变更。
制作需求变更日志，保留升级版本，通过版本控制进行需求管理；
通过需求《管理计划书》使每个参与人员看到共同的努力目标。

㈡ 如何进行用户需求分析

1.概念
需求的定义包括从用户角度(系统的外部行为),以及从开发者角度(一些内部特性)来阐述需求.
关键的问题是一定要编写需求文档.我曾经目睹过一个项目中途更换了所有的开发者,客户被迫与新的需求分析者坐到一起.系统的分析人员说:"我们想与你谈谈你的需求."客户的第一反应便是:"我已经将我的要求都告诉你们前任了,现在我要的就是给我编一个系统".
百事通
而实际上,UGGs,需求并未编写成文档,因此新的分析人员不得不从头做起.所以如果只有一堆邮件、会谈记录或一些零碎的未整理的对话,你就确信你已明白用户的需求,那完全是自欺欺人.
需求的另外一种定义认为需求是"用户所需要的并能触发一个程序或系统开发工作的说明".有些需求分析专家拓展了这个概念:"从系统外部能发现系统所具有的满足于用户的特点、功能及属性等".这些定义强调的是产品是什么样的,而并非产品是怎样设计、构造的.而下面的定义则从用户需要进一步转移到了系统特性:
需求是指明必须实现什么的规格说明.它描述了系统的行为、特性或属性,是在开发过程中对系统的约束.
从上面这些不同形式的定义不难发现:并没有一个清晰、毫无二义性的"需求"术语存在,真正的"需求"实际上在人们的脑海中,这个人们主要是指客户,但一般情况下,用户并不能描述自己的需要,只就需要系统分析人员根据用户的自己语言的描述整理出相关的需要再进一步和客户核对.系统分析员和客户需要确保所有项目风险承担者在描述需求的那些名词的理解上务必达成共识.
任何文档形式的需求(例如如下将要描述的需求规格说明书)仅是一个模型,一种描述.
2.需求分析的任务
开发软件系统最为困难的部分就是准确说明开发什么.最为困难的概念性工作便是编写出详细技术需求,这包括所有面向用户、面向机器和其它软件系统的接口.同时这也是一旦做错,将最终会给系统带来极大损害的部分,并且以后再对它进行修改也极为困难.
目前,国内产品的庞杂,一家企业可能有几个系统并立运行,它们之间接口是系统开发人员最头痛的问题.
对于商业最终用户应用程序,企业信息系统和软件作为一个大系统的一部分的产品是显而易见的.但是对于我们开发人员来说,并没有编写出客户认可的需求文档,我们如何知道项目于何时结束?而如果我们不知道什么对客户来说是重要的,那我们又如何能使客户感到满意呢?
然而,即便并非出于商业目的的软件需求也是必须的.例如库、组件和工具这些供开发小组内部使用的软件.当然你可能偶尔勿需文档说明就能与其他人意见较为一致,但更常见的是出现重复返工这种不可避免的后果,而重新编制代码的代价远远超过重写一份需求文档的代价,这些血的教训正在国内的软件开发者身上发生.
近来,我遇到一个开发小组开发包括代码编辑器在内的一套内部使用的计算机辅助软件.不幸的是,当他们开发完这个工具后,发现这个工具不能打印出源代码文件,使用者当然希望有这个功能.结果这个小组只好手工抄写源代码文档以供代码检查.这说明那怕需求明确无误并构思准确,如果我们没有编写文档,软件达不到期望目标也只能是咎由自取了.
相反的情况,我曾见一个要集成到"错误跟踪系统"中的简单界面写了一页需求说明.而操作系统系统管理员在为处理脚本时发现简单的一张需求清单竟是如此有用.他们依据需求对系统进行测试时,此系统不仅非常清晰地实现了所有必需功能,而且未发现任何错误.
事实上,需求文档在开发过程中一直起指导作用.
3.需求分析过程
可把整个软件需求工程研究领域划分为需求开发和需求管理两部分更合适,如图4-1所示:
图4-1 需求工程域的层次分解示意图
需求开发可进一步分为:问题获取、分析、编写规格说明和验证四个阶段.这些子项包括软件类产品中需求收集、评价、编写文档等所有活动.需求开发活动包括以下几个方面:
确定产品所期望的用户类别.
获取每个用户类的需求.
了解实际用户任务和目标以及这些任务所支持的业务需求.
分析源于用户的信息以区别用户任务需求、功能需求、业务规则、质量属性、建议解决方法和附加信息.
将系统级的需求分为几个子系统,并将需求中的一部份分配给软件组件.
了解相关质量属性的重要性.
商讨实施优先级的划分.
将所收集的用户需求编写成文档和模型.
评审需求规格说明,确保对用户需求达到共同的理解与认识,并在整个开发小组接受说明之前将问题都弄清楚.
需求管理需要"建立并维护在软件工程中同客户达成的合同" .这种合同都包含在编写的需求文档与模型中.客户的接受仅是需求成功的一半,开发人员也必须能够接受他们,并真正把需求应用到产品中.通常的需求管理活动包括:
定义需求基线(迅速制定需求文档的主体).
评审提出的需求变更、评估每项变更的可能影响从而决定是否实施它.
以一种可控制的方式将需求变更融入到项目中.
使当前的项目计划与需求一致.
估计变更需求所产生影响并在此基础上协商新的承诺,这种承诺具体体现在项目解决方案上.
让每项需求都能与其对应的设计、源代码和测试用例联系起来以实现跟踪.
在整个项目过程中跟踪需求状态及其变更情况.
以上几点说明是我总结了成功实施项目后系统分析人员的经验,同时也根据国内外的其他系统实施的相关成功经验,进行了总结.
4.需求的类型
下面这些定义是需求工程领域中常见术语的定义.
软件需求包括三个不同的层次:业务需求、用户需求和功能需求(也包括非功能需求).
1.业务需求(business requirement)反映了组织机构或客户对系统、产品高层次的目标要求,它们在项目视图与范围文档中予以说明.
2.用户需求(user requirement) 文档描述了用户使用产品必须要完成的任务,这在使用实例(use case)文档或方案脚本说明中予以说明.
3.功能需求(functional requirement)定义了开发人员必须实现的软件功能,使得用户能完成他们的任务,从而满足了业务需求.
在软件需求规格说明书 (SRS)中说明的功能需求充分描述了软件系统所应具有的外部行为.软件需求规格说明在开发、测试、质量保证、项目管理以及相关项目功能中都起了重要的作用.对一个大型系统来说,软件功能需求也许只是系统需求的一个子集,因为另外一些可能属于子系统(或软件部件).
作为功能需求的补充,软件需求规格说明还应包括非功能需求,它描述了系统展现给用户的行为和执行的操作等.它包括产品必须遵从的标准、规范和合约;外部界面的具体细节;性能要求;设计或实现的约束条件及质量属性.所谓约束是指对开发人员在软件产品设计和构造上的限制.质量属性是通过多种角度对产品的特点进行描述,从而反映产品功能.多角度描述产品对用户和开发人员都极为重要.
下面以一个字处理程序为例来说明需求的不同种类.业务需求可能是:"用户能有效地纠正文档中的拼写错误",该产品的包装盒封面上可能会标明这是个满足业务需求的拼写检查器.而对应的用户需求可能是"找出文档中的拼写错误并通过一个提供的替换项列表来供选择替换拼错的词".同时,该拼写检查器还有许多功能需求,如找到并高亮度提示错词的操作;显示提供替换词的对话框以及实现整个文档范围的替换.
从以上定义可以发现,需求并未包括设计细节、实现细节、项目计划信息或测试信息.需求与这些没有关系,它关注的是充分说明你究竟想开发什么.项目也有其它方面的需求,如开发环境需求或发布产品及移植到支撑环境的需求.尽管这些需求对项目成功也至关重要,但它们并非本书所要讨论的.
5.需求分析的原则
不重视需求过程的项目队伍将自食其果.需求工程中的缺陷将给项目成功带来极大风险,这里的"成功"是指推出的产品能以合理的价格、及时地在功能、质量上完全满足用户的期望.下面将讨论一些需求风险.
不适当的需求过程所引起的一些风险:
1. 无足够用户参与
客户经常不明白为什么收集需求和确保需求质量需花费那么多功夫,开发人员可能也不重视用户的参与.究其原因:一是因为开发人员感觉与用户合作不如编写代码有意思;二是因为开发人员觉得已经明白用户的需求了.在某些情况下,与实际使用产品的用户直接接触很困难,而客户也不太明白自己的真正需求.但还是应让具有代表性的用户在项目早期直接参与到开发队伍中,并一同经历整个开发过程.
系统人员在实践过程中,也有些感觉,在实施一家公司的项目时,若无足够的用户参与,系统人员获得的需求是片面的,不完整的,这样系统在需求之初就埋下风险.
2. 用户需求的不断增加
在开发中若不断地补充需求,项目就越变越庞大以致超过其计划及预算范围.计划并不总是与项目需求规模与复杂性、风险、开发生产率及需求变更实际情况相一致,这使得问题更难解决.实际上,问题根源在于用户需求的改变和开发者对新需求所作的修改.
要想把需求变更范围控制到最小,必须一开始就对项目视图、范围、目标、约束限制和成功标准给予明确说明,并将此说明作为评价需求变更和新特性的参照框架.说明中包括了对每种变更进行变更影响因素分析的变更控制过程,有助于所有风险承担者明白业务决策的合理性,即为何进行某些变更,相应消耗的时间、资源或特性上的折中.
产品开发中不断延续的变更会使其整体结构日渐紊乱,补丁代码也使得整个程序难以理解和维护.插入补丁代码使模块违背强内聚、松耦合的设计原则,特别是如果项目配置管理工作不完善的话,收回变更和删除特性会带来问题.如果你尽早地区别这些可能带来变更的特性,你就能开发一个更为健壮的结构,并能更好地适应它.这样设计阶段需求变更不会直接导致补丁代码,同时也有利于减少因变更导致质量的下降.
3. 模棱两可的需求
模棱两可是需求规格说明中最为可怕的问题.它的一层含义是指诸多读者对需求说明产生了不同的理解;另一层含义是指单个读者能用不止一个方式来解释某个需求说明.
模棱两可的需求会使不同的风险承担者产生不同的期望,它会使开发人员为错误问题而浪费时间,并且使测试者与开发者所期望的不一致.一位系统测试人员曾告诉我,她所在的测试组经常对需求理解有误,以致不得不重写许多测试用例并重做许多测试.
处理模棱两可需求的一种方法是组织好负责从不同角度审查需求的队伍.仅仅简单浏览一下需求文档是不能解决模棱两可问题的.如果不同的评审者从不同的角度对需求说明给予解释,但每个评审人员都真正了解需求文档,这样二义性就不会直到项目后期才被发现,那时再发现的话会使得更正代价很大.
4. 不必要的特性
"画蛇添足"是指开发人员力图增加一些"用户欣赏"但需求规格说明中并未涉及的新功能.经常发生的情况是用户并不认为这些功能性很有用,以致在其上耗费的努力"白搭"了.开发人员应当为客户构思方案并为他们提供一些具有创新意识的思路,具体提供哪些功能要在客户所需与开发人员在允许时限内的技术可行性之间求得平衡,开发人员应努力使功能简单易用,而不要未经客户同意,擅自脱离客户要求,自作主张.
同样,客户有时也可能要求一些看上去很"酷",但缺乏实用价值的功能,而实现这些功能只能徒耗时间和成本.为了将"画蛇添足"的危害尽量减小,应确信:你明白为什么要包括这些功能,以及这些功能的"来龙去脉",这样使得需求分析过程始终是注重那些能使用户完成他们业务任务的核心功能.
5. 过于精简的规格说明
有时,客户并不明白需求分析有如此重要,于是只作一份简略之至的规格说明,仅涉及了产品概念上的内容,然后让开发人员在项目进展中去完善,结果很可能出现的是开发人员先建立产品的结构之后再完成需求说明.这种方法可能适合于尖端研究性的产品或需求本身就十分灵活的情况.但在大多数情况下,这会给开发人员带来挫折(使他们在不正确的假设前提和极其有限的指导下工作),也会给客户带来烦恼(他们无法得到他们所设想的产品).
6. 忽略了用户分类
大多数产品是由不同的人使用其不同的特性,使用频繁程度也有所差异,使用者受教育程度和经验水平也不尽相同.如果你不能在项目早期就针对所有这些主要用户进行分类的话,必然导致有的用户对产品感到失望.例如,菜单驱动操作对高级用户太低效了,但含义不清的命令和快捷键又会使不熟练的用户感到困难.
7. 不准确的计划
据统计,导致需求过程中软件成本估计极不准确的原因主要有以下五点:频繁的需求变更、遗漏的需求、与用户交流不够、质量低下的需求规格说明和不完善的需求分析.
对不准确的要求所提问题的正确响应是"等我真正明白你的需求时,我就会来告诉你".基于不充分信息和未经深思的对需求不成熟的估计很容易为一些因素左右.要作出估计时,最好还是给出一个范围.未经准备的估计通常是作为一种猜测给出的,听者却认为是一种承诺.因此我们要尽力给出可达到的目标并坚持完成它.
6.需求分析人员和用户的合作关系
优秀的软件产品是建立在优秀的需求基础之上的.而高质量的需求来源于客户与开发人员之间有效的交流与合作.通常,开发人员与客户或客户代理人,如市场人员间的关系反而会成为一种对立关系.双方的管理者都只想自己的利益而搁置用户提供的需求从而产生摩擦,在这种情况下,不会给双方带来一点益处.
只有当双方参与者都明白要成功自己需要什么,同时也应知道要成功合作方需要什么时,才能建立起一种合作关系.由于项目压力与日渐增,所有风险承担者有着一个共同的目标这一点容易被遗忘.其实大家都想开发出一个既能实现商业价值,又能满足用户需要,还能使开发者感到满足的优秀软件产品.
软件客户需求权利书列出了十条关于客户在项目需求工程实施中与分析人员、开发人员交流时的合法要求.每一项权利都对应着软件开发人员、分析人员的义务.而软件客户需求义务书也列出了十条关于客户在需求过程中应承担的义务.如果愿意,可以将其作为开发人员的权利书.
客户有如下权利:
1:要求分析人员使用符合客户语言习惯的表达
需求讨论应集中于业务需要和任务,故要使用业务术语,你应将其教给分析人员,而你 不一定要懂得计算机的行业术语.
2:要求分析人员了解客户的业务及目标
通过与用户交流来获取用户需求、分析人员才能更好地了解你的业务任务和怎样才能使产品更好地满足你的需要.这将有助于开发人员设计出真正满足你的需要并达到你期望的优秀软件.为帮助开发人员和分析人员,可以考虑邀请他们观察你或你的同事是怎样工作的.如果新开发系统是用来替代已有的系统,那么开发人员应使用一下目前的系统,这将有利于他们明白目前系统是怎样工作的,其工作流程的情况,以及可供改进之处.
3:要求分析人员编写软件需求规格说明
分析人员要把从你和其他客户那里获得的所有信息进行整理,以区分开业务需求及规范、功能需求、质量目标、解决方法和其它信息.通过这些分析就能得到一份软件需求规格说明.而这份软件需求规格说明便在开发人员和客户之间针对要开发的产品内容达成了协议.软件需求规格说明书可以用一种你认为易于翻阅和理解的方式组织编写.要评审编写出的规格说明以确保它们准确而完整地表达了你的需求.一份高质量的软件需求规格说明能有助于开发人员开发出真正需要的产品.
4:要求得到需求工作结果的解释说明
分析人员可能采用了多种图表作为文字性软件需求规格说明的补充.因为如工作流程图那样的图表能很清楚地描述出系统行为的某些方面.所以需求说明中的各种图表有着极高的价值.虽然它们不太难于理解,但是你很可能对此并不熟悉.因此可以要求分析人员解释说明每张图表的作用或其它的需求开发工作结果和符号的意义,及怎样检查图表有无错误及不一致等.
5:要求开发人员尊重你的意见
如果用户与开发人员之间不能相互理解,那关于需求的讨论将会有障碍,共同合作能使大家"兼听则明".参与需求开发过程的客户有权要求开发人员尊重他们并珍惜他们为项目成功所付出的时间.同样,客户也应对开发人员为项目成功这一共同目标所作出的努力表示尊重与感激.
6:要求开发人员对需求及产品实施提供建议,拿出主意
通常,客户所说的"需求"已是一种实际可能的实施解决方案,分析人员将尽力从这些解决方法中了解真正的业务及其需求,同时还应找出已有系统不适合当前业务之处,以确保产品不会无效或低效.在彻底弄清业务领域内的事情后,分析人员有时就能提出相当好的改进方法.有经验且富有创造力的分析人员还能提出增加一些用户并未发现的很有价值的系统特性.
7:描述产品易使用的特性
你可以要求分析人员在实现功能需求的同时还要注重软件的易用性.因为这些易用特性或质量属性能使你更准确、高效地完成任务.例如,客户有时要求产品要"用户友好"或"健壮"或"高效率",但这对于开发人员来说,太主观了并无实用价值.正确的应是:分析人员通过询问和调查了解客户所要的友好、健壮、高效所包含的具体特性.
8:调整需求,允许重用已有的软件组件
需求通常要有一定的灵活性.分析人员可能发现已有的某个软件组件与你描述的需求很相符.在这种情况下,分析人员应提供一些修改需求的选择以便开发人员能够在新系统开发中重用一些已有的软件.如果有可重用的机会出现,同时你又能调整你的需求说明,那就能降低成本和节省时间,而不必严格按原有的需求说明开发.所以说,如果想在产品中使用一些已有的商业常用组件,而它们并不完全适合你所需的特性,这时一定程度上的需求灵活性就显得极为重要了.
9:获得满足客户功能和质量要求的系统
每个人都希望项目获得成功.但这不仅要求你要清晰地告知开发人员关于系统"做什么"所需的所有信息,而且还要求开发人员能通过交流了解清楚取舍与限制.一定要明确说明你的假设和潜在的期望.否则,开发人员开发出的产品很可能无法让你满意.
客户有下列义务:
1:给分析人员讲解你的业务
分析人员要依靠你给他们讲解的业务概念及术语.但你不能指望分析人员会成为该领域的专家,而只能让他们真正明白你的问题和目标.不要期望分析人员能把握你们业务的细微与潜在之处,他们很可能并不知道那些对于你和你的同事来说理所当然的"常识".
2:抽出时间清楚地说明并完善需求
客户很忙,经常在最忙的时候还得参与需求开发.但无论如何,你有义务抽出时间参与"头脑风暴"会议的讨论,接受采访或其它获取需求的活动.有时分析人员可能先以为明白了你的观点,而过后发现还需要你的讲解.这时,请耐心一些对待需求和需求的精化工作过程中的反复,因为它是人们交流中的很自然的现象,何况这对软件产品的成功极为重要.
3:准确而详细地说明需求
编写一份清晰、准确的需求文档是很困难的.由于处理细节问题不但烦人而且又耗时,故很容易留下模糊不清的需求.但是,在开发过程中,必须得解决这种模糊性和不准确性.而你恰是为解决这些问题作出决定的最佳人选.不然的话,你就只好靠开发人员去正确猜测了.在需求规格说明中暂时加上待定(to be determined, TBD也可采用汉语拼音略写"DQD:待确定")的标志是个不错的办法.用该标志可指明了哪些需要进一步探讨、分析或增加信息的地方.不过,有时也可能因为某个特殊需求难以解决或没有人愿意处理它而注上TBD标志.尽量将每项需求的内容都阐述清楚,以便分析人员能准确的将其写进软件需求规格说明中.如果你一时不能准确表述,那就得允许获取必要的准确信息这样一个过程.通常使用所谓的原型技术.通过开发的原型,你可以同开发人员一起反复修改,不断完善需求定义.
4:及时地作出决定
正如一位建筑师为你修建房屋,分析人员将要求你做出一些选择和决定.这些决定包括来自多个用户提出的处理方法或在质量特性冲突和信息准确度中选择折衷方案等.有权做出决定的客户必须积极地对待这一切,尽快做处理、做决定.因为开发人员通常只有等你做出了决定才能行动,而这种等待会延误项目的进展.
5:尊重开发人员的需求可行性及成本评估
所有的软件功能都有其成本价格,开发人员最适合预算这些成本(尽管许多开发人员并不擅长评估预测).你所希望的某些产品特性可能在技术上行不通,或者实现它要付出极为高昂的代价.而某些需求试图在操作环境中要求不可能达到的性能或试图得到一些根本得不到的数据,开发人员会对此作出负面的评价意见,你应该尊重他们的意见.有时,你可以重新给出一个在技术上可行、实现上便宜的需求,例如,要求某个行为在"瞬间"发生是不可行的,但换种更具体的时间需求说法("在50ms以内",但若没有准确的技术分析不能轻易下结论),这就可以实现了.
6: 划分需求优先级别
大多数项目没有足够的时间或资源来实现功能性的每个细节.决定哪些特性是必要的,哪些是重要的,哪些是好的,是需求开发的主要部分.只能由你来负责设定需求优先级,因为开发者并不可能按你的观点决定需求优先级.开发者将为你确定优先级提供有关每个需求的花费和风险的信息.当你设定优先级时,你帮助开发者确保在适当的时间内用最小的开支取得最好的效果.在时间和资源限制下,关于所需特性能否完成或完成多少应该尊重开发人员的意见.尽管没有人愿意看到自己所希望的需求在项目中未被实现,但毕竟是要面对这种现实的.业务决策有时不得不依据优先级来缩小项目范围或延长工期,或增加资源,或在质量上寻找折衷.
7:评审需求文档和原型
正如我们将在第1 4章讨论的,无论是正式的还是非正式的方式,对需求文档进行评审都会对软件质量提高有所帮助.让客户参与评审才能真正鉴别需求文档是否的确完整、正确说明了期望的必要特性.评审也给客户代表提供一个机会,给需求分析人员带来反馈信息以改进他们的工作.如果你认为编写的需求文档不够准确,就有义务尽早告诉分析人员并为改进提供建议.通过阅读需求规格说明,很难想象实际的软件是什么样子的.更好的方法是先为产品开发一个原型.这样你就能提供更有价值的反馈信息给开发人员,帮助他们更好地理解你的需求.必须认识到:原型并非是一个实际产品,但开发人员能将其转变、扩充成功能齐全的系统.
8:需求出现变更要马上联系
不断的需求变更会给在预定计划内完成高质量产品带来严重的负面影响.变更是不可避免的,但在开发周期中变更越在晚期出现,其影响越大.变更不仅会导致代价极高的返工,而且工期也会被迫延误,特别是在大体结构已完成后又需要增加新特性时.所以一旦你发现需要变更需求时,请一定立即通知分析人员.
9:应遵照开发组织处理需求变更的过程
为了将变更带来的负面影响减少到最低限度,所有的参与者必须遵照项目的变更控制过程.这要求不放弃所有提出的变更,对每项要求的变更进行分析、综合考虑,最后作出合适的决策以确定将某些变更引入项目中.
10:尊重开发人员采用的需求工程过程
软件开发中最具挑战性的莫过于收集需求并确定其正确性.分析人员采用的方法有其合理性.也许你认为需求过程不太划算,但请相信花在需求开发上的时间是"很有价值"的.如果你理解并支持分析人员为收集、编写需求文档和确保其质量所采用的技术,那么整个过程将会更为顺利.尽管去询问分析人员为什么他们要收集某些信息,或参与与需求有关的活动.
系统分析人员在开发过程中可能会遇到以下问题,一些很忙的客户可能不愿意积极参与需求过程,而缺少客户参与将很可能导致不理想的产品.故一定要确保需求开发中的主要参与者都了解并接受他们的义务.如果遇到分歧,通过协商以达成对各自义务的相互理解,这样能减少今后的摩擦.
7.需求文档
需求开发的最终成果是:客户和开发小组对将要开发的产品达成一致协议.协议综合了业务需求、用户需求和软件功能需求.就像我们早先所看到的,项目视图和范围文档包含了业务需求,而使用实例文档则包含了用户需求.你必须编写从使用实例派生出的功能需求文档,还要编写产品的非功能需求文档,包括质量属性和外部接口需求.只有以结构化和可读性方式编写这些文档,并由项目的风险承担者评审通过后,各方面人员才能确信他们所赞同的需求是可靠的.
你可以使用以下三种方法编写软件需求规格说明:
用好的结构化和自然语言编写文本型文档.
建立图形化模型,这些模型可以描绘转换过程、系统状态和它们之间的变化、数据关系、逻辑流或对象类和它们的关系.
编写形式化规格说明,这可以通过使用数学上精确的形式化逻辑语言来定义需求.
由于形式化规格说明具有很强的严密性和精确度,因此,所使用的形式化语言只有极少数软件开发人员才熟悉,更不用说客户了.虽然结构化的自然语言具有许多缺点,但在大多数软件工程中,它仍是编写需求文档最现实的方法.包含了功能和非功能需求的基于文本的软件需求规格说明已经为大多数项目所接受.图形化分析模型通过提供另一种需求视图,增强了软件需求规格说明.

㈢ 企业如何进行员工招聘需求分析

用人部门提出招聘需求，作为招聘负责人根据什么确定招人是否真需求，是否合理性？千万不要他们说招你就招。所以，做好招聘需求分析是当务之急。

一、我们为什么要招聘？原因有五个：
1. 有人离职
2. 工作量增加
3. 新岗位
4. 储备
5. 准备换人

二、判断是否真需求的方法，有五句话：
1. 工作内容不明确的不招。
要招的这个人，打算具体让他做什么，不要笼统的，要具体的工作内容描述；

2. 招来没有人管的不招。
谁将是他的师傅，师傅是怎么想的，做好准备没有？

3. 能内部协调调配的不招。
如果不能按计划招到，用人部门的负责人，有什么备选方案，备选方案有没有可能成为主方案？

4. 不可能完成的需求不招。
能不能制定出招聘计划，做不出招聘计划的需求，不要说“试试看，想办法”，应该立即调整；

5. 简单的换人需求不招。
对现有人员不满意，如果只是管理问题，管理问题改善前，不招新人。

对上述5句话，后两句可能有争议，这样表达，是为了倒逼用人部门和HR部门一起，不要老想着换人，用新人；要着眼培养人，用人长处，不断提升管理水平，将人才资产盘活。

三、招聘需求分析步骤
严格地讲，招聘需求分析尚未形成特别科学和准确的方法，但可以尝试采用以下思路：

第一步：岗位信息的采集搜集
现有的岗位说明书、组织机构、团队结构、用人机制等资料是岗位信息的重要来源，实地考察、任职者访谈、绩优者分析等是采集搜集岗位信息的有效方法。

第二步：岗位信息的整理提炼
所有与岗位相关的信息可以被整合成四个方面：
1. 岗位职责要求：岗位的关键产出是什么？岗位对人的行为要求是什么？这些要求哪些是对人的，哪些是对事的？
2. 工作环境特点：是否要求承担较大的工作压力？工作节奏快慢如何？岗位在公司中的地位如何？任职人所在团队氛围如何？
3. 公司文化要求：公司倡导什么样的价值观？公司体现什么样的精神风貌？公司需要体现什么样的工作风格？
4. 公司发展需要：公司未来的业务方向是什么？在可预见的未来，业务发展对人的要求将发生什么样的变化？

第三步：汇总岗位的用人要求
从“知识、技能、经验”、“能力”、“动机/价值观”三个维度，对上述信息加以汇总，形成岗位用人要求。

第四步：有效招聘要素的选择
上述岗位用人要求是一种理想状态，但企业需要的是最合适的人，而不是“完美”的人。在招聘过程中，不需要面面俱到，只需要重点选择若干个核心要素作为考察点。考察点的衡量标准如下：

1. 培养成本：某项考察点在短期内进行培养的难易程度。易于培养的，作为考察的次要标准或不予考察;不易培养的，则作为主要考察点。

2. 人群区分度：某项考察点在应聘者群体中的差异度和区分度。区分度小的，作为次要标准或不予考察；区分度大的，则作为主要考察点。

3. 环境约束度：某项考察点因环境因素对职责发挥的影响程度。环境约束度高的，作为次要标准或不予考察；约束度低的，则作为主要考察点。

4. 可衡量度：某项考察点能用现有方式进行衡量的程度。不能或不易衡量的，作为次要标准或不予考察；易于衡量的，则作为主要考察点。

需求不合理下的招聘工作，会拖死HR部门，我们的HR部门将永远忙于人事事务工作，没有精力来思考和落实人力资源管理工作，最后的结果只能是，天天招人，始终无人可用。所以，判断招聘需求是否合理性是一个有必要性的工作。

㈣ 怎样用劳动力需求的原理分析 减员增效,下岗分流

“精干主体，分离辅助”，实现企业劳动力资源的合理配置，是企业提高劳动效率，适应市场经济发展的重要举措。在实施减员增效的过程中，必须要把减员增效与企业内部机构改革、行业结构调整结合起来，以减员促改革，以改革求效益，并用科学的标准规范减员行为和程序。

(一)调整产业结构、合理配置劳动力

根据现代化企业制度的要求、社会主义市场经济的需要及国家局扩大优势企业生产规模、“一业为主、多种经营”的发展战略的要求，按照精干、高效、科学的原则，进行战略性企业重组。要搞好企业的定岗、定编、定员、定责、定薪工作，建立一个适应市场经济的用人机制，搞好人力资源的合理配置。

(二)完善定额定员标准、加大实施力度

加强工业企业定标达标工作的实施，优化工种、岗位，优化定员分布结构，制定相应的实施管理办法，督促企业自觉按最优化人力资源配置组织生产，以最小的人工成本投入取得最大的经济效益，提高企业在市场经济条件下的竞争力。

在调整研究的基础上，尽快编制出台商业企业定额定员标准，改变商业企业因用人无标准而造成的不科学、不规范用人的局面。同时，避免因工业企业减员分流，人员盲目转向商业企业，造成商业企业人员无序膨胀的不良循环状况。

(三)引进竞争机制、择优上岗

加强在职职工培训工作，提高职工素质。组织广大职工加强学习，更新就业观念，增强竞争意识。通过学习，提高其专业技术水平和实际操作能力。根据岗位在企业生产活动中的地位、作用和上岗人员应具备的条件、职责，制定上岗标准。只要是符合上岗条件，不分干部工人，不论是否在岗，均可公平竞争、择优上岗。对那些不参加竞争上岗、不符合上岗条件和标准或没有岗位上岗的，即视为下岗人员。

三、行业减员增效的措施

减员增效、下岗分流，形成“优胜劣汰”的竞争机制，是国有企业深化改革、实施产业结构调整的重要举措。减员，一方面是对劳动力资源的阶段性闲置，造成一定的失业和社会压力；另一方面，可以提高劳动生产率，降低成本，增强企业产品在市场上的竞争能力，提高经济效益，从而相应增强对劳动力的吸纳需求。

下岗职工同样是一部分重要的人力资源，是社会主义现代化建设的重要力量。重新就业是《劳动法》赋予他们的劳动权利。党的十五大报告中明确指出：“党和政府要采取积极措施，依靠社会各方面的力量，关心和安排好下岗职工的生活，搞好职业培训，拓宽就业门路，推进再就业工程。”国家局党组也指出：“现有的多元化经营企业以及今后新开办的项目，都要优先考虑烟草职工的分流问题，特别是要为下岗职工创造再就业的机会和条件，使多元化经营为增强行业的凝聚力和维护职工队伍的稳定做出积极贡献。”因此，企业有责任、有义务为下岗职工创造条件，帮助他们转变就业观念，增强就业能力，以期尽快重新就业，充分发挥他们的作用。为实现行业持续良性发展，注入新的生机和活力，在操作过程中，要做到摸清底数，制定规划，明确任务。具体可采取以下措施：

(一)精干主体

1．积极研究、探索下岗职工的再就业途径，发挥劳动者在就业择岗上的积极性。鼓励下岗职工或调出、或辞职、或自谋职业。对由职工本人提出申请，要求自谋职业，同时解除劳动合同的职工，可给予一定的扶持政策。

2．对已医疗期满，符合退职条件的病休及长期不能正常上班的人员，办理退职、退养手续。

3．对距法定退休年龄五年以内的职工，可办理厂内退休手续，待达到退休年龄时，再办理正式退休手续。

4．挖掘企业内部潜力。对不该外聘、可以不聘企业外人员的岗位，要坚持清退外聘人员。

5．充分运用法律手段，加大职工队伍整顿力度。严格按照《劳动法》中有关解除、终止劳动合同规定，对严重违反劳动纪律和有关规章制度的人，坚决予以解除劳动合同。

(二)分离辅助

对企业内部具有办社会性质的辅助部门，或具有一定分流条件的部门和单位，要与主体剥离，使其成为立足市场、自主经营、独立核算、自负盈亏的经济实体。

(三)理顺管理体制

积极发展第三产业和其它经济实体，对长期存在的全民支援集体企业的职工实行“脱岗”管理，把对集体企业的人力支援纳入人员流动的正常轨道管理。

(四)建立企业内部劳动力管理中心

办好劳动力管理服务中心，对下岗职工实行托管。托管期间，要制定相应的职工培训计划，对下岗职工进行各种转业转岗培训；加强职业介绍，提供就业指导和就业需求信息。并为职工发放基本生活费，办理社会保险，为下岗职工解除后顾之忧。同时，企业要制定相应的上岗、待岗、下岗工资待遇政策和待岗、下岗托管时间期限。对待岗期间两次不服从分配，或待岗一定时间(一年或两年)通过培训仍不能上岗的，可解除劳动合同。

(五)开辟新的就业渠道

发展多种经营企业，兴办第三产业等经济实体，积极主动为下岗职工提供安置就业岗位。

㈤ 为什么进行需求分析

A 战略层需求（一般来自老板）
一个公司的方向性需求，一般不是产品经理所能决策的，这个层面的需求一般来自于决策层。老板一般会根据自己拥有的资源优势，以及对市场的分析，决定产品的战略方向。

比如为什么微信是做熟人社交，陌陌是做陌生人社交，360是做杀毒。对于这个层面的需求，一般不会有太具体的需求。通常产品经理会听到的需求会是，产品大概要面向什么样的用户，帮助用户解决什么样的问题，这种类型的需求可能在初期的创业公司会听的更多，例如饿了么的诞生是来自于他的创始人想要解决校园里叫外卖不便的现状 。

在相对成熟的公司孵化新项目时，你听到的需求可能会变成：公司有哪些资源优势，我们利用这样的优势能切入哪个行业，解决什么问题。比如小程序的诞生，一定是（wo cai de） 微信的决策层在思考自己拥有这个体量的用户后 ，产品能做更多的事情。在这个思路下，逐渐衍生出了小程序的概念。利用小程序，微信实现了流量的转化，实现了自己平台化、系统化的想法。

在这个阶段产品经理更多的事情应该是去了解老板提出的方向。基于这样的需求，可以确定人群，确定要需求范围（就是要做啥事），以及手里面可用的一些资源。（比如流量资源，内容资源，算法资源等）。

简单的来说，如果把做产品比作开店，那么这个阶段差不多菜系（要解决问题）和大厨（资源）应该是选好了，以及卖给什么样的人。但是开在什么地方，面积选择，店面装潢，详细的菜品和定价都还没有确认。

B 用户需求调研
在接到了战略层的需求，接下来要做的事情是分解和完善需求，将需求细化。这个时候你要做的事情包括：找到目标人群、了解目标人群的使用习惯。

比如你要做一个外卖平台，你的用户群里可能包含了两个人群，商家和用户。针对这两个人群，又会派生出很多需求。你需要考虑商家的使用环境，普通的小店很可能收银、送货、点餐全部加起来只有一到两个人。他们可能就没有办法专职的关注下单情况，这种情况下你的推送机制，语音提醒可能就要保证时效性。同样的因为生产环境的原因，订单管理需要人工来确认，保证不会过载，影响用户的体验。商品的上架和下架就要尽可能简单、清晰，在商家没有货的时需要及时下架。（不同于客户端的丰富、种类繁多）。

用户端则面对学生群体，不同于在食堂购买，在PC或者手机上，如何展示有哪些商家，每个商家又有什么样的特色，如何帮助用户去挑选商家，怎么评判商家的口味，价格如何展示。需求和商家端有很大的不同。

文章中举例的外卖软件，在我们日常生活中比较常见。很多需求依托常识就可以做出判断。但是如果遇到小众的需求，例如二次元社区、情趣用品等，如果产品经理没有这些产品经验，则需要去找到用户群体，比较常见的做法有联系公司内部的工作人员，例如运营和客服，这些经常需要和用户去打交道的职位，能给够你一些最真实的意见。还可以维护种子用户微信群，做调研问卷等。

但是小公司一般不太会采用这些方式，因为这些方式成本高，耗时长。最好的办法还是产品经理能变成产品的忠实用户，去真实的使用产品。而不是假想自己是产品。

在这个环节，其实产品经理基本上可以将方向性的需求转变为更详细的功能范围，以及对应的优先级。还是拿开饭店的那个例子，在这里其实我们根据老板给的菜系和大厨以及开店预算。

我们基本上确认了我们的菜是要卖给什么人，这些人来吃饭的需求是工作餐还是周末聚会，还是情侣约会，以及他们大概的预算会在什么范围（目标人群及核心需求） 。在这些条件的支撑下，我们基本可以确定菜谱上的内容，要设置凉菜、热菜、招牌菜、主食（需求转化为对应的功能列表）。根据这些人的性格特点，店面的装潢也可以确定了（页面风格，排版）

C 协作部门的需求
确定了用户的需求之后，我们要继续确认内部的工作流程。产品不仅是用于服务用户，同时还要服务自己内部体系的其他部门。例如：

运营部门日常的内容和活动维护，那你就会需要一个管理后台；
客服要可以收集和解答用户的问题，那我们的页面上就会需要客服的展示位以及后台给客服回复的页面；
像饿了么这个例子，它的协作部门还包括了外卖配送人员，这个时候就需要给配送员一个可以快速查看和管理订单的页面（体量足够，可以变成app）；
网站类的产品可能收到来自seo部门的需求，他会要求的你的页面上增加很多的内链、会要求一些搜索词要有落地页面。（这个可能会直接影响你的网站结构，seo会让你做很多专门给爬虫抓取的页面）。
可能还会有一些页面上看不到的需求:比如财务可能有做账的需求，BI有数据统计的需求。
确定了你可能需要协作的部门之后，有的时候你还需要继续确认他们的人员配置和工作流程是什么样的，这些会影响到前后端的设计。

以我所在的公司为例，产品是垂直领域的内容类产品，在我规划内容展示的时候，首先需要明确我们内容的生产的范围和内容数量、以及内容的展示形式（音频、视频？），这些东西决定了你的页面如何展示。

㈥ 人员需求报告怎么写

这是一个人员需求预测的报告模板，你可以参考一下，其中的一些表格复制不过来，没有显示表格的形式，但是不影响框架的体现。
公司年度人员需求预测报告

文本名称 ××公司年度人员需求预测报告 受控状态
编 号
一、目录（略）
二、呈送文（略）
三、报告正文
（一）人力资源现状分析
1．员工构成情况
伴随公司成立以来的发展和积累，目前在生产和经营领域初步形成了一支素质较好、层次较高的人才队伍，共有在职职工368人。具体人员构成情况见下表所示。
××公司员工构成情况表
类别 具体分布情况
职能分布 公司高层 管理中层 管理人员 生产人员
人数 比例 人数 比例 人数 比例 人数 比例
5 1.4 15 4.1% 38 10.3% 310 84.2%
学历分布 硕士及以上 本科 大专 大专以下
人数 比例 人数 比例 人数 比例 人数 比例
6 1.6% 40 10.9% 135 36.7% 187 50.8%
年龄构成 30岁及以下 31～40 41～50 50以上
人数 比例 人数 比例 人数 比例 人数 比例
186 50.5% 116 31.5% 41 11.1% 25 6.8%
2．定岗定编情况
本公司目前各部门定岗定编情况如下表所示。（表略）
3．人力资源现状分析结果说明
（1）87．5%的员工集中在大专及以下学历，具有中高级技术职称的人员不多。
（2）员工年龄在40岁以下的占总人数的82.1%，具备进一步学习的能力。
（3）随着公司的发展、业务规模的扩大，专业技术人才、一线生产人员、市场拓展人员均应有较大需求。
（二）人力资源需求预测结果
1．未来人力资源流失预测
（1）未来退休人员预测：公司2004年至2006年退休13人，其中2人内退，11人正常退休。2007年公司51岁以上人员仅有25人，相对公司人员规模来说，退休人员很少，不会影响公司的人员数量变化，建议不作考虑。
（2）未来离职人员预测：公司2004年至2006年共有15人，其中12人主动离职，3人被开除，离职人员人数较少，基本集中在一线生产工人类别上，在未来离职人员预测中不作考虑。
2．未来新增人员及主要岗位需求
为满足公司的战略发展要求，未来人员需求将集中于投融资管理人才和专业技术人才、经营人才等。
（1）投融资管理人才：公司未来几年内将积累大量财务资源，急需投融资管理方面人才，初步估计投融资管理人才需2人。
（2）专业技术人才：公司预计2008年将新增产品品种，新增1条生产线，初步估计具有生产专业技术中级及以上职称的人才3人，生产工人20人。
（3）业务经营人才：随着公司业务规模的扩大，将扩展销售领域和市场份额，可引进具有丰富业务管理经验、极具市场开拓精神的高级经营人才，初步估计业务经营人才需10人。
3．未来人员净需求
公司2008年各部门人员需求表
部门名称 新增岗位及人数 部门名称 新增岗位及人数
决策层 设置战略发展部，2人 生产部 车间主任1人，生产岗位工人20人
财务部 投融资主管1人，专员1人 市场部 策划专员1人
技术部 技术研发人员2 销售部 销售区域经理3人，销售专员7人
产品部 产品设计人员2人 质量部 检验员1人
行政部 人员不变 采购部 采购专员1人
人力资源部 人员不变 仓储部 不变
人员净需求 42人

相关说明
编制人员 审核人员 批准人员
编制日期 审核日期 批准日期

㈦ 简述员工需求分析各个层面的内容及需求分析方法

【柯氏四级评估】

第一级：反应评估

第二级：学习效果评估

第三级：行为评估

第四级：成果评估

关于柯氏四级评估，有两个注意点：

1）4321做规划，1234看效果

培训后，我们会按柯氏1→2→3→4级来做培训效果评估。在培训前期的规划阶段，应该反过来，按照4→3→2→1做规划。

需求分析及调研怎么做？大神教你从这3个层次入手
首先，应该明确需要达到的业绩成果（成果评估）。其次，反思支持绩效达成所要进行的行为改变（行为评估），最后再匹配、规划并开展培训。

2）一定要自上而下做分析

问：作为培训经理，如果你只有一个客户，TA会是谁？

答：老板。

需要区分开来的是——老板是客户，你的管理者、员工是用户。

培训需求的调查一定是自上而下做分析，了解老板的需求在哪里，然后再进行传达、执行和落地。老板认为什么是重要的，我们就要去跟随和支持。

需求分析及调研怎么做？大神教你从这3个层次入手
战略层面“找方向”

1）清晰界定需要改善的业务问题

组织的战略和发展在哪里？组织没有很清晰的战略怎么办？这里有两个方法可以参考——

① 钱从哪里来？钱会去哪里？

未来什么地方可以赚钱？ 即分析企业经营发展战略，以确定今后的培训重点；

现在什么地方赚钱？什么地方该赚钱而没有赚钱？ 即分析企业当前整体绩效，找出存在问题并分析原因，以确定当前企业培训的重点。

② 资料信息分析法

从既往资料、方案等分析培训需要（包括企业年报、发展计划书、年底绩效总结等）。

举个例子

资料一：公司从今年6月至9月，公司并购3家公司发展太阳能新业务；员工从1500余人发展到4000余人；

资料二：管理队伍新提拔或转化岗位56人，其中新提拔23人；

资料三：由总裁主讲“公司发展与管理者的要求”；举办一次“如何有效沟通”；培训部组织3次新员工培训。

资料分析：

1.关键词“新业务”，新业务需要培训，这是一次机遇也是挑战；

2.关键词“从1500余人发展到4000余人”，人数的增长暗示文化融合问题，需要提前进行规划；

3.关键词“管理者人数上升”，新进管理者需要培养；

4.关键词“高管授课及活动”，发掘未来培训的方向以及可用的资源。

人力资源部门的一些报告，看似跟我们关系不大，但如果我们没有去关注这些信息，等到半年之后，潜在问题像轰汹涌的洪水朝我们冲过来的时候，我们只能被冲走。

所以我们一定要离开当前培训部的位置，尝试站出去看经营，看组织的规模发展，看行业的趋势，在更好地了解组织发展后，才能作为一个组织的投资者去帮助组织，通过人才投资的方式不断得到增长和发展。

2）对企业战略了解程度的测试

要做战略落地的培训计划，一定要从战略层面去思考，不单是停留在职能部门。可以通过以下问题了解——

1.我们公司最重要的收入来源是？2.我们公司最重要的业务增长驱动因素是？3.我们公司的核心战略是？4.我们公司的主要竞争对手是？5.我们公司面临的最大威胁是？6.我们公司面临的最大人力资源挑战是？

当我们看的更加清楚之后，才知道接下来风向在哪里。站在风口，猪也会飞起来。

需求分析及调研怎么做？大神教你从这3个层次入手
组织层面“找方法”

既然知道重点，该用什么样的方式设计培训？

1）培训的边界

什么是培训能解决的问题？——知识、技能和态度问题。其中，态度问题是一个大难题，它不是通过单一一次培训能够去解决的，需要通过系统、不断的培训、影响和改变，才可以达到。

需求分析及调研怎么做？大神教你从这3个层次入手
2）能力需求调研问卷

市面上有很多有很多胜任力模型/能力素质清单，大家可以参考并设计出属于自己的培训需求分析问卷。

需求分析及调研怎么做？大神教你从这3个层次入手
3）部门培训业务需求面谈

现在的组织架构发生了一些改变，譬如OD（组织发展）、HRBP（业务部门的合作伙伴）。这种转变把培训和人力资源下放到业务部门之下，直接对业务负责，增进了培训和专业部门的相互理解，可以对于业务了解之后再输出学习。

需求分析及调研怎么做？大神教你从这3个层次入手
员工层面“量体裁衣”

这个部分对于多半企业来讲还不太现实，暂时只在一些较关键的群体，比如说领导力，或者在一些企业的专家或高管启动。

员工层面还需要做调查吗？

需要，要做需求培训的方式和周期的需求分析。按照四级评估模型来说，这一步叫做一级评估调查。

什么时间，什么方式学习比较有效？培训先找到“药”，再思考怎么样让学生能愿意吃下去。

1）淡季开展培训，旺季开发课程

不同行业在处理这个问题时的方式不太一样，比如说服装快销的行业，很多时候以季度为单位——分季前、季中和季后。季前和季后都都是比较忙的，所以第一季度2月份比较适合做培训， 1月份3月份的时间就不要打扰他们了。

2）根据群体特性开展培训

70后、80后、90后偏好学习的方式不太一样，同样课程内容，如果群体对象不一样，为了保证有效培训，还要考虑不同的方式。如按年龄、专业线条等特性，给他们提供比较适合的方式方法进行培训。

㈧ 需求分析如何来做

随着技术的不断发展和用户对网站功能性的需求不断提高，如今网站项目的设计已经不能再仅仅简单地利用静态Html文件来实现，与前几年网站设计由一两名网页设计师自由的创作相比，网站项目的设计和开发越来越像一个软件工程，也越来越复杂，网站项目的设计和开发进入了需要强调流程和分工的时代，建立规范的、有效的、健壮的开发机制，才能适应用户不断变化的需要，达到预期的计划目标。
网站项目管理（WPM）的含义为Web-based Project Management，即以Web 应用程序为主要表现方式的架构来进行的项目设计及管理，这样的架构中包含了浏览器、网络和Web
服务器等关键主体，主要体现在网站设计、以浏览器为客户端的Web应用程序开发（例如信息类网站、网上商店、虚拟邮局、客户关系管理。）等项目管理中。
按照笔者的经验，网站项目管理可以分为以下l六个阶段进行控制： 1. 需求分析及变更管理 2. 项目模型及业务流程分析 3. 系统分析及软件建模 4. 界面设计、交互设计及程序开发 5. 系统测试和文档编写 6. 客户培训、技术支持和售后服务
需要说明的是，这些阶段虽然具有一定的延续性，但是并非完全隔断的，例如需求变更管理和测试工作、文档编写都是贯穿整个项目过程的，许多工作时交叉进行或同时进行的。
（一）如何做好需求分析及变更管理？
业务员与客户进行的沟通，撰写需求分析报告是项目展开的基础。项目是以客户的需求为中心，而不是为技术而迁就需求。
一：让客户畅所欲言，罗列出所有的需求
让用户将所有的想法尽可能的阐述清楚，并把所有的要求罗列出来，不要遗漏。这时候不应该害怕“勾引”起客户的潜在需求而增加设计开发的工作量，从而被今后客户无止境的变更拖入泥潭，直接明白地跟客户把问题和要求一条条地列出来，把条理、归纳、分析先都扔到一边去，将用户最原始、最完整的要求准确地记录下来就完成了第一步的工作。
很明显，假如客户的需求做的都不完整，随时可能会产生意想之外的变更，甚至这个变更会破坏已经做的模型及结构，那么这个项目从开始就注定了会失败；比如站点所有的功能都实现了，本地测试起来也没有什么问题了，但是你却不知道客户的系统是要承受每天100万独立IP的访问，而你原来想当然的以为了不起就是1万独立IP访问的访问流量，稍微有经验的开发人员都会明白这样的设计是个灾难，无论是应用服务器、数据库还是程序全部要重新开发！
二：透过现象分析潜在的需求
很多情况下客户并非专业人士，在他们滔滔不绝的描述中不能指望他们帮助我们整理出重点和技术难关，这需要我们去为客户进行分析、归纳和整理，尤其是客户谈的不多却又是技术上实现难度和强度很高的地方特别值得注意。
客户往往对需求的概念是非常模糊的，大多时候给出的需求都是笼统而且尺度难以控制的，这就要求业务人员在倾听了客户的详细说明以后，帮助客户进行整理和分析，同时预测客户在开发过程中变更及今后应用中可能进行修改升级的潜在需求。
比如在为客户设计办公自动化系统的时候，也许就要为客户预留将来与他们的业务单位进行交互的通道；在设计邮件系统的时候要考虑可能会需要广告管理服务器；设计网络电子商店时今后增加库存产品进销存统计分析等等；限于时间财力的考虑，客户通常能够接受分阶段实施的开发过程，在需求分析时，提早为客户设想到今后的需求变更除了使项目开发更加顺利以外，也为今后业务的进一步深入打下了更好的基础。
笔者曾负责一个大型新闻网站的设计，当客户拿着将近五十页厚的一本设计要求报告时，我发现有四十页的内容对程序开发来说都是重复的，而在其中一页的角落却画了个“搜索其他网站相关新闻”的按钮，并且没有做任何说明，仅仅这10个字所完成的工作量完全顶的上其他整整四十页重复赘述所做的工作，客户完全不知道这个要求引发的问题实际就是一个搜索引擎的开发，通过协商，客人同意了修改成站内搜索的引擎。
三：利用自然的语言描述项目模型
在业务员与客户进行沟通和调查时撰写的需求分析，尽可能用自然的语言进行描述，虽然客户的水平和资历有所不同，但是最自然的描述能够使项目开发的各个成员都能清楚地理解需求含义，不至于在理解上产生偏差。对客户而言，这样的模型描述最接近真实，容易参与修订，并能以此为测试和验收的依据。
请比较以下两份关于需求的描述， “用户在访问首页的时候可以在点击‘客户通道’按钮，弹出填写‘用户名’和‘密码’的窗口，输入正确后在新窗口打开客户通道的首页，在该页显示所有可操作的功能的导航条和最新的导读新闻链接列表 。”
“站点分为公开和加密两种状态，通过身份验证机制使特有的用户可以访问到加密信息，并提供不同于普通用户的功能。” 前段描述我们就很容易想象的出来设计完成的网站是什么样子，而后一段的描述可能会做出无数不同的版本，造成对需求理解的歧意。
四：利用示意图和图表将用户的需求表现出来
需求分析无论文字上怎么样表述都还是抽象的，对客户而言理解毕竟是困难的，将基本确定的需求制作出示意图是最直观有效的。
制作示意图可以有很多种方式，用PowerPoint或Visio制作流程示意，用Html文档制作界面示意都是可行的，最简单利用画图和Word表格方式也完全可以，关键是利用示意图将客户的需求和即将开始设计的系统体现起来，在进行系统分析和程序开发之前，双方对今后要完成的产品就能够有直观的认识，换言之，就是在产品还没有真正进入开发阶段的时候，双方就对工作的结果达成统一的意见，这将大大地减轻需求变更所带来的困扰，同时客户更容易地参与到项目的开发过程，保证项目往正确的方向进行。
在RUP中有这样的描述：
利用电影、卡通、图片、表格和动画片等制作示意图开始，告诉我们用户是谁，要发生什么事情，如何发生。
以用户友好的方式帮助收集并改进用户需求。
鼓励更有创造性、更加创新的设计解决方案。 鼓励团队复审，并避免所有人都不希望出现的特征。
确保以可理解、直观的方式实施特征。
使访谈过程变得轻松，避免出现访谈没有结果的现象。
简单地说，制作示意图就是使用工具向用户 (主角) 说明（有时是动画演示）系统如何适应组织的需要，并表明系统将如何运转。协调员将初始示意板展示给小组，小组成员提供意见。之后，在举办研讨班期间，示意板也进行“实时”演进。所以，您需要一种可以轻松更改示意板的画图工具。为了避免分散注意力，一般最好使用简单的工具，比如图表、白板或PowerPoint。
五：什么人要看需求分析报告
项目经理、系统分析员、开发经理、交互设计师、测试人员、文档人员包括客户代表都应该看需求分析，并进行共同的讨论，达成一致的意见。
我们经常会遇到业务人员辛辛苦苦谈下来的项目，对开发人员来说却是难以实现的，而技术人员设计的产品却常常得不到客户的认可，甚至发生纠纷，因此参与项目开发的人员都应该对这份需求有统一清晰的认识，并根据自己的工作对需求提出意见，通过与客户的沟通修订，最终确定项目实现的目标。
例如：
项目经理通过需求分析才能组建所需要的团队包括配置工作环境，制定开发周期。 开发周期的限制和功能上的要求可能会影响到程序员采用什么样的语言和工具进行编写； 操作用户的技能水平将影响到交互设计师进行前台设计时做到什么样的精度； 界面设计人员根据项目的性质和定位确定表现方式。 测试人员了解测试环境和条件后才能对项目质量进行跟踪和检测；
通过下表，我们可以看的出不同角色根据需求的变更所进行的工作流程：

六：建立需求变更日志，制作新版本的需求分析报告
尽管我们费了许多功夫在需求分析进行了最大可能的努力，但几乎可以肯定的是，这份需求分析在开发过程中一定会发生变化，也许是出自客户的遗漏，也可能是在开发过程中被激发出来的，这种变更有时是如此的频繁和琐碎，以至于往往不能将变更及时反馈到项目的各个角色中，那么做好需求变更日志就显得非常重要。
在需求分析后面附上变更日志，并将修改后的需求分析制作成新版本，保留每次更改过的版本，而不是覆盖，这样就比较容易地跟踪到需求变更过程中所带来的工作调整。
在新版本的需求分析中，将变更多部分用特殊方式表明出来，并在日志中记录变更多重的明细。
关于需求分析和变更管理可以参照下图示意：

七：本阶段重点工作角色
在需求分析和变更管理的过程中，工作量最大的角色为客户代表、业务员和项目经理。
客户代表提出需求，业务员帮助整理和分析，项目经理对整个项目进行评估。
在实际工作中，很多项目失败的起因都和需求分析有关。 客户代表和业务员通常并非从事技术开发的专业人员，在讨论需求的时候往往对项目的技术难度、工作量、时间进度把握不准确，这时候需要项目经理或技术人员进行参谋。
为了降低项目的风险，提高工作效率，有必要设计规范的需求管理计划书，帮助客户代表和业务员更好的完成任务。
以下提供一份需求管理计划的模板可作为参考：

八：总结
根据笔者的经验，要尽快做好需求分析掌握以下要点，也许能事半功倍：
仔细聆听，罗列客户的所有要求； 将需求进行分析，确认可操作的系统模型； 利用最自然的语言将系统进行描述，使每个开发人员不会产生歧意； 迅速确定网站的用户角色； 比如访客、会员、重要客户、前台管理员、网站管理员、业务员等； 分析确定每个角色的权限及可操作的功能； 比如会员可以查看特别信息、修改个人信息、退出登陆等； 前台管理员能够登录管理系统，能够发布编辑修改信息，能够审查会员资格等； 网站管理员可以更改栏目、修改网站界面等； 制作流程图和示意图将需求表现出来； 让客户参与到示意图的设计中，及时正确的反应出需求变更。 制作需求变更日志，保留升级版本，通过版本控制进行需求管理； 通过需求《管理计划书》使每个参与人员看到共同的努力目标。

㈨ 需求分析的详细分析

从广义上理解：需求分析包括需求的获取、分析、规格说明、变更、验证、管理的一系列需求工程。
狭义上理解需求分析指需求的分析、定义过程。 需求分析就是分析软件用户的需求是什么。如果投入大量的人力，物力、财力、时间，开发出的软件却没人要，那所有的投入都是徒劳。如果费了很大的精力，开发一个软件，最后却不满足用户的要求，从而要重新开发过，这种返工是让人痛心疾首的(相信大家都有体会)。比如：用户需要一个for linux的软件，而你在软件开发前期忽略了软件的运行环境，忘了向用户询问这个问题，而想当然的认为是开发for windows的软件。当你千辛万苦地开发完成向用户提交时才发现出了问题，那时候你是欲哭无泪了，恨不得找块豆腐一头撞死。
需求分析之所以重要，就因为他具有决策性、方向性、策略性的作用，他在软件开发的过程中具有举足轻重的地位，大家一定要对需求分析具有足够的重视。在一个大型软件系统的开发中，他的作用要远远大于程序设计。 需求分析阶段的工作,可以分为四个方面：问题识别、分析与综合、制订规格说明、评审。
问题识别：就是从系统角度来理解软件，确定对所开发系统的综合要求，并提出这些需求的实现条件，以及需求应该达到的标准。这些需求包括：功能需求(做什么)、性能需求(要达到什么指标)、环境需求(如机型、操作系统等)、可靠性需求(不发生故障的概率）、安全保密需求、用户界面需求、资源使用需求(软件运行是所需的内存、CPU等)、软件成本消耗与开发进度需求、预先估计以后系统可能达到的目标。
分析与综合： 逐步细化所有的软件功能，找出系统各元素间的联系，接口特性和设计上的限制，分析他们是否满足需求，剔除不合理部分，增加需要部分。最后综合成系统的解决方案，给出要开发的系统的详细逻辑模型(做什么的模型)。
制订规格说明书： 即编制文档，描述需求的文档称为软件需求规格说明书。请注意，需求分析阶段的成果是需求规格说明书，向下一阶段提交。
评审： 对功能的正确性，完整性和清晰性，以及其它需求给予评价。评审通过才可进行下一阶段的工作,否则重新进行需求分析。 需求分析的方法有很多，这里只强调原型化方法，其它的方法如：结构化方法、动态分析法等，从来没用过这些方法在此不讨论。
原型化方法是十分重要的，原型就是软件的一个早期可运行的版本，它实现了目标系统的某些或全部功能。
原型化方法就是尽可能快地建造一个粗糙的系统，这系统实现了目标系统的某些或全部功能。但是这个系统可能在可靠性、界面的友好性或其他方面上存在缺陷。建造这样一个系统的目的是为了考察某一方面的可行性，如算法的可行性、技术的可行性或考察是否满足用户的需求等。如：为了考察是否满足用户的要求，可以用某些软件工具快速的建造一个原型系统，这个系统只是一个界面，然后听取用户的意见，改进这个原型。以后的目标系统就在原型系统的基础上开发。
原型主要有三种类型：探索型、实验型、进化型。
探索型：目的是要弄清楚对目标系统的要求，确定所希望的特性，并探讨多种方案的可行性。
实验型：用于大规模开发和实现前，考核方案是否合适，规格说明是否可靠。
进化型：目的不在于改进规格说明，而是将系统建造得易于变化，在改进原型的过程中，逐步将原型进化成最终系统。
在使用原型化方法时有两种不同的策略：废弃策略、追加策略。
废弃策略：先建造一个功能简单而且质量要求不高的模型系统，针对这个系统反复进行修改,形成比较好的思想，据此设计出较完整、准确、一致、可靠的最终系统。系统构造完成后，原来的模型系统就被废弃不用。探索型和实验型属于这种策略。
追加策略：先构造一个功能简单而且质量要求不高的模型系统，作为最终系统的核心，然后通过不断地扩充修改，逐步追加新要求，发展成为最终系统。进化型属于这种策略。 客户与开发人员交流需要好的方法。下面建议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%的比例，其它两种情况一年都不会遇到一次。实际中还有很多这样的例子，不一一列举了。 永远别忘了：需求分析和程序设计不尽相同，合理、可行是才是重要的。跳出程序设计的圈子，站在系统的角度上来看问题，你的结论会截然不同。