需求开发与管理

需求开发与管理是软件项目中一项十分重要的工作，据调查显示在众多失败的软件项目中，由于需求原因导致的约占到45%，因此，需求工作将对软件项目能否最终实现产生至关重要的影响。虽然如此，在项目开发工作中，很多人对需求的认识还远远不够，从本人参与或接触到的一些项目来看，小到几十万元，大到上亿元的软件项目的需求都或多多少的存在问题，有的是开发者本身不重视原因、有的是技术原因、有的是人员组织原因、有的是沟通原因、有的是机制原因，以上种种原因都表明做好软件需求开发是一项系统工作，而不是简单的技术工作，只有系统的了解和掌握需求的基本概念、方法、手段、评估标准、风险等相关知识，并在实践中加以应用，才能真正做好需求的开发和管理工作。

本文将通过介绍关于软件需求的基本知识和个人在实际工作中总结的一些经验，帮助读者了解软件需求，学习需求开发的一些基本方法，避免因需求原因而导致的项目失败。

1 什么是软件需求和需求工程

1.1 软件需求的定义

在IEEE软件工程标准词汇表(1997年)中定义软件需求为：

（1）用户解决问题或达到目标所需的条件或能力。

（2）系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力。

（3）一种反映上面(1)或(2)所描述的条件或权能的文档说明。实通俗的讲，“需求”就是用户的需要，它包括用户要解决的问题、达到的目标、以及实现这些目标所需要的条件，它是一个程序或系统开发工作的说明，表现形式一般为文档形式。

1.2 需求工程的定义

需求分析的过程，也叫做需求工程和需求阶段，它包括了需求开发和需求管理两个部分。需求开发是指从情况收集、分析和评价到编写文档、评审等一系列产生需求的活动，分为四个阶段：情况获取、分析、制订规格说明和评审。这四个阶段不一定是遵循线性顺序的，他们的活动是相互独立和反复的。需求管理是软件项目开发过程中控制和维持需求约定的活动，它包括：变更控制、版本控制、需求跟踪、需求状态跟踪等工作。

2 需求分析的风险

由于需求分析的参与人员、业务模式、投资、时间等客观因素的影响和需求本身具有主观性和可描述性差的特点，因此，需求分析工作往往面临着一些潜在的风险。这些风险主要表现在：

（1）用户不能正确表达自身的需求。在实际开发过程中，常常碰到用户对自己真正的需求并不是十分明确的情况，他们认为计算机是万能的，只要简单的说说自己想干什么就是把需求说明白了，而对业务的规则、工作流程却不愿多谈，也讲不清楚。这种情况往往会增加需求分析工作难度，分析人员需要花费更多的时间和精力与用户交流，帮助他们梳理思路，搞清用户的真实需求。

（2）业务人员配合力度不够。有的用户日常工作繁忙，他们不愿意付出更多的时间和精力向分析人员讲解业务，这样会加大分析人员的工作难度和工作量，也可能导致因业务需求不足而使系统无法使用。

（3）用户需求的不断变更。由于需求识别不全、业务发生变化、需求本身错误、需求不清楚等原因，需求在项目的整个生命周期都可能发生变化，因此，我们要认识到，软件开发的过程实际上是同变化做斗争的过程，需求变化是每个开发人员、项目管理人员都会遇到的问题，也是最头痛的问题，一旦发生了需求变化，就不得不修改设计、重写代码、修改测试用例、调整项目计划等等，需求的变化就像是万恶之源，为项目的正常的进展带来不尽的麻烦。

（4）需求的完整程度。需求如何做到没有遗漏？这是一个大问题，大的系统要想穷举需求几乎是不可能的，即使小的系统，新的需求也总会不时地冒出来。一个系统很难确定明确的范围并把所有需求一次性提出来，这会导致开发人员在项目进展中去不断完善需求，先建立系统结构再完成需求说明，造成返工的可能性很大，会给开发人员带来挫折感，降低他们完成项目的信心。

（5）需求的细化程度。需求到底描述到多细，才算可以结束了？虽然国家标准有需求说明的编写规范，但具体到某一个需求上，很难给出一个具体的指标，可谓仁者见仁，智者见智，并没有定论。需求越细，周期越长，可能的变化越多，对设计的限制越严格，对需求的共性提取要求也越高，相反，需求越粗，开发人员在技术设计时不清楚的地方就越多，影响技术设计。

（6）需求描述的多义性。需求描述的多义性一方面是指不同读者对需求说明产生了不同的理解；另一方面是指同一读者能用不同的方式来解释某个需求说明。多义性会使用户和开发人员等项目参与者产生不同的期望，也会使开发、测试人员为不同的理解而浪费时间，带来不可避免的后果便是返工重做。

（7）忽略了用户的特点分析。分析人员往往容易忽略了系统用户的特点，系统是由不同的人使用其不同的特性，使用频繁程度有所差异，使用者受教育程度和经验水平不尽相同。如果忽略这些的话，将会导致有的用户对产品感到失望。

（8）需求开发的时间保障。为了确保需求的正确性和完整性，项目负责人往往坚持要在需求阶段花费较多的时间，但用户和开发部门的领导却会因为项目迟迟看不到实际成果而焦虑，他们往往会强迫项目尽快往前推进，需求开发人员也会被需求的复杂和善变折腾的筋疲力尽，他们也希望尽快结束需求阶段。

3 如何做好需求工作

