软件项目需求管理的目标和原则 软件项目需求管理

软件开发中项目需求管理策略是什么呢？

需求管理需要遵守以下策略： 1、需求一定要与投入有必然的联系。

需求一定要与投入有必然的联系，否则如果需求变更的成本由开发方来承担，则项目需求的变更就成为必然了。

人们常说世上没有免费的午餐，同样也不应该有免费的需求变更。

但是，接受需求变更目前却是软件开发商不得不咽下的苦果。

所以，在项目的开始无论是开发方还是出资方都要明确这一条：需求变，软件开发的投入也要变。

2、需求的变更要经过出资者的认可。

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

笔者曾经经历过一个项目，为了避免项目的风险，我们请了用户代表全程参与了开发过程，结果此用户代表在开发过程提出了大量“小的需求变更，当开发人员按此需求变更修改了软件时，在项目进入现场实施阶段时，却有大量的这些变更需要改回去，问题就是出在我们的项目组成员视该用户代表的需求为圣旨，却忽略了需求是否经过了客户方真正有决策权的人员的认可。

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

小的需求变更也要经过正规的需求管理流程，否则会积少成多。

在实践中，人们往往不愿意为小的需求变更去执行正规的需求管理过程，认为降低了开发效率，浪费了时间。

正式由于这种观念才使需求的渐变不可控，最终导致项目的失败。

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

并非对需求定义的越细，越能避免需求的渐变，这是2个层面的问题。

太细的需求定义对需求渐变没有任何效果。

因为需求的变化是永恒的，并非由于需求写细了，它就不会变化了。

注意沟通的技巧。

实际情况是用户、开发者都认识了到了上面的几点问题，但是由于需求的变更可能来自客户方、也可能来自开发方，作为客户他们可能不愿意为需求的变更付出更多的投资，开发方有可能是主动的变更了需求，他们的目的可能是使软件做的更精致，于是作为需求管理者、项目经理需要采用各种沟通技巧来使项目的各方各得其所。

基于上述的问题，必须对需求进行管理，使需求能够真正成为软件工程和管理的基线，使软件计划、活动和工作产品同软件需求保持一致，使需求可以复用

企业软件工程项目和商业软件项目需求管理的不同有哪些？

企业业务软件工程项目和商业软件产品项目上项目无论是需求重点，实现方式，项目管理等方面都有极大不同。

现在的软件工程有关研究并没有关注此中的区别，实际上，其中绝大部分还集中在较简单的产品项目上。

对于需求变动要大得多的企业软件项目来说，对需求进行分级管理是非常必要的，也是生死悠关的。

企业化软件项目和商业软件的（承包开发）还是有很大的不一样的，最大的区别就在于项目需求的重点不一样，以致于这两种同样称为软件工程，就其项目过程管理是几乎完全不一样的。

商业软件的开发最大的特点是就是基本功能非常明确，只在细节上有多种选择，所以商业软件开发的项目管理重在源代码管理和算法的优化，以及测试严格，就测试要求的强度上单纯软件代码的质量来说，要强于企业信息化的软件工程项目。

企业信息工程项目一般来源于企业某一特定的业务软件需求，象要上一个仓库管理系统，从进货到定期定标出仓平衡责任追踪等；或者是一个生产流程配料系统，象MRP2；或者是一个购销一体计划系统，象ERP（资源管理），等等。

这种软件有时侯会象国产的那些变相的会计软件式的ERP一样当成商业软件开发，显然，这时侯与上述的成形商业软件没有太大的区别，但在企业实际上千差万别的应用需求上，几乎就是一堆电子垃圾。

企业业务软件是一种必须适应同时能够优化企业流程的计算机辅助运营系统，真正起作用的，通常只能是一对一实现定制；这种需求是如此广泛，以致于大型企业如果不是聘有一两家软件咨询顾问公司就是自建一个计算机部门专门负责这一方面的工作；最典型的例子就是沃尔玛特。

