In this article I tried to consider in detail the problem of developing Terms of Reference. The topic is as old as the problem. But it is still often decided "how it goes."
  As Henry Shaw said, "The little things worry us the most: it's easier to dodge an elephant than a fly."

Development terms of reference. What is it, why is it needed, where to start and what should it look like?

What is this article about?

I am often asked: “How to develop the terms of reference for automated system? " A similar topic is constantly discussed in various forums. This question is so broad that in a nutshell it is impossible to answer. Therefore, I decided to write a large article on this topic. In the process of working on the article, I realized that putting everything in one article would not work, because it will turn out under 50 pages and decided to break it into 2 parts:

• In the first part " Development of technical specifications. What is it, why is it needed, where to start and how should it look? ”I will try to answer questions of the topic in detail, consider the structure and purpose of the Terms of Reference, give some recommendations on the formulation of requirements.
• Second part " Development of technical specifications. How to formulate requirements? ”Will be fully devoted to identifying and formulating requirements for the information system.

First you need to figure out what the question really interests those who ask “How to develop a technical task?” The fact is that the approach to the development of a technical task will strongly depend on for what purposes this is done, as well as who will be used. . What options are I talking about:

• 
  The commercial organization decided to introduce an automated system. She does not have her own IT service and decided to do this: An interested person should develop a Terms of Reference and give it to a third-party organization;
• The commercial organization decided to introduce an automated system. She has her own IT service. We decided to do this: develop the Terms of Reference, then coordinate it between the IT service and interested parties, and implement it on our own;
• The state structure decided to start an IT project. Everything is so muddy here, a bunch of formalities, kickbacks, cuts, etc. I will not consider such an option in this article.
• An IT company is involved in the development and / or implementation of automated systems. This is the most difficult case, because you have to work in a variety of conditions:
  • The client has its own specialists with their own views, and they present specific requirements for the terms of reference;
  • The terms of reference are developed for their own developers (the client does not care);
  • The terms of reference are developed for transmission to the contractor (i.e. a group of programmers who are behind the company’s staff, or to an individual specialist);
  • A misunderstanding arises between the companies and the client in the question of the result obtained, and the company again and again asks the question: "How should the Terms of Reference be developed?" Perhaps the latter case seems like a paradox, but it is true.
  • Other less common options are also possible;

I think now the reader should have questions:

• And why it is impossible to develop the Terms of Reference is always the same?
• Are there any standards, methodologies, recommendations? Where to get them?
• Who should develop the Terms of Reference? Should this person have any special knowledge?
• How to understand whether the Terms of Reference is well prepared or not?
• At whose expense should it be developed, and is it even necessary?

This list can be endless. I say so confidently that it has been 15 years in professional software development, and the question of Terms of Reference pops up in any development team with whom you have to work. The reasons for this are different. Raising the topic of developing the Terms of Reference, I am well aware that I will not be able to put it 100% for all those interested in the topic. But I’ll try, as they say, "put everything on the shelves." Those who are already familiar with my articles know that I do not use the “copy-paste” of other people's work, I do not reprint other people's books, I do not quote multi-page standards and other documents that you yourself can find on the Internet, passing them off as your ingenious thoughts. Just type in the search engine "How to develop Terms of Reference" and you can read a lot of interesting, but, unfortunately, many times repeated. As a rule, those who like to get smart on the forums (try to search all the same!) Themselves have never done a sensible Technical Assignment, and they constantly quote GOST recommendations on this issue. And for those who are really serious about the issue, there is usually no time to sit on the forums. About GUESTS, by the way, we'll talk too. In different years of my work, I had to see many options for technical documentation compiled by both individual experts and eminent teams and consulting companies. Sometimes I also engage in such activities: I devote time to myself and search for information on a topic of interest from unusual sources (such a little intelligence). As a result, I had to see documentation on such monsters as Gazprom, Russian Railways and many other interesting companies. Of course, I follow the privacy policy, despite the fact that these documents come to me from publicly available sources or from the irresponsibility of consultants (they scatter information on the Internet). Therefore, I immediately say: I do not share confidential information that belongs to other companies, regardless of the sources of occurrence (professional ethics).

What is the terms of reference?

The first thing we will do now is to figure out what kind of beast this is, “Technical Assignment”.

Yes, there really are GOSTs and standards in which attempts are made to regulate this part of the activity (software development). Once all these GOSTs were relevant and actively used. Now there are different opinions about the relevance of these documents. Some argue that GOSTs were developed by very far-sighted people and are still relevant. Others say they are hopelessly outdated. Perhaps someone now thought that the truth was somewhere in the middleJ. I would answer with Goethe's words: “They say that between two opposing opinions lies the truth. In no case! There is a problem between them. ” So, there is no truth between these opinions. Because GOSTs do not reveal the practical problems of modern development, and those who criticize them do not offer alternatives (concrete and systemic).

We note that the GOST does not explicitly even give a definition, it says only: “TK on a nuclear power plant is the main document that defines the requirements and the procedure for creating (developing or modernizing - further creating) an automated system, in accordance with which the development of the nuclear power plant and its acceptance during commissioning into action. "

If someone is interested in what GOST I am talking about, then here they are:

• GOST 2.114-95 Unified system for design documentation. Technical conditions;
• GOST 19.201-78 Unified system of program documentation. Technical task. Requirements for the content and design;
• GOST 34.602-89 Information technology. Set of standards for automated systems. Terms of reference for the creation of an automated system.

A much better definition is presented in Wikipedia (the truth about TK in general, and not just for software): “ Technical task  - this is the initial design document technical  object. Technical task  establishes the main purpose of the object being developed, its technical and tactical and technical characteristics, quality indicators and technical and economic requirements, instructions for the implementation of the necessary stages of creating documentation (design, technological, software, etc.) and its composition, as well as special requirements. A task as a source document for the creation of something new exists in all areas of activity, differing in name, content, order of execution, etc. (for example, a design assignment in construction, a combat assignment, homework, a contract for a literary work, etc. d.) "

And so, as follows from the definition, the main purpose of the Terms of Reference is to formulate requirements for the object being developed, in our case, an automated system.

It is the main, but the only one. It is time to tackle the most important thing: put everything in order, as promised.

What you need to know about the requirements? It must be clearly understood that all requirements must be divided by type and by property. Now we will learn how to do it. GOST will help us to separate the requirements by type. The list of types of requirements that are presented there is a good example of what types of requirements should be considered. For instance:

• Requirements for functionality;
• Security and Access Requirements;
• Staff qualification requirements;
• ... Etc. You can read about them in the mentioned GOST (and below I will also consider them in a little more detail).

