Software requirement specification structure
Software requirement specification (SRS) is a document encompassing all functional and non-functional requirements of the product. It is essential to have them all put down and agreed as it helps to avoid uncertainties and miscommunication as well as is an important kick-off point for creating software. Throughout the whole software development life cycle the SRS should be the source of truth for the whole engineering team. There are lots of templates with examples of functional and non-functional requirements as well as other product attributes and ways of their description. One can use such templates or just follow the logical path of this information layout to create one’s own document. Basically, there are several main questions to be answered by SRS, let us consider them.
What is the business purpose of the product?
Why are we creating this product, e.g., to facilitate finding your business partners within a certain location, to sell goods or to enhance documents flow and processing for you and your partners, to optimize a production workflow, etc? Defining and sticking to the right purpose of the product will result in the validation of the software as fit for the defined goal. Business requirements are usually high-level and do not include any details of functionalities or implementation peculiarities. It is actually a brief introduction of what the project is about, the statement of its main idea and core value.
Who will the users of the product be?
Having a clear understanding of who will be the end users predefines how they might use your product (are they going to mainly work mobile phones or large screens, will they have an internet connection, or do they need a desktop application, are there any special requirements to accessibility, etc). Looking at the product from this perspective is widely practiced in agile software development frameworks to create user stories. Their model is “As a [persona], I [want to], [so that].” There might be several types of users with various access rights, roles, and workflows and they have to be outlined right at the start of the project.
What is the product structure and design?
Knowing the purpose and use cases of the website or app you can think about its main structural parts (e.g., pages or modules) and create a sitemap. Possible designs and wireframes are also good guides for the engineering team. Such designs may be the result of the cooperation of the customer with the designer, who can visualize their ideas for the product. The design might not always be included in the SRS, sometimes it is a separate set of mockups or a prototype.
Functional requirements
This is a crucial part of any SRS. The answer to the question “What are functional requirements?” is – “The description of What the software should do. In other words, the functional requirements definition is the list of features inherent to the software, which aim to satisfy the user’s goal.”
Examples of functional requirements
Functional requirements show us which objectives must be met by the product, these are then mapped to the functionalities or features to be included. Here are some common functional requirements examples for a web application:
– The app should allow the user to log in with a Google account
– The system must allow the user to buy a monthly subscription
– The user should be able to search other users by locations
Such requirements answer the above-mentioned question and later become user stories and tasks for the engineering team. Don’t forget to consider all possible use cases, system workflows, and external interfaces in order to implement them in the functionalities of the software. You may create special requirement traceability matrices to have visibility of requirements coverage by tasks and tests.
Who and how writes functional requirements
Ideally, there is a dedicated Business Analyst who prepares the SRS. However, putting down the list of requirements on paper is just the tip of the iceberg. It is preceded by often time-consuming and thoroughly thought-through conversations with all the possible stakeholders, such as product owners or potential users, as well as by the analysis of a similar product on the market. Brainstorming sessions and surveys may also be a good idea. In other words – all means are good. Only after that, were the specifications written in the most possible short, clear, and most unambiguous way, so as not to confuse anyone reading them. There should be strict consistency in terminology so don’t forget to draw up a glossary if needed. One of the best practices is to keep requirements granular and avoid combining them. Also, each requirement must be tracked to the business need, to put it simply, it has to be necessary, thus avoiding too large a scope and focusing on the important features.
Non-Functional requirements
What is the next step after agreeing on ‘What’ the system does? – Find out ‘How’ it will do it. That is the principal difference between the functional and the non-functional requirements: features included vs performance characteristics or quality attributes.
Typical non-functional requirements examples
The list of non-functional requirements describes the technical side of the software specifications, the samples might be:
– The website response time should be less than [number] seconds
– The app should support [number] concurrent users
– The iOS application should support [number] OS version
They define how robust the product will be, what will be the user experience, system security, reliability, scalability, compatibility, responsiveness, possible accessibility options, etc. Most of these requirements may be measured and, like functional ones, they must be testable and able to be translated into the tasks for the development team.
How to gather non-functional requirements
Gathering all the necessary non-functional requirements is where you need the expertise of the technical staff: architects, technical leaders, or developers. They will for sure have the best insight into which non-functional characteristics are possible and necessary to be implemented to achieve the goals set by the functional requirements. It is important here not to use such words as “quickly”, “effectively”, “the latest” etc. to avoid ambiguity and misinterpretations, using figures will be an absolute win. Non-functional requirements are the basis for building the architecture of the project and result in a positive user experience. At this point, it will also be possible to see if there are any technical constraints or obstacles in implementing the functional requirements.
Review of requirements
So first you must figure out what product you want to create, and whose problems it will help to solve (function), and after that decide how to do it (non-function). In the initial stages of the project, a well-written and prioritized requirements document will be the key to more accurate time, effort, and resource estimates. After the requirements have been written, ask the stakeholders to review them, this is very important, as it is easier and cheaper to adjust the requirements to the possible technical or resource restrictions than to change a ready product. There might be cases where the scope of the project dictates changes to the requirements, thus the SRS has to be very logically structured, so that it is easy to change and update, all the stakeholders need to be in the loop if there are any amendments.
Having a good understanding of functional vs non-functional requirements and their efficient organization will become the key to communicating the right tasks to the development team and add up to project success.
Roksolana Karamysheva
Business Analyst & Head of QA Department
