需求分解与分配说明书模板.docVIP

产品需求分解与分配说明书

目的

编写本说明书的主要目的，也可指出与本本说明书相对应活动应达到的目的。

适用范围

列出有哪些角色、部门、岗位、人员在什么情况下使用本说明书。也可鉴别并简单地列出该说明书不适用的领域。

定义

列出本文档中所使用的术语和缩略语。可引用已有的数据字典，如没有则需要在此列出。例如：参见《数据字典.doc》

术语——列出在本流程中用到的关键词和专用词，并给出其含义；

缩略语——应列出在本流程中用到的所有缩略语，并给出中英文全称；另外在正文中缩略语首次出现处也要给出其中英文全称。

写作指导

系统分解和分配要明确将系统从功能和物理二方面划分为各子系统、单元、装配件、部件或设备，并明确各个部分之间在结构、电源、信号和热性能等方面的接口。分解是把大的和复杂的设计问题分解成较小的更加容易管理的问题，从而可以逐步达成解决方案。分解也能够帮助构建问题，这使得能用有序的方法达成解决方案以及同时开发系统的各个部分成为可能。应该仔细地进行分解，以便在满足其他目标的同时最佳地满足最高优先级的设计需求。

分解和分配过程基于设计需求进行，能够被分解和分配的系统各个方面是：

功能

可靠性

性能

维修和维护

可测试性

装配

人机工程

根据功能来做分解和分配是最常用的选择，但是头脑里一定要有整个系统观念和其他各个方面，这很重要。例如，当为了达到高可靠性而分解系统的时候，设计团队可以设法将模块之间的连接数量减到最少，因为这常常是低可靠性的原因。但较少的连接可能导致需要很大的模块，大模块一般缺少灵活性，难于测试和维护，并且常常成本更高。过多的小模块可能导致物料浪费、连接数量、装配、检查和测试的增加，从而引起制造成本增加。另一方面，如果模块设计得容易制造，较高的生产量可能实际上减少制造成本。而且，维护成本和后勤也是受到系统分解决策影响很大的其他方面。模块的规模是一个要素——大模块的复杂性常常阻止快速的问题隔离、诊断和修复。相反，使用很多较小的模块可能意味更多的模块失效，所以增加服务成本、备件成本等。一个通用的分解决策是硬件和软件。一般来说，有些功能既可以分配给硬件实现也可以分配给软件实现。

确定备选的分解和分配方案是一个反复的过程。一旦确定了备选方案，就必须对备选方案进行评估以确保没有功能被遗漏，并且分配给每个子系统的功能可以得到满足。成功的需求分配来自于富有经验的工程判断和对需求、系统复杂性、系统各部分的目标以及各子系统之间相互关系等方面知识的扎实掌握。有助于做分配的一种方法是功能分析。

分解和分配

画系统框图

做功能分析（按照自上向下的方式描述功能，以帮助系统工程师在细分的各个层次上完整地描述系统），按下图例子相类似的方法描述主要的系统功能，并把它们分解到越来越细层次的子功能，直到明确了独立的任务。

这些独立的任务随后被分配到不同子系统的特定单元，对这个分配，可能有几种备选方案，它们代表不同的备选设计方案。要运用权衡（Trade-off）分析来评估并选择一种方案以便进一步开发。

描述功能与接口

下一步是文档化系统分解和需求分配的备选方案（每个备选概念由上面的一个框图和下面的对应表格组成，最好有多种备选方案）以便用于权衡分析。下面表格中，系统功能可分解成由各个子系统、模块、部件及接口执行的那些功能。功能分解基于新产品对应的现有产品。必要时，要对其他类型的分解重复这一过程。

分解和分配备选方案X（只要列出有争议的点）

功能

接口

子系统1

模块1

单元1

部件1

4.8.3

部件2

部件3

部件4

单元2

部件1

部件2

部件3

模块2

单元1

部件1

部件2

部件3

单元2

部件1

部件2

部件3

模块3

单元1

部件1

部件2

部件3

单元2

部件1

部件2

部件3

单元1

部件1

部件2

部件3

子系统2

模块1

单元1

部件1

部件2

4.8.4

部件3

部件4

单元2

部件1

部件2

部件3

模块2

单元1

部件1

部件2

4.8.5

部件3

单元2

部件1

部件2

部件3

……