How to build a software requirements specification while you test a system

All of us in the testing world have had to execute testing when you don’t have the software requirements at least once, right? If not, you’re lucky! Without the software requirements specification (SRS), it’s very difficult for us to do our jobs since it details what the application is supposed to do and how.

But, it’s okay; Don’t panic if you don’t have one! 

We have some tips by Pilar Albacete, one of our leading testers at Abstracta, for building an SRS that she came up with while working on a project without defined requirements, in which she began to work on documenting them so that she could have a benchmark to test the system. This documentation would then have many useful purposes for the client such as defining processes, methodologies, user manuals, or if one day, they decide to change the system, they would be clear about their needs.

Tip 1: Project Kick Off

Having a kick off to start the project will make users and stakeholders feel more committed to the project. You can present the objectives of the project, the way the work will be done, how much each person needs to participate, and for what each person is responsible. You might want to bring snacks if that helps to get them interested 🙂

Tip 2: Find a Template for Your Specification Documentation

Why start from scratch if you don’t have to? Ask if the client already has any old specification documentation done and if you can use it as a reference. This will help you start and also save you time by serving as a guide for the format, colors, font, etc. that you should use. If they don’t have one, then you’ll have to just create your own and revise it later.

Tip 3: Interview Stakeholders and Users

Research as deeply as you can to find out the details of the software requirements. The users may assume that you already know something about the program that you do not, so ask as many questions and keep them as thorough as possible. Probe them with questions, cross-examinations, statements, etc while keeping in mind the sequence of steps that you will need to stay organized. Then, go back to each participant to have them validate what you have documented afterward.

Tip 4: Define a Business Rules Section

Every requirement should have a Rules of Business section, as it is very important to specify assumptions and constraints that come up. These rules affect the definition of use cases of that requirement and those of other requirements that could be related. An example of a business rule could be “Only supervisors are allowed to approve refund transactions.”

Tip 5: Specify the Data for Each Requirement

It should be made clear what each element of the screens (label, dropdown, combo boxes, text) is used for. It’s recommended to document these in the Specification Data Requirement Table. This table must not point to data type, or validation, but definitions. For example, specify in the fields the dates to and from to create an instance of a determined entity: what they mean, where they come from, and what was entered. If we have a field for financing interest, for example, we would say what it is, what formula is used, the time period of the calculation, and where this period is specified. This way we can avoid ambiguities and confusion.

Tip 6: Include a Table of Pre-Conditions and Post-Conditions

This gives a more comprehensive view of the flows of the process at a higher level. It aims to describe the requirements such as what is necessary for an action to occur and what must be required to happen after the action.

Tip 7: Plan and Validate

After you are done researching and putting together the requirements, make sure to go back to the people you surveyed to check that the requirements are exactly as they want them to be before testing. It would be a major waste of time to start testing according to inaccurate requirements.

We hope these tips are useful to you and that you share any other tips that you have based on your own experiences!

Recommended for You

The Software Testing Wheel
Yoda’s ‘The Way of the Jedi Tester’: A Guide for Agile Testing