Contractors' Questions: What's in a software specification?

Contractor’s Question: I am yet to start the development for a piece of software I have agreed, in principle, to design, build and stress-test for a client, so have done the right thing by not commencing work without an SDA in place. However I need to know more about what seems the most critical part - the specification. I can imagine why this is important but what type of detail should I include in the specification and what’s the significance if I get it wrong, legally or from my/their business point-of-view?

Expert’s Answer: A key part of a software development project and the corresponding software development agreement is indeed the specification – the details of the software to be developed.

A prospective client may present its requirements to you as the developer in the form of anything from a general description of what it wants the software development to achieve for its business to a more detailed statement – a business requirements or functional specification. You may have received that brief informally or as part of a more formal invitation to tender process.

However the business requirements are communicated to you, and then you, as the IT developer, apply your expertise as to how that brief might be realised from a technical perspective. The technical reality will often differ from the client’s requirements to a greater or lesser extent.

From a legal point of view, to protect your position it is important to have a clear statement of the software development which you are undertaking and which the client agrees. This can be achieved by including a technical specification in the software development agreement. The technical specification sets out the criteria the software is to meet. It will usually be prepared by you as the developer so will specify those criteria in terms of what it is technically feasible for you to produce.

The technical specification will be a more objective specification of the software. The performance of the finished software will be more readily measurable against that technical specification than the client’s business requirements specification which might be somewhat aspirational. It will be the standard against which the completion and acceptance of the software can be assessed, any warranties given and limitations put on your liability.

The significance of a proper specification is therefore to reduce the chances of you suffering any problems arising out of the project, such as the client refusing to accept what has been developed or to pay for the work or any other ongoing dispute. Any of these would obviously have a detrimental effect on your business and cashflow and on your ability to concentrate on other projects.

The expert was Sue Mann, commercial solicitor for Cousins Business Law.

Tuesday 26th June 2012