2

我见过不同的项目经理以不同的格式编写规范。几乎每个人都有自己的规范编写风格。

一方面是那些给程序员的冗长的文档可能会导致他/她遗漏一些东西。我个人害怕word文档规范...我认为这是因为我的阅读风格...我总是快速阅读我认为会导致我错过关键点的东西。

另一方面，我已经看到我们的一个客户用 Excel 编写的这个创新规范。他过去编写规范的方式是在 Excel 中创建一个模拟应用程序并使用一些 VBA 来模拟它。他会做一些事情，比如点击按钮，表单应该去哪里或者它应该执行什么操作（在评论中）。

在数据表单上，他会在单元格中显示一个表单，在每个数据输入单元格上，他会评论什么是有效值，应该执行什么验证等。

我认为使用这种技术，不太可能错过需要做的事情。此外，对开发人员进行单元测试要容易得多。测试人员也对系统有更好的了解，因为它在实际编写之前“执行”。

Visio 是另一种进行屏幕设计的工具，但考虑到它的 VBA 支持和功能，我仍然认为 Excel 比它有更好的优势。

你认为这应该成为一种更流行的编写规范的方式吗？我知道这涉及项目经理（或编写规范的人）的一些额外工作，但回报是巨大的......我自己可以看到使用它可以提高生产力。如果有任何更好的规范格式可以真正帮助程序员。

4

4 回答 4

5

Joel on Software尤其擅长这些，并且有一些关于这个主题的好文章......

具体案例

于 2008-08-22T18:22:44.057 回答
3

两种方法对我来说效果很好。

一个是您在问题中描述的“工作原型”。根据我的经验，该公司聘请了一位用户界面专家来创建功能齐全的 HTML 模拟。页面上的数据是静态的，但它允许开发人员和管理人员查看和使用网站的“功能”版本。剩下要做的就是用动态内容替换页面上的静态数据——这个原型是我们产品初始版本的规范。设计师甚至详细解释了悬停在模拟链接上时会出现的弹出对话框中的一些微妙行为。它对我们的团队很有效。

在随后的项目中，我们没有 UI 专家的奢侈，但我们使用了类似的方法。我们使用 wiki 来模拟网站的一个版本。我们在系统的功能方面创建了链接，并详细记录了每个功能。反过来，每个功能都可以链接到详细的设计和架构决策。我们还使用 wiki 来保存每个版本的列表功能列表（这成为我们的发行说明）。这些文档链接回详细的功能页面。wiki 变成了一个活生生的文档——详细描述了我们系统的发布和演变。这是一种宝贵的资源。

我更喜欢 wiki 而不是工作原型，因为它更容易扩展——随着系统的发展而增长并变得更有价值。

于 2008-09-02T18:48:07.043 回答
2

我想你可能会看一下测试驱动的需求，这是一种制定可执行规范的技术。

为此目的，有一些很棒的工具，例如FIT、Fitnesse、GreenPepper或Concordion。

于 2008-08-29T08:49:26.170 回答
0

Microsoft Press 的其中一本书籍中有各种文档的出色示例，包括 SRS（我认为这就是您所说的）。这可能是 Weigert 的要求书之一（我认为那是他的名字，我现在正在空白）。我见过美国政府组织用它作为模板，从我在政府的三个工作经验来看，他们喜欢尽可能地制作自己的东西，所以如果他们重复使用它，那一定是好的。

另外 - 在我看来，规范应该不包含代码。它应该关注系统必须做什么，应该做什么，以及不能使用文本和图表做什么。

于 2008-08-22T18:22:31.250 回答