When a client approaches an organization to implement their project, it is essential to create a Technical Specification at the agreement stage (before the development stage begins). This applies to almost all types of desired products, whether it involves developing a website/MVP, branding, styling, or refining/optimizing an existing product. The Technical Specification allows the task to be structured, gives the executor an idea of the expected result with all the details and features of the future product, calculates the preliminary cost and duration of development, and ensures that the entire work process is carried out without unnecessary delays in agreeing on undisclosed details.
This, in turn, guarantees that both interested parties – the client and the executor – will be satisfied with the speed and efficiency of the development and will receive a predictably excellent product in the end. In this article, we will explain how to create a Technical Specification that ensures the quality execution of any project.
Let’s start with the definition. A Technical Specification (TS) is a document in which the client describes precise and comprehensive requirements for the future product, the sequence of stages, and development timelines. A clear TS allows for systematic and efficient development, providing all the necessary information for implementing the required parts of the project.
Many mistakenly take a Concept-Idea for a Technical Specification. The difference between them is significant and has a considerable impact on both the development and the overall result. A Concept-Idea is a starting point before creating a Technical Specification but cannot replace it as it only contains general descriptions of the future product.
A Concept-Idea is a general visualization of the future product, its capabilities, and functions. Usually, the vision focuses on the already functioning product and its usefulness for business processes. It is more of a motivational element rather than clear documentation for managing development. Meanwhile, a TS provides a more specific and complete description of all necessary elements, their properties, and functions.
Concept idea:
Buy and eat delicious bread.Technical Specification:
It is necessary to buy one loaf of bread today by 7:00 PM
- made from white flour
- sliced along its entire length
- packaged in a cellophane bag
- produced no earlier than this morning
- weighing 250-300 grams
As you can see, the amount of information the executor receives from these two tasks differs significantly. The likelihood that the executor, guided only by the first task, will be able to deliver even a satisfactory result is extremely low. Too many factors are not taken into account, which can result in an outcome that does not match the client’s initial expectations.
But with the second version of the task, everything is very straightforward. An executor with sufficient qualifications in the matter will be able to complete the task without difficulty and on time, delivering an excellent result that fully satisfies the client. Alternatively, they can make adjustments to the document even before starting the work, which will adjust the work plan without affecting the deadlines and final result.
In the case of developing a web project, a Technical Specification can be quite extensive. In such cases, it is recommended to break down the development process into shorter stages, with exact and comprehensive descriptions of the results that are easier for the executor to provide and present to the client. To maintain the overall timeline of the product development, a Product Roadmap is introduced. This document segments the development into time intervals, visually showing the overall progress of the product’s development.
A Roadmap is a document that visually (often graphically) displays the strategic plan of the project: the timeline and sequence of all key stages of product development. A roadmap allows for the assessment of deadlines for each stage and the understanding of the task sequence. It helps in planning upcoming development stages and in timely preparation of all necessary supporting materials and resources.
The development team for even a standard web project can often consist of 10-15 people, including both full-time staff and hired specialists (designers, architects, optimization experts). A well-prepared TS allows for quicker onboarding of new team members into the current development processes. It can answer some questions that arise during the work, which were already addressed during the planning stage and are detailed in the document. This positively impacts the continuity and quality of the development process, allowing for faster development of product elements and more thorough and detailed testing of the results.
Competitiveness is an important aspect that must be considered at the business planning stage of the future product model. Monitoring the state of competitors and the target market as a whole is a mandatory process. This not only helps to better calculate economic models but can also showcase existing algorithms for providing certain services. Do not hesitate to mention direct competitors in the Technical Specification. Indicate specific functions and algorithms that you would like to implement in your project, or existing errors in competitors’ products that you would like to avoid in your product. Visual aids and examples help quickly demonstrate certain algorithms or approaches and show the desired sequence of processing user requests in the application. Even if there is no competing product containing all the necessary functions, you can specify segments from different products that closely reflect the essence and principles of the required functions.
In the “User Scenarios” section of the Technical Specification, it is important to display and describe the general usage scenario of the future product. User scenarios involve a detailed description of the sequences of actions that the application’s client (or the administrator/manager when working with the admin panel) will go through. This includes the volume and type of information obtained at each step/stage, the necessity and availability of optional or non-mandatory actions, as well as the general rules for dividing accessible areas for authorized/anonymous/administrative users.
Example of User Scenario for using the image online converter function on the project’s website:
- The user visits the project’s homepage and receives a notification prompting them to authenticate to access their previous conversions and action history.
- If the user agrees to authenticate, they receive a pop-up window with a Login and Password form.
- If the user declines to authenticate, they return to the project’s homepage
(provided mockup of the project’s homepage)- On the homepage, the user clicks on the graphic file upload form and, after selecting the desired file, sees the upload progress bar.
- Upon completion of the upload, the user is presented with a choice of the resulting image format from the available options (depending on the image type and the user’s account level if authentication was completed).
(mockup of the format selection window)- After clicking on the tile with the required image format, a progress bar for the conversion process appears on the page. The user waits for the result. Any other functions or pages of the project are unavailable during this waiting period.
- Upon completion of the conversion process, a message of successful completion appears on the page, and the user is prompted to specify the path for saving the result.
- After saving the converted image, a prompt to perform the next conversion appears on the page.
It is considered good practice to create a list of all third-party services you plan to integrate into the product or connect to the project, such as payment gateway systems or external authentication modules. All services you plan to connect via API during the product development process should be specified, including the functions they will perform in the application.
Additionally, it is important for the Technical Specification to be written in simple and understandable language, as it will be studied not only by technical specialists but also by sales department managers and the client’s team. Of course, technical terms are unavoidable, but the text should not be overloaded with them. Diagrams, drawings, video examples, and tables are not mandatory but highly recommended, as graphic elements convey information in a clear and understandable form.
Many projects may contain a number of specialized terms. Not all specialists involved in the development may be familiar with terms outside their professional scope. Any words that might have multiple meanings or are not obvious to those outside the field of the developed product should be included in a glossary and described in detail. For instance, IT specialists creating a cost calculator for a reinforced concrete foundation on a website may not know the specifics of this technology and the accompanying terminology. Clarifying each unclear term individually would waste time and reduce the efficiency of the entire process. This also applies to narrowly specialized formulas or calculations. If we consider the same example as before, a project manager or programmer likely does not know how to accurately calculate the necessary amount of materials required for pouring foundations of different shapes and types. In this case, the client must comprehensively describe all possible configurations and aspects of such calculations with clear explanations of the sequence and formulas to achieve the correct result. This way, a person who is not an expert in construction can step by step understand and implement all the calculation functions for the process, such as on a sample calculator for the website.
The development of a Technical Specification is usually undertaken by specialists who know all the nuances of the planned development and how the project will be executed – work stages, deadlines, components, and the final product. These specialists include PMs, developers, and testers. Each of them contributes profile-specific information to the TS, building an overall picture of the project.
You can entrust the writing of the technical specification to in-house specialists who know what product they need and can detail the desired functions and characteristics of the future product in the document. However, this approach often results in double work. It is much more efficient to obtain general requirements for functions and key capabilities from in-house specialists and provide them as recommendations to the team creating the Technical Specification.
It is better to entrust the writing of the technical specification to professionals – those who will be developing the product themselves. You can approach them with an idea without having a clear vision of how to implement it. A good Technical Specification will save time, money, and nerves for both the client and the developer.
A well-prepared TS can serve as a crucial document in case of disputes between the client and the executor regarding the quality of the result and the delivery deadlines. Such a document will protect the client from delays in the executor’s work and the executor from changes in the initial requirements from the client.