我们总是编写函数或类，它们的逻辑非常复杂。 如果没有这些结构的规范，那么即使我们自己也很难掌握这些结构。
如何编写复杂函数和类的规范？
请告诉我一些你自己的经历，但不仅仅是一些链接，谢谢。
答案 0 :(得分：13)
我发现函数规范的最大挑战不是直接格式，而是让它们与驱动它们的东西（需求）和构建它们的东西（测试用例，文档）保持同步。
出于这个原因，我更倾向于使用模型驱动的方法处理这个问题，而不是纸张驱动的方法。
我使用UML建模工具（Sparx Systems的Enterprise Architect，但许多工具也可以工作）在一个地方捕获项目的所有工件并在它们之间创建可跟踪性。在Enterprise Architect中，我可以创建从需求工件到设计工件的可追溯性（例如），只需将它们放在同一个图表上，然后用鼠标拖动创建一个连接器即可。
我的“功能规范”实际上是活动图的集合，系统中每个用例一个。每个用例都与一个或多个需要该用例的要求相关联。即使最终用户也能轻松地遵循活动图并对其进行验证（让最终用户阅读，更不用说理解和验证传统的纸质功能规范有多容易？）
以类似的方式，我可以从我的活动图（用例）创建可追溯性到特定的设计工件，如类图。
QA可以对测试用例进行建模，并创建从测试用例到用例的可追溯性。这样，我们看看是否有任何用例没有测试用例（或者没有足够的测试用例）。
作为一种工具，Enterprise Architect的优点在于所有这些工件都存储在SQL数据库中，因此我可以运行一些随着时间的推移而构建的查询，以查找没有跟踪它们的工件。
答案 1 :(得分：11)
结帐Joel on Software。并且here。并且here。甚至还有一个真实世界example。
答案 2 :(得分：5)
答案 3 :(得分：0)
我看到上面有一些关于链接到Joel的内容的投诉，而不是内联文本，所以这是我对他所说的内容的看法。
在最高级别，功能规范需要传达计划旨在为消费者或客户做的事情。我和Joel 100％合作：严格使用的英语（任何！）语言是一个非常强大的工具，所有客户都将成为消化专家。 UML的专家不是。
顶级功能规范文档（FSD）可以提供一个逻辑框架，用于捕获人们可以轻松理解的逻辑模型中的系统需求。
纯粹的需求文件 - 在FSD之前的东西 - 是一个难以处理的鱼。很少有人能够在心理上区分什么是要求和什么是解决方案的一部分。因此，最好将需求保持在非常高的水平，并且作为分析师，关注FSD。
FSD应该是系统的完整顶级模型，以及后续的设计过程，更详细地阐明模型的层次结构。最后的细节级别是真实的代码。
消防处应该以一套简单的英文陈述结束。在文档中使用单个标题级别，最多保留两个句子，并对每个段落编号。回顾一下，确保每个人都说有用的东西。如果没有，删除它。短暂是好的！
非常认真地考虑FSD中的语言。在段落中对关键名词进行严格定义。这些名词成为你的课程。您使用的动词将成为您的类方法。真的很简单！
正如乔尔所说，写下你要编译的句子。例如，写“如果事情发生然后做更多”而不是“如果事情发生，做更多”或“当事情发生时做更多事情” ”
这些编写的模型可以从特定图表的使用中受益，例如有限状态图，但要注意您可以使用一组UML图捕获系统。这些东西本身并不强大，灵活或严谨，无法作为完整的描述。以严谨的英语写成的大纲开始更有效，并在必要时补充。
至于迭代的问题，在理想的世界中，你应该只需要修改模型的较低层。如果你必须改变高水平，那么严重的问题就是错误的。至于UML工具更快启用revisting - poppy-cock！关键是所有这些描述都是简短而简洁的。英语是要走的路，因为我们已经练习了很长时间。
我看到人们花了一个下午试图让实体图表看起来很重要。喜欢为什么？您的终极解决方案是二维盒子和线条吗？没有！这就是UML的问题：图表本身就成为分析师的终结，并将您从客户中解脱出来，而不是帮助沟通。