需求分析是软件项目开发中最困难的一项工作，它不仅要求分析人员具有丰富的需求分析经验和良好的专业素质，还要求分析人员具有良好的学习能力、公关能力、语言能力和组织能力。在实际工作中分析人员要面对不同的单位、不同的部门、不同的人员、不同的文化、不同的关系、不同的管理水平等等不同的情况，面对如此纷繁复杂的环境，如何做好需求分析工作？首先需要建立一个有效的工作机制，只有建立了工作机制，才能保证需求工作按照既定方案执行，需求开发和管理的参与者才会在一种有序的状态下工作。其次才是充分运用工作机制和个人能力去获取问题、分析问题、编写需求文档和进行需求管理。

3.1 建立需求分析工作机制需考虑的几个因素

（1）抓住决策者最迫切和最关心的问题，引起重视。用户方决策者对项目的关心重视程度是项目能否顺利开展的关键，决策者的真实意图也是用户方的最终需求，因此，在开发过程中要利用一切机会了解决策者关心的问题，同时也要让他们了解项目的情况。在诸如谈判、专题汇报、协调会议、领导视察、阶段性成果演示等过程中用简短明确的语言或文字抓住领导最关心的问题，引导他们了解和重视项目的开发，当决策者认识到项目的重要性时，需求分析工作在人力、物力、时间上就有了保障。

（2）建立组织保障，明确的责任分工。项目开发一般都会成立相应的项目组或工程组，目前，常见的组织形式是：产品管理组、质量与测试组、程序开发组、用户代表组和后勤保障组，各组的主要分工是：产品管理组负责确定和设置项目目标，根据需求的优先级确定功能规范，向相关人员通报项目进展。程序管理组负责系统分析，根据软件开发标准协调日常开发工作确保及时交付开发任务，控制项目进度。程序开发组负责按照功能规范要求交付软件系统。质量与测试组负责保证系统符合功能规范的要求，测试工作与开发工作是独立并行的。用户代表组负责代表用户方提出需求，负责软件的用户方测试。后勤保障组负责确保项目顺利进行的后勤保障工作。

（3）建立良好的沟通环境和氛围。分析人员与用户沟通的程度关系到需求分析的质量，因此建立一个良好的沟通氛围、处理好分析人员与用户之间的关系显得尤其重要，一般情况，用户作为投资方会有一些心理优势，希望他们的意见得到足够的重视，分析人员应该充分的认识到这一点，做好心理准备，尽量避免与他们发生争执，因为我们的目的是帮助用户说出他们的最终需要。在沟通时分析人员应注意以下几个方面：1）态度上要尊重对方，但不谦恭。谦恭可能会让用户一时感到满意，但对长期合作并没有好处，尤其是在发生冲突的时候，用户会习惯性地感到自己的优势，而忽略分析人员地意见。2）分析人员要努力适应不同用户的语言表达方式。每个人都有自己的表达方式，所以优秀的分析人员应该是一个优秀的“倾听者”，他们能很快的适应用户的语言风格，理解他们的意思。3）善于表达自己，善于提问。分析人员在开口前应该先让对方充分表达他的意思，在领会了后，自己再说，尽量不要抢话。4）工作外的交流有助于增进理解，加强沟通。

（4）需求质量控制要制度化需求的变化是软件项目不可避免的事实，因此需求质量控制是一项艰苦的工作，要保证该项工作的顺利实施，就必须有制度保证，这个制度可以在项目质量控制方案中制定，该方案主要是具体化、定量化的描述用户要求，形成全面、一致、规范的软件需求分析规格说明书，明确需求分析规格说明书的工作程序和要素，规范开发活动，为后续软件设计、实现、测试、评审及验收提供依据。在方案中要明确项目组各部门关于需求质量控制的职责，制定需求分析的工作程序，包括编制需求分析工作计划、编制《需求分析说明书》、《需求分析规格说明书》的评审和确认、《需求分析规格说明书》修改控制、确定需求质量控制的质量记录文档规范等内容。

3.2 需求开发与管理的一些方法

需求开发是一项复杂的工作，使用的方法也很多，不同的开发方式有不同的方法，这里简单介绍一些相关的方法：

（1）绘制关联图：绘制系统关联图是用于定义系统与系统外部实体间的界限和接口的简单模型。

（2）可行性分析：在允许的成本、性能要求下，分析每项需求实施的可行性，提出需求实现相关风险，包括与其它需求的冲突，对外界因素的依赖和技术障碍。

（3）需求优先级：确定使用实例、产品特性或单项需求实现的优先级别。以优先级为基础确定产品版本将包括哪些特性或哪类需求。

（4）系统原型：当用户自身对有的需求不十分清楚时，我们可以建立一个系统原型，用户通过评价原型更好地理解所要解决的问题。。

（5）图形分析模型：绘制图形分析模型是编制软件需求规格说明重要手段。它们能帮助分析人员理清数据、业务模式、工作流程以及他们之间的关系，找出遗漏、冗余和不一致的需求。这样的模型包括数据流图、实体关系图、状态变换图、对话框图、对象类及交互作用图。

（6）数据字典：数据字典是对系统用到的所有数据项和结构的定义，以确保开发人员使用统一的数据定义。在需求阶段，数据字典至少应定义客户数据项，确保客户与开发小组是使用一致的定义和术语。

（7）质量功能调配：质量功能调配是一种高级系统技术，它将产品特性、属性与对客户的重要性联系起来。该技术提供了一种分析方法以明确哪些是客户最为关注的特性。它将需求分为三类：期望需求、普通需求、兴奋需求。

需求管理的目的就是要控制和维持需求事先约定，保证项目开发过程的一致性，使用户得到他们最终想要得产品。需求管理的方法主要包括以下一些方面：

