CMMI3 PA之需求开发过程域(RD)解释和实施指南

CMM的时候，是没有需求开发这个PA的，需求开发和需求管理有什么区别呢？

需求管理强调的是管理项目产品及产品组件的需求，并界定这些需求与项目计划及工作产品间的差异,强调的是需求与项目计划及工作产品之间的一致性。而需求开发讲究的是用系统的方法识别和获取真正的全面的能实现的需求，产出并分析客户、产品及产品组件的需求。

CMMI和CMM相比，增加了很多专门针对软件工程的PA，其中需求开发(RD)就是其中之一。需求开发这个PA，从很高的层次描述了如何做好需求开发。要理解好本PA，需要先理解清楚以下几个关键的概念：

1)客户需求(Customer Requirements)

2)产品需求(Product Requirements)

3)产品组件需求(Product Component Requirements)

客户需求（需要什么、期望什么、限制什么、外部接口是什麽等）是可以理解成客户为什么要做本系统，要解决什么问题，客户对系统有怎样的期望，希望能具备一些怎样的特点，简单的说，就是客户的需要是什么。一般表现为系统功能、性能、界面等要求；

产品需求是能满足客户需求，并对软件产品规格进行了详细描述的需求，产品派生需求（如法规、习惯性做法、性能需求等），在产品需求的开发时增加上去；软件设计师可以根据产品需求进行设计、编码等工作。

产品组件需求，是对产品需求的进一步细化，产品可能会分割成几个子系统、几个部分，每个子系统每部分要具备怎样的功能、要具备怎样的性能、接口及界面要求、数据库等，这些可以认为是产品组件需求。分配需求（为每个产品组件分配需求）依赖于设计（技术解决方案），功能需求是软件实现、还是硬件实现，是分配到产品组件的硬件还是软件，如手机产品拨打电话的功能需求，是通过触摸屏和软体实现，还是通过手机按键（硬件）的方式实现，所以产品组件的需求是依赖与设计（技术解决方案）；有分配产品组件需求就有接口需求（内部和外部接口等），有模块和组件，就有接口与界面、数据库等；

从另外一个角度，需求可以分为功能性需求和非功能性需求两类，功能性需求就是系统具备怎样的功能，能做什么事情，而非功能性需求就是指系统要具备怎样的性能、安全级别等方面的要求。客户需求、产品需求和产品组件需求，都会包含功能需求和非功能需求。

以“短信订餐系统”为例，其实这个系统，客户需求很简单，就是要解决部分员工不方便订餐的问题。我们看到，如果我们没有抓住这个客户需求，一开始就认为非要做一个短讯系统，那么就会陷入例子的陷阱中。要解决这个客户需求，办法之一就是做短讯订餐系统，但更合适的办法可能就是打电话回公司让别人代订午饭了。我们很多需求开发没有做好的原因，大部分是没有把握好客户需求，直接进入软件的细节，去讨论要做什么功能，界面要怎样设计去了，而忘记了软件的根本目的是为了解决什么问题。

当我们明确客户需求后，就应该把客户需求转变成产品需求和产品组件需求，客户需求一般都是比较高层次的，而且描述也会比较简单，我们需要对软件的规格进行详细说明。一般来说，我们写的软件规格说明书都会包含产品需求和产品组件需求的。我们导出产品需求和产品组件需求的时候，要注意产品需求和产品组件需求，必须和客户需求对应起来，通常是多对多的关系。为什么要对应起来？我们要保证，软件的每一个界面，每一个功能都是有用的，都是“源自”客户需求的，这样才能保证我们做的事情都是正确的事情，防止被不相干的事情干扰。

我们经常抱怨客户的需求在变，其实80%的原因是没有把握住客户需求，其实客户经常变的是产品需求或者是产品组件需求，客户需求是很少变的，就是因为我们没有把握住客户到底想要什么、需要什么，导致我们认为客户太难“服侍”了。只有把握住客户真正的需求，我们才能抓住根本，万变不离其中。

需求开发的方法：

1.面向结构开发法，结合获取的《用户需求说明书》，可采用数据流图等分析模型，把系统功能需求、非功能需求按事件流、数据流分析方式，逐层细化到系统操作及操作数据的存储方式，如数据的输入、输出，并考虑外部接口。结合数据流图和数据字典,详细说明系统功能间的输入、输出、系统活动及约束条件 ,编制需求规格说明书。

2.面向对象开发法，使用UML辅助类图或其他分析方式来分析已获取的系统需求、用例模型、类图、数据字典等。结合图形化分析模型、类图、顺序图、关联图等进行说明，准确描述用户及系统的交互活动，编制需求规格说明书。

