Software Requirements Specification: What It Is & Why We Need It

The article by Karen Manucharian, Release Manager at QA Madness

Do you remember the episode of “Friends” where Monica asks Phoebe to cut her hair like Demi Moore? In the midst of the process, Monica notices that the haircut is a “little” shorter than what they had discussed. “Would you relax? This is how he wears it”. And that’s when they realize: Phoebe used Dudley Moore as a reference, and Monica ended up with a mannish haircut 🤭

What does it have to do with QA? Well, lack of clear, detailed requirements has quite similar consequences regardless of a sphere of our life. In startups, for example, it is a common situation that no one is one hundred percent sure what feature a target audience needs, how users will react to their product, and how it all should be implemented in the first place. To get it all right, you need to be a visionary like Kanye West or an extremely perceptive and persistent person who will insistently ask a product owner about the requirements and write the specification.

What Is Software Requirements Specification?

Correctly written documentation is the key to project success. Requirements specification, or simply requirements, is a detailed description of what is to be implemented to accomplish a specific goal. This document outlines a business idea in the form of a technical statement, making it understandable to the entire development team.

Usually, a business analyst (BA) is the one to draw up the software requirements specification, becoming an intermediary between a business and a development team. The purpose of requirements in IT is to accurately describe a business task that a dev team receives from stakeholders. Then, specialists use it as a reference for writing the software code that will satisfy the mentioned requirements.

For a QA team, requirements are the basis for concluding whether the code fulfills its purpose. However, documentation can feature ambiguous descriptions, or there can be gaps in the requirements. For example, sometimes functions are described inaccurately or not covered at all. In this case, a QA specialist contacts a BA for clarification.

Software Requirements Specification & QA

An SRS document is the foundation of the project. It addresses most of the issues a development team can face and saves a lot of time for figuring out those issues. Otherwise, specialists will have to clarify the details through emails, calls, and meetings during the development and testing stages. Besides, functional specification greatly facilitates acceptance testing. A properly written software requirements document features all the valid arguments that let you make conclusions about a product’s readiness for release.

Writing project documentation is a direct responsibility of a QA team. However, it is extremely important to involve QA engineers in this process – and the earlier, the better! QA specialists help identify and correct inconsistencies in descriptions and explanations of product features. There is a type of testing covering this — requirements testing, also known as documentation testing.

Once a BA completes writing a specification for a new feature, a QA or QC engineer starts analyzing the described requirements. A QA expert conducts a review and finds inaccuracies in the documentation. You can learn more about levels and types of requirements here. The earlier the review is conducted, the more time and effort a project team will save in the future.

Software Requirements Specification & QA

That is where our favorite recursive part begins. As you might guess, there are specific requirements for writing a technical requirements document. To write the specification correctly, you need to remember about several important principles:

• Correctness.
• Unambiguity.
• Completeness.
• Non-contradiction.
• Ability to check them.
• Traceability.
• Comprehension.

Now, imagine what can happen if at least one of these principles is violated.

To tell the truth, having no specification at all is better than a badly written specification that doesn’t explain much and takes time to redo.

Harm from Bad Requirements

It is more or less clear about good documentation, but what about bad requirements? Well, a document that doesn’t meet one or several criteria mentioned above falls under this category.

Here are some examples of what can happen if a team uses a poorly written requirements document:

1. Flaws in functionality description that usually cause a complete misunderstanding between a business and a development team. It, in turn, entails considerable loss of time and money, as well as the need to redo the document.
2. Lack of or unclear description of a purpose of a specific feature. It can be a consequence of an inaccurate description in a technical task. As a result, we have unfulfilled requirements that block acceptance testing.
3. Problems in interactions between old and new features.
4. Inconsistencies in web page or app design that can directly affect an end user, scaring them away.
5. Risks for the project if a key knowledge bearer leaves the project
6. Loss of time and money due to the long onboarding of QA specialists.

The consequences of working without a functional specification document will be about the same.

If It Seems There Are No Requirements

It’s disappointing to admit that there are still projects with no software requirements specification in 2022. Nevertheless, a QA team needs to rely on something other than experience in their work.

Software doesn’t exist without requirements. The very fact that you work with it shows that there are requirements – in the minds of stakeholders and product managers. BAs just haven’t received a documented version of these ideas yet.

So, if it’s a small project, QA experts might know the product better than others. Therefore, they can write functional specification and acceptance testing criteria.

What If Requirements Aren’t Documented?

Let’s say a QA specialist has just joined a project and figured out that there is no requirements specification or it’s poorly written. What should one do?

For starters, you can take the initiative. Try to convey the idea about the necessity to document the requirements or improve them. After all, the task of QA is to take care of the project’s quality as a whole, and not just look for bugs. You can raise this issue at a meeting, send an email with an explanation to the client, or write about your idea in the work chat. It depends on how communication with your team usually goes. The key thing is to competently argue your proposal.

A QA expert can show exactly how the lack of requirements affects the quality of the project. For example, you can mention the bus factor. If only one or a few specialists have exclusive knowledge about a product and they are hit by a bus, then this knowledge will be lost forever. So, the project will be delayed or discontinued.

If a client’s team doesn’t have a specialist who can write the requirements, or there is not enough time for this, we can offer to prepare test cases. They can be used as minimal documentation in the future to better understand how a particular feature works. If there is such a need, a QA team can help edit project documentation or write user guides for the system.

Thus, you shouldn’t ignore the lack of requirements. Instead, discuss it with the team and make a polite suggestion to improve the situation. And even if these proposals are not accepted, you’ll demonstrate your proactivity and efficiency.

Why Do We Need Requirements Specification & What Are Their Benefits?

So, what we have for conclusions:

• You can’t keep it all in your head. Sooner or later, you’ll definitely forget something. Therefore, it’s better to keep the functionality described in a document.
• Software requirements specification accelerates onboarding of new team members.
• If a key knowledge bearer leaves the project, all the information will remain available through the requirements. So, there are fewer risks for the project.
• If documentation is up-to-date, you save much time on effort that would be otherwise spent on clarifying the functionality.
• Reduced project costs due to time savings and clearer estimates.
• Requirements specification should be UNAMBIGUOUS and CONSISTENT.

You just need to find time to document the project’s theory and get it approved by stakeholders. Believe us, it’ll change your life on the project, whilst developers and newbies will be grateful to you.