Functional programming 你对功能规格有什么感觉？还有软件设计？

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

另一种方法是使用

我主要使用瀑布模型，并且只使用功能规范。当我自己工作时（在那里我可以以我想要的任何方式设置我自己的模型和程序），我从编写功能规范开始，然后实现它们。它让我对工作的规模和范围有了更好的了解，帮助我估计所需的时间，并确保我不会错过任何东西

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

用户，以便他们能够明确自己的需求

开发人员创建功能

测试人员确保他们测试的是正确的东西

架构师，以便他们能够分析需求

---

将功能需求置于用户情景之上是一个优先事项，也是项目的范围。如果您的用户群较小，那么您可能能够避开用户故事（概述了用户可能执行的各种事件序列），但是对于较大的项目，您应该使用功能需求，因为它们有更多的细节，并且导致更少的误解。将其视为与项目所有相关人员沟通的一种方式。

这取决于功能规范。我有过一些功能规范，作者对系统了如指掌，并以此编写了规范，我也有过其他作者编写规范时所用的正是他们作为用户所期望看到的

对于前者，它更容易，因为我确切地知道我需要写什么以及需要在哪里写，但它限制了我重构现有代码的容易程度，因为评估只考虑了这一特性，而没有重构它所涉及的现有代码

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

---

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

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

---

如果你还没有写一个，停止你正在做的，写一个。如果你不这样做，你就是在浪费时间。您可以开始了。

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

---

它们在大型组织中也被证明是有用的（需求不准确！实现没有遵循需求！QA没有正确测试此需求！等等）

我不会开始任何自由职业者的项目，除非我有一份设计规范和功能规范，并签字认可。如果你没有的话，流氓客户有太多的空间可以用五分镍币和一角镍币处死你。功能规范允许您保持目标/专注，并为您提供一个自然的检查列表

如果没有功能规范，那么所有的“如果”都会慢慢出现，开发人员会想——你知道，这会很有用，而且只需要我一个小时。确定一个小时来编写原型并使其基本正常工作-加上一天来设计所有测试并确保涵盖所有测试用例，然后再过几天来消除所有bug，然后是时间来编写文档。在没有规范的情况下，有太多的空间来添加看似微不足道的内容。毫无疑问，您已经听说过臭名昭著的“范围爬行”。还有太多的空间让客户说“这不是我想要的…”当你交付它并试图逃避支付给你的时候

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

有两件轶事，第一件是真实的，另一件是常见的误解：

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

人们的误解是，一个正在工作的原型有80%的成功率——不要被愚弄，事实并非如此。因此，客户很容易会说：“怎么花了这么长时间，我还以为你就快完成了呢！”然后就狡辩说，他们为几个月前就应该完成的事情付了太多钱。有些设计方法确实很适合这种流行的误解。如果没有正确使用瀑布式设计方法，它就是其中之一

我的观点是确保你的理解是一致的，双方都签字。设定里程碑，让客户在一开始就意识到原型离项目完成还有很长的路要走，并从一开始就设定对这些里程碑是什么以及客户期望何时能够看到它们交付的期望

对于开发团队的项目经理来说，文档和期望就是一切。没有它你就活不下去，它是r的唯一形式