正由于企业用的软件都存在着强烈的需求一对一定制的要求，所以这种项目其一是不便宜；如果一个企业客户以购买商业成形软件的理解水平来购买一个项目洽谈的话，在他理解什么叫企业项目前，最好不要打算做他的生意。

一个企业项目动辄数百万上千万是不奇怪的，上亿也寻常，而一套商业软件，无论名称多么好听，什么第几代ERP，都只不过是一万几千大洋就可以打发的；实在不愿意给钱又不怕给罚盗版的话，还可以花五个铜板上街买一套盗版光盘现装现用。

为了应付企业业务软件项目的强烈的定制需求，供应商都提供了广泛的基础组件和嵌套工具，以便可以由二三级的程度员可以在现场为用户一对一的进行定制试用更改再定制等项目实现。

典型如SAP，有朋友问我拿SAP的盗版玩玩，保证不外流。

我费了很大的工夫才让他明白，SAP有的只是基础组件库，还很丰富，涉及到27个项目常用业务场合的组件库，包括与之配合的数据库预制定义（表定义），但绝不是象国内那些ERP那样装起来可以玩的东东。

一个SAP项目要求用户按自已需求定购这些组件库，以及必须的支持软硬件，数据库操作系统什么的，最经常的就是ORACLE和SOLARIS了；然后SAP项目组要到企业里蹲点，听各个部门讲流程故事；然后是写需求文档，建原型，让企业的项目组试用部门流程，基干流程确定合乎需求了，下一步的工作就是简单了，找几个三流的程序员用ABAP4这种比javascipt还简单的脚本语言把各个组件的功能连成一个统一的流程。

这个工作就完成了一大半了。

——可别小看这些三流程序员，在软件蛮荒年代他们凭这一招可以拿到每个月两万人民币的工资呢！其实呢，那是一个高中生就可以完成的工作。

由此可见，企业软件项目的关键在于需求管理和流程建模，相反，算法和基本功能以及BUG什么的，那是作为商业软件开发的组件保证的，那一般以外包的形式由印度这些公司早早做了出来。

企业软件需求最大的困难就是用户根本不知道自已要干什么，最常犯的错误就是把现有的落后流程要求电脑重复一遍，拿了机关枪，总是要求上面没有装刺刀，还抱怨不比红缨枪好用。

另一个常见的错误就是随着企业项目主管，（职业最低成是电脑科主任，高点就是一二把手了）知识开始丰富后，总是把有用没有用，暂时有用或永远没有用的需求要项目组一一实现，反正，每条要求都是振振有词，仿佛都是非立刻实现不可的。

作为承包方的人员是没有办法与之争业务上有没有用的，（谁是这一行业的专家啊？人家已经是霸主了才上软件，你算那们子专家啊？），但如果真的一一跟着他的点子走，就算累死了，这个项目也是永远没有法子完成的。

而在商业需求明确的商业软件开发中就不会碰上这种事情。

这时侯需要对客户的需求进行分级管理，简单地说，把需求分成五级：ugent（必须立刻优先实现），necessay（必须实现，但不一定马上进行），needed（需要的，不过没有也还凑合），ette（现在似乎也可以，但可以更好一点），useful（总会有用的）。

一个需求等级的确认需要两个过程，首先是从正面论证它是不是必须的，是不是好得多；然后从反而论证，不要他是不是可以回避的，天会不会塌下来？这样，一个软件需求就可以相当定一个级别。

毫无疑问，如果一个项目各项需求验证下来只是useful的，不但赚不了多少钱，而且，这个项目未必有必要存在；但如果都是ugent的话，如果不是大幅度加价的话，就叫神仙来做好了。

显然，无论客...

软件开发之项目需求管理是什么？

前言：在软件项目的开发过程中，需求变更贯穿了软件项目的整个生命周期，从软件的项目立项，研发，维护，用户的经验在增加，对使用软件的感受有变化，以及整个行业的新动态，都为软件带来不断完善功能 ，优化性能，提高用户友好性的要求。

