我不会开始任何自由职业项目，直到我写好并签署设计规范和功能规范。如果您没有它，会给不良客户留下太多讨价还价的空间。功能规范让您保持目标/专注，并为您提供自然的核对清单。

如果没有功能规范，那么你就会开始考虑所有可能发生的情况，开发人员也会思考——你知道吗，这很有用，只需要一个小时。确实，要编写原型并使其基本工作需要一个小时的时间——还要花一天时间设计所有测试并确保所有测试用例都被覆盖，然后再花几天时间排除所有错误，然后再写文档。当没有规范时，似乎有太多的空间可以插入看似微不足道的添加物。您无疑已经听说过臭名昭著的“范围蔓延”。当您交付时客户也有太多的机会说：“那不是我想要的……”，并试图逃避支付。

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

有几个轶事在外面流传，其中第一个是真的，而另一个是常见的误解：

• Software development is only 15% about the code, the rest is resource/people management.
• It takes 20% of the time to complete the first 80% of the project and the remaining 80% of the time to complete the last 20%.

误解是一个工作原型已经完成了80% - 不要被愚弄，它没有。因此，客户很容易说“为什么这么久，我以为你们快完成了！”然后挑剔地说他们付了太多钱，而这应该在几个月前就完成了。一些设计方法论真的非常适合这种流行误解。瀑布式设计方法就是其中之一，如果不正确使用就会出现这种情况。

我的看法是要确保你的理解是一致的，双方都签署协议。设定里程碑，并在项目初期让客户非常清楚地知道原型与项目完成还有很长的路要走，并要在项目开始时就设定期望，包括这些里程碑是什么以及客户可以期待何时看到它们的交付。

对于开发团队的项目经理来说，文档和期望是至关重要的。你不能没有它，它是你对抗“那不是我说的”或“那不是我想要的”的唯一手段，因此“我不会付款”的唯一手段。 对于开发团队的项目经理来说，文档和期望是至关重要的。你不能没有它，它是你对抗“那不是我说的”或“那不是我想要的”的唯一手段，因此“我不会付款”的唯一手段。

我从比我更有资格的开发人员犯的很多错误中学到了很多，并看到了它对他们造成了什么影响。您项目中最重要的两个文档是设计规范和功能规范。不要离开家时没有它们，否则可能会回来咬你屁股。

增补：有关用户故事：

关于用户故事的一个额外说明是它们非常适合自己的职责。它们应该包括在您的功能规格说明中，但不能代替您的功能规格说明。

用户故事仅描述单个任务。它非常轻量级，不包含过多的细节。如常见的建议所述，它应适合于一个3x5卡片...如果您作为项目经理将一个3x5卡片交给我，并告诉我根据我所读的内容编写一段软件，毫无疑问它将在最后交给用户，并告诉项目经理这不是他们想要的。

您的功能规格书需要更详细的级别。它不应限于基本工作流程。一个功能规格书应该包括大量的用户故事及其解释的注释，可以进行的改进以及可以结合以提高效率的常见任务。列表还可以继续延伸。

因此，用户故事是一个很好的开始，但它们不能替代一个功能规范，它们只是功能规范中的要点。

我主要使用瀑布模型，并仅使用功能规范。在独自工作时（我可以自行设置自己的模型和编程方式），我首先撰写功能规范，然后再实施它们。它让我对工作的规模和范围有更好的了解，帮助我估计所需的时间，并有助于确保我没有漏掉任何东西。

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

1. Users so that they can make their requirements clear
2. Developers to create the functionality
3. Testers to make sure they are testing the right thing
4. Architects so that they can analyze the requirements

使用功能需求而不是用户故事，这是一种偏好和项目范围的问题。如果你的用户群体很小，那么你可能可以使用用户故事（它们概述用户可能执行的各种事件序列），但对于较大的项目，你应该使用功能要求，因为它们具有更多的细节并且会减少误解。将其视为与参与项目的所有人进行沟通的手段。

坦白说，功能规格说明应该已经是您的大M（瀑布）方法论的一部分。您的功能规格说明是您要建造的东西; 不一定是您要如何建造它（这将是您的详细设计/规格说明和瀑布的下一步）。

如果你还没有写过，那就停下你现在正在做的事情，写一篇。如果你不这样做，你会浪费时间。你可以从这里Joel的文章开始。

它花费我十年以上的时间才能将其铭记于心，在编码之前编写功能规格说明。现在，对于任何需要花费超过一天的事情，我都会编写一个功能规格说明。详细程度和假设程度应视需求而定，以清晰地定义需要完成的任务并向他人传达（或提醒自己），任何超过此范围的都是浪费。