I think it is obvious to you that the well-formulated requirements for functionality are the key factor in a successful Terms of Reference. These requirements are the subject of the majority of the works and techniques that I spoke about. Requirements for functionality - this is 90% of the complexity of the work on the development of the Terms of Reference. Everything else is often “camouflage”, which is worn on these requirements. If the requirements are poorly formulated, then what a beautiful camouflage do not pull them, a successful project will not work. Yes, formally, all requirements will be met (according to GOST J), the statement of work is developed, approved and signed, money for it has been received. So what? And then the fun begins: what to do? If this is a project at GosZakaz, then there is no problem - there is such a budget that it won’t fit into any pocket, everything will be clarified in the implementation process (if there is one). That is precisely how the majority of the project budgets at GosZakazy are sawn (TK was heated, tens of millions were merged, but they didn’t do the project. All the formalities were met, there were no perpetrators, a new car was near the house. Beauty!). But we are talking about commercial organizations where they count money, and the result is needed different. Therefore, let's deal with the main thing, how to develop useful and working Terms of Reference.

I said about the types of requirements, but what about the properties? If the types of requirements can be different (depending on the goals of the project), then with properties everything is simpler, there are 3 of them:

1. Requirement must be understandable;
2. Requirement must be specific;
3. Requirement must be testable;

Moreover, the last property is impossible without the two previous ones, i.e. is a sort of "litmus test." If the result of the requirement cannot be tested, then it is either not clear or not specific. Think about it. It is in the possession of these three properties of requirements that craftsmanship and professionalism lie. In fact, everything is very simple. When you figure it out.

On this, the narrative that such Terms of Reference could be completed and go to the main thing: how to formulate requirements. But not so fast. There is another extremely important point:

• in what language (in the sense of difficulty of understanding) should the technical task be written?
• Should specifications of various functions, algorithms, data types, and other technical things be described in it?
• And what is technical design, which, by the way, is also mentioned in GOSTs, and how is it related to the Terms of Reference?

The answers to these questions are a very insidious thing. That is why often disputes arise about the sufficiency or absence of the necessary specification of requirements, about the comprehensibility of the document by the Customer and Contractors, about redundancy, presentation format, etc. And where is the border between the Terms of Reference and the Technical Project?

Technical task  - This is a document based on requirements formulated in a language that is understandable (ordinary, familiar) for the Customer. At the same time, industry terminology that is understandable to the Customer can and should be used. There should not be any bindings to the features of technical implementation. Those. at the stage of TK, in principle, it does not matter on which platform these requirements will be implemented. Although there are exceptions. If we are talking about introducing a system on the basis of an existing software product, then such a binding can take place, but only at the level of screen forms, report forms, etc. It should be engaged in the clarification and formulation of requirements, as well as the development of the Terms of Reference business analyst.And certainly not a programmer (unless he combines these roles in himself, this happens). Those. this person must speak with the Customer in the language of his business.

Technical project  - This is a document that is intended for the technical implementation of the requirements formulated in the Terms of Reference. This document just describes data structures, triggers and stored procedures, algorithms and other things that will be required technical specialists. It is not necessary for the customer to delve into this at all (he may not understand such terms). Technical project does System architect(the combination of this role with the programmer is quite normal). More precisely, a group of specialists led by an architect. The larger the project, the more people work on the Terms of Reference.

What do we have in practice? It is amusing to observe when the Terms of Reference are brought to the director for approval, which is replete with technical terminology, a description of the data types and their meanings, the structure of the database, etc. He, of course, tries to delve into it, since you have to argue, trying to find familiar words between the lines and not lose the chain business requirements. What, a familiar situation? And how does it end? As a rule, such TK is approved, then implemented, and in 80% of cases then it does not at all correspond to the fact of the work performed, because they decided to change a lot of things, redo them, misunderstood, didn’t think so, etc. etc. And then the series begins about the delivery of work. “And here it’s not as we need”, but “it will not work for us”, “it is too complicated”, “it is inconvenient”, etc. Is it familiar? !! So I know, I had to fill up cones in due time.

So what do we have in practice? But in practice, we have a blurred border between the Terms of Reference and the Technical Project. She swims between TK and TP in a wide variety of ways. And that's bad. And it turns out so because the development culture has become weak. This is partly due to the competencies of specialists, partly to the desire to reduce budgets and timelines (after all, documentation takes a lot of time - this is a fact). There is another important factor affecting the use of the Technical Project as a separate document: the rapid development of rapid development tools, as well as development methodologies. But this is a separate story, a little lower I will say a few words about it.

Another small but important point. Sometimes a technical task is called a small piece of requirements, simple and straightforward. For example, to refine the search for an object by any conditions, add a column to the report, etc. This approach is quite justified for itself, why complicate life. But it is used not on large projects, but on small improvements. I would say this is closer to the maintenance of the software product. In this case, the Specification can also describe a specific technical solution to the implementation of the requirements. For example, “Introduce such and such a change to the algorithm,” indicating a specific procedure and a specific change for the programmer. This is the case when the border between the Terms of Reference and the Technical Projects is completely erased, because there is no economic feasibility to inflate paperwork where it is not needed, and a useful document is created. And it is right.

Do you need a technical task? A technical project?

Am I overheated? Is it even possible without Technical task? Imagine perhaps (or rather, it occurs), and this approach has many followers, and their number is increasing. As a rule, after young specialists read books about Scrum, Agile and other technologies of rapid development. In fact, these are wonderful technologies, and they work, only they do not say literally "do not do technical tasks." They say “a minimum of papers”, especially unnecessary ones, closer to the Customer, more specificity and faster to the result. But no one canceled the fixing of requirements, and there it is clearly said. It is there that the requirements are fixed on the basis of three remarkable properties, which I spoke about above. It’s just that some people have such a consciousness that if something can be simplified, then let's simplify it to a complete absence. As Einstein said, “ Make it as simple as possible, but no simpler. ” . Gold words are suitable for everything. So that Technical task  you need, otherwise you will not see a successful project. Another question is how to compose and what to include there. In the light of rapid development methodologies, you need to focus only on requirements, and the whole “camouflage” can be discarded. In principle, I agree with this.

