In life, it often happens that a person cannot explain what he wants, even in everyday things. When it comes to explaining your “wants” to a programmer, a person simply falls into a stupor.

Ideally, the TK should be drawn up by the customer - only he knows what he needs. But in practice, due to the low competence of the customer in the field of 1C, this often has to be done by the contractor. The customer verbally voices his needs, and the programmer (consultant) formalizes this in writing.

Why is a specification needed?

Any, ideally, should be accompanied by a technical task. This is, firstly, a clear definition of the task, deadlines and method of implementation. Secondly, it is a document with the help of which all disputes in the future are resolved. It is, of course, up to you whether to write a technical specification or not; for me personally, a technical specification makes it easier to work and communicate with a client.

Get 267 1C video lessons for free:

What should the terms of reference contain?

Those. The assignment must include:

• goal- the task that we will solve by implementing this TOR;
• description- a summary of upcoming improvements;
• implementation method — detailed description goal solving methods. At this point, it is necessary to describe all the nuances of the task in the programming language: what, we create / edit, how the interface should look, etc. If you don't know the "programming language", but "heard something", it's better not to try to write in a technical language - it turns out to be quite fun. The description should be unambiguous and not cause questions. It may also contain an example of the implementation of a similar solution in another area;
• performance appraisal- a very important point, a description of labor costs.

There are also state standards to writing TK - GOSTs. In practice, they are rarely used anywhere, but it happens that the customer insists on this.

From experience, when handing over work, situations like “we told you then…” very often arise, which is not very pleasant, and often you have to redo the work entirely. Therefore, a well-written TOR greatly facilitates the lives of both parties.

Examples and samples of TK for 1C

A small selection that I found freely available on the net. Starting from the simplest and most accessible, ending with fairly complex documents.

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, to speed up the work on the task. To the client - to tell exactly what he wants, to simplify quality control, to get the exact cost of the service. We will tell you how to properly draw up a TOR and what to do with it later.

What is a technical task

Terms of Reference - a document that reflects all the requirements for a future product. It describes all the technical requirements. Usually, TK is compiled in the form of a text document, rarely in other formats.

TK is used by all website developers. For typesetters, programmers, designers, it helps to better understand the requirements of the client and make a resource that meets his expectations. In addition, TK is used in all other areas, for example - in:

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

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

How to draw up a technical task: the structure of the technical specifications for the site

Before starting work:

• Decide who will make technical task
• Explain terms
• Avoid subjective terms

At first glance, it seems that the technical specifications for the site should be made by the client, because he orders a resource and makes demands on 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, the client says that he wants a site adapted to all users, and the developer prescribes adaptability requirements for 4 available sizes - PCs, laptops, tablets, smartphones.

Definition of terms is very important. It is advisable to explain all highly specialized terms at the very beginning - clients do not always know what a basement (footer), CMS, fish is. The simpler and clearer the explanations are, the clearer the TOR will be for both parties.

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

The structure of the technical task can be any. As an example, we offer a simple structure of TOR for the site.

Describe the site

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

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

Tell me about the structure

Without an understanding of the structure, it is impossible to develop a normal site. Describe what pages will be on the site, and show their nesting levels. You can do this 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, which parent page each section has. We recommend using flowcharts - they are simpler and easier to read than lists and tables, they help to evaluate the entire structure of the site in a few seconds.

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

Describe what will be on each page

Tell us how you see the pages of the site. It is desirable to do this in a prototype format in order 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 form is located feedback, which will be in the free sidebar.

If all the pages of the site are approximately similar - for example, you plan to create a business card site, 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 the catalog of an online store, 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 prototype of the main page of the site: everything is simple, convenient, understandable

Make design demands

If there is a developed layout, great - you can simply insert it into the terms of reference. If not, you need to write down the requirements for color scheme used images, logos. For example:

• Specify which corporate colors can be used in design, and which shades are absolutely not
• Provide a logo, which must be present in the header of the site
• Specify the fonts that you would like to use for the design of pages, menus, footers, 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 approval of the TOR, otherwise the difference in tastes can significantly delay the project.

Describe the requirements for tools, code, hosting, domain

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

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