其他人更喜欢用户故事...这也是可以的，只要你做一些规划。

另一种实现方式是使用用户故事。

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

<p style="tongue: in-cheek">它们还可以用于在大型组织中指责他人（要求不准确！实施没有遵循要求！QA没有正确测试这个要求！等等）。</p>

I ll second Codeslave s reference to Painless Functional Specification. It s a good series of articles on specifications. See also this Stackoverflow post for a discussion on what content to put into functional specs.

I ve done a few large projects, including one with some hundereds of person-years of total effort. As a project team gets larger the number of informal communication channels goes up with a quadratic upper bound. Without a spec this informal communication mechanism is the only way things can get communicated. With a spec, the communication channels approach a hub-and-spokes, making the growth more like a linear function of the project team size.

A spec is really the only scalable way to to get the team singing off the same hymn sheet . There should be some review and negotiation about the spec, but ultimately someone has to take ownership of this to avoid the project becoming a free-for-all.

I think they re a lovely idea, and should be tried.

Just a few comments on some of the answers here...

First of all, I do believe that a good spec document is important for any moderatly complex requirement (and definitly for highly complex ones). But make sure it is a good spec i.e. don t just state the obvious (like one poster already mentioned) but also don t leave out those parts that may seem trivial to you (or even the developers) since you might have more knowledge of that part of the system than some others involved (e.g. testers or documenters) which will appreciate the otherwise "missing bits".

And if your spec is good, it will get read - in my experience (and I ve written and read lots of specs over the last years) it s the bad specs that get dumped and the good ones that get followed.

Concerning user stories (or sometimes also called use cases): I think these are important to get an idea of the scenario, but they usually can t replace the details (e.g. screen mockups, how where and if a feature is configurable, data model, migration issues etc.) so you ll probably need both for more complex requirements.

In my experience, functional specs have a fine line between not saying enough and saying too much.

If they don t say enough, then they leave areas open to misunderstanding.

If they say too much, they don t leave enough "wiggle room" to improve the solution.

And they should always be open to a process of revision.

It depends on the functional specification. I ve had functional specifications where the writer knew the system inside and out, and wrote the specification as such, and I ve had other writers write it with just what they expected to see as a user.

With the former, it s easier because I know exactly what I need to write and where I need to write it, but it limits how easily I can refactor the existing code, since estimates took into account just this feature, and not refactoring existing code that it touches.

With the latter, I have freedom to refactor (so long as end functionality is the same), but if it s a system I m unfamiliar with, the time estimate is harder to make.

Overall, I love functional specifications -- I also like to remind people that they re written on paper that bends, and as such, should be flexible.

Whether you call them functional specs, business requirements, or user stories, they are all very beneficial to the development process.

The issue with them comes when they are chiseled in stone and used as a device to pass blame around when the system utimately doesn t fit with the user s real needs. I prefer to use the functionals or requirements as a starting point for an iterative process not as the bible for exactly how the system will look when it is complete. Things change, and users typically don t have an understanding of what they want until they have something (a working prototype possibly) in their hands that they can work with instead of conceptualizing on a piece of paper how it will function in the real world. The most successful projects I ve implemented were ones where the development team and the users were closely aligned and were able to rapidly turn around changes instead of holding people to what they wanted on a piece of paper six months ago.

Of course this process wouldn t work if you were in a fixed-bid type of situation as one of the earlier answers pointed out.

One interesting substitute for a func spec or user stories that I have seen advocated is to write a user manual for the software first.

Even if this is only notional (i.e. if you do not intend to ship any manual - which you probably shouldn t as nobody will read it), it can be a useful and reasonably lightweight way to reach a common understanding of what the software will do and look like. And it forces you to do the design up front.

I ve found that even if you write Functional Specs a lot of the detail is sometimes lost on the person you are trying to address. Now if a Functional Spec is written along with some kind of UI mockup, that makes a huge difference. UI mockups not only show the user what you are envisioning, it also triggers users into remembering things they wouldn t have thought off in the first place.

I have seen and written many specs, some were very good, most weren t. The main thing that they all had in common is that they were never followed. They all had cobwebs on them by the 3rd day of coding.

Write the spec if you want, the best time to do it is at the end of the project. It will be useless for developers to follow but it will at least be an accurate representation of what was done (I know- not really a spec). But don t expect the spec to get the code written for you. That is the real job. If you don t know what to write talk to your stakeholders and users and get some good user stories and then get on with it.