1）确定需求变更控制过程。制定一个选择、分析和决策需求变更的过程，所有的需求变更都需遵循此过程。

2）进行需求变更影响分析。评估每项需求变更，以确定它对项目计划安排和其它需求的影响，明确与变更相关的任务并评估完成这些任务需要的工作量。通过这些分析将有助于需求变更控制部门做出更好的决策。

3）建立需求基准版本和需求控制版本文档。确定需求基准，这是项目各方对需求达成一致认识时刻的一个快照，之后的需求变更遵循变更控制过程即可。每个版本的需求规格说明都必须是独立说明，以避免将底稿和基准或新旧版本相混淆。

4）维护需求变更的历史记录。将需求变更情况写成文档，记录变更日期、原因、负责人、版本号等内容，及时通知到项目开发所涉及的人员。为了尽量减少困惑、冲突、误传，应指定专人来负责更新需求。

5）跟踪每项需求的状态。可以把每一项需求的状态属性（如已推荐的，已通过的，已实施的，或已验证的）保存在数据库中，这样可以在任何时候得到每个状态类的需求数量。

6）衡量需求稳定性。可以定期把需求数量和需求变更（添加、修改、删除）数量进行比较。过多的需求变更"是一个报警信号"，意味着问题并未真正弄清楚。

4 需求分析评价标准

如何判断需求规格说明的好坏，不同的软件工程规范都有自己的一套标准，这里向大家介绍一个比较常见的NASA SEL推荐方法，它是由美国国家航空和航天局软件工程实验室开发的五大常用国际软件工程规范之一，它对软件需求过程的评价标准是：清晰、完整、一致、可测试。

（1）清晰：目前大多数的需求分析采用的仍然是自然语言，自然语言对需求分析最大的弊病就是它的二义性，所以开发人员需要对需求分析中采用的语言做某些限制。例如尽量采用主语＋动作的简单表达方式。需求分析中的描述一定要简单，千万不要采用疑问句、修饰这些复杂的表达方式。除了语言的二义性之外，注意不要使用行话，就是计算机术语。需求分析最重要的是和用户沟通，可是用户多半不是计算机的专业人士，如果在需求分析中使用了行话，就会造成用户理解上的困难。

（2）完整：需求的完整性是非常重要的，如果有遗漏需求，则不得不返工，在软件开发过程中，最糟糕的事情莫过于在软件开发接近完成时发现遗漏了一项需求。但实际情况是，需求的遗漏是常发生的事情，这不仅仅是开发人员的问题，更多发生在用户那里。要做到需求的完整性是很艰难的一件事情，它涉及到需求分析过程的各个方面，贯穿整个过程，从最初的需求计划制定到最后的需求评审。

（3）一致：一致性是指用户需求必须和业务需求一致，功能需求必须和用户需求一致。在需求过程中，开发人员需要把一致性关系进行细化，比如用户需求不能超出预前指定的范围。严格的遵守不同层次间的一致性关系，就可以保证最后开发出来的软件系统不会偏离最初的实现目标。

（4）可测试：一个项目的测试从什么时候开始呢？有人说是从编码完成后开始，有人说是编码的时候同时进行单元测试，编码完成后进行系统测试，这些结论都不完全正确。实际上，测试是从需求分析过程就开始了，因为需求是测试计划的输入和参照。这就要求需求分析是可测试的，只有系统的所有需求都是可以被测试的，才能够保证软件始终围绕着用户的需要，保证软件系统是成功的。

CMM中的需求管理与需求开发

需求管理（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概述 需求是从系统外部能发现系统所具有的满足于用户的特点、功能及属性等。需求是指明必须实现什么的规格说明。它描述了系统的行为、特性或属性，是在开发过程中对系统的约束。 软件需求工程划分为需求开发和需求管理，其中需求开发可进一步分为问题获取(elicitation)、分析(analysis)、编写规格说明(specification)和验证(verification)四个阶段, 需求开发活动包括以下几个方面： (1)确定产品所期望的用户类 (2)获取每个用户类的需求 (3)了解实际用户任务和目标以及这些任务所支持的业务需求 (4)分析源于用户的信息以区别用户任务需求、功能需求、业务规则、质量属性、建议解决 方法和附加信息 (5)将系统级的需求分为几个子系统，并将需求中的一部分分配给软件组件 (6)了解相关质量属性的重要性 (7)商讨实施优先级的划分 (8)将所发现的用户需求编写成规格说明和用例模型 (9)评审用例和需求规格说明，确保对用户需求达到共同的理解与认识，并在整个开发小组 接受说明之前将问题都弄清楚。 需求管理活动包括以下几个方面： (1)定义需求基线(迅速制定需求文档的主体) (2)评审提出的需求变更、评估每项变更的可能影响从而决定是否实施它 (3)以一种可控制的方式将需求变更融入到项目中 (4)使当前的项目计划与需求一致 (5)估计变更需求所产生的影响并在此基础上协商新的承诺。 (6)让每项需求都能与其对应的设计、源代码和测试用例联系起来以实现跟踪 (7)在整个项目过程中跟踪需求状态及其变更情况。 2需求工程的推荐方法 需求工程推荐方法 需求开发

需求开发和管理流程范例

需求开发和管理流程范例 目录 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.退出准则 《需求特性列表》通过审核，与高级经理沟通后初步明确项目经理

研发部需求开发流程管理

研发部需求开发流程管理

