SRS document relation to contract signing in software development ( b2b ) [closed]

Question

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.

---

This question does not appear to be about programming within the scope defined in the help center.

Closed 5 years ago.

Improve this question

I was always wondering whats the relation of the SRS document with the official contract signed between two companies ( one supplies a software project the other is the customer ).

Does the SRS document have to be written before the initial contract signing or after ? And does it stand as an official document that two partners in a b2b relation can use as a contract ?

Answer 1

The relationship between SRS and contract is arbitrary and depends on the mode of collaboration that the parties want to establish with the contract. The main modes are:

• waterfall: the contract refers to the fully detailed finished SRS that has to be implemented. Change is costly and complicated.
• agile time & material: no SRS up front, just a few user stories to fill the first iteration
• agile fixed price: mixture of previous two

Answer 2

Software requirement specification is one among ‘must have’ document, which is equally important for business and the technical team.

SRS act as a foundation document for technical team to prepare for any high or low level technical specification including the solution architecture. I am not adding more at technical side since that wasn’t this question.

Now when it comes to business and in particular the agreement, the SRS communicate and act as a safe bridge between two business. This outlines what consumer can expect from a complete software and what service provider agree to provide. This means, both parties get their ground to talk and to negotiate.

Ideally, when we prepare SRS, we include points such as product scope, business function, area of coverage, future direction and list goes on and on. And this document later ‘signed’ by the stakeholders including the product owners and end user. This agreement gives both parties a structured understanding of their responsibilities.

Therefore, for me, it is less likely to initiate any project without a draft version of SRS.

Finally, I wanted to touch the software development process. As you know, we have handful of development process, which we follow to simplify our life of software development. Eg: Waterfall, VModel, RUP, URUP, Agile are some of them.

Irrespective of any particular process, if it can provide following;

1. a pleasant journey of end to end software development and it’s management.
2. has the ability to align and adopt changing business demand.

What happens if customer change their mind ?

Customer shall change their mind over the course of development. Such changes are addressed differently in different process. In case of waterfall, any breaking changes or extra requirement must go through a change requirement management process. This will help you to communicate and quantify time and cost. When it comes to agile, we have to add/update/prioritize user stories followed by its impact, cost etc.

In one of the accepted answer, it was mentioned as ‘no upfront SRS’ in agile. I prefer it be reworded as ‘no complete SRS upfront’. This means, it is less likely to have a complete SRS now a days due to nature of business. But this doesn’t means that no SRS.

To conclude, SRS must be your ‘must have’ document when you deal with external customers. Hence it doesn't really matter which process you follow in your organization.

Answer 3

As @Matthias has said, the relation between SRS document and contract depends on the collaboration mode.

The SRS document have to be written before the contract as the functional and non-functional requirements and implementation goals must be clear so that the development is done as required by the customer.

The SRS document is an official document and can be used for legal settlements as the SRS is a deliverable document that will require the client’s sign-off and approval.