在软件项目管理过程中，项目经理经常面对用户的需求变更。

如果不能有效处理这些需求变更，项目计划会一再调整，软件交付日期一再拖延，项目研发人员的士气将越来越低落，将直接导致项目成本增加、质量下降及项目交付日期推后。

这决定了项目组必须拥有需求管理策略。

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

缺少正式的完整的需求文档浪费了大量的人力物力，但是有了需求文档又出现了新的问题。

在用户方进行的需求评审会完全是走形式，因为用户根本不去听他读那上百页的需求文档。

不同层次的客户（用户）关心的问题是不一样的，想要每个客户都成为需求专家是不现实的。

2、需求的完备程度问题。

需求如何做到没有遗漏？如何准确划定系统的范围？这确实是一个两难问题，稍微大一点的系统要想穷举需求几乎是不可能的，每次开需求评审会时，总会冒出新的需求，以至于系统没有一个准确的范围界定。

即使是这样，系统还是要开发，没办法，系统的范围还要硬性的划定一个，从而建立一个基线。

3、需求开发的工期问题。

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

4、需求的细致程度问题。

需求到底描述到多细，才算可以结束了？仁者见仁，智者见智，并没有定论，如果时间允许，要想细总可以细下去的。

但是，需求的周期越长，可能的变化越多，对设计的限制越严格，对需求的共性提取要求越高，所以只要大家（客户、用户、需求分析人员、设计人员、测试人员）认为描述清楚了，就可以进入设计阶段了。

5、需求的变化问题。

在软件开发过程中如果只有一条真理的话，那一定是：需求的变化是永恒的，需求不可能是完备的。

软件开发的过程实际上是同变化做斗争的过程，需求的变更不一定是坏事，也有可能是好事，是商业机会，对市场敏感的人可以从需求的变化中发现市场机会。

需求变化的原因很多，如： 一开始没有识别全，需要增加需求； 业务发生了变化，需求必须变化； 需求错误； 需求不清楚。

需求的变化问题是每个开发人员、每个项目经理都遇到的问题，也是最头痛的问题，一旦发生了需求变化，你不得不来修改你的设计、重写你的代码、修改你的测试用例、调整你的项目计划等等，需求的变化好比是万恶之源，为项目的正常的进展带来不尽的麻烦，怎么办？管理它！使需求在受控的状态下发生变化，而不是随意变化，需求管理就是要按照标准的流程来控制需求的变化。

难题随之而来，需求中的变化一般不是突发的革命性的变化，最常见的是项目需求的渐变（Project Scope Creep）问题，这种渐变很可能是客户与开发方都没有意识到的，当达到一定层度时，双方才蓦然回首，发现已经物是人非，换了一番天地。

需求管理策略 需求管理需要遵守以下策略： 1、需求一定要与投入有必然的联系。

需求一定要与投入有必然的联系，否则如果需求变更的成本由开发方来承担，则项目需求的变更就成为必然了。

人们常说世上没有免费的午餐，同样也不应该有免费的需求变更。

但是，接受需求变更目前却是软件开发商不得不咽下的苦果。

所以，在项目的开始无论是开发方还是出资方都要明确这一条：需求变，软件开发的投入也要变。

2、需求的变更要经过出资者的认可。

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

笔者曾经经历过一个项目，为了避免项目的风险，我们请了用户代表全程参与了开发过程，结果此用户代表在开发过程提出了大量“小的需求变更，当开发人员按此需求变更修改了软件时，在项目进入现场实施阶段时，却有大量的这些变更需要改回去，问题就是出在我们的项目组成员视该用户代表的需求为圣旨，却忽略了需求是否经过了客户方真正有决策权的人员的认可。

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

小的需求变更也要经过正规的需求管理流程，否则会积少成多。

在实践中，人们往往不愿意为小的需求变更去执行正规的需求管理过程，认为降低了开发效率，浪费了时间。

正式由于这种观念才使需求的渐变不可控，最终导致项目的失败。

4、精确的需求与范围定义并不会阻止需求的...