管理目标 1、所有关系人清晰明确地了解项目的需求和 期望，努力做到满足项目所有关系人的不同需求；项目关系人包括：项目团队成员和项目团队外(内部/外部客户，内部/外部合作伙伴，经销商/客户等)。 2、项目管理三要素平衡（时间/成本/质量）， 即开发项目按需按时按质的完成。 3、目标：功能满足需求，设计支持变化，开发 快速迭代，成果持续交付。 执行概述 1、建立有效的工作流程保证项目的顺利进行， 初期使用传统RUP过程，引入部分敏捷方法，团队磨合完成后逐步实现敏捷开发全流程管理。 2、明确项目目标，制定具有可行性的项目计 划，有效明确的分解项目需求。 3、跟踪设计/开发/测试/回归/发布全流程，推 动项目按预定计划执行。 4、解决项目过程中出现的问题和冲突，一般集

中在需求不明/工作量或时长/开发难度/跨 部门协调等几个方面。 5、调动开发团队的积极性，创造力，推动团队 成员在项目过程中的学习成长。 6、风险识别、风险控制以及风险的预案。 项目管理 1、需求阶段 对项目进行技术可行性分析、技术评估、成本评估以及风险评估。 与需求提出方的代表进行需求讨论，明确项目的目标、价值。 确定项目范围、功能及优先级。 组建项目团队，特别要搞清楚项目的关键人。 项目启动会议，相关的关系人都必须参加。 2、设计阶段 根据确认后的软件需求规格说明书，制定项目进度计划，工作任务分解(WBS)；资源申请，项目涉及到的开发资源、测试资源、设计资源(包括人员和软硬件资源)；数据库设计；系统

设计；文档(包括系统用例、Demo、测试用例等)；评审会议。 设计阶段结果交付一般为系统用例/系统原型/系统设计文档(概要设计和详细设计)/数据库设计文档等。 该阶段交付成果需要进行评审。 3、执行阶段(开发和测试) 准备开发环境、测试环境。 跟踪，推动项目按计划进行。 项目成员以日报/项目负责人以周报的形式通报各关系人当前项目的进展情况。 按里程碑对阶段成果进行评估，以确保该阶段完成的质量。 代码审核，包括CS审核、SQL审核、WEB 审核等。 对需求变更进行控制管理。 测试阶段BUG响应及改进、收集反馈意见。 对项目风险进行管理。 4、发布阶段 包括制定项目发布计划，用户培训，发布上

软件项目的需求开发与管理

软件项目的需求开发与管理需求开发与管理是软件项目中一项十分重要的工作，据调查显示在众多失败的软件项目中，由于需求原因导致的约占到45%，因此，需求工作将对软件项目能否最终实现产生至关重要的影响。虽然如此，在项目开发工作中，很多人对需求的认识还远远不够，从本人参与或接触到的一些项目来看，小到几十万元，大到上亿元的软件项目的需求都或多多少的存在问题，有的是开发者本身不重视原因、有的是技术原因、有的是人员组织原因、有的是沟通原因、有的是机制原因，以上种种原因都表明做好软件需求开发是一项系统工作，而不是简单的技术工作，只有系统的了解和掌握需求的基本概念、方法、手段、评估标准、风险等相关知识，并在实践中加以应用，才能真正做好需求的开发和管理工作。 本文将通过介绍关于软件需求的基本知识和个人在实际工作中总结的一些经验，帮助读者了解软件需求，学习需求开发的一些基本方法，避免因需求原因而导致的项目失败。 1? 什么是软件需求和需求工程 软件需求的定义 在IEEE软件工程标准词汇表(1997年)中定义软件需求为： （1）用户解决问题或达到目标所需的条件或能力。 （2）系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力。（3）一种反映上面(1)或(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、业务逻辑比较复杂的由对业务逻辑比较了解的人负责。

需求开发与管理过程

密级：普通 标识: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)

需求开发与管理过程(Req. Development Mgt. Process)

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）业务人员配合力度不够。有的用户日常工作繁忙，他们不愿意付出更多的时间和精力向分析人员讲解业务，这样会加大分析人员的工作难度和工作量，也可能导致因业务需求不足而使系统无法使用。

需求开发流程管理规定

需求开发流程管理规定 1. 目的 通过需求开发流程的规定，规范公司软件项目的需求开发和管理活动，提高需求质量，降低开发成本，改进系统质量。 ，

4. 流程图 图1：需求开发流程图

5. 主要活动 需求定义的目的是需求提出人通过收集、调查与分析，获取用户业务需求并定义需求。需求定义的主要活动包括：需求收集、需求分析&定义。 需求管理的目的是在需求方与程序组之间建立对需求的共同认识和理解，维护需求与程序开发成果的一致性，并控制需求的变更。需求管理的主要活动包括：需求评审确认、需求变更、需求跟踪控制。 在需求文档中，一般取二级类别进行标识。 5.1.3 需求优先级 需求分析员应确定每个需求的优先级，需求的优先级判定标准如下：

●确保所描述的需求可以通过适当的手段得到验证，即需求的可测试性； ●考虑了各个层次的需求影响，确定了需求的优先级，以确保需求的可行性。 提醒：对于版面调整、活动等不需要做过多业务流程更改的需求，采用《程序需求表》进行填写。 5.2 需求评审确认及开发流程 需求评审是指程序开发方和需求提出方共同对《立项需求说明书》进行评审，双方对需求与商业目的达成共识。

