软件开发需求建议书

2024-09-04

软件开发需求建议书（通用8篇）

1.软件开发需求建议书篇一

1. 项目名称:中国*********分公司******办公综合楼

2.项目背景

2.1***市地域优势及经济发展

***市位于******市东部，全境面积******平方公里，共辖******个乡、镇及街道办事处，******个行政村，全市总人口******万人。

近年来，***市经济建设发展迅速，国内生产总值完成******亿元，境内财政收入******亿元，地方财政收入7.06亿元，名列全国县域经济基本竞争力百强县(市)第******位。

目前，***市“建设******大框架下富而美的新***”规划出台实施，各项改造整治工作顺利进行，南部经济开发区(工业园区)发展迅速，招商引资项目不断增加，政务区南迁工程正在顺利进行，20，***市委、市政府规划设计的现代化大学城已正式开工建设，预计在一年内部分大中专院校将陆续招生。仅大学城建成使用后，在校学生数量就可达10万余人。

届时，以***市政务区、经济开发区、大学城为主体的新城区，将成为***市政治、经济、文化中心，也必将成为包括******通讯行业在内的众多商家企业的必争之地。因此，尽早地选取最理想的位置，加快前期基础性建设，将为今后的市场开拓、扩大企业规模，奠定坚实的基矗

2.2***分公司经营状况分析

中国******有限公司******分公司于******年6月设立***经营部，******年2月，成立***分公司。公司现有员工******人，城区自建******厅2个，乡镇******厅21个，联合******厅3个，代理商140多家，客户经理队伍达300余人。

20**年，***分公司完成业务收入4948.3万元，占当地******市场份额的39%，占******市分公司业务收入的?%。

目前，公司拥有各类******用户达7万余人，占当地******用户份额的43%。

2.软件开发需求建议书篇二

关键词：需求工程,需求开发,需求分析,需求管理

1 概述

需求工程在软件开发中是一个首当其冲的问题。如果没有一个清晰、完善的需求分析, 项目队伍或开发人员将为此付出不可估量的代价。有资料表明, 许多问题都是由于收集、编写、协商、修改软件需求过程中的失误而产生的, 诸如信息收集不全、交流不充分、文档不完善、需求不断变更等, 且有40%～60%的问题都是在需求阶段埋下的隐患。在软件规模不断扩大、应用领域不断拓展的今天, 软件开发的前期工作变得越来越重要。当然, 软件需求分析作为软件开发的第一步, 也是决定性的一步, 也就理所当然的左右了一个软件项目的成功与否。

2 需求工程一般模型

在讨论需求工程的一般模型时, 先来看下什么是需求工程。一般来讲, 需求工程就是指应用已证实有效的技术、方法进行需求分析, 确定客户需求, 帮助分析人员理解问题并定义目标系统的所有外部特征的一门学科;它通过合适的工具和记号系统的描述待开发系统及其行为特征和相关约束, 形成需求文档, 并对用户不断变化的需求演进给予支持。需求工程可分为系统需求工程和软件需求工程。本文所要讨论的软件需求工程是一门分析并记录软件需求的学科, 整个软件需求工程研究领域可划分为需求开发和需求管理两部分, 如图1。

2.1 需求开发

需求开发一般包括需求获取、分析、编写文档、验证等阶段。

2.1.1 需求获取

需求获取是软件开发的第一步, 是通过调研, 获得清晰、准确的客户需求。获取需求的一个必不可少的结果是对项目中描述的客户需求的普遍理解。一旦理解了需求, 分析者、开发者和客户就能探索出描述这些需求的多种解决方案。

需求获取可能是软件开发中最困难、最关键、最易出错及最需要交流的方面。需求获取只有通过有效的客户—开发者的合作才能成功。分析者必须建立一个对问题进行彻底探讨的环境, 而这些问题与产品有关。对需求问题要进行全面考察, 不仅要考虑问题的功能需求方面, 也要考虑其非功能需求方面。所以, 需求获取是一个高度合作的活动, 并不是客户需求的简单拷贝。同时, 当进行需求获取时, 也应尽量避免受不成熟细节的影响。只有当这些细节被排除时, 才会使随后的设计过程畅通无阻。

2.1.2 需求分析

(1) 需求分析任务。

由于需求分析是软件开发的一个奠基性工作, 所以我们必须对它进行认真审视。需求分析阶段要完成具体明确的任务及就是最终形成一份开发方和用户认可或达成共识的需求规格说明书, 这也是软件开发中最为困难的部分—-即准确说明开发什么、系统必须做什么。当然, 最为困难的概念性工作便是编写出详细的技术需求, 这包括所有面向用户、面向机器和其它软件系统的接口。如果一旦做错, 将最终会给系统带来极大损害, 且以后再对它进行修改也非常困难。可以说需求文档在开发过程中起着指导作用。

(2) 需求分析过程。

需求分析的过程就是将收集到的调研信息加以处理并理解他们。

把调研信息分成不同的类型, 同时将客户需求同可能的软件需求相联系。然后将客户信息结构化, 编写成文档和示意图, 作为提交给让客户代表评审并纠正存在错误的一个书面文档。重复详述需求, 以确定用户目标和任务, 并把它作为使用实例。进行深入收集和分析, 消除任何冲突或不一致性, 拟定出详细的使用实例, 使其融合到必要的功能需求, 为编制测试用例作准备。

进行需求分析时, 尽量理解用户用于表述他们需求的思维过程, 充分研究用户执行任务时做出决策的过程, 并提取出潜在的逻辑关系。流程图和决策树是描述这些逻辑决策途径的好方法。避免使用用户提供的需求细节, 因为会给随后的设计过程带来不不要的限制, 用周期性地检查需求获取, 以确保用户参与者将注意力集中在今天所讨论的话题适合的抽象层上。此外, 不可忽视非工程需求的描述, 它表明了系统的限制和用户对质量的期望。

为了更好和用户交流, 最初的屏幕构思有助于描述开发人员对需求的理解, 可以利用Visio来设计界面。如果项目开发周期允许, 可以开发原型来交流和确认。随后针对用户的需求说明细化用户界面设计, 有助于对需求达成共识, 为以后的设计工作带来便利。

(3) 需求分析方法。

通常的软件需求分析方法有三种:面向功能分析、面向对象分析、面向数据分析。

面向功能分析是最早的分析方法, 它将软件需求当做一颗倒栽的功能树, 从上到下, 功能由粗到细。其功能分析体现了自顶向下、逐步求精的思想, 适合于结构化分析、结构化设计、结构化编程等传统式软件工程思想。

面向对象分析, 也从系统的基本功能入手, 每一个功能对应一个对象, 然后将对象上升为类, 再用对象总线或对象框架将类组装起来, 用以表示用户需求。CASE工具Rational Rose用Use case来进行需求分析, 所有Use case的集合, 就是系统的需求。

面向数据分析, 就是面向元数据和中间数据分析, 对开发人员来讲, 就是要将这两类数据及其之间的关系弄透。

2.1.3 编写文档

需求开发的最终成果是:客户和开发小组对将要开发的产品达成一致协议。协议综合了业务需求、用户需求和软件功能需求。开发人员必须编写从使用实例派生出的功能需求文档, 还要编写产品的非功能需求文档, 包括质量属性和外部接口需求。