If the client does not understand anything in the terms used, explain how WordPress differs from Modex, PHP from HTML, a domain in the .ru zone from a domain in the .com zone. Together, make the requirements so that they suit the client.

Specify site requirements

By default, the site should work for users of all devices, in different browsers, withstand hacker attacks and stay up when 1000 users visit at the same time. But it's better to write it in a separate block. Specify:

• Acceptable site loading speed for you or a standard value - 1–5 seconds
• Cross-browser compatibility - describe in which browsers the site should open
• Responsiveness - specify the screen sizes that the design should adapt to and the devices used
• Load resistance - how many people should be on the site at the same time so that it does not "lay down"
• Resilience to hacker and dDos attacks: the site must withstand small attacks

Write out scenarios for the site

Describe how the user should interact with the site, and what actions should occur on the resource 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 script for each of them.

An example of the simplest scenario of the site

Find out who is doing the content.

Some developers write texts themselves, someone orders them from copywriters, someone uses fish. Immediately clarify whether the provision of content is included in the development service. If so, you can immediately prescribe additional requirements, for example, to:

• - not 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 for 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 spammed. In addition, this is how accurate criteria for assessing the quality of texts appear.

Specify terms

This is often forgotten. Most of the terms of reference must specify the terms, otherwise the development may drag on for several months, half a year, years. Do not use incorrect wording - for example, "in a month." Write the exact date: December 1, 2018, for example.

Life hack: it is better to draw up the terms of reference as an annex to the cooperation agreement. So you fix all the requirements for the development of the site, and in case of disputes you can win the case in court.

Remember: in each TK there should be several main blocks:

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

An example of drawing up a technical specification for software

We need to create software. Technical requirements - below.

Description: a program for searching articles by keyword on all authoritative sites, you need to manually enter the addresses of authoritative sites.

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 into pages - 10 on each.

Technical requirements:programming language - any, it doesn't matter. The main thing is that the program can then be finalized and brought out as an online service. Ideally, the service should search for 10 seconds.

Timing: until 15.09.2018.

Naturally, this TOR can be improved - we provided it as an example. And how do you think, how can the terms of reference be improved so that it becomes even clearer, simpler, more convenient?

From the author: How to write terms of reference for website development? The topic is quite extensive, and within the framework of one article it is difficult to disassemble it 100% (if at all possible). But general provisions, what you need to take into account, what you should pay attention to when drawing up the TOR, I will try to describe in sufficient detail in this article.

So, TK

The terms of reference are drawn up for the site developer. The TK must be referred to when drawing up an agreement between the customer and the contractor. Responsibility for non-fulfillment or incorrect fulfillment of the points and terms of the TOR on both sides should be stipulated. But the most important thing (in my opinion), for which a TK is created, is for speeding up the site development process.

Let's analyze this example:

Suppose you need a calendar somewhere on the side of your site. It seemed like a trifle. But the more you describe the functionality of this calendar, the faster you will get the result.

I'll explain a little here. The calendar is different. There is a calendar that simply shows the numbers for the days of the week of the current month. There is a calendar with the ability to scroll through the months. There is a calendar with the ability to flip through the months and years.

Suppose you need last option calendar (with the ability to scroll through months and years) with highlighting the current date. You indicated in the TOR: "a calendar is needed in the sidebar." The customer makes the first version of the calendar for you (simply shows the numbers by the days of the week of the current month).

What we have. The contractor completed the TK item, but you wanted a completely different calendar. It seems that everything is in accordance with the TOR, no one is to blame, it didn’t come to a conflict, but the most important thing is lost time and money.

This is an example of just a banal calendar.

And if you have to redo something more serious, the processing of which takes more than half a day, as is the case with the calendar? And you don’t have a website, and the customer is messing with you, although he could complete your project and start a new one.

Therefore, than more If you describe the functionality of each site module, the faster you will get the result. Both parties should be interested in this.

What items does a TOR usually consist of?

Let's imagine that you are the owner of some company or firm. Your company is engaged in the production of any product, and its implementation. You have buyers. You cooperate with sellers (shops and online stores), service centers, product consumers. Or you are making a website for such a company and you need to write a technical specification.

