2 votes

Good day, dear readers. Working on a website with a client is always difficult. The client, as a rule, wants either “something cool” or “nothing unusual, let it be like everyone else.” Abstract concepts, you will agree. If this is your first order, then you may even be happy with similar words: “Cool, they give me creative freedom, I can do whatever I want.” I can tell you from experience, nothing like it!

The customer has his own understanding of “cool” and “like everyone else.” You may not guess, be in the wrong mood, or the client will simply decide that “for that kind of money, this guy (or girl) can do a little more work.” To prevent this from happening, today we will discuss how technical specifications for website development are drawn up.

Action plan for working with the customer

You find a client. He is ready to pay the money, and you get to work. Where to start and how to proceed?

• First communication.

So, you have received the initial information: this can happen in person (if you offer services yourself) or over the phone (when the client finds you on their own). Let's say you know that the customer wants an online store from you, and he himself owns a chain of jewelry. Never start a conversation about the site right away. Make an appointment so that you can all prepare together and in unison.

Try to somehow motivate the person to look at the information so that he has a clearer idea of ​​what he wants from you.

• Preparation and first brief.

Look at sites that you think will be suitable for the client. Download some templates and say the site could look exactly like this. The more materials, the better. Let you have something to show the customer, have a clear idea of ​​what he likes and what he doesn’t. Avoid abstract concepts from the series: beautiful, convenient, high quality. Everyone has their own ideas about these categories.

Ideally, it is better to even leave the client with these materials for a day or send them by mail a few days before the meeting. Although, at this stage, the customer, as a rule, is not particularly interested in the portal. He is ready to cut the truth straight after the fact and force you to redo it and add something new, but not discuss anything in advance. Therefore, the only way out is to ask as much as possible and write down every word.

• Drawing up and signing technical specifications.

Remember, the more pieces of paper, the cleaner the butt. Write down, draw up and sign everything possible from the client. Subsequently, you will have something to show. In general, when writing out the technical specifications, immediately imagine that you and the client do not see eye to eye and are defending your case in court.

We are not talking about super expensive projects, and I hope that you will have good luck with customers. But one meticulous client can ruin your mood for a long time. You will want to spit, refuse money, just not to meet with him anymore. This is understandable, but if you initially show yourself as a professional, study everything thoroughly and show yourself as a respectable person, then you won’t have to do this.

One day I was very lucky. Before coming to the meeting, the client studied the issue and himself drew up not only a competent technical specification, but also an artistic assignment. That is, literary and detailed description what it should look like. My surprise knew no bounds, to which he replied: “I believe that the customer himself, first of all, should know what he wants, and not torment specialists.” Unfortunately, this is rare, so we have to ask questions, prescribe and approve.

• Development and reception.

Once you have signed everything, you can begin implementing the project.

What should not be in the technical specification, and what should be there

In fact, the technical specification should not contain instructions regarding the design itself. You write that on a website for a programmer you will draw a keyboard, and then it starts - it’s not like that, I want it to be in the style of comics and then prove that you are not a deer. The better you prove yourself as a professional, the fewer complaints there will be against you!

You yourself know in what style and what should be drawn. You are faced with a task: to improve brand awareness or motivate people to vacation in such and such a place. How you will implement this task is your problem. What was also missing was for the customer to teach you how to write code and tell you what tools to use.

Let your statement of work contain the phrase: “Everything that is not agreed upon is performed at the discretion of the performer.” And it is not necessary to make this line in small font. Let him think in advance, and not start dreaming when the project is already ready. Of course, you can and should make small changes. A good reputation is the key to future clients, but sometimes a customer can be so annoying with his wishes that he doesn’t want to live.

Once again I would like to focus your attention on the fact that the technical specification should not contain abstract concepts: “convenient”, “beautiful”, “high quality”, etc. Let the boundaries be clear: instead of search convenience, it is better to write filtering by date or material.

And don't forget about the signature. Everything is serious, the customer must understand this.