软件项目计划的计划制定

项目计划详细说明了所需软件工作及如何实现。

它定义了每一个主要任务，并估算其所需时间和资源，同时为管理层的评估和控制提供了一个框架。

项目计划也提供了一种很有效的学习途径。

如果能合理建档，它便是一个与实际运行效能比较的基准。

这种比较可以使计划者看到他们的估算误差，从而提高其估算精确度。

我们着重强调对项目规模和资源的估算，是因为低质量的项目资源估算将不可避免地造成资源短缺，进度延迟和预算超支。

又由于项目资源估算是从软件规模估算中直接衍生出来的，所以低质量的规模估算是造成许多软件项目问题的根本原因。

项目计划应在项目开始初期制定出，并随着工程的进展不断地加以精化。

起初，由于软件需求通常是模糊而又不完整的，我们的工作重点应在于明确该项目需要哪些领域的知识，并且如何获取这些知识。

如果不遵循这一指导原则，程序员们通常会积极地投入到那部分已知的工作中去，而把未知部分留滞到以后。

这种工作方式通常会产生很多问题，因为未知部分具有最高的风险系数。

软件项目计划的逻辑如下所述 ：由于软件需求在初始阶段是模糊而又不完整的，质量计划只能建立在对客户需求的大致而不确切的理解之上。

因此，项目计划应该从找出含糊不确切与准确恰当的软件需求间的映射关系入手。

接着建立一种概念设计。

项目初始架构的建立要十分谨慎，因为它通常标定了产品模块的分割线，同时描述了这些模块所实现的功能及所有模块间的关系。

这就为项目计划和项目实施提供了组织框架，因此一个低质量的概念设计是不能满足要求的。

在每一次后续的需求精化时，也应同时精化资源映射，项目规模估算和工程进度。

软件项目计划-制订软件项目计划的方法与策略制订软件项目计划的目的在于建立并维护软件项目各项活动的计划，软件项目计划其实就是一个用来协调软件项目中其它所有计划，指导项目组对项目进行执行和监控的文件。

一个好的软件项目计划可为项目的成功实施打下坚实的基础。

软件项目有其特殊性，不确定因素多，工作量估计困难，项目初期难于制定一个科学、合理的项目计划。

我曾主持和参与过大大小小的软件项目十余项，下面我将把我制订软件项目计划的经验分享给大家。

1.注重项目计划的层次性软件项目计划的层次及其关系如下图所示。

高级计划，是项目的早期计划。

高级计划应当是粗粒度的，主要是进行项目的阶段划分，确定重大的里程碑，所需相关的资源，包括人力资源、设备资源、资金资源，即所谓的人、财、物三个要素。

大的阶段交替之前，应做好下一阶段的详细计划，我们称之为二级计划。

详细计划要确定各项任务的负责人，开始时间，结束时间，任务之间的依赖关系，设备资源，小的事件点（即里程碑）。

如果项目规模相对较大，可以有多级的计划，比如说，一个项目组可能分为几个开发组，二级计划是各开发组制订的适合的自己小组的计划。

如果开发组还分了小组，可以有小组的三级计划。

开发人员的个人计划是低级计划，由开发人员根据自己的任务自行制定，要把任务细化到人·日。

一般的，软件项目计划至多有四级就够了，过多的等级将会引发效率的瓶颈。

大的项目不见得要有庞大的组织和人员数量来支撑，合理的划分小组，减少组织的层次，有利于项目计划的制订和实施。

较小的软件项目由于工期不长，人员较少，有二级计划（高级计划与低级计划）也是可行的。

2.重视与客户的沟通与客户的沟通是很重要的。

不必害怕客户知道我们的开发计划，特别是项目进度情况，应当和客户共享这些信息。

首先，客户会提出一些对项目时间、进度、效果上的要求，这个指标往往经不起推敲，有的还带有较强的政策性。

如：在我主持的一个某单位人nnerlink>MIS系统的开发中就发现，客户方对时间上的约束是有成形的文件的，是他们单位领导们开会的决定。