Regardless of what role you are in, the first thing to do is to study the structure of the organization, what it does, the nomenclature, characteristics, and in general everything related to the product and the company. From how deeply the customer will delve into the essence of what is happening at the enterprise, depends on what will happen on the site. Therefore, the task here is mutual: the customer should tell about the enterprise in as much detail as possible, and the performer should thoroughly understand the essence of what is happening.

Even if you yourself write technical specifications for the company that will make the site, it's not bad to estimate all this on a piece of paper.

Let's go to the points.

Description of the site

Here you can write in a couple of sentences about the company, what it does. Do something like an introduction.

for whom - the target audience of the site:

• potential buyers
• sellers of products (shops, online stores)
• service centres
• partners (firms)
• product consumers (those who have already bought)

Why do you need a website:

• To enhance the company's image
• To increase sales
• For customer convenience

Site type:

• Corporate
• Website - business card
• Internet shop

Language versions:

• English
• Russian

The site must solve some problems. Accordingly, we move further along the goals and objectives of the site.

Goals and objectives of the site

In this section of the TOR, we go through the entire target audience and describe the range of tasks that the site should solve for them.

Potential buyers of products.

Target: to attract more buyers and convince them to make the first purchase, help to make a choice.

Problems need to be solved:

Give high-quality, comprehensive information about products, additional services, guarantees, service, selection methods.

• Submit information about stores
• Provide retail information trading network

Provide an opportunity to ask a question through the organization of online-consulting of potential buyers by specialists of the enterprise on the selection, purchase of products.

Thus, we go through the entire target audience. If you follow our site, we describe the goals and objectives for product sellers (shops, online stores), service centers, partners (companies), product consumers. That is, what the site should do specifically for each of them.

Now we enumerate the modules of the site.

Site functionality

In order to list the functionality of the site, you need to decide what it needs:

• Do you need news on the site
• Do you need an ad block?
• Is registration required
• Do I need a private section of the site (only for registered users)
• Do you need a feedback form?
• Do I need a mailing script
• Etc. etc.

After all this has been described, we are getting to the most important and interesting. Of course, all the work done above is very important, but now it's getting even "hotter".

Description of site functionality

On the this moment we know who the site is for, what goals and tasks it should fulfill, its additional functionality.

The time has come when you need to bring all the collected information into the system and beautifully put it into the site. To make it easier and not reinvent the wheel, you can look at sites of similar subjects. Learn something from them, see and test their functionality and try to improve what seemed inconvenient on your site. In principle, you can look at sites of similar topics (and if you don’t have experience, then you even need to) at the very beginning of compiling the TOR.

I suggest starting with the menu items. It needs to display the main pages of the site and make sure that each of the visitors quickly finds information for themselves. And visitors are our target audience. The menu will include many items, so it will be in the form of a drop-down list.

First you need to tell about the company. There may be pages about the company, company history, contacts, reviews.

Naturally, there should be a menu item "products", with sub-items " Product Catalog”, “releases”, “product reviews”.

In general, I hope it is clear how to paint. I will present the final version of a possible menu for our site:

About company

• history of the company
• contacts
• reviews

News

• developments
• stock
• new on site

Products

• Product Catalog
• releases
• product reviews

Service

• service department
• warranty service
• post-warranty service

Consumer

• purchase and delivery
• use
• about the service

Shops and online stores

• product photos
• Frequently asked Questions

Service centers

• How to become service center
• Frequently asked Questions

Partners

• invitation to cooperation
• frequently asked Questions

We sort of figured out the menu. Now you need to describe what will be on each page and how it all works as a whole. Plus, provide an approximate layout of the site. It can be drawn on a piece of paper with a pencil, scanned and attached to the TK. The only thing I will say is that do not limit the designer's imagination, sketch it in the most general form.

This part changes depending on how you want your page to look. Maybe you don’t need so many banners at the top, maybe you need to specify contacts at the top (address, phone, fax), maybe in the form of icons “site map”, “home”, “contacts”. Maybe you don’t need news on the left, but show “promotions and releases” on the left.

The main thing now is to describe the logic of work.

Operation logic

I will describe based on the figure above.

