需求分析模板需求分析时应该建立哪些模型，如何建立？

怎么做项目需求分析报告

做项目真辛苦阿！这样的感叹整天都挂在口上。

客户需求变动确实是一个软件开发永远不变的话题。

为什么小的软件企业面对经常变动的需求是如此的狼狈？到底要怎么做才能满足客户的需求？ 听棠的“客户需求何时休”深刻的披露了这个问题存在的根源。

需求分析，不仅仅是拿到客户的需求，更重要的是还需进行分析，了解细节，并就细节跟客户咨询，获取最详细的资料。

客户所能提供给你的只是他们想到的功能需求，很多问题并不在他们考虑的范围之内，如果作为项目承担方没有去做分析，简单的按照功能要求去设计、规划，最终出来的系统是很难完全符合客户的业务流程的，这时，自然需要更改，被看成了需求的更改。

其实，都是缺乏分析所一手造成的。

问题等到系统出来了才被发现，这样的系统本身就是先天不足的了。

听棠所说到的几点，感受特别深： “其实问题出在开头，客户需求只是软件需求分析的一部分，虽然是比较重要的一部分，但也不要只是去记客户的需求，而是要把客户的需求进行分析” “客户本身是不怎么懂技术的，客户只知道自己的业务需求，而在软件设计时，是在把业务需求抽象到系统中实现的，把业务转变为逻辑时，一切都应该符合逻辑的，但客户的业务思想有时候在软件系统实现时会有问题的，这就需要分析时分析出来的。

少了分析，问题也会在后面的开发中暴露出来，到时可就更麻烦了。

” 还有客户的需求本身会有矛盾（这矛盾是指在逻辑角度来讲），客户本身是意识不到的，只有在分析设计时，才会分析出这里的矛盾，而这些问题，如果在期初时，软件负责人不分析，而是纯粹的“听从”客户要求去做，当暴露这些问题时，你怪客户也没用啊。

项目需求分析报告，在了解客户需求时，不要不动脑子，不要一味的点头说“I C”，其实在表面的业务里面可能包含着N多的细节，这些细节是需要你反问客户的，只有当你提的问题越多，最终获取的需求最具体，才能让项目越顺利。

而且有很多问题，都是在你的反问中，客户也才开始思考本来没思考过的问题，客户也会找到一种合理的需求给你，有人会觉得这样了解客户需求未免太麻烦了。

至于一些在技术上会遇到问题的地方，也要告诉客户，别以为到时候再说，客户是不关心你的技术细节的，但你如果给他解释的话，他也会试着理解的。

客户的需求本身是无休止，因为他们本身也在变，但当你期初的分析合理，后面的变动也将在逻辑上变动，相信代价已经不会那么大了。

这其实也体现了系统的扩展性。

需求分析，是一个项目提出方和承担方相互沟通的过程，一方是系统的使用者，一方是系统的制造者，在系统制造过程中，只有双方相互配合，共同对系统进行设计才能最后达到使用的要求。

客户是业务上的熟悉者，对业务流程有非常清晰的了解，但是，对于软件需求方面的描述是不了解的，他们所能提供的只是他们最终要达到的功能，但是，这其中包含的业务流程是非常复杂的。

我们拿到客户需求后，应该根据功能、流程进行初步的设计，构造出业务流程图，再让客户进行评审，提出业务流程上不对的地方进行修改。

这样来回的交流，最终才能取得较全面的需求，并减少后期的修改。

人员需求报告怎么写？

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

　　公司年度人员需求预测报告 　　文本名称 ××公司年度人员需求预测报告 受控状态 　　编 号 　　一、目录（略） 　　二、呈送文（略） 　　三、报告正文 　　（一）人力资源现状分析 　　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. 引言 1.1. 背景 说明： a．待开发的软件系统的名称； b．本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络； C．该软件系统同其他系统或其他机构的基本的相互来往关系。

1.2. 参考资料 列出本说明书中引用和参考的资料，如： a．本项目的经核准的计划任务书或合同、上级机关的批文； b．属于本项目的其他已发表的文件； c．本文件中各处引用的文件、资料、包括所要用到的软件开发标准。

