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，通常是通过评审的方法来满足的。