需求管理（Requirements Management ）是属于CMM2中的过程域，简称为REQM ，需求开发（Requirements Development ）是CMM3中的过程域，简称RD 。这两个过程域是CMMI 体系中关于需求的全部内容，下面分别对这两部分进行介绍。本文对CMM 的一些基础知识、基础术语不再介绍。
需求管理与需求开发的分界线：
市场营销
用户需求
管理层
需求开发
需求管理
市场
营销
管理层项目环境
项目变更 大家可以这样理解，需求管理是指对需求变更的管理、对需求的跟踪，而获取需求、定义需求则属于需求开发部分。
需求管理
在CMMI 中，需求管理的目标定义为：
a. 把软件需求建立一个基线供软件工程和管理使用。
b. 软件计划、活动和工作产品同软件需求保持一致。
更高的目标：
软件需求的复用
需求管理的原则和方法
a. 必须与需求工程的其他活动紧密整合
b. 需求必须是文档化的、正确的、最新的、可管理的、可理解的
c. 只要需求变化了，需求变更的影响就必须被评估
d. 需求必须分优先级
e. 需求一定要分类管理
需求管理的主要工作：
特定目标和特定实践
特定目标
●管理需求
管理需求并识别需求与项目计划和工作产品之间的差
异。
●SP 1.1 取得需求理解
●SP 1.2 取得需求承诺
●SP 1.3 管理需求变更
●SP 1.4 维护需求的双向追溯性
●SP 1.5 识别项目工作与需求间的差异
REQM特定目标的关系
SP 1.1 取得需求理解
SP 1.1 和需求提出者一同来了解需求。
l 识别出谁是需求的提供者
l 识别出需求的接受标准：
a. Clearly and properly stated得到清晰和恰当的定义
b. Complete完整的
c. Consistent with each other相互一致的
d. Uniquely identified得到唯一标识的
e. Appropriate to implement适宜实现
f. Verifiable (testable)可以验证（测试）
g. Traceable可追溯
l 分析需求，确保符合已建立的准则。
l 与需求提供者达到需求共识，以使项目成员能承诺它们SP1.2 获取对需求的承诺
SP1.2 取得项目成员对需求的承诺。
●评估需求对现有承诺的影响。
需求变更或新需求发生时，评估它们对项目成员的影
响。
●协商并记录承诺。
在项目成员对需求或需求改变承诺之前，对现有承诺
的改变应先进行协商。
●承诺的时间点：
a. 需求刚建立时
b. 需求变更时
产出物
●需求影响评估
●需求和需求变更承诺的纪录
●项目组成员工作任务书
SP 1.3 管理需求变更
SP 1.3 当需求在项目执行期间逐渐开发时，管理
需求的变更。
●在项目执行期间，造成需求变更的原因很多：
a. 需要改变
b. 工作进行中产生新需求
●提出需求变更的动机是好的，目的是希望产品更加符合用户的需求。对项目
开发小组而言，变更需求意味着要调整资源、重新分配任务、修改前期工作成果等，开发小组要为此付出较重的代价。如果每次需求变更请求都被采纳的话，这个项目也许永远不能按时完成。
配置变更委员会CCB
●CCB是授权进行正式基线变更的机构
?例如客户需求、设计基线。。。
●职能：
?确保变更被分类以及被评估
?评审和批准变更
?确保只有被批准的变更得到实施
?决定需要实施的变更的优先级
●变更控制活动必须在整个项目中具有可视性
●CCB成员可能包括：项目经理，配置管理员，质量保证人员，开发人员代表，
客户代表。
需求变更的阶段
●提交
●评估
●审批
●实施
●验证
●关闭
产出物
●需求变更申请表
●需求变更汇总表
SP 1.4 维护需求的双向追溯性
●维护需求与项目计划和工作产品间的双向追溯性。
●产出物：
需求跟踪矩阵
需求跟踪矩阵的主要作用
RTM的作用
A、验证需求的可实现性、可测试性
B、进行需求变更的影响分析
C、维护阶段，管理需求的变更
需求跟踪矩阵分为：纵向跟踪和横向跟踪
应该建立哪些需求跟踪矩阵？
●在SEI的调查中达成的基本共识是：纵向跟踪是必须的，如果没有，则REQM
SP1.4无法通过。
●对于纵向跟踪矩阵：
必需的：
?客户需求与产品需求的跟踪
?产品需求与测试用例的跟踪
?100%的接口需求
?全局性需求
?核心需求
并非必需的：
?性能需求
?不影响系统架构的功能需求
需求跟踪矩阵由谁来建立？
●有多个角色参与建立RTM：
a. 需求开发人员
b. 设计人员
c. 测试用例的编写人员
d. PPQA
RTM是否纳入基线管理？
●RTM要纳入基线管理。
●纳入基线后，每次变更都要申请，RTM的变更一般是和其他配置项的变更一
起申请，很少单独申请变更RTM，除非RTM有错误。
●如何简化RTM的工作？
●由于在RTM中，需求可能有很多项，设计、测试用例、代码等都有多项，所
以建立和维护RTM的工作量还是比较大、比较烦琐。对于变化频繁的项目，更是如此。在实践中，为了简化该RTM的建立与维护工作，有的企业仅仅通
过需求与设计、代码、测试用例的编号来实现跟踪，如需求为：r1,r2,……
等编号，而设计的编号为：r1-d1,r1-d2,…….,测试用例的编号为：
r1-t1,r1-t2等等。需要注意的是需求与它们之间是多对多的关系，仅通过编号是无法实现这种关系的。如果不借助DOORS之类的需求管理工具，一般只能通过EXCEL来维护RTM，工作量就
●是比较大。要简化，就要平衡管理的投入与产出。
●当然也可以考虑增大需求、设计、代码、测试用例的颗粒度大小，但是那样
RTM的作用就打了折扣，还是一个平衡问题。
SP1.5 确认项目工作和需求间的差异
主要活动：
●评审项目计划、活动和工作产品是否与需求和需求变更相符。
●识别差异来源及其理由。
●当需求基线有变动时，识别有关计划和工作产品所需的变更。
●启动纠正措施。
识别差距的时机？
●评审时
●变更时
●日常工作中
识别出的不一致问题要有记录，并跟踪问题的关闭需求管理我们需要客户方如何做。
●了解乙方需求变更流程，并与乙方就此流程达成一致
●指定专人负责需求变更
●内部形成一个需求变更流程
●针对内部提交的需求变更，在提交乙方之前横向分析对业务的影响
●在提交乙方之前，内部达成一致意见
●需求变更必将导致乙方开发成本增加，为保证项目成功，必要时追加合同资
金
需求管理（Requirements Management ）是属于CMM2中的过程域，简 称为REQM ，需求开发（Requirements Development ）是CMM3中的过程域，简称RD 。这两个过程域是CMMI 体系中关于需求的全部内容，下面分别对这两部分进行介绍。本文对CMM 的一些基础知识、基础术语不再介绍。 需求管理与需求开发的分界线： 市场营销 用户需求 管理层 需求开发 需求管理 市场 营销 管理层需求变更项目环境 项目变更 大家可以这样理解，需求管理是指对需求变更的管理、对需求的跟踪，而获取需求、定义需求则属于需求开发部分。 需求管理 在CMMI 中，需求管理的目标定义为： a. 把软件需求建立一个基线供软件工程和管理使用。 b. 软件计划、活动和工作产品同软件需求保持一致。 更高的目标： 软件需求的复用
需求管理的原则和方法 a. 必须与需求工程的其他活动紧密整合
b. 需求必须是文档化的、正确的、最新的、可管理的、可理解的 c. 只要需求变化了，需求变更的影响就必须被评估 d. 需求必须分优先级 e. 需求一定要分类管理 需求管理的主要工作： 特定目标和特定实践 特定目标 ●管理需求 管理需求并识别需求与项目计划和工作产品之间的差 异。 ●SP 1.1 取得需求理解 ●SP 1.2 取得需求承诺 ●SP 1.3 管理需求变更 ●SP 1.4 维护需求的双向追溯性 ●SP 1.5 识别项目工作与需求间的差异 REQM特定目标的关系
SP 1.1 取得需求理解 SP 1.1 和需求提出者一同来了解需求。 l 识别出谁是需求的提供者 l 识别出需求的接受标准： a. Clearly and properly stated得到清晰和恰当的定义 b. Complete完整的 c. Consistent with each other相互一致的 d. Uniquely identified得到唯一标识的 e. Appropriate to implement适宜实现 f. Verifiable (testable)可以验证（测试） g. Traceable可追溯 l 分析需求，确保符合已建立的准则。 l 与需求提供者达到需求共识，以使项目成员能承诺它们SP1.2 获取对需求的承诺 SP1.2 取得项目成员对需求的承诺。 ●评估需求对现有承诺的影响。 需求变更或新需求发生时，评估它们对项目成员的影 响。 ●协商并记录承诺。
浅谈敏捷项目管理在软件开发中的应用 摘要：本文先介绍了使用传统项目管理技术管理软件开发项目的方法，然后介绍了使用敏捷项目管理的初步实践，通过两者比较，提出了使用敏捷项目管理进行软件开发的方法。 一、使用传统项目管理技术管理软件开发项目的方法 按照《人月神话》的说法，软件开发是个焦油坑，书店里关于软件开发管理的书籍林良满目，各个软件开发组织也在尝试和应用不同的软件开发管理办法，希望寻找到“软件开发的银弹”。 在软件开发管理中，引入项目管理的办法，已经得到广大软件开发管理人员的一致认同，但对于具体实施何种项目管理办法，各个软件开发组织都有不同的答案，更多的迷茫，因为引入的项目管理办法不能从根本上解决软件开发项目面临的进度拖后、费用超支等问题，软件开发的银弹到底在哪里？ 以下是笔者对国内软件开发组织不同项目管理成熟度的归纳和总结，大概可以分如下几类;1)小作坊、混沌形的，这样的组织还处在接单求生存的阶段，管理者还根本没有项目的意识，以满足客户需求、定制开发和回款为第一要务；2）尝试按照项目管理的思路与方法管理软件开发项目，但发现推
行困难，不得要领，目前很多中小型的软件开发组织都处于这个阶段；3）大型的软件企业，已经通过CMM|ISO认证、有足够的资源做保障，实行规范的项目管理做法，如一些软件外包工厂。 本文主要讲述处于第二个层次的软件开发组织的项目管理问题。软件开发项目管理涉及非常多的内容，从软件开发本身的业务出发，有需求管理、变更控制、配置管理、测试管理、系统分析与设计等；从项目管理的知识领域角度，有范围管理、时间管理、沟通管理、人力资源管理等内容。 按照传统的经典项目管理方法，通过一定的项目管理模板与IT工具，总结多个项目的经验，笔者总结有如下经典步骤来完成项目管理的计划编制与进度控制过程： 计划编制的经典步骤： ①建立企业和项目资源库：这个是进行项目管理的基础工作。 ②设置项目日历、资源日历。 ③设置项目的主要里程碑点。 ④在WBS（工作包）下列出工作清单（Task，Activity）。工作分解结构（WBS）和作业是进行项目范围管理的途径。 ⑤对每个Task估计工期。 ⑥连接每个Task间的逻辑关系（SS，FS，FS，FF，延时）。
软件需求开发与管理 1概述 需求是从系统外部能发现系统所具有的满足于用户的特点、功能及属性等。需求是指明必须实现什么的规格说明。它描述了系统的行为、特性或属性，是在开发过程中对系统的约束。 软件需求工程划分为需求开发和需求管理，其中需求开发可进一步分为问题获取(elicitation)、分析(analysis)、编写规格说明(specification)和验证(verification)四个阶段, 需求开发活动包括以下几个方面： (1)确定产品所期望的用户类 (2)获取每个用户类的需求 (3)了解实际用户任务和目标以及这些任务所支持的业务需求 (4)分析源于用户的信息以区别用户任务需求、功能需求、业务规则、质量属性、建议解决 方法和附加信息 (5)将系统级的需求分为几个子系统，并将需求中的一部分分配给软件组件 (6)了解相关质量属性的重要性 (7)商讨实施优先级的划分 (8)将所发现的用户需求编写成规格说明和用例模型 (9)评审用例和需求规格说明，确保对用户需求达到共同的理解与认识，并在整个开发小组 接受说明之前将问题都弄清楚。 需求管理活动包括以下几个方面： (1)定义需求基线(迅速制定需求文档的主体) (2)评审提出的需求变更、评估每项变更的可能影响从而决定是否实施它 (3)以一种可控制的方式将需求变更融入到项目中 (4)使当前的项目计划与需求一致 (5)估计变更需求所产生的影响并在此基础上协商新的承诺。 (6)让每项需求都能与其对应的设计、源代码和测试用例联系起来以实现跟踪 (7)在整个项目过程中跟踪需求状态及其变更情况。 2需求工程的推荐方法 需求工程推荐方法 需求开发
软件项目管理常见问题及解决方案资料来源:互联网整理人:class4117 软件行业是一个极具挑战性和创造性的行业, 软件开发是一项复杂的系统工程, 牵涉到各方面的因素, 在实际工作中, 经常会出现各种各样的问题, 甚至面临失败。如何总结、分析失败的原因,得出有益的教训,对一个公司来说,是在今后的项目中取得成功的关键。 1 .项目管理在软件开发中的应用的成因 目前我国大部分软件公司,无论是产品型公司还是项目型公司,都没有形成完全适合自己公司特点的软件开发管理模式, 虽然有些公司根据软件工程理论建立了一些软件开发管理规范,但并没有从根本上解决软件开发的质量控制问题。这样导致软件产品质量不稳定, 软件后期的维护、升级出现麻烦, 同时最终也会损害用户的利益。 2. 软件项目管理常见问题及解决方案 (1缺乏项目管理系统培训 在软件企业中, 以前几乎没有专门招收项目管理专业的人员来担任项目经理, 被任命的项目经理主要是因为他们能够在技术上独当一面, 而管理方面特别是项目管理方面的知识比较缺乏。 解决方案:项目经理接受系统的项目管理知识培训是非常必要的, 有了专业领 域的知识与实践, 再加上项目管理知识与实践和一般管理的知识和经验的有机结合,必能大大提高项目经理的项目管理水平。 (2项目计划意识问题 项目经理对总体计划、阶段计划的作用认识不足, 因此制定总体计划时比较随意, 不少事情没有仔细考虑; 阶段计划因工作忙等理由经常拖延, 造成计划与控制管理脱节,无法进行有效的进度控制管理。
解决方案:计划的制定需要在一定条件的限制和假设之下采用渐近明细的方式进行不断完善。提高项目经理的计划意识, 采用项目计划制定相关知识、技术、 工具,加强对开发计划、阶段计划的有效性进行事前事后的评估。 (3管理意识问题 部分项目经理不能从总体上把握整个项目, 而是埋头于具体的技术工作, 造成 项目组成员之间忙的忙、闲的闲,计划不周、任务不均、资源浪费。有些项目经理没有很好的管理方法,不好安排的工作只好自己做,使项目任务无法有效、合理地分配给相关成员,以达到“负载均衡”。 解决方案:加强项目管理方面的培训,并通过对考核指标的合理设定和宣传引导项目经理更好地做好项目管理工作。技术骨干在担任项目经理之前, 最好能经过系统的项目管理知识,特别是其中的人力资源管理、沟通管理的学习, 并且在实际工作中不断提高自己的管理素质, 丰富项目管理经验, 提高项目管理意识。 (4沟通意识问题 在项目中一些重要信息没有进行充分和有效的沟通。在制定计划、意见反馈、情况通报、技术问题或成果等方面与相关人员的沟通不足, 造成各做各事、 重复 劳动,甚至造成不必要的损失 ; 有些人没有每天定时收邮件的习惯,以至于无法 及时接收最新的信息。 解决方案:制定有效的沟通制度和沟通机制, 提高沟通意识 ; 采取多种沟通方式, 提高沟通的有效性。通过制度规定对由于未及时收取邮件而造成损失的责任归属 ; 对于特别重要的内容要采用多种方式进行有效沟通以确保传达到位, 例如:除发送 邮件外还要电话提醒、回执等, 重要的内容还要通过举行各种会议进行传达。 (5风险管理意识问题
产品需求分析管理和产品规划培训课程 课程背景 营销大师科特勒指出：“以市场为导向、以客户为中心”就是对市场需求的管理！市场需求管理是公司战略、市场计划、新产品开发的依据，决定了公司竞争力的延续，直接影响到公司效益。 但是：“有价值的客户需求在哪里，对有价值的需求如何进行汇总、分析。”目前大量的理论体系到此为止，如何在实际的操作层面上进行下去？如何执行？根据权威机构统计：项目缺陷的56％来源于需求定义错误，80％的缺陷修复成本用于修复需求导致的错误，需求的正确与否直接影响产品开发周期、产品开发成本，甚至直接决定产品最终的市场成败。 通过和众多国内科技企业接触，我们发现这些企业中普遍存在如下问题： 1.缺少完备的需求收集、汇总、分析机制，“公司神经末梢与大脑失去联系”； 2.产品开发过程需求工作持续时间短，需求分析不充分；需求没有有效地分层分级，对不同阶段需求应该详细到什么程度没有明确的定义； 3.需求的表达不够结构化，充斥着“故事会”格式的需求，直接影响了不同团队对需求理解一致性； 4.产品开发闭门造车，关注技术，不关注客户； 5.产品开发出来才找客户、找卖点； 6.不清楚业界众多需求分析工具如何在不同需求分析阶段进行恰当运用等； 本课程结合以上企业在市场需求管理中存在的问题进行深入的探讨，结合多年企业的实践和研发管理咨询的案例，就企业在市场需求的收集、整理、归类、分析、分解与分配、执行与验证等环节的问题展开深入的讲解，并分享大量企业的案例。 课程特色 课程的实践性：讲师从事过市场需求管理的工作多年，同时完成过近10个咨询项目，通过大量的案例和演练，让学员非常便于理解；具体的操作方法和工具：课程涉及的市场需求分析和市场需求管理的方法和工具十分具体，操作性非常强；讲师独特的专业背景：讲师都是从研发做起，在知名企业担任研发中高层领导，并且在成功的企业有成功的实践经验。 培训收益 1.了解研发需求工程过程与其他研发流程体系的接口关系； 2.掌握从市场角度进行有效的客户需求收集的机制和方法，筛选高质量的客户需求； 3.掌握对客户需求进行整理、分类、分析的方法，提高各个角色对需求理解的一致性，最终形成产品包需求，明确产品的竞争优势与卖点； 4.掌握外部需求和内部需求一体化管理的机制，从而降低产品的端到端生命周期成本； 5.掌握对产品包需求进行分解和分配，确保需求与设计协同一致，减少模块间耦合的方法； 6.掌握对客户需求、产品包需求、设计需求进行持续验证和跟踪的机制和方法； 7.掌握构建需求收集长效机制，提升公司整体需求管理能力的机制和方法； 8.掌握支撑研发需求工程各个阶段工作运作的工具和操作方法。 课程大纲 一、例分析：某案例公司市场之路
需求开发和管理流程范例 目录 1.目的 (3) 2.适用范围 (3) 3.名词和缩略语 (3) 4.角色和职责 (3) 5.过程综述 (5) 5.1. 流程图 (5) 5.2. 过程说明 (5) 6.过程活动 (6) 6.1. 活动一：获取用户需求 (6) 6.2. 活动二：建立系统需求 (7) 6.3. 活动三.需求分析与建模 (9) 6.4. 活动四.形成需求规格说明 (10) 6.5. 活动五.需求验证 (11) 6.6. 活动六：需求变更 (12) 6.7. 活动七：需求跟踪 (12) 7.过程度量与改进 (15) 8.过程裁剪指南 (15) 9.相关文件 (15)
10.质量记录 (16) 11.附录 (17) 11.1. 附录1：需求优先级说明 (17) 11.2. 附录2：需求状态说明 (17)
1.目的 本程序文件定义了本组织的需求与管理的过程，目的是实现有计划地收集、分析顾客的需求，并保证所有共利益者在项目进展过程中始终保持对需求一致的理解和承诺。 2.适用范围 本过程适用于公司所有合同项目和自主研发项目。 3.名词和缩略语 4.角色和职责
5.1.流程图 5.2.过程说明 需求开发与管理过程包括首先获取用户需求，然后对用户需求进行分类和整理，形成系统需求。通过对系统需求进行分析和建模，形成需求规格说明书，并将分析后的需求以模型或原型方法与用户进行确认，以此建立设计开发基础。最后采用原型、测试验证、评审等方式验证需求。同时，在开发活动中有序的管理需求变更，并通过需求跟踪确保需求的可追溯性和一致性。
6.1.活动一：获取用户需求 通过与用户交流、对现有系统的了解以及对项目任务的分析，开发、捕获和修订用户的需要。 6.1.1.进入准则 经过市场扫描活动、售前支持、客户反馈等活动，产品经理经过基本分析，确定要进行某产品的开发和较大升级； 6.1.2.输入 市场分析报告、售前和售后服务相关记录 6.1.3.任务 任务1：产品市场扫描。市场服务部会同产品经理针对特定产品进行市场扫描工作，主要包括与该产品相关的其他产品的名称、主要功能、市场情况；产品的领域，相关标准情况；产品主要涉及的技术领域和技术发展概况。产品经理根据市场扫描的结果确认是否需要进行产品开发和升级。 任务2：需求调研。产品经理根据《需求调研规程》组织相关人员实施需求调研活动，形成相关调研记录和《需求特性列表》。评审小组对调研结果实施结构化审查。 任务3：产品路线图设计。产品经理根据产品的需求特性列表和市场情况初步确定产品功能特性的优先级，优先级划分参见附录1，并且将优先级的划分与高级经理进行沟通，得到初步的确定后，对需求特性列表按照优先级进行分类整理，形成《产品路线图》。 对于项目而言，此任务可以演化成考虑项目分阶段实施的需求划分。 6.1.4.输出 《需求特性列表》、《产品路线图》 6.1.5.退出准则 《需求特性列表》通过审核，与高级经理沟通后初步明确项目经理
软件开发项目管理 ?启动阶段 这个阶段的工作目的是决定一个项目是否需要启动。为了达到这个目的，首先要明确项目的总体战略目标，对项目的需要建立认同。即确定到底需要做什么、开发什么产品或提供什么服务，以及需要解决什么样的问题和需要满足客户或市场的什么要求等，同时还要总结项目工作的范围、所需资源、大约开支、各种风险，以及该项目不执行的其他替代选择等。这些代表了对整个项目目标从战略角度和宏观层次所进行的分析，通过项目的意向书总结出来，由此确证客户或项目发起人和赞助者的要求与期望，并帮助他们判定项目是否上马。项目意向总结书的通过及项目被批准上马形成了这个项目的起始点。 ?计划阶段 这个阶段的工作是为整个项目做计划。项目开始后，首先要确定项目的具体范围，明确定出项目到底要做什么，总结、归纳并定出产品的功能。然后进一步制定项目的计划，列出每项具体工作，并建立所有工作任务的重要性及顺序；确定每项工作的执行人和所需资源；根据人员的配置和能力设定各项工作和整个项目的完成时间表。 ?执行阶段 这个阶段的工作是通过执行项目的计划来完成项目的任务。它包括落实一切所需资源，如：人员、设备、费用、技术、信息，由管理者领导全体项目参与者开展各项工作。同时跟踪各项具体工作和整个项目的进度，定期向全体项目人员及项目的发起人报告项目状态。 ?控制阶段 这个阶段的工作是确证项目工作的结果符合项目的计划。它通过对项目结果的衡量和审核，与项目计划所期望的结果进行比较，找出实际结果与计划的差别，并制定处理措施。这个阶段的工作还包括对项目进程中出现的任何更改要求进行审核和批准。同时调解项目进程中出现的各种问题，如：对缺乏的资源的补偿调节；对项目的进度表及各项具体工作的优先级或顺序的修订。 ?结束阶段 这个阶段的工作是确保项目的最终结果或提交物达到计划的要求，并对完成的结果作可接受的确认。还包括在项目完成之后的收尾工作，对整个项目的经历进行总结，修订项目文档，用户培训等。
软件项目的需求开发与管理需求开发与管理是软件项目中一项十分重要的工作，据调查显示在众多失败的软件项目中，由于需求原因导致的约占到45%，因此，需求工作将对软件项目能否最终实现产生至关重要的影响。虽然如此，在项目开发工作中，很多人对需求的认识还远远不够，从本人参与或接触到的一些项目来看，小到几十万元，大到上亿元的软件项目的需求都或多多少的存在问题，有的是开发者本身不重视原因、有的是技术原因、有的是人员组织原因、有的是沟通原因、有的是机制原因，以上种种原因都表明做好软件需求开发是一项系统工作，而不是简单的技术工作，只有系统的了解和掌握需求的基本概念、方法、手段、评估标准、风险等相关知识，并在实践中加以应用，才能真正做好需求的开发和管理工作。 本文将通过介绍关于软件需求的基本知识和个人在实际工作中总结的一些经验，帮助读者了解软件需求，学习需求开发的一些基本方法，避免因需求原因而导致的项目失败。 1? 什么是软件需求和需求工程 软件需求的定义 在IEEE软件工程标准词汇表(1997年)中定义软件需求为： （1）用户解决问题或达到目标所需的条件或能力。 （2）系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力。（3）一种反映上面(1)或(2)所描述的条件或权能的文档说明。 实通俗的讲，“需求”就是用户的需要，它包括用户要解决的问题、达到的目标、以及实现这些目标所需要的条件，它是一个程序或系统开发工作的说明，表现形式一般为文档形式。 需求工程的定义 需求分析的过程，也叫做需求工程和需求阶段，它包括了需求开发和需求管理两个部分。需求开发是指从情况收集、分析和评价到编写文档、评审等一系列产生需求的活动，分为四个阶段：情
研发部需求开发流程管理
管理目标 1、所有关系人清晰明确地了解项目的需求和 期望，努力做到满足项目所有关系人的不同需求；项目关系人包括：项目团队成员和项目团队外(内部/外部客户，内部/外部合作伙伴，经销商/客户等)。 2、项目管理三要素平衡（时间/成本/质量）， 即开发项目按需按时按质的完成。 3、目标：功能满足需求，设计支持变化，开发 快速迭代，成果持续交付。 执行概述 1、建立有效的工作流程保证项目的顺利进行， 初期使用传统RUP过程，引入部分敏捷方法，团队磨合完成后逐步实现敏捷开发全流程管理。 2、明确项目目标，制定具有可行性的项目计 划，有效明确的分解项目需求。 3、跟踪设计/开发/测试/回归/发布全流程，推 动项目按预定计划执行。 4、解决项目过程中出现的问题和冲突，一般集
中在需求不明/工作量或时长/开发难度/跨 部门协调等几个方面。 5、调动开发团队的积极性，创造力，推动团队 成员在项目过程中的学习成长。 6、风险识别、风险控制以及风险的预案。 项目管理 1、需求阶段 对项目进行技术可行性分析、技术评估、成本评估以及风险评估。 与需求提出方的代表进行需求讨论，明确项目的目标、价值。 确定项目范围、功能及优先级。 组建项目团队，特别要搞清楚项目的关键人。 项目启动会议，相关的关系人都必须参加。 2、设计阶段 根据确认后的软件需求规格说明书，制定项目进度计划，工作任务分解(WBS)；资源申请，项目涉及到的开发资源、测试资源、设计资源(包括人员和软硬件资源)；数据库设计；系统
设计；文档(包括系统用例、Demo、测试用例等)；评审会议。 设计阶段结果交付一般为系统用例/系统原型/系统设计文档(概要设计和详细设计)/数据库设计文档等。 该阶段交付成果需要进行评审。 3、执行阶段(开发和测试) 准备开发环境、测试环境。 跟踪，推动项目按计划进行。 项目成员以日报/项目负责人以周报的形式通报各关系人当前项目的进展情况。 按里程碑对阶段成果进行评估，以确保该阶段完成的质量。 代码审核，包括CS审核、SQL审核、WEB 审核等。 对需求变更进行控制管理。 测试阶段BUG响应及改进、收集反馈意见。 对项目风险进行管理。 4、发布阶段 包括制定项目发布计划，用户培训，发布上
软件项目管理常见问题及解决方案 摘要:Web技术的网上学习系统提供了实施研究性学习的环境与技术手段。基于研究性学习 模式理念,探讨在网上学习系统中如何实现研究性学习。给出研究性学习模式形式,以及网上研究性学习系统的设计方案。 关键词:Web;研究性学习;教学网站 软件行业是一个极具挑战性和创造性的行业,软件开发是一项复杂的系统工程,牵涉到各方面的因素,在实际工作中,经常会出现各种各样的问题,甚至面临失败。如何总结、分析失败的原因,得出有益的教训,对一个公司来说,是在今后的项目中取得成功的关键。 1.项目管理在软件开发中的应用的成因 目前我国大部分软件公司,无论是产品型公司还是项目型公司,都没有形成完全适合自己公司特点的软件开发管理模式,虽然有些公司根据软件工程理论建立了一些软件开发管理规范,但并没有从根本上解决软件开发的质量控制问题。这样导致软件产品质量不稳定,软件后期的 维护、升级出现麻烦,同时最终也会损害用户的利益。 随着软件开发的深入、各种技术的不断创新以及软件产业的形成,人们越来越意识到软件过 程管理的重要性,管理学的思想逐渐融入软件开发过程中,应用开发的项目管理日益受到重视。 2.软件项目管理常见问题及解决方案 (1)缺乏项目管理系统培训 在软件企业中,以前几乎没有专门招收项目管理专业的人员来担任项目经理,被任命的项目经理主要是因为他们能够在技术上独当一面,而管理方面特别是项目管理方面的知识比较缺乏。解决方案:项目经理接受系统的项目管理知识培训是非常必要的,有了专业领域的知识与实践,再加上项目管理知识与实践和一般管理的知识和经验的有机结合,必能大大提高项目经理的 项目管理水平。 (2)项目计划意识问题 项目经理对总体计划、阶段计划的作用认识不足,因此制定总体计划时比较随意,不少事情没有仔细考虑;阶段计划因工作忙等理由经常拖延,造成计划与控制管理脱节,无法进行有效的 进度控制管理。 解决方案:计划的制定需要在一定条件的限制和假设之下采用渐近明细的方式进行不断完善。提高项目经理的计划意识,采用项目计划制定相关知识、技术、工具,加强对开发计划、阶段计划的有效性进行事前事后的评估。 (3)管理意识问题 部分项目经理不能从总体上把握整个项目,而是埋头于具体的技术工作,造成项目组成员之间忙的忙、闲的闲,计划不周、任务不均、资源浪费。有些项目经理没有很好的管理方法,不好安排的工作只好自己做,使项目任务无法有效、合理地分配给相关成员,以达到“负载均衡”。 解决方案:加强项目管理方面的培训,并通过对考核指标的合理设定和宣传引导项目经理更好地做好项目管理工作。技术骨干在担任项目经理之前,最好能经过系统的项目管理知识,特别是其中的人力资源管理、沟通管理的学习,并且在实际工作中不断提高自己的管理素质,丰富 项目管理经验,提高项目管理意识。
产品需求分析与需求管理——如何搞定市场需求 主讲：董奎（十多年高科技企业的研发与管理实践经验，在某著名高科技企业工作期间，先后担当项目经理、系统工程师、产品经理、软件部经理） 课程对象：企业CEO/总经理、研发总监、研发经理/项目经理/技术经理/产品经理、产品规划专家等。 授课方式：讲师讲授+视频演绎+案例研讨+角色扮演+讲师点评。 【课程背景】 通过和众多国内科技企业接触，发现这些企业中普遍存在： 1、技术很牛，但最终倒闭的公司一大推；被技术人员嗤之以鼻的公司，反而活的还不错 2、研发从早忙到晚，产品开发的不少，但市场成功的产品屈指可数，开发的越多，死得越快 3、产品开发闭门造车，关注技术，不关注客户；产品开发出来才找客户、找卖点 4、了解市场的不懂技术，懂技术的不了解市场，不知道需求应该谁负责 5、需求准确把握决定产品成败，但没有人关注需求，即使偶尔想关注也不知道如何关注 6、需求的表达不够结构化，充斥着“故事会”格式的需求，直接影响了不同团队对需求理解的一致性 7、缺少完备的需求收集、汇总、分析机制，“公司神经末梢与大脑失去联系” 8、不能从自身能力提升来引导客户需求，反而天天在抱怨客户需求经常变动 9、针对需求大家“吵成一锅粥”：公司与客户吵，市场与开发吵，开发与测试吵，…… 不能满足客户需求、给客户创造价值，再牛的技术也没有价值。根据权威机构统计项目缺陷的56%来源于需求定义错误，80%的缺陷修复成本用于修复需求导致的错误，把技术变成金钱的不二选择关注、锁定、满足市场需求，创造客户价值。【课程重点】 1、如何确定目标客户，如何分析需求关系人？
2、如何从市场（客户）角度进行有效的客户需求收集？ 3、围绕产品成功2个核心因素差异化+成本优势，整理产品需求 4、如何对客户需求进行整理和分析，形成产品包需求？ 5、如何基于产品需求与竞争友商对比分析，确定我们的核心诉求，形成产品概念？ 课程贯穿案例分享，详细讲解目标客户?客户要求?客户需求?产品包需求?产品概念确定全过程，详细讲解把技术转变为金钱的方法和工具（利润区、回溯分析、决策模型分析、KJ、$APPEALS、BSA、概念定义7个核心秘诀、破坏性创新的3石蕊实验、SweetPoint模型、基于不同产品生命周期的12个创新思路等），提升产品的竞争力，确保市场成功、财务成功。 【课程价值】 1、掌握从市场角度进行有效的客户需求收集的机制和方法，筛选高质量的客户需求； 2、掌握对客户需求进行整理、分类、分析的方法，提高各个角色对需求理解的一致性，最终形成产品包需求，明确产品的竞争优势与卖点； 3、掌握外部需求和内部需求一体化管理的机制，从而降低产品的端到端生命周期成本； 4、掌握产品核心诉求的提炼方法，确定有吸引力的产品概念； 5、掌握支撑研发需求工程各个阶段工作运作的工具和操作方法； 【培训内容】 一、案例分享 二、六个基本概念 1、什么是客户？ 1)客户、用户、目标客户、潜在客户、可以送给竞争友商的毒药客户 2、什么是需求？ 1)WANTS/NEEDS/DEMANDS、真假需求、客户需求、用户需求、产品需求、设计需求、需求规格、技术需求、非技术需求 2)案例：某运营上广告折射对需求五层次的理解 3、需求工作的2个基本点：
精心整理 管理目标 1、所有关系人清晰明确地了解项目的需求和期望，努力做到满足项目所有关系人的不同需求；项目关系人包括：项目团队成员和项目团队外(内部/外部客户，内部/外部合作伙伴，经销商/客户等)。 2、项目管理三要素平衡（时间/成本/质量），即开发项目按需按时按质的完成。 3、目标：功能满足需求，设计支持变化，开发快速迭代，成果持续交付。 执行概述 1、 2、 3、跟踪设计/开发/测试/回归/ 4、/跨部门协 调等几个方面。 5、 6、风险识别、风险控制以及风险的预案。 项目管理 1、需求阶段 2 根据确认后的软件需求规格说明书，制定项目进度计划，工作任务分解(WBS)；资源申请，项目涉及到的开发资源、测试资源、设计资源(包括人员和软硬件资源)；数据库设计；系统设计；文档(包括系统用例、Demo、测试用例等)；评审会议。 设计阶段结果交付一般为系统用例/系统原型/系统设计文档(概要设计和详细设计)/数据库设计文档等。 该阶段交付成果需要进行评审。 3、执行阶段(开发和测试) 准备开发环境、测试环境。
跟踪，推动项目按计划进行。 项目成员以日报/项目负责人以周报的形式通报各关系人当前项目的进展情况。 按里程碑对阶段成果进行评估，以确保该阶段完成的质量。 代码审核，包括CS审核、SQL审核、WEB审核等。 对需求变更进行控制管理。 测试阶段BUG响应及改进、收集反馈意见。 对项目风险进行管理。 4、发布阶段 包括制定项目发布计划，用户培训，发布上线。 5、试运行阶段 数据监控(日志、服务器状态) 定情况执行补丁升级。 6、收尾阶段 产品交付，项目总结会。 常见问题 1、开发时间的估算 算，通常单个模块开发时间取决于以下因素： 1 2(包括对框架和应用的熟悉程度)。 3 开发者没有相关的代码可以参考，自己也没有经验， 1、在划分好模块后，首先项目管理人员预先估算各个模块所需要的开发时间。 2、召集所有开发人员，讨论模块的分配和开发时间估算。将划分好的模块，分配给开发人员，如状况允许可允许开发人员自主选择以提高开发人员的主动性和参与性。分配模块的时为确保开发的速度和质量，基本原则如下： A、类似的模块由同一人负责开发，比如用户信息的增删改应由同一开发者负责。这样开 发者对相关逻辑会比较熟悉，代码/接口的定义也会相对明确，沟通的成本低，相应可以降低功能实现的缺陷概率。 B、技术难度较大的模块由技术水平比较高的人负责。 C、业务逻辑比较复杂的由对业务逻辑比较了解的人负责。
软件公司研发项目管理制度 第一节总则 第一条为规范自有软件研发以及外包软件的管理工作，特制定本制度。本制度适用 于公司软件研发与管理。 第二条本制度中软件开发指新系统开发和现有系统维护或改造，此类工作均需要以项 目制管理。 第三条本制度中自行开发是指主要依赖公司自身的管理、业务和技术力量进行系统 设计、软件开发、集成和相关的技术支持工作，一般仅向外购置有关的硬件设备和支撑软件平台；合作开发是公司与专业IT公司（合作商）共同协作完成IT应用的项目实施和技术支持工作，一般形式是公司负责提供业务框架，合作商提供技术框架，双方组成开发团队进行项目实施，IT系统的日常支持由技术研发部承担；外包开发是指将IT应用项目的设计、开发、集成、培训等任务承包给某家专业公司（可以是专业的IT公司或咨询公司等），由该公司（承包商）负责应用项目的实施。? 第四条 ?软件开发遵循项目管理和软件工程的基本原则。项目管理涉及立项管理、项目计划和监控、配置管理、合作开发管理和结项管理。软件工程涉及需求管理、系统设计、系统实现、系统测试、用户接受测试、试运行、系统验收、系统上线和数据迁移。 第五条 除特别指定，本制度中项目组包括业务组（或需求提出组）、开发组（可能包括网络管理员和合作开发商）。 第二节立项管理 第六条 提出项目需求的部门参与公司层面立项，进行立项的技术可行性分析，编写《立项分析报告》，开展前期筹备工作。《立项分析报告》应明确项目的范围和边界。 第七条 需求提出部门将立项分析报告》交相关部门会签后，上交公司高层进行立项审批，以保证系统项目与公司整体策略相一致。 第八条 《立项分析报告》得到批准后，成立项目组（如果是外包开发，则成立外包商项目组； 如果是合作开发，则与外包商共同成立合作开发项目组，以下统称“项目组”），项目组应包括业务组（由公司技术研发部需求管理组和相关业务部门组成）和开发组（自行开发为技术研发部开发组、网络管理员；外包开发为技术研发部指定的开发组长、网络管理员和外包商成员；合作开发为技术研发部开发组指定人员、网络管理员和外包商成员）。公司技术研发部委派一名项目经理负责监督项目的进度，进行项目管理工作，确保开发能及时完成并能满足业务需要。项目组人员的选择应满足项目对业务及技术要求，项目组人员应有足够的业务和IT技术方面的专业知识来胜任项目各方面的工作。 第三节需求分析
密级：普通 标识:S_RD_XQKFYGLGC 版本号：2.0 分册：第1册/共1册 需求开发与管理过程 湖南创博龙智信息科技股份有限公司 湖南创博龙智信息科技股份有限公司对本文件资料享受著作权及其它专属权利，未经书面许可不得将该等文件资料（其全部或任何部分）披露予任何第三方，或进行修改后使用。
文件更改摘要：
目录 1.目的/方针 (3) 2.范围 (3) 3.术语 (3) 4.角色与职责 (3) 5.入口准则 (3) 6.输入 (3) 7.流程图 (4) 8.主要活动 (4) 8.1.需求获取 (4) 8.1.1.明确所需获取信息的来源与渠道（Where） (5) 8.1.2.获取需求（How） (5) 8.1.3.需求获取资料的保管 (7) 8.1.4.编写用户需求规格说明书 (7) 8.2.需求分析 (7) 8.2.1.结构化分析方法 (7) 8.2.2.基于用例的分析方法 (8) 8.3.需求定义 (9) 8.3.1.定义需求的优先级 (9) 8.3.2.编写《需求分析说明书》 (10) 8.4.需求确认 (10) 8.4.1.需求评审 (10) 8.4.2.需求承诺 (11) 8.4.3.建立需求基线 (11) 8.5.需求变更 (11) 8.5.1.需求变更申请................................................................. 错误！未定义书签。 8.5.2.需求变更的实施 (12) 8.6.需求跟踪 (12) 8.6.1.建立需求跟踪矩阵 (12) 8.6.2.需求跟踪矩阵的维护与使用 (12) 9.输出 (12) 10.出口准则 (13) 11.资源 (13) 12.引用文档 (13)
软件项目管理的研究及在项目开发中的应用 针对软件项目开发的特点和软件开发包项目高失败率的善通过对软件项目管理方法的研究提出了软件项目开发过程的一种管理流程和相应的子流程，实现了对软件项目控制和管理。前言 软件项目管理是为了使软件项目能够按照预定的成本、进度、质量顺利完成，而对成本、人员、进度、质量、风险等进行分析和管理的活动。实际上, 软件项目管理的意义不仅仅如此，进行软件项目管理有利于将开发人员的个人开发能力转化成企业的开发能力，企业的软件开发能力越高，表明这个企业的软件生产越趋向于成熟，企业越能够稳定、持续地发展。 软件项目管理的特殊性表现在：①软件产品是无形的。软件项目管理者不能像其他项目管理者那样，能够从被开发的产品上看到进度、已经完工的部分 是否与设计相符等，他们只能从其他人所提交的文档中来掌握相关的情况。② 没有标准的软件过程。对软件过程的理解虽然已经取得了长足的进步，但是软 件管理者还是不能确切地预见某一软件过程何时有可能出现问题。③大型软件 项目常常是一次性的”。由于软件项目与一个国家、地区的经济政策相联系, 与用户的发展战略、经济实力、管理水平相适应，软件项目的开发过程中所采用的技术和管理方式与当时的计算机和通信技术有关，因此大型软件项目一般都不同于早先的项目，管理者纵使有在计划中降低不确定性的经验，也很难较准确地预见问题的出现，以前的经验教训也较难在新项目中发挥大的作用。 从目前国内外的软件企业来看，软件危机”的阴影仍然存在，软件行业的项目实施情况一直很不乐观。研究表明，软件项目失败的原因主要有两个: 是应用项目的复杂性；二是缺乏合格的软件项目管理人才。实践证明，缺乏有效的项目管理是导致软件项目失控的直接原因。
产品需求分析与需求管理 －－如何搞定市场需求通过和众多国内科技企业接触，发现这些企业中普遍存在： 1. 技术很牛，但最终倒闭的公司一大推；被技术人员嗤之以鼻的公司，反而活的还不错 2. 研发从早忙到晚，产品开发的不少，但市场成功的产品屈指可数，开发的越多，死得越快 3. 产品开发闭门造车，关注技术，不关注客户；产品开发出来才找客户、找卖点 4. 了解市场的不懂技术，懂技术的不了解市场，不知道需求应该谁负责 5. 需求准确把握决定产品成败，但没有人关注需求，即使偶尔想关注也不知道如何关注 6. 需求的表达不够结构化，充斥着“故事会”格式的需求，直接影响了不同团队对需求理解的一致 性 7. 缺少完备的需求收集、汇总、分析机制，“公司神经末梢与大脑失去联系” 8. 不能从自身能力提升来引导客户需求，反而天天在抱怨客户需求经常变动 9. 针对需求大家“吵成一锅粥”：公司与客户吵，市场与开发吵，开发与测试吵，…… 不能满足客户需求、给客户创造价值，再牛的技术也没有价值。根据权威机构统计项目缺陷的56%来源于需求定义错误，80%的缺陷修复成本用于修复需求导致的错误，把技术变成金钱的不二选择关注、锁定、满足市场需求，创造客户价值。 本课程重点讲解： 1. 如何确定目标客户，如何分析需求关系人？ 2. 如何从市场（客户）角度进行有效的客户需求收集？ 3. 围绕产品成功2个核心因素差异化+成本优势，整理产品需求 4. 如何对客户需求进行整理和分析，形成产品包需求？ 5. 如何基于产品需求与竞争友商对比分析，确定我们的核心诉求，形成产品概念？ 课程贯穿案例分享，详细讲解目标客户→客户要求→客户需求→产品包需求→产品概念确定全过程，详细讲解把技术转变为金钱的方法和工具（利润区、回溯分析、决策模型分析、KJ、$APPEALS、BSA、概念定义7个核心秘诀、破坏性创新的3石蕊实验、Sweet Point模型、基于不同产品生命周期的12个创新思路等），提升产品的竞争力，确保市场成功、财务成功。 一、案例分享 二、六个基本概念 1. 什么是客户？ 1) 客户、用户、目标客户、潜在客户、可以送给竞争友商的毒药客户 2. 什么是需求？ 1) WANTS/NEEDS/DEMANDS、真假需求、客户需求、用户需求、产品需求、设计需求、需 求规格、技术需求、非技术需求 2) 案例：某运营上广告折射对需求五层次的理解 3. 需求工作的2个基本点： 1) 差异化 2) 成本优势 4. 需求工程全过程： 1) 需求收集→需求整理→需求分析→概念确定→需求分解→需求实现与验证 5. 官方体系对需求的定义： 1) RM（目的、关键实践、典型输出） 2) RD（目的、关键实践、典型输出） 6. 产品经理3个核心素质特征：
Req. Development & Mgt. Process 需求开发与管理过程 Prep分配需求ed by 拟制陈刚 Date 日期 2006-05-16 Reviewed by 评审人SEPG team Date 日期 2007-4-20 Approved by 批准田松涛 Date 日期 2007-4-24
Revision Record 修订记录
Table of Contents 目录 1Purpose 目的 (5) 2Scope 范围 (5) 3Abbreviations and Acronyms 术语和缩略语 (5) 4Policy 方针 (5) 5Process Description 过程描述 (5) 5.1Roles and Responsibilities 角色和职责 (6) 5.2Entrance Criteria 入口准则 (6) 5.3Input 输入 (6) 5.4Activities 活动 (6) 5.4.1Summarize 总述 (6) 5.4.2Flow Chart 流程图 (7) 5.4.3Requirements Development and Validation 需求开发及确认 (8) 5.4.4Trace Requirements and Requirements Management 需求跟踪和管理 (10) 5.5Output 输出 (11) 5.6Exit Criteria 出口准则 (11) 6Resource and Tools 资源与工具 (11) 7Configuration Management and Assets 配置管理和资产 (11) 8Training 培训 (11) 9Process Measurement 过程度量 (11) 10Tailoring Guidelines 裁剪指南 (12) 11Verification 验证 (12) 12Related Process 相关过程 (12) 13Reference Materials 参考文献 (12)
需求开发与管理是软件项目中一项十分重要的工作，据调查显示在众多失败的软件项目中，由于需求原因导致的约占到45%，因此，需求工作将对软件项目能否最终实现产生至关重要的影响。虽然如此，在项目开发工作中，很多人对需求的认识还远远不够，从本人参与或接触到的一些项目来看，小到几十万元，大到上亿元的软件项目的需求都或多多少的存在问题，有的是开发者本身不重视原因、有的是技术原因、有的是人员组织原因、有的是沟通原因、有的是机制原因，以上种种原因都表明做好软件需求开发是一项系统工作，而不是简单的技术工作，只有系统的了解和掌握需求的基本概念、方法、手段、评估标准、风险等相关知识，并在实践中加以应用，才能真正做好需求的开发和管理工作。 本文将通过介绍关于软件需求的基本知识和个人在实际工作中总结的一些经验，帮助读者了解软件需求，学习需求开发的一些基本方法，避免因需求原因而导致的项目失败。 1 什么是软件需求和需求工程 1.1 软件需求的定义 在IEEE软件工程标准词汇表(1997年)中定义软件需求为： （1）用户解决问题或达到目标所需的条件或能力。 （2）系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力。 （3）一种反映上面(1)或(2)所描述的条件或权能的文档说明。实通俗的讲，“需求”就是用户的需要，它包括用户要解决的问题、达到的目标、以及实现这些目标所需要的条件，它是一个程序或系统开发工作的说明，表现形式一般为文档形式。 1.2 需求工程的定义 需求分析的过程，也叫做需求工程和需求阶段，它包括了需求开发和需求管理两个部分。需求开发是指从情况收集、分析和评价到编写文档、评审等一系列产生需求的活动，分为四个阶段：情况获取、分析、制订规格说明和评审。这四个阶段不一定是遵循线性顺序的，他们的活动是相互独立和反复的。需求管理是软件项目开发过程中控制和维持需求约定的活动，它包括：变更控制、版本控制、需求跟踪、需求状态跟踪等工作。 2 需求分析的风险 由于需求分析的参与人员、业务模式、投资、时间等客观因素的影响和需求本身具有主观性和可描述性差的特点，因此，需求分析工作往往面临着一些潜在的风险。这些风险主要表现在： （1）用户不能正确表达自身的需求。在实际开发过程中，常常碰到用户对自己真正的需求并不是十分明确的情况，他们认为计算机是万能的，只要简单的说说自己想干什么就是把需求说明白了，而对业务的规则、工作流程却不愿多谈，也讲不清楚。这种情况往往会增加需求分析工作难度，分析人员需要花费更多的时间和精力与用户交流，帮助他们梳理思路，搞清用户的真实需求。 （2）业务人员配合力度不够。有的用户日常工作繁忙，他们不愿意付出更多的时间和精力向分析人员讲解业务，这样会加大分析人员的工作难度和工作量，也可能导致因业务需求不足而使系统无法使用。