################################################
需求文件是收集需求过程的产出：
收集需求过程详解链接：https://www.cnblogs.com/hemukg/p/12566131.html
################################################
一、需求文件背景
1. 需求文件相关负责人
相关方、高层级
2. 需求文件定义
需求文件描述各种单一需求将如何满足与项目相关的业务需求。
发起人、客户和其他相关方的已量化且书面记录的需要和期望。
3. 需求文件作用
（1）需求文件识别了应纳入范围的需求。并且需求文件用于证明符合项目范围。
（2）将需求与实际结果比较，以决定是否有必要进行变更、采取纠正措施或预防措施。
（3）需求文件用于发现任何对商定的项目或产品范围的偏离。
4. 需求文件完成步骤/执行时间
定期更新
（1）一开始可能只有高层级的需求，然后随着有关需求信息的增加而逐步细化。
（2）在指导与管理项目工作过程中可以识别新的需求，也可以适时更新需求的实现情况。
（3）在创建WBS过程提出并已被批准的变更的需求
5. 需求文件分类
需求文件的格式多种多样
（1）既可以是一份按相关方和优先级分类列出全部需求的简单文件
（2）也可以是一份包括内容提要、细节描述和附件等的详细文件。
前者是相关方的需要，后者是指如何实现这些需要。
把需求分成不同的类别，有利于对需求进行进一步完善和细化
6. 需求与基准
只有明确的（可测量和可测试的）、可跟踪的、完整的、相互协调的，且主要相关方愿意认可的需求，才能作为基准
二、需求文件内容
1. 高层级需求/业务需求
高层级需求见《项目章程》（《项目章程》链接：https://www.cnblogs.com/hemukg/p/12392846.html）
整个组织的高层级需要：
（1）解决业务问题或抓住业务机会
（2）实施项目的原因
2. 相关方需求
相关方或相关方群体的需要。
根据《相关方登记册》，登记不同相关方的期望和需求。
（《相关方登记册》链接：https://www.cnblogs.com/hemukg/p/12401751.html）
3. 解决方案需求
为满足业务需求和相关方需求，产品、服务或成果必须具备的特性、功能和特征。
解决方案需求又进一步分为功能需求和非功能需求：
（1）功能需求
功能需求描述产品应具备的功能，例如，产品应该执行的
<1> 行动
<2> 流程
<3> 数据
<4> 交互
（2）非功能需求
非功能需求是对功能需求的补充，是产品正常运行所需的环境条件或质量要。
例如，
<1> 可靠性
<2> 保密性
<3> 性能
<4> 安全性
<5> 服务水平
<6> 可支持性
<7> 保留或清除
（3）业务解决方案
相关方的需要。
（4）技术解决方案
指如何实现相关方需要。
5. 过渡和就绪需求
这些需求描述了从“当前状态”过渡到“将来状态”所需的临时能力，如
（1）数据转换
（2）培训需求
6. 项目需求
项目需要满足的行动、过程或其他条件，例如
（1）里程碑日期
（2）合同责任
（3）制约因素
7. 质量需求
用于确认项目可交付成果的成功完成或其他项目需求的实现的任何条件或标准，例如
（1）测试
（2）认证
（3）确认
8. 沟通需求
需求文件可能包含项目相关方对沟通的需求。
9. 资源需求
严格说，资源需求不算在需求文件之内，因为需求文件时在项目规划开始就需要的文件。
还没有提及具体资源，在完成活动资源估算后才会形成。
我们在之后，单独描述资源需求的内容。到时更新链接。
（1）资源类型
（2）资源数量
三、应用过程
需求文件**（4.1.1、4.3.3.6、4.7.1.3、见5.2.3.1、5.3.1.3、5.3.3.2、5.3.3、5.4.1.2、5.4.3.2、5.5.1、5.5.3、5.6.1.2、8.1.1、9.1.1、10.1.1.3 、11.2.1.2、12.1.1.4、12.1.3.9、12.2.1.2、12.2.3.4 、12.2.3.5、12.3.1.2、13.1.1.4）
1. 规划资源管理
需求文件指出了项目所需的资源的类型和数量，并可能影响管理资源的方式。
2. 规划沟通管理
需求文件可能包含项目相关方对沟通的需求。
3. 识别风险
需求文件列明了项目需求，使团队能够确定哪些需求存在风险。
4. 规划采购管理/实施采购/控制采购
需求文件可能包括：
（1）卖方需要满足的技术要求
（2）具有合同和法律意义的需求
非技术要求如：
<1> 健康
<2> 安全
<3> 安保
<4> 绩效
<5> 环境
<6> 保险
<7> 知识产权
<8> 同等就业机会
<9> 执照
<10> 许可证
5. 确认范围
将需求与实际结果比较，以决定
（1）是否有必要进行变更
（2） 采取纠正措施或预防措施
6. 控制范围
需求文件用于发现任何对商定的项目或产品范围的偏离。
7. 结束项目和阶段
需求文件用于证明符合项目范围。
四、更新需求文件过程
1. 指导和管理项目工作
在指导和管理项目工作过程中可以识别新的需求，也可以适时更新需求的实现情况。
2. 实施采购
需求文件可能更新：
（1）卖方需要满足的技术要求
（2）具有合同和法律意义的需求
非技术要求如：
<1> 健康
<2> 安全
<3> 安保
<4> 绩效
<5> 环境
<6> 保险
<7> 知识产权
<8> 同等就业机会
<9> 执照
<10> 许可证
3. 确认范围
记录实际的验收结果，更新需求文件。
需要特别注意实际结果比原定需求更好的情况，或者原定需求已经被放弃的情况。
4. 控制范围
如果项目范围偏离，可以通过增加或修改需求而更新需求文件。
#################################################
需求文件时项目初期就需要确定，并且需要再项目进行的过程组定期更新的。
再项目初期，我们只有项目章程中的高层级需求，需要进一步完善项目文件中所列的子项。
这里我们只提供一个《需求文件》的框架，后期项目中又完善的《需求文件》，我会更新并添加链接。
愿各位在进步中安心
2020-03-25 禾木
#################################################
需求文件**（4.1.1、4.3.3.6、4.7.1.3、见5.2.3.1、5.3.1.3、5.3.3.2、5.3.3、5.4.1.2、5.4.3.2、5.5.1、5.5.3、5.6.1.2、8.1.1、9.1.1、10.1.1.3 、11.2.1.2、12.1.1.4、12.1.3.9、12.2.1.2、12.2.3.4 、12.2.3.5、12.3.1.2、13.1.1.4）