一般可以用好的结构化和自然语言、建立图形化模型、编写形式化规格说明等方法编写文档。文档不仅是系统测试和用户文档的基础, 也是所有子系列项目规划、设计和编码的基础。它应该尽可能完整地描述系统预期的外部行为和用户可视化行为。而且作为产品需求的最终成果必须具有综合性:必须包括所有需求。开发者和客户不能作任何假设。

2.1.4 需求验证

再完成文档的编写后, 并不能说已经完成了需求开发阶段的工作。只有以结构化和可读性方式编写这些文档, 并由项目的风险承担者评审通过后, 各方面人员才能确信他们所赞同的需求是可靠的。其验证的手段主要有软件评审和软件测试, 在文档编写后, 必须对需求进行评审以验其质量。软件测试也是对需求的第二次验证。

需求验证主要围绕编写文档的质量特性展开, 这些质量特性包括正确性、无二义性、完整性、可验证性、一致性、可修改性和可跟踪性等。

2.1.5 需求分析原则

有资料表明:频繁的需求变更、遗漏的需求、与用户交流不够、质量低下的需求文档和不完善的需求分析是导致需求过程中软件成本估计极不准确的主要因素。所以, 开发人员一般应当遵循以下一些原则。

(1) 有足够用户参与。

在实施项目时, 若无足够的用户参与, 系统人员获得的需求是片面的, 不完整的, 这样系统在需求之初就埋下风险。

(2) 控制需求变更范围。

在开发中若不断地补充需求, 项目就越变越庞大以致超过其计划及预算范围。所以, 必须一开始就对项目视图、范围、目标、约束限制和成功标准给予明确说明, 并将此说明作为评价需求变更和新特性的参照框架, 以达到把需求变更范围控制到最小, 有利于减少因变更导致软件质量的下降。

(3) 确认需求。

模棱两可是需求规格说明中最为可怕的问题。模棱两可的需求会使不同的风险承担者产生不同的期望, 它会使开发人员为错误问题而浪费时间, 并且使测试者与开发者所期望的不一致。如果这种不一致性直到项目后期才被发现, 那时付出的代价将会很惨重。所以, 需求的确认非常重要。

(4) 不要画蛇添足。

指开发人员增加自己觉得一些用户欣赏但需求规格说明中并未涉及的新功能, 但往往这并不能获得用户的认可。开发人员应努力使功能简单易用, 而不要未经客户同意, 擅自脱离客户要求, 自作主张。

当然除了以上提到的, 还包括不要过于精简规格说明、不要忽略用户分类、要准确的调研、分析、计划等。

2.2 需求管理

软件需求的最大问题就是需求不断的变更, 同时也是软件开发之所以困难的主要根源, 因此有效的管理需求是项目成功的基础。而且, 管理问题是贯穿于整个软件开发周期中的。

需求管理是在工作进程中维持需求约定集成性和精确性的所有活动。一方面, 需求管理要保持软件需求与客户需求之间的一致性, 要保持软件开发过程中的其它系统元素以及活动与软件需求的一致性。另一方面, 软件需求是受控的, 也就是说在给定时间使用工作产品的版本是已知的 (版本控制) , 并且以受控的方式引进改革 (变更控制) 。需求管理的任务是分析变更影响并控制变更过程, 主要包括变更控制、版本控制和需求跟踪等活动。

2.2.1 需求变更控制

对大多数项目来说, 需求的改进是合理的且是不可避免的。新的开发技术和项目目标的调整等都可能产生需求的变更, 但是如果不对需求变更的范围加以控制, 将会使项目陷入混乱, 甚至导致软件开发的失败。Capers Jones曾在报告中声称需求变更对80%的管理信息系统和70%的军事软件项目造成风险, 因为迟到的需求变更会对已进行的工作有较大影响。

(1) 需求变更的影响分析。

需求变更贯穿于软件开发的全过程中, 不处理好需求变更, 将会障碍软件的开发。它包括影响软件质量及开发进度、影响文档和代码的一致性、影响开发者和用户的合作关系等。

(2) 处理需求变更的原则。

要正确的处理需求变更, 必须采用规范的变更管理过程。如下面提到的, 必须建立需求变更控制机制;增强系统对需求变更的应变能力;选择合适的客户经理;提高用户的认识水平;采用先进的需求管理工具等。

(3) 需求变更解决方案。

引起需求变化的主要原因有:未受控制的需求变更、遗漏的需求、与用户交流不够、编写文档考虑不周、低效的需求分析等。针对以上问题, 可以采用如图2的方案进行解决。

2.2.2 需求文档版本控制

版本控制是管理需求的一个必要方面, 它保证在需求文档中记录和反映所有的需求变化。需求文档的每一个版本都必须统一确定, 组内每个成员必须能够得到需求的当前版本, 需求变更应该及时通知到项目开发所涉及的人员。每一个公布的需求文档应该包括一个修正版本的历史状况, 即变更内容、变更日期、变更人姓名、变更原因等。

本文建议在经过每一次需求变更及确认后, 项目管理者可以给每一次变更的需求设定一个统一的版本号。每一次变更后, 版本就升级。这样可以方便、快速、有效的进行软件开发, 同时也随时可以查到客户新增的哪些功能。

2.2.3 需求跟踪

需求跟踪就是将需求与系统设计元素、编码、测试等阶段的工作成果与需求文档进行比较, 建立与维护“需求文档—设计文档—代码—测试用列”之间的一致性, 确保产品依据需求文档进行开发, 图3表示软件开发过程中需求的跟踪关系。当需求发生变化时, 使用需求跟踪可以确保不忽略每个受到影响的系统元素, 需求变更的准确实施可以降低由此带给项目的风险。

一个管理系统的需求跟踪通常应该满足:

①能够完整地定义需求之间的各种关系, 并提供可视化表示方式;

②在需求变更时, 系统能够按照所定义的需求跟踪链, 跟踪到所有受影响的需求。同时, 管理人员也需要进行需求状态跟踪, 以了解项目工程进行到了何种程度, 从而对项目进度进行控制。

2.2.4 需求管理工具

当然, 需求管理人员不可能用手工来管理软件开发, 还必须得用到一些管理工具。因为采用需求管理工具, 可以提高需求管理工作流程的自动化程度, 使需求管理可以在项目实施过程中得到有效的排行。

目前, 需求管理工具还是比较多的。例如, CA公司的CA-Super Project & Project Software、Development公司的Qwiknet Professional、Rational公司的Analyst Studio需求工作包等。需求跟踪工具有, LMSC公司的ARTS (The automated Requirement Traceability System) 、TOOR (Traceability of Object-Oriented Requirement) 、Remap系统、RETH和Radix工具等。

3 总结

软件开发人员应充分认识到需求工程在软件开发过程中的作用。如果没有一个准确、清晰的软件需求工程工作, 将给项目队伍或软件公司带来不可估量的损失。本文从需求工程的过程各阶段的作用来叙述, 讨论了以后研究的重点还应放在需求分析、需求管理问题的研究上。当然, 必须理论联系实际, 需求工程现状中另一明显的不足是理论解决方案通常是在对实际问题简化的基础上得到的, 理论研究和实践脱节。要获取需求突破, 改善需求工程的开发效率和质量, 主要的一点就是探索有效的解决途径, 缩小理论与应用之间的鸿沟, 使开发出的系统与应用领域相匹配。

参考文献

[1]曹伟.如何进行软件需求分析, 中国系统分析员, 2002 (3)

[2]Wiegers K E.陆丽娜, 王忠民, 王志敏等译, 北京:机械工业出版社, 2000