And what about the technical project? This document is very useful and has not lost its relevance. Moreover, often you just can not do without it. Especially when it comes to outsourcing development work, i.e. outsourcing. If this is not done, there is a risk of learning a lot about how the system that you intended should look like. Should the customer meet him? If he wants, why not, but there is no need to insist and approve this document, it will only restrain and interfere with work. Designing a system to the smallest detail is almost impossible. In this case, you will have to continuously make changes to the technical design, which takes a lot of time. And if the organization is greatly bureaucratized, then generally leave all the nerves there. It is precisely the reduction of this kind of design that is discussed in modern rapid development methodologies, which I mentioned above. By the way, all of them are based on the classic XP (extreme programming) - an approach that is already about 20 years old. So make a high-quality Terms of Reference, it is clear to the Customer, and use the Technical Design as an internal document for the relationship between the system architect and programmers.

An interesting detail about technical design: some development tools arranged according to the principle of subject orientation (such as 1C and similar) suggest that design (meaning the documentation process) is required only in really complex areas where interaction between whole subsystems is required. In the simplest case, for example, to create a directory, a document, only correctly formulated business requirements are enough. This is also evidenced by the business strategy of this platform in terms of training specialists. If you look at the exam ticket of a specialist (that is what it is called, not a “programmer”), you will see that there are only business requirements, and how to implement them in a program language is the specialist’s task. Those. that part of the task that the Technical Design is designed to solve, the specialist must solve “in the head” (we are talking about tasks of medium complexity), and here and now, following certain standards of development and design, which again forms the 1C company for its platform. Thus, of the two specialists whose work outwardly looks the same, one may pass the exam, and the second not, because flagrantly violated development standards. That is, it is obviously assumed that specialists should be qualified to design typical tasks on their own, without the involvement of system architects. And this approach works.

We continue the study of the question: “What requirements should be included in the Terms of Reference?”

Formulation of requirements for the information system. The structure of the terms of reference

We’ll immediately decide: we will talk specifically about the formulation of requirements for the information system, i.e. assuming that the work on developing business requirements, formalizing business processes and all previous consulting work has already been completed. Of course, some refinements can be performed at this stage, but precisely the refinements. The automation project itself does not solve business problems - remember this. This is an axiom. For some reason, some leaders are trying to refute it, believing that if they buy the program, then order will come in a chaotic business. But the axiom is the axiom that evidence is not required.

Like any activity, the formulation of requirements can (and should) be divided into stages. Everything has its time. This is hard intellectual work. And, if you treat it with insufficient attention, the result will be appropriate. According to expert estimates, the cost of developing the Terms of Reference can be 30-50%. I have the same opinion. Although 50 is probably too much. After all, the Terms of Reference is not the last document to be developed. After all, there must also be technical design. This variation is due to various automation platforms, approaches and technologies used by project teams during development. For example, if we are talking about developing in a classical language such as C ++, then we cannot do without detailed technical design. If we are talking about introducing a system on the 1C platform, then the situation with the design is somewhat different, as we saw above (although, when developing the system from scratch, it is designed according to the classical scheme).

Despite the fact that the wording of the requirements is the main part of the Terms of Reference, and in some cases it becomes the only section of the ToR, you should pay attention to the fact that this is an important document, and it should be drawn up accordingly. Where to begin? First of all, you need to start with the content. Compose the content, and then begin to expand it. Personally, I do this: first, I outline the content, describe the goals, all the background information, and then get down to the main part - the wording of the requirements. Why not the other way around? I don’t know, it’s more convenient for me. Firstly, this is a much smaller part of the time (compared to the requirements), and secondly, while you describe all the background information, you tune in to the main thing. Well, this is how you like it. Over time, you will develop your own Terms of Reference template. To begin, I recommend that you take exactly the content that is described in GOST as the content. It fits perfectly for content! Then we take and begin to describe each section, not forgetting the recommendations for following three properties: understandability, concreteness and testability. Why am I insisting on this? About this in the next section. And now I propose to go all-tact to those items of TK that are recommended in GOST.

1. general information;
2. purpose and objectives of the creation (development) of the system;
3. characteristics of automation objects;
4. system requirements;
5. the composition and content of work to create a system;
6. system control and acceptance procedure;
7. requirements for the composition and content of work on preparing the automation object for putting the system into operation;
8. documentation requirements;
9. development sources.

Total, 9 sections, each of which is also divided into subsections. We will analyze them in order. For convenience, I will present everything in the form of a table for each item.

Section 1. General information.

	What to do with it in practice
full name of the system and its symbol;	Everything is clear here: we write what the system will be called, its short name
subject code or contract number (number);	This is not relevant, but you can also indicate if required
name of enterprises (associations) of the developer and customer (user) of the system and their details;	indicate who (which organizations) will work on the project. You can specify their roles. You can delete this section altogether (quite formal).
a list of documents on the basis of which the system is created, by whom and when these documents were approved;	Helpful information. Here it is worth indicating the regulatory and reference documentation that you have been provided with for familiarizing yourself with a certain part of the requirements
planned start and end dates for the creation of the system;	Wishes on time. Sometimes in TK they write about it, but more often such things are described in contracts for work
information about the sources and procedure for financing work;	Similarly, as in the previous paragraph about the timing. More relevant for government orders (for state employees)
the procedure for registration and presentation to the customer of the results of work on the creation of the system (its parts), on the manufacture and commissioning of individual tools (technical, software, information) and software and hardware (software and methodological) complexes of the system.	I do not see the need for this paragraph, because the requirements for documentation are made separately, and besides this, there is a whole separate section "Procedure for control and acceptance" of the system.

Section 2. purpose and objectives of the creation (development) of the system.

	What to do with it in practice
System purpose	On the one hand, the appointment is simple. But it is desirable to formulate specifically. If you write something like “qualitatively automate inventory accounting in company X”, then you can discuss the result for a long time at its completion, even regardless of a good statement of requirements. Because The customer can always say that by quality he meant something different. In general, nerves can spoil each other a lot, but why? It’s better to write right away something like this: “The system is designed for stock keeping in company X in accordance with the requirements set forth in this Terms of Reference.”
System goals	Goals are by far the important section. If we include it, then we must be able to formulate these goals. If you have difficulty setting goals, then it’s best to exclude this section altogether. An example of an unsuccessful goal: "To ensure the quick execution of documents by the manager." What is fast? This can then be proved endlessly. If this is important, it is better to reformulate this goal as follows: "The sales manager should be able to draw up a document" Sales of goods "of 100 lines in 10 minutes." A similar goal may appear if, for example, the manager is currently spending about an hour on it, which is too much for this company and it is important for them. In this formulation, the goal already intersects with the requirements, which is quite natural, because when expanding the goal tree (i.e., splitting them into smaller connected goals), we will approach the requirements anyway. Therefore, do not get involved. In general, the ability to identify goals, formulate them, build a tree of goals is a completely separate topic. Remember the main thing: you know how - write, you are not sure - do not write at all. And what will happen if you do not formulate goals? You will work according to requirements, this is often practiced.

