architecture - 您如何描述您的解决方案/系统？

Question

我即将编写一些项目经理、开发人员和业务分析师会使用的标准/指南和模板。目标是更好地理解正在开发或已经开发的解决方案。

其中一部分是提供有关记录解决方案的标准/指南。例如。记录解决/满足业务案例/用户需求的软件。

现在，作为一名程序员，我可以看到不可能规定并说“每个解决方案都必须使用 Y 定义 X 并根据 Z 呈现它。”，因为 X Y Z 并不总是适用等。

然而，我知道，即使对于我的爱好项目，我总是以一种或另一种方式描述我的解决方案，模块/组件、源代码注释、API、数据库模型、使用的一些分类法、日志日志、xml 格式等。

因此，为了继续我的工作，如果您能分享您记录的内容以描述您的解决方案(最好还有如何以及为什么)，我将不胜感激 - 我知道它会因许多事情而有很大差异，但任何一般或具体答案很有趣。谢谢。

更新
不清楚，但我不是指 X Y Z 的用户需求。我指的是系统可能拥有的所有可能类型的文档。因此，将其解读为“不可能说明每个解决方案都必须具备:所需框架列表；服务器软件的操作手册；所需的主数据；用户需求与测试的矩阵；用户界面规范。虽然产生这样一个有限的一组需求，很难清晰和准确，因为最重要/相关的内容因项目而异。

另外，我很久以前就问过这个问题，但从未接受过答案，对此感到抱歉。也许，既然这是一个悬而未决的问题，那么作为社区 wiki 会更好吗？

Answer 1

文档始终是任何项目中最棘手的部分。如果您想重新开始，那么您可能需要查看 Domain Driven Design .

如果您有正确的模板，使用故事模板会非常有益。

作为 [X]
我要 [是]
这样 [Z]

类似地，您可能想查看 Use Cases