functional-programming - 您对功能规格有何感受？和软件设计？

Question

功能规范是帮助还是阻碍您的期望？练习瀑布方法的程序员是否对功能规范持开放态度？我是一名网页设计师/开发人员，与一个由 5 名程序员组成的团队合作，我想编写一个功能规范来解释我们需要什么，这样当我开始工作时——我知道我们正在朝着同一个目标努力。

Answer 1

在我写好设计规范和功能规范并签字之前，我不会开始任何自由职业项目。如果你没有它，流氓客户有太多的空间来镍和一毛钱死。功能规范允许您保持目标/专注，并为您提供一个自然的检查清单。

如果没有功能规范，那么您就会得到所有“假设”开始蔓延，开发人员会思考——你知道，这很有用，而且只需要我一个小时。确定一个小时来编写原型并使其基本工作 - 再加上设计所有测试并确保涵盖所有测试用例的一天，然后再花几天时间来解决所有错误，然后是编写文档的时间。在没有规范的情况下，插入看似微不足道的添加内容的空间太大了。您无疑听说过臭名昭著的“范围蔓延”。当你交付它并试图扭动不付钱给你时，客户也有太多的空间说“这不是我想要的......”。

如果您在开发之前编写好设计规范和功能规范，并且您和客户都已经签署，您不仅对基本细节的理解，而且对所使用语言的所有细微差别的理解都是一样的 -只有这样才能开始真正的工作。

有几个轶事，第一个是相当真实的，而另一个是一个常见的误解：

• 软件开发只占代码的 15%，剩下的就是资源/人员管理。
• 完成项目的前 80% 需要 20% 的时间，而完成后 20% 的时间需要剩余 80% 的时间。

误解是工作原型已经完成了 80% - 不要被愚弄，事实并非如此。所以客户很容易说“什么花了这么长时间，我以为你快完成了！” 然后狡辩说他们为几个月前就应该完成的事情付出了太多。那里的一些设计方法确实很适合这种流行的误解。如果使用不当，瀑布设计方法就是其中之一。

我的观点是确保你的理解是一样的，都签字。设定里程碑，让客户从一开始就非常清楚原型距离项目完成还有很长的路要走，并从一开始就设定这些里程碑是什么以及客户何时可以期望看到它们交付的期望。

对于开发团队的项目经理来说，文档和期望就是一切。没有它你就活不下去，这是你对“我不是这么说”或“我不是这个意思”和“我不付钱给你”的唯一追索方式。

我从比我更合格的开发人员所犯的许多错误中吸取了教训，并看到了它对他们的影响。您的项目最重要的两个文件是设计规范和功能规范。不要在没有它们的情况下离开家，否则它可能 [或很可能会] 回来咬你的屁股。

附录重新：用户故事：

关于用户故事的另一个注意事项是，它们非常适合它们的本来面目。它们应该包含在您的功能规范中，但不应该是您的功能规范。

一个用户故事只描述一个任务。它非常轻巧，不包含过多的细节。按照常见的建议，它应该适合 3x5 卡...如果您作为项目经理递给我一张 3x5 卡并告诉我根据我阅读的内容编写一个软件，毫无疑问它会交给最后的用户，他们会告诉项目经理这不是他们想要的。

您需要在功能规范中提供更高级别的详细信息。它不应该局限于基本的工作流程。功能规范是一大堆用户故事，以及对这些用户故事的解释、可以对其进行的改进、可以组合以提高效率的常见任务。名单还在继续。

所以用户故事是一个好的开始，但它们不是功能规范的替代品，它们是功能规范中的要点。

Answer 2

我主要使用瀑布模型，并且只使用功能规格。当我自己工作时（我可以设置自己的模型并以任何我想要的方式编程），我首先编写功能规范，然后实施它们。它让我更好地了解工作的规模和范围，帮助我估计所涉及的时间，并帮助确保我不会错过任何事情。

此外，您可以将此文档传递给：

1. 用户，以便他们可以明确他们的要求
2. 开发人员创建功能
3. 测试人员确保他们正在测试正确的东西
4. 架构师，以便他们可以分析需求

在用户故事上使用功能需求是一个偏好和项目范围的问题。如果您的用户群较小，那么您可能能够摆脱用户故事（概述用户可能执行的各种事件序列），但对于较大的项目，您应该使用功能需求，因为它们具有更多细节并导致更少误解。将它们视为与参与项目的所有人员进行交流的一种方式。

Answer 3

坦率地说，功能规范应该已经成为您的 Big-M（瀑布）方法的一部分。您的功能规范就是您要构建的内容；不一定要如何构建它（这将是您的详细设计/规范和瀑布的下一步）。

如果你还没有写一篇，停下你正在做的事情，写一篇。如果你不这样做，你只是在浪费时间。您可以从Joel 的文章开始。

Answer 4

在编写任何代码之前，我花了 10 多年的时间才想到编写功能规范。现在我会为任何需要超过一天的时间写一篇文章。详细程度和假设程度应尽可能多地明确定义需要完成的工作并将其传达给他人（或提醒自己），除此之外的任何事情都是浪费。

