Terms of reference for the development of the site - how to write?

Terms of reference for the development of the site - how to write?

 

The functionality of a modern Internet resource is optimized for the tasks of the client, and the design and content are optimized for the characteristics of the target audience. All these integral parts of the development process are regulated by a single document - terms of reference or TOR.

Why do we need a technical task?

TOR is a mandatory appendix to any contract for the development of a software product. This is a document that formalizes the requirements and wishes of the client, provides clear criteria for the commissioning of work, and also protects the rights of the parties.

The customer is guaranteed the fulfillment of all the requirements specified in the TOR for the indicated cost, the contractor is guaranteed the absence of fundamental changes at later stages. All this helps to avoid disputes, conflicts and misunderstandings.

Assigning a task to an executor

Writing a technical task for the development of a software product helps to understand what should be the result of the work .  This is especially important for the contractor, who, having studied the document, will be able to provide the customer with the exact cost of the work, predict the timing of their completion.

TOR is usually compiled by the customer himself for the contractor. However, sometimes both parties work on this document if the formalization of the requirements causes any difficulties.

What does the TK consist of?

The terms of reference consists of several blocks. Despite the fact that the TK is part of the contract and has legal force, their order and names may differ slightly:

1. Glossary. This section provides an explanation of all concepts and terms that will be used throughout the document.
2. General information. This is one of the most important sections. Here it is necessary to indicate the address of the future site, its name, determine the procedure for agreeing on various issues. It is equally important to formalize in this section a phased schedule for the implementation of work, to indicate the procedure for coordinating the results. However, this information becomes known after the completion of the TOR, so it can be placed in a separate block, which is placed at the end of the document.
3. Goals and objectives. This section indicates ways to further use the resource, describes its target audience.
4. Software. It is necessary to indicate which browsers the new site should be compatible with, as well as which technologies will be used to implement it.
5. Design requirements. This is a fairly free block in which the customer formulates his requirements for the appearance of the future site. You can specify the style, typefaces used, define the color scheme, and more. It is also worth indicating here the need to use animated elements, banners, etc.
6. Structure requirements. This block is usually the largest. All the necessary pages of the site, their structure, links between them are indicated here. It also briefly describes the purpose and content of each section.
7. CMS. The content management system of the site allows you to simplify its further filling and use. The use of such a software product also makes it possible to reduce the cost and development time.
8. Content requirements. This section describes in detail the terms of reference for creating turnkey websites, where the developer must prepare all the necessary content. In this case, you should determine the number, volume and format of articles, news, various media materials and more.
9. The order in which the work result is passed. It is necessary to agree in what form the customer will receive the site. It can be placed on the network, hosted, or, for example, transferred on some medium for further work.

This list is by no means exhaustive. However, he describes all the main blocks, without which the TOR cannot be considered complete. In the following, we will take a closer look at the most important sections of this document and provide guidance on how to draft them.

How to compose and sample

Before considering the foundational issues, here are two important recommendations to help make the ToR more comprehensive and understandable.

First, use objective or measurable criteria. For example, if you want the headings on your site to be green, it's better to specify the exact RGB or HEX code. The same applies to CMS: it is better to spend some time looking for a suitable system (for this, for example, you can consult with the contractor) than to use vague terms like “convenient”, “easy to learn”, etc.

Second - describe all the elements of the site in as much detail as possible. This will help to avoid double interpretations, additional time for agreeing on technical specifications, clarifying requirements, etc. In this case, an excessive description is better than an insufficient one.

TK as the basis of the basics.

Work on the TOR begins with determining the tasks for which the site will be used. It could be:

• acquiring new customers;
• strengthening customer and partner loyalty;
• portfolio or assortment presentation;
• formation of a certain image of the company, etc.

When the tasks are defined, you should think about who will use the site, what is its target audience. The more detailed portrait of a potential visitor can be compiled, the more suitable solutions will be used to meet the requirements of the TOR.

Description of site sections

It is important to describe in detail the contents of all static and unique sections. It is necessary to consistently, moderately describe in detail all the elements that should be presented on them.

In addition to the textual description, it would be useful to attach schematic page layouts here. To create it, you can use special software for prototyping. The layout is highly desirable for the home page, as it is the main entry point for visitors to the site. It is not necessary to make layouts for all internal sections, as they usually have a similar structure. It is enough to attach separate prototypes for unique pages, as well as one common one for standard ones.

Description of the functional part

Each element or block of the site, the functionality of which differs from the standard display of content, must be described in detail. For example, if it is planned to place a button for ordering a callback in the site header, then its description could look like this: “By clicking on the“ Order a call ”button, a pop-up window opens with the fields: Name, Phone, and also with the button “Call me back”. Naturally, if you need validation of the entered data, you should specify what exactly and how should be checked.

It will be useful to work out and formalize in this section the standard scenarios for using the resource. This will help you find ideas for a more optimal arrangement of blocks and more.

All blocks and elements, the logic of which is not described in the TOR, are usually implemented by standard CMS tools, which does not always fully meet the requirements of the client.

Approval of the finished TOR

Development of TOR can only be completed when this document is approved, signed by both parties and attached to contract.

Programmers, designers and other specialists who will participate in its implementation should familiarize themselves with the TOR with the contractor. They have the right to demand adjustments if any aspects of their part are described incorrectly or too vaguely.

On the part of the customer, in agreeing on the TOR, the person who has the right to sign must accept. Inside the company, a document can go through any number of readings by different employees. However, it will be much more convenient and faster if the person who will sign the document will submit the edits and comments to the performer. This will reduce the reconciliation time and avoid confusion.