Software Requirements Specification – A Must for Any IT Project

Have you ever tried to assemble furniture without instructions? You can have all the components you need and an image of the final product, but the lack of a detailed plan for how to put it all together will make the process slow and overcomplicated. The same goes for developing software without a clear software requirements specification (SRS).

At Apriorit, business analysts always start a project by working on the stakeholder requirements and developing an SRS. In this article, we talk about how this document helps us deliver complex projects within the estimated time and budget. We also take a look at the challenges and best practices for creating a quality SRS and share some of our experience working with software requirements documents.

What is an SRS and why is it important?

By definition, a software requirements specification describes a product to be developed. It commonly includes the purpose of the software, its use cases, functional and non-functional requirements, external and internal interfaces, and desired performance.

An SRS is usually developed according to guidelines and templates provided by ISO/IEC/IEEE 29148:2018 or the IEEE 830-1998 standard. However, a business analyst may deviate from these standards to adjust an SRS to the needs of a particular project.

Business analysts develop software requirement documentation after they elicit project requirements from stakeholders. A high-quality SRS:

• Structures and formalizes the project’s ideas. Original requirements may be fragmented, inconsistent, or incomplete. When preparing an SRS, BAs structure requirements, identify gaps or unclear demands, and elicit requirements from stakeholders.
• Creates agreement between all parties. An SRS contains all requirements that the client and the development company have discussed and agreed upon. If either party has doubts about the agreement, they can simply check the SRS.
• Clearly defines the project scope. An SRS outlines the priority of the requirements, which helps the development team plan project iterations, releases, and the scope of work.
• Allows for precise schedule and budget estimates. The development team can analyze SRS contents to draw up the budget and accurately estimate the project.
• Provides the basis for software testing. Quality assurance (QA) engineers test software against the SRS to determine if the developed solution complies with the client’s requirements. 
• Simplifies future software improvements. If the client needs to upgrade the developed software, it’s easier for a new contractor to study it by analyzing the SRS than by investigating or reverse engineering the software itself.

Skipping the development of an SRS or creating a low-quality SRS document will harm product development. Here are the key risks of not paying enough attention to the SRS:

• Inaccurate schedule and budget estimates. Without a clear and complete requirements specification, a development company can’t provide accurate estimates of a project’s duration and budget, which might result in financial losses for the client.
• Developed software doesn’t meet all the client’s needs. An overcomplicated or ambiguous SRS can confuse developers instead of guiding them. Developers may misunderstand the stakeholder’s requirements and the client may end up with software that doesn’t meet their needs.
• Communication overhead for all project participants. A low-quality SRS doesn’t provide the project team with complete requirements. In this case, project BAs, developers, and stakeholders will have to hold many meetings to negotiate and clarify each next step. 

The only way to mitigate all these risks is to establish a fine-grained SRS. However, this is not easy. Now that we’ve figured out what the SRS document is, let’s take a look at the key challenges of creating an SRS and best practices that BAs can use to deal with them.

Challenges of SRS development and how to overcome them

Creating a high-quality software requirements specification in software engineering is challenging even for an experienced BA. At Apriorit, we’ve worked out a set of best practices to overcome some of the biggest challenges of writing software requirements specifications:

Extensive and overcomplicated requirements 

This challenge is common for large projects with many stakeholders. When working on such projects, BAs need to process the requirements carefully before writing them down in the SRS. To sort out complex requirements, our BAs use the following best practices:

• Create the SRS with a clear structure. A well-structured SRS makes it easier for the project team to understand the requirements. When working on the structure of an SRS, a BA should take into account developers’ and stakeholders’ preferences and choose the most comfortable SRS format for both sides. For example, one of our clients doesn’t like user stories, so we prepare use cases and mockups instead. For another client, we combine user stories with mockups to make the user stories easier to visualize and understand.
• Add a glossary. A glossary is a source of terms used in the project and domain. The lack of a glossary may cause misunderstandings between stakeholders and developers. In one of our projects, stakeholders used the words “payer,” “plan,” “health plan,” and “market” as synonyms for “insurance company.” That caused a lot of confusion until our BA added those definitions to the glossary.
• Link the SRS with other project documentation. An SRS in software engineering isn’t the only source of information on the project, and linking it with other documents allows the team to quickly find descriptions of necessary requirements. That’s why our BAs augment an SRS with references to analysis models, previous specifications, test cases, tasks in bug tracking systems, etc.

Constant changes in the requirements

Changes in the requirements are unavoidable in any project. Yet there are some projects where requirements keep coming in even after all project discussions are over. In this case, the development team can’t make any progress as they have to rework the developed functionality or add more features in accordance with newly introduced requirements.

Here’s what Apriorit BAs do to make introducing necessary changes to the project scope manageable and efficient:

• Elicit requirements. Elicitation is the process of researching, discussing, and augmenting stakeholders’ requirements. It helps a BA reduce the risk of discovering hidden and undiscussed demands in the middle of development.
• Make the SRS adaptable to changes. Neverending changes to the SRS might make this document useless to the development team. We faced this issue in one of our company’s first projects. Our BA developed the SRS in full accordance with IEEE standards. But because of many changes, the document became too long and too complex for the developers to follow. Based on this experience, we prefer to develop a lightweight SRS that’s easy to understand and modify.

Conflicting requirements

This challenge is common for projects that have many stakeholders. Usually, these stakeholders belong to different departments and have diverging or even opposite opinions on the software. Simply writing all their requirements in an SRS will confuse the development team.

• The requirements elicitation techniques discussed above are also useful for resolving requirement conflicts. Another practice that helps our BAs detect and work out such issues is conducting a team review of the SRS.
• Team review gives developers, QAs, and designers the opportunity to ask questions about the SRS, get a clear understanding of the required functionality, and identify gaps in the requirements. After conducting a team review, our BAs can be sure the team understands what they’re required to do.

Misunderstanding of the desired functionality

To ensure a correct understanding of the requirements, the wording of the SRS is as important as the logical structure of the document. A BA should constantly verify that the requirements are clear. 

Besides eliciting and structuring the client’s requests, Apriorit BAs use these best practices:

• Write positive requirements. It’s best to avoid using “don’t” in an SRS since it’s difficult to implement something that is forbidden. For example, the requirement that email notifications are sent when they are on in the user profile settings is more obvious than email notifications are not sent if they are off in the user profile settings. But sometimes negative constructions are necessary, such as with requirements like the application must not require a system restart.
• Use verifiable requirements. Statements like the system must be stable or a large number of users can work with the system simultaneously might seem clear, but it’s hard to verify their implementation. BAs need to provide exact descriptions for such demands: Stable under which conditions? How many users constitute a large number? Etc. This allows QAs to confirm if the requirements are implemented correctly.

These best practices help a business analyst develop an SRS that is useful for the whole project team. To make the application of these best practices even more efficient, Apriorit BAs have created their own rules for preparing software requirement specifications. Let’s see what helps us make the most of them.

How do we develop a simple and efficient SRS?

Developing an efficient SRS is an important part of what a BAs does. Over the years, Apriorit BAs have worked out their own approach to creating this document:

The first thing that differentiates our SRSs is their lightweight structure. We’ve already mentioned that an SRS developed according to all the standards is quite a complex document. As a result, instead of working on the software itself, developers have no choice but to spend a lot of time sorting out this document, especially for large projects. To resolve this problem, Apriorit BAs have come up with a simplified SRS structure that includes only five components:

1. Glossary
2. Introduction
3. General requirements
4. Use cases (including preconditions, normal flows, exceptions, and postconditions)
5. Mockups and UI descriptions

A lightweight structure allows our BAs to make the requirements readable and easy to understand for the project team. As a result, team members spend less time studying the SRS.

Secondly, to improve the understanding of the software requirements, we create formal written descriptions and visual models. Visual models that we use include:

• Use case diagrams — Depict relationships between users and actions they can perform in the software
• State diagrams — Show the lifecycle of an entity
• Entity relationship diagrams — Show the relationships between entities stored in the database
• Data flow diagrams — Illustrate how software uses data
• Business process model and notation — Represents business activities

These two requirement representations complement each other: formal written requirements provide detailed descriptions of features, while visual models make them easier to explain. Also, different team members need requirements to be presented in different ways. For example, a BA can prepare a visual representation of a complex feature with alternative flows to help developers understand it. But stakeholders won’t need this representation because they don’t need to know the details of how the feature is implemented. For them, a BA will create only a general written description of the feature.

Finally, when working on an SRS, our BAs take into account the project’s development methodology. At Apriorit, we prefer Agile development because it’s flexible and emphasizes communication inside the team. Agile projects are developed in small iterations, and this applies to SRS development as well. 

At the beginning of a project, BAs collaborate with stakeholders to specify the general software requirements and demands for the first iteration so developers and QAs can start working on the project. Meanwhile, analysts continue eliciting requirements for the next iteration.

Changes in requirements are particularly common for Agile projects. To track changes and keep the team updated, our business analysts create a Confluence space with the SRS. Frequent changes also call for creating high-level user stories and acceptance criteria, which are easier to develop and change than formal software engineering specifications. At the same time, user stories and acceptance criteria provide the development team with all the information they need to start working. 

These three rules help our BAs create SRSs that are useful and easy for project teams to understand. 

Conclusion

Creating a clear and complete software requirements specification is just as important as designing software and writing code. A well-thought-through SRS allows the project team to estimate the project, calculate the budget, plan development, test the solution, and avoid miscommunications in the process. 

That’s why business analysts at Apriorit pay a lot of attention to the SRS document. Software requirements specifications help our dedicated teams deliver complex projects on time and in strict accordance with our clients’ requirements. 

Whether our BAs are working on an Apriorit project or augmenting a client’s development team, they deliver the best possible results. Contact us to find out how Apriorit BAs can facilitate your project!