在需求说明书生成后，需求分析员将文档提交给需求受理人，由受理人进行初审，确保文档的正确性和合理性，并符合文档编写规范。 5.2.1 需求评审 评审的目的在于：使需求文档达到易读、无歧义、一致、必要、完整、可实现、可验证。 需求受理人（一般为部门总监，各个地区分站由技术中心受理）对提交的需求文档进行初审通过后，由信息技术中心组织和安排需求的评审工作：确定评审时间、地点、评审人员和其他参加人员。至少应包含以下成员： ●评审组长：总裁及总裁办相关领导、信息技术总监； ●评审成员：项目经理、程序员及其他相关人员； ●输入：《立项需求说明书》初稿 ●输出：《评审结果报告》 当需求文档评审通过后，程序开发方和需求提出方应须进行书面签字确认，使之生效。之后若需要调整需求，则须走需求变更控制流程。 未经书面确认的需求开发，若发生需求分歧，由未签字确认方及其上级承担主要责任。 经书面确认的需求开发，若发生预期需求与开发实现的功能不一致而影响开发质量的，责任归属 界定： A.因需求不明确、阐述遗漏、描述错误等，且后期没有对应的需求变更记录备案，而造成实现 的功能与预期需求不一致，由需求方承担主要责任。 B.因需求不明确、阐述遗漏、描述错误等，而后期存在对应的需求变更记录备案，而造成实现 的功能与预期需求不一致的，由程序开发方承担主要责任。 5.3 需求变更 对一个软件项目来说，无论最初的需求分析有多么明确，开发过程中的需求变化也还是不可避免。这主要有以下几种原因： 1. 系统所应用的外部环境发生变化； 2. 随着对软件的熟悉和应用，又提出新的需求； 3. 进行需求分析时未能彻底分析原始需求，或分析错误； 4.在开始时不能很全面的知道所需软件的功能。 需求变更的影响：对项目研发而言，变更需求意味着有可能需要重新分配任务、修改前期工作成果、调整工作计划和项目预算等。 只有当需求变更带来的好处大于坏处时，变更需求才是有意义的，但也须遵循变更控制流程：申请→审批→执行；如果需求变更带来的坏处大于好处，则应拒绝变更。 需求受理人应适当拒绝一些不合理的变更。如：提出的变更不是由于程序开发方的过错引起的，此变更可能造成程序开发方占用额外的资源或成本，而需求方又不愿给出额外资源对变更进行处理等。 变更控制流程如图所示，主要包括：变更申请、评审和审批、填写执行记录。

需求开发流程

密级：内部公开 文档编号：KKCQ-Proc-RDM 版本号：V1.0 分册名称：第1册/共1册 需求开发与管理说明

文档更改摘要：

1. 目的 通过此需求开发流程的定义，规范公司内部项目的需求开发和管理活动，提高需求质量，从而提高需求任务处理率，降低开发成本，改进系统质量。 通过对业务部提交的需求进行评审，确保需求的正确性和合理性，获得需求的承诺；控制需求的变更，并确保项目工作成果与需求的一致性。 2. 范围 适用于公司内部开发项目及已经通过《商业需求确认书》的项目，如未通过《商业需求确认书》，技术中心暂时无法参与需求立项，评审，分析等流程。附件一：《商业需求确认书》 3. 术语 4. 角色与职责 5. 流程图

图1：需求开发流程图 6. 主要活动 需求定义的目的是需求提出人通过收集、调查与分析，获取用户业务需求并定义需求。需求定义的主要活动包括：需求收集、需求分析&定义。 需求管理的目的是在需求方与程序组之间建立对需求的共同认识和理解，维护需求与程序开发成果的一致性，并控制需求的变更。需求管理的主要活动包括：需求评审确认、需求变更、需求跟踪控制。 6.1需求定义 由于在实际情况下，大部分原始需求都未完整地讲述其业务需求，需求获取的质量，对后续的需求分析和需求定义工作将会产生重大影响。 在完成需求收集所得到的记录与资料的分析与整理后，产品经理应对需求进行分类、排优先级等。 6.1.1 标识需求与命名规则 为了便于需求文档的统一管理，更好的识别每个项目的需求，需要明确需求文档的命名规则，具

体格式为： [需求年月]-[项目类别]-[用途类别] 如，201310-综合信息项目-活动需求； 6.1.2 需求分类 在需求文档中，一般取二级类别进行标识。 6.1.3 需求优先级 时，正确地对需求实现的范围或实现的优先程度做出取舍。

软件方案的需求开发与管理

软件项目的需求开发与管理 需求开发与管理是软件项目中一项十分重要的工作，据调查显示在众多失败的软件项目中，由于需求原因导致的约占到45%，因此，需求工作将对软件项目能否最终实现产生至关重要的影响。虽然如此，在项目开发工作中，很多人对需求的认识还远远不够，从本人参与或接触到的一些项目来看，小到几十万元，大到上亿元的软件项目的需求都或多多少的存在问题，有的是开发者本身不重视原因、有的是技术原因、有的是人员组织原因、有的是沟通原因、有的是机制原因，以上种种原因都表明做好软件需求开发是一项系统工作，而不是简单的技术工作，只有系统的了解和掌握需求的基本概念、方法、手段、评估标准、风险等相关知识，并在实践中加以应用，才能真正做好需求的开发和管理工作。 本文将通过介绍关于软件需求的基本知识和个人在实际工作中总结的一些经验，帮助读者了解软件需求，学习需求开发的一些基本方法，避免因需求原因而导致的项目失败。 1 什么是软件需求和需求工程 1.1 软件需求的定义 在IEEE软件工程标准词汇表(1997年)中定义软件需求为： （1）用户解决问题或达到目标所需的条件或能力。 （2）系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力。（3）一种反映上面(1)或(2)所描述的条件或权能的文档说明。 实通俗的讲，“需求”就是用户的需要，它包括用户要解决的问题、达到的目标、以及实现这些目标所需要的条件，它是一个程序或系统开发工作的说明，表现形式一般为文档形式。 1.2 需求工程的定义 需求分析的过程，也叫做需求工程和需求阶段，它包括了需求开发和需求管理两个部分。需求开发是指从情况收集、分析和评价到编写文档、评审等一系列产生需求的活动，分为四个阶段：情况获取、分析、制订规格说明和评审。这四个阶段不一定是遵循线性顺序的，他们

