您对功能规格有何看法？ 还有软件设计？
功能规格是否有助于或阻碍您的期望？ 实践瀑布方法的程序员是否对功能规范持开放态度？ 我是一名网页设计师/开发人员，与一个由 5 名程序员组成的团队合作，想编写一个功能规范来解释我们需要什么，这样当我开始工作时 - 我知道我们正在朝着同一个目标努力。
Does the functional spec help or hinder your expectations? Do programmers who practice the waterfall methodology, are they open to functional specs? I'm a web designer/developer working with a team of 5 programmers and would like to write a functional spec to explain what we need, so that when I begin my work - I know we are working towards the same goal.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（15）
在编写并签署设计规范和功能规范之前，我不会开始任何自由项目。 如果你没有的话，流氓客户就有太多的空间可以把你砸死。 功能规范可以让您保持目标/专注，并为您提供一个自然的工作清单。
如果没有功能规范，那么你就会开始陷入所有“假设”，开发人员会思考 - 你知道，这会很有用，而且只需要我一个小时。 当然，需要一个小时来编写原型并使其基本正常工作，再加上设计所有测试并确保覆盖所有测试用例的一天，然后再花几天时间来消除所有错误，然后是编写文档的时间。 当没有规范时，有太多的空间可以插入看似微不足道的添加内容。 您无疑听说过臭名昭著的“范围蔓延”。 当你交付产品并试图逃避付款时，客户也有太多的空间说“这不是我想要的……”。
如果您在开发之前就已经写好了设计规范和功能规范，并且您和客户都已签字同意，那么您不仅对基本细节的理解，而且对所用语言的所有细微差别的理解都是相同的 -只有这样才能开始真正的工作。
有一些轶事，第一个是非常真实的，而另一个是一个常见的误解：
人们错误地认为工作原型已经完成了 80% 的工作——不要被愚弄，事实并非如此。 因此，客户很容易说“怎么花了这么长时间，我以为你快完成了！” 然后狡辩说他们为几个月前就应该完成的事情付出了太多的代价。 一些设计方法确实很适合这种流行的误解。 如果使用不当，瀑布设计方法就是其中之一。
我的观点是确保您的理解是相同的，两者都签字。 设定里程碑，让客户从一开始就非常清楚原型距离项目完成还有很长的路要走，并从一开始就设定关于这些里程碑是什么以及客户何时可以期望看到它们交付的期望。
对于开发团队的项目经理来说，文档和期望就是一切。 没有它你就无法生活，这是你对抗“那不是我说的”或“那不是我的意思”以及“我不会付钱给你”的唯一追索形式。
我从比我更有资格的开发人员所犯的许多错误中吸取了教训，并看到了这对他们造成的影响。 您的项目最重要的两个文件是设计规范和功能规范。 不要在没有它们的情况下离开家，否则它可能（或很可能）回来咬你的屁股。
附录：用户故事：
关于用户故事的附加说明是，它们本身就很出色。 它们应该包含在您的功能规范中，但不应该成为您的功能规范。
用户故事仅描述单个任务。 它非常轻，不包含过多的细节。 按照常见的建议，它应该适合 3x5 卡...如果您作为项目经理递给我一张 3x5 卡并告诉我根据我读到的内容编写一个软件，毫无疑问它将交给最后用户会告诉项目经理这不是他们想要的。
您需要功能规范中更详细的信息。 它不应仅限于基本工作流程。 功能规范是一大堆用户故事，以及解释这些用户故事的注释、可以对它们进行的改进、可以组合起来以提高效率的常见任务。 这样的例子还在继续。
因此，用户故事是一个好的开始，但它们并不能替代功能规范，它们只是功能规范中的要点。
I won't start any freelance project until I've got a design spec and functional spec written up and signed off. There's too much room for rogue clients to nickel and dime you to death if you don't have it. The functional spec allows you to stay on target/focused and gives you a natural check list to work to.
If there's no functional spec then you get all the "what ifs" starting to creep in and developers thinking - you know, this would be useful, and it'll only take me an hour. Sure an hour to code the prototype and get it basically working - plus the day to design all the tests and make sure all test cases are covered, then another couple of days to iron out all the bugs, then time to write the documentation. There's far too much room for what seems like a trivial addition to be inserted when there's no spec. You've no doubt heard of the infamous "scope creep". There's also far too much room for clients to say "that's not what I wanted..." when you deliver it and try and wriggle out of paying you.
If you've got the design spec and the functional spec written up ahead of the development and both you and the client have signed off that your understanding of not only the basic details but all the nuances of the language used is one and the same - only then can the real work begin.
There are a couple of anecdotes out there the first is quite true, while the other is a common misconception:
The misconception is that a working prototype is 80% of the way there - don't be fooled, it is not. So it's easy for a client to say "what's taking so long, I thought you were almost done!" and then quibble that they're paying too much for something that should've been finished months ago. Some of the design methodologies out there really lend themselves well to this popular misconception. The waterfall design methodology is one of them if it's not used correctly.
My view is make sure your understanding is the same, both sign off. Set milestones and make the client very aware at the outset that prototypes are a long way from the completion of the project and set expectations right from the outset as to what those milestones are and when the client can expect to see them delivered.
For project managers of development teams documentation and expectations are everything. You can't live without it, it's the only form of recourse you have against "That's not what I said" or "That's not what I meant" and ergo "I'm not paying you".
I learned from a lot of mistakes made by far more qualified developers than me and saw what it did to them. The two most important documents for your project are the design spec and the functional spec. Don't leave home without them or it can [or most likely will] come back and bite you in the ass.
Addendum re: User Stories:
An additional note about user stories is that they're great for what they are. They should be included in your functional specification but shouldn't be your functional specification.
A user story only describes a single task. It is very lightweight and doesn't contain excessive detail. As the common recommendations go, it should fit on a 3x5 card...if you as a project manager handed me a 3x5 card and told me to write a piece of software based on what I read, no doubt it would be handed to the user at the end and they'd tell the project manager that's not what they wanted.
You need a far greater level of detail in a functional spec. It shouldn't be limited to basic workflows. A functional spec is a whole bunch of user stories along with notes on interpretation of those user stories, improvements that can be made to them, common tasks that can be combined to improve efficiency. The list goes on.
So user stories are a good beginning, but they're not a replacement for a functional spec, they're bullet points in a functional spec.
我主要使用瀑布模型，并且仅使用功能规格。 当我自己工作时（我可以按照自己想要的方式设置自己的模型和程序），我首先编写功能规范，然后实现它们。 它让我更好地了解工作的规模和范围，帮助我估计所涉及的时间，并有助于确保我不会错过任何事情。
此外，您还可以将此文档传递给：
使用功能需求而不是用户故事是很重要的偏好和项目范围。 如果您的用户群较小，那么您可能可以摆脱用户故事（概述用户可能执行的各种事件序列），但对于较大的项目，您应该使用功能需求，因为它们具有更多细节并导致更少误解。 将它们视为与参与项目的所有人员进行沟通的一种方式。
I work with mostly the Waterfall model, and solely with functional specs. When working on my own (where I can set my own model and program any way I want) I start by writing up functional specs and then implementing them. It gives me a much better idea of the size and scope of the work, helps me estimate the time involved, and helps ensure that I don't miss anything.
Also, you can pass this document to:
Using functional requirements over user stories is a matter of preference and the scope of the project. If you have a small user base, then you may be able to get away with user stories (which outline various event sequences the user might do), but for larger projects, you should use functional requirements as they have more detail and lead to fewer misunderstandings. Think of them as a means of communication with all people involved in the project.
坦率地说，功能规范应该已经成为 Big-M（瀑布）方法的一部分。 您的功能规格就是您要构建的内容； 不一定是您将如何构建它（这将是您的详细设计/规范以及瀑布中的下一步）。
如果您还没有写一篇，请停止手头的事情，写一篇。 如果你不这样做，你就是在浪费时间。 您可以这里阅读 Joel 的文章。
Frankly, the Functional Specifications should already be part of your Big-M (Waterfall) methodology. Your functional specification is WHAT you are going to build; not necessarily how you are going to build it (which would be your detailed design/specification and the next step in the waterfall).
If you haven't written one yet, stop what you are doing and write one. You are just waste time if you do otherwise. You can start here with Joel's article.
我花了 10 多年的时间才让自己在编写任何代码之前先编写功能规范。 现在我会为任何需要一天以上才能写完的事情写一篇。 细节水平和假设水平应该与清楚定义需要做什么并将其传达给他人（或提醒自己）所需的程度一样多，超出此范围的任何事情都是浪费。
其他人更喜欢用户故事……这也很好，只要你做某种规划。
It took me more than 10 years to get it beat into my head to write a functional spec before doing any code. Now I will write one for anything taking more than a day to write. The level of detail, and level of assumptions should be as much as needed to clearly define what needs to be done and communicate it to others (or remind yourself), anything beyond that is a waste.
Others prefer User Stories ... which is fine too, as long as you do some kind of planning.
实现此目的的另一种方法是使用用户故事
Another way to accomplish this is using user stories
我发现编写良好的功能规范非常有用。 组织良好的功能规范还可以帮助组织您的测试（从单个需求到测试用例的多对多映射）。
事实证明，它们对于在大型组织中相互指责也很有用（要求不准确！实施没有遵循要求！QA 没有'不能正确测试此要求等）I find well-written functional specs very useful. A well organized functional specification can also help organize your tests (many-to-many mapping from individual requirements to test cases).
<p style="tongue: in-cheek">They also prove useful for finger-pointing in larger organizations (The requirements were inaccurate! The implementation didn't follow the requirement! QA didn't properly test this requirement! etc.)</p>我将其次 Codeslave 对 无痛功能规范。 这是关于规范的一系列很好的文章。 另请参阅这篇 Stackoverflow 帖子，了解有关将哪些内容放入功能规范的讨论。
我完成了一些大型项目，其中一个项目需要数百人年的全部努力。 随着项目团队规模的扩大，非正式沟通渠道的数量会呈二次方上限增加。 如果没有规范，这种非正式的沟通机制是沟通事物的唯一方式。 通过规范，沟通渠道接近中心辐射状，使得增长更像是项目团队规模的线性函数。
规范实际上是让团队“唱出同一张赞美诗”的唯一可扩展的方式。 应该对规范进行一些审查和谈判，但最终必须有人拥有它的所有权，以避免该项目成为一个混战。
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.
我发现，即使你写了功能规范，很多细节有时也会被你试图与之交谈的人遗漏。 现在，如果功能规范与某种 UI 模型一起编写，就会产生巨大的差异。 UI 模型不仅向用户展示您的设想，还触发用户记住他们最初不会想到的事情。
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.