[3]黄怡强.浅谈软件开发需求阶段的主要任务, 中山大学学报论从, 2002, 22 (1)

[4]姬晓鹏等, 需求管理的一个系统解决方案[A].计算机工程, 2003.

[5]卢梅, 李明树等.软将需求工程—方法及工具评述[A].计算机研究与发展, 1999, 36 (11)

[6]刘小波等.软件系统需求变更影响分析及解决方案[A].华南理工大学学报 (自然科学版) , 2002, 30 (4)

3.软件开发需求建议书篇三

保证需求与软件的统一

Richard Bender是基于需求的软件测试方法创始人。他认为：改进软件系统测试方法的最佳途径在于改进软件需求定义开发过程和功能测试设计过程，基于需求的测试是一种最根本的软件测试。

软件需求分析解决的主要问题是“软件产品必须或应该做什么”，软件需求分析的最重要成果就是需求说明书，需求说明书是软件产品的雏形，软件产品是需求说明书的最终展现成果。由于需求和软件之间是相互对应的，编码和测试用例之间也是相互对应的，所以需求和测试用例之间是互相对应的，在本质上也是互相关联、密不可分的，可以实现需求和测试用例之间的双向跟踪追溯。

值得一提的是，在软件开发过程中，编程和测试是紧密相关、相辅相成的活动，两者同等重要、缺一不可。测试的目的是为了发现尽可能多的缺陷，并期望通过修改完善缺陷以提高软件的质量。成功的测试在于发现了迄今尚未发现的缺陷，测试人员的职责是设计这样的测试用例，它能有效地揭示潜伏在软件里的缺陷。

然而，在企业应用软件项目的实施过程中，普遍存在重编码轻测试、缺乏高素质软件测试人员的现象。事实上，设计与测试应该完全分离，好的开发者构建事务，好的测试者破坏事务，一个好的软件测试工程师应该要比开发工程师对整个系统的理解更加透彻。目前很多软件测试工程师处在软件项目组的最低职级，缺乏高层的重视和支持，自身对于整个应用系统“该做什么、要做什么、必须做什么”并不清楚，如果再加上与设计人员的沟通交流协作过程中不讲究原则性、策略性，其工作成效可想而知。

基于需求的软件测试方法

要实施基于需求的软件测试，其正确的工作步骤如下：

1．全面清晰地掌握用户需求

全面、清晰、准确地认识理解用户需求、软件平台架构是软件测试工程师开展一切测试工作的前提和基础。软件测试工程师应认真阅读、研究、分析《用户需求说明书》、《软件产品设计说明书》（分为概要设计和详细设计）等关键文档，清晰掌握平台架构设计、数据库结构设计、模块功能设计、核心算法、界面展现、人员权限角色分配、输入输出数据等要素，将业务操作流程和以上要素分别逐一对应关联。

2．明确测试的目标和任务

软件测试的任务就是验证软件是否准确地实现了用户需求，检验需求和软件之间是否一致。好的测试用例能发现软件中潜在的新缺陷，糟糕的测试用例在目标及任务尚不明确的情况下盲目进行评测，不仅效率低下，而且毫无效果。

3．分阶段制订测试计划方案

测试计划方案不是从头到尾一成不变的，应根据企业应用软件项目所处的不同阶段制订，不同的项目阶段所需的测试方法是不一致的。可以借鉴RBT理论关于基于需求的测试方法的最佳实践（参见链接）。

4．设计基于需求的复合测试用例

在很多情况下，单一的测试方法很难实现软件缺陷或错误的全面检查，在软件工程中使用最多的往往是组合多种测试方法的复合测试用例。例如黑盒测试和白盒测试两者的功能作用就可以互相弥补，实践中可以将两种测试方法组合起来设计复合测试用例。

5．妥善处理测试和设计之间的关系

测试是“破坏性”的，而开发却是“建设性”的。从行为学角度看，开发与测试是对立的。如果测试人员对开发人员的错误批评指责过多，容易导致双方的关系对立隔阂；如果测试人员对开发人员的错误疏忽怠慢，容易导致软件质量的隐形下降，实践中需要找到一个平衡点。

6．建立测试报告审批通报制度

建立测试报告审批通报制度对于提升软件质量具有明显作用。作为一名优秀的测试工程师，要养成书面起草测试工作报告的好习惯。将已经定位发现的缺陷或错误进行分析汇总，用统计数字、图表等方式说明缺陷或错误的根源，及时将测试工作报告提交上级主管领导审议，并通知研发设计人员，使设计人员做到对缺陷心中有数、控制有道，以防患于未然。

链接

基于需求的测试理论的五项最佳实践

1．转变“编码后进行测试”的传统观念。在软件编码开始之前的设计阶段就根据需求文档和设计文档开发出90%以上的测试用例，尽早发现和排除绝大部分的缺陷。

2．根据各项应用功能的优先级、重要性制订不同等级的测试方案、测试用例。重要的模块投入较多的测试资源（人力、时间、物资），次要的模块投入较少的测试资源。

3．尽早测试，频繁测试。测试进行得越早，缺陷发现越早，修复缺陷的代价越小；测试进行得越晚，缺陷发现越迟，修复缺陷的代价越大。

4．摒弃“经验至上”的想法。设计系统、严谨、合理的测试用例才能使测试达到实效。

4.汽车需求建议书篇四

序：

某出租公司因业务需要，将要向某企业购买一批汽车。希望进购一批为可乘坐四人，悬挂坚硬，不容易坏，刹车盘耐用，维修便宜的车子作为出租车。

1．工作表述

企业将执行下面任务：有关汽车的销售

某出租车公司（甲方）因业务需要，将要向某企业（乙方）购买一批汽车。对汽车的需求为可乘坐四人，悬挂坚硬，不容易坏，刹车盘耐用，维修便宜。

2．交付物

符合甲方要求的汽车。

3．甲方提供的条款

甲方将帮助乙方企业筛选汽车的类型。

4．合同类型

合同必须以一个商定的价格，给提供满足需求建议书要求工作的开发商付款。

5．到期日

乙方必须在2013年5月1日以前将车交于甲方。

6．时间表

甲方希望在2013年4月1日前选中一家企业。这个项目需要完成的时限是1个月，从2013年4月2日开始实施项目，要求汽车正式验收前试运行半天以上的时间，并根据试运行情况进行适当修改。

7．付款方式

当甲方已经满意于项目100％的完成，并且乙方已经履行了全部契约义务时再付出总额。8．需求建议书内容

(1)方法。乙方能清晰地理解需求建议书，理解什么是被期望达到的要求。而且要详细描述乙方领导项目的方法，要求对每个任务的详细描述，任务如何完成的详细描述。

(2)交付物。乙方要提供交付物的详细描述。

(3)进度计划。列出每周要执行的详细任务的时间表，以便在要求的项目完成日期内能够完成项目。

(4)经验。叙述一下乙方最近已经执行的项目。

5.RFP需求建议书篇五

（request for proposal, rfp）

足其已识别需求所应做的准备工作。也就是说，需求建议书是客户向服务商发出的用来说明如何满足其已识别需求的建议书，是客户与服务商建立正式联系的第一份书面文件，又称招标书。需求建议书一般由客户起草，主要描述客户的需求、条件及对项目任务的具体要求。一份完整的需求建议书主要包括满足其需求的项目的工作自述、对项目的要求、期望的项目目标、客户供应条款、付款方式、契约形式、项目时间、项目申请书的要求等。

