|How-to||– 12 min read –||October 16, 2019|
How to draw up a development technical requirement specification and what should it be
What is the technical requirement specification (and why you do not actually need it)
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.
What is a technical requirement specification
- 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:
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?"
How to formulate business 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:
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:
But usually, online stores are not effective if they do not have an interface.
What about the design requirements
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.
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:
Remaining within borders
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.
Learn how to get the most out of Serpstat
Want to get a personal demo, trial period or bunch of successful use cases?
Send a request and our expert will contact you ;)
Cases, lifehacks, researches and useful articles
Don’t you have time to follow the news? No worries!
Our editor Stacy will choose articles that will definitely help you with your work. Join our cozy community :)