SRS文檔與軟件開發合同簽署的關係（b2b）

Question

我一直在想，SRS文檔與兩家公司（一家提供軟件項目而另一家是客戶）簽訂的官方合同的關係如何。

是否必須在初始合同簽署之前或之後寫入SRS文檔？它是否是一個官方文件，b2b關係中的兩個合夥人可以用作合同？

Answer 1

SRS和合同之間的關係是任意的，取決於雙方希望與合同建立的合作模式。主要模式有：

• 瀑布：合同是指完全詳細完成的SRS必須實施。變化成本高昂且複雜。
• 敏捷時間&材料：無SRS前面，只有幾個用戶故事以填充第一迭代
• 敏捷固定價格：前兩個

Answer 2

正如@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是一份可交付文件，需要客戶的簽署和批准。

Answer 3

軟件需求規格是‘must have’文件之一，對業務和技術團隊同樣重要。

SRS充當technical team的基礎文檔，爲包括解決方案架構在內的任何高級或低級技術規範做好準備。我不會在技術方面增加更多，因爲這不是這個問題。

現在談到業務，特別是協議，SRS溝通並充當兩個業務之間的安全橋樑。這概述了消費者可以從完整的軟件和服務提供商同意提供什麼。這意味着，雙方都有理由談話和談判。

理想情況下，當我們準備SRS時，我們會包含諸如product scope, business function, area of coverage, future directio n和列表等。並且這份文件後面的‘signed’由利益相關者包括產品所有者和最終用戶。這agreement gives both parties a structured understanding of their responsibilities。

因此，對於我來說，沒有SRS草稿版本的情況下啓動任何項目的可能性較小。

最後，我想觸摸軟件開發過程。如您所知，我們有少量的開發過程，我們遵循這些過程來簡化我們的軟件開發生活。例如：Waterfall, VModel, RUP, URUP, Agile are some of them.

不考慮任何特定的過程，如果它可以提供以下;

1. 一個愉快的端到端軟件開發之旅和它的 管理。
2. 有能力調整和採用不斷變化的業務需求。

如果客戶改變主意會發生什麼？

客戶應change他們的頭腦在發展過程中。這些變化在不同的過程中有不同的處理。在waterfall的情況下，任何重大更改或額外要求都必須經過更改要求管理流程。這將幫助您溝通和量化時間和成本。當涉及到agile時，我們必須添加/更新/優先考慮用戶故事，其次是影響，成本等。

在其中一個被接受的答案中，它被提及爲敏捷中的‘no upfront SRS’。我更喜歡它被重寫爲‘no complete SRS upfront’。這意味着，由於業務性質，現在不太可能在一天內擁有完整的SRS。但這並不意味着沒有SRS。

總之，當您與外部客戶打交道時，SRS必須是您的「必備」文件。因此，您組織中遵循哪個流程並不重要。