A Software Requirements Specification (SRS) document is used within the software industry to represent the final software project that a client has requested a developer to build. Both the client and the developer have to agree that it’s an accurate representation before development can proceed. The document is used to capture the end-goals and needs for a project.
The SRS is the client’s assurance that the developers will build the software product that they asked for. It’s also beneficial to the developer to avoid ‘scope creep’ which is where the client asks for features that were not originally agreed upon. The SRS forms the basis of the contract between the client and the developer and is a safeguard for both parties.
When is the SRS produced and by whom?
The SRS is created by the developers in the early stages of a software project, this stage is often called the consultation stage and/or requirements gathering. The software consultant will work closely with the client and together they will draw up the requirements for the proposed software.
These requirements form the basis of the software project and the software consultant will take the agreed upon requirements and create a document that specifies every detail in words or visual form. Once the client and the developer have agreed that this is a true representation of what the client requires, the developers can then provide the client with a fixed quote, if required.
What type of software requires a specification?
There are two main types of software. The first is custom or bespoke software. This is produced by a software development company for an individual client or company and is tailored to meet their needs. The second type is sometimes referred to as ready-made’ or ‘off-the-shelf. This software is created by a software development company to sell to many customers in the open market. In this case an SRS is often produced to structure the development.
Not too many years ago, before the agile development revolution, most software projects required an SRS. Custom software developers needed the SRS as it formed the basis of the contract between the client and the development company. Where as software being developed in-house to be sold on the open market had an SRS in order to establish the requirements of the product they were planning to build. This document could also be used by the sales department to start marketing the product before development was fully complete.
Many companies now use agile methodologies in order to produce software. Agile methodologies are built in chunks rather than as a whole, allowing the software development company to start off with small set of basic features, build and test those features and then move on to the next feature. As requirements are gathered per feature as the project progresses, it often negates the need for an SRS.
An SRS nowadays is most important when the client wants to know the cost of the software and requires a fixed price before the project begins. For custom software this is often what the client desires as it assures them that the project cost won’t get out of hand. Before the project begins, the developers will produce an SRS and any changes the client requires will be amended, added or removed from the SRS until the client is satisfied that the SRS represents what they require. Once agreed the developers can then give the client a fixed cost for the project and providing the client agrees, development can then proceed.
What does an SRS document contain?
An SRS can differ between different software development companies. This could be based on experience, the type of project they are developing or whether they creating custom or off-the-shelf software. The size and complexity of the project will also dictate what will need to be contained within the SRS. However, the aim of the document is to give the client a full view of what the software will be like once it is fully developed. So, the essential elements and size of the SRS are dependent upon what is needed in order to achieve this aim.
Here are some typical items you may find in an SRS:
- The SRS normally starts with an introductory section, that gives an overview of what the software will do. It will also outline the scope of the project, this is what the software will cover and possibly what it won’t cover.
- Mock-ups and wireframes, these are drawing created by hand but more than likely with computer software. These show the ‘look and feel’ of the views and screens. They may contain components like buttons and combo boxes in the positions they would be placed on an actual screen. These mock-ups are often annotated to show when a button would be disabled or what elements would be in a combo box.
- Functional requirements specify behaviour of the software system. This is often split into individual activities which state what the user can do and how the system will behave in response. These behaviours can be specified in a written form, shown as an activity diagram or both. These are written in a form that is easier for the clients to understand.
- Functional requirements may also be shown in the form of a ‘Use Case’ which details what the behaviour is, what triggers the behaviour, any conditions that must be in place before the event is triggered; steps of what happens after an event is triggered; alternate paths of behaviour and post conditions the state of the system at the end of an event. These are often written more with a developer in mind.
- The SRS may also include the non-functional requirements these describe all the requirements that are not covered by the behaviours of the system. A non-functional requirement could be that the system needs to be able to run on a computer, with a Windows 10 operating system.
- An Entity Relationship diagram may also be part of the SRS, if the finished project will be using a database. The Entity Relationship diagram will describe the database and the types of data it will contain and the associations between the different types of data.
When is an SRS unnecessary?
It’s easy to argue that any software change could benefit from an SRS, however practically it’s not always possible to spend the time creating one. When working with existing clients who already have a software system in place, new features do not always require an SRS. If the feature is small, such as adding a new report type and the system is already able to generate documents in a required format then an SRS is probably not necessary.
Agile projects often skip the step of an SRS document, as the software is discussed and implemented iteratively, this usually enables development to start shortly after initial discussions instead of having to front-load all the thinking.
What does it cost to have an SRS document for my project?
Most software companies charge for an SRS as there is a lot of work is involved in creating them. Depending on the size and complexity of the project, an SRS can range from ten to hundreds of pages. Here at BSPOKE Software, in most cases don’t charge for an SRS if we will be building the project for the client, as the SRS reduces the amount of design work required.
We do charge for an SRS when we are acting in the role of a software consultant and we are producing the SRS for a client who intends to use another developer to develop the project. We may also charge if the client may use us for the development work, but there is no clear agreement and the client has no plans to develop the project within the near future.
If I have an SRS already, would BSPOKE Software develop the project for me? Yes, if you already have an SRS, we can still develop the project for you. We would at first go over the SRS and make sure that what was being requested was feasible. Also. we may have to tweak the SRS with your consent. The age of the SRS may have an impact on how relevant it is, especially if it specifies technologies that are now out of date, where possible we would suggest equivalent solutions.
Having an SRS already would speed up the process of being able to give you a fixed price quote. If this is your situation, please contact us or give us a call on 01733 215 777.
