我一直想知道 SRS 文档与两家公司（一家提供软件项目，另一家是客户）之间签订的正式合同有什么关系。
SRS 文件必须在初始合同签署之前还是之后编写？它是否可以作为 b2b 关系中的两个合作伙伴用作合同的官方文件？
【问题讨论】：
标签： specifications requirements contract b2b
SRS 与合同之间的关系是任意的，取决于双方希望与合同建立的协作模式。主要模式有：
【讨论】：
软件需求规范是‘must have’ 文档之一，对于业务和技术团队同样重要。
SRS 充当technical team 的基础文档，为任何高级或低级技术规范（包括解决方案架构）做准备。我不会在技术方面添加更多内容，因为这不是这个问题。
现在，当涉及到业务，尤其是协议时，SRS 进行通信并充当两个业务之间的安全桥梁。这概述了消费者对完整软件的期望以及服务提供商同意提供的内容。这意味着，双方都可以进行谈判和谈判。
理想情况下，当我们准备 SRS 时，我们会包含诸如 product scope, business function, area of coverage, future direction 之类的点，并且列表会不断增加。该文档稍后由产品所有者和最终用户等利益相关者‘signed’。这个agreement gives both parties a structured understanding of their responsibilities。
因此，对我来说，如果没有 SRS 草案版本，就不太可能启动任何项目。
最后，我想谈谈软件开发过程。如您所知，我们有一些开发流程，我们遵循这些流程来简化我们的软件开发生活。例如：Waterfall, VModel, RUP, URUP, Agile are some of them.
不考虑任何特定流程，只要能提供以下；
如果客户改变主意会发生什么？
客户应在开发过程中change 他们的想法。这种变化在不同的过程中得到不同的解决。对于waterfall，任何重大变更或额外需求都必须经过变更需求管理流程。这将帮助您沟通和量化时间和成本。对于agile，我们必须添加/更新/优先考虑用户故事，然后是其影响、成本等。
在一个公认的答案中，它在敏捷中被称为‘no upfront SRS’。我更喜欢将其改写为‘no complete SRS upfront’。这意味着，由于业务性质，现在不太可能拥有完整的 SRS。但这并不意味着没有 SRS。
总之，当您与外部客户打交道时，SRS 必须是您的“必备”文件。因此，您在组织中遵循哪个流程并不重要。
【讨论】：
正如@Matthias 所说，SRS 文档和合同之间的关系取决于协作模式。
SRS 文件必须在合同之前写成functional and non-functional requirements and implementation goals must be clear，以便按照客户的要求进行开发。
SRS 文档是 an official document and can be used for legal settlements，因为 SRS 是需要客户签字和批准的可交付文档。
【讨论】：