Section 3. Characterization of automation objects.

Section 4. System Requirements

	What to do with it in practice
Requirements for the system as a whole. GOST decodes the list of such requirements: requirements for the structure and functioning of the system; requirements for the number and qualifications of the system personnel and the mode of its work; destination indicators; reliability requirements; safety requirements; ergonomics and technical aesthetics requirements; transportability requirements for mobile speakers; operating requirements maintenancerepair and storage of system components; requirements for protecting information from unauthorized access; safety requirements for accidents; requirements for protection against external influences; patent cleanliness requirements; standardization and unification requirements;	Despite the fact that the main, of course, will be a section with specific requirements (functional), this section can also be of great importance (and in most cases it has). What may be important and useful: Qualification requirements . Perhaps the system under development will require retraining of specialists. It can be both users of the future system, and IT specialists who will be needed to support it. Lack of attention to this issue often turns into problems. If the qualifications of the existing staff are clearly insufficient, it is better to write down the requirements for the organization of training, the training program, terms, etc. Requirements for protecting information from unauthorized access. There are no comments here. These are precisely the requirements for delimiting access to data. If such requirements are planned, then they need to be described separately, as detailed as possible according to the same rules as the functional requirements (understandability, specificity, testability). Therefore, it is possible to include these requirements in the section with functional requirements. Standardization requirements.   If there are any development standards that are applicable to the project, they may be included in the requirements. As a rule, such requirements are initiated by the Customer’s IT service. For example, 1C company has requirements for the design of program code, interface design, etc .; Requirements for the structure and functioning of the system.   Here the requirements for the integration of systems among themselves can be described, a description of the general architecture is presented. More often, integration requirements are generally distinguished in a separate section or even a separate Terms of Reference, because these requirements can be quite complex. All other requirements are less important and can not be described. In my opinion, they only complicate the documentation, and have little practical benefit. And it is very difficult to describe ergonomic requirements in the form of general requirements, it is better to transfer them to functional ones. For example, the requirement “Get information about the price of goods by pressing only one button” may be formulated. In my opinion, this is nevertheless closer to specific functional requirements, although it refers to ergonomics.
Requirements for the functions (tasks) performed by the system	Here it is, the very main and key point that will determine success. Even if everything else is done perfectly, and this section is at “3”, then the result of the project will be at best at “3”, or even the project will fail. It is these that we will deal with in more detail in the second article. It is to this point that the "rule of the three properties of requirements" refers to, of which I spoke.
Requirements for types of collateral GOST distinguishes the following types: Mathematical Informational Linguistic Software Technical Metrological Organizational Methodical other…	At first glance, it might seem that these requirements are not important. In most projects, this is true. But not always. When to describe these requirements: Decisions on which language (or which platform) will be developed are not made; The system has multilingual interface requirements (for example, Russian / English) For the functioning of the system, a separate unit must be created or new employees hired; For the system to function, the Customer must undergo changes in working methods and these changes must be specified and planned; It is supposed to integrate with any equipment and requirements are imposed on it (for example, certification, compatibility, etc.) Other situations are possible, it all depends on the specific objectives of the project.

Section 5. Composition and content of work to create a system

Section 6. System control and acceptance procedure

What to do with it in practice

Types, composition, scope and test methods of the system and its components (types of tests in accordance with applicable standards that apply to the developed system); General requirements for acceptance of work by stages (list of participating enterprises and organizations, place and dates), the procedure for approval and approval of acceptance documentation;

But even the presence of testable requirements may not be enough for the delivery of the system, if the procedure for acceptance of work is not clearly defined. For example, a common trap: the system is done, it is fully functional, but the Customer is not ready to work in it for any reason. These reasons can be any: once, goals changed, someone quit, etc. And he says: "Since we are not yet working in the new system, it means we cannot be sure that it works." So learn to correctly identify the stages of work, ways to verify the results of these stages. Moreover, such methods should be understood by the customer initially. If they are fixed at the level of the Terms of Reference, then you can always turn to them if necessary and sum up the work with the transfer.

Section 7. Requirements for the composition and content of work on preparing the automation object for putting the system into operation

	What to do with it in practice
Bringing the information coming into the system (in accordance with the requirements for information and linguistic support) to a form suitable for processing using a computer;	A very important point. For example, for the functioning of the system as intended, it may be necessary to use any industry or national reference books and classifiers. These directories must somehow appear in the system, be updated and correctly used. There may be any other information entry rules adopted by the company (or planned). For example, information about the contract was previously entered in a text line in any form, but now a separate number, a separate date, etc. are required. There can be a lot of such conditions. Some of them can be perceived with the resistance of the staff, therefore it is better to register all such cases at the level of requirements for the data entry procedure
Changes to be implemented in the automation object Creation of conditions for the functioning of the automation object, under which the compliance of the created system with the requirements contained in the technical requirements	Any changes that may be required. For example, the company does not have a local network, an outdated fleet of computers on which the system will not work. Perhaps some necessary information was processed on paper, and now it needs to be entered into the system. If this is not done, then some module will not work, etc. Perhaps something has been simplified, but now you need to take it into account in more detail, so someone should collect information according to certain rules. This list may be long; look at the specific case of your project.
Creation of departments and services necessary for the functioning of the system; Dates and procedures for staffing and staff training	We already spoke about this earlier. Perhaps the system is being developed for a new structure or type of activity that did not exist before. If there is no appropriate personnel, and even trained, then the system will not work, as it does not work properly.

Section 8. Documentation Requirements

What to do with it in practice

The list of sets and types of documents to be developed agreed by the developer and the customer of the system

Having full documentation is an important part of the result. We all know that documenting something is a laborious job. Therefore, it is necessary to stipulate in advance with the Customer what types of documentation will be developed, how they will look (content and preferably examples). Think about how user guides will be presented. Perhaps the Customer has accepted corporate standards, so you need to contact them. Ignoring documentation requirements very often leads to the most unexpected consequences on projects. For example, everything is done and everything works. Users also know how to work. They didn’t agree or talk about documentation at all. And suddenly, when submitting work, one of the top managers of the Customer, who did not even participate in the project, but participates in the acceptance of work, asks you: “Where are the user manuals?” And he begins to convince you that it was agreed to have user manuals it’s not necessary, this “by itself” is supposedly implied. And all does not want to accept your job. At whose expense will you develop guidelines? Many teams have already fallen on this hook.

Section 9. Development Sources

	What to do with it in practice
