关于SDLC阶段和SRS的几个问题

Question

我在小型IT行业工作，我们正试图在我们的组织中实施流程和SDLC，因为我们处于初始阶段，所以我不太担心，因此希望这里的专家提供一些顾问：

• 目前，我们创建了一个主要的SDLC文档: SRS。
• SRS最初是由我们的业务开发主管创建的，他们是在任何需求出现时都具有客户端的第一个POC。他们创建了一个粗糙的SRS文档，其中包含了客户端的所有需求。
• 一旦需求被冻结，SRS就会传递给项目经理，然后项目经理根据业务开发主管指定的要求提供文档。

我所关切的是：

• 这是我们所遵循的正确方式吗?如果不是，请提出正确的方法。
• 只有在需求冻结后才能准备SRS吗？
• 如果是，那么哪些文档应该由业务开发主管准备，他们仍在收集客户的需求。

Answer 1

我不喜欢您的需求似乎存在于软件需求规范文档中，而不是需求管理工具中。基于文档的方法使捕获需求之间的可跟踪性和在软件产品线中跨项目或产品重用需求变得更加困难。这些不一定是您现在关心的问题，但从需求管理工具开始要比尝试管理文档、然后将多个文档导入一个工具、删除重复和事后管理可追溯性要容易得多。

也许这是隐含的，但您所描述的过程并没有对需求进行任何形式的迭代。当最初的客户需求来自业务开发主管时，它们可能不适合执行设计、实现和测试活动。至少有一些要求需要澄清和重写。此外，可能还有来自其他来源的其他需求--您的测试团队可能会引入您需要实现的可测试性需求，可能会有影响您的产品的业务或法规需求。还需要在SRS中捕获这些信息，并与客户一起进行审查，以确保他们理解并能够接受这些需求。

冻结SRS的概念对我来说有点奇怪。即使在一个连续的过程中，客户端也可能希望更改需求。与需求更改相关的成本和进度影响(特别是在后续流程中的后期)，但是接收更改请求、评估请求以及确定响应和处理的过程应该是您想要定义的。

如果您想进一步指导如何处理软件需求和开发一种方法，我强烈建议您获得一份软件需求(第三版)：卡尔·威格斯和喜悦·比提副本。IEEE标准29148-2011的副本也可能是有用的。