产品需求开发与需求管理-王小刚

产品需求开发与需求管理 主办单位：一六八培训网 时间：2016年5月27-28日地点：北京讲师：王小刚 价格：3600元/人(包授课、资料、午餐、茶歇、会务和税务费用) 课程背景 随着时代背景的变迁，互联网信息技术的不断发展，研发企业在全球范围内所面临的竞争也在不断的加剧，如何才能在强手如林的竞争环境中脱颖而出，保持并不断提升企业的竞争力? 笔者认为最为根本的依靠还是看研发企业是否具备优秀的产品开发能力，能否做到持续领先于竞争对手向市场推送满足客户需求的产品，唯有如此，才能保证产品市场份额和企业利润的可持续发展，但说时容易做时难，如今国内大部分研发企业在产品开发能力上依然有大幅的提升空间，尤其是在产品需求开发与管理上，您是否能够把有限的资源全部投放在正确的需求上；即使您做到了这一点，那是否在产品服务或者用户体验需求上继续探索，寻找着力点；即使您又做到了，是否能够在产品开发过程中对需求进行高效科学的管理，保证正确的需求能够快速、准确的实现、并及时推送给您的客户，如果这几方面还做的不够优秀，本课程将会对您大有益处。 本次需求管理课程的两个关键词是”开发与管理“，需求开发的目的是让我们的企业能够”做正确的事“，这是成功或失败的源头，重要性毋庸置疑，但光有这个源头，还不足以让我们走在竞争对手的面前获得成功，我们企业还必须要具备“把事情做正确的能力”，让正确的需求始终正确，而且能够高效的实现，最终获得市场和客户认可，这正是需求管理的范畴。所以需求开发与需求管理相辅相成，缺一不可，本次课程全面系统的从需求开发与需求管理两个维度进行展开，结合产品市场管理和产品开发管理两个体系的实践活动进行详细的讲解。 培训收益 1. 深度理解产品需求的价值和范围 2. 全面、系统的学习产品需求开发与管理的过程，拒绝做”需求管理的临时工” 3．掌握产品需求开发与管理组织、角色、流程、能力的建设思想 4. 掌握产品需求开发与管理与集成产品开发体系的关系和接口建设

软件项目的需求开发和管理

摘要 需求开发与管理是软件项目中一项十分重要的工作，据调查显示在众多失败的软件项目中，由于需求原因导致的约占到45%，因此，需求工作将对软件项目能否最终实现产生至关重要的影响。如何从各种各样的应用专业领域中特别是直接从最终用户处捕获需求，并完整、准确地予以描述与分析，需求工程成为研究的热点之一。 本文通过对需求工程的基本概念、需求开发和管理中的主要风险和对策进行研究和总结，希望在实践中加以应用，真正做好需求的开发和管理工作。 关键字：软件项目、需求工程、需求分析、需求开发、需求管理、X围管理、X围变更控制

目录 1软件需求和需求工程3 1.1软件需求的基本概念3 1.2软件需求的重要性3 1.3需求工程的基本概念4 1.4需求开发过程域4 1.5需求管理过程域5 1.6需求工程的一些感悟5 2需求开发和管理的主要风险6 3需求开发和管理的主要对策6 3.1建立需求开发和管理工作机制需考虑的几个因素7 3.2需求开发和管理流程7 3.2.1需求调查7 3.2.2细化用户需求8 3.2.3撰写需求说明书8 3.2.4需求确认9 3.2.5需求跟踪10 3.2.6需求变更控制10 4总结13

软件项目的需求开发和管理 1软件需求和需求工程 1.1 软件需求的基本概念 在IEEE软件工程标准词汇表(1997年)中定义软件需求为： 1)用户解决问题或达到目标所需的条件或能力。 2)系统或系统部件要满足合同、标准、规X或其它正式规定文档所需 具有的条件或能力。 3)一种反映上面1)或2)所描述的条件或权能的文档说明。实通俗的 讲，“需求”就是用户的需要，它包括用户要解决的问题、达到的目 标、以及实现这些目标所需要的条件，它是一个程序或系统开发工 作的说明，表现形式一般为文档形式。 所以我们可以理解，软件需求来源于用户的一些“需要”，这些“需要”被分析、确认后形成完整的文档，该文档详细地说明了产品“必须或应当”做什么。 1.2 软件需求的重要性 软件需求是整个产品链的源头，需求工作的优劣将直接影响到产品的设计，生产，销售和维护的全过程。就像一条河流，如果源头被污染了，那么整条河流也就被污染了。Frederick Brooks在他的经典文章“No Silver Bullet”是这样描述需求的重要性的：开发软件系统最困难的部分就是准确说明开发什么。最困难的概念性工作是编写出详细的需求，包括所有面向用户、面向机器和其它软件系统的接口。此工作一旦做错，将会给系统带来极大的损害，并且以后对它修改也极为困难。

研发部需求开发流程管理

