技术需求文档，应当这么写！

需求文档是咱们在开发中经常使用的一类沟通方式和媒介，它承载着需求方的指望，同时也标记着一系列事项的生命周期。

不一样部门、不一样受众的需求文档各异，例如运营人员向产品人员提出的活动需求、产品人员向开发人员提出的功能需求、开发人员向运维人员提出的服务支撑需求、各小组内部同事之间互相提出的需求等等。

为什么须要需求文档？

大部分场景下需求提出方和需求承接方都存在不小的信息差，需求提出方经常使用的语句是“我须要作成这样”、“越快越好”、“怎么用你不用管，给我就行”、“这不是我想要的”、“我想要的实际上是那样”。

一我的常常否认本身的选择和言语的现象是存在的，不管有意或无心，但这无疑会耗费双方的时间和精力。需求文档不只能够做为双方沟经过程中的清单，还能够做为双方选择和执行的日志，有了需求文档，就可以避免因先后矛盾致使空耗的问题。同时，需求文档能够清晰地体现参与人员的劳动成果与劳动价值，是自我总结的良好依据。

需求文档通用模板参考

一百种需求有一千种提法，但需求中的事项相差却无几。这里给出了一份需求文档模板，你们能够将其用在工做当中，做为不一样人员之间的信息传递媒介。

要注意的是，需求和执行是双生相伴的，所以这里的下面这份参照文档与其说是需求文档，不如说是任务执行记录，由于它记录着这个任务从产生到执行完毕的完整生命周期。

为了方便你们理解，文档选用不一样颜色来帮助咱们区分阶段，其中：

🔲 浅粉色区块呈现的是文档的基本信息；
🔲 浅蓝色区块呈现的是需求主体与需求生命周期主体；
🔲 浅绿色区块呈现的是需求生命周期接近末尾，即将达成目的；

为何要这么设计？

相信各位见过很多的需求文档，所以对上面这份参考也有不一样的见解，可能不由会问：

• 为何设计成这样的结构？
• 怎么不用在线需求文档管理工具呢？
• 必填项和非必填项如何体现？
• 这份参考好像不能知足全部开发场景？

为何设计成这样的结构？

需求文档应当涵盖从需求产生到需求完成交付的完整过程，例如需求是在什么样的场景下产生的、到底要作成什么样、须要何时完成、以什么形式交付、需求是否可以实现、需求实现过程当中作了哪些、交付的结果是否达到预期等。

咱们能够将完整过程分为如下几个阶段，以便更好地展开工做：

🔲 需求描述
🔲 需求调研
🔲 需求评审
🔲 开发/实施
🔲 阶段验收
🔲 测试/数据验证
🔲 上线

按照这个结构，咱们可以想象工做流大抵以下：

首先需求提出方给出需求的背景、具体事项描述等信息，帮助需求承接方更好地理解，同时提出对交付时间、交付方式的指望。需求承接方收到需求信息后须要作初步的调研，了解需求实现过程当中的关键项并记录不明确的事项。

接着，双方初步接触后约定时间对需求进行评审，双方的讨论将基于调研期间得到的信息展开，在评审讨论会结束后一般会肯定需求是否能实现、需求改动项、交付方式、交付时间、最终参与人员等。

而后评审经过，需求承接方开始进行开发/实施。需求承接方要记录这个过程当中谁在什么时间作了什么事并获得怎样的结果、期间是否出现了哪些变化。

需求提出方可能会阶段性地跟进事件进展，并帮助需求承接方确认工做和工做结果没有出现误差，同时双方互换一些信息。

开发/实施接近尾声或完成后，需求方组织人员检验成果，检验经过则通知需求承接方交付/发布上线，检验未经过则作相应调整。

版权水印 - 微信公众号 Python 编程参考

除了需求背景、开发/实施相关的信息外，需求文档自己也须要提供一些基础属性，用以对需求进行整理、分类、追溯、总结等，因此在需求文档的开头设定了一些重要信息栏，例如：

🔲 需求重要等级；
🔲 需求发起日期；
🔲 需求完结日期；
🔲 需求发起人及对应部门；
🔲 需求承接人及对应部门；
🔲 需求所属的业务类型；
🔲 需求关键词；
🔲 也求所属业务的名称；
🔲 需求关注者；
🔲 需求编号；
🔲 需求名称；

团队内部能够定义统一的需求等级，例如紧急且重要的设为 A、紧急但不重要的设为 B1、重要但不紧急的设为 B2、不重要也不紧急的设为 C 等，这样你们在参与需求的时候可以合理地分配时间和资源，优先解决那些等级高的需求。

怎么不用在线需求文档管理工具呢？