好的需求建议书能让服务商准确把握客户所期待的产品或服务。当然，并非在所有情况下都需要准备一份正式的需求建议书，当某一企业的需求由内部开发项目予以满足时，这一过程似乎变得简单多了，此时更多需要的是口头上的交流和信息传递，而不是把宝贵的时间耽搁在仅仅起到信息传递作用的需求建议书上。例如，某一软件开发公司感到公司原来的财务分析系统已经远远不能适应日益增加的业务需要时，便可直接要求软件开发小组进行开发，这时只需口头把相

书写rfp要认真负责、严肃对待，内容要具体，语言要精练。1．在第一行正中写建议书三个字。2．写接受建议对方的名称。3．正文：

（1）建议的原因或出发点，便于对方考虑。

（2）建议的具体事项。4．表达建议者的愿望。

5．结尾写表示敬意的话，如此致敬礼等语。6．写上建议者的名称和写建议书的日期。

1、标题

2、称谓

3、正文（开头部分，主体部分，结尾部分）

4、署名及时间

需求建议书的书写指导方针

需求建议书必须说明项目目标（project objective）或目的，包括任何可能对承约商有用的合理信息或背景信息，以便承约商可以准备相应的建议书。对外起草一份正式的需求建议书，有如下的指导方针：

（1）需求建议书必须提供工作陈述（statement of work, sow）

（2）需求建议书中必须包含客户要求（customer requirements）定义好规格和属性。

（3）需求建议书中应当说明客户期望承约商或者项目团队提供什么样的交付物。

（4）需求建议书中应当列明任何应由客户提供的物品。

（5）需求建议书中可能要说明需要客户审批的内容。

（6）某些需求建议书中会提到顾客想用的合同类型。

（7）需求建议书可能会表明顾客想用的付款方式。

（8）需求建议书应当表明项目完成所要求的进度计划。

（9）需求建议书应当指导并说明承约商申请书的格式和内容。

（10）需求建议书应当指出客户希望潜在承约商提交申请书的最后期限。

（11）需求建议书可能会包含评价标准。

需求建议书一般包含以下主要内容：

客户必须搜集大量相关资料准备需求建议书，因为it项目实施者需要按照rfp来准备他们的项目技术方案，并以此参与竞标。rfp中包括项目的目标，也就是用户的期望，也包括客户要求项目的进度计划；对实施商申请书的表格和内容的规定；客户希望潜在的实施商提交投标申请书的最后期限；评价申请书的标准等。一份好的rfp应该包括以下一些内容。1．工作表述

工作表述就是说明项目的工作范围，概括客户要求开发商或项目团队执行的任务或工作单元，说明项目所涉及的各种事情，哪些必须由开发商或项目团队去完成，哪些由客户自己去做。例如，一个办公自动化软件系统的具体目标。又如建设一个网站，所需设备的采购任务，是由客户自己完成，还是由开发商去完成；企业网站上的页面文字，是客户自己撰写，还是由开发商撰写等。

2．任务要求

需求建议书必须要具体规定开发商需要完成任务的规格和特征，如要求涉及大小、数量、颜色、重量、速度和其他开发商提出的解决方案中，所必须满足的物理参数和操作参数。例如，建立一个企业网站，可能要求在1 000人同时访问的情况下不会产生堵塞的感觉，网站的浏览页面不低于多少；建立一个自动结账和收款系统，可能要求每天能办理12 000次交易的功能和其他特定的功能，如在开出了发票的30天内没有收到账款，就会自动产生催款通知。具体的任务要求，可能会成为将来的验收标准。3．交付物

交付物就是开发商所提供的实体内容，这在需求建议书中应该说明。例如，对于自动结账和收款系统来说，客户可能要求开发商提供硬件(计算机)、软件(磁盘和一些印刷品)、操作手册和培训课程。交付物也可能包括客户要求开发商提供定期进度报告或终期报告。4．客户供应条款

需求建议书还应该列出客户的供应条款。例如，客户需要建立一个网j站，可能需要向开发商提供企业内部的组织结构及各部门之间业务关系的详细说明，包括信息流程的类型、信息流量和发生频率等。

5．表述客户对需求的确认

需求建议书不是对客户需求的最后确认。最后的确认应该在对开发商提出的方案进行评估之后。例如印刷宣传手册，可能在开印之前要经过客户审定；局域网的建设，在购买材料和设备之前，客户必须审定开发商的技术方案。这一点在需求建议书中必须向开发商说明。6．期望的合同类型(1)合同可以按固定价格订立。这样，开发商实际上就是费用包干。客户只给固定的价钱，不管开发商实际工作花费多少。开发商必须保证功能的实现和质量要求，超支的风险由开发商负担。

(2)合同也可以规定开发商不承担风险，即在时间、原材料限制的条件下，不论实际成本多少，都会给开发商特定的报酬，也就是所谓包工不包料。在我国现阶段的条件下，由于质量检验和资信度水平不高，这种合同比较普遍。在需求建议书中，最好说明客户是希望采用那种类型的合同。

7．期望的付款方式

付款方式可以分为一次性付款和分阶段付款；在开始前付款和结束后付款。一般依项目的性质来定付款方式。如网页制作，往往在项目末期付款；而架设局域网，一般在方案确认后，付款30％以便开发商采购，工程结束验收后付满90％，留10％等到使用一段时间以后确认无问题时付清。具体付款方式需要合同双方协商，但在需求建议书中，客户应该先提出自己的期望付款方式。8．要求的进度计划

进度计划的要求可能很粗，如要求在6个月内完成；也可以详细一些，如多长时间内完成方案设计和审定，多长时间内完成硬件选购与安装，多长时间内完成软件研制、测试与安装，最后开发商在系统安装调试后，在多长时间内提交所有的系统文件和操作培训。9．申请书的格式和内容提示

为了便于在几个开发商之间进行比较和评价，申请书应该在形式上采取同一个格式，内容的结构也应该一致。这样对不同的申请者来说比较公平，也能减轻客户在评审时的工作量。客户在需求建议书中可以限定申请书的每一部分采用的文字数量或页数。10．提交申请书的最后期限

申请书受理的截止日期是必须要交代清楚的。例如，要求开发商在接到需求建议书后多少个工作口之内(如l周之内、1个月之内等)提交申请书，或大家一律在某月某日之前提交申请书。这样做的目的是便于同时对众多的申请者进行比较、评估，也是为了保持公正，不给某些开发商以额外的时间和机会。11．对申请书的评价标准

要告诉开发商客户将根据哪些准则来评价他提交的申请书。这样做的目的，是指导开发商写好申请书。一般评价标准包括4个方面的内容：(1)开发商在类似项目中的经验。如他们近期是否在预算内按期完成了类似的项目，客户对他们是否满意?(2)开发商提出的技术方案是否合适。如采用哪种类型的计算机软件?数据库的设计、方法是什么?用来建立管理信息系统的是哪种语言?采用哪些供应商的设备?等等。(3)进度计划。开发商是否能按照所要求的进度完成项目计划?(4)成本。如开发商的报价是否合理?成本预算中有无漏算的条款?将来在执行时有没有可能出现超支，或有无可能因过于节约而导致质量不能保证?有的申请人为了争取合同，在报价上压低成本，到了执行阶段，或偷工减料，或增加成本，结果导致所建系统的缺陷很多，或使最终成本大大超出原始的估算。对此需要引起注意。12．资金总量

