Creating a whole new software product isn’t exactly easy. That’s why there are certain parts of the process designed to help increase the likelihood of project success. One such part is a documented System Requirements Specification – which can be a daunting task for those who haven’t written one before.
A System Requirements Specification differs from a Software Requirements Specification as it focuses on the entire system, such as external sources/influences, and may include hardware specifications, instead of treating things like this as a black box. Rather than detailing simply the software part of the system (which can later be written in a Software Requirements Specification if necessary), this document outlines the full system.
A System Requirements Document doesn’t even have to include a software component – it could be a description of a system without software.
Before you get down to the nuts and bolts and start drafting your System Requirements Specification, you’ll need to capture all of your customers’ requirements for the project.
You’ll need to have a plan in place first as to how to go about this. Customer requirements will come in the form of:
Business requirements: e.g. budget, timelines, communication methods
Functional requirements: e.g. user information will be stored for analysis, calculating costs of an order
User requirements: e.g. UI, workflows, help
Non-functional requirements: e.g. loading speeds, hardware requirements, legislative requirements
Capturing all this information from the customer can be a lengthy process. There may be several stakeholders involved in the project to interview. You will also need to ask the customer questions that they may not have thought about, such as ability to scale in the future, or on-device processing power limits. It’s no wonder that requirements engineering even has its own discipline.
These resources may help in the initial stage of eliciting requirements from the customer:
A System Requirements Specification will outline what the system will do, have it will behave and interact, what components will be necessary, and external systems that it will utilize. What the document will not do is make suggestions for specific technologies, or directions on how to proceed with the project.
The document should be able to be picked up by someone in 15 years time and a system built, with whatever tools they have at the time.
It is designed to be an accountable agreement between the project coordinator and the customer for what is to be delivered. Depending which software development methodology is used it may be an evolving document, for example an Agile project may see various versions of the System Requirements Specification along the software development journey.
There are a few must-have elements of a System Requirements Specification.
Most will need to include diagrams for a better explanation of the system, such as Use Case diagrams, Data Flow Diagrams, and any other helpful architecture diagrams. It will require measurable metrics for accountability.
A good way to learn how to write your own System Requirements Specification is to study other (good) ones, like the USC Research Administration System (RAS) System Requirements or this one from California State University, and read, well, format specifications for the specification, such as MIL-STD-961E, which is the US Department of Defense, Defense And Program Unique Specifications Format And Content – which is very comprehensive, but targeted at military systems development.
There are also a number of templates floating around, such as this one from Project Management. The best thing that you can do if you have never written a System Requirements Specification before is get your hands on as many templates and examples as possible, and pick the parts relevant to your project to include in your document.
Ultimately, how large and detailed the document is will be a function of the project size itself.
The System Requirements Specification is generally written by the system architect, based on information from stakeholders. However, depending on the project, the main writer may be a technical writer or even a software developer themselves.
The other important thing to note about your System Requirements Specification is that it may change over time. When you go back to your customer with the first version, it may (read: probably will) need revisions. If you intend to use it as a living document following Agile methodology it will likely change, too.
This means that you need to be on top of your versioning and backups. If you are using a clouded productivity document editor such as Dropbox Paper or Google Docs, then you may already know that versioning is inbuilt into the product – however it may not be as useful as versioning your doc using Git. Yes, it’s fine to use Git for all your versioned project resources. Just don’t forget to back up if your server is local.
If all this sounds a bit daunting, an alternative is to outsource the work to a software development company. They will have experience creating requirements documents and will be able to create a detailed specification based on an outline brief.