3.快速原型开发法，分析已获取的用户需求，增量、迭代地明确用户工作流程、约束条件等，设定需求的优先级排序，在风险较小的基础上分析、设计和实现系统构架结构或用户界面架构。结合立项时所选用生命周期，迭代进行分析活动，编制需求规格说明书。

需求开发包含的元素：

1.基于场景的元素——用户角度表现系统

用例文本、用例图、活动图、泳道图——带角色的活动图等

2.面向信息流的元素——通过处理函数进行转换

数据流图、控制流图、处理说明等

接着下来，我们将从每个SG和每个SP来详细讲解需求开发这个PA

RD有三个SG，SG1开发客户需求，SG2开发产品需求，SG3分析和确认需求。

前两个SG讲述的是需求开发由顶而下、由粗到细的过程，SG3讲述的是需求分析和确认的过程。下面详细阐述：

SG1: 开发客户需求

开发客户需求：干系人的需要、期望、约束和接口要求被收集，对其加以和解释并转化为客户需求。

SP 1.1:引导需求

引导需求：导出干系人对整个产品生命周期各阶段的需要和期望（客户需求、需求规格说明书、设计文档）、约束（前提条件如C语言、100天、开发人员掌握的技术、面向对象开发还是结构化开发等）和接口要求等。这句话要包含了几个要点：

 1)干系人（利益关系人）：干系人除了指甲方的领导、系统的最终用户，还包括使用本系统的第三方以及与本系统有交互的第三方系统的拥有者、使用者、供应商、测试人员、制造人员，与后勤支持人员等，干系人需求是决定客户需求的重要的基础等。

2)产品生命周期各阶段：干系人对系统的期望不一定只限于软件功能的，可能还包括数据的整理、资料录入、安装培训、维护要求等，干系人可能对软件生产的过程阶段（整个生命周期）都会提出他的要求，获取需求的时候，要注意干系人在软件生命周期不同阶段有什么要求。

3)需要、期望、约束、接口要求：甲方一般会对系统的目标、范围、解决什么问题、希望系统具备怎样的一些特性，满足一些什么接口要求和约束条件等，都会有大致的想法。需求调研工作，首先要注意搞清楚这些内容。

4)导出：客户的原始想法可能是不明确的，或者是客户一时难表达完整的，我们需要用一定的方法，让客户能完整无遗漏准确地表达出他的想法。通常我们可以通过原型、图示、类比、问卷等办法来导出客户的需求。

SP 1.2: 开发客户需求

开发客户需求：转化干系人的需要、期望、约束和接口要求为客户需求。

SP1.1讲述的是通过一些方法获取和记录客户和干系人原始的需求信息，而SP1.2讲述的就是把客户和干系人原始的需求信息整理成正式的客户需求，通常会包括对系统目标、范围、解决问题、软件特性、接口要求、验证和确认要求等有详细的描述。

来自客户和干系人的各种输入和需求信息，须经合并和检查是否有遗漏的需求信息，以及解决冲突（如客户的需求和其他干系人的需求之间，或客户的需求与需求之间冲突，如客户要求的功能需求与进度、成本矛盾的等）等过程，解决后并记录为客户需求，所以在冲突适当解决之后，需要转换成被认可的客户需求。客户需求可包括与验证和确认有关的需要、期望及限制。

客户需求与其他干系人的需要、期望、限制及接口可能有所冲突， 冲突的解决过程可能需要客户和其他干系人参与；

代表产品生命周期的所有阶段的相关干系人，应包括经营方面及技术功能方面的代表。因此，所有与产品生命周期相关的过程概念，都应与产品的概念同步考?。

客户需求来自信息充分的决策，同时考?需求在经营面与技术面的影响。也就是说客户和其他干系人需求要不单要考虑技术面需求（如产品的功能、性能需求等），也要考虑经营面需求（如公司的经营策略和经营计划等，如公司定价策略影响项目对成本控制的策略和需求等）

SG2: 开发产品需求

开发产品需求：对客户需求加以精炼和细化，以用来开发产品需求和产品组件需求。

SG1讲述的是导出客户需求，而SG2讲述的是由客户需求到产品需求、产品组件需求的过程。

分析客户需求并开发操作概念，以衍生更详细和精准的需求，此需求称为“产品与产品组件需求”。“产品与产品组件需求”说明产品生命周期每一阶段的相关需要。衍生需求或派生需求（法规、习惯性做法、性能需求），是由限制、对某些隐含议题的考?及某些因素而间接产生，这些议题在客户需求中并未明确说明；而这些因素是基于所选用的架构、设计，以及开发者独特的经营考?等而产生。需求须以后续的、较低阶的需求及功能架构再检查，并细化优先的产品概念。