市面上的需求文档管理工具繁多，Python 编程参考但愿在不依赖特定工具的状况下向你们介绍需求文档，各位在理解需求文档后再结合工做中用到的管理工具，效率定会更高。

实际上工做中老是会用到各式各样的管理工具，工具能够很好地帮助咱们关联文档、汇总信息。例如一个编号为 TK2020120101 的需求完成后，后续又衍生出针对它的维护类需求 TK2021010103 时，能够将维护类需求 TK2021010103 与 TK2020120101 关联起来，这样在管理需求文档的时候就可以直观地看到需求之间的关系和变化，具体以下图所示。

实际工做中大几率会用到管理工具，工具能够提升咱们的效率，便于咱们管理事件，借助工具是很是好的选择

必填项和非必填项如何体现？

实际上这份文档包含的区块都是必要信息，但区块中的子项能够根据实际状况省略。

首先，浅粉色区块的需求文档基础信息部分是必填的，这里的内容是整个需求的缩影，因此一个格子也不能少。

其次，浅蓝色区块的主体部分是能够省略的，例若有时候需求调研和需求评审能够放在同一时间展开，划分到需求评审便可；例如子项详细描述中的注意事项、交付要求等选项也是能够根据实际状况省略的；若是需求并不复杂，或者说时间周期也不长，那么子项阶段验收能够省略，在数据验证阶段校验便可；若是没有预上线，或者需求并不须要上线，那么能够省略浅绿色区块部分的项。

最后，若是以为上面的阶段还不足以记录完整的需求生命周期，能够根据实际状况增长阶段或子项；

这份参考好像不能知足全部开发场景？

固然，开发场景千千万万，Python 编程参考提供的这份需求文档做为基础，各位在具体使用的时候能够根据团队状况和业务状况自行调整文档项。

需求文档实例参考

虽然上面提供了一份基础模板，可是有一些读者可能还不太明白在实际使用的时候应该如何编写。下面以实际的工做需求给出一份实例参考。

阅读并吸取上面的知识后，想必聪明的你对整个需求文档的构成、设计考量和具体实践有了必定的认知，如今已经可以很好地梳理、组织需求文档了。这里做者再帮助诸位整理一下需求文档的一些细节。

需求调研研究的是什么？

需求调研是基于需求展开的实际状况探索，主要诉求是得出是否、可否等确切的结论；例如参考实例中提到的：

🔲 当前线上 Nginx 配置文件是否须要改动；
🔲 调用方是否要在更换新 Nginx 后切换调用地址；
🔲 线上服务地址权限是否能顺利得到；

需求评审讨论什么？

需求评审基于调研结果和需求背景展开，主要诉求是得出实现方式、结果、呈现方式等确切的结论，并针对那些不稳定的事项给出结果，同时也包含是否、可否等确切结论，例如：

🔲 评审项：监控项与可视化面板是否匹配
🔲 评审结果：监控项与可视化面板匹配，但要设定告警则须要单独设置面板，不影响展现；

开发实施记录哪些内容？

开发/实施项中没必要记录细节，只须要记录阶段性内容便可。一般是谁在什么时间完成了什么事，也就是 时间[事件] 这样的格式，例如参考实例中记录的：

🔲 2020-12-01[张三] - 提供 Nginx 配置文件；
🔲 2020-12-05[王五] - 在 Grafana 中导入 Prometheus 数据源并配置可视化面板；
🔲 2020-12-07[王五] - 更改域名解析；

阶段验收写什么？

阶段验收关注的是事件结果，也就是 时间[结果] 这样的格式，与开发/实施记录相似，例如参考实例中记录的：

🔲 2020-12-08[张三] - 服务切换后一切正常；
🔲 2020-12-06[张三] - Grafna 可视化面板数据；
🔲 2020-12-03[张三] - Nginx 日志已同步到 ElasticSearch 中；

上线项关注什么？

上线项关注的是上线结果和业务自己的状态，是 时间[状态] 这样的格式，例如参考实例中记录的：

🔲 2020-12-09[王五] - 服务正常正常；
🔲 2020-12-09[张三] - 数据正常；
🔲 2020-12-09[李四] - 数据正常；

这里的状态也能够理解为结果，但细细想来，仍是用状态更为贴切一些。

这里是微信公众号 Python 编程参考，若是你以为这篇文章对你有帮助，请来关注我哦。点击前往做者韦世东的技术专栏 www.weishidong.com，看更多有用知识。热门文章一览：

《几个有效应对 35 岁危机的办法》

《工程师绘图与设计实践指南》

《持续交付实践 - GitHub Actions 部署 Node 应用到云服务器》

《SSH 免密码/免用户名/免IP登陆云服务器实践》

《ElasticSearch 定时删除指定天数的数据实践》