Documents and information materials should be listed (feasibility study, reports on completed research work, information materials on domestic, foreign analog systems, etc.), on the basis of which TK was developed and which should be used to create the system.	To be honest, it's closer to the lyrics. Especially when they talk about the economic effect and other things that are almost impossible to objectively calculate. Those. can of course, it will be more likely on paper, purely theoretically. Therefore, it is better to refer simply to the survey report, the requirements of key individuals.

And so, we examined all the sections that can be included in the Terms of Reference. “They can,” and not “Obliged,” precisely because any document must be developed to achieve a result. Therefore, if it is obvious to you that a separate section will not bring you closer to the result, then you do not need it and you do not need to spend time on it.

But without the main thing: not one competently competent technical task is complete. I want to note that in practice such Terms of Reference are found, and how! There are figures who are able to separate the waters in all sections, describe the general requirements in general terms, and the document is very weighty, and there are a lot of smart words in it, and even the Customer may like it (i.e. he will approve it). But working on it may not work, i.e. there is little practical benefit from it. In most cases, such documents are born when you need to get a lot of money specifically for the Terms of Reference, and you need to make it quickly and without going into details. And especially if it is known that things will not go further, or completely different people will do it. In general, just for the development of the budget, especially the state.

In the second article we will only talk about section 4 “System Requirements”, and specifically we will formulate the requirements for reasons of comprehensibility, concreteness and testability.

Why requirements must be clear, specific, and testable.

Because practice shows: at first, most of the technical specifications that are developed by specialists either turn out to be unclaimed (do not correspond to reality) or become a problem for which one should implement it, because The customer begins to manipulate non-specific terms and requirements. I’ll give a few examples of what phrases met, what it led to, and then I will try to give recommendations on how to avoid such problems.

Type of requirement

Incorrect wording

Laboratory preparation

Read lecture material on the topic “Models of LC software. Life cycle stages in accordance with GOST 19.102-77. Problem statement "of the discipline" Development and standardization of software and IT ".

1. To study the relevant sections in the publications.

Theoretical part. Development of technical specifications

Technical taskit is a document in which the main development goals, requirements for the software product are formulated, the terms and stages of development are defined and the acceptance testing process is regulated. Both the customer’s representatives and the contractor’s representatives participate in the development of the technical task. This document is based on the initial requirements of the customer, an analysis of the latest achievements of technology, the results of research work, pre-project research, scientific forecasting, etc.

The procedure for the development of technical specifications

The development of technical specifications is carried out in the following sequence. First of all, establish a set of functions performed, as well as a list and characteristics of the source data. Then determine the list of results, their characteristics and methods of presentation.

They further specify the environment for the functioning of the software: the specific configuration and parameters of hardware, the version of the operating system used and, possibly, the versions and parameters of other installed software with which the future software product will interact.

In cases where the software being developed collects and stores some information or is included in the management of any technical process, it is also necessary to clearly regulate the actions of the program in case of equipment and power supply failures.

1. General Provisions

1.1. The terms of reference are drawn up in accordance with GOST 19.106-78 on sheets of A4 and A3 format according to GOST 2.301-68, as a rule, without filling out the fields of the sheet. The numbers of sheets (pages) are affixed at the top of the sheet above the text.

1.2. The approval sheet and title page are drawn up in accordance with GOST 19.104-78. The information part (annotation and content), the sheet of registration of changes is allowed not to be included in the document.

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

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

Introduction;

Name and scope;

The basis for development;

Designation;

Technical requirements for a program or software product;

Technical and economic indicators;

Stages and stages of development;

Order of control and acceptance;

Applications

Depending on the features of the program or software product, it is allowed to clarify the contents of the sections, introduce new sections or combine individual ones. If necessary, it is allowed to include applications in the terms of reference.

2.1.Introduction should include a brief description of the scope of the program or software product, as well as the object (for example, the system) in which they are supposed to be used. The main purpose of the introduction is to demonstrate the relevance of this development and to show what place this development occupies in a number of similar ones.

2.2. In the section "Name and scope" indicate the name, a brief description of the scope of the program or software product and the object in which the program or software product is used.

2.3. In the section "Basis for development" should be indicated:

The document (documents) on the basis of which development is underway. Such a document may serve as a plan, order, contract, etc .;

The organization that approved this document and the date of its approval;

Name and (or) symbol of the development topic.

2.4. In the section “Designation Designation”, the functional and operational designation of the program or software product shall be indicated.

2.5. The section "Technical requirements for a program or software product" should contain the following subsections:

Requirements for functional characteristics;

Reliability requirements;

Terms of Use;

Requirements for the composition and parameters of technical equipment;

Information and software compatibility requirements;

Labeling and packaging requirements;

Requirements for transportation and storage;

Special requirements.

2.5.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, time characteristics, etc.

2.5.2. The subsection “Reliability requirements” shall indicate the requirements for ensuring reliable functioning (ensuring stable functioning, control of input and output information, recovery time after failure, etc.).

2.5.3. The subsection "Operating conditions" should indicate the operating conditions (ambient temperature, relative humidity, etc. for the selected types of storage media) at which the specified characteristics, as well as the type of service, the required quantity and qualification must be provided staff.

2.5.4. In the subsection "Requirements for the composition and parameters of technical means" indicate the necessary composition of technical means with an indication of their technical specifications.

2.5.5. In the subsection “Requirements for information and software compatibility about, the requirements for information structures at the input and output and methods of solution, source codes, and programming languages \u200b\u200bmust be indicated. If necessary, information and programs should be protected.

2.5.6. In the subsection "Requirements for marking and packaging" in general, indicate the requirements for marking a software product, options and methods of packaging.

2.5.7. In the subsection “Requirements for transportation and storage”, the conditions of transportation, storage location, storage conditions, storage conditions, storage periods under various conditions should be indicated for the software product.

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

2.6. In the section "Stages and stages of development" establish 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 a rule, the timing of development and determine the executors.

2.7. The section "Procedure for control and acceptance" should indicate the types of tests and general requirements for acceptance of work.

2.8.In the annexes to the terms of reference, if necessary, the following shall be given:

The 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.

In cases where the customer does not make any requirements stipulated by the terms of reference, indicate “No requirements are made” in the appropriate place.

Examples of the development of technical specifications are given in Annexes B and C.

test questions

1. Give the concept of a software life cycle model.

2. Give the stages of software development.

3. What does the statement of the problem and pre-project research include?

4. List the functional and operational requirements for the software product.

5. List the rules for the development of technical specifications.

6. What are the main sections of the technical specifications.

Appendix A

Job Options

Laboratory work No. 1-5 are performed for the same option.