管理目标 1、所有关系人清晰明确地了解项目的需求和期望，努力做到满足项目所有关系人的不同需求；项目关系人包括：项目团队成员和项目团队外(内部/外部客户，内部/外部合作伙伴，经销商/客户等)。 2、项目管理三要素平衡（时间/成本/质量），即开发项目按需按时按质的完成。 3、目标：功能满足需求，设计支持变化，开发快速迭代，成果持续交付。 执行概述 1、建立有效的工作流程保证项目的顺利进行，初期使用传统RUP过程，引入部分敏捷方 法，团队磨合完成后逐步实现敏捷开发全流程管理。 2、明确项目目标，制定具有可行性的项目计划，有效明确的分解项目需求。 3、跟踪设计/开发/测试/回归/发布全流程，推动项目按预定计划执行。 4、解决项目过程中出现的问题和冲突，一般集中在需求不明/工作量或时长/开发难度/跨部 门协调等几个方面。 5、调动开发团队的积极性，创造力，推动团队成员在项目过程中的学习成长。 6、风险识别、风险控制以及风险的预案。 项目管理 1、需求阶段 对项目进行技术可行性分析、技术评估、成本评估以及风险评估。 与需求提出方的代表进行需求讨论，明确项目的目标、价值。 确定项目范围、功能及优先级。 组建项目团队，特别要搞清楚项目的关键人。 项目启动会议，相关的关系人都必须参加。 2、设计阶段 根据确认后的软件需求规格说明书，制定项目进度计划，工作任务分解(WBS)；资源申请，项目涉及到的开发资源、测试资源、设计资源(包括人员和软硬件资源)；数据库设计；系统设计；文档(包括系统用例、Demo、测试用例等)；评审会议。 设计阶段结果交付一般为系统用例/系统原型/系统设计文档(概要设计和详细设计)/数据库设计文档等。 该阶段交付成果需要进行评审。 3、执行阶段(开发和测试) 准备开发环境、测试环境。 跟踪，推动项目按计划进行。 项目成员以日报/项目负责人以周报的形式通报各关系人当前项目的进展情况。

论如何进行有效的需求管理

论如何进行有效的需求管理 很多人会有这种感受，一个项目做了很久，感觉总是做不完，就像一个“无底洞”。你想加人尽快完成这个项目，而用户总是有新的需求要项目开发方来做，就像用户是一个不知廉耻的要求者，而开发方是在苦苦接收的接受者。实际上，这里涉及到一个需求管理的概念。项目中哪些该做，哪些不该做，做到什么程度，都是由需求管理来决定的。需求管理是软件项目中一项十分重要的工作，据调查显示在众多失败的软件项目中，由于需求原因导致的约占了很大的一部分，因此，需求工作将对软件项目能否最终实现产生至关重要的影响。 在软件项目的开发过程中，需求变更贯穿了软件项目的整个生命周期，从软件的项目立项，研发，维护，用户的经验在增加，对使用软件的感受有变化，以及整个行业的新动态，都为软件带来不断完善功能，优化性能，提高用户友好性的要求。在软件项目管理过程中，项目经理经常面对用户的需求变更。如果不能有效处理这些需求变更，项目计划会一再调整，软件交付日期一再拖延，项目研发人员的士气将越来越低落，将直接导致项目成本增加、质量下降及项目交付日期推后。这决定了项目组必须拥有需求管理策略。 下面主要针对需求开发及需求管理两个方面对需求进行分析。 1. 需求开发，从目前我们的实际工作情况来看按顺序主要分成如下几个部分： ?请教行业专家 行业客户对信息化的需求越来越细化，对专业性以及行业能力的全面性要求越来越高，惟有深入行业，洞察其需求，研发出更适合客户需求的产品，才能成功。因此有必要先请这方面的行业专家对于客户的业务需求进行从流程上的梳理。为什么请行业专家，而不是直接请客户进行交谈，得到其实需求，个人认为主要是因为目前各政府部门、企事业单位对于信息化与业需求的整合这一块缺少经验，大部分情况还不能完全整理出完善、清晰的系统需求来。只有通过行业专家对其实业务流程进行梳理，一方面更容易与客户产生共鸣，另一方面也可以大大减少因为知识方面的差异导致错识需求的产生。 ?和客户交谈 你要面对“正确”的客户区分不同层次的客户需求，要面对不同层级，不同部门的客户，把客户分类，区分需求的优先级别。如果你做的项目业务是你熟悉的，那还好，如果是你不熟悉的，一定要花点精力学习一下这个行业业务的背景资料，这也是我上面谈到的先请行业专家的原因。毕竟，客户是不可能给你系统地介绍业务的。只有你通晓了行业业务，才能和用户交流，并正确而有效地引导客户，做好需求分析，你不能指望客户能明确地说出需求。

需求开发与需求管理指引

第1章C M M I综述

·2· 第1章 CMMI综述 1.1CMMI简介 (4) 1.1.1 CMMI发展简史 (4) 1.1.2 CMMI的过程域 (5) 1.1.3 CMMI的两种表示法 (6) 1.2CMMI阶段式表示法 (7) 1.2.1 成熟度等级L1：初始级的特征 (8) 1.2.2 成熟度等级L2：已管理级的特征 (9) 1.2.3 成熟度等级L3：已定义级的特征 (9) 1.2.4 成熟度等级L4：量化管理级的特征 (9) 1.2.5 成熟度等级L5：持续优化级的特征 (10) 1.3CMMI连续式表示法 (10) 1.3.1 能力等级0-不完整级的特征 (12) 1.3.2 能力等级1-已执行级的特征 (12) 1.3.3 能力等级2-已管理级的特征 (12) 1.3.4 能力等级3-已定义级的特征 (13) 1.3.5 能力等级4-量化管理级的特征 (13) 1.3.6 能力等级5-持续优化级的特征 (14) 1.4过程域的部件及解释 (14) 1.4.1 必需部件 (15) 1.4.2 期望部件 (15) 1.4.3 信息部件 (16) 1.5CMMI评估 (17) 1.5.1 CMMI评估要求 (17)