其他人更喜欢用户故事......这也很好，只要你做一些计划。

Answer 5

实现此目的的另一种方法是使用用户故事

Answer 6

我发现编写良好的功能规范非常有用。组织良好的功能规范还可以帮助组织您的测试（从单个需求到测试用例的多对多映射）。

<p style="tongue: in-cheek">它们也被证明对大型组织中的指责很有用（要求不准确！实施没有遵循要求！QA 没有正确测试这个要求！等等）</p>

Answer 7

我将第二次Codeslave对无痛功能规范的引用。 这是关于规范的一系列很好的文章。另请参阅此 Stackoverflow 帖子以讨论将哪些内容放入功能规范中。

我已经完成了一些大型项目，其中一个需要数百人年的总努力。随着项目团队的扩大，非正式沟通渠道的数量会以二次上限上升。如果没有规范，这种非正式的沟通机制是沟通事情的唯一方式。有了规范，沟通渠道就接近了中心辐射，使增长更像是项目团队规模的线性函数。

规范确实是让团队“唱出同一张赞美诗”的唯一可扩展方式。应该对规范进行一些审查和协商，但最终必须有人拥有它，以避免项目成为一个免费的项目。

Answer 8

我认为他们是一个可爱的想法，应该尝试。

Answer 9

这里只是对一些答案的一些评论......

首先，我确实相信一个好的规范文档对于任何中等复杂的需求（当然对于高度复杂的需求）都很重要。但要确保它是一个好的规范，即不要只陈述显而易见的内容（就像已经提到的一张海报），而且不要遗漏那些对你（甚至开发人员）来说似乎微不足道的部分，因为你可能有更多的知识系统的该部分比其他一些相关的部分（例如测试人员或文档人员）更重要，这将欣赏否则“缺失的位”。

如果你的规范很好，它会被阅读——根据我的经验（我在过去几年里写过很多规范），不好的规范会被抛弃，好的规范会被遵循。

关于用户故事（或有时也称为用例）：我认为这些对于了解场景很重要，但它们通常不能替代细节（例如屏幕模型、功能在何处以及是否可配置、数据模型，迁移问题等），因此您可能需要两者来满足更复杂的要求。

Answer 10

根据我的经验，功能规格在说得不够和说得太多之间有一条很好的界限。

如果他们说得不够多，那么他们就会留下容易被误解的地方。

如果他们说得太多，他们就没有足够的“回旋余地”来改进解决方案。

他们应该始终对修订过程持开放态度。

Answer 11

这取决于功能规范。我有功能规范，作者从内到外都了解系统，并这样编写规范，并且我让其他作者编写了他们期望作为用户看到的内容。

使用前者，它更容易，因为我确切地知道我需要写什么以及我需要在哪里写，但它限制了我重构现有代码的难易程度，因为估计只考虑了这个特性，而不是重构现有的代码它触及。

对于后者，我可以自由地重构（只要最终功能相​​同），但如果它是我不熟悉的系统，时间估计就更难了。

总的来说，我喜欢功能规格——我还想提醒人们，它们是写在可弯曲的纸上的，因此应该是灵活的。

Answer 12

我看到提倡的 func 规范或用户故事的一个有趣替代方法是首先为软件编写用户手册。

即使这只是名义上的（即，如果您不打算发布任何手册 - 您可能不应该这样做，因为没有人会阅读它），它可能是一种有用且相当轻量级的方式，可以就软件的功能达成共识做和看起来像。它迫使您预先进行设计。

Answer 13

无论您称它们为功能规范、业务需求还是用户故事，它们都对开发过程非常有益。

当系统完全不符合用户的实际需求时，它们被刻在石头上并被用作推卸责任的工具时，问题就出现了。我更喜欢将功能或需求用作迭代过程的起点，而不是作为系统完成后确切外观的圣经。事情发生了变化，用户通常不了解他们想要什么，直到他们手中有可以使用的东西（可能是工作原型），而不是在一张纸上概念化它在现实世界中的功能. 我最成功的项目

当然，如果您处于固定出价类型的情况下，则此过程将不起作用，正如先前的答案之一所指出的那样。

Answer 14

我发现即使你编写了功能规范，很多细节有时也会在你试图解决的人身上丢失。现在，如果功能规范与某种 UI 模型一起编写，那将产生巨大的差异。UI 模型不仅可以向用户展示您的设想，还可以让用户记住他们一开始就不会想到的事情。

Answer 15

我看过并写过很多规格，有些非常好，大多数都不是。他们的主要共同点是他们从未被追随。到编码的第 3 天，他们身上都长满了蜘蛛网。

如果需要，请编写规范，最好的时间是在项目结束时。开发人员遵循它是没有用的，但它至少可以准确地表示所做的事情（我知道——不是真正的规范）。但是不要指望规范会为您编写代码。这才是真正的工作。如果您不知道该写什么，请与您的利益相关者和用户交谈并获得一些好的用户故事，然后继续进行下去。