Req. Development & Mgt. Process 需求开发与管理过程Prep分配需求ed by拟制陈刚Date日期2006-05-16Reviewed by 评审人SEPG teamDate日期2007-4-20Approved by批准田松涛Date日期2007-4-24Revision Record 修订记录Table of Contents 目录1Purpose 目的 (5)2Scope 范围 (5)3Abbreviations and Acronyms 术语和缩略语 (5)4Policy 方针 (5)5Process Description 过程描述 (5)5.1Roles and Responsibilities 角色和职责 (6)5.2Entrance Criteria 入口准则 (6)5.3Input 输入 (6)5.4Activities 活动 (6)5.4.1Summarize 总述 (6)5.4.2Flow Chart 流程图 (7)5.4.3Requirements Development and Validation 需求开发及确认 (8)5.4.4Trace Requirements and Requirements Management 需求跟踪和管理 (10)5.5Output 输出 (11)5.6Exit Criteria 出口准则 (11)6Resource and Tools 资源与工具 (11)7Configuration Management and Assets 配置管理和资产 (11)8Training 培训 (11)9Process Measurement 过程度量 (11)10Tailoring Guidelines 裁剪指南 (12)11Verification 验证 (12)12Related Process 相关过程 (12)13Reference Materials 参考文献 (12)Table List 表目录表格1术语与缩略语 (5)表格2角色和职责 (6)Figure List 图目录图表1需求开发与管理过程 (7)1 Purpose 目的为确保文思创新软件技术有限公司（简称文思创新）在软件开发项目中的工作产品质量稳定，对需求开发和需求管理过程进行规范化描述，特制定本文档。

需求开发是为了准确地获取客户方下发的需求，并对获取到的需求进行正确的理解和分析，最终形成明确的产品需求，以指导后续的设计工作。

需求管理是为了有序地对需求进行管理和控制，并确保需求之间的双向追溯性以及需求与项目计划和工作产品间的一致性。

2 Scope 范围本文档适用于南京文思创新软件技术有限公司中采用瀑布、迭代软件开发模型的软件项目。

读者为项目组成员、项目管理人员和其它相关人员。

3 Abbreviations and Acronyms 术语和缩略语4 Policy 方针1、要确保项目的参与者理解需求，并获得项目的参与者对需求的承诺。

2、要有需求跟踪矩阵来维护需求的双向追溯性，并且当需求发生变更时，及时更新需求跟踪矩阵。

3、在整个需求开发管理过程中，项目经理需时时考虑关键任务和商业驱动，并在必要时调整工作；5 Process Description 过程描述5.1 Roles and Responsibilities 角色和职责5.2 Entrance Criteria 入口准则项目已启动5.3 Input 输入（未定）《项目启动报告》等任何与用户需求相关的材料《产品设计规格》5.4 Activities 活动5.4.1 Summarize 总述本文档包含需求开发和需求管理两大过程。

其中需求开发过程从项目启动初期到所有需求文档开发结束；需求管理过程的启动略晚于需求开发过程，且和需求开发过程迭代进行，并延续至项目结束。

两大过程的具体活动描述见如下文档。

5.4.2 Flow Chart 流程图图表 1 需求开发与管理过程5.4.3 Requirements Development and Validation 需求开发及确认项目启动后，项目经理需识别该项目的需求来源并确定提供需求的客户方接口人，并与客户方接口人明确需求下发的方式及需求接收的准则并将其文档化，在获得双方认可之后纳入配置库，以作为我方人员对《产品设计规格》确认的准则。

5.4.3.1 需求澄清活动项目经理获取《产品设计规格》之后，将其纳入配置库并邮件通知项目组成员。

待项目组成员（包括开发、测试、资料）经过初步分析之后，客户方接口人需指定客户方人员进行需求澄清活动，以保证项目组成员对需求理解的正确性，一致性。

需求澄清的方式包含但不限于如下形式：1）需求澄清会：由客户方人员在需求澄清会议上讲解需求功能点。

我方对需求的疑问及需求答疑需以会议纪要的形式记录；2）需求疑问的文档跟踪：我方人员需定期或事件驱动式整理并文档化需求疑问，并及时将需求疑问的答疑结果和客户方确认。

如上所有的文档需纳入配置库进行管理。

需求澄清活动的内容包含但不限于如下内容：1）讲解《产品设计规格》中涉及到架构需求，以帮助我方人员理解所需实现的功能对架构需求的影响；2）讲解功能性需求和质量属性需求（例如性能、效率、安全性、互操作性等）的具体描述，包括其中量化的功能需求是否合理，以保证我方人员对其中的操作概念和场景描述理解的正确性；3）帮助我方人员理解对于性能、产品架构等有重大影响的关键性需求，并就需求的优先级达成共识；4）讲解接口需求定义（包含内部接口和外部接口），保证接口定义的完整性和兼容性；5）对于一些理解较困难或容易产生歧义的需求，客户方需进一步通过原型图，数据模拟图（包括数据流图、实体关系图、状态转换图等）等，来帮助我方进一步理解需求；对于需求澄清活动中发现的需求类缺陷，待客户方修改完成后，项目经理需及时将最新的《产品设计规格》在配置库上予以更新。

