这通常称为“竣工”文档;互联网上有大量的信息。
我的偏好是将文档分成几个部分;每个都和另一个一样重要,但您不需要在它们上花费相同的时间。
功能设计
应用程序应该做什么?预期的行为是什么?关键的用户旅程是什么?
我喜欢为此使用use cases 或用户故事,详细程度各不相同。系统上下文图也有帮助。用例既可以是视觉的,也可以是文本的;几个小时通常足以描述一个简单的应用程序
非功能性需求
诸如安全性、性能、浏览器支持、搜索引擎优化、可访问性之类的内容 - 列出您在应用程序中拥有和未提供的内容,以便未来的开发人员知道要担心什么以及要测试什么。
概念设计
对已构建系统的高级概述,确定主要组件、集成点和依赖项。
详细设计
这是最容易改变的部分,也是维护最大的痛苦。使用 PHPDoc 是保持最新状态的好方法。
验收测试
即使您不接受测试驱动开发,将未来的开发留给应用程序工作的测试方法也是保持他们理智的好方法。理想情况下,验收测试应该是自动化的/脚本化的(例如使用 Selenium)。
已知错误
向未来的开发人员提供已知错误列表可以阻止他们拔掉头发...
所有这一切都需要大量工作 - 如此多的团队使用“低形式”的交流方式 - wiki、白板照片,甚至是团队解释设计的视频。
更正式地说,有像 UML 这样的标准可以帮助以行业标准方式捕获文档。