开发商总是希望了解客户有多少资金可以用于发展拟议中的真t项目，但客户在需求建议书中，往往不愿意透露这个信息。其实，客户暗示大约的数字，告诉开发商他打算花多少钱来办这件事是有好处的，这样可以使开发商能够提交与资金水平相适应的申请书，提高在项目准备阶段的工作效率。

需求建议书的必要性

需求建议书(rfp)是项目客户与开发商建立正式联系的第一份书面文件，也叫招标书。一般由项目的客户自己起草，主要描述客户的需求、条件以及对项目任务的具体要求，向可能的开发商发送。

需求建议书是客户为确保供应商理解项目的需求，并在此基础上提供项目建议书而编制的需求规范。虽然它不能确保客户据此就能获得理想的解决方案，但却可以帮助客户发现那些尽可能接近自身需求的系统准备。其目的是从客户自身的角度出发，通过全面、详细地陈述，使开发商或项目团队理解客户所希望的是什么，以可行的价格满足客户的已识别的需求。

对于一些预算较少的客户，开发商往往不愿意花精力准备正式的方案建议书，这种情况下，客户的需求建议书就变得很重要。事实上，项目无论大小，都需要编写需求建议书。

第一，需求建议书需要描述用户的目标与需求。编制需求建议书的过程也是客户进一步明确自己的目标与需求的过程，并以此建立起客户与供应商进行深人沟通的桥梁。即使因为各种原因使得供应商看不到或不愿响应需求建议书，这种努力也是值得付出的。

第二，需求建议书可节省选型的时间，并使得对各供应商之间的比较变得更容易。客户提供给所有竞标供应商的信息都是一样的，避免了跟各开发商的重复沟通，同时，有需求建议书作为基准，客户可以约束各开发商以一致的格式提交方案建议书，以提高各供应商之间的可比性。