In general, I highly recommend that you pay attention to the little things. Imagine a lathered woman comes to you and hastily unbuttons her huge jacket so that an oversized scarf sticks out of it. He takes out of his bag a crumpled note of 18 sheets, folded a hundred times, and tries to smooth it out with nearby objects. Red face and inarticulate: “Here, I wrote and made it shorter, this is what your website will look like, sign it.”

Another variant. A young man knocks on your office door, slowly undresses, takes a folder out of his briefcase, slowly opens it and leisurely invites you to look at just one small piece of paper, holds out a golden pen and invites you to sign this document.

Let the young lady from the first example do a titanic job, she read a thousand books, drew 18 examples to choose from, and basically did everything herself. She is able to create an incredibly cool project that will lead your company to prosperity and worldwide fame. And the young man from the second example doesn’t know how to do anything; he printed out a sample from the Internet, which in no way suits you.

I assure you that any client will torture the poor woman with nagging, wishes and alterations, and will accept the young man’s project, if not immediately, then for the second time. It's not about what you can do, but how you act and the impression you create.

There is GOST, according to which you can create technical specifications for website development, and there is long-term practice. State standards do not always fit the realities of life. Let's try to combine both of these parts.

Whether you are writing technical specifications for the city administration or the legendary Vasily Pupkin, the content is best done in accordance with GOST. Learn this in advance.

It looks like this:

1. Glossary
2. General provisions
3. Subject of development
4. Purpose of the document
5. Requirements to graphic design site
6. Website design requirements
7. The procedure for approving the design concept
8. Functional requirements
9. Requirements for website presentation
10. Requirements for a content management system
11. Requirements for sharing access
12. Requirements for types of collateral
13. Requirements for information support
14. Software requirements
15. Technical requirements
16. Requirements for linguistic support
17. Requirements for ergonomics and technical aesthetics
18. Requirements for project acceptance and delivery
19. Requirements for filling information
20. Personnel requirements
21. Distribution provision procedure
22. The procedure for transferring a site to technical means customer

True, you will not have to create your document with the task in this order, but to make it easier to understand, I will tell you according to this plan. At the end of this article I am attaching a sample that you can download and work on it, based on the transcript given in this part of the article. This template is good because it has All, even what you will never need. But you must process it for yourself and cross out any unnecessary crap that you consider unnecessary.

Glossary

According to GOST, the document should begin with a glossary, but in fact you will write it at the end. Here you need to give the terms that you will use when working with the customer. You tell us what hosting, a website and other nonsense are. All this nonsense can be downloaded from the Internet.

However, in addition to this very heresy, it is necessary to mention terms, in the understanding of which you and the customer may have a difference of opinion. You mean one thing, but he puts a completely different meaning into the words.

General provisions

At this point we need to answer the question of what we are actually going to do and why.

Subject of development

What we will do is approximately clear. The client provides this information almost immediately. It is more important to understand the operational purpose of the site, that is, what benefit awaits the client. It is clear that all customers want to make a profit through the site. This formulation will not work.

Think about how the client will make money, what his goal is. If this is an online store, then it should be engaged in sales; if it is a corporate website, then they like a beautiful phrase: “increasing brand loyalty,” informing about the company’s activities, and so on.

Purpose of the document

Here we tell you how important this document is. We show that this is not a simple trick, but wow! We use legal terms. This part can be copied from the Internet, but do not forget to carefully read what you write!

By the way, in this same part you need to include information that everything that you do not discuss with the client in advance remains on your conscience. You are free to do whatever you want if he “forgot”, “changed his mind” or “wants everything completely differently”.

Requirements for website graphic design

Website design requirements

Here you need to describe in general terms the design of the site, what should be there and what points should be adhered to: corporate colors, fonts, and so on. In general terms, don't go into details.

The procedure for approving the design concept

In this part, you again intimidate the client using legal terms. You tell him that you are going to provide him with a website design in the form of a picture made in Photoshop. He is obliged to watch it within the specified period. After which we will provide you with the edits, and you, in turn, will think about whether he is a deer, and you will coordinate and understand how logical these changes are and whether you will take on the “correction”.

Functional requirements

Here you describe what we are actually going to do. We describe the visual component. The chapter develops into three parts: we describe the main page, internal and site structure.

