What is a requirements specification and how to test it?

Requirements specification is a document that contains a set of requirements for a software product. The requirements describe the logic of the product (functional requirements), its appearance (user interface), constraints in development, and non-functional requirements. Use cases are often used to describe functional requirements. Use cases include options for how a user can interact with the software. Non-functional requirements describe constraints on the product design and implementation (product performance, security, reliability, compatibility, design constraints, quality standards).

So what are the main sections of a requirements specification? The document follows a standard structure that may vary from project to project, but in general looks like this:

1. Introduction
2. Overall Description
3. Functional requirements
4. System Features
5. Interface Requirements
6. Other Nonfunctional Requirements
7. Other Requirements

You can find specification templates in documents 1, and 2.

Even though the presence of documented requirements is already a quality criterion for the developed product, the requirements themselves might be described improperly. Poorly described requirements have a harmful effect on the development team's understanding of what kind of product should be in the end. Unclear requirements can be interpreted by team members in different ways, leading to a situation where one task is performed by several specialists at the same time, using completely different methods or in a different form. As a result, errors may occur in the product, which would not have happened if the requirements had been clarified, tested, and corrected.

Let's look at how requirements are tested. To understand that the requirements are poorly described, one must first understand what a well-described requirement should look like. Good requirements are characterized by the following quality criteria: 

Atomicity

Based on this criterion, requirements should be described without further elaboration or splitting one requirement into several. An example of a bad requirement - a user can register and add personal information to a profile. Registering and adding information are two different functions and so should be described and clarified separately in different parts of the specification. An example of a good requirement - a user can subscribe to other users' updates.

Completeness

Requirements for the same functionality should be described in one specification section. A situation where the same functionality is described in different parts of the document must be avoided.

Consistency

The requirement must not contradict other system requirements and constraints. 

For example: the phone number of the user should be requested from social networks. This obviously contradicts the restrictions of social networks, as the phone number is hidden information that social networks do not provide. The users have to enter their phone numbers themselves for the system to receive it. It is important that there are no such contradictions between specification sections. For example, the same button should be named the same way in the entire document.

Traceability

A criterion that helps to understand why a particular requirement has been written. For example, when it comes to websites selling alcoholic beverages, registration may be required only for adult users due to legal restrictions.

Relevance

This criterion checks whether the requirements are up-to-date (e.g., from the legislative/technical side or from the side of product usability, and relevance of its user interface). Outdated browsers, such as IE, or outdated mobile devices and their OS should not be included in the requirements, as they are practically not used.

Implementability

A check that the requirement can be implemented with the help of relevant currently available technologies. For example, there may be a requirement that the system should provide a fast response (here, it needs to be specified - no longer than 3 seconds) under moderate load (here, it also needs to be specified by the number of users and actions performed by them). However, the requirement for a response time of less than a second under a very heavy load is an unrealistic requirement in today's realities.

Clarity

The requirement must be formulated in a clear, specific, and unambiguous way to ensure that it is equally understood by the entire development team. 

Verifiability

The creation is used to determine whether a finished product can be compared to a requirement and check whether this requirement is met. If the requirement is described too vaguely, it will not be possible to verify it. For example: photos should be uploaded quickly/profile settings should be intuitive/order placement should be easy. To test such requirements we need to clearly define how fast/intuitive/easy the process is.

Obligatoriness

Defines how important and prioritized the fulfillment of a given requirement is. Each requirement in the specification must be assigned importance, stability, and priority. This allows the development team to prioritize tasks.

Identification

Each requirement must have a unique ID that links the requirement to other project artifacts. For example, an ID of the requirement that is tested by the test case is indicated in the test case description.

Modification

Requirements should be easily modified if necessary.

Completeness

It is the most difficult criterion according to which the requirements must exhaustively describe all the functionality of the system. Everything that the system must do must be specified in the requirements, otherwise, a serious mistake can be made when designing the architecture. The problem is that it is very difficult to accurately specify and describe all functions at the initial stages of the system design. The requirements are first described using more general statements and then they are refined.

How are requirements tested?

Requirements testing is a necessary step that helps to improve them by clarifying, detailing, and ensuring mutual understanding between team members and avoiding different interpretations. Moreover, testing the requirements will show whether they can be implemented in general (whether there are enough resources, time, and budget, or whether it is possible in terms of technology).

These are the following techniques for testing requirements:

1. Mutual review. It is divided into Quick review – the author of the requirements provides the document for a quick review to colleagues to give their comments, recommendations, and questions in the form of a simple informal discussion. Technical review – the requirements are provided to a group of specialists for review. Formal inspection – the requirements are reviewed by a large group of specialists where all comments are documented. 
2. Ask questions. If there are any questions during the study of the requirements, all controversial issues should be clarified with experienced colleagues or the customer.
3. Verification of requirements. For verification, consider creating a checklist or test case for a specific requirement. If you manage to quickly come up with checks for a checklist or test case, this is a good sign.
4. Imagine the behavior of the implemented system, that is, the user's work with the system created according to the tested requirements. This may help to identify unclear or ambiguous moments in the system.

Graphical visualization and prototyping – representing information in the form of drawings, and diagrams, and creating a system prototype (user interface) helps to better analyze the information in the specification, and find inconsistencies and inaccuracies. 

Apart from testing the requirements well and finding inaccuracies, it is also necessary to formulate and leave comments on the requirements correctly. So what are the common mistakes to look out for when making comments and what should be avoided? Here are some tips:

• Do not change the format of the documentation file. You should not delete or modify the original text, instead, it is better to leave comments on the text or suggest corrections. The document must remain in a format that is suitable for editing (TXT/Excel/DOC). Pay attention that the .pdf format or pictures are not suitable. 
• Only problematic areas should be mentioned in the comments. The well-formulated requirements should not be marked in any way. This only complicates the work with the comments, since one will have to choose among all the comments those that need to be corrected.
• Do not write the same comment in several places. This quality criterion applies the same way as with the requirements. If one needs to write the same comment on the same information, it is better to put this comment at the end of the document and list the items to which it refers. And already in the items, one can make references to the comments at the end of the document.
• Specify exactly the place in the text to which the comment applies. There is no need to highlight the entire paragraph if the comment is about a single sentence. In Word, it is possible to select the desired part of the text and write a comment on it.
• If you need to add a clarifying question, it should be very precise and well-formulated. For example, there is a big difference between "What are the default settings?" and " What kind of default settings are there?". The second one clarifies important information for the specification, while the first one is completely meaningless and incompetent.
• Do not write very long comments; a short, clearly formulated, and structured text without spelling mistakes is perceived much easier.
• Do not write comments in the form of criticism towards the text or its author, instead, make constructive comments. Categorical comments such as "this is impossible to implement" also need to be justified.
• Do not edit the requirements independently without approval. Amendments to the specification can be made only after approval from the responsible persons. Otherwise, a serious problem may arise when something in the product is not implemented as planned due to uncoordinated changes in the requirements.

A requirements specification is an important document that ideally should be described for every product. Well-described requirements make the work of the entire development team simpler - it's easier for programmers to understand how the product should be implemented and how to design the architecture correctly, while for testers, it is also a source of expected results during testing. The ability to write and test requirements well is a sign of competence and professionalism.