The top of the site remains the same on every page of the site. The news feed is only visible on the main page. On the secondary pages on the left, we show the menu sub-items of the item in which we are currently located (for example, if we are on the "service" page, then we show links to "warranty service", "post-warranty service"). Accordingly, the transitions on these links lead to the corresponding pages. Here, under the sub-items on the left, we display data for contacting online consultants (Skype, ICQ). Block promotions and releases remain on each page. The footer of the site is displayed the same on every page.

Approximately so the general logic of work is described.

Now we describe each block in detail. For example "News feed".

"News feed" of 10 latest news. Each news item should consist of a news title, publication date, a brief start of the news (4-5 lines) and a "read full" link. By clicking on the link "read in full" we get to the news page. The news that was hit is displayed in place of the main content. It also includes the title of the news, the date of publication. The news feed is also displayed on the left. News from previous months and years is archived. That is, under the news for the current month, we display “an archive for (such and such a month or year)”. When you click on the link "archive for (such a month or year)" down, a list of news for the corresponding month / year drops out.

This is how we describe the operation of each block. Let's not forget about the case with the calendar. And most importantly, you need to paint the work of the product catalog. Here I give you a task: try to think and describe how the catalog will work. Send your options by e-mail. We will post the best one.

What else should be? It would be nice to indicate compatibility.

Compatibility

In this paragraph, we indicate which operating systems and in which browsers the site should look equally good. In what version, what language should be written. What CMS is being used. It's worth pointing out if you really understand what you're talking about.

If you do not own these questions, then simply indicate the browsers in which the site should be displayed correctly. For the rest, count on the conscience of the performer.

Conclusion

In this article, I did not seek to show that this is how the TK is compiled and nothing else. Do this and you won't have any problems. Compiling a high-quality TOR is more a matter of experience. In the first couple, not everyone will succeed in compiling a competent TK.

In this article, I wanted to show the principles by which the terms of reference are built, the main points that are worth paying attention to. To what extent I succeeded, I hope to learn from your comments.

And don't forget the challenge!

G O S U D A R S T V E N N Y S T A N D A R T S O YU Z A S S R

Unified system of program documentation	GOST 19.201-78 (ST SEV 1627-79)
TECHNICAL TASK. REQUIREMENTS FOR CONTENT AND DESIGN
United system for program documentation. Technical specification for development. Requirements to contents and form of presentation

Decree of the USSR State Committee for Standards dated December 18, 1978 No. 3351 established the deadline for introduction

from 01.01. 1980

This standard establishes the procedure for the construction and execution of technical specifications for the development of a program or software product for computers, complexes and systems, regardless of their purpose and scope.

The standard fully complies with ST SEV 1627-79.

1. GENERAL PROVISIONS

1.1. The terms of reference are drawn up in accordance with GOST 19.106-78 on sheets of format 11 and 12 in accordance with GOST 2.301-68, as a rule, without filling in the fields of the sheet. Numbers of sheets (pages) are put down in the upper part of the sheet above the text.

1.2. The approval sheet and the title page are drawn up in accordance with GOST 19.104-78.

The informational part (abstract and content), the change registration sheet may not be included in the document.

1.3. To make changes or additions to the terms of reference at the subsequent stages of developing a program or software product, an addendum to it is issued. Coordination and approval of the addition to the terms of reference is carried out in the same manner as established for the terms of reference.

1.4. The terms of reference should contain the following sections:

• introduction;
• grounds for development;
• purpose of development;
• requirements for the program or software product;
• requirements for software documentation;
• technical and economic indicators;
• stages and stages of development;
• procedure for control and acceptance;
• it is allowed to include applications in the terms of reference.

Depending on the features of the program or software product, it is allowed to clarify the content of the sections, introduce new sections or combine some of them.

2.1. In the "Introduction" section indicate the name, brief description the scope of the program or software product and the facility in which the program or software product is used.

(Changed edition, Rev. No. 1)

2.2. The Basis for Development section should include:

• document (documents) on the basis of which the development is carried out;
• the organization that approved this document and the date of its approval;
• name and (or) symbol of the development topic.

(Changed edition, Rev. No. 1)

2.3. The Purpose of Development section should indicate the functional and operational purpose of the program or software product.

