软件开发计划评审 软件开发计划评审报告
测试计划怎么评审
1.计划评审测试计划编写完成后，一般要对测试计划的正确性、全面性以及可行性等进行评审，评审人员的组成包括软件开发人、营销人员、测试负责人以及其他有关项目负责人。
2.计划总结项目完成后，应该对计划的执行情况进行评审，看有哪些不合理的地方，以便为编写下一个项目测试计划做经验积累。
测试计划Testing plan，描述了要进行的测试活动的范围、方法、资源和进度的文档；是对整个信息系统应用软件组装测试和确认测试。
它确定测试项、被测特性、测试任务、谁执行任务、各种可能的风险。
测试计划可以有效预防计划的风险，保障计划的顺利实施。
软件项目开发计划是什么？
.1编写目的【阐明编写开发计划的目的，指出读者对象。
】 1.2项目背景【可包括：a.项目的委托单位、开发单位和主管部门.b.该软件系统与其他系统的关系。
】 1.3定义【列出本档中用到的专门术语的定义和缩写词的原文。
】 1.4参考资料【可包括：a.项目经核准的计划任务书、合同或上级机关的批文；b.文档所引用的资料、规范等；列出这些资料的作者、标题、编号、发表日期、出版单位或资料来源。
】 2.项目概述 2.1工作内容【简要说明项目的各项主要工作，介绍所开发软件的功能、性能等。
若不编写可行性研究报告，则应在本节给出较详细的介绍。
】 2.2条件与限制 【阐明为完成项目应具备的条件、开发单位已具备的条件以及尚需创造的条件。
必要时还应说明用户及分合同承包者承担的工作、完成期限及其他条件与限制。
】 2.3产品 2.3.1程序【列出应交付的程序名称、使用的语言及存储形式。
】 2.3.2文档【列出应交付的文档。
】 2.4运行环境【应包括硬件环境、软件环境。
】 2.5服务【阐明开发单位可向用户提供的服务。
如人员培训、安装、保修、维护和其他运行支持。
】 2.6验收标准 3.实施计划 3.1任务分解【任务的划分及各项任务的负责人。
】 3.2进度【按阶段完成的项目，用图表说明开始时间、完成时间。
】 3.3预算 3.4关键问题【说明可能影响项目的关键问题，如设备条件、技术难点或其他风险因素，并说明对策。
】 4.人员组织及分工 5.交付期限 6.专题计划要点 【如测试计划、质量保证计划、配置管理计划、人员培训计划、系统安装计划等。
软件开发项目计划的目的与作用是什么呢？
项目计划目的与作用 根据软件能力成熟度模型集成CMMI1.1，软件开发项目计划的目的是：建立和维护定义项目活动的计划。
项目计划属于CMMI的第2级，其过程域包括开发项目计划、与相关人员交流、获取对计划的承诺、维护计划；项目计划为实施和监控项目活动提供了基线。
项目计划的第一个目的是建立估计值，即建立和维护项目计划因素的估计值。
为此应该确定项目范围，即通过建立高层工作分解结构来估计项目范围；监理工作产品和任务属性的规模与复杂度；确定项目的生命周期阶段、以此来限定计划范围；基于估算的原理进行对工作产品和任务的项目工作量和成本的估算。
项目计划的第二个目的是开发项目计划文档，即文档化项目计划，维护项目计划，并以此作为项目管理的基线。
为此应该建立和维护项目的预算和进度表；要识别和分析项目风险；确定如何采集和管理项目数据；确定实施计划所需要的各种资源；确定项目实施所必需的知识和技能；确定各项任务或活动的承担人；编写项目计划文档。
项目计划的第三个目的是获得并维持所有项目干系人对项目的承诺。
为此应当评审影响项目的所有计划使所有项目干系人理解项目承诺；必要时调整项目计划以适应有效的和已经估计的资源；获取所有项目干系人特别是项目任务或活动的承担人对项目计划的承诺。
项目计划是项目实施的基础。
通过所有项目干系人认可的项目计划形成文件，便于本企业高层领导、相关管理部门粮道、相关参与部门领导、项目组成员、客户、协作单位、分包单位等等所有项目干系人之间的交流沟通。
项目计划是项目组为实现项目目标而科学地预测并确定项目生命周期的行动方案。
任何项目计划都是为了解决三个问题：一是确定项目目标，二是确定为了达成项目目标的各项行动的顺序和时间，三是确定项目中每项行动所需要的资源。
所以制定项目计划就是在明确项目目标的基础上，确定项目行动方案，分配相关资源的项目综合管理过程，就是通过对历史的、当前的、项目或组织内部的和项目或组织外部的有关信息进行分析和评价，对项目生命周期过程中可能的发展进行评估、预测，对新项目实施工作进行的各项活动做出尽可能周密的安排，最终形成一个所有项目干系人认可的、约定项目各项活动、作为项目实施工作基础的文件—项目计划。
项目计划围绕项目目标的完成系统地确定项目的任务、安排任务进度、编制完成任务所需的资源预算等，从而保证项目能够在合理的工期内，用尽可能低的成本达到尽可能高的项目质量要求。
在制定项目计划过程中必须明确五个基本问题：做什么、如何做、何时做、谁去做、需要多少资源。
简单地说，项目计划可以起到如下作用： 1、 确定完成项目目标所需的各项任务范围，落实责任，制定各项任务的时间表，明确各项任务所需的人力、物力、财力； 2、 确定项目的工作规范，遵循的标准，成为项目实施的依据和指南； 3、 明确项目组各成员及其工作责任范围以及相应的职权；使项目组成员明确自己的工作目标、工作方法、工作途径、工作期限要求； 4、 保证项目进行过程中项目组成员和项目干系人之间的交流、沟通与协作，使得项目各项工作协调一致，增加客户满意度； 5、 为项目的跟踪控制提供基础。
6、 项目计划在项目中起到承上启下的作用，计划批准后应当作为项目的工作指南。
软件开发计划制定中的几个问题是什么？
1.1 详细设计不彻底 详细设计的不彻底，导致开发计划制定后执行的空洞，从而无法真正实现计划的实现和监控，大多的情况是在不断的弥补，或者进度的追赶，从导致代码的质量无法保证，甚至亦无法保证功能的实现。
1.1.1 详细的设计的不足 很多开发人员在接到开发任务后，担心不能及时完成任务，在匆忙做完了概要设计（其实此时的概要设计可能根本不能满足需要），以没有时间为借口，直接进入到编码阶段，没有对软件系统进行更为详细的设计，从而导致了对开发中出现的问题没有做出相应的应对措施。
而且在出现问题后，对问题认识的不足（包括担心问题的出现会使自己的技能被别人否定等），和解决方法的缺乏，从而导致了问题的堆积和时间的流失，到最后使得项目的进度不得不发生了延迟。
众多公司的项目和产品中普遍存在这个问题。
1.1.2 详细设计应该达到的地步 详细设计应该能够达到一个这样的地步，比如，在一个模块所需要实现的功能基础上，对此模块再次进行的详细设计，以至不可再分，甚至可以细化到可以实现的某一个具体的函数、类、属性等之上。
而且不遗漏细节！ 比如页面设计 可以以页面为单位进行详细设计，从而细化到每个页面大概需要实现的基本要素，包括多少个按钮、列表框、输入框等，以及每个页面中的功能点，包括需要连接的数据库等。
这样每个页面的具体时间就能准确的确定，并被执行。
且需要做出一个网页的设计图样，共项目评审使用。
比如图形制作可以以每幅图为单位进行详细设计，从而可以细化到每个可能需要实现的基本要素，包括道路等各项图形要素，以及功能点等。
这样每副图形制作的具体时间就能准确的确定，并被执行。
亦可以做评审使用。
1.1.3 重物的称量 试想，我们需要称量一个重物，如果没有磅秤，只有弹簧称，那么我们只能将此重物进行分割，方能知道此重物的重量，而且需要保证在分割的过程中没有损耗。
否则就需要进行一个定量的、适度的估算，比如百分比等，以弥补分割过程的损耗。
在这个比喻中，我们把重物看成是个项目，分割重物的人是项目经理或系统分析人员，称量的人则是实施开发的人员，分割过程则是项目开发过程。
如果在分割重物的人，没有具备分割的能力，重物的重量将会远远偏离其实际目标。
如果称量重物的人，没有具备称量的能力，重物的重量也会偏离其实际目标，只不过相对于分割重物的人的不称职，离目标可能会近些。
1.1.4 西瓜籽的计算 有时候我们开发项目的过程也想一个计算西瓜籽的过程。
看下面的过程，根据西瓜向阳一面多籽的特性，确立西瓜的中心线，然后将西瓜籽分解成阳面、阴面的两部分，再根据中心线与阳面、阴面的距离，将西瓜进行多次分块，直到我们能够较容易得数出西瓜中的西瓜籽。
这样我们可以对所有的西瓜块进行分类，这样就能够很快的得出西瓜籽的数量。
如果我们对西瓜的结构很是了解，那么即使有些误差，但也会相差无几。
在这里，西瓜是我们需要建立的系统，西瓜籽是我们所需要实现的功能，西瓜籽的数目则是我们的时间，对西瓜的分块和分类则是我们的进度安排。
而我们只有采用科学的方法，才能快捷的获得一个较为准确的项目进度计划。
项目开发计划与软件测试有哪些呢？
要适当文档化，＂源代码就是设计＂体现在业务流程细节上，大方面业务流程、特殊算法、产品功能规划、系统设计、开发计划与优先级等，一定要文档化；老是把这些东西保存在开发人员和测试人员的大脑里，是一个管理混乱的表现，随着人员流动，新人需要从代码和测试慢慢明白系统的各种业务流程，是极大的浪费资源。
要更加强调软件测试，特别是开发人员的单元测试。
考试大（www.Examda。
com） 很多时候，开发人员特别是JAVA开发人员，喜欢做出漂亮的WEB界面，然后告诉你完成了，当你细细一点按钮来测试功能，却发现这也不行，那也不行----典型的好看不好用。
靠测试人员来保证软件质量是正确的，所谓QA，但是中国软件公司不注重测试是一个难以改变的现实，小公司就更严重了，全职的测试人员比例太小了，所以想依靠测试组来保证系统质量在小公司是不怎么现实的。
软件开发项目计划制定的原则是什么呢？
项目计划制定的原则 1、 目的性。
任何项目计划的制定应当围绕项目目标的实现展开。
制订计划的第一步就是必须分析目标、进而找出为了完成目标所要完成的所有任务。
2、 系统相关性。
项目计划由一系列子计划组成，如范围计划、人力资源计划、进度计划、资源计划、质量管理计划、风险管理计划等等。
各个子计划不是孤立存在的，彼此之间相对独立，又紧密相关，应当形成一个有机的整体。
构成项目计划的任何子计划的变化都会影响到其它子计划的制定和执行，进而影响到项目计划的正常实施。
3、 经济性。
项目不仅要有较高的效率，而且要有较高的效益，因此计划过程是对多种选择权衡、优化的过程。
考试大整理 4、 动态性。
由于项目环境一般处在变化之中，特别是软件开发先把棺木的多变性，经常使计划的实施偏离项目的基准计划，因此项目计划要随作环境和条件的变化不断调整和修改，以保证项目目标的完成。
如何防止项目计划多变，对出现的问题及时加以处理以保证进度按原计划实现，在一定的意义上说甚至是更为重要的。
防止项目计划多变，就要改进计划的编制工作，提高计划的质量，这首先要求项目经理和项目计划制定人员应当较好地掌握项目的环境条件，对各种条件进行深入的调查落实并做出有根据的预测，据以制定实施方案，适当留有余地，以使编制的项目计划切实而可行。
其次就是要使这种计划能够得到贯彻执行，因为再好的计划，如果不能认真执行，也不过是毫无意义的一纸空文。
根据各方面的经验，实行各种不同形式的责、权、利机制是保证计划实现的关键。
软件开发项目的进度安排方式有哪些？
软件开发项目的进度安排可以有两种考虑方式。
第一种，系统最终交付使用的日期已经确定，软件开发机构必须在合同规定的时间内安排；第二种，只确定了大致的年限，最后交付使用的日期由软件开发机构根据具体情况确定。
后一种考虑能够对软件开发任务进行细致的分析；能够最好地利用资源，合理地分配工作量，但实际工作中常常遇到第一种情况，问题是软件管理人员如何在规定的期限内分配人力和安排进度。
进度安排的好坏往往影响整个项目的按期完成和用户的使用，如不能按期完成，用户就会不满，而且需向用户赔偿损失。
如作为商品，将会失去市场竞争力。
进度安排的精确性有时比成本估算更重要。
在商品生产的社会中，某种商品的损失往往还可以通过其他商品或分期偿还来承担。
而进度拖延的损失是无法弥补的。
下面就软件开发项目进度安排中的几个问题进行讨论。
1.软件工作的特殊性 制定软件进度与其他工程没有很大的区别，因此使用一般的通用技术和工具即可。
但重点要强调的是软件产品是逻辑产品，这与其他工程不同。
因此当几个人共同完成某项任务时，人与人之间就有一个思想交流问题，称之为通信关系。
通信是要付出代价的，不只是要花时间，同时由于通信中的疏忽常常会使错误增加。
如一个组有4个软件工程师，两两之间进行通信联系，通信路径有6条；对6个软件工程师，则通信路径增加至14条。
因此所付的代价就必然会增加，所以工作组的人员不宜太多，一般3—5人为好，目前国外一般采用主程序员组的制度。
另一点要强调的是软件工作切忌中间临时加人，必须在安排进度时就考虑周到。
2.各阶段工作量的分配 估算出总的工作量以后，就需要一个可以进行各阶段工作量分配的模型。
某一阶段工作量所占的百分比必须根据经验数据确定。
这里要再一次强调，在开发过程中保存的记录将增加经验数据库存，而且将改善今后估算的准确性。
R.S.Pessman提出一种称作40-20-40的工作量分配规则，即前期工作（计划、需求分析、概要设计和详细设计阶段）和后期工作（测试阶段）各占40%，编码阶段占20%。
应该强调要重视前期和后期工作。
前期工作容易被忽视，主要原因是：管理人员认为不开始编码工作就算没有进行，他们不了解前期工作的重要性；技术人员往往也急于编码，认为写出代码任务就算完成了。
后期工作也容易被忽视，认为编码出来就完事了，对测试工作要占这么大的工作量没有思想准备。
所以要制定好进度计划，就要研究软件工作的规律，前期基础工作没做好，将会给后期工作带来很大困难，往往使工程进度一拖再拖，难以坚持，有的不得不中途夭折。
3.制定开发进度 需要涉及的下一个未知量是开发进度。
进度安排是软件计划工作中一项最困难的任务，计划人员要把可用资源与项目工作量协调好；要考虑各项任务之间的相互依赖关系，并且尽可能地平行进行；预见可能出现问题和项目的“细脖子”，并提出处理意见；以及规定进度，评审和应交付的文档。
假设用作变量的开发时间TD按线性变化，而且已经得到了总的开发工作量估算值ED，要求在规定的时间TD内完成，在项目中最好有参加工作的人员平均值M，即M=EDTD，这将是一个非常有用的数据。
遗憾的是在上述算式中，项目的工作量和开发时间不能作为独立的变量。
Books定律描述了这种现象的最极端情况：为误期的软件项目增加人员将会使其进度更慢。
来源：www.examda.com （四） 软件开发组织 有多少个软件开发机构，几乎也就有多少人员的组织机构。
不管这些组织机构是好或坏，一般是不可能轻易改变的。
尽管组织机构的改变不属于软件计划人员的职责范围内的事。
不过，在一个新的软件项目中直接涉及人员的组织问题却是可以，也应该在软件计划阶段加以认真考虑的。
IT公司软件开发部门员工的培训计划一般都包括哪些？
软件开发的主要任务是解决逗如何做地的问题 一、问题识别 首先系统分析人员要研究计划阶段产生的可行性分析报告和软件项目实施计划。
主要是从系统的角度理解软件并评审用于产生计划估算的软件范围是否恰当，确定对目标系统的综合要求，即软件的需求；并提出这些需求的实现条件，以及需求应达到的标准，也就是解决要求所开发软件做什么，做到什么程度。
这些需求包括： （1）功能需求：列举出所开发软件在功能上应做什么，这是最主要的需求。
（2）性能需求：给出所开发软件的技术性能指标，包括存储容量限制、运行时间限制、安全、保密性等。
（3）环境需求：这是对软件系统运行时所处环境的要求。
例如，在硬件方面，采用什么机型、有什么外部设备、数据通信接口等等；在软件方面，采用什么支持系统运行的系统。
（4）可靠性需求：各种软件在运行时，失效的影响各不相同。
在需求分析时，应对所开发软件在投入运行后不发生故障的概率，按实际的运行环境提出要求。
对于那些重要的软件，或是运行失效会造成严重后果的软件，应当提出较高的可靠性要求，以期在开发的过程中采取必要的措施，是软件产品能够高度可靠地稳定运行，避免因运行事故而带来的损失。
（5）安全保密工作需求：工作在不同环境的软件对其安全、保密的要求显然是不同的。
应当把这方面的需求恰当地作出规定，以便对所开发的软件给予特殊的设计，使其在运行中其安全保密方面的性能能得到必要的保证。
（6）用户界面需求：软件与用户界面的友好性是用户能够方便有效地使用软件的关键之一，从市场角度来看，具有友好用户界面的软件有较强的市场竞争力。
因此，必须在需求分析时，为用户界面细致地规定达到的要求。
（7）资源使用需求：这是指所开发软件运行时所需的数据、软件、内存、空间等各项资源。
另外，软件开发时所需的人力、支撑软件、开发设备等属于软件开发的资源，需要在需求分析时加以确定。
（8）软件成本消耗与开发进度需求：在软件项目立项后，要根据合同规定，对软件开发的进度和各步骤的费用提出要求，作为开发管理的依据。
（9）预先估计以后系统可能达到的目标。
这样，在开发过程中，可对系统将来可能的扩充与修改做准备，一旦需要时，就比较容易进行补充和修改。
功能性需求是人们普遍关注的，但对非功能性需求的分析常常被忽视。
其实非功能性需求并不是无关紧要的，它们的主要特点涉及到的方面多而广，却容易被忽略，任何一个软件的非功能性需求都要根据其类型和工作环境来确定。
问题识别的另一项工作是建立分析所需要的通信（沟通）途径，以保证能顺利地对问题进行分析。
分析员必须与用户、软件开发机构的管理部门、软件开发组的人员建立联系。
项目负责人在此过程中起协调人的作用。
分析员通过这种通信途径与各方面商讨，以便能按照用户的要求去识别问题的基本内容。
此外，如果在进行需求分析之前没有做过可行性分析，那么补充完成这部分工作往往是必要的，从问题定义和调查研究入手，与用户密切联系，详细了解问题提出的背景、弄清要解决什么问题，然后从软件系统特性和用户目标出发，做市场调查和现场考察。
仔细收集信息之后进行数据分析和功能分析，建立系统的高层逻辑模型，再进一步做成本/效益分析。
最后提交一份可行性分析报告，从技术、经济、社会效应等方面论证可行性，以确认软件开发的目标是否可行。
二、分析与综合 需求分析的第二步工作是问题分析和方案的综合。
分析员需从数据流和数据结构出发，逐步细化所有软件功能，找出系统各元素之间的联系、接口特性和设计上的限制，分析它们是否满足功能要求，是否合理。
依据功能需求、性能需求和运行环境需求等，剔除其不合理的部分，增加其需要部分。
最终综合成系统的解决方案，给出目标系统的详细逻辑模型。
在这个步骤中，分析和综合工作反复地进行。
在对现行问题和期望的信息（输入和输出）进行分析的基础上，分析员开始综合出一个或几个解决方案，然后检查它的工作是否符合软件计划中规定的范围等等，再进行修改。
总之，对问题进行分析和综合的过程将一直持续到分析员与用户双方都感到有把握正确地制定该软件的规格说明为止 常用的需求分析方法有面向数据流的结构化分析方法（简称SA）、面向数据结构的Jackson方法（简称JSD）、面向对象的分析方法（简称OOA）等，以及用于建立动态模型的状态迁移图或Petri网等。
三、编制需求分析文档 在软件开发的瀑布模型中，每个阶段形成的最终文档是阶段完成的里程碑，因而，需求分析阶段编制文档以备下步评审，也是此阶段的重要任务之一。
以上已经确定的需求应当得到清晰准确的描述。
通常把描述需求的文档叫做软件需求规格说明书。
同时，为了确切表达用户对软件的输入输出要求，还需要制定数据要求说明书及编写初步的用户手册，着重反映被开发软件的用户界面和用户使用的具体要求。
此外，根据在需求分析阶段对系统的进一步分析，从目标系统的精细模型出发，可以更准确地估计所开发项目的成本与进度，从而修改、完善与确定软件开发实施计划。
四、...
软件需求设计评审须知的8大注意是什么？
、 注意对需求规格说明的正确性进行评审 需求规格说明的正确性通常可以从如下方面得以体现： 是否有需求与其他需求相互冲突或者重复？通常一份长达几百页的需求规格说明书都不会是一蹴而就的，它可能是系统分析师几个夜晚的心血之作。
正是因为撰写过程的连续性，可能导致同一份文档中前后名词定义不一致，前后观点上有重叠或差异的情况出现，这需要我们在撰写报告前首先要在思想上形成统一概念， 可使术语列表贯穿整份文档以达提纲挈领之效。
是否清晰、简洁、无二义地表达了每个需求？ “清晰”是让人能够读懂；“简洁”是让人愿意去读；“无二义”决定”读”的效果，是让大家对需求描述的理解能够达成一致。
需求陈述是“三重门”，这三扇门是否开启决定了需求说明书的质量高低。
我们尤其要拒绝“二义性”的名词术语的出现， 似是而非的概念定义是需求书应该避免的。
换句话说，如果一份需求说明书没能给人以清晰、简洁和无二义的阐述，则需求评审是没有进行下去的必要，同时也无法进行下去。
需求评审的前提是用户读懂了需求说明，并且用户的理解内容就是分析师们所描述的内容。
是否每个需求都通过了演示、测试、评审，分析是否得到了验证？ 需求应该是可以测试的，通常通过测试去验证它是不是正确。
比如我们完成了“销售员客户佣金提成规则”需求的撰写，如果需求书未能经过原型测试通过，则需求评审是不能得到通过的。
面对相当复杂的业务需求，经过测试或演示是让用户信任的一个必要过程。
试想一下， 如果连需求都不能很好地被确认，则开发实现阶段更是没有把握控制了。
是否每个需求都在项目的范围内？ 划分项目范围和区分系统边界同样是需求说明书的一个任务，不要对需求书作出超范围的论述和延伸，要知道需求书不是分析师卖弄概念、展示时尚的场所，它是软件工程的一个重要环节。
是否每个需求都没有内容和语法上的错误？按照传统的需求列表方式，需求像菜单一样被一条条列出来，构成需求项的主要栏位包括：需求ID、 需求描述、优先级、来源和状态等。
通常需求首先要经过“拼写检查”，保证没有拼写上的问题，然后通过逐行浏览修改那些在内容或行文上出现问题的需求。
在现有的资源内， 是否能实现所有的需求？ 需求规格说明要考虑可行性的问题。
事实上，分析师的关注层面是价值驱动和成本驱动方面。
分析师应该明白不是所有的需求都要去实现，一些看上去很明显与涉及用户有冲突的、费力不讨好的需求应该果断地舍弃。
国内有专家提出，搞需求也要讲“和谐”即是此中道理。
每一条特定的错误信息，是否都是唯一的和具有含义的？ 不要忽视错误信息的定义， 它必须具有唯一性。
如果过于笼统地定义错误信息则和没有定义的效果是一样的。
二、 注意对需求规格说明的实践性进行评审 所谓实践性是指需求本身是否来源于目前企业的相关业务规则和文件制度，而非源于分析师们经验主义的臆测。
实践性是判断需求规格说明是不是理论联系实践、密切和用户联系的一个关键性指标。
如果需求规格说明和用户实践脱离，即使看上去写得再天花乱坠，也会使需求说明如同无根之树、无源之水，会大大减低用户对需求报告本身的信任度。
有经验的系统分析师通常会迷信自己的经验，把从前的经验嫁接到目前的企业需求分析中。
也许由于行业性质相同，但如果不经过当前的实践调研则给出需求，仍然会无法体现出企业自身的特征。
因而不能为企业带来真正的价值，也会造成与用户需求的鸿沟。
笔者也曾经“轻实践重抽象”，我认为系统分析师的工作特点是站在具体案例上的深度抽象，前提是必须获得本企业的一手具体业务背景、流程和规则。
我们在分析比如“任务跟踪”之类的系统时，由于系统的抽象模型是已知的（通过大量同类软件的分析得知），但还是需要分析师把抽象模型演绎到企业当前业务现状。
这样的需求分析才会有“实话实说”之效，才能引发评审者的共鸣。
否则，在需求评审中评审者是很难读懂你的意图，自然不会立即通过你的需求报告，导致需要重新返工撰写需求报告。
三、 注意对需求规格说明的完整性进行评审 我们经常由下面的问题清单来评审需求说明书是否“完整”。
1 编写的所有需求，其详细程度是否一致和合适？ 2 需求是否能为设计提供足够的基础？ 3 所有对其他需求的内部引用是否正确？ 4 是否包含了每个需求的实现优先级？ 5 是否定义了功能说明的内在算法？ 6 是否包含了所有已知的客户需求或系统需求？ 7 是否遗漏了必要的信息？如果有遗漏的话，把他们标记为待确定的问题（TBD）? 8 是否对所有预期的错误条件所产生的系统行为都编制了文档？ 需求说明的完整性主要体现在需求说明的详细程度上，我们怎样判断该需求的描述是否详细呢？我认为需求需要精化，而不是仅仅提出精化功能、对象要考虑涉众参与者、做些什么、需要什么数据信息、受什么业务规则和条件限制、系统会有什么响应，等等。
-