客户给出的从项目启动到验收的时间只有三个月，但是，经过我们认真的需求调研，做出项目进度的粗计划和部分的二级计划后，发现三个月的时间是难于实现的。

我们把做出的调研文档和项目计划摆出来和和客户讨论，最终使项目的开发时间延长为六个月。

站在为了科学地分析和解决问题的立场上来看，项目组和客户的目的是一致的，所以对于合理的项目进度客户是会理解与支持的。

其次，我们有义务要让客户知道项目的计划。

这样才能让客户和用户主动、积极参与项目，达到项目的最终目标。

项目计划取得双方签字认可是一种好的习惯。

客户可能不愿意签正式的文件，那么在文档的封面上签上双方负责人的姓名、联系方式也行，虽然是非正式的，但留下了项目工作的痕迹。

有必要想办法让客户清楚签字意味着什么。

这就意味说双方有了一个约定，既让用户感觉心里踏实，也让自己的项目组有了责任感，有一种督促和促进的作用。

3.该详细的详细，该简略的就简略软件项目计划就如同软件项目本身一样有它特殊性，一个三五个人花两三个月就可以完工的小项目，可能项目计划就四五页纸，包括一个WBS（工作分解结构）和一个Gantee图（甘特图）。

一个需要五六十个人甚至上百人，要花上半年或更长时间的...

软件项目中的计划阶段项目目标和范围是什么？

开始一个新项目或版本时候，首先是和用户一起确认需求，进行项目的范围规划。

项目是范围，进度，质量和资源四要素的平衡，用户对项目进度要求和优先级高的时候，我们往往要缩小项目范围，对用户需求进行优先级排序，排除优先级低的需求。

另外我们做项目范围规划的一个重要依据就是我们的历史经验数据，对项目特征的清楚认识，项目范围规划初期需求你进行一个较宏观的估算，否则你很难判断清楚或给用户承诺在现有资源情况下，你3个月时间里面是否可以完成20个或更多用户功能。

正规过程好像是先确认项目范围，然后根据WBS-进度计划确认实际的项目周期，但实际情况往往很难如此，用户往往对进度的关注度大于对范围的关注度，一个项目半年或一年都看不到具体的产品出来用户肯定是无法接受的，所以我们的软件项目一般也是按版本增量迭代进行开发。

另外这里需要强调下项目目标的确定，项目的目标不能简单理解为在某个时间点完成所有功能。

项目另外一个重要目标就是项目的质量目标，你完成的这个项目需要达到那个等级的质量标准，交出的产品BUG泄漏率要控制在什么范围内等内容。

项目的质量目标不会影响到我们的范围，但会影响到我们后续评审，测试等时间的安排，直接影响到项目的进度。

PMBOK里已经明确提到项目范围定义的另一个重要目的就是项目的绩效测量和验收准则，你交付项目的时候用户会根据用户需求说明书内容对项目进行验收，所有我们项目的范围的定义必须是明确，量化，可验证和可测试的，这样才能够避免后期无谓的纠纷。

另外在概述阶段需要分析项目的假设和约束，假设和约束又分为技术方面和非技术方面，在这里我们分析的所有假设都可能成为项目的风险。

2.项目进度的确定 项目的目标和范围确定后，需要开始确定项目的过程，项目整个过程中采用何种生命周期模型？项目过程是否需要对组织级定义的标准过程进行裁剪等相关内容。

项目过程定义是进行WBS分解前必须确定的一个环节，你采用瀑布模型和增量迭代模型对WBS分解和进度计划安排显然是完全不同的。

项目过程确认清楚后开始进行项目的WBS分解，WBS分解一般是项目组的核心成员参加，但项目经理应该是起主导和协调作用。

WBS分解方法一般有基于过程和基于成功两种方式，但两种方式可以混合使用，比如在高层分解的时候先分解出子系统和工作包，在底层的时候再按照需求，设计，编码和测试各个过程进行分解。

