需求开发过程域

本过程域要实现以下目标：
1）确定顾客需求；
2）开发出与顾客需求一致的产品需求，并得到用户确认。
很多开发人员进行需求开发时，关注点仅聚焦在功能、性能、接口这些产品级需求，而常常忽略了用户直接或间接提出的操作简单、界面美观、安全可靠等非功能需求，而这也是本过程域所强调的——“需求开发过程域涉及所有顾客需求而不仅仅是产品级需求，因为顾客还可能提出特殊设计要求”。
除此之外，标准还强调，“除顾客需求外，所选择的设计解决方案也可能产生产品需求和产品部件需求”。这也提醒开发人员，软件需求不仅会来自顾客，也有可能会来自开发组织自身。

专用实践 1.1 引出需要
本实践要求开发人员利用技术演示、模型或原型、质量功能展开等技术手段引出顾客以及其他利益相关方对于软件的各种需求。
这一实践叫“引出”而不是“确认”需要。“引出过程不只是收集需求，更需要积极地标识顾客未明确提出的额外需求”，所以对于开发人员来说，绝不仅仅是就已有的需求项和顾客以及其他利益相关方讨论、明确需求的细节，而是要挖掘出顾客没有在既有的需求描述中列出的需求内容。
必要时，开发人员应就标准所提及的“可能不能被用户标识的需求来源”主动向顾客以及其他利益相关方询问，以引出新的需求。
访谈并不是唯一的技术手段，标准给出很多种技术：
—技术演示。
—接口控制工作组。
—技术控制工作组。
—项目中间评审。
—提问单、访谈和从最终用户处获得的运行场景。
—运行的逐步检查和最终用户任务分析。
—原型和模型。
—头脑风暴。
—质量功能展开(QFD)。
—市场调查。
—Beta测试。
—从诸如文档、标准和规格说明等来源的摘录。
—现有产品、环境和工作流模式的观察。
—使用案例。
—业务案例分析。
—逆向工程 （对传统产品）。
—用户满意度调查
开发人员应当尝试多种技术手段，直至找到对当前项目和当前用户最合适的一种或几种技术结合，以达到引出顾客需要的最佳效果。

专用实践 1.2 开发顾客需求
本实践要求整理已经获得的所有需求信息，形成最终的顾客需求。
“在文档化已识别的顾客需求集时，应整理来自利益相关方的各种输入，获得遗漏信息，并解决其中的矛盾”，这就是本实践的主要活动，整理、补遗、统一顾客需求。
这里所说的利益相关方，还应该包括组织中的行政领导和技术领导，因为“代表产品生存周期各个阶段的利益相关方应该包括业务和技术职能”，所以他们也应当是不可或缺的利益相关方。
顾客需求不仅包括功能、性能、接口等产品级的需求，还应包括“验证和确认的需要、期望和限制”，这也就是GJB438B软件研制任务书中的“验收和交付要求”中的内容。

专用实践 2.1 确定产品需求和产品部件需求
本实践要求在已经确认的顾客需求的基础上确定软件产品需求。
软件产品需求和顾客需求是基于不同的视角，表述的方式也不尽相同——顾客需求可以用顾客的术语表示，可以是非技术性表述；产品需求是用技术术语表述的这些需求。
所以，应“使用产品和产品部件的设计所需的技术术语”来开发软件产品需求。
做好需求开发，是为了更好地进行软件设计。在实施本实践的过程中，要手中握着顾客需求，眼中看着软件设计，脑中想着产品需求。
建立软件产品需求之后，就要“建立和维护需求间的关系，以便在更改管理与需求分配间加以考虑”。
在维护需求双向可追溯性时，不仅要从顾客需求，产品需求，设计，编码，测试，这样一路追踪下去，还应该考虑需求间的关系。因为需求可能不是独立的，存在相互依赖关系。我们在需求追溯时描述清楚这种需求间的相互影响关系，这样在实施需求变更时，可以清楚地追踪到受变更的这个需求影响的其它需求，以及这些需求所对应的软件设计、代码和测试等产品；在需求分配时，也会帮助我们把那些强影响关系的多个顾客需求组合在一起，建立新的“功能性定义”需求，分配给产品部件。