Be careful. This is an important point where it is better to write more. For example, you should have a “Related News” section. What will you do: write an algorithm that will calculate which articles are closest to the topic, give a list of the last five articles added to the site, or will the author of the text have the opportunity to insert links into this block independently?

Requirements for website presentation

1. Site structure: we describe what categories (headings) will be on the site.
2. Home page: best with a schematic picture and description of the main elements.
3. Internal pages: same as in the previous paragraph. Diagram and description of internal pages.

If you are making an online store, you can also insert a diagram of the order page, payment confirmation, and so on here. Describe any pages that will differ from the standard template.

Requirements for a content management system

My blog is intended for people who make websites using WordPress. Therefore, I will not attach serious importance to this point. We state that we are going to use this engine and that will be enough.

If you are going to make a control system yourself, then everything is much more complicated. You will have to draw diagrams again and describe general requirements, management of sections, content and settings. Draw each element that will be different.

Requirements for sharing access

Here, in essence, they want to find out from us when and why the user will need registration. Which sections we are closing, and which of them readers can safely use. If this is a business card site, informational or selling, it will be completely open, and on VKontakte, for example, access to personal page has limited access and can only be performed after entering your login and password.

Requirements for types of collateral

Requirements for information support

This part is created simply to show your own awareness and once again show the client what a professional you are, what sophisticated terms you know.

You will tell them that you are going to store the data in a specific place on the server, and not in your desk or under your pillow. Use programming languages.

You undertake to post images only in gif format or jpg, and the pages will not exceed a certain weight. By the way, great point. Then, if the customer bulges his eyes and says that he needs something else, you can show this item and say: “Well, you yourself signed about the weight, I don’t know anything, all this is impossible!”

Another really useful thing that you can also mention here is limiting the content provided. You need to define the scope - are you doing all the content or creating account administrator, give the customer the login and password and let them figure it out!

Software requirements