2.4. The "Requirements for the program or software product" section should contain the following subsections:

• performance requirements;
• reliability requirements;
• terms of Use;
• requirements for the composition and parameters technical means;
• requirements for information and software compatibility;
• requirements for labeling and packaging;
• requirements for transportation and storage;
• special requirements.

(Changed edition, Rev. No. 1)

2.4.1. The subsection "Requirements for functional characteristics" should indicate the requirements for the composition of the functions performed, the organization of input and output data, temporal characteristics, etc.

2.4.2. The subsection "Requirements for reliability" should specify the requirements for ensuring reliable operation (ensuring stable operation, control of input and output information, recovery time after a failure, etc.).

2.4.3. The subsection "Operating conditions" should indicate the operating conditions (ambient air temperature, relative humidity, etc. for the selected types of data carriers), under which the specified characteristics should be provided, as well as the type of service, required amount and staff qualifications.

2.4.4. In the subsection "Requirements for the composition and parameters of technical means" indicate the required composition of technical means with an indication of their main technical characteristics.

2.4.5. In the subsection “Requirements for information and software compatibility”, the requirements for information structures input and output and solution methods, source codes, programming languages ​​and software tools used by the program.

Where necessary, information and programs should be protected.

(Changed edition, Rev. No. 1)

2.4.6. In the subsection “Labeling and packaging requirements”, in the general case, the requirements for software product labeling, packaging options and methods are indicated.

2.4.7. In the subsection "Requirements for transportation and storage", the conditions for transportation, storage places, storage conditions, storage conditions, storage periods in various conditions for the software product must be indicated.

2.5a. The section "Requirements for software documentation" should indicate the preliminary composition of the software documentation and, if necessary, special requirements for it.

(Introduced additionally, Rev. No. 1).

2.5. In the section "Technical and economic indicators" should be indicated: indicative economic efficiency, supposed annual demand, economic advantages of development in comparison with the best domestic and foreign samples or analogues.

2.6. In the "Stages and stages of development" section, the necessary stages of development, stages and content of work (a list of program documents that must be developed, agreed and approved), as well as, as a rule, the development timeframe and determine the executors are established.

2.7. In the section "Procedure for control and acceptance", the types of tests and General requirements to accept work.

2.8. In the annexes to the terms of reference, if necessary, provide:

• a list of research and other works substantiating the development;
• algorithm schemes, tables, descriptions, justifications, calculations and other documents that can be used in the development;
• other sources of development.

Reissue (November 1987) with Amendment No. 1 approved in July 1981 (IUS 7-81)

The question “Is it necessary to draw up a technical task (TOR) at all?” can only arise for those who have never ordered the development of a site in their lives, since the need for it arises after the first communication between the customer and the contractor.

ToR is a document that describes the future project in detail and completely. The more detailed it is, the more accurately the idea will be implemented and the less conflicts and disputes will arise during the implementation of the project, because absolutely any thing can be done in different ways. You can refer to it if something is not done or done wrong or other errors are made. Before starting work, the customer usually describes the future project in a thesis form or fills out a brief, and the contractor formalizes all these requirements and wishes, if necessary, proposes adjustments. At the same time, the customer needs to make sure that all his "Wishlist" is fixed in those tasks.

If a contract for the development of a site is concluded with a web studio or freelancer, then that task usually comes as an attachment to it. And in controversial situations, they are guided by what is written there.

What is TK made of?

Suppose, within the framework of the project, it is required to draw up a technical task for the development of the website of the Pero copywriting studio. What items should it contain?

General information (description)

Here are indicated:

Company information. general information about the studio, what it does. It will not be superfluous to provide a list of services provided. Here you can also add the address of the future site, contact information.

Stages and terms of project implementation. A very important point, as a rule, calendar plan for all stages of work are compiled at the very end. This part gives an understanding of what will be done and when. For example (with dates):

• Preparatory stage;
• Website concept development;
• Design;
• Creation of a design layout;
• Page design development;
• Layout;
• Programming;
• Filling content;
• SEO optimization;
• Testing;
• Launch.

There may not be any stages, for example, SEO promotion. Depends on the goals and objectives of the customer and the competencies of the contractor.

Purpose and goals

