RD有三个SG，SG1开发客户需求，SG2开发产品需求，SG3分析和确认需求。
前两个SG讲述的是需求开发由顶而下、由粗到细的过程，SG3讲述的是需求分析和确认的过程。下面详细阐述：
SG1: Stakeholder needs,expectations,constraints,and interfaces are collected and translated into customer requirements.
干系人的需要、期望、约束和接口要求被收集并转化为客户需求。
SP 1.1: Elicit stakeholder needs,expectations,constrains,and interfaces for all phases of the product life cycle.
导出干系人对整个产品生命周期各阶段的需要、期望、约束和接口要求等。这句话要包含了几个要点：
1)干系人：干系人除了指甲方的领导、系统的最终用户，还包括使用本系统的第三方以及与本系统有交互的第三方系统的拥有者、使用者等。
2)产品生命周期各阶段：干系人对系统的期望不一定只限于软件功能的，可能还包括数据的整理、资料录入、安装培训、维护要求等，干系人可能对软件生产的过程阶段都会提出他的要求，获取需求的时候，要注意干系人在软件生命周期不同阶段有什么要求。
3)需要、期望、约束、接口要求：甲方一般会对系统的目标、范围、解决什么问题、希望系统具备怎样的一些特性，满足一些什么接口要求和约束条件等，都会有大致的想法。需求调研工作，首先要注意搞清楚这些内容。
4)导出：客户的原始想法可能是不明确的，或者是客户一时难表达完整的，我们需要用一定的方法，让客户能完整无遗漏准确地表达出他的想法。通常我们可以通过原型、图示、类比、问卷等办法来导出客户的需求。
SP 1.2: Transform stakeholder needs,expectations,constraints,and interfaces into customer requirements.
转化干系人的需要、期望、约束和接口要求为客户需求。
SP1.1讲述的是通过一些方法记录客户原始的需求信息，而SP1.2讲述的就是把客户原始的需求信息整理成正式的客户需求，通常会包括对系统目标、范围、解决问题、软件特性、接口要求等有详细的描述。
SG2: Customer requirements are refined and elaborated to develop product and product-components requirements.
客户需求是精确和详细的，以用来开发产品需求和产品组件需求。
SG1讲述的是导出客户需求，而SG2讲述的是由客户需求到产品需求、产品组件需求的过程。
SP 2.1: Establish and maintain product and product-component requirements,which are based on the customer requirements.
建立和维护产品和产品组件需求，这些产品和产品组件需求是基于客户需求的。产品和产品组件需求，是比较细致的需求，会详细描述软件与用户是怎样交互的，用户需要输入什么，系统会输出什么等都会比较详细描述出来。而客户需求一般只描述能实现什么功能、解决什么问题等，比较高层次。
客户需求一般是难以验证是否已实现的，而产品需求和产品组件需求是对软件规格的描述，是可以用来做为验收的标准的。
SP 2.2: Allocate the requirements for each product component.
分配需求给每一个产品组件。
这个SP将需求开发与技术解决方案联系起来，所有的需求应该与设计的产品组件对应起来，保证需求驱动后续的设计工作，同时也保证设计都是为了需求服务的。SP2.2是对SP2.1的进一步细化。
SP 2.3: Identify interface requirements
定义接口需求。接口需求包括系统与第三方的系统的接口要求，也包括系统本身各组件、各子系统、各部分之间的接口要求。通常这些接口需求在客户需求级别的时候，并不是很明细，需要对客户需求进一步细分成产品需求、产品组件需求，然后发掘出接口需求。SP2.3也是对SP2.1的进一步深化。
SG3: The requirements are analyzed and validated,and a definition of required functionality is developed.
需求被分析和确认，并定义出具体的功能性需求。
SP 3.1: Establish and maintain operational concepts and associated scenarios.
建立和维护操作场景及相关情景。
SP 3.2: Establish and maintain a definition of required functionality.
建立和维护功能定义。
SP3.1和SP3.2是对需求描述的要求，要求描述出具体需求的操作场景、上下文，具体的操作步骤，对功能的详细描述等。通常我们可以通过UML的Use Case图或者是序列图等来表达这些内容。
SP 3.3: Analyze requirements to ensure that they are necessary and sufficient.
分析需求以确认需求是必须和充分的。
SP 3.4: Analyze requirements to balance stakeholder needs and constrains.
分析需求平衡以平衡干系人的需要和约束。
SP3.3和SP3.4是对需求的准确性、全面性、可实现性方面的要求，除了要取得全面准确地需求，还需要平衡约束条件，保证需求在约束条件下是可实现的。
SP 3.5: Validate requirements to ensure the resulting product will perform as intended in the user's environment using multiple techniques as appropriate.
用各种合适的方法确认需求，确保最终产品能在用户的环境中按照设想运行。
这是需求开发的最后一步了，需求导出过程中尽管用了很多办法，但需求确认的时候，仍然需要采取办法确保获取的需求是符合最终的使用场景要求。
SP3.3、SP3.4和SP3.5，通常是通过需求评审来满足的。
CMMIonline 版权所有
欢迎转载，但请给出指向本网站的链接：
http://www.cmmionline.net
版权声明见：
http://cmmionline.net/forums/thread/1340.aspx