我已经看到不同的程序管理员以不同的格式编写规范。几乎每个人都有自己的风格来编写规范。

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

另一方面，我看到了我们的一位客户用Excel编写的这一创新性规范。他过去编写规范的方式是在Excel中创建一个模拟应用程序，然后使用一些VBA对其进行模拟。他会做类似单击按钮的操作，该操作应该将表单移至何处或者应执行什么操作(在注释中)。

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

我认为，使用这种技术，不太可能错过需要完成的事情。而且，对开发人员进行单元测试要容易得多。在实际编写系统之前，测试人员也对系统进行了更好的理解。

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

我们是否认为这应该成为编写规范的更流行的方式？我知道这会涉及项目经理(或者编写规范的人)的一些额外工作，但回报是巨大的……我自己可以从使用它的工作中看到很多生产率的提高。并且，如果有任何更好的规范格式对程序员有实际帮助。

解决方案

回答

一本Microsoft Press的书籍提供了各种文档的出色示例，其中包括SRS(我认为这是我们在说的)。这可能是Weigert撰写的需求书之一(我想那是他的名字，我现在对此空白。)我已经看到美国政府组织将其用作模板，从我在政府的三项工作经验中，他们希望尽可能地自己做，因此，如果要重用它，那一定很好。

我认为规范中也不应包含任何代码。它应该重点关注系统必须使用文本和图表执行，应该执行和不能执行的操作。

回答

Joel on Software在这些方面尤其擅长，并且有一些有关该主题的好文章...

具体情况

回答

我认为我们可能对"测试驱动需求"有所了解，这是一种制定可执行规范的技术。

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

回答

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

一种是"工作原型"，我们可以在问题中进行描述。以我的经验，该公司聘请了一位用户界面专家来创建功能齐全的HTML模拟。页面上的数据是静态的，但允许开发人员和管理人员查看和使用网站的"功能"版本。剩下要做的就是用动态内容替换页面上的静态数据，该原型是我们针对产品​​初始版本的规范。设计师甚至在悬停在模拟链接上时会在弹出对话框中包含一些细微行为的详细说明。对于我们的团队来说效果很好。

在随后的项目中，我们没有UI专家那么花钱，但是我们使用了类似的方法。我们使用了Wiki来模拟该网站的版本。我们在系统的功能方面之间创建了链接，并详细记录了每个功能。每个功能可以依次链接到详细的设计和体系结构决策。我们还习惯了使用Wiki来保留每个发行版的功能列表(已成为我们的发行说明)。这些文档链接回到详细功能页面。 Wiki变成了生动的文档，详细描述了我们的发行版和系统的演进。这是一种宝贵的资源。

我更喜欢Wiki，而不是可以正常工作的原型，因为随着系统的发展，它可以更轻松地扩展并变得越来越有价值。