我即将编写一些项目经理，开发人员和业务分析师将使用的标准/指南和模板。目标是更好地理解已经或正在开发的解决方案。
其中一部分是提供有关记录解决方案的标准/指南。例如。记录解决/满足业务案例/用户要求的软件。
现在，作为一名程序员，我可以看到，不可能指示并说“每个解决方案必须使用Y来定义X并根据Z来呈现它”，因为X Y Z并不总是适用等。
然而，我知道即使对于我的爱好项目，我总是最终以这样或那样的方式描述我的解决方案，模块/组件，源代码注释，API，数据库模型，使用的一些分类，日志日志，xml格式等..
因此，为了继续我的工作，如果您能够分享您的文档以描述您的解决方案（最好也是如何以及为什么），我将非常感激 - 我知道它会因很多事情而有很大不同一般或具体的答案是有意义的。感谢。
更新 目前尚不清楚，但我没有提到X Y Z的用户要求。我指的是系统可能具有的所有可能类型的文档。因此，将其视为“无法说明每个解决方案必须具备：所需框架的列表;服务器软件的操作手册;所需的主数据;用户需求与测试的矩阵;用户界面规范。虽然有必要生成这样的有限一套要求，很难清晰和准确，因为项目与项目之间最重要/最相关的是什么。
另外，我刚才问了这个问题，从未接受过答案，对不起。也许，既然这是一个悬而未决的问题，那么作为一个社区维基会更好吗？
答案 0 :(得分：6)
如果您的这个项目将享受任何长寿，您可能想要开始考虑使用一些行业一致的方法。最后，您可能会花费更多时间，最终可能会得到相同的最终结果。
它还取决于您所谈论的文档级别： 有关基于应用程序的体系结构指导，请查看Microsoft Application Architecture Guide 2.0（最近发布）。
如果它低于此级别，请从SandCastle开始，然后根据其生成的内容进行逻辑扩展。
就个人而言，我喜欢从交互图开始，只是简单地展示系统的所有组件如何相互作用，然后将每个组件分解为类。将类分解为序列图，并继续运行，直到达到方法级别的状态图表，或者对于您的项目而言是低的。
如果它是您需要的更高级别，请查看我之前的帖子：Enterprise, Systems and Application Architecture (best Practise)
在一天结束时，只要它对阅读它的人来说是合乎逻辑的，并且它是有用的（而不是你必须提供的东西，而且永远不会再使用它）你已经做得对
更大的问题通常是使文档保持最新。这将很快带您进入流程和程序创建/改进任务。
答案 1 :(得分：4)
文档始终是任何项目中最棘手的部分。如果您想重新开始，那么您可能需要查看Domain Driven Design。
如果您拥有正确的模板，使用故事模板可能非常有用。
作为 [X]
我想 [Y]
以便 [Z]
您也可以查看Use Cases
答案 2 :(得分：2)
使用当前域的字词。如果存在通常使用的业务域字，则在文档和代码中使用相同的单词。如果存在通常使用的编程术语（例如众所周知的设计模式），则在编写代码和记录技术细节时使用它。
要记录程序的工作方式，作为用户界面设计的一部分，我会生成图片序列（纸上或powerpoint），显示用户如何使用用户界面执行任务。这是每个人都能理解的通用语言，从用户到客户，从经理到程序员。
答案 3 :(得分：1)
很遗憾！
但是，如果您的指南适用于经理和开发人员，那么您使用的语言与您提供的语言一样重要。避免使用流行语和营销术语（Here's a good list!）
我个人觉得图表和图纸有助于强化想法，预期用户与系统交互的流程图可能有助于更好地呈现系统所谓的要做的事情。 （当然，深入分析系统如何实现这一目标！）
答案 4 :(得分：1)
要扩展项目的范围，最好使用域名进行沟通。对于需求发现，prototype tools可用于快速构建UI以确保需求得到充分理解。如果您的目的是找到记录解决方案的最佳方式，我认为它确实与solution architecture有关。 我认为IEEE 1471标准提供了一种记录软件架构的整体方法。另请查看perspectives and viewpoints方法。当然，您可以使用您喜欢的UML工具来完成它。
答案 5 :(得分：1)
基本上有很多方法可以为项目做文档。我过去使用过的2种方法是1）用例驱动开发，2）测试驱动开发。由于我只使用过一次测试驱动开发，我建议如何使用用例驱动开发。
这里的关键是彻底使用UML表示法。用户，业务分析师和开发人员会说不同的语言（显然），而您尝试做的是使您的文档具有意义。有3个基本文件是关键。
业务规格 - 本文档由用户制作，不受任何干扰或与开发团队协商。为什么？因为这个文档需要纯粹捕获用户需要的东西。例如，用户想要一个程序来煮咖啡。现在必须手动打开用户的咖啡机。用户的大脑需要时间在早上运行所有气瓶。
软件需求规范 - 这是分析师将用户需求细分为功能规范的地方。分析师根据用户的需求创建流程。这是您开始使用UML的地方。从用例和活动图开始，了解系统的感受。获取其他派生规范，如安全要求和基础架构约束等其他需求。
软件设计说明 - 这是架构或解决方案设计人员为设计满足要求的解决方案而生成的技术文档。架构师细分功能规范并将流程转换为技术规范。每个用例都可以分解为序列图和通信图。您可以使用这些图表来开始为类创建函数。这些图可用于开发类图。您可能知道状态机打破了类图，但我通常不会那么远。您还可以使用组件结构记录整个体系结构并在本文档中分解其组件。该文档还可以包括系统将要放入的部署基础结构。
将这3个文档结合使用可以帮助读者更好地理解系统中的工作原理。程序员可以了解技术规范的来源，以及最终如何运作。如果你不能让程序员理解技术规范以便做出正确的功能，那么不妨告诉他们最终需要如何运作。
为了与来自不同级别的团队成员（例如，用户，经理，业务分析师，解决方案架构师和程序员）进行协调，我创建了一个矩阵，用于连接业务规范，功能规范和技术/设计规范。矩阵还将包括将与要测试的元素协调的测试模块。在实现V-Model开发方法时，矩阵非常有用。
矩阵示例： “商业需求A” - ＆gt; “功能规格A”和“功能规格B” “功能规格A” - ＆gt; “组分A”，“组分B”和“组分C” “组分B” - ＆gt; “A级”和“B级”
当然，这在电子表格上看起来总是更好。
答案 6 :(得分：0)
也许是因为我刚读过它而且它仍在我脑海中嗡嗡作响，但我认为值得一读37signals Getting Real。虽然它是关于启动一个项目，但我（作为程序员）对文档的方法非常满意。这不是每个人的口味，但如果其他人都参与其中，那么它甚至可能使文档变得愉快。我发现了。
答案 7 :(得分：0)
以下列出了我认为在描述解决方案时有意义的事情。我把它变成了维基，所以请加入并挑战并添加。
也感兴趣： 1.安全性（解决方案的哪个区域受到安全，密码/加密等） 2.数据传输（磁盘/网络之间传输什么？
的变量答案 8 :(得分：0)
TOGAF（开放组架构框架）定义了一种＆＃34;方法＆＃34;建筑师应该如何定义解决方案。 TOGAF的一部分还涉及定义作为建筑项目的一部分应该产生哪些输入和输出。
但是，对于您需要哪些文档的问题，应由不同的人（BA，程序员，测试人员，经理等）共享，您应该查看TOGAF中的Views和ViewPoints。您提到的所有这些人都是您的利益相关者，而观点和ViewPoints可以解决利益相关者的问题。所以，我鼓励你去看看View和ViewPoints。