CMMI需求开发指南
- 格式：doc
- 大小：318.50 KB
- 文档页数：14
下载文档原格式
合集下载
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 分析需求，确保符合已建立的准则。
CMMI-产品需求分析书(样例)
密级：机密—JM招行云企通商城项目项目编号：________________产品需求分析书目录1。
引言 (9)1。
1.编写目的 (9)1。
2。
........................................................................................................................项目背景91。
3。
................................................................................................................................. 定义91。
4。
........................................................................................................................参考资料92。
任务概述 (10)1.5.目标 (10)1.6.用户的特点 (10)1.7.运行环境 (10)1。
8.条件与限制 (10)3.总体功能概述 (10)4。
关键业务流程图 (12)5.系统用例模型描述 (13)1.9.系统用例模型图 (13)1.10。
................................................................................................................... 参与者描述136。
功能需求详述 (13)6.1。
小企业E家官方网站 (13)6.1。
1 小企业E家首页 (13)6.1。
1。
1 ........................................................................................................功能描述136.1.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)·4·第1章 CMMI综述1.1 CMMI简介1.1.1 CMMI发展简史1981年，美国卡内基梅隆⼤学软件⼯程研究所（SEI），应美国联邦政府的要求开发了⼀种⽤于评价软件承包商能⼒并帮助其改善质量的⽅法。
Watts Humphrey将成熟框架带到了SEI并增加了成熟度等级的概念，将这些原理应⽤于软件开发，发展成为软件过程成熟度框架，它提供了⼀个评估软件开发过程的管理以及⼯程能⼒的标准。
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 分析需求，确保符合已建立的准则。
产品开发流程(IPD-CMMI)手册
产品开发流程（IPD-CMMI）手册文件编号：版本：保密等级：发出部门：发布日期：发送：抄送：总页数： 10 页附件：无主题词：产品开发流程手册文件类别：跨部门部门内编制人：责任人：审核：批准：文件变更记录变更日期版本变更条款变更内容责任人文件分发清单分发部门/人数量签收人签收日期分发部门/人数量签收人签收日期目录1目的 (3)2适用范围 (3)3定义 (3)4体系概述 (3)4.1IPD-CMMI流程管理体系总方针 (3)4.2IPD-CMMI流程管理体系总目标 (4)4.3IPD-CMMI流程管理体系框架 (4)4.4项目分类 (6)4.5生命周期模型 (6)4.6裁剪指南 (6)4.7IPD-CMMI流程与CMMI过程域的对应关系 (6)5IPD-CMMI流程体系介绍 (7)5.1工程类 (7)5.1.1总体描述 (7)5.1.2《产品开发流程之概念/计划/开发/验证/发布阶段流程》、《迭代开发流程》75.1.3《评审规范》 (8)5.2项目管理类 (8)5.2.1总体描述 (8)5.2.2《PM作业规范》 (8)5.2.3《采购管理控制程序》 (9)5.3支持类 (9)5.3.1总体描述 (9)5.3.2度量与分析 (9)5.3.3《PQA作业规范》 (9)5.3.4《配置管理》 (10)5.4过程管理类 (10)5.4.1总体描述 (10)5.4.2《IPD流程改进制度》 (10)6参考文件 (11)7附件 (11)1目的产品开发流程（IPD-CMMI）是在公司流程管理体系框架的指导原则下建立的，是公司产品开发（包括技术开发）的指导文件。
本手册规定了产品开发流程的总体方针和目标。
建立IPD-CMMI流程体系的目的是做到产品开发运作全过程的有效控制，快速推出高质量的产品，以达到客户满意和实现公司的经营发展目标；在不同的产品开发项目组间能最大限度地共享技术、开发方面的财富和经验；在组织层面上定义和收集各项目共用的一组标准的过程指标。
CMMI需求规格说明书
需求规格说明书变更日志1引言1.1 目的I说明编写这份软件露求说明书的目的,指出狡劭的读-若。
/1.2 背景I说味(1＞恃开发的软料系统的N称:(2)本项目的任务提癌者、开发毒、用户及实现该软件的过算中心或过算机网络:⑶该软件系统同其他系统或其他机构他举本的柏行来往关系。
本过程适用于级次内部的标准软件过程及相关过程资产的泠理,I1.3 定义I下衣列出本报告中专门术语的定义、英文缩写词的磔词组和意义、项R组内达成一致意见的专用词汇.同时继承全部的先前过程中定义过的词汇.]词汇名称词汇含义务注1.4 参考资料t列出用得若的参考资料,如；(I)本项目的经核戏的计翅任务书或合同、上级机关的批文:(2、诚于本项H的其他已发丧的文件:(3)本文件中各处承用的文件、资料、包括所要用到的软件开发标准.列出这鼓文件费科的标SS、M件编号、发衣H期和出版单位,说明能够出到这些文件责料的来源.[■号费科名称说明2任务概述2.1 目标1叙述该项软件开发的意图、应用目标、作用范用似及其他感阳读者说册的有关该软件开发的背景材料。
解弃被开发软件与其他有关软件之间的关盛，姐果木软件产品是•项独立的软件,而且全部内容自含,W说明这一点。
如果所定义的产品是一个更大的系统的一个姐成部分,则应说明本产品与谈系统中其他任组成部分之间能关系,为此可使用一张方框图来说明该系统的组成和本产&网其他界深分的联系和接n.12.2 用户的特点t列出本软朴的最终用户的特点,充分说明糠作人员、维护人员的教育水¥和技术专长,以及本软件的授期使电顿瘦。
这或是软件设计工作的求整约束.)2.3 假定和约束t的出迸行本软件开发工作的假定和约束.纲如姓跟限耐、开发期果等,I3需求规定t以下各小节可节选或者合并.]3.1 对功能的规定t用外衣的方式（例如IFo我即输入、处理、榆出我的形式）,逐项定录和定性适叙述对软件所推出的功能要求.说明输入什么蛾、经怎样的处理、褥到什么输出,说明软件应支持的终於数和应支持的并行操作的用户数。
CMMI-需求开发与管理规程
需求开发与管理广东×××技术股份有限公司修订历史记录目录1目的 (4)2适用范围 (4)2.1机构 (4)2.2业务 (4)3名词术语 (4)4概述 (4)5过程定义 (5)5.1需求开发与管理 (5)5.1.1 角色与职责 (5)5.1.2 入口准则 (6)5.1.3 输入 (6)5.1.4 过程活动 (6)5.1.5输出 (7)5.1.6 出口准则 (8)5.1.7 过程度量 (8)5.1.8 确认与验证 (8)6规程 (8)7标准与规范、指南 (8)8裁剪指南 (8)9模板与表格 (8)10实施指导 (9)1目的定义需求开发与管理过程，为需求开发及跟踪提供有效的流程和方法。
2适用范围2.1机构公司研发、技术等部门。
2.2业务提供需求开发与管理过程的标准活动说明。
3名词术语3.1 RDM（Request Development and Management）：需求开发与管理。
3.2 SRS(Software Requirement Specification)：软件需求规格说明书。
3.3 客户(Customer)：开发产品订单的付费方3.4 最终用户(End User)：最终真正操作软件的用户3.5 用户需求：指直接来自于客户或者用户的原始需求3.6 产品需求：指对用户需求进行需求分析和开发之后生成的对于软件产品开发的需求3.7 CCB(Change Control Board)：变更控制委员会。
CCB的组长一般为适用机构的领导，成员一般为PMO及适用机构领导制定的某些特定人员，对于子部门级别的项目，CCB可直接由子部门的经理担任组长，由PMO担任组员。
4概述项目在工程活动的开始，首先要进行需求开发。
后续所有的工程活动，包括设计、实现、测试均是根据需求展开的，所以需求开发的重要程度是最高的，而由于需求的抽象性，需求开发人员（系统分析员）既需要有过硬的专业知识，还要具备较强的交流、沟通能力，所以需求开发也是最难的。
CMMI-需求阶段
1 概述 2 需求开发 3 需求分析 4 需求评审 5 需求管理
C 目录 ONTENTS
4、需求评审
Page 21
4、需求评审
Page 22
4、需求评审
Page 23
4、需求评审
Page 24
1 概述 2 需求开发 3 需求分析 4 需求评审 5 需求管理
C 目录 ONTENTS
质量保证工程师
需求调研
1 概述 2 需求开发 3 需求分析 4 需求评审 5 需求管理
C 目录 ONTENTS
1、概述
部门现阶段的项目执行过程采用的生命周期模型是：瀑布模型。
项目启动 需求分析 软件设计 实现 测试 上线 项目收尾
过程改进体系文件还定义了另一种模型：瀑布+螺旋模型。选择方法参见《生命周期模型手册》
Page 10
2、需求开发
• 将需求调研的内容转化为需求调研报告。 • 包括客户需求、约束、接口等。 • 明确客户的非功能性需求。
需求整理 •明确客户功能需求和非功能性需求的优先级。 • 确定客户需求的验收和确认的准则。
确认
• 建立需求原型 • 需求调研报告需要得到客户确认。 • 确认的内容包括功能性需求、非功能性需求、验收准则等。 • 需求确认过程中如客户提出需求增加或修改，需要保存需求变更过程内容。
Page 5
1 概述 2 需求开发 3 需求分析 4 需求评审 5 需求管理
C 目录 ONTENTS
2、调研开发
需求调研规程
项目经理
开始
RD010 制定调研计划
《需求调研计划》
RD020 召开调研启动会
《会议纪要》
RD040 实施调研
RD060 需求评审
cmmi 开发计划管理流程
cmmi 开发计划管理流程CMMI (Capability Maturity Model Integration) is a framework that supports the improvement of an organization's processes and ultimately the improvement of its performance. CMMI development project management process is an important part of the CMMI framework and it plays a crucial role in ensuring the success of software development projects.CMMI 开发计划管理流程是 CMMI 框架的重要组成部分，它在确保软件开发项目成功方面发挥着至关重要的作用。
CMMI 框架是支持组织流程改进，最终提高其绩效的重要框架。
Effective development project management is essential for ensuring that software development projects are completed on time, within budget, and meeting customer expectations. The CMMI development project management process provides guidelines and best practices for managing project plans, monitoring project progress, and addressing project risks.高效的开发项目管理对于确保软件开发项目按时完成、在预算内，并满足客户期望至关重要。
CMMI标准学习需求开发(RD)
派生的需求
产品需求 产品组件需求
SG 2开发产品需求
子实践： 1. 用必要的技术词汇，开发产品和产品组件 2. 根据设计的决策派生需求 3. 针对在变更管理和需求分配中的事宜，建立并维护需 求之间的关系
SP2.2 分配产品组件需求：
SG 2开发产品需求
针对每个产品组件，分配需求。
1. 相关配置需求到产品和产品组件，请参考技术解决方案过程域。
SG 1 开发客户需求
SP1.1 提取需求：
子实践 ：
使相关的关系人一起参与，使用方法以便提取需求、期望、约束和外部 接口
SG 1 开发客户需求
SP1.2 开发客户需求：
来自相关干系人的各种输入，要经过合并，提取遗漏的信息，解 决冲突等过程，并记录为客户的需求。客户的需求包括要求验证 和确认相关的需要、期望和约束。 在一些情况下，客户在项目中规定了一套要求，或者这些要求已 经在先前项目活动的产出结果存在。在这些情况下，客户要求可 能和相关的干系人的需要，期望，约束和接口存在冲突，需要在 适当解决这些冲突后转换为对客户要求的统一认识。
SG 3分析和确认需求
对需求进行分析和确认，并且开发所要求的功能度的定义。 执行分析，以确定那些影响到将来的操作环境的需求是否足以 满足干系人的需要、期望、约束和接口。视产品范围而定，可行性、 任务需要、成本限制、潜在的市场规模及采购策略等必须纳入考虑。 还要建立所要求的功能度的定义。产品的所有规定的使用模式都要 予以考虑，并且对时间顺序敏感的功能随时间变化的分析。 分析的目的在于：针对那些将满足干系人需要、期望和约束的 产品概念确定候选需求；然后把这些概念转换成需求。与此同时， 要基于客户输入和初步的产品概念，确定用于评价该产品有效性的 参数。 确认需求，是为了使最终的产品更有把握在使用环境中运行。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
CMMI需求开发指南文档编号：COSHIP-CMMI-GDL-RD密级：机密版本信息：V1.0批准日期：编辑软件：MS Office Word2003 SP2，MS Office Visio2003 SP2同洲电子股份有限公司版权所有内部资料注意保密文档修订记录序号版本号变化状态变更（+/-）说明作者日期1 0.1 C 创建蒋小东2007-7-182 0.2 A、M 增强与完善内容蒋小东2007-7-263 1.0 A、M 根据评审意见和建议修订蒋小东2007-8-2*变化状态：C――创建，A——增加，M——修改，D——删除文档审批信息版本过程改进组（EPG）审核会签批准备注1.0目录文档修订记录 (2)目录 (3)1 简介 (4)1.1 文档目的 (4)1.2 适用范围 (4)1.3 术语 (4)1.4 参考资料 (4)2 需求开发基本概念 (5)2.1 需求工程 (5)2.2 需求的层次 (5)2.3 需求开发的内容 (6)2.4 优秀需求具有的特性 (6)3 需求获取 (7)3.1 需求获取原则 (8)3.2 需求获取任务 (8)3.3 需求获取方法 (9)3.3.1 问卷调查法 (9)3.3.2 会议讨论法 (10)3.3.3 用例模型 (10)4 需求分析 (11)4.1 需求分析内容 (12)4.2 需求分析方法 (12)4.2.1 结构化分析法 (12)4.2.2 面向对象分析法 (12)5 需求定义 (13)5.1 需求规格说明书 (13)5.2 优秀需求规格说明的特点 (13)6 需求验证 (14)6.1 需求评审 (14)6.2 需求验证方法 (14)1简介1.1 文档目的本指南的目的在于指导公司所有产品和项目的需求开发活动，确保需求开发活动能够遵循有效的工作方式和方法。
1.2 适用范围本文档的适用范围为同洲电子股份有限公司的需求开发。
1.3 术语需求：系统必须符合的条件或具备的功能，并通过文档进行说明。
干系人：指所有可能受到项目结果重大影响的人，如客户（或客户代表）、用户（或用户代表）、投资者、项目经理、系统分析员、设计师、测试工程师、PPQA等。
干系人即可能是项目的受益者，也是项目的风险承担者，甚至有可能是项目的受害者。
业务需求：反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。
用户需求：描述了用户使用产品必须要完成的任务，这在用例(use case)文档或方案脚本说明中予以说明。
产品需求：定义了开发人员必须实现的产品功能，使得用户能完成他们的任务，从而满足业务需求。
特性：是指逻辑上相关的功能需求的集合，给用户提供处理能力并满足业务需求。
1.4 参考资料《PRC-需求开发过程》《PRC-需求管理过程》《PRC-评审管理过程》《PRD-技术评审规范》《G-项目管理指南：项目分类管理》《PRD-集成测试规范》《PRC-集成产品开发过程》《PRD-集成产品开发组织角色定义规范》《PRD-项目组织定义规范》2需求开发基本概念2.1 需求工程需求工程是指应用已证实有效的技术、方法进行需求分析，确定客户需求，帮助分析人员理解问题并定义目标系统的所有外部特征的一门学科。
它通过合适的工具和记号系统地描述待开发系统及其行为特征和相关约束，形成需求文档，并对用户不断变化的需求演进给予支持。
需求工程是一个不断反复的需求定义、文档记录、需求演进的过程，并最终在验证的基础上冻结需求。
需求工程分为需求开发过程和需求管理过程。
以下是需求工程的构成：需求工程需求开发需求管理获取需求分析需求定义需求验证需求需求变更控制需求跟踪需求状态跟踪需求版本控制图一需求工程构成2.2 需求的层次需求开发将分为三个不同的层次：业务需求、用户需求、系统需求并最终形成系统需求规格说明书，它们之间的关系层次如下图所示：系统需求规格说明书功能需求约束条件质量属性其它非功能需求系统需求用户需求业务需求图二 需求层次2.3 需求开发的内容需求开发活动包括的内容主要有： ● 确定产品所期望的用户类。
● 获取每个用户类的需求。
● 了解实际用户任务和目标以及这些任务所支持的业务需求。
● 分析源于用户的信息以区别用户任务需求、功能需求、业务规则、质量属性、建议解决方法和附加信息。
● 将系统级的需求分为几个子系统，并将需求中的一部份分配给软件组件。
● 了解相关质量属性的重要性。
● 商讨实施优先级的划分。
● 将所收集的用户需求编写成规格说明和模型。
● 评审需求规格说明，确保对用户需求达到共同的理解与认识，并在整个开发小组接受说明之前将问题都弄清楚。
2.4 优秀需求具有的特性优秀需求的特性主要体现在需求说明和需求规格说明的特征，下面是针对优秀需求说明应具有的特征，后续章节会对优秀需求规格说明的特征进行描述。
需求说明的特征： ● 完整性每一项需求都必须将所要实现的功能描述清楚，以使开发人员获得设计和实现这些功能所需的所有必要信息。
●正确性每一项需求都必须准确地陈述其要开发的功能。
做出正确判断的参考是需求的来源，如用户或高层的系统需求规格说明。
只有用户代表才能确定用户需求的正确性，这就是一定要有用户的积极参与的原因。
●可行性每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施的。
为避免不可行的需求，最好在获取（e l i c i t a t i o n）需求(收集需求)过程中始终有一位项目开发组的成员与需求分析人员或考虑市场的人员在一起工作，由他负责检查技术可行性。
●必要性每一项需求都应把客户真正所需要的和最终系统所需遵从的标准记录下来。
“必要性”也可以理解为每项需求都是用来授权你编写文档的“根源”。
要使每项需求都能回溯至某项客户的输入，如使用实例或别的来源。
●划分优先级给每项需求、特性或使用实例分配一个实施优先级以指明它在特定产品中所占的分量。
如果把所有的需求都看作同样重要，那么项目管理者在开发或节省预算或调度中就丧失控制自由度。
●无二义性对所有需求说明的读者都只能有一个明确统一的解释，由于自然语言极易导致二义性，所以尽量把每项需求用简洁明了的用户性的语言表达出来。
避免二义性的有效方法包括对需求文档的正规审查，编写测试用例，开发原型以及设计特定的方案脚本。
●可验证性检查一下每项需求是否能通过设计测试用例或其它的验证方法，如用演示、检测等来确定产品是否确实按需求实现了。
如果需求不可验证，则确定其实施是否正确就成为主观臆断，而非客观分析了。
一份前后矛盾，不可行或有二义性的需求也是不可验证的。
3需求获取需求获取是一个确定和理解不同客户和用户的需要和约束的过程。
需求获取主要通过与客户和用户的交流开发、捕获和修订客户和用户的需求。
项目任务书下达后，项目经理组织进行有目标的需求获取活动。
需求获取主要通过调研活动完成，需求获取的工作产品可能有调研报告、调研备忘录或非正式的邮件等。
调研活动要求制定计划，按计划进行。
3.1 需求获取原则定义客户的需求就是指通过与客户的长期沟通，对客户购买产品的欲望、用途、功能、款式进行逐渐发掘，将客户心里模糊的认识以精确的方式描述并展示出来的过程。
当然，在进行客户需求定义是要注意从不同的角度和侧面来分析，具体为遵循以下几个原则：●全面性原则对于任何已被列入客户范畴的消费者，我们要全面的定义其几乎所有的需求，全面掌握客户在应用中对于各种产品的需求强度和满足状况。
之所以要全面了解，是要让客户应用中的需要完整地体现出来，而且根据客户的全面需要分析其使用习惯、消费偏好、购买能力等相关因素。
●突出性原则项目的目标是帮助客户满足需求，为公司赢得利润。
所以，要突出产品和客户需求的结合点，清晰的定义出客户的需求，从而实现双赢。
●深入性原则沟通不能肤浅，否则只能是空谈。
对客户需求的定义同样如此，只有深入的了解客户应用的各个环节，才会发现其对产品拥有的真正需求。
也就是说，要对客户的需求做出清晰的定义，事前工作的深入性是必不可少的。
●广泛性原则广泛性原则不是对某一个特定客户需求定义时的要求，而是要求销售人员在于客户沟通是要了解所有接触客户的需求状况，学会对比分析，差异化的准备自己的相关工具和说服方法。
●建议性原则客户不是我们的下属，所以命令他们是不会接受的，当然我们也不可能这么做。
在客户需求的定义过程中同样如此，客户所认同的观念跟我们或多或少的存在一些差异，所以对客户的需求要进行定义只能是“我们认为您的需求是……，您认同吗？”3.2 需求获取任务需求获取主要的任务有：●编写项目视图和范围文档。
项目视图和范围文档应该包括高层的产品业务目标，所有的使用实例和功能需求都必须遵从能达到的业务需求。
项目视图说明使所有项目参与者对项目的目标能达成共识。
而范围则是作为评估需求或潜在特性的参考。
具体操作中可在立项报告中体现。
●将用户群分类并归纳各自特点。
为避免出现疏忽某一用户群需求的情况，要将可能使用产品的客户分成不同组别。
他们可能在使用频率、使用特性、优先等级或熟练程度等方面都有所差异。
详细描述出它们的个性特点及任务状况，将有助于产品设计。
●选择每类客户/用户的产品代表。
为每类客户/用户至少选择一位能真正代表他们需求的人作为那一类客户/用户的代表并能作出决策。
他们必须一直参与项目的开发而且有权作出决策。
●让客户/用户代表确定使用实例。
从客户/用户代表处收集他们使用系统完成所需任务的描述——使用实例，讨论用户与系统间的交互方式和对话要求。
●召开系统开发讨论会议。
系统开发讨论会议是范围广的、简便的专题讨论会，也是分析人员与客户代表之间一种很好的合作办法，并能由此拟出需求文档的底稿。
该会议通过紧密而集中的讨论得以将客户与开发人员间的合作伙伴关系付诸于实践。
●确定质量属性和其它非功能需求。
在功能需求之外再考虑一下非功能的质量特点，这会使你的产品达到并超过客户的期望。
这些特点包括性能、有效性、可靠性、可用性等，而在这些质量属性上客户提供的信息相对来说就非常重要了。
●通过检查当前系统的问题报告来进一步完善需求。
客户的问题报告及补充需求为新产品或新版本提供了大量丰富的改进及增加特性的想法，负责提供用户支持及帮助的人能为收集需求过程提供极有价值的信息。
●跨项目重用需求。
如果客户要求的功能与已有的产品很相似，则可查看需求是否有足够的灵活性以允许重用一些已有的系统组件。
3.3 需求获取方法以下三种方法是需求获取最常用的方法，对于不同的项目或产品的需求获取可以用到其中的一种或几种，也可能用到其它的方法，总的目标是确定和理解客户或用户的原始需求，为后续的需求分析、定义、验证及实现奠定基础。
其中，问卷调查法常用于对业务有一定理解（如已有最初版本的产品）的项目或产品；会议讨论法常用于新业务（如新产品或客户化需求）的项目或产品；用例模型法对需求获取人员要求比较高，必须掌握好用例建模技术，可用于各种项目或产品。