How to draw up a development technical requirement specification and what should it be

In this article, we will tell you how to independently create a really useful document that will help you understand the problem and not vice versa.

To begin with, it is the perfect time to figure out the terms: during the process of developing a project we are constantly writing some documents, they all have different purposes and they are written for different sections of the project and different audiences.

At the start of the project, it is important for the team to understand the business task:

• what business goals should the product under development serve?
• what tasks should the product solve?
• who and in what situations will use the product?
• what are the limitations in terms of implementation?
• what are the business and product competitors?

Trying to convey the essence of the task to the development team, the customer, in turn, is used to operating with one capacious concept which is the technical requirement specification.

This is the document on the basis of which the development team implements the project, and which describes:

• the purpose of the system to be developed;
  
• list of functions and algorithms that should be implemented within the project;
  
• interface requirements;
  
• integration requirements (including a technical description of the API or any other data exchange format that you intend to use);
  
• system architecture requirements;
  
• business processes;
  
• user cases;
  
• development methodology;
  
• technological stack (what technologies will be used and why);
  
• and many other things.
  

That is, a technical requirement specification contains comprehensive knowledge about the purpose of the system, functionality and implementation methods and answers the following questions:

Obviously, the development of such documentation firstly requires specialized knowledge (therefore, a technical requirement specification is normally written by a system analyst or lead developer), and secondly, an understanding of business goals and objectives.

Conclusion: at the start of the project we do not need a technical requirement specification that describes how to make the system, but a document that answers the question "Why and for whom are we making this system?"

A document describing business goals and business system requirements is called the Business Requirements Document, or BRD, or business and functional system requirements.

You can draw up such a document yourself if you follow certain algorithms.

Let's consider an example: your customer has a certain business and the feeling (possibly supported by statistics) that the business has started or continues to stagnate.

Business: vinyl record store represented in Moscow by several offline stores.

Issues from the business owner viewpoint: vinyl collectors are not able to regularly visit the store, monitor new items and quickly order interesting goods, and since the business is not automated, all pre-orders are only made by phone, which is inconvenient for both business and the customer.

As a result, the store misses potential profit, increases the load on shop assistants and consultants, has a poor idea of a portrait of its customers and cannot communicate with the audience to the necessary extent to build a further marketing strategy. Plus, some unaccounted residuals constantly appear in the warehouse which distorts the statistics of commodity circulation.

Solution: to develop an online store where a customer can see the entire catalog, pre-order and track the execution of their order, and the seller can ensure timely execution of the order, receive a report on the state of the warehouse gathering statistics on user interests and user behavior along the way.

Well, we have an understanding of the business problem and its possible solutions. It is important here not to start writing a technical requirement specification, but still write the Business Requirements Document (despite the creative itch that encourages you to write a detailed development task).

We start the document with the "Business Goal" item. Our business goals are as follows:

If the goals are clear, the objectives of the project also become clear:

Intermediate result: the list of tasks is formulated where each task is tied to a specific goal (or several ones).

Now we are specifying what the system should be able to do so that each task in the context of each goal is successfully solved. That is, we fixate the main system functions.

The output should look like this matrix:

Now the development team understands why the customer needs an online store, what basic functions it should have, and by what parameters the success of the project will be evaluated.

But usually, online stores are not effective if they do not have an interface.

Formulating these requirements, many people end up saying something like "I want/I like" format, projecting in this way a personal perception of beauty on a system that first and foremost should be functional and convenient.

It is important to understand that design is not visual art, in relation to which everyone has the right to an opinion "like/dislike", and the interface is not just some kind of interactive picture painted in different colors.

An interface (screens, pages) is just that set of elements (pictures, texts, buttons, checkboxes, interactive forms, etc.), which users will use to interact with your system. And the requirements for it should be justified by the functional purpose of the system and use cases.

To draw a quality design, you need to understand what goals it will serve (the BRD answers these questions), what content will be published, what are the technical limitations on implementation and support.

Let's say right away — nothing pleases the heart of UI/UX designers and interface designers like references. That is examples of already implemented similar projects.

Designers ask for references not because every creator is a plagiarist in the soul and wants to make their life easier, but because everyone has different perceptions and interpreting formulations like "I want something grassy green and causing a sensation of a summer picnic in my grandmother's dacha" in the context of a specific design tasks is obviously a fortune-telling game on horoscopes, the loss of task meaning and time.

Adding a link to an already working project in BRD is clearly easier than describing each page in detail at the risk of being misunderstood.

Conclusion: it will be much easier for the team to understand the design task if there are the following elements in its description:

So, we agreed above on what goals our system will serve, what requirements the interface will meet. The next important point is to determine the boundaries of the system and the scope of the project.

System boundaries are a set of system components interacting with each other as part of the execution of relevant business processes.

For example, we understand that the online store will be integrated with some kind of commodity circulation system, from where the online store receives data on stocks and their cost (for example, we have the system "1C: Trade management"), therefore 1C is an important component of the whole system that takes part in such business processes as "Publication of the product catalog on the website" and "Ordering goods by the customer".

The scope of the project is a set of system functions that must be implemented as part of the project "Development of an online store".

If we turn to the example of integration with 1C, then the tasks of integration with 1C fit within the scope of the project, but the tasks of possible improvements of 1C will relate to another project.

The experience shows that workable systems are released with due quality and on time if these rules are kept.