锐客网

  1. 首页 > 睿知 > >

如何才能写出好的软件设计文档？ 软件设计文档模板

生活知识睿知

软件设计文档模板(怎样才能写出好的软件设计文档？)
作为一名软件工程师，我花了很多时间阅读和编写设计文档 。经过上百份文档的磨练，我发现优秀的设计文档和项目的成功有着密切的关系 。
本文将介绍如何撰写一份优秀的设计文档 。
为什么要写设计文档？
文档也是技术规范，用来描述你打算如何解决问题 。已经有很多文章解释了为什么设计文档应该写在编码之前 。这里不再赘述，但我想再补充一点:
设计是确保工作正确完成的最有用的工具 。
该文档的主要目的是迫使您仔细思考设计并收集他人的反馈，以便更好地完成您的工作 。一般认为 ， 设计文档的目的是让别人了解某个系统，或者作为参考文档 。这些只是设计文档有益的副作用，但绝不是其根本目的 。
根据经验 ， 如果你的项目需要一个人月或更长时间，那么你应该写设计文档 。此外，一些小项目也可以受益于迷你设计文件 。
但是 ， 不同的工程团队，甚至是同一个团队的工程师，写设计文档的方式是不一样的 。接下来，我们来谈谈优秀设计文档的内容、风格和流程 。
设计中应该包括哪些内容？
设计文档描述了问题的解决方案 。因为每个问题的性质不同，设计文档的结构也不同 。
这是一份清单 。你至少可以考虑在文档中包含这些内容 。
头衔和角色 。
文档的标题、作者(应该与计划参与项目的人员列表相同)、文档的审阅者(我们将在“过程”部分详细讨论)以及文档的最后更新日期 。
摘要
摘要可以帮助公司的每个工程师理解文档的内容，决定是否继续阅读文档的其余部分 。摘要最多可包含3个段落 。
背景
描述要解决什么问题，为什么需要这个项目 ， 需要哪些知识的人来评估这个项目，以及它与团队的技术战略、产品战略或者季度目标的关系 。
目标和非目标
目标应包括:
描述项目对用户的影响——你的用户可能是另一个工程团队或者另一个系统 。
指定如何使用度量来衡量项目的成功——如果能链接到度量仪表板就更好了 。
非目标同样重要 。它们用来描述项目解决不了什么问题，让大家达成共识 。
里程碑
一系列可测量的检查点，通过这些检查点，你的项目经理和你的老板可以大致知道项目的每个部分何时完成 。如果项目时间超过1个月，我建议你把它分解成面向用户的里程碑 。
设置里程碑时，可以使用日历日期，考虑到延误、节假日、会议等因素 。例如:
开始日期:2018年6月7日
里程碑1-在黑暗模式下运行新系统MVP:2018年6月28日
里程碑2-抛弃旧系统:2018年7月4日
End:在新系统中增加新功能X，Y，Z:2018 . 7 . 14
如果其中一些里程碑的ETA发生了变化，就需要在这里添加【更新】，相关人员可以很容易的看到更新的内容 。
目前的方案
除了描述当前的实现，还应该举例说明用户如何与系统交互以及数据如何在系统中流动 。
这时候可以用用户故事 。记住，你的系统可能有不同类型的用户，他们的使用场景也不尽相同 。
拟议方案
有人称这部分为技术架构 。这一部分也可以通过用户故事来体现，用户故事可以包含多个子部分和图表 。
从大图开始，然后补充细节 。确保即使你在荒岛上度假，团队中的其他工程师也能按照你的描述来实现解决方案 。
其他选择
在提出上述解决方案的同时，有没有考虑过其他的解决方案？替代品的优缺点是什么？你是否考虑使用第三方解决方案——或者开源解决方案——来解决问题，而不是构建自己的解决方案？
以及监控和警报
人们往往把这一部分当作事后的想法，甚至直接忽略 。但是问题发生后，他们很着急，却不知道该怎么办，也不知道为什么会出现这些问题 。
跨团队影响
这样会不会增加倒班待机和DevOps的负担？
它的成本是多少？
会增加系统延迟吗？
会不会暴露系统安全漏洞？
会带来哪些负面后果和副作用？
支持团队应该如何与客户沟通？
讨论
此部分可以包含您不确定的任何问题、您希望阅读文档的人一起权衡的有争议的决定、对未来工作的建议等等 。
的详细范围和时间表
本部分的主要读者是参与项目的工程师、技术主管和管理人员 。因此，这一部分放在文件的末尾 。
本质上这就是项目计划的实施方法和时间分解，可以包含很多内容 。

推荐阅读


上一篇：如何辨别野生黑枸杞的真假

下一篇：四大教哪四个 四大教主