5.4.3.2 评审及确认《产品设计规格》需求澄清活动结束后，我方人员需对更新后《产品设计规格》进行进一步的评审，以保证需求的完整性，正确性，并确保该文档足以指导后期的需求开发活动。

《产品设计规格》评审活动结束后，项目经理按照项目前期确定的需求接收准则对《产品设计规格》进行确认，确认的内容可以包括但不限于如下内容：1)《产品设计规格》是否按照双方约定的形式下发；2)《产品设计规格》下发的时间点是否存在延期，并说明延期存在的相关风险；3)《产品设计规格》的描述是否达到前期约定的接收标准；4)《产品设计规格》的评审缺陷是否修改闭环，且该文档是否能够指导下一阶段的需求开发活动；项目经理需及时将需求确认的情况反馈给客户方，在得到双方的确认通过之后，项目组配置管理员对定稿后的《产品设计规格》进行基线化。

《产品设计规格》基线化之后下发的需求均作为需求变更进行处理，具体的需求变更的流程请参考《配置管理过程》。

5.4.3.3开发《软件需求规格说明书》《软件需求规格说明书》是界定客户的最终需求，并用技术语言对《产品设计规格》中的需求描述做进一步的细化描述。

编制的目的是为了使客户和软件开发者双方对该软件的初始规定有一个共同的理解，指导后续设计活动。

我方开发人员根据基线后的《产品设计规格》，按照指定的模板撰写《软件需求规格说明书》。

开发人员在开发《软件需求规格说明书》的时候需要考虑如下内容：1)识别需求的逻辑、类似功能或者质量属性、设计限制条件、潜在的衍生需求等，以此准则来进行进一步的需求划分，并在需求划分的过程中及时与客户接口人进行确认；2)按照需求划分为每个产品构件分配需求，如有必要还需进行更细化的分配（如子功能或者支持组件）；3)随着产品或产品组件的选择，开发详细的操作概念场景，以定义产品、最终用户及环境的相互作用，以满足操作、维护、支持和处理的需要；4)识别并文档化功能之间或对象之间的接口需求，包括内部接口、外部接口、软件、结构件、产品生命周期过程中的接口（比如测试过程需依赖的物理接口、设计过程中受相应技术的影响产生的新接口等等），并持续维护接口需求；5)定义产品或产品组件的操作环境，产品的相关配置项、网络环境、服务器环境等；6)识别并文档化技术性能的度量以便在开发阶段可以对其进行跟踪。

项目经理可以根据项目情况将如上内容纳入评审checklist，作为评审《软件需求规格说明书》的关注点；5.4.3.4 评审《软件需求规格说明书》《软件需求规格说明书》完成之后，项目经理组织相关人员进行《软件需求规格说明书》的评审活动，参与评审的人员包括但不限于项目组成员、及客户方相关人员。

《软件需求规格说明书》的评审除了关注评审checklist列的内容之外，还需满足如下要求：1)需求的说明清楚、恰当，没有二义性；2)需求的说明完备；3)需求之间彼此一致；4)需求不重复；5)适宜于实现；6)可以验证（例如，可以测试）；7)可以跟踪。

此评审过程可能会引起《产品设计规格》评审和开发《软件需求规格说明书》两个活动的反复进行。

评审活动结束后，若没有达到项目计划阶段确定的质量要求，则由项目经理及项目骨干人员经过分析之后决定是否进行重新评审；若评审通过，项目经理则根据《产品设计规格》及《软件需求规格说明书》建立《需求跟踪矩阵》，从而保证来源需求到它的较低层次需求的溯源性，和从较低层次的需求到它们的来源需求的溯源性。

5.4.4 Trace Requirements 需求跟踪5.4.4.1 维护需求的双向追溯性及与项目的一致性随着项目的开展，为了保证需求的完整性和一致性，项目经理需通过《需求跟踪矩阵》维护需求之间及需求和工作产品之间的关系。

项目组在需求跟踪活动中最低的执行标准为：《产品设计规格》—《软件需求规格说明书》—设计文档—代码；《软件需求规格说明书》—测试方案—测试用例；项目过程中，项目经理通过项目监控（PMC）过程时时监控需求跟踪活动，以识别项目计划、工作产品与需求之间的不一致性，并针对不一致的情况识别不一致的来源、条件和理由；同时也需识别由于需求变更而导致的必须对项目计划、活动和工作产品做出的变更，并启动纠正措施。

同时，项目经理需及时更新《需求跟踪矩阵》，以体现更新的工作产品和需求之间的对应关系；5.4.4.2 管理需求变更项目过程中，项目经理通过项目监控（PMC）过程时时识别需求变更。

针对识别的变更需求（需求类的变更，设计文档类的变更，代码类的变更），项目经理组织项目相关干系人参与对需求变更的影响性分析，分析的内容包括但不限于如下内容：1）需求变更的工作量；2）需求变更所影响的范围；3）实现需求变更存在的技术风险；4）实现需求变更可能对进度、质量、成本带来的风险；分析完成之后，需求提交人将相关性影响分析按照需求变更单（CR）模板中的要求填写，对需求变更的具体操作流程请参考《配置管理过程》。