One of the Microsoft Press books has excellent examples of various documents, including an SRS (which I think is what you are talking about). It might be one of the requirements books by Weigert (I think that's his name, I'm blanking on it right now). I've seen US government organizations use that as a template, and from my three work experiences with the government, they like to make their own whereever they can, so if they are reusing it, it must be good.
Also - a spec should contain NO CODE, in my opinion. It should focus on what the system must do, should do, and can not do using text and diagrams.
一个是您在问题中描述的“工作原型”。 根据我的经验，该公司聘请了一位用户界面专家来创建功能齐全的 HTML 模拟。 页面上的数据是静态的，但它允许开发人员和管理层查看和使用网站的“功能”版本。 剩下要做的就是用动态内容替换页面上的静态数据 - 这个原型是我们产品初始版本的规范。 设计者甚至在将鼠标悬停在模拟链接上时出现的弹出对话框中包含一些微妙行为的详细解释。 这对我们的团队来说效果很好。
在随后的项目中，我们没有聘请 UI 专家，但我们使用了类似的方法。 我们使用维基来模拟该网站的一个版本。 我们在系统的功能方面之间创建了链接，并详细记录了每个功能。 反过来，每一项功能都可以链接到详细的设计和架构决策。 我们还使用 wiki 来保存每个版本的功能列表（这成为我们的发行说明）。 这些文档链接回详细功能页面。 wiki 成为了一个动态文档 - 详细描述了我们系统的发布和演变。 这是一种无价的资源。
与工作原型相比，我更喜欢 wiki，因为它更容易扩展——随着系统的发展而成长并变得更有价值。
Two approaches have worked well for me.
One is the "working prototype" which you sort of described in your question. In my experience, the company contracted a user interface expert to create fully functional HTML mocks. The data on the page was static, but it allowed for developers and management to see and play with a "functional" version of the site. All that was left to do was replace the static data on the pages with dynamic content - this prototype was our spec for the initial version of our product. The designer even included detailed explanation of some subtle behavior in popup dialogs that would appear when hovering over mock links. It worked well for our team.
On a subsequent project, we didn't have the luxury of the UI expert, but we used similar approach. We used a wiki to mock a version of the site. We created links between the functional aspects of the system and documented each piece of functionality in detail. Each piece of functionality could, in turn, link to detailed design and architecture decisions. We also used to wiki to hold our to list feature list for each release (which became our release notes). These documents linked back to the detailed feature page. The wiki became a living document - describing our releases and evolution of our system in great detail. It was an invaluable resource.
I prefer the wiki to the working prototype because it's more easily extensible - growing and becoming more valuable as your system evolves.
发布评论
评论（4）
我想您可能会了解一下测试驱动需求，这是一种制定可执行规范的技术。
有一些很棒的工具，例如 FIT、健身、GreenPepper 或 Concordion 用于此目的。
I think you may have a look about Test-Driven Requirements, which is a technique to make executable specifications.
There are some great tools like FIT, Fitnesse, GreenPepper or Concordion for that purpose.
Microsoft Press 的一本书籍提供了各种文档的优秀示例，包括 SRS（我认为这就是您正在谈论的内容）。 这可能是 Weigert 的要求书之一（我认为这是他的名字，我现在对此一片空白）。 我见过美国政府机构用它作为模板，从我在政府的三个工作经历来看，他们喜欢尽可能地自己制作，所以如果他们重复使用它，那一定是好的。
另外 - 在我看来，规范不应包含任何代码。 它应该使用文本和图表来重点关注系统必须做什么、应该做什么和不能做什么。
One of the Microsoft Press books has excellent examples of various documents, including an SRS (which I think is what you are talking about). It might be one of the requirements books by Weigert (I think that's his name, I'm blanking on it right now). I've seen US government organizations use that as a template, and from my three work experiences with the government, they like to make their own whereever they can, so if they are reusing it, it must be good.
Also - a spec should contain NO CODE, in my opinion. It should focus on what the system must do, should do, and can not do using text and diagrams.
Joel on Software 特别擅长这些，并且有一些关于该主题的好文章。 一个具体案例：
文章和规范。
Joel on Software is particularly good at these and has some good articles about the subject...
A specific case: the write-up and the spec.
有两种方法对我来说效果很好。
一个是您在问题中描述的“工作原型”。 根据我的经验，该公司聘请了一位用户界面专家来创建功能齐全的 HTML 模拟。 页面上的数据是静态的，但它允许开发人员和管理层查看和使用网站的“功能”版本。 剩下要做的就是用动态内容替换页面上的静态数据 - 这个原型是我们产品初始版本的规范。 设计者甚至在将鼠标悬停在模拟链接上时出现的弹出对话框中包含一些微妙行为的详细解释。 这对我们的团队来说效果很好。
在随后的项目中，我们没有聘请 UI 专家，但我们使用了类似的方法。 我们使用维基来模拟该网站的一个版本。 我们在系统的功能方面之间创建了链接，并详细记录了每个功能。 反过来，每一项功能都可以链接到详细的设计和架构决策。 我们还使用 wiki 来保存每个版本的功能列表（这成为我们的发行说明）。 这些文档链接回详细功能页面。 wiki 成为了一个动态文档 - 详细描述了我们系统的发布和演变。 这是一种无价的资源。
与工作原型相比，我更喜欢 wiki，因为它更容易扩展——随着系统的发展而成长并变得更有价值。
Two approaches have worked well for me.
One is the "working prototype" which you sort of described in your question. In my experience, the company contracted a user interface expert to create fully functional HTML mocks. The data on the page was static, but it allowed for developers and management to see and play with a "functional" version of the site. All that was left to do was replace the static data on the pages with dynamic content - this prototype was our spec for the initial version of our product. The designer even included detailed explanation of some subtle behavior in popup dialogs that would appear when hovering over mock links. It worked well for our team.
On a subsequent project, we didn't have the luxury of the UI expert, but we used similar approach. We used a wiki to mock a version of the site. We created links between the functional aspects of the system and documented each piece of functionality in detail. Each piece of functionality could, in turn, link to detailed design and architecture decisions. We also used to wiki to hold our to list feature list for each release (which became our release notes). These documents linked back to the detailed feature page. The wiki became a living document - describing our releases and evolution of our system in great detail. It was an invaluable resource.
I prefer the wiki to the working prototype because it's more easily extensible - growing and becoming more valuable as your system evolves.