WBS的最底层工作单元需要是可以独立核实的产品，需要去下达计划和任务，工作单元需要有明确的责任人，因此有时候在没有做仔细的估算时候我们很难让工作单元满足这些要求，这样就难免在进行估算过程中还要对WBS进行优化和调整。

WBS分解完成后可以开始进行工作单元的估算，估算一般有专家法，三点法和功能点法估算，由于我们的项目采用专家法估算，因此更需要项目核心成员和有经验的成员参加，估算一般会针对工作单元的单位和复杂度进行估算，最后估算出项目的总规模，再除以项目的生产率后得到项目的工作量数据。

专家法估算一般会进行很多轮，直到所有指标都收敛（收敛标准是组织或项目事先确定清楚了，如偏差人员的责任矩阵进行分析，对于关键路径一般直接用运筹学中的关键路径分析法确定ES,EF,LE和LF四个时间即可。

在项目进度计划基本排出来后就可以规划和确定项目的里程碑和基线了，项目的里程碑和基线是项目重要的跟踪控制检查点，在里程碑项目还会做专门的里程碑报告，对项目的当前状态，项目的进度，工作量，规模，缺陷等各项指标的偏离进行分析。

整个项目进度计划基本出来后需要和项目组的所有项目成员确认，获取项目的内部承诺，项目成员应该对整个进度计划安排基本达成一致。

项目计划还有需要支持计划需要制定，项目进度计划出来后整个可以通知QA和配置管理员分别制定质量保证计划和配置管理计划，项目经理协助测试负责人制定项目的系统测试计划。

项目管理的目标是什么？

先从目标来看，项目管理的目标可是说是将项目需求种的所有要求都完成。

这是最基本的目标，不过如果仅仅是着眼于这个目标，那么项目经理和工头又有什么差别？而且实践证明，如果这样来管理项目，那么十有八九项目最终是要失败的。

原因？软件项目从来不像想象的简单，一板一眼的按流程完成合同中规定的要求就可以交付项目的情况，通常是可遇而不可求的。

所以不能把项目管理的目标仅仅放在实现合同规定的项目需求上。

敏捷方法论提出的观点是，要为客户创造价值，以提高客户的竞争力为出发点，这比仅仅完成合同更进了一步。

客户是整个软件项目的发起者，从这一个角度来讲，甚至可以认为客户所说得一切都是对的！时刻牢记这一点，通常能够是项目的进行保持在一个更接近正确路线的状态。

如何在软件项目中进行有效的管理

及时向开发组反映客户的新要求。

让客户得到一个质量上乘功能齐全的产品。

完备的项目管理拥有一支经验丰富的项目管理队伍，计划中规定出项目目标、质量目标，这是项目经理应凭自己的经验调整进度、系统测试阶段和客户测试阶段、质量管理、配置管理、资源状况和调配，在项目初期指定配置管理计划，以质量取信于市场。

CMM2的六个关键域为：需求管理，对项目及项目经理做出合理评价。

配置管理采用先进的配置管理方法。

项目进程中避免不了因需求或其他技术问题干扰进度。

通过CMM2的六个关键域职称项目管理以CMM为目标和支撑进行项目的管理。

在国内软件开发行业一片混乱中，减少双方需求误会和严格控制进度，这依赖于我们有一套严格的项目管理体系。

领导的重视对于一个企业来说领导的重视莫过于的项目管理的最大支持，设置多个检验点，分析态势、重新调配资源项目管理我们不能保证我们的技术方案在各个方面都是最优的，但是我们能够保证最终交给用户的是一套高质量、高可用的系统，让所有客户满意，使公司的开发过程与国际接轨，由QA监督个检验点评审过程，项目外部的QA人员对整个项目的过程进行监控，并严格控制变更。

客观上、分承包商管理。

需求管理在项目经理运用娴熟的项目管理技巧进行客户与公司的沟通，从而达到明确需求和管理需求的目的，通过这支队伍的努力、设计阶段、编码阶段、项目组结构，在严格符合规程的条件下运用项目经理丰富的管理经验将技术和人力资源合二唯一进行管理。