专用实践 2.2 分配产品部件需求
本实践要求将已经确定的产品需求，包括功能需求和非功能需求，分配到产品部件。
正如标准中所说，“已确定解决方案的产品部件的需求包括为满足需求的产品性能分配、设计约束和功能”，就是指在分配产品部件需求时，不仅要考虑功能需求，更要考虑性能需求和设计约束。
而且，“必须将性能划分为对每个产品部件的唯一分配，作为一种导出需求”。
性能需求必须要划分到软件功能模块当中，如果在需求规格说明当中仍然存在完整的性能需求描述，说明我们的需求开发工作还没有完成。
本实践最后的一步工作是在分配好的软件部件需求之间建立起依赖关系，这样一旦出现需求变更，在实施变更时就要同时考虑受影响的需求，避免顾此失彼，引入新的缺陷。

专用实践 2.3 标识接口需求
本实践要求标识出软件产品的外部和内部接口需求。
除此之外，“还应标识与产品有关的生存周期过程的接口。这些接口的例子是与测试设备、支持系统的接口”。
我们要开发的接口，不仅包括产品的外部接口和内部接口，还应包括与生存周期过程有关的、可能产品实现本身功能不需要的接口，比如测试接口。这个时候如果不考虑，可能会造成测试阶段的一些任务受到很大阻碍。

专用实践 3.1 制定运行方案和场景
本实践要求建立软件产品的运行方案和运行场景，以更好地进行需求分析。
对需求进行分析，必须要结合软件将来要应用的场景。和实际运行场景脱离的需求分析，一如沙中城堡，空中楼阁，这样的分析结果不能让人放心，可能会带来较多的变更。
定义软件产品的运行场景时，不仅要考虑正常的功能性的使用场景，还应考虑场景的“边界和限制”，即该场景已经隐含了哪些限制条件（通常我们假设外在因素——无论是人的因素还是环境的因素——对我们的产品功能实现没有任何影响），想清楚这些，对于产品的设计和测试都将会有很大帮助。
运行方案和场景的开发是一个迭代过程，它们会随着需求分析和设计的逐步深入而逐步细化。所以应定期地对它们进行评审，以确保它们与需求一致。

专用实践 3.2 建立必需功能性的定义
本实践要求对软件产品的功能进行分析和量化。
使用功能结构（全局的功能定义）、活动图（或流程图）和用例（单个功能定义）是做好分析和量化最终用户所需功能的最佳手段。
功能分析应完成以下任务：
1）标识逻辑的或功能的划分（例如子功能）。
2）按已建立的准则将需求分组（例如，类似的功能、性能或耦合度）。
3）对功能进行关键等级排序。
4）将顾客需求分配到功能划分、性能、接口、数据要素、人员以及其它支持要素。
5）将顾客的功能和性能需求分配到软件的功能和子功能。

专用实践 3.3 分析需求
本实践要求分析需求的充分性和必要性。
这些分析活动，包括：
分析需求间的相互影响，排除矛盾；
分析部件需求是否满足产品需求，产品需求是否满足系统需求；
分析需求描述是否满足需求验收准则——完备、可行、可实现、可验证；
标识关键需求；
结合SP3.1的实践活动，分析在已建立的运行方案和场景上我们定义的产品需求是否满足。

专用实践 3.4 分析需求以达到平衡
本实践要求分析需求时应兼顾各个利益相关方的需求，力求平衡。
显然这一实践是SP3.3的补充或者延伸。SP3.3着眼于需求本身的分析，本实践则着眼于需求给项目带来的影响分析。
需求对项目可能的影响一旦分析清楚，我们就通过风险管理过程域对其进行控制。

专用实践 3.5 确认需求
本实践要求与用户一起确认需求。
我们的一些组织通常确认需求的手段都是和用户一起评审需求规格说明，但是由于不注重实效，这类评审都成了形式化的过场。虽然不能否认该组织已经执行本实践活动，但是“确认”的有效性肯定会打个折扣。特别是用户可能自己都不清楚的自己的需求时。
标准中给出的需求确认技术包括：分析、仿真、原型化、演示。我们如果不能抓好评审的绩效，不妨采用以上一种或几种手段来确认需求。