Here it is formulated what functions the site will perform and for whom it is intended.

Site Purpose. What are the goals of creating a site to achieve? What is it for, what tasks does it solve?

• Advertising and attracting new customers;
• Customer and partner support;
• Demonstration of the work performed;
• Familiarization with the list of services;
• Creation and maintenance of the company's image.

Perhaps some points should be described in more detail. For example, if the site is faced with the task of informing visitors, it is better to explain what exactly.

The target audience. Who will use the site, for whom is it created?

• Webmasters, bloggers;
• Online store owners;
• Owners of information portals;
• Advertising studios;
• Representatives of firms and companies present in the online space.

Requirements

A large and extremely important section, which takes into account as many aspects of design and development as possible, because the customer will have to pay extra for the functionality not specified in the TOR.

Type of. What category does the web resource belong to?

• Landing page;
• Business card site;
• Corporate website;
• Informational portal;
• Online store.

Design Requirements. They can be of the following form:

• The site should be minimalistic and at the same time reflect the type of activity of the company.
• Primary colors: green and white, according to the brand book or at the discretion of the designer.
• Animation, pop-up windows, Flash-elements, design excesses cannot be used in the design.
• Serif fonts cannot be used (standard fonts can be used: Verdana, Arial, Tahoma, etc.). The size should provide maximum readability (12-16 pt.).

When it comes to design requirements, different approaches can be applied. If the customer himself knows exactly what he wants to receive, then he describes in detail his wishes, gives examples of sites that he likes and gives other specifics. But sometimes it happens that he himself does not know exactly how it all should look, in this case they usually proceed from the tasks that the design should solve. The contractor develops concepts, proposes solutions, defends his idea and corrects it according to the customer's comments. The second option is more expensive and requires more qualifications from the contractor.

Language Requirements. Which native language will be able to visit the resource? What language versions of the site should be?

• Russian;
• English;
• Esperanto.

Compatibility Requirements. From which devices and which browsers will the site open correctly? Recently, there has been a trend towards adaptive layout, when the page is displayed correctly on any device with any aspect ratio and screen resolution. Here you can list the browsers with which the resource must be uniquely compatible. Usually on all modern browsers sites are displayed the same way, there are only problems with older versions of Internet explorer.

CMS Requirements. The site administration capabilities determine which blocks can be edited and configured through the control panel, without interfering with the code and without directly editing the database, but using a convenient visual interface. For example, you can put it like this:

• The ability to change the content on the pages of the site;
• Ability to manage pages (adding, renaming, deleting, etc.);
• Ability to edit the site structure and menu items;
• Functions for automatic graphics processing (creating previews, transforming to a given size, etc.);
• Ability to prescribe unique Meta tags;

As in other subsections, you need to describe all the requirements and wishes.

Often the customer already has experience with one of the popular CMS, then it is advisable to look for contractors for a specific engine. Also, when choosing a CMS, it is better not to settle for self-written solutions, because. In the future, this will make it dependent on the performer. Self-written engines, in my opinion, are justified only in very large projects where specific functionality or optimization of large loads is required.

Structure and navigation. What sections, subsections and individual pages will the project contain?

• Main page
• Services

• Copywriting
• Rewriting
• SEO copywriting
• proofreading
• transcription
• Content management
• Content Marketing

• Portfolio
• About Us
• Contacts

Do and short description each page, give definitions. For example, what is meant by the "Contact" page? It must contain an address, phone number and email in text format? Or should there be a feedback form? Or maybe you need to embed the Yandex Maps code? Or should the contact page contain all of the above, and even links to representations in social networks?

It is desirable to prepare the content, or at least its outline, before starting work with the contractor. This will facilitate more effective communication.

Additional requirements. Everything that is not included in the other paragraphs of the section.

Description of site sections

This paragraph contains the details. Usually, the content of all unique pages is signed: what elements will be there, how the user will interact with them.

Main page. The formulation of the problem can be in the following form.

The main part of the main page should be made in the form of Landing Page . It should contain the following elements from top to bottom:

• Hat - logo, company name;
• Navigation menu;
• Information about promotions and discounts;
• Order button;
• Advertising text;
• Block with five the best works and a link to the portfolio section;