列出这些文件资料的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。

1.3. 假定和约束[可选] 列出进行本软件开发工作的假定和约束，例如经费限制、开发期限、设备条件、用户的资料准备和交流上的问题等。

1.4. 用户的特点[可选] 列出本软件的最终用户的特点，充分说明操作人员、维护人员的教育水平和技术专长，以及本软件的预期使用频度。

这些是软件设计工作的重要约束。

2. 功能需求 2.1. 系统范围 明确概要地说明用户对系统、产品高层次的目标要求，如系统开发的意图、应用目标、作用范围以及其他相关的背景材料。

如果所定义的产品是一个更大系统的一个组成部分，则应说明本产品与该系统中其他各组成部分之间的关系，为此可使用一张方框图来说明该系统的组成和本产品同其他各部分的联系和接口。

2.2. 系统体系结构（二层架构的系统可剪裁本小节）[可选] 以图+文本结合的方式描述系统的总体架构。

以下应提供系统总体架构图： 以下对系统总体架构进行描述： 2.3. 系统总体流程 以图+文本结合的方式说明系统的总体流程。

图一是计划合同管理系统的总体流程图。

图一 2.4. 需求分析 需求分析的目的是获取或描述系统需求中的每一个功能需求，并通过分析确定系统能够做什么？谁来使用这个系统？ · 建立用例模型：发现角色和用例，并确定角色之间的关系、用例之间的关系，以及角色与用例之间的相互关系 · 描述用例：角色与系统如何交互的规格说明。

2.4.1. XXXXXXX(功能需求名称) 2.4.1.1. 功能描述 功能编号： 功能需求：从用户业务的角度描述功能需求。

2.4.1.2. 业务建模 从可视化的角度--用例图--描述功能需求 图二是综合计划管理系统合同编辑业务的功能需求用例图。

图二 2.4.1.3. 用例描述 以文本的方式描述每一个用例中角色与系统相互交互的规格说明。

1、 XXXXXX(用例名称) 描述对象 描述内容 标识符 用例的唯一标识符 说明 对用例的概要说明 参与者 与该用例相关的参与者列表，以及参与者的特点 频度 参与者访问此用例的频率 状态 通常分为：进行中、等待审查、通过审查或未通过审查 前置条件 一个条件列表，如果其中包含条件，则这些条件必须在访问用例之前得到满足 后置条件 一个条件列表，如果其中包含条件，则这些条件将在用例成功完成以后得到满足 被扩展的用例 此用例所扩展的用例（如果存在） 被包含的用例 此用例所包含的用例（如果存在） 基本操作流程 参与者在用例中所遵循的主逻辑路径，即当各项工作都正常进行时用例的工作方式 可选操作流程 在变更工作方式、出现异常或发生错误的情况下所遵循的路径 修改历史记录 修改人 ： 修改日期：修改原因： 问题 如果存在，则为与此用例的开发相关的问题或操作项目的列表 以下是综合计划管理系统中的合同编辑功能需求中的合同增加用例描述： 描述对象 描述内容 标识符 IPMS0101 说明 增加一条合同记录 参与者 合同编辑人员--熟悉合同管理业务 频度 状态 通过审查 前置条件 1. 参与者具有合同增加的权限2. 参与者已选取对应的计划记录3. 当前计划总投资≥SUM(该计划下已签合同价) 后置条件 1. 数据库中更加一条合同纪律2. 可执行合同原件扫描用例3. 可执行合同付款增加用例4. 可执行合同修改和合同删除用例 被扩展的用例 无 被包含的用例 无 基本操作流程 请参见图三的合同增加流程 可选操作流程 当用户确认合同增加时发现异常时，系统提示合同增加无效的提示 修改历史记录 修改人 ： 修改日期：修改原因： 问题 1. 合同编码的具体约定2. 合同类型、资金来源、合同受委托方字典表的具体设计 图三 合同增加活动流程 2、XXXXX(用例名称) …… 2.4.1.4. 用户界面 概要描述功能对应的用户界面风格，采用原型生命周期的项目也可以提供原型界面拷贝。

