Back in 1999, NASA lost Mars Climate Orbiter, a spacecraft worth a whopping $125 million, just because two engineering teams didn’t specify what measurements of key performance data to use. Jet Propulsion Laboratory was using the metric system involving millimeters and meters for the spacecraft’s route calculations, while Lockheed Martin Astronautics followed an English units measurement. As a result, the spacecraft went off from Mars orbit and got lost in the planet’s upper atmosphere.
If such an exceptionally dumb situation happened to NASA, there is a chance it can happen to your software development project, so it’s better to be careful. To avoid mistakes of that sort across the entire software product development lifecycle, you must have a software requirement specification (SRS) that contains all the details about your future product.
In this article, the JatApp team will explain the meaning of software requirement specification and how to write one to safeguard your project from troubles similar to NASA’s. So relax and enjoy!
What is an SRS and what does it include?
For starters, let’s give a brief definition for SRS. Software requirements specification is a technical document that includes details about software’s functions, its technical capabilities, architecture, design, interactions with users, and guidelines for implementation.
Software requirements specification example
Actually, any SRS is the most basic requirements document in software development. To explain what we mean, let’s take a look at the entire structure of software requirements:
- Top tier. It involves high-level requirements related to goals a business wants to achieve. For instance, simplification of inventory management can be a top-tier requirement for a retail business company.
- Middle tier. This level focuses on requirements related to users and stems directly from the top tier. The top-tier requirement to simplify inventory management, for example, means that the software should enable users to quickly find necessary items, sort them, order new deliveries, create reports, and such.
- Bottom tier. That’s where your SRS resides. It includes descriptions of specific system features, actions, characteristics, and user flows to meet the requirements of the middle and top tiers.
A software requirements specification can be of different formats and structures, but it has to describe such aspects as:
- The product’s purpose
- General description of the software
- The product’s functions
- Performance measures and requirements
- Non-functional characteristics
- The product’s interactions with external apps and hardware, if applicable
- Any limitations to the product’s design and environments of its use
To be sure that nothing is missing in your SRS, we suggest you include the following components of software requirements specification, but any additional levels are possible:
- Vision and scope. The highest level of your product, at which you should define the purpose of your solution and goals it should achieve.
- User stories. Any software has its user personas — sets of characteristics typical for a particular person who will interact with the product. In such a way, every single user story is an independent situation, in which a specific user persona uses the solution in a unique way to get a desired result.
- Functional and non-functional requirements. Functional requirements describe what functions your product is expected to perform. For example, multiplying numbers is a functional requirement of a calculator app. At the same time, non-functional requirements refer to attributes and properties of the app’s system. Again, when talking about a calculator app, an ability to process 100,000 user requests at the same time can be a non-functional requirement.
- Technical designs. When you have clearly stated functional and non-functional requirements, it’s crucial to write down how your team will implement them. Architecture, computing capacity, database and servers, programming languages, and similar should be mentioned.
- Tasks. It’s not mandatory to write down all the tasks your team needs to complete for a successful product development. But if you feel that it can help, why don’t write them down? But we need to warn you: write only the tasks that you are absolutely sure your product requires. In case some tasks are likely to change or become unnecessary during the development process, it’s better to avoid cluttering your SRS with them.
This is a Careful Hog. And he asks you to read carefully the paragraph below
We would also like you to note that the structure mentioned above refers to WHAT information you should have at your fingertips before writing an SRS. In the next section, we’ll show you HOW to write software requirements specification on your own.
Writing your own SRS
Since you already know what an SRS should include and what logical structure to follow, you just need to organize it in a convenient fashion. We’ve told you that everything will be easy with writing SRS, so you don’t have to bother yourself with writing it from scratch because we already created a SRS template for you. You can download it here. You are welcome, but when you want to know how to make your SRS even better, keep reading.
Ways to amplify the power of your SRS
Having a software requirements specification document is certainly vital for the entire project, so you want your SRS to be as good as possible. There is a number of best practices that can make any SRS even more useful:
- Visualization. You know, one picture says more than a thousand words, and your SRS is no exception. Enrich your specification with charts, schemes, infographics, and mind maps to visualize the ideas and structure the requirements. In the best case scenario, each level of requirements should have its own visualization that connects to relatable visuals on the bottom level, thereby creating a bird-eye view of the entire product.
- Clarity. Once we are talking about software requirements specification, there is no place for ambiguity. That is why you should use simple and straightforward language to describe the requirements, so that your words don’t have any alternative interpretation. Avoid words that cause confusion. Don’t say something like “the app should load as soon as possible” or “the software should be able to process approximately 10, 000 inquiries within 3-5 minutes”. If you are not sure about certain requirements at that point, just don’t write them. Trust us, you’ll amend your SRS many times.
- Customer-centeredness. Once you’re going to write an SRS, you should research your target audience and develop at least one user persona for your product. It is reasonable to include any important information about your intended audience to give developers and designers an understanding of who will use the product. Your team shouldn’t base their work on wild guesses and gut feeling, so adding a detailed description of user personas is a good way to avoid many confusions.
- Prioritization. Describe the requirements according to the priority they have to your business. When it comes to functional requirements, we even suggest you mark each feature as must have, should have, and can have. The must-have features will be the top priority and comprise your minimum viable product (MVP). Should-have features are important, but only when you release your MVP. Can-haves include the rest of features that you may add to the project’s backlog and develop them later when the necessity arises.
- Flexibility. You have to to ensure that your SRS is easy to change at any moment. For that reason, don’t add too much extra information that is unnecessary at the current stage of your product development life cycle. Besides, having a change log to track all changes made is a decision you will thank yourself for at some point.
- Traceability. Every requirement should have its own ID in order to trace it within the whole system of documentation. Additionally, assigning unique IDs to each requirement significantly helps to avoid misunderstandings between team members, as the whole team understands what requirement is under discussion at the moment. We also recommend you create a traceability matrix to see the full picture of requirements.
- Consistency. It goes without saying that requirements should not contradict each other in your SRS. However, consistency has to be present in everything: terms, measures (hello, NASA!), user personas, project roles, to name a few. Also, don’t forget to add a glossary for terms that are uncommon. A concisely written SRS doesn’t cause misunderstandings and confusions. Your development team shouldn’t waste time clarifying this or that part of the software requirements.
Feeling like you could use some help? JatApp is at your service
Even though writing an SRS isn’t that difficult, you may still face many barriers related to business, design, or development aspects of your software product. But it’s not a problem after all, once you have JatApp — a software development company that has written and successfully implemented more than 200 specifications for projects of different industries and scale. Moreover, 99% of our customers were satisfied with the end results we delivered. You may just have an intention to build some product, and our business analysts can help you with developing a detailed concept of your solution.
Get in touch with us to learn more about how we work. We will get back to you as soon as possible.