第1章 CMMI综述.3.1.5.2 CMMI标准评估方法SCAMPI (17) 1.5.3 CMMI评估考虑事项 (18) 1.6CMMI和CMM的比较 (19) 1.6.1 CMMI与CMM的模型比较 (19) 1.6.2 CMMI 与CMM 过程域比较 (19) 1.6.3 CMMI 与CMM评估方法比较 (21) 1.7CMM/CMMI在中国 (21)

软件目的需求开发与管理

软件工程－软件目的需求开发与管理 需求开发与管理是软件项目中一项十分重要的工作，据调查显示在众多失败的软件项目中，由于需求原因导致的约占到45%，因此，需求工作将对软件项目能否最终实现产生至关重要的影响。虽然如此，在项目开发工作中，很多人对需求的认识还远远不够，从本人参与或接触到的一些项目来看，小到几十万元，大到上亿元的软件项目的需求都或多多少的存在问题，有的是开发者本身不重视原因、有的是技术原因、有的是人员组织原因、有的是沟通原因、有的是机制原因，以上种种原因都表明做好软件需求开发是一项系统工作，而不是简单的技术工作，只有系统的了解和掌握需求的基本概念、方法、手段、评估标准、风险等相关知识，并在实践中加以应用，才能真正做好需求的开发和管理工作。 本文将通过介绍关于软件需求的基本知识和个人在实际工作中总结的一些经验，帮助读者了解软件需求，学习需求开发的一些基本方法，避免因需求原因而导致的项目失败。 1 什么是软件需求和需求工程 1.1 软件需求的定义 在IEEE软件工程标准词汇表(1997年)中定义软件需求为： （1）用户解决问题或达到目标所需的条件或能力。 （2）系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力。

（3）一种反映上面(1)或(2)所描述的条件或权能的文档说明。实通俗的讲，“需求”就是用户的需要，它包括用户要解决的问题、达到的目标、以及实现这些目标所需要的条件，它是一个程序或系统开发工作的说明，表现形式一般为文档形式。 1.2 需求工程的定义 需求分析的过程，也叫做需求工程和需求阶段，它包括了需求开发和需求管理两个部分。需求开发是指从情况收集、分析和评价到编写文档、评审等一系列产生需求的活动，分为四个阶段：情况获取、分析、制订规格说明和评审。这四个阶段不一定是遵循线性顺序的，他们的活动是相互独立和反复的。需求管理是软件项目开发过程中控制和维持需求约定的活动，它包括：变更控制、版本控制、需求跟踪、需求状态跟踪等工作。 2 需求分析的风险 由于需求分析的参与人员、业务模式、投资、时间等客观因素的影响和需求本身具有主观性和可描述性差的特点，因此，需求分析工作往往面临着一些潜在的风险。这些风险主要表现在： （1）用户不能正确表达自身的需求。在实际开发过程中，常常碰到用户对自己真正的需求并不是十分明确的情况，他们认为计算机是万能的，只要简单的说说自己想干什么就是把需求说明白了，而对业务的规则、工作流程却不愿多谈，也讲不清楚。这种情况往往会增加需求分析工作难度，分析人员需要花费更多的时间和精力与用户交流，帮助他们梳理思路，搞清用户的真实需求。

十问软件需求分析与管理

十问软件需求分析与管理 1.需求工作涉及到哪些内容 首先需求包括了产品需求，用户需求，软件需求。产品需求关注的是产品的标准化和通用化，会对收集到的用户需求进行分类和优化，结合业界标准系统模型进行抽象并通用化。用户需求反映的是用户面临的问题域，根据问题域用户期望的能够达到的解决效果；而对于软件需求则是用软件工程的语言结构化和文档化的对用户需求和产品需求的描述。 需求工作涉及到需求开发和需求管理。需求开发涉及到需求调研，需求收集，需求分析，需求开发等工作，其中的重点有业务流程，数据字典，业务规则，界面原型。对于基于面向对象的开发方法则涉及到业务用例，系统用例（涉众，基本流，扩展流，业务规则，界面，操作）等诸多内容。需求管理工作涉及到需求的状态管理，变更管理，需求的跟踪，需求的验证和确认等重要内容。 在我们需求分析和开发中，最容易忽视的主要有两点，一个就是缺乏需求分析和开发的过程，把用户需求直接作为了软件需求，没有需求建模和抽象的过程。另外一点就是对于性能，安全，易用性，可维护性和扩展性等非功能性需求没有考虑，导致开发出来的系统是一个不好用的半成品。CM MI把需求管理放到2级，需求开发放到3级，实际上真正的提高需求人员的需求分析和开发能力才是解决需求问题之道。需求分析开发做不好，需求变更或追踪管的再好也没有用处，在这点上一定不能本末倒置。 2.做好需求分析需要具备哪些知识 需求分析岗位主要承担的是系统分析员的工作，做需求分析的人员要有软件工程基础知识的积累，而且最好有一定的软件开发经验积累。自己做过设计开发工作的才能够体会到如何才能够把系统做好，如何更好的把软件需求和后续实现更好的衔接起来。有一本《软件