1. Develop a program module "Accounting for student performance." The program module is designed for the operational accounting of student performance in the session by the dean, deputy deans and employees of the dean’s office. Information about student performance should be stored throughout their entire period of study and used in compiling certificates of completed courses and diploma supplements.

2. To develop the program module "Personal files of students." The software module is designed to obtain information about students by employees of the dean’s office, trade union committee and personnel department. Information should be stored throughout the entire student learning period and used in the preparation of certificates and reports.

3. To develop a software module "Solution of combinatorial-optimization problems." The module should contain algorithms for finding the minimum length cycle (the traveling salesman problem), finding the shortest path and finding the minimum connecting tree.

4. Develop a software module "Processing of the matrix." The module should contain algorithms for searching sums and products of matrix elements by rows and columns, as well as calculating average, minimum and maximum values \u200b\u200bin the matrix.

5. Develop the Windows Organizer application. The application is designed to record, store and search addresses and phone numbers of individuals and organizations, as well as schedules, meetings, etc. The application is intended for any computer user.

6. Develop a Windows application “Calculator”. The application is intended for any users and should contain all arithmetic operations (with respect to priorities) and preferably (but not necessarily) several mathematical functions.

7. To develop the program module "Department" containing information about the employees of the department (name, position, academic degree, discipline, workload, community service, part-time jobs, etc.). The module is intended for use by employees of the personnel department and dean’s office.

8. Develop a program module “Laboratory” containing information about the laboratory staff (name, gender, age, marital status, children, position, academic degree). The module is intended for use by employees of the trade union committee and the personnel department.

9. Develop a program module “Dry Cleaning”. When registering for service, an application is filled out, which indicates the name of the owner, description of the product, type of service, date of receipt of the order and the cost of the service. After completion of work, a receipt is printed.

10. To develop a software module "Accounting for traffic violations." For each car (and its owner), a list of violations is stored in the database. For each violation, the date, time, type of violation and the size of the fine are recorded. When paying all fines, the car is removed from the database.

11. To develop the software module “Automobile shop file cabinet”, intended for use by agency employees. The database contains information about cars (make, engine size, release date, etc.). Upon receipt of a purchase application, a search is made for a suitable option. If this is not the case, the client is entered into the client base and notified when the option appears.

12. To develop the software module “Card index of PBX subscribers”. The card file contains information about the phones and their owners. It fixes debts on payment (monthly and time-based). It is believed that time-based local telephone billing has already been introduced.

13. To develop a program module "Car ticket" containing information about the availability of seats on bus routes. The database should contain information about the flight number, route, driver, type of bus, date and time of departure, as well as the cost of tickets. Upon receipt of an application for tickets, the program searches for a suitable flight.

14. Develop a program module “Bookstore” containing information about books (author, title, publisher, year of publication, price). The buyer draws up an application for the books he needs, if there are none, he is entered into the database and notified when the necessary books arrive at the store.

15. Develop a software module "Parking". The program contains information about the brand of the car, its owner, date and time of entry, cost of parking, discounts, arrears of payment, etc.

16. To develop a program module "Personnel Agency" containing information about vacancies and resumes. The software module is designed both to search for an employee who meets the requirements of the leaders of the company, and to find a suitable job.

LABORATORY WORK № 1

Stages of software development with a structural approach to programming. Stage "Terms of Reference"

purpose of work: familiarize yourself with the rules for writing technical specifications.

Laboratory preparation

Read lecture material on the topic “Models of LC software. Life cycle stages in accordance with GOST 19.102-77. Problem statement "of the discipline" Development and standardization of software and IT ".

  Examine the relevant sections in the publications.

Theoretical part. Development of technical specifications

Technical taskit is a document in which the main development goals, requirements for the software product are formulated, the terms and stages of development are defined and the acceptance testing process is regulated. Both the customer’s representatives and the contractor’s representatives participate in the development of the technical task. This document is based on the initial requirements of the customer, an analysis of the latest achievements of technology, the results of research work, pre-project research, scientific forecasting, etc.

The procedure for the development of technical specifications

  The development of technical specifications is carried out in the following sequence. First of all, establish a set of functions performed, as well as a list and characteristics of the source data. Then determine the list of results, their characteristics and methods of presentation. They further specify the environment for the functioning of the software: the specific configuration and parameters of hardware, the version of the operating system used and, possibly, the versions and parameters of other installed software with which the future software product will interact. In cases where the software being developed collects and stores some information or is included in the management of any technical process, it is also necessary to clearly regulate the actions of the program in case of equipment and power supply failures. 1. General Provisions

  The terms of reference are drawn up in accordance with GOST 19.106-78 on sheets of A4 and A3 format according to GOST 2.301-68, as a rule, without filling out the fields of the sheet. The numbers of sheets (pages) are affixed at the top of the sheet above the text. The approval sheet and title page are drawn up in accordance with GOST 19.104-78. The information part (annotation and contents), the sheet of registration of changes is allowed not to be included in the document. To make changes and additions to the technical rear, in the subsequent stages of developing a program or program product, an addition to it is issued. Coordination and approval of the supplement to the terms of reference is carried out in the same manner as that established for the terms of reference. The terms of reference should contain the following sections:

  introduction; name and scope;

  basis for development; development purpose; technical requirements for a program or software product; technical and economic indicators; stages and stages of development; control and acceptance procedure; applications.

Depending on the features of the program or software product, it is allowed to clarify the contents of the sections, introduce new sections or combine individual ones. If necessary, it is allowed to include applications in the terms of reference. 2. The content of the sections

  The introduction should include a brief description of the scope of the program or software product, as well as the object (eg, system) in which they are intended to be used. The main purpose of the introduction is to demonstrate the relevance of this development and to show what place this development occupies in a number of similar ones. In the section "Name and scope" indicate the name, a brief description of the scope of the program or software product and the object in which the program or software product is used. In the section "Basis for development" should be indicated:

  document (s) on the basis of which development is being conducted. Such a document may serve as a plan, order, contract, etc .; the organization that approved this document and the date of its approval; name and (or) symbol of the development topic. 2.4. In the section “Designation Designation”, the functional and operational designation of the program or software product shall be indicated. 2.5. The section "Technical requirements for a program or software product" should contain the following subsections:

  functional requirements; reliability requirements; Operating conditions; requirements for the composition and parameters of technical equipment;

  requirements for information and software compatibility;

  labeling and packaging requirements; requirements for transportation and storage; special requirements.

