问题标签 [specifications]

需求规范的初稿已经完成，现在是评估需求、审查规范的时候了。此过程的一部分是确保规范中没有相当大的差距。不用说，这些差距会导致估计非常不准确、项目后期不可避免的范围蔓延，并最终导致死亡行军。

有哪些好的、有效的技术可以用来确定缺失的和隐含的需求？

• 这个问题是关于实用技术的，而不是一般的建议、原则或指导方针。
• 缺少需求对于产品或服务的完整性至关重要，但没有被考虑或忘记，
• 隐式需求是用户或客户自然认为将成为软件的标准部分而无需明确要求的东西。

_{我很高兴重新访问已接受的答案，只要有人提交更好、更全面的解决方案。}

我需要开始弄乱一个 vb.net(vs2008) 项目文件，并且我想要一个参考，理想情况下，它是规范。

任何链接都会非常有帮助

我赢得了一个项目的投标，现在客户（本身来自 IT 部门）希望我以非常特殊的方式构建/实施解决方案。我确信应用程序会因为性能问题而失败。而且它不容易扩展。

这个特定的客户/用户对我将使用的平台和语言（ASP.NET / SQL Server）一无所知。他唯一的知识是 Cobol，试图让他理解我的 POV 只会让他生气。

他联系了我。他是在竞标中选择我作为获胜者的人。他将批准我的支票。他是我与这家公司的唯一联系人。

我对提供一个我知道会失败的解决方案感到不舒服，我不想被称为导致它失败的愚蠢程序员。我确实知道他们对这个应用程序的真正需求和使用模式，因为我过去曾为他们做过项目。

另一方面，以他的方式这样做只会延长我的合同更多时间（因此，更多的经济收益），以便通过修改代码来解决问题。

我是否应该从这个项目中辞职，因为我可能会永远失去这个客户？

或者……</p>

我是否应该服药并从扩展项目中获得经济利益，而只是将坏名声视为成本？

目前我正在使用 Visual Source Safe（是的，是的！）来存储我的技术规范文档。

实际的文档是用 MS Word 编写的。

如果发现以 word 格式编写规范是一个很大的负担，那么要真正使用规范，就不应该有任何使用障碍，更重要的是访问。

如果我不能快速扫描文档、超链接到其他相关文档或部分，那么这一切有什么用？

因此，以此为背景：

有什么软件可以创建真正可访问的文档？即到其他页面/部分等的超链接？甚至可查询，因此我可以查看依赖于模块 4.5.3 的所有文档

它基本上只是一个维基吗？还要别的吗？

假设我们正在创建 Acme CMS。此 CMS Web 应用程序将允许您创建无限数量的具有子类别（无限深度）的类别，并且每个类别可以有 0+ 个与之关联的内容页面。

所以这个项目，在高层次上将有：

前端 1. 索引页面 2. 带有内容页面列表的类别页面 3. 内容页面

管理控制面板 1. 类别（添加/更新/删除） 2. 页面（添加/更新/删除/）

架构设计 1. 表 2. 存储过程 3. 数据访问层

问题：我正在使用错误跟踪器和 Wiki，那么我应该如何分解这个项目？

我正在考虑将每个部分（前端/管理面板）分解为单独的页面，然后为每个页面（或主题）编写简单的用户故事。

当我完成用户故事后，我将在我的错误跟踪器中创建一个案例列表，代表我必须开发的功能，以及对每个案例的估计。

我是否正确地分解了这个项目？计划中的任何重大差距都会导致该项目失败（理论上无论如何！）

请提供详细的答案，也许是我应该做什么的大致想法，并附有详细的示例来解释它以及原因等。

根据定义，算法独立于它们运行的​​介质。例如，在用编程语言实现算法之前，我使用 Excel 表来玩数据结构并做一些移动/洗牌/标记实验。

您使用什么工具和技术来设计和模拟算法的功能？你如何使用绘图程序？一种特殊的规范语言？

在我工作的地方，人们不喜欢编写规范。（男孩，有人吗？）所以他们不这样做，除非他们的老板强迫。如果他们被迫编写它们，它们会尽可能短。（顺便说一句，他们也包括我。）

这导致规范如

• 该软件将事件 A 和 B 之间的时间记录到事件日志中
• 参数 X 的名称和路径在 ini 格式的配置文件中设置。
• 该软件是活动的，无需用户登录到计算机（作为 Windows 服务实施）

这个例子取自一个非常小的项目，效果很好，但我认为它不足以处理更复杂的事情。我没有指定操作系统/硬件要求，因为这是内部开发，我们有涵盖这些的公司或部门标准。

所以我的问题是： 您认为任何重要软件的功能规范中的绝对最低细节水平是多少？

是的，当我们阅读项目规范以及它们如何帮助保持项目按时并在范围内等时，我们都会感到温暖和模糊。

这里有谁真正为一家保持最新规范的公司工作？

如果这样做，这是什么原因？是您拥有庞大团队的主要原因吗？

我读到域驱动设计是关于专注于问题域而不是专注于软件。他们说解决问题领域的复杂性比解决软件的复杂性更容易，因为在解决了领域之后，您也更了解如何构建软件。他们还说，实际上域比软件的结构更复杂，或者如果你从树林里看不到森林，你就有麻烦了。

但是领域驱动设计与仅使用软件规范有何不同？我的意思是，我们当然应该在开始编码之前了解问题域。DDD 是在重新发明轮子吗？

Joel 测试中的一项是项目/公司应该有一个规范。

我想知道是什么让规范变得更好。一些公司会编写大量没有人阅读的无用规范，而另一些公司则不会写下任何内容，因为“无论如何也没有人会阅读任何内容”。那么，您在规范中添加了什么？这两个极端之间的良好平衡是什么？有什么特别重要的东西，真的，真的（！）应该总是记录在规范中吗？