> 陷入循环的规格说明问题 > 要确切知道我们要开发什么软件，唯一的方法就是完全地进行规格说明：如果不这样做，我们的模糊想法和严酷的现实之间就会存在差距。然而，一个完整的、抽象的规格说明，一般来说，至少和开发软件本身一样费力——在许多情况下，它甚至更加费力。嗯，有一种方法可以做到这一点：这就是需求。软件工程有一个子领域叫做需求工程，专门处理这个问题。我们这个领域令人遗憾的是，甚至没有停下来写下哪怕一页的要点式描述，说明软件应该做什么。我们更愿意直接跳入开发，然后在之后花费数小时、数天、数周、数月，甚至数年的时间来重构我们最初错误的东西，或者每当出现新的（通常可以预见的）需求时，就用锤子不断地敲打它。当然，软件开发是一个年轻的领域，但如果不断忽视甚至忘记基本的东西，它将永远无法成熟。
源讨论哪些因素解释了软件的本质？原帖 91 条评论 · 导入时统计把你的经验，加入这段讨论。
软件规格之所以是循环的，是因为我们写下的需求会很大程度上取决于实现的可行性。但实现的可行性通常在实际尝试实现之前是不清楚的。 事实上，我想说，如果在设计阶段，你所要实现的每一个部分的精确结构，以及所有替代方案的范围和可行性都已知且清晰明了，那么这个项目就是简单的，可能根本不需要设计阶段——你或许直接写代码就可以了。 这篇文章也表达了这个观点："一个完整的、抽象的规格说明，通常来说，至少和创建软件本身一样费力"
完整原文需求能为一个项目做的准备是有限的。在某个时候，花在详细说明需求上的时间会带来边际效益递减。当然，需求可能会改变，所以在工作进行时，能够灵活调整是非常理想的。 开发软件通常更像一个过程，而不是一个计划。这与传统工程不同，传统工程中你绝对需要一个严格的计划来建造一座桥或一栋建筑。当然现实是混乱的，没有一个计划是完美的
完整原文扩展一下别人所说的内容：如果规格说明的规模没有和软件一样大，那么它就会遗漏细节。但‘大家都知道我们的意思’——直到他们尝试实现它。然后他们会发现有些未说明的部分。 ‘部分’，因为还有另一部分未说明，而他们只是假设只有一种可能的答案，因此甚至没有意识到在规格说明中存在一个空白。但确实存在，如果有人在某个地方做出相反的假设，这个空白就会变得重要。
完整原文“……一个新的（通常可以预见的）需求似乎出现了……” 而很多时候并非如此，特别是当你在构建一个新系统时。如果你是在替换一个现有系统，你发现的需求通常是："它必须和旧系统完全一样工作。"
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。