配置需求于产品功能及产品组件，包括对象、人员及过程，并记录需求到功能、对象、测试、议题，或其他实体的追溯性。已配置的需求及功能是组成技术解决方案的基础。当开发内部组件时，须定义新增的接口，并建立接口需求。

SP 2.1: 建立和维护产品或组件需求

建立和维护产品和产品组件需求，这些产品和产品组件需求是基于客户需求的。

简单说，就是要满足客户要求，产品和产品组件应该有哪些需求；

产品和产品组件需求，是比较细致的需求，会详细描述软件与用户是怎样交互的，用户需要输入什么，系统会输出什么等都会比较详细描述出来。而客户需求一般只描述能实现什么功能、解决什么问题等，比较高层次。客户需求一般在系统实际的使用环境下或模拟的使用环境可以确认是否实现和满足要求，而产品需求和产品组件需求是对软件规格的描述，是可以用来做为验证的标准的。客户需求对应验收测试用例，产品需求规格说明书对应系统测试用例。

客户需求可能以客户术语表示，且以较不具有技术的方式描述。产品需求则是以专业术语表示这些客户需求，以方便用来进行后续的设计的决策。“质量机能展开”是此转换的范例，它描述客户期望与技术参数（产品和产品组件质量和性能、功能等）的对应关系。例如：“结实的门”可能对应到尺寸规模大小、重?、适合、湿度及共振频率。针对所需的重要的产品和产品组件所需质量和性能、功能，开发架构需求。“产品与产品组件需求”强调客户、经营，以及项目目标和相关属性(如有效性和负担能力)的满足。

根据设计决策结果派生出需求（法规、习惯性做法、性能需求），派生（衍生）需求也包括其他生命周期阶段的成本和绩效 (如生产、操作及销毁)，以与经营目标兼容（如设计提高复用，提高产品质量和生产率）。

建立并维护需求间的关连性，并考?在变更管理和需求配置时的影响。有关维护需求追溯，请参考需求管理过程域，以获得更多信息。需求间的关连有助于评估变更的影响。

SP 2.2: 配置或分配产品组件需求

分配产品组件需求。

这个SP将需求开发与技术解决方案联系起来，所有的需求应该与设计的产品组件对应起来，保证需求驱动后续的设计工作，同时也保证设计都是为了需求服务的。SP2.2是对SP2.1的进一步细化。

分配需求（为每个产品组件分配需求）依赖于设计（技术解决方案），功能需求是软件实现、还是硬件实现，是分配到产品组件的硬件还是软件，如手机产品拨打电话的功能需求，是通过触摸屏和软体实现，还是通过手机按键（硬件）的方式实现，所以产品组件的需求是依赖与设计（技术解决方案）；有分配产品组件需求就有接口需求（内部和外部接口等），有模块和组件，就有接口与界面、数据库等；

SP 2.3: 识别和定义接口需求

识别和定义接口需求。接口需求包括系统与第三方的系统的接口要求，也包括系统本身各组件、各子系统、各部分之间的接口要求。通常这些接口需求在客户需求级别的时候，并不是很明细，需要对客户需求进一步细分成产品需求、产品组件需求，然后发掘出接口需求。SP2.3也是对SP2.1的进一步深化。

SG3: 分析和确认需求

分析和确认需求：需求被分析和确认，并定义出具体的功能性需求。

分配需求后；建立操作概念和场景；建立工作流（流程）；建立功能性定义、分析需求（有些技术难度高，有些技术难度低，成本分析，进度，风险，达成一致，）加一些约束；达成一致后；做不到的需求需要删除一些需求后，需求平衡好后，才与客户承诺及确认；确认的方式：通过示范、演示、原型等方式来评审需求，以保证最终产品将会在用户环境中按照预期运行；

「分析并确认需求」特定目标的特定执行方法，支持「开发客户需求」和「开发产品需求」两个特定目标的需求开发过程。本特定目标的特定执行方法涵盖需求的分析，以及确认需求是否符合使用者预期。

执行分析，以决定为求满足客户和干系人的需要、期望、限制及接口，对原计划的操作环境会产生哪些影响。视产品的范围而定，可行性、任务需要、经费限制、市场潜力及采购策略等都必须纳入考?，并建立必要功能的定义。所有产品的特定使用形式均应考?，并产生对时间敏感的功能顺序的时间点分析。

分析的目的，在于决定可满足客户和干系人需要、期望及限制的产品概念的可能需求，再将这些概念转换为需求。与此活动同时进行的是，依据客户的输入和初步的产品概念，决定用以评估产品有效性的参数。

确认需求，以增加最终产品在使用环境中，可按照期望运作的可能性。

SP 3.1: 建立和维护操作概念及相关场景.

建立和维护操作概念及相关场景。