1. Here we are talking about hosting or servers. Since my blog is aimed at creators who work on Timeweb ( https://timeweb.ru ) - everything is very simple. If you are not one of “ours,” then you need to look at specifications. For example, someone very smart makes a cool website, and then tries to connect it to hosting, but the technical specifications are so high that no hosting in Russia can handle it. The item is necessary, but not for beginners in the field of development.
2. Here we describe whether the portal will have mobile version, adapted for portable devices or can only be opened through Google Chrome, and any distortions in other browsers do not bother us at all.

Requirements for linguistic support

Will the site be made in two languages ​​or will we only need Russian?

Requirements for ergonomics and technical aesthetics

Once again we briefly mention the main principles of design. Everything will be clear, straightforward, and uniform. The logo will be visible everywhere and Contact Information. Everything is super, everything is wonderful.

Requirements for project acceptance and delivery

Requirements for filling information

At this point we tell you what we undertake to do, as well as what the customer must provide us with so that the work goes faster and better. He usually requires information and photographs.

We also write again that if he wants to correct or change something, he will have to draw up a similar agreement again, which you will either sign or not.

Personnel requirements

Who can use the site. For example, some companies work with codes and don’t even bother with a control system for normal people. For basic actions on the site, significant knowledge will be required from the staff. In this case, the point is relevant, but in our case it’s just scribbled paper.

Distribution provision procedure

What will you give to the customer when the work is completed: login, password, back and forth.

We fill in the price of the technical specification

As you already understand, the main task of technical specifications is not so much to understand, although this is important. And yet, its additional function is to create the right impression of oneself and protect against all sorts of alterations.

Everything about this document should be impressive! If you are going to send it for preliminary review by mail, then be sure to use PDF format. And the client probably won’t want to torture himself with edits and he will think of you as a professional. A small thing, but a significant one. To convert a Word document, you can use the service https://smallpdf.com/ru/ .

Don't forget to insert your logo in the background own company or your brand, and insert contacts. They can be issued quickly and efficiently on the website https://logaster.ru .

Well, that's all, all you have to do is download the example that I created especially for you. It will help you understand and take as a basis some template points that will not be different and you’re done.

Now you can safely go to the customer and not be afraid that you will be accused of being incomplete.

DOWNLOAD TK TEMPLATE

Good luck in your endeavors and see you again. Subscribe to my blog and get the best useful information, which will definitely come in handy when working on developing a good website for your clients.

The terms of reference are important for both the contractor and the client. It helps the contractor to better understand what the customer wants, to insure against sudden “wants” on the part of the client, and to speed up the work on completing the task. To the client - to tell exactly what he wants, to simplify quality control, to receive exact cost services. We will talk about how to correctly draw up technical specifications and what to do with it later.

What is a technical specification

Technical specifications are a document that reflects all the requirements for the future product. It describes all technical requirements. Typically, technical specifications are compiled in the form text document, rarely - in other formats.

TK is used by all website developers. It helps layout designers, programmers, and designers to better understand the client’s requirements and create a resource that meets their expectations. In addition, technical specifications are used in all other areas, for example in:

• application development;
• house design;
• writing texts and others.

If you work according to technical specifications, the risk of disputes and protracted litigation is minimized.

How to draw up technical specifications: structure of technical specifications for a website

Before you start:

• Decide who will draw up the technical specifications
• Explain the terms
• Avoid subjective terms

At first glance, it seems that the technical requirements for the site should be drawn up by the client, because he orders a resource and puts forward requirements for it. In fact, both should participate in the process: the client voices the requirements, and the performer writes them down specifically, accurately and clearly. For example, a client says that he wants a website adapted for all users, and the developer specifies requirements for adaptability for 4 available sizes - PCs, laptops, tablets, smartphones.

Clarification of terms is a very important point. It is advisable to explain all highly specialized terms at the very beginning - clients do not always know what a footer, CMS, or fish is. The simpler and clearer the explanations are, the clearer the technical specifications will be for both parties.

Subjective terms can cause unnecessary controversy. Don’t write “design should be beautiful” - everyone’s concept of beauty is different. The same applies to qualitative adjectives “convenient”, “easy to use”, “large”. Use specific numbers and parameters: for example, describe the color scheme or arrangement of elements.

The structure of the technical specifications can be any. As an example, we offer a simple structure of terms of reference for a website.

Describe the site

Tell us what type of site is needed, who will use it, and why it is being created. For example, write that you need an online store, a landing page for selling a product, or a business card website with 10 pages. Please indicate the approximate number of pages if you do not know the exact number.

If the project has a specific the target audience, describe it. This will help you create a resource that will appeal to customers - for example, using appropriate language in articles or a design that appeals to young people or older generations.

Tell us about the structure

Without an idea of ​​the structure, it is impossible to develop a normal website. Describe what pages will be on the site and show the levels of their nesting. This can be done in different ways:

• Scheme
• Table
• List

The main thing is that in the end it is clear which pages will be located in the menu, where they will lead, and which parent page is for each section. We recommend using flowcharts - they are simpler and easier to understand than lists and tables, and help you evaluate the entire structure of the site in a few seconds.

An example of a simple structure in the form of a block diagram

Describe what will be on each page

Tell us how you see the site's pages. It is advisable to do this in prototype format to clearly demonstrate the location of each element. You can describe the requirements with a list, for example, tell what will be in the header of the site, where the feedback form is located, what will be in the free side column.

If all the pages of the site are approximately similar - for example, you are planning to create a business card website, you can get by with two prototypes: for home page and other sections. If there are several groups of similar pages - for example, sections in an online store catalog, a blog with articles and a description of delivery/assembly/installation services, it is better to make your own prototype for each group.

An example of a website home page prototype: everything is simple, convenient, understandable

Set design requirements

If you have a developed layout, great - you can simply insert it into the technical specifications. If not, you need to describe the requirements for the color scheme, images used, and logos. For example:

• Indicate which corporate colors can be used in design and which shades absolutely cannot
• Provide a logo, which must be present in the site header
• Specify the fonts that you would like to use for pages, menus, footers, and content

If there are no clear requirements - that is, the client himself cannot formulate his vision of the site, you can offer him several standard layouts to choose from or develop a layout individually, and then agree on it. This must be done before the technical specifications are approved, otherwise the difference in tastes can significantly delay the project.

Describe the requirements for tools, code, hosting, domain

This is necessary to know in advance which tools you can work with and which you cannot. Describe in a separate block:

• Which site should the site be on - WordPress, Joomla, Modex, etc.
• What programming language can be used - PHP, JavaScript, HTML, others
• On what hosting and in what domain zone should the site be located? Domain name can be used
• Which software platform can be used - .NET, OpenGL, DirectX
• And so on

If the client does not understand anything about the terms used, explain the difference between WordPress and Modex, PHP from HTML, a domain in zone.ru from a domain in zone.com. Together, draw up the requirements so that they suit the client.

Specify the site operation requirements

By default, the site should work for users of all devices, including different browsers, withstand hacker attacks and not go down when 1000 users visit simultaneously. But it’s better to write this as a separate block. Please indicate:

• Website loading speed that is acceptable to you or the standard value is 1–5 seconds
• Cross-browser compatibility - specify in which browsers the site should open
• Responsiveness - specify the screen sizes that the design should adapt to and the devices used
• Resistance to loads - how many people should be on the site at the same time so that it does not “go down”
• Resistance to hacker and dDos attacks: the site must withstand small attacks

Write down the site operation scenarios

Describe how the user should interact with the site, and what actions on the resource should occur in response. This can be done in the form of a simple numbered list or a branched algorithm if users have a choice between actions. If there are many interactive services, write a scenario for each of them.

An example of the simplest scenario for a website

Find out who is producing the content.

Some developers write texts themselves, some order them from copywriters, others use fish. Please immediately clarify whether the provision of content is included in the development service. If yes, you can immediately specify additional requirements, for example, for:

• - no less than 95% according to Advego, Text.ru, Content.Watch
• Nausea (spamming) - no more than 10% according to Advego or 65% according to Text.ru
• Points according to Glavred - at least 6.5 or 7 points

Of course, different services are not a panacea, but they minimize the risk that it will be “watery” or over-spammed. In addition, this is how precise criteria for assessing the quality of texts appear.

Specify deadlines

This is often forgotten. Most technical assignments must specify deadlines, otherwise development may drag on for several months, six months, or years. Do not use incorrect wording - for example, “in a month.” Write the exact date: December 1, 2018, for example.

Lifehack: it is better to draw up the terms of reference as an annex to the cooperation agreement. This way you establish all the requirements for website development, and in case of disputes you will be able to win the case in court.

Remember: each technical specification must contain several main blocks:

• Goals and objectives - about why you created the technical specifications in general, what you want to do with the product
• What should the product be like - description in general terms
• Technical requirements- area of ​​the house, volume of text, application functionality, etc.
• Deadlines - they are important to avoid disputes.

An example of drawing up technical specifications for software

We need to create software. Technical requirements are below.

Description: a program for searching articles by keyword on all authoritative sites; the addresses of authoritative sites must be entered manually.

What the software should do:after entering keyword finds articles on sites that have been entered in advance as authoritative sources, displays a list of matches in this format:

• Link
• Article title
• Lead paragraph

If there are more than 10 matches, you need to divide it into pages - 10 on each.

Technical requirements:programming language - any, it doesn’t matter. The main thing is that the program can then be modified and released as an online service. Ideally, the service should search in 10 seconds.

Deadlines: until September 15, 2018.

Naturally, this technical specification can be improved - we provided it as an example. How do you think the terms of reference can be improved to make it even clearer, simpler, and more convenient?

What is a technical specification? How to do it and what is it for? Examples, samples, tips and recommendations.

It would seem how great it is when someone understands you perfectly. You gave out a few phrases and here it is, exactly what you imagined. Unfortunately, it doesn't work that way.

The problem of information perception is eternal. The “broken phone” effect is a common occurrence. But what about if you simply don’t know how to set a task? Yes, this also happens and you need to work with it somehow, but how? To ensure that the results of the tasks you set meet your expectations, write a technical specification.

What is a technical specification

Technical specification (or TOR) is a document that contains the customer’s requirements for the products or services provided by the contractor. In simple words: I want this way and that, so that there are seven mutually perpendicular lines, and also some in red, and some in colorless (I recommend watching a video about this topic at the end of the material).

Design department

This document can take up either one A4 page or a whole volume, it all depends on the tasks and wishes that are included in it. For example, you can write a technical specification for a small landing page(one-page site) or complex software with machine learning and other features.

Why do you need technical specifications?

• To assign tasks to performers.
• To describe in detail what you want to get at the end.
• To agree on the order of work.
• To evaluate and accept the work after implementation.
• To...(add your options in the comments).

In fact, there are much more purposes and advantages of the technical specification than in the list above. For me personally, the main task that technical specifications solve is the implementation of what I need with minimal deviations from expectations (my expectations).

Thanks to technical specifications, you can always ask about implementation time, money and compliance with the declared characteristics of the final product or service.

In fact, this is a serious document that is drawn up by the customer and the contractor. To the extent that penalties and obligations of the parties are prescribed. There are a number of GOSTs, read more on Habré.

Development of technical specifications

If we are talking about a “grown-up” game, for example, technical specifications for development mobile application or website, then this separate work, for which a lot of money is paid. You attract a person, usually a former or current Chief Technical Officer, and ask him to help you.

Having a beard is optional

Depending on the scope of the project/tasks, this person collects all your “wants”, translates them into technical language, maybe prepares sketches (what it should approximately look like) and gives you the finished document. Next, you hand over this document to the performers (a team within your company or outsourced), agree on money, deadlines, and get to work.

Tip: The CTO should be on your team, otherwise you will most likely miss something during the implementation process. You simply don’t have enough knowledge for everything. Whoever participated in writing the technical specifications checks it.

What does the technical specification consist of?

Everything will depend on the template you choose (a little further I will give some links to templates/examples), but there are basic blocks that are included in the technical specifications:

1. Description of the project/task. We briefly write what the project or task is that needs to be completed.
2. Purpose and goals. What are the goals for the project?
3. Requirements. Design, functions, technologies that are needed.
4. Description of work. What, when and how will be done.
5. Control and acceptance procedure. How the work will be accepted, what can be considered completed.
6. Applications. Sketches, sketches, prototypes.

The cost of the work is usually included in a separate appendix to the contract, but it happens when the parties specify the amounts in the technical specifications themselves.

Sorry to interrupt reading. Join my telegram channel. Fresh announcements of articles, development of digital products and growth hack, it’s all there. Waiting for you! Let's continue...

Examples of technical specifications

Despite the fact that the development of technical specifications is a complex process, it is very interesting. Your task is to recreate the picture of the final result, and then describe it in parts.

An example of one of my technical specifications for an update Smart apps TV. Tasks for more complex and complex products were compiled with the help of colleagues from the technical department. Do not hesitate to ask your teammates for help, involve them in the process as often as possible. And don't forget to give feedback! There is nothing worse than putting effort and time into something without knowing the results. Tell us how the person’s advice was useful in your work, otherwise, it’s a one-sided game.

Terms of reference for the development of an online store

Terms of reference for the development of a mobile application

Terms of reference for the site

Terms of reference for services/updates

If you need more samples, just Google it.

The main recommendation is to do this. The trouble is that mother laziness overcomes everyone and it is not easy to resist it. Gather all your willpower and start writing technical specifications, just write and don’t stop. Don’t worry that it doesn’t work out “perfectly”, I’ll tell you a secret, this never happens. Just write, it will get better and better every time.

This is how it should be

My first rudiments for writing technical specifications began to appear several years ago. I worked with designers and set the task of creating creatives for advertising campaigns. I wanted it incoherently and it turned into a lot of wasted time and explanations. Over time, the setting of tasks began to turn into some kind of semantic blocks, and then into something like a technical specification.

For example, for the task “Like button on the site”:

1. Description: you need to create a “Like” button on our website.
2. Purpose and goals: user involvement, issuance/rating of materials based on the number of likes.
3. Requirements: the following design (example: a link to something similar), functionality (any user can rate the picture and like it, the site system takes into account the number of likes and changes the output of materials), technology (available on desktop and mobile versions of the site).
4. Description of work: draw 3 options for button layouts (ready date: 10/01/17), develop a system for distributing materials based on likes (date: 10/14/17), function testing (date: 10/16/17), release (date: 10/17/17)
5. Acceptance of work: the user presses the like button, the system counts the click, the delivery of materials changes.
6. Applications: sketches, sketches, examples of projects where a similar function works.

Leave for yourself those sections and parts of the structure that are needed for your tasks. For example, the sixth block “Applications” can be described in functional requirements. Basic advice: one way or another, describe the task according to the structure of the technical specifications. This way you won't miss out important points and save yourself from unnecessary questions, and make life easier for your colleagues.

Here you go

We looked at what a technical task is and how to do it. Now you have the ability to clearly and clearly set tasks, convey your thoughts to other people and save time on additional explanations. I hope now you know what to do with all this.

Terms of reference “TOR” is a document that is taken as the basis for the development of any project. And no matter how complex or large the task, it should always be accompanied by a clear and understandable technical specification. First of all, the customer needs this in order to get exactly what he wanted to see. But it is advisable for the performer to always demand a clearly stated task in order to understand what they want from him. Many people ignore the fact of writing detailed technical specifications, which subsequently leads to misunderstandings, disputes, conflicts and quarrels.

We recommend reading:

I, the author of this article, in my life have managed to be both the customer of several large projects worth tens of thousands of dollars, and the executor of no less expensive orders. Before reaching a serious level, I had to re-read hundreds of “Technical Specifications” and compose several dozen of my own explanations for the performer. Each time the technical specifications became clearer and clearer, which made it possible to obtain the final version of the work as I had imagined. In this article I would like to talk about how to write a technical specification, what to pay attention to first. I will also tell you why it is advisable for the customer and the contractor not to work on a good word, but to document everything.

Why does the customer need technical specifications?

You, as a customer, have an idea of ​​the final version of your order. Only life is such a thing that each person can interpret the same words differently. Because of this, problems often arise, especially among customers and performers. The first one didn’t explain everything, the second one didn’t understand it correctly, and the result is completely different from what everyone thought. A technical specification is a document according to which you will accept the work performed. And if something is done wrong, something is not finalized, something is not completed in full, then you can always point to an item from the technical specifications and substantiate your claim to finalize the submitted project. If there is no technical specification, then it will be practically impossible to prove that you said, wrote, mentioned it. We can say that the technical specification is a kind of prototype of a service agreement. If you are working on a large project, then the terms of reference should be an addition to the main contract. When signing the acceptance certificate for the completed work, you must compare everything with the amount of work that was indicated in the original statement of work.

We recommend reading:

Why does the performer need technical specifications?

First of all, this is your guide to what needs to be done. Often customers come up with something during the development process, trying to force you to perform unnecessary tasks. Do you want to work for free? I'm sure not. Please clarify that the amount agreed upon at the very beginning concerned exclusively the scope of work specified in the terms of reference. Anything more is paid separately. Also, upon delivery of the project, you will be able to report on the assigned tasks and their implementation. I have more than once encountered moments when the customer did not want to accept the work, arguing that it was not completed completely. But when the initial technical specifications were raised, it turned out that no one had set the tasks in question at all. Once again I emphasize - do not work without technical specifications, because the customer’s opinion can change more often than the weather, and you will have to redo everything dozens of times, wasting your time, and not receiving additional payment for it.

Where to start drawing up a competent technical specification

So let's move on to main topic this article. Next, we will talk about how to draw up technical specifications and what points you should definitely pay attention to. As you understand, each TK is unique, and I will not be able to cover all aspects. Therefore, I will only point out the main points that should be in any task, regardless of the project and the customer’s field of activity.

• General provisions of the technical specifications

If you have a technically complex project, or a very specific one, then be sure to general provisions There should be a glossary - a dictionary of terms and definitions. Of course, it is very good if the customer and the contractor understand each other and understand specific terminology without any problems. But this is not always the case, therefore, it is better to write down what certain words, phrases, designations mean. It might be worth explaining some of your phrases in the glossary. Let's say you use a certain phrase, interpreting it a little differently. To avoid confusion, immediately put everything in its place.

We recommend reading:

I had a case where a lack of understanding of the terms led to a missed deadline for more than a month. As a result, the customer suffered certain losses, but the problem was solely on his side. Therefore, do not allow disagreements. Decide on terminology before starting the project.

• Project goals

It is imperative that the terms of reference indicate what the goals of your project are, why it is being created, how it will work, and what the final result should be. Even if the performer is working on a small part of the project, he must fully understand its structure, tasks, goals, technical solutions. For what? It is not always possible for the contractor to receive advice and clarification from the customer, and there is no point in asking for interpretation of some little things if you can turn to the goals, understand what the project is for, and do your job based on this.

Let me give you an example. Recently developed big internet project, and ordered the design. The designer was told what the site would be about, what functions it would have, what it should do, and how the site would help people. In general, they chewed everything down to the smallest detail, and not just what concerns design. As a result, we received a layout that required virtually no modifications, as well as a dozen ideas on how to improve the site, what to add, how to make it more attractive.

• Functional requirements

All customer requirements can be divided into two types: functional and special. Functional requirements are those implementation options that you want to see in yourself. If we take the example of an Internet site, then you must provide the contractor with examples of functional solutions from other projects that you like and that you want to see in yours. For example, they saw an element they liked technically, described it, and immediately gave a link so that a person could clearly understand what it was about and could take it as a basis.

We recommend reading:

Special requirements are requirements with the help of which the assigned tasks must be fulfilled. If we again take website development as a basis, you can specify the programming language, special parameters layout, coding, use of certain styles and everything you want to see. If there are no such requirements, then let the contractor decide independently what and how he will use when performing your technical specifications.

• Deadlines

The deadlines for completion must be specified in the terms of reference. Always take with a small margin so that the speed of execution does not affect the quality. Not in any case there must be a clear deadline, and sanctions for failure to meet these deadlines are described. The contractor must understand that this is not just a point in the terms of reference, but a real installation, and if not completed, he risks incurring financial or other sanctions.

• Reporting

If the project is large and requires several months to complete, then break the work into stages and set clear time frames for each. After completing a particular stage, require reporting on the work completed. This will keep the performer in good shape, so that he doesn’t walk around for several months, eating and drinking the advance payment, and then in a week he does everything at breakneck speed.

There must also be a report on the actual work performed. What was done, how much time was spent on it, what difficulties the performer encountered, etc.

• Responsibility

If you draw up a contract, then a clause regarding liability will be in it. If you are only limited to the technical specifications, then it is worth describing there that the contractor is responsible for missing deadlines, not delivering the project, disclosing the nuances of the work to third parties, which entails losses for you. Which one? Firstly, in accordance with the law, but you can also set your own fines and sanctions.

We recommend reading:

And at the end of this article, I would like to give some advice based on my own experience in drawing up and receiving technical assignments.

1. The technical specifications must be detailed. Don't be afraid to describe every element, every item, every button. Write everything, everything, in as much detail as possible. Don't be afraid to appear meticulous. It’s better to repeat something several times and chew it over than to finish it later, pay extra, and modify it. The last technical task I wrote concerned the development of a website. It was a big information project. First we developed a design, and then, based on it, I described a functional task for programmers. So, all the specifications turned out to be 54 pages A4 11 font. The terms of reference came as an addition to the main contract, which was also 7 pages long. But I want to say that even in such a detailed technical specification I could not take everything into account, because during the development process three more additional agreements were signed, with which I made certain adjustments to the original version of the assignment.
2. The technical specifications must be clear. No water needed. Everything is to the point. If you write about the deadline, then a specific figure, if about functionality, then a list of functional solutions you need, etc.
3. Your technical specification is not a dogma, but only one of possible options execution of tasks. To be honest, I'm not a programming expert. Yes, I can think through the structure of the project, its functionality, some technical solutions, but always, when drawing up the final version of the technical specifications, I consult with the performers. They can see something, express their opinion, give advice optimal solution execution.

That's probably all I wanted to say in this article. Drawing up technical specifications is not so difficult if you clearly understand what you want from the contractor. You can re-read my advice again and apply it to your specific case. Good luck!