2.4.2. XXXXXXX(功能需求名称) …… 3. 非功能需求 3.1. 性能要求 3.1.1. 精度[可选] 说明对该软件的输入、输出数据精度的要求，可能包括传输过程中的精度。

3.1.2. 时间特性要求 说明对于该软件的时间特性要求，如对：响应时间；更新处理时间；数据的转换和界面更新传送时间等的要求。

3.1.3. 输人输出要求 解释各输入输出数据类型，并逐项说明其媒体、格式、数值范围、精度等。

对软件的数据输出及必须标明的控制输出量进行解释并举例，包括对硬拷贝报告（正常结果输出、状态输出及异常输出）以及图形或显示报告的描述。

3.2. 数据管理能力要求[可选] 说明需要管理的文卷和记录的个数、表和文卷的大小规模，要按可预见的增长对数据及其分量的存储要求做出估算。

3.3. 安全保密性要求 用户对系统所应具备的故障处理能力、处理方式及故障后的系统恢复、数据恢复等要求，对系统防止机密数据被非法侵入、修改及丢失的要求。

3.4. 灵活性要求[可选] 说明对该软件的灵活性的要求，即当需求发生某些变化时，该软件对这些变化的适应能力，如： a．操作方式上的变化； b．运行环境的变化； c．同其他软件的接口的变化； d．精度和有效时限的变化； e．计划的变化或改进。

对于为了提供这些灵活性而进行的专门设计的部分应该加以标明。

3.5. 其他专门要求[可选] 如用户单位对使用方便的要求，对可维护性、可补充性、易读性、可靠性、异常处理要求、运行环境可转换性的特殊要求等。

4. 运行环境规定 4.1. 设备 列出运行该软件所需要的硬设备。

说明其中的新型设备及其专门功能，包括： a．处理器型号及内存容量； b．外存容量、联机或脱机、媒体及其存储格式，设备的型号及数量； c．输入及输出设备的型号和数量，联机或脱机； d．数据通信设备的型号和数量； e．功能键及其他专用硬件 4.2. 支持软件 列出支持软件,包括网络和硬件设备平台、操作系统平台、数据库系统平台以及编译（或汇编）程序和测试支持软件等。

4.3. 接口[可选] 说明该软件同其他软件之间的接口、数据通信协议等。

4.4. 控制[可选] 说明控制该软件的运行的方法和控制信号，并说明这些控制信号的来源。

5. 需求跟踪 需求跟踪的主要目的是保证所有的需求都得到分析，以承诺需求-分析需求对应表（PRS_SRS表）的方式描述已分析需求对已承诺需求的覆盖情况。

PRS_SRS表的格式请参见软件需求管理过程规范（SUPL-MANU-SRS-001）。

需求分析时应该建立哪些模型，如何建立？

　　需求分析是指理解用户需求，就软件功能与客户达成一致，估计软件风险和评估项目代价，最终形成开发计划的一个复杂过程。

（这个和我在微软体验到的又不太一样，微软的需求分析大多是市场人员和用户协助小组的人去评估用户的接受程度，这一点也可以理解，因为公司的性质有根本差别）在这个过程中，用户的确是处在主导地位，需求分析工程师和项目经理要负责整理用户需求，为之后的软件设计打下基础。

需求分析阶段结束后，要求得到：1.SRS文档 (System Requirement Specification); 2.DRM 文档；eptance Plan. 　　从广义上理解：需求分析包括需求的获取、分析、规格说明、变更、验证、管理的一系列需求工程。

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

　　一、为什么要需求分析 　　需求分析就是分析软件用户的需求是什么.如果投入大量的人力，物力,财力,时间,开发出的软件却没人要,那所有的投入都是徒劳.如果费了很大的精力,开发一个软件,最后却不满足用户的要求,从而要重新开发过,这种返工是让人痛心疾首的.(相信大家都有体会)比如,用户需要一个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、 尊重开发人员采用的需求分析过程 　　软件开发中最具挑战性的莫过于收集需求并确定其正确性，分析人员采用的方法有其合理性。

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

