Different sources on the Internet offer different practices of using the SRS in software projects, but they don’t answer why you should use this document and how you should write it in full. If you want to write a specification for your project, but don’t know what to start with, this article will explain what the SRS is, answer why it is important for all software development projects, and provide you with a software requirements specification example to help you prepare a comprehensive document.
Contents:
What Is a Typical SRS Document?
A software requirements specification is a document that explains how a software product must be developed. The core of the document is the description of functional and non-functional requirements for software as well as the design and/or implementation constraints that might occur in a project depending on its peculiarities.
Since a software specification belongs to technical documentation, the regulations on drafting and managing the SRS in software engineering are defined in the official IEEE 830 standard available on the Internet. Before downloading the standard, make sure you use a trusted source.
Why Use the SRS in a Project?
Many aspects of software development are negotiable and changeable. For example, a client can ask to add more features to the product or change its design architecture at some point of the development process. So, it doesn’t mean that specialists must follow the first draft of the SRS unconditionally. Still, the benefits of software requirements specification prove that it’s a powerful document to rely on.
Detailed Project Description
A requirement specification document is essential for making a detailed decomposition of the project’s functional aspects. It regulates the development process and ensures efficient project and time management. It organizes the workflow giving all the team members an understanding of what they must do to ensure that all the clients’ requirements are followed. Besides, it helps to select the development method based on the peculiarities of a project.
Resource Allocation
With the SRS, developers can determine time and effort to build software and managers can count costs of features and rates of human resources based on that information. So, along with other project documentation like a client-vendor agreement, architecture or testing specifications, etc., it’s one of the key documents for scheduling, team selection, and cost estimation of a project.
Relationship Regulation
The goal of the document is to make sure that the development team has enough information on clients' requirements and needs. In case any misconception or problem occurs between clients, managers, and team members, the SRS is a source for settling disputes.
Who Uses the Document?
The SRS gives clients and non-technical staff of the company like marketers an idea of how the finished product will look like. Based on the requirements, project managers can build diagrams, describe use cases as well as estimate costs and time to complete the project. A software development team gets clear instructions on how exactly they must build the product. Also, by following the SRS, quality assurance specialists plan and run software tests.
How to Write Software Requirements Documents?
The SRS doesn’t require a certain number of specialists to be necessarily engaged in drafting it. This type of documents is mainly written by a project manager or a team lead who’s responsible for the technical part of the process.
QA specialists are among the key team members that work with the SRS from start to end of the development process. They analyze the requirements, identify technical challenges and ways to deal with them as well as make a conclusion about whether the implementation of some software system components is possible or not. Developers also take part in the first draft of the document because they estimate their time and effort to get the project done.
However, the process of project development will be even more smooth if business analysts and designers participate in creating the SRS.
How to Collect Requirements?
A software specification can be created before the development process starts as well as when the project is already in work. It isn’t necessary to write the SRS for small projects, but drafting the specification makes sense if the scope of functions for such projects increases. In this case, it helps to regulate the workflow and product or project support. That’s why the SRS can be written at any stage of the project development. The key points to do here will be to plan software architecture and add information on new features to be implemented in the existing project to the document. It’s also crucial to review and update the SRS because it serves as a reference document for project management, architecture, development, and testing documentation.
Note: Since any requirement can be reviewed, changed, or removed spontaneously, some times it’s not critical if you lack information about some parts of the project. In this case, use the “TBD” abbreviation in the requirement description to indicate that the matter is to be determined later.
According to K. Wiegers, there are three correlative levels of software specifications: business, user, and software requirements. The last category includes functional and non-functional requirements that will be explained in detail in the next paragraph. At the stage of information gathering, business and user requirements are carefully analyzed and captured to serve further as the ground for software requirements description:
Business Requirements
A person who drafts the document explains why the client needs this software and what business goals must be achieved. This information is entirely provided by a client. For example, a clinic owner wants to minimize administrative work to save money they would have spent on personnel and hardware. A solution for the clinic could be a fully-functional doctor booking app that will automate all the administrative processes and, thereby, help an owner achieve their business goal.
User Requirements
This type of requirements specifies goals and tasks that a user can accomplish while interacting with software. If to get back to the example of a doctor appointment mobile app software requirements specification, one of the most typical scenarios to include would be a patient’s ability to make or cancel a doctor’s appointment. The point is to define and indicate in the specification as many user stories as possible.
What Does the Basic SRS Structure Look Like?
Software requirements documents are usually written according to a definite template. However, they may differ by structure depending on the size and unique characteristics of each project. If you don’t know what to add to the table of contents in your specification, follow the typical structure below.
Revision History
In the course of development, different specialists review a technical specification to improve it. Each revision is indicated at the beginning of the document, and all the previous versions of it are kept in case some changes got to be restored.
Introduction
The introductory part contains the information on the purpose of the document, its intended audience (who can read this specification), project scope, and system overview. Also, it contains terms, definitions, and abbreviations that a reader might come across while working with the SRS and a list of references that state the grounds for using various technologies in the project.
Overall Description
This part covers the information on a product perspective and a summary of the functions to be performed by software. At this point, a reader finds out about the user roles that must be included in software and a list of actions that users are supposed to do. This part may also include assumptions and dependencies related to the project as well as design and implementation constraints that a development team might face.
These constraints can be:
- Coding standards;
- Data exchange standards;
- Programming language and database to use;
- Constraints related to project business logic;
- Constraints posed by the operational environment, for example, compatibility with only one OS, etc.
External Interface Requirements
External Interface Requirements refer to the interactions between users, hardware, and software. It explains what APIs to use, how interfaces must interact, how different types of data would be collected by software, etc. This type of requirements is divided into four subparagraphs, each covering different types of interface interactions, namely:
- User Interfaces. In this subparagraph you must describe the relationship between a user and software;
- Hardware Interfaces. This part is about the interaction between software and hardware components;
- Software Interfaces. Here you must point out the correlation between software and its components such as OS, databases, libraries, etc.;
- Communications Interfaces. This subparagraph must deal with the communication channels used by the product such as e-mails, server protocols, browsers, e-forms, and others.
Functional Requirements
Functional requirements define the behavior of a product under different circumstances or user scenarios. They point out what developers must do to make it easier for users to accomplish their tasks. See the examples of how to phrase software features:
3.1 Booking a Doctor’s Appointment
A user shall be provided with the ability to confirm an appointment
A user shall be able to cancel an appointment
… (etc.).
3.2 Reviews and Ratings Feature
Software shall allow a user to rate doctors
… (etc.).
Note: It would be an advantage if you add more details to the function description and outline all possible use cases. For example, you can extend the phrase ‘A user shall be able to cancel an appointment’ to ‘A user shall be able to select “Cancel” in the block with scheduled appointments on their Profile page’ for clarity.
Set priorities for the functions. Priorities help a development team go through challenges, e. g. when the client’s expectations changed but the time for development is almost over, or when some tasks can’t be done in full within the given constraints.
Non-Functional Requirements
Non-functional requirements, also known as software attributes, do not describe what software does, the focus here is on how well software performance is. This type helps to set the constraints that could come along with a project under development. Complex projects can have an extensive list of attributes, but only some of them are described in detail. These attributes are:
- Usability;
- Safety;
- Security;
- Reliability;
- Testability;
- Scalability;
- Integrability;
- Extensibility;
- and others.
Other Requirements
If some critical information on a project isn’t covered earlier in the text, you can add it to this paragraph. The requirements that fall into this category typically include legal, copyright, licensing, and financial requirements, explain delivery conditions, or cover the issues of software launch, configuration and halt, etc.
Appendices
This part is often used to give definitions to terms and abbreviations if those weren’t explained in an introductory section. Sometimes it identifies the analysis models or general diagrams on workflow and teamwork, or includes a list of points to be defined later in a project, or a product mockup. You can add any information about a software product that wasn’t revealed in the text before, or not use the appendices at all.
How to Write a Good SRS?
The smartest way of cooperation with other people is to make their work as easy as possible. To do so, make sure that the information you write in the SRS is:
- Clear. Write the requirements in a way that is convenient and easy to understand by all the participants of the project. Use simple, straightforward, but informative sentences and consistent terminology. Explain all field-specific words in appendices. Use graphs, data flow diagrams, or any other type of visual information to make it easier for readers to assimilate information.
- Consistent. Present the information in a logical order and link the parts of your text one to another to engage a reader in a project and avoid distractions during reading. For the sake of consistency, all SRSs are formally structured to let specialists navigate the document easily.
- Accurate. Accuracy is in details. The more specific instructions you provide, the fewer questions would arise. Explain even the obvious things because the staff working on a project may change, and the SRS will be then handed to a lot of people. In this case, people won't waste their time reading and understanding the requirements.
Software Requirements Specification Template
Among a great number of software requirements specification templates, the most detailed and commonly used now was made by Karl Wiegers. K. Wiegers is an experienced software developer and author of numerous books and papers on software engineering and development process improvement. If you are in search of a step-by-step description of writing a specification document, you can download our template of the document.
Conclusion
Creating the SRS is a vital part of a project that helps to get a high-quality software product because:
- It gives a team an understanding of what exactly a client wants to get;
- It aims at passing the information on software to as many specialists as possible and must be written simply and clearly;
- It provides the characteristics of users, gathers all possible software usage scenarios and, thereby, predicts development risks;
- It describes software behavior in different operating environments;
- It helps to scrutinize the issues of software safety and security and find ways to avoid accidents;
- It serves as a basic document to follow during software testing;
- It minimizes the need for a further redesign of the system since all possible risks are analyzed and defined;
- It contains plenty of detailed diagrams and other visual information to ease the development process;
- It regulates communication between clients, managers, and development staff.
Leave your comment