第三，需求建议书可以避免一些潜在的疏漏。在准备需求建议书时，客户往往会因为太过关注具体细节而忽略了一些重要的因素。收到需求建议书后，有的供应商可能会主动对这样的疏漏提出质疑以提醒客户。还有些开发商为了使自己的方案建议书更具有吸引力，甚至会提出一些需求建议书没有涉及的好想法来拓展客户的思路。编写需求建议书的一般原则需求建议书应该由用户编写，但各种客观因素的限制，实际上很难做[到。所以，很多时候都是由用户与项目小组共同编写。编写项目需求说明的j过程也是项目小组带领客户进入项目需求启发的过程。编写优秀的项目需求[建议书没有公式化的方法，需要大量的实践经验。以下是编写需求建议书需要把握的几个原则：(1)需求应该是正确的。每个需求必须精确描述要交付的功能。确定需求内容是否正确，需要用户的代表来参与确认，由他们检查、决定用户需[求的正确性。没有用户的需求检查就会导致很多项目实施中的问题出现。例如用户会说：“这不是我们要的东西”；“你没明白我们的意思”，等等。(2)需求应该是可行的。项目的需求应该在有限的资源(已知的能力、有限的系统及其环境)下是可实现的。为了避免需求的不可行性，在需求分析阶段应该有核心技术人员参与，检查在技术上什么能做、什么不能做，哪些需要额外的付出等。(3)需求内容应该是必要的。需求建议书中的每个需求都应该有相应[的出处，即说明什么是客户确实需要的，什么要顺应于外部的需求、接口或标准。如果不能标识出处，则可能这个需求不是真正需要的。(4)需求内容应该有优先权。优先权是由客户或其代理及项目小组共同商讨后建立的。如果所有的需求都被视为同等重要，那么在开发中遇到预t算削减、计划超时或组员的离开而导致新的需求时，项目经理将无所适从。一般优先权有以下三个级别。1)高优先权，表明需求必须体现在本阶段项目的成果中或这个产品的版本中。篇二：1-项目需求建议书(rfp)项目需求建议书（rfp）a.项目信息

提供关于项目名称、客户名称、项目经理以及项目发起人姓名等方面的一般信息

项目名称：

项目经理：

项目发起人：

客户名称：文件起草人：日期： b.项目目标描述完成项目的时间、质量要求等方面的信息 c.工作描述（sow）描述执行项目的具体工作 d.可交付结果

描述执行项目的阶段，完成项目任务的主要交付结果等方面的信息 e.合同类型描述使用哪种性质的合同 f.付款方式描述付款的时间、金额、币种、方式等 g.建议书的内容

描述建议书应包括的具体内容 h.建议书的评价标准

描述评价建议书的主要标准，包括价格、技术方案、项目管理方法、经验与资质等方面 i.提交建议书的时间、地点要求描述建议书的截止日期、提交的地点等信息篇三：项目需求建议书

项目需求建议书（rfp）a.项目信息

提供关于项目名称、客户名称、项目经理以及项目发起人姓名等方面的一般信息

项目名称：

项目经理：

项目发起人：

客户名称：文件起草人：日期： b.项目目标

描述完成项目的时间、质量要求等方面的信息 c.工作描述（sow）

描述执行项目的具体工作 d.可交付结果

描述执行项目的阶段，完成项目任务的主要交付结果等方面的信息 e.合同类型

描述使用哪种性质的合同 f.付款方式

描述付款的时间、金额、币种、方式等 g.建议书的内容

描述建议书应包括的具体内容 h.建议书的评价标准

描述评价建议书的主要标准，包括价格、技术方案、项目管理方法、经验与资质等方面 i.提交建议书的时间、地点要求

描述建议书的截止日期、提交的地点等信息 iso9000质量管理体系项目需求建议书（rfp）a.项目信息

提供关于项目名称、客户名称、项目经理以及项目发起人姓名等方面的一般信息

项目名称：

项目经理：

项目发起人：

建立iso9000质量管理体系李伟张卫东客户名称：智能科技公司文件起草人：王芳日期： 2005年8月20日 b.项目目标

描述完成项目的时间、质量要求等方面的信息 c.工作描述（sow）d.可交付结果 e.合同类型 f.付款方式 g.建议书的内容 h.建议书的评价标准 i.提交建议书的时间、地点要求篇四：需求建议书

需求建议书（request for proposal，rfp）

什么是需求建议书[1] 需求建议书是指从客户角度出发，全面、详细地向服务商陈述、表达为了满足其已识别需求所应做的准备工作。也就是说，需求建议书是客户向服务商发出的用来说明如何满足其已识别需求的建议书，是客户与服务商建立正式联系的第一份书面文件，又称招标书。需求建议书一般由客户起草，主要描述客户的需求、条件及对项目任务的具体要求。一份完整的需求建议书主要包括满足其需求的项目的工作自述、对项目的要求、期望的项目目标、客户供应条款、付款方式、契约形式、项目时间、项目申请书的要求等。

需求建议书必须要具体规定开发商需要完成任务的规格和特征，如要求涉及大小、数量、颜色、重量、速度和其他开发商提出的解决方案中，所必须满足的物理参数和操作参数。例如，建立一个企业网站，可能要求在1 000人同时访问的情况下不会产生堵塞的感觉，网

站的浏览页面不低于多少；建立一个自动结账和收款系统，可能要求每天能办理12 000次交易的功能和其他特定的功能，如在开出了发票的30天内没有收到账款，就会自动产生催款通知。具体的任务要求，可能会成为将来的验收标准。3．交付物

需求建议书还应该列出客户的供应条款。例如，客户需要建立一个网j站，可能需要向开发商提供企业内部的组织结构及各部门之间业务关系的详]细说明，包括信息流程的类型、信息流量和发生频率等。

5．表述客户对需求的确认

(2)合同也可以规定开发商不承担风险，即在时间、原材料限制的条件下，不论实际成本多少，都会给开发商特定的报酬，也就是所谓包工不包料。在我国现阶段的条件下，由于质量检验和资信度水平不高，这种合同比]较普遍。在需求建议书中，最好说明客户是希望采用那种类型的合同。

7．期望的付款方式

8．要求的进度计划

开发商总是希望了解客户有多少资金可以用于发展拟议中的真t项目，但客户在需求建议书中，往往不愿意透露这个信息。其实，客户暗示大约的数字，告诉开发商他打算花多少钱来办这件事是有好处的，这样可以使开发商能够提交与资金水平相适应的申请书，提高在项目准备阶段的工作效率。[编辑] 需求建议书的必要性[2] 需求建议书(rfp)是项目客户与开发商建立正式联系的第一份书面文件，也叫招标书。一般由项目的客户自己起草，主要描述客户的需求、条件以及对项目任务的具体要求，向可能的开发商发送。

需求建议书是客户为确保供应商理解项目的需求，并在此基础上提供项目建议书而编制的需求规范。虽然它不能确保客户据此就能获得理想的解决方案，但却可以帮助客户发现那些尽可能接近自身需求的系统准备。其

目的是从客户自身的角度出发，通过全面、详细地陈述，使开发商或项目团队理解客户所希望的是什么，以可行的价格满足客户的已识别的需求。

对于一些预算较少的客户，开发商往往不愿意花精力准备正式的方案建议书，这种情况下，客户的需求建议书就变得很重要。事实上，项目无论大小，都需要编写需求建议书。第一，需求建议书需要描述用户的目标与需求。编制需求建议书的过程也是客户进一步明确自己的目标与需求的过程，并以此建立起客户与供应商进行深人沟通的桥梁。即使因为各种原因使得供应商看不到或不愿响应需求建议书，这种努力也是值得付出的。第二，需求建议书可节省选型的时间，并使得对各供应商之间的比较变得更容易。客户提供给所有竞标供应商的信息都是一样的，避免了跟各开发商的重复沟通，同时，有需求建议书作为基准，客户可以约束各开发商以一致的格式提交方案建议书，以提高各供应商之间的可比性。

第三，需求建议书可以避免一些潜在的疏漏。在准备需求建议书时，客户往往会因为太过关注具体细节而忽略了一些重要的因素。收到需求建议书后，有的供应商可能会主动对这样的疏漏提出质疑以提醒客户。还有些开发商为了使自己的方案建议书更具有吸引力，甚至会提出一些需求建议书没有涉及的好想法来拓展客户的思路。[编辑] 编写需求建议书的一般原则[2] 需求建议书应该由用户编写，但各种客观因素的限制，实际上很难做[到。所以，很多时候都是由用户与项目小组共同编写。编写项目需求说明的j过程也是项目小组带领客户进入项目需求启发的过程。编写优秀的项目需求[建议书没有公式化的方法，需要大量的实践经验。以下是编写需求建议书需要把握的几个原则：(1)需求应该是正确的。每个需求必须精确描述要交付的功能。确定需求内容是否正确，需要用户的代表来参与确认，由他们检查、决定用户需[求的正确性。没有用户的需求检查就会导致很多项目实施中的问题出现。例如用户会说：“这不是我们要的东西”；“你没明白我们的意思”，等等。(2)需求应该是可行的。项目的需求应该在有限的资源(已知的能力、有限的系统及其环境)下是可实现的。为了避免需求的不可行性，在需求分析阶段应该有核心技术人员参与，检查在技术上什么能做、什么不能做，哪些需要额外的付出等。(3)需求内容应该是必要的。需求建议书中的每个需求都应该有相应[的出处，即说明什么是客户确实需要的，什么要顺应于外部的需求、接口或标准。如果不能标识出处，则可能这个需求不是真正需要的。(4)需求内容应该有优先权。优先权是由客户或其代理及项目小组共同商讨后建立的。如果所有的需求都被视为同等重要，那么在开发中遇到预t算削减、计划超时或组员的离开而导致新的需求时，项目经理将无所适从。一般优先权有以下三个级别。1)高优先权，表明需求必须体现在本阶段项目的成果中或这个产品的版本中。2)中优先权，表明需求是必须的，但是如果需要可以推迟到晚一些的产品版本中。3)低优先权，表明有它很好，但我们必须认识到如果没有充足的时间或资源，它可以被放弃掉。(5)需求内容应该是明确的。需求不该有歧义，要避免使用一些对于拟订项目需求建议书的人很清楚，但对于其他人模糊不清的词汇。如：用户友好性，容易，简单，快速，有效，几个，艺术级，改善的，最大，最小等等。每写一个需要都应简洁、直观地采用用户熟知的语言，而不要采用计算机术语。[编辑] 需求建议书例子[2] 例：某企业项目管理软件开发项目需求建议书

有关单位：某企业(甲方)由于业务发展的需要，决定采用项目管理的方式进行管理，为了更有效地对项目的执行过程进行控制，该企业决定开发一套项目管理软件以满足这一需要。1．工作表述

开发商将执行下面任务：开发项目管理软件。

开发项目管理软件的主要功能包括项目及工作信息的录入、项目网络计划图的绘制、项目时间计划的安排、甘特图计划的制定、项目执行信息的录入与分析及各种计划报表的输出等功能。2．要求

6.物流园区需求建议书篇六

本项目依托长虹控股子公司长虹民生物流的仓储配送体系，拟建设开放式现代物流园，提高物流的服务水平和降低物流总体成本，为园区企业和其他潜在的客户提供优质高效的物流配送服务。

二、项目背景和政策支持

根据绵阳市“十一五”规划，结合长虹总部主体、生产区域的分布以及对未来物流的发展需求，决定建设“长虹信息化现代物流园”，重点建设仓储、配载、配送设施，并以此为雏形，逐步投入资金开发同时具备仓储、配载/配送、商务办公、物流采购交易、物流信息集成、教育培训、综合服务等功能的大型物流园。项目可享受国家、省市灾后重建相应政策和我市相关的投资政策。

三、项目定位和选址

(一)项目定位

长虹物流在为长虹集团做好服务的同时，以“立足西南，抓住商机，拓展市场，快速发展”为目标，全力打造物流服务品牌，努力将长虹物流打造成为专业化、集约化、信息化的现代物流服务集成供应商。

(二)项目选址

本项目建设地位于绵阳经济技术开发区，项目建设地地势平坦，毗邻绵阳南郊机场，厂区大门与绵三路相连，道路宽敞，交通方便、运输便捷，能满足本项目的交通及运输需要。

四、项目开发思路及初步规划

(一)项目开发目标及指导思想

在长虹集团战略转型规划中，现代物流将作为公司重要产业发展。本项目将逐步整团所有物流业务，并逐步拓展服务供应市场范围。

(二)规划布局

项目已完成总体设计方案，并通过国土、规划、环保等部门的联合预审，同意该项目在经开区长虹工业园内建设。目前，正在进行项目前期各项行政手续的审批工作。

五、项目财务分析

本项目的各项经济指标较好，利润与财务内部收益率高，具有较好的抵抗风险的能力。

7.解析企业软件开发项目的需求管理篇七

随着信息时代的发展, 计算机软件的需求愈来愈复杂, 规模愈来愈大, 而且随着企业的发展和工作过程重组, 需求变更已愈来愈成为必然。在企业软件项目的开发过程中, 需求变更贯穿了软件项目的整个生命周期, 在软件的项目立项、研发及维护各阶段, 用户经验的增加、对软件使用感受的变化以及整个行业的新动态, 都为软件带来不断完善功能、优化性能、提高用户友好性的要求。在软件项目管理过程中, 项目经理经常面对用户的需求变更。如果不能有效处理这些需求变更, 项目计划会一再调整, 软件交付日期一再拖延, 项目研发人员的士气将越来越低落, 将直接导致项目成本增加、质量下降及项目交付日期推后。这决定了项目组必须拥有需求管理策略。

需求管理是软件开发生命周期的初始阶段, 它对最终提交的软件产品的质量起着至关重要的作用。有资料统计, 软件项目40%—60%的问题都源于需求分析。所以, 重视需求、谨慎对待、严密分析, 是每一个开发者应该持有的正确态度。建立软件需求管理过程的目的在于用户和软件项目组之间形成共同的理解, 这种共同理解应体现在用户需求的文档化确认和对用户需求的控制中, 并保证项目的计划、工作产品和活动都与需求一致。

1 需求管理复杂性分析

软件需求是整个软件开发项目的最关键的一个输入, 和传统的生产企业相比较, 软件的需求具有模糊性、不确定性、变化性和主观性的特点, 不同于生产汽车、电脑等硬件的需求, 是有形的、客观的、可描述的、可检测的, 软件需求是企业软件项目最难把握的问题, 其复杂性体现在以下方面:

1.1 需求的描述问题。

缺少正式的、完整的需求文档浪费了大量的人力物力, 但是有了需求文档又出现了新的问题。在用户方进行的需求评审会完全是走形式, 因为用户根本不去听那上百页的需求文档。不同层次的客户 (用户) 关心的问题是不一样的, 想要每个客户都成为需求专家是不现实的。

1.2 需求的完备程度问题。

需求如何做到没有遗漏?如何准确划定系统的范围?这确实是一个两难问题, 稍微大一点的系统要想穷举需求几乎是不可能的, 每次开需求评审会时, 总会冒出新的需求, 以至于系统没有一个准确的范围界定。即使是这样, 系统还是要开发, 系统的范围还要硬性的划定一个, 从而建立一个基线。

1.3 需求开发的工期问题。

在需求上花费了大量的时间, 客户、企业是否能够忍受?为了确保需求的正确性, 完备性, 项目经理往往坚持要在需求阶段花费大量的时间, 但是客户与企业的高层领导却会为项目迟迟看不到实际可运行的软件担心不已, 他们往往会催促项目组尽快往前推进, 而项目组的成员往往也会被系统复杂、善变的需求折腾的筋疲力尽, 希望尽快结束需求分析的相关工作。

1.4 需求的细致程度问题。

需求到底描述到多细, 才算可以结束了?仁者见仁, 智者见智, 并没有定论, 如果时间允许, 要想细总可以细下去的。但是, 需求的周期越长, 可能的变化越多, 对设计的限制越严格, 对需求的共性提取要求越高, 所以只要客户 (用户) 、需求分析人员、设计人员、测试人员认为描述清楚了, 就可以进入设计阶段了。

1.5 需求的变化问题。

在软件开发过程中如果只有一条真理的话, 那一定是:需求的变化是永恒的, 需求不可能是完备的。软件开发的过程实际上是同变化做斗争的过程, 需求的变更不一定是坏事, 也有可能是好事, 是商业机会, 对市场敏感的人可以从需求的变化中发现市场机会。

2 需求变化的原因:

需求变化的原因很多, 比如: (1) 一开始没有识别全, 需要增加需求; (2) 业务发生了变化, 需求必须变化; (3) 需求错误; (4) 需求不清楚。

需求的变化问题是每个开发人员、每个项目经理都遇到的问题, 也是最头痛的问题, 一旦发生了需求变化, 项目组不得不修改设计、重写代码、修改测试用例、调整项目计划等等。需求的变化好像为项目的正常的进展带来不尽的麻烦, 怎么办?只有通过需求管理使需求在受控的状态下发生变化, 而不是随意变化, 需求管理就是要按照标准的流程来控制需求的变化。难题随之而来, 需求中的变化一般不是突发的革命性的变化, 最常见的是项目需求的渐变 (Proje ct Scope Cre e p) 问题, 这种渐变很可能是客户与开发方都没有意识到的, 当达到一定程度时, 双方才蓦然回首, 发现已经物是人非, 换了一番天地。

3 需求管理策略

需求管理需要遵守以下策略:

3.1 需求一定要与投入有必然的联系

需求一定要与投入有必然的联系, 否则如果需求变更的成本由开发方来承担, 则项目需求的变更就成为必然了。人们常说世上没有免费的午餐, 同样也不应该有免费的需求变更。但是, 接受需求变更目前却是软件企业不得不咽下的苦果。所以, 在项目的开始无论是开发方还是出资方都要明确这一条:需求变, 软件开发的投入也要变。

3.2 要充分理解客户提出来的需求

开发者应该理解客户的需求, 如果这点做不到, 后面的工作是没有意义的, 所以, 那种在没有理解需求的情况下, 就仓促开发的做法是不合适的。

3.3 需求的变更要经过出资者的认可

需求的变更引起投入的变化, 所以要通过出资者的认可, 这样才会对需求的变更有成本的概念, 能够慎重地对待需求的变更。

3.4 做好需求文档的版本管理

记录用户需求、系统需求、软件分配需求的文档都要作为基线确定下来, 做好相关文档的管理工作。需求的基线是指是否容许需求变更的分界线, 需求分析人员在充分与客户用户进行沟通的基础上形成第一个版本的需求文档, 这个需求文档在通过需求评审后即可以建立第一个需求基线。此后每次需求变更并经过需求评审后, 都要重新确定新的需求基线, 以免将来用户需求发生变更时, 原来的需求无法查找。为有效进行需求变更控制, 必然要做的工作就是保存好各个版本的需求基线, 维护需求基线文档, 以备不时之需。

3.5 小的需求变更也要经过正规的需求管理流程

小的需求变更也要经过正规的需求管理流程, 否则会积少成多。在实践中, 人们往往不愿意为小的需求变更去执行正规的需求管理过程, 认为降低了开发效率, 浪费了时间。正是由于这种观念才使需求的渐变不可控, 最终导致项目的失败。

3.6 精确的需求与范围定义并不会阻止需求的变更

并非对需求定义的越细, 越能避免需求的渐变, 这是两个层面的问题。太细的需求定义对需求渐变没有任何效果, 因为需求的变化是永恒的, 并非需求写细了就不会变化了。

3.7 注意沟通的技巧

由于需求的变更可能来自投资方、也可能来自用户方和开发方, 作为投资方可能不愿意为需求的变更付出更多的成本, 而开发方有可能主动的变更了需求目的是使软件做的更精致。于是作为需求管理者, 项目经理需要采用各种沟通技巧来使项目的各方各得其所。

4 结束语

需求管理是软件项目中一项十分重要的工作, 据调查显示在众多失败的软件项目中, 由于需求原因导致的约占到45%, 因此有效的需求管理是企业软件开发项目顺利达成目标的重要支撑条件。理解项目开发的目的和用途, 梳理用户需求, 设计系统的各项功能需求, 监控需求变化, 进行需求确认, 对需求风险进行防范, 以一系列的方法和措施实施需求管理工作, 才能推进软件项目良性发展, 达到用户与软件开发企业的双赢。

摘要：需求管理是整个软件工程的管理的基础, 也是项目成功的关键所在。本文论述了企业软件开发项目中需求管理的重要性, 详细描述了软件需求的复杂性, 分析了需求变化的原因, 并针对这些问题提出相应的管理策略。

关键词：需求管理,软件需求,需求变化

参考文献

[1]吴艳艳.软件项目管理中的需求管理[J].信息技术与信息化, 2008 (2) .

[2]唐薇娜.正确应对需求变更[J].软件工程, 2007 (6) .

8.基于儿童需求开发校本课程篇八

一、打造多彩游戏家园

学校以“适合儿童生活的幸福家园”为办学目标，怀着对儿童的尊重与关爱，营造了温馨和谐、其乐融融的游戏空间：

镜头一：热闹的跃动园。一群孩子在教学楼中央的成长广场中玩着“飞行棋”。巨大的棋盘，五彩的大色子上下翻飞。这是教师们亲自设计、动手绘制的可以“运动”的房子，如飞行棋、幸运转盘棋、大城小城等。教师带领学生开发各种跳房子游戏，孩子们在跃动园里享受游戏之乐。

镜头二：翻滚的“彩虹”。怎么校园里轮胎也是彩色的？那是洪小师生DIY的杰作。他们创意无限，为轮胎穿上多彩的外衣，学生在课间自由嬉戏，有的进行轮胎接力跑，有的“过桥钻山洞”，校园里欢声笑语，翻腾着绚丽多姿的“彩虹”。

镜头三：美丽的开心农场。“童孙未解供耕织，也傍桑阴学种瓜”。学校利用校园内的角落，开辟“开心农场”，让每个儿童体验种植的乐趣。清明前后，种瓜点豆。老师们带领学生翻土、播种、施肥、浇水，种植各种蔬菜。锄头、铁锹这些在城市里见不到的工具，孩子们在这里都一一熟知。待到果实累累时，老师和孩子们一起采摘蔬菜，体验劳动的乐趣。

此外，一些在城市里渐渐绝迹的传统游戏，如滚铁环、扔沙包、跳皮筋、踢毽子等，开始回归校园。学生的课间活动越来越丰富，下课铃一响，校园里便生龙活虎起来，踢毽子、丢沙包，孩子们玩得不亦乐乎，校园里欢笑声连连，孩子们回归到了最真实的儿童世界。

二、开发多样游戏课程

学校以节日课程为载体，让孩子们在各种趣味活动中学得知识、培养能力。丰富的节日课程与游戏结合在一起，既能扩大孩子们的视野，又能增强他们的想象力，让孩子们真切体验到童年生活的美妙奇特。

数学游戏节以“夺宝奇兵”为主题，让孩子们踏上有趣的寻宝之旅。孩子们手持特印的“夺宝奇兵”地图册，一路经过“趣味魔方馆”“七巧大比拼”“口算小能手”等充满趣味与挑战的场馆。每完成一项挑战，他们就可以顺利盖上一枚印章。等集齐印章，他们就可寻得数学宝藏。

读书节cosplay活动，校园里闪动着一个个耀眼的“明星人物”，有白娘子、孙悟空、诸葛亮、哈利波特等。孩子们装扮成自己最喜爱的书中人物，在校园的角落摆上图书跳蚤市场，通过换书活动，感受自由交易，训练口语表达能力，让时间和空间成功大挪移。

每年一度的体育游戏节，周周有活动，天天有游戏，人人皆参与。特别是闭幕式活动，邀请家长代表参加。家长、孩子、老师，一起参与各种团体游戏，什么“赶猪上山”“同舟共济”“无敌风火轮”等。

各年级游戏体验课程，更是精彩纷呈。如一年级“百岁老人诞生季”，一百个孩子一齐穿衣服、系鞋带、整理书包、做100道口算题等，孩子们在游戏中动手、动脑、竞赛，感受成长之妙。六年级体验活动“养护蛋宝宝活动”，孩子们将蛋宝宝精心打扮，带着自己的“宝宝”穿山洞、过独木桥、穿越火线，“宝宝”平安无事则护幼成功。他们从活动中感受到父母养育孩子的辛苦，从而深刻体会到孝敬父母、感恩明礼的道理。

三、营造趣味游戏课堂

成尚荣先生说，教室中的儿童与文本中的儿童联结，老师的精神状态也要和孩子一样，这样的课堂才是诗意的欢聚。营造有趣的游戏课堂，让课堂流动孩子气，就是要注重为孩子的情感释放、想象放飞创造空间。课堂游戏能让儿童感到快乐、满足和充分的成就感，是孩子最喜欢的一种学习活动方式。

学校在学科教学中融入游戏课程，起到了非常好的教学效果。如，在低年级识字教学中引入“摘苹果”“一字开花”“火箭发射”等游戏来帮助学生巩固记忆，学生注意力得到加强，更能高效进行识字学习；中高段语文学习中加入“词语接龙”“角色扮演”等游戏，使学生学习语文的兴趣浓厚许多。数学老师在执教《可能性》一课中，对数学知识与“游戏活动”进行了资源整合，把枯燥的数学学习和快乐的游戏体验有机结合在一起，将体验教学的妙处发挥到极致。通过“抛硬币、摸球、猜棋子、闯关”等一系列的游戏活动，让学生沉浸在快乐的体验之中，教学气氛活跃，师生互动高潮迭起，教学效果很好。

学校一直在积极探索符合儿童学习的各类游戏课程，如对学生进行心理健康教育的综合实践课《我能行》，通过挑战一个又一个看似不能成功的游戏，树立健康自信的人生观、价值观；科技制作课《趣味多米诺》《玩转七巧板》，将传统的游戏器材引入到课堂，老师和孩子们一起探究，一起尝试，享受成功与快乐。

四、收获共赢游戏精神

游戏课程的实施，锻造了学生遵守规则的意识。通过参加各种游戏活动，学生了解到各种游戏规则，懂得游戏一定要遵守规则，否则就会失去游戏的意义。他们的规则和道德意识慢慢形成，不断积累，逐步转化为个人内在的修养。

游戏课程的实施，培养了学生的合作意识。从个人游戏到团队合作游戏，学生慢慢学会与同伴合作，他们懂得了靠单打独斗是难以成功的，必须依赖集体的力量。这种合作能力将成为学生以后人生成功的基石。

游戏课程的实施，培养了学生的综合素质。通过制作游戏工具如毽子、沙包、学具等，学生的动手能力得到了锻炼；通过创编游戏，学生的创新意识渐渐增强；通过参与游戏，孩子摆脱了一切以自我为中心的意识，学会与同伴协商，关心体谅同伴，从而提高情商，学会处理人际关系。

让校园回归童真，还儿童幸福童年。我们期待，一种以儿童为本位的身心协调的新“童年生态”逐渐在学校建立起来，让“绿色游戏”引领课堂教学新潮流，让丰富的游戏活动激发学生的潜能，引导学生在“玩中学”，玩出“智慧”。奔跑吧，快乐游戏课程！

（作者单位：武汉经济技术开发区洪山小学）

【软件开发需求建议书】推荐阅读：