　　“需求确认”意味着什么 　　在“需求分析报告”上签字确认，通常被认为是客户同意需求分析的标志行为，然而实际操作中，客户往往把“签字”看作是毫无意义的事情。

“他们要我在需求文档的最后一行下面签名，于是我就签了，否则这些开发人员不开始编码。

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

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

” 　　这两种态度都是不对的。

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

　　对“需求分析报告”的签名是建立在一个需求协议的基线上，因此我们对签名应该这样理解：“我同意这份需求文档表述了我们对项目软件需求的了解，进一步的变更可在此基线上通过项目定义的变更过程来进行。

我知道变更可能会使我们重新协商成本、资源和项目阶段任务等事宜。

”对需求分析达成一定的共识会使双方易于忍受将来的摩擦，这些摩擦来源于项目的改进和需求的误差或市场和业务的新要求等。

需求确认将迷雾拨散，显现需求的真面目，给初步的需求开发工作画上了双方都明确的句号，并有助于形成一个持续良好的客户与开发人员的关系，为项目的成功奠定了坚实的基础。

　　六、点评需求分析误区 　　要想说什么是好的需求分析，不如说什么是不好的需求分析，知道什么是不好的，自然也就知道了什么是好的。

以下就是一些不好的情况： 　　（1）创意和求实 　　毋庸质疑的，每个人都会为自己的一个新的Idea而激动万分，特别是当这个Idea受到一些根本不知道你原本要干嘛的人的惊赞时。

但是请注意，当你激动得意的时候，你可能已经忘了你原本是在描述一个需求，而不是在策划一个创意、创造一个概念。

很多刚开始做需求分析的人员都或多或少的会犯这样的错误，陶醉在自己的新想法和新思路中，却违背了需求的原始客观性和真实性原则。

　　永远别忘了：需求不是空中楼阁，是实实在在的一砖一瓦。

　　（2）解剖的快感 　　几乎所有搞软件的人，做需求分析的时候，一上来就会把用户告诉你的要求，完完整整的作个解剖，切开分成几个块，再细分成几个子块，然后再条分缕析。

可是当用户迷惑的看着你辛辛苦苦做出来的分析结果问你：我想作一个数据备份的任务，怎么做？这时，你会发现，需要先后打开三个窗口才能完成这个任务。

　　永远别忘了：分解是必需的，但最终的目的是为了更好的组合，而不是为了分解。

　　（3）角度和思维 　　经常听到这样的抱怨：“用户怎么可以提出这样苛刻的要求呢？”。

细细一了解，你会发现，用户只不过是要求把一个需要两次点击的功能，改成只有一次点击。

这样会导致需要改变需求、改变编码、甚至重新测试，增加工作量。

可是，如果换个角度来想想，这个功能，开发的时候只用了几次、几十次，可是用户每天都要用几百次甚 至几千次几万次，改动一下就减少了一半的工作量，对他来说，这样的需求难道会苛刻吗？ 　　永远别忘了：没有任何需求是不对的，不对的只是你的需求分析。

试着站在用户的思维角度想想，你的需求分析就会更加的贴近用户，更加的合理。

软件应该是以人为本的。

　　（4）程序员逻辑 　　从程序员成长为系统分析员是一个普遍的轨迹，但并不是一个好的程序员就必然能成为一个好的系统分析员。

一些程序员的固化逻辑，使得他们在做需求分析的时候往往钻进了一些牛角里面。

比如说1／0逻辑（或者是说黑白逻辑），认为不是这样就是那样，没有第三种情况。

可实际情况往往是，在一定的时候是这样，其它时候是那样。

又比如穷举逻辑，喜欢上来就把所有一二三可能的情况列举出来，然后一个一个分别处理，每个占用三分之一的时间；可是实际的情况往往是，三分之一的情况占了99％的比例，其它两种情况一年都不会遇到一次。

实际中还有很多这样的例子，不一一列举了。

　　永远别忘了：需求分析和程序设计不尽相同，合理、可行是才是重要的。

跳出程序设计的圈子，站在系统的角度上来看问题，你的结论会截然不同。