Documentation 需求、设计、代码推导

我正在跟踪验证和验证线程，我认为一个示例可能会有所帮助。我不是一名经验丰富的开发人员，因此我想知道这是否正确：

用户要求：我想将我朋友的姓名、地址和电话号码保存到系统中

软件需求说明：用户希望能够输入并保存姓名、地址、电话号码

技术分析：用于数据输入的web UI。数据将保存到SQL数据库中

详细设计：UI元素：3个字符串类型字段、1个按钮、对象XYZ、dbConnection

代码：（UI、db脚本的实际代码）

是那样的吗？有人能纠正或补充我在这里遗漏的内容吗？

---

对于验证，每个阶段都可以根据需求（可追溯性）进行验证。至于验证，功能代码应该按预期工作（保存三个属性）。

我从来没有见过一种好的方法可以将代码跟踪到单个sprint/时间框之外的需求。而且，您的列表中缺少测试人员！除非你们的测试人员也是你们的业务分析师（根据我的经验，专业的测试人员会发现很多需求不一致——也就是bug）

我认为最好的方法是让每个人都尽可能地参与进来，这样你就可以经常交叉参考每个人的期望。如果每个人都在一起工作，您就不需要实现一个cargo cult流程，即批量信息以一种方式向下传输

---

具有可追溯性的最简单工具是您的VCS，其中每个提交都包括提交相关的用户故事/用例的ID。

虽然这在理论上是正确的（我不得不说这一点），但在所有实际和现实场景中都是完全错误的

捕获用户需求并为什么他想做某件事。这允许您只构建用户想要的软件，消除作为组成需求、技术需求、好东西等一部分的浪费

因此

I want to be save my friend's name, address and phone number to the system...

我希望下面的内容能够强调用户的实际需求

我想在我朋友生日那天给他寄张贺卡

现在，我知道我只需要他的名字和地址。因为这是为了将来，我也想存储这些信息。因此，我接下来要写的是一套满足上述客户需求的验收标准。如果我能将它们捕获为一组可执行规范，那么就更好了，因为它们是可编程验证的

忽略其他一切。可追溯性是不必要的开销。如果我们是基于预制需求构建软件，我们就需要它

阅读下面的文章

• 及

---

我认为总体思路是正确的，但应该尽可能具体。+1：“可追溯性是不必要的开销。”。我会将BDD添加到您的列表中。一旦有人搜索atdd或可执行要求，DVD肯定会出现。我不想让帖子充斥着流行语，所以……一旦代码可执行，测试人员就会参与验证。验证很少由测试人员来完成，而不是分析师、开发人员（静态分析）嗨，特里，我强烈不同意你所说的。I测试人员可以在验证需求方面做出很大贡献，以阻止其他事情：需求中的差距、以微妙方式相互矛盾的需求、在实现之前发现UI可用性缺陷。显然，这取决于您雇佣的测试人员的类型。专业测试人员与能够使用鼠标、键盘和阅读测试脚本的人员。如果你想进一步研究这个问题，我建议你读这本书