项目经理对外代表公司与客户做最充分的沟通，对内代表客户严格要求质量、资源调配情况心中有数，从而及时化解突发事件。

项目计划我们的项目经理会最终依照客户需求给出该项目的实施计划，我们已拥有规范化和适用于的项目管理流程。

记录较大的需求变更，并愿意通过项目管理提高产品质量。

质量管理无论在项目内部还是项目外部我们都由QA人员对项目进行监督。

多名经验丰富的项目经理管理个项目。

突出管理我们的项目管理决不只是单纯的对规程的遵照，而是注重管理，以该项目计划为基准进行项目的开发和实施。

QA按照事先规定的配置管理基线和项目里程碑进行审核。

重视项目经理的管理技巧和沟通能力，以便在更大程度上满足客户的需求。

项目管理方式项目管理流程介绍： 我们的项目的生命周期大致分为以下几个阶段：需求阶段，规定各阶段的流程并指定责任人。

按照规程和项目实际情况确定个项目的里程碑，决定走国际化的标准轨道，以提高高层的项目管理意识来带动整个公司的项目管理体系日益成熟化、风险预期以成本估算等。

在项目执行过程中，以标准保证质量。

特别要指出的是、项目开发及实施进度，并在开发期间应用。

按照项目生命周期建立配置管理基线，把握项目大方向，接受美国的成熟方法，项目内部QA人员负责测试和配置管理的计划及落实，我们有一部分来自外企和国外的高层人员，我们的高层人员有成熟的项目管理理念，关注项目管理：在我们公司的培训内容上有针对于领导层的项目管理培训系列培训。

项目追踪在项目实施过程中我们要求我们的项目经理每周至少运用项目管理工具Project跟踪两次项目做到对项目的进程，并按照项目管理流程严格监督、项目计划、项目跟踪

软件项目管理的需求如何管理

需求管理包括需求调研，需求开发，需求确认，需求变更管理需求调研是要到市场或者最终用户处进行需求调研的，获取原始的用户需求，形成客户需求说明书。

需求开发是根据原始的用户需求，进行开发整理，形成需求规格说明书；需求确认是项目干系人，包括专家、用户一起进行进行需求评审，确认需求，这时一般会将需求规格说明书转化成需求矩阵（需求表格，进行整个生命周期管理）需求变更管理是需求管理的重要组成部分，需要有变更申请与批准，未被批准的需求变更不允许程序员私自修改。

项目管理的组织设计原则是什么？

(1) 目标的一致性。

为了总目标的完成， 建立层层保证、左右协调的目标体系。

来源：考试大 （2） 有效的管理幅度和层次。

管理幅度与管理层次成反比， 因此应尽可能地扩大管理幅度， 减少不必要的层次， 以免信息的迟滞和失真。

（3） 责任和权力要对等。

责权要对等， 有权无责， 会助长瞎指挥乱拍板；有责无权会束缚管理人员的工作开展和积极性。

（4） 要合理分工和密切协作。

这种分工协作既包括上下级的分工协作， 也包括平级之间的分工协作。

来源：考试大 （5） 集权与分权相结合。

集权与分权应考虑到具体项目的情况， 但不能走极端。

（6） 建立激励和约束机制。

严明的奖惩制度也是非常重要的一个环节。

项目管理的目标应符合合同的要求有哪些呢？

1、工程建设的安全管理目标； 2、项目的总投资目标（因为项目工程总承包需要做设计）和建设项目工程总承包方的成本目标（其前者是业主方的总投资目标，后者是建设项目工程总承包方本身的成本目标）； 3、建设项目工程总承包方的进度目标； 4、建设项目工程总承包方的质量目标。

工程总承包管理活动应包括项目部的项目管理活动和工程总承包企业职能部门参与的项目管理活动。

转载请注明出处51数据库 » 软件项目需求管理的目标和原则