一般会产生如下工作产品：操作概念描述，产品或产品组件安装、操作、维护和支持概念性描述，部署概念，用例，时间表场景，新需求等。可以通过如下几步完成该实践：一是开发操作概念和场景，包括适当的功能、性能、维护、支持及销毁和部署在内的操作概念及场景。识别并开发场景，此场景须与客户及干系人的需要、预期及限制一致。二是定义产品或产品组件的操作环境，包括边界和约束。三是要审查操作概念和场景，以精炼需求并发现新需求。操作概念和场景的开发是个反复的过程。应定期举行审查，以确保其结果与需求一致。审查可采用逐步审查的形式。四是当选择产品或产品组件时，一经选定，就开发详细的操作概念，以定义产品、最终用户及环境的互动，并满足操作、维护、支持及销毁和部署的需要。

SP 3.2: 建立和维护必要的功能定义

建立和维护必要的功能定义。（分析量化用户功能需求、分析需求包括产品功能和子功能、需求分类、需求排序和确定优先级、分配客户需求、分配产品功能和性能）

一般会产生如下工作产品：功能框架图、活动图和用例，使用服务或方法标识的面向对象分析。可以通过如下几步完成该实践：一是分析和?化最终用户的功能需求。二是分析需求，以识别逻辑或功能分割(如子功能)。三基于已确定的标准(如类似的功能、性能或耦合性)，将需求分割成群组，使需求分析更容易、更便于聚焦。四是在产品组件开发的整个过程，考?具有时效性的功能的顺序（时间要求敏感或高的功能）。五是分配客户需求于功能分割、对象、人员或支持组件，以支持解决方案的整合合。六是分配功能及性能需求于功能及子功能。

SP3.1和SP3.2是对需求描述的要求，要求描述出具体需求的操作场景、上下文，具体的操作步骤，对功能的详细描述等。通常我们可以通过功能框架图、UML的Use Case图或者是序列图等来表达这些内容。

SP 3.3: 分析需求

分析需求以确认需求是必要的和充分的。

一般会产生如下工作产品：需求缺陷报告，用来解决缺陷的需求变更建议，关键需求，技术性能（或产品有效性评估的参数）度?指标；可以通过如下几步完成该实践：

1.分析干系人的需要、期望、限制及外部接口，以移除矛盾或冲突，并把它们根据相关主题组合在一起。

2.分析需求，以决定是否满足更高阶需求的目标（比如商业目标等都可以称为更高级别的需求）。

3.分析需求，以确保是完整、可行、可实现及可验证的。虽然设计决定某特殊解决方案的可行性，但分析需求可以了解哪些需求会影响后续的可行性。

4.识别对成本、进度、功能、风险或性能有重大影响的关键需求。

5.识别需要在开发过程中跟踪的技术性能（或产品有效性评估的参数）度?，以便于开发阶段时进行追踪。有关度?的用途，请参考度?与分析过程域，以获得更多信息。

6.分析操作观念及场景，以精炼客户需要、限制及接口，并发现新需求。此分析可能产生更详细的操作观念及场景，同时也衍生新需求。

SP 3.4: 分析需求以取得平衡

分析需求平衡以平衡干系人的需要和约束。

一般会形成需求相关风险的评估报告；

可以通过如下几步完成该实践：

1. 使用经验证的模型、仿真及原型等，以分析干系人的需要和限制间的平衡。.

分析的结果，可用以降低产品的成本与开发产品时的风险。

2. 执行需求及功能架构的风险评估。有关执行客户及产品需求和功能架构的风险评估，请参考风险管理过程域，以获得更多信息。.

3.研究产品生命周期概念，以分析它对需求风险的影响或风险冲击。

SP3.3和SP3.4是对需求的准确性、全面性、可实现性方面的要求，除了要取得全面准确的需求，还需要平衡约束条件，保证需求在约束条件下是可实现的。

SP 3.5: 确认需求

用各种合适的方法确认需求，确保最终产品能在用户的环境中按照设想运行。这是需求开发的最后一步了，需求导出过程中尽管用了很多办法，但需求确认的时候，仍然需要采取办法确保获取的需求是符合最终的使用场景要求。

一般会形成分析方法和结果的纪录；

可以通过如下几步完成该实践：

1.分析需求以识别最终产品不能于用户环境下适当运行的风险。

2.以产品展示(如，原型、仿真、模型、情境及场景)，以及取得相关干系人的回馈，寻求需求的充分性和完整性。有关产品及产品组件的确认及确认执行，请参考确认过程域，以获得更多信息。

3.于设计成熟时，在需求确认环境的上下文中进行评估，以识别确认发现的问题，并发现未说明的需要和客户需求。

SP3.3、SP3.4和SP3.5，通常是通过评审的方法来满足的。