In the subsection “Requirements for functional characteristics”, the requirements for the composition of the functions performed, the organization of input and output data, time characteristics, etc. must be indicated. In the subsection “Requirements for reliability”, the requirements for ensuring reliable functioning (ensuring stable functioning, control of input and output information, recovery time after failure, etc.). In the subsection "Operating conditions", the operating conditions (ambient temperature, relative humidity, etc. for the selected types of storage media) must be indicated, at which the specified characteristics, as well as the type of service, the required number and qualification of personnel should be provided. In the subsection "Requirements for the composition and parameters of technical means" indicate the necessary composition of technical means with an indication of their technical characteristics. In the subsection “Requirements for information and software compatibility about, requirements for information structures at the input and output and solution methods, source codes, and programming languages \u200b\u200bshould be indicated. If necessary, information and programs should be protected. In the subsection “Requirements for marking and packaging”, in general, indicate the requirements for marking a software product, options and packaging methods. In the subsection “Requirements for transportation and storage” transportation conditions, storage places, storage conditions, storage conditions, storage periods in various conditions should be indicated for the software product.

  2.5.8. In the section "Technical and economic indicators" should be indicated: approximate economic efficiency, estimated annual demand, economic advantages of development in comparison with the best domestic and foreign models or analogues.

  In the section "Stages and stages of development" establish 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 a rule, the timing of development and determine the executors. In the section "Control and acceptance procedure" the types of tests and general requirements for acceptance of work should be indicated. In the annexes to the terms of reference, if necessary, the following shall be given:

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

  In cases where the customer does not make any requirements stipulated by the terms of reference, indicate “No requirements are made” in the appropriate place. Examples of the development of technical specifications are given in Annexes B and C.

Work order

  Develop terms of reference for the software product in accordance with its version (see the options in Appendix A). Design work in accordance with GOST 19.106-78. At registration to use MS Office. Hand over and protect the work.

Lab report protection

  The report on laboratory work should be issued on the basis of STP and consist of the following structural elements:

  title page; text part; application: developed technical specifications for a software product.

  The text part of the report should include points:

  the task; execution order.

  Saving the laboratory report consists in presenting the results to the teacher in the form of a file and demonstrating the acquired skills in answers to the teacher's questions.

test questions

  Give the concept of a software life cycle model. Give the stages of software development. What does the statement of the problem and pre-project research include? List the functional and operational requirements for the software product. List the rules for the development of technical specifications. What are the main sections of the technical specifications.

List of references

  Bedrina S.L., Software Development and Standardization. - Vladivostok: Publishing House of VSUES, 2006. Blagodatskikh V.A., Volnin V.A., Poskakalov K.F. Standardization of software development. - M: Finance and Statistics, 2003. GOST 19.102-77 ESPD. Development stages

Appendix A

Job Options

Laboratory work No. 1-5 are performed for the same option.

To develop a program module "Accounting for student performance." The program module is designed for the operational accounting of student performance in the session by the dean, deputy deans and employees of the dean’s office. Information about student performance should be stored throughout their entire period of study and used in compiling certificates of completed courses and diploma supplements. To develop the program module "Personal files of students." The software module is designed to obtain information about students by employees of the dean’s office, trade union committee and personnel department. Information should be stored throughout the entire student learning period and used in the preparation of certificates and reports. To develop a software module "Solution of combinatorial-optimization problems." The module should contain algorithms for finding the minimum length cycle (the traveling salesman problem), finding the shortest path and finding the minimum connecting tree. To develop the software module “Matrix Processing”. The module should contain algorithms for searching sums and products of matrix elements by rows and columns, as well as calculating average, minimum and maximum values \u200b\u200bin the matrix. Develop the Windows Organizer application. The application is designed to record, store and search addresses and phone numbers of individuals and organizations, as well as schedules, meetings, etc. The application is intended for any computer user. Develop a Windows application “Calculator”. The application is intended for any users and should contain all arithmetic operations (with respect to priorities) and preferably (but not necessarily) several mathematical functions. Develop a program module “Department” containing information about the department’s employees (name, position, academic degree, discipline, workload, community service, part-time jobs, etc.). The module is intended for use by employees of the personnel department and dean’s office. To develop the “Laboratory” software module containing information about laboratory employees (name, gender, age, marital status, children, position, academic degree). The module is intended for use by employees of the trade union committee and the personnel department. To develop the Dry Cleaning software module. When registering for service, an application is filled out, which indicates the name of the owner, description of the product, type of service, date of receipt of the order and the cost of the service. After completion of work, a receipt is printed. To develop a software module "Accounting for traffic violations." For each car (and its owner), a list of violations is stored in the database. For each violation, the date, time, type of violation and the size of the fine are recorded. When paying all fines, the car is removed from the database. To develop a software module “Automobile shop file cabinet” intended for use by agency employees. The database contains information about cars (make, engine size, release date, etc.). Upon receipt of a purchase application, a search is made for a suitable option. If this is not the case, the client is entered into the client base and notified when the option appears. To develop the software module “Card index of PBX subscribers”. The card file contains information about the phones and their owners. It fixes debts on payment (monthly and time-based). It is believed that time-based local telephone billing has already been introduced. To develop a program module "Autocash" containing information about the availability of seats on bus routes. The database should contain information about the flight number, route, driver, type of bus, date and time of departure, as well as the cost of tickets. Upon receipt of an application for tickets, the program searches for a suitable flight. Develop a program module "Bookstore" containing information about books (author, title, publisher, year of publication, price). The buyer draws up an application for the books he needs, if there are none, he is entered into the database and notified when the necessary books arrive at the store. To develop the program module "Parking". The program contains information about the brand of the car, its owner, date and time of entry, cost of parking, discounts, arrears of payment, etc. Develop a program module "Personnel Agency" containing information about vacancies and resumes. The software module is designed both to search for an employee who meets the requirements of the leaders of the company, and to find a suitable job.

Note.When developing a program, do not limit yourself to the functions described in the option; add a few of your functions. It is mandatory to use a structural and modular approach to programming.

Appendix B

Example 1Develop terms of reference for a software product designed to clearly demonstrate to schoolchildren the graphs of the functions of one argument y= f(x). The program being developed should calculate a table of values \u200b\u200band plot the functions on a given interval using a given formula and change the step of the argument and the boundary of the interval. In addition, the program must remember the entered formulas.

1. Introduction

This technical assignment extends to the development of a program for sorting a one-dimensional array using bubble, direct selection, Shell and quick sorting methods, designed for use by high school students in studying the course of school informatics. 2. The basisfor development

  The program is developed on the basis of the curriculum of the department "Computer Science and Software of Computing Systems". Name of work:

  "The program for sorting a one-dimensional array."

  Contractor: BcstSoft company. Co-executors: source

3. Appointment  The program is intended for use by schoolchildren when studying the topic "Processing of one-dimensional arrays" in the course "Computer Science". 4. Requirements for a program or software product 4.1. Functional Requirements 4.1.1. The program should provide the ability to perform the following functions:

  entering the size of the array and the array itself; array and memory storage; selection of sorting method; output a text description of the sorting method; output of the sorting result.

  4.1.2. Initial data:

  array size specified by an integer; an array.

  Organization of input and output data.

  Input data comes from the keyboard. The output is displayed on the screen and, if necessary, printed.

  Reliability requirements

  Provide for control of input information. To provide blocking of incorrect actions of the user when working with the system.

  Requirements for the composition and parameters of technical equipment.

  The system should run on IBM-compatible personal computers. Minimum configuration:

  processor type Pentium and higher; the amount of random access memory 32 MB or more; 40 MB free hard disk space.

  Recommended Configuration:

  processor type Pentium II 400; RAM capacity 128 MB; the amount of free space on your hard drive is 60 MB.

  4.4. Software Compatibility Requirements.
The program should run under the family of Win 32 operating systems (Windows 95/98/2000 / ME / XP, etc.).

The developed program modules should be self-documenting, i.e. the program texts should contain all the necessary comments. The program being developed should include background information about the program, descriptions of sorting methods and tips for students. The accompanying documentation should include:

  Explanatory note on five sheets containing a description of the development. User's manual.

Appendix B

Example 2To develop terms of reference for the development of the “Module of an automated system for operational dispatch control of heat supply for buildings of the Moscow Institute”.

1. Introduction

The work is carried out as part of the project "Automated system for operational dispatch control of electric heat supply for buildings of the Moscow Institute". 2. The basisfor development

  The basis for this work is contract No. 1234 of March 10, 2003.

  Name of work:

  “Module of an automated system for operational dispatch control of heat supply for buildings of the Moscow Institute”.

  Executors: OJSC “Software Creation Laboratory”.

  Co-executors: no.

3. Purpose of development  Creation of a module for monitoring and operational adjustment of the state of the main parameters for providing the Moscow Institute buildings 4. Technical requirements  4.1. Requirements for functional characteristics. 4.1.1. The composition of the functions performed. The developed software should provide:

  collection and analysis of information on heat, hot and cold water  according to heat meters SA-94 at all thermal outputs; collection and analysis of information from control devices for air heating and conditioning systems of the type RT1 and RT2 (developed by the Department of SMME and TC); preliminary analysis of information on the subject of finding parameters within acceptable limits and signaling when parameters go beyond tolerance;

  issuing recommendations for further work;

  display of the current state according to a set of parameters - cyclically constantly (24-hour operation mode), while maintaining the frequency of monitoring other parameters; visualization of information on coolant flow:

  current, similar to meter readings; with accumulation over the past day, week, month - in the form of an hourly chart for information per day and week; daily consumption - for information per month.

For supply ventilation control devices, the current information should contain the number of the supply system and all parameters issued to its own indicator. Upon request, internal settings are made. At the end of the reporting period, the system must archive data. 4.1.2. Organization of input and output data. The initial data in the system come in the form of values \u200b\u200bfrom sensors installed in the premises of the institute. Thesevalues \u200b\u200bare displayed on the dispatcher’s computer. After analyzing the information received, the operator of the control center sets the necessary parameters for the devices that regulate the heating and ventilation in the premises. It is also possible to automatically set some parameters for control devices. The main mode of using the system is daily work. 4.2. Reliability Requirements. To ensure reliability, it is necessary to verify the correctness of the data received from the sensors. 4.3. Operating conditions and requirements for the composition and parameters of technical equipment. For the system to work, a responsible operator must be allocated. Requirements for the composition and parameters of technical equipment are specified at the stage of outline design of the system. 4.4. Requirements for information and software compatibility. The program should run on Windows 98 / NT / 2000 platforms.

4.5. Requirements for transportation and storage.

The program is delivered on a laser storage medium. Software documentation is delivered electronically and in hard copy. 4.6. Special Requirements:

  the software should have a user-friendly interface designed for the user (in terms of computer literacy) qualifications; in view of the volume of the project, the tasks are supposed to be solved in stages, while the software modules created at different times should assume the possibility of building up the system and be compatible with each other, so the documentation for the adopted operational software should contain the complete information necessary for programmers to work with it; programming language - at the choice of the executor, should provide the ability to integrate software with some types of peripheral equipment (for example, SA-94 counter, etc.).

5. Requirements for software documentation  The main documents governing the development of future programs should be the documents of the Unified Program Documentation System (UPRP): user manual, administrator manual, description of application. 6. Technical and economic indicators The effectiveness of the system is determined by the convenience of using the system to control and manage the main heat supply parameters of the premises of the Moscow Institute, as well as the economic benefits obtained from the introduction of a hardware-software complex. 7. Order of control and acceptance  After the Contractor transfers a separate functional module of the program to the Customer, the latter has the right to test the module for 7 days. After testing, the Customer must accept the work at this stage or state in writing the reason for the rejection. In the event of a justified refusal, the Contractor undertakes to finalize the module.

1. The terms of reference for the supply of equipment for the development of information and technological infrastructure of the fire service and emergency response services. Subject of the state contract

   Technical task

   for the supply of equipment for the development of information and technological infrastructure of the fire service and emergency response services.

2. Terms of Reference for a complex of design and construction works

   Technical task

   2.1. The performance of work under this technical assignment implies the performance by the Contractor of the entire complex of survey, design and construction works on the reconstruction (conversion, redevelopment) of the turnkey construction project, incl.

3. Terms of Reference for the work on the creation of the site sheets

   Technical task

   requirements of RD 50-34.698-90 “Methodical instructions. Information technology. A set of standards and guidelines for automated systems.

4. The terms of reference for the inspection of the technical condition of apartment buildings for major repairs. Low-current system. Communication, alarm, security

   Technical task

   An automatic fire alarm system, as well as a warning and evacuation control system, is an integral part of building life support systems

5. Technical Assignment Lot No. 1 Supply of foreign literature for the library of the go-to-vocational school “SevKavgtu”

   Technical task

   The order of contract pricing: the contract price should include all the costs of the Supplier related to the execution of the contract, including the cost of delivery, unloading of literature to the library, VAT payment and payment

6. The technical specifications of the documentation on the open auction in electronic form No. 624-ea for the right to conclude

   Technical task

   2. Requirements for the period and (or) the volume of guaranteeing the quality of the goods: the warranty period for the delivered goods must be at least 24 months from the date of commissioning.