How to draw up a technical specification correctly. How to competently write technical specifications for a programmer. Fundamentals of mutual understanding. Terms of reference for the development of a mobile application

In most large organizations, intra-company user-IT relationships are inevitable, especially when creating work applications that the user needs on an ongoing basis. The complexity of this relationship can be due to many factors, but most often it is a misunderstanding that arises because the parties speak different “languages” with different terminology. The user understands what he wants, but cannot formulate it; the IT specialist understands the user, but is afraid that the result will come out differently than the first one sees. Most often, the problem begins with the fact that the user is not ready for dialogue: he demands “for it to work”, “for a one-button report”, “for it to be displayed in a minute”, “for dates not to appear in Excel”, and so on. At the same time, he is not at all interested in how this is done and what mechanisms work. The user does not respond to statements about the load on the server, requests to draw a diagram of the desired result, or discuss solutions, believing that a real professional will handle everything. The results of such misunderstanding harm the entire production process: deadlines for solving problems are delayed, errors and gaps arise in systems that the user needs, a server overloaded with incorrect actions suffers, and work speed decreases.

One way to resolve such a conflict is to write a project assignment - terms of reference, which involves a complete and accurate statement of the requirements of the internal customer and is a kind of instruction for an IT specialist. However, not every user is able to express their thoughts competently and intelligibly.
I will give some tips for writing a correct task for the user, which can be worked on and which forms the basis of the relationship between the customer of the solution and the specialist.

1. Before drawing up technical specifications, the user must understand what exactly he wants to receive. You should determine the purpose of the task, the key features of the desired result, draw (write, create a table) for yourself the desired output of the work.

2. Collect documentation, according to which you perform work for which an application (program) is needed. Read it carefully, with a pencil, noting features and subtleties.

3. It should be understood what parameters should be set at the input, what is the frequency of working with the desired program (report, application, utility), how much data will approximately be obtained as an output and whether all of it is needed (for example, if you need the amount of revenue from sales of five categories of products in categories without names, you should not require the creation a million-line report showing each sale with detailed characteristics). Not every specialist needs the most detailed information, the processing of which creates a significant load on computing systems.

4. Describe in detail necessary information , indicate its features, exceptions, and the required level of detail. You should think through all the little things: number format, rounding, fractions, rates, etc.

6. Discuss the written task with the direct executor, try to resolve all questions, carefully listening to the opinion of the interlocutor. Don’t forget that you know your field of activity better and only you can explain exactly what tool you need to work effectively. An IT specialist knows his business and is not required to know the nuances of the work of each department in the organization.

7. Transfer assignment to work within a reasonable time before final implementation, so that there is an opportunity to test the result and correct possible errors.

8. If your subordinates will also use the application you created, try using it yourself explain the features of working with the application– this will save an IT specialist from having to explain the same thing a hundred times.

9. Remember that your assignment will serve as a reference for you - you can always look at the description of the information in it and remember a forgotten requirement.

Of course, just the ability to write a technical specification will not eliminate all problems, but it will allow relations with the IT department to move into a serious level of cooperation, allow the user to increase their technical literacy and get what they need, and save the IT specialist from a number of problems and unnecessary questions.

And so, the main standards, methodologies and bodies of knowledge that mention TK or SRS (Software (or System) Requirements Specification):

GOST 34
GOST 19
IEEE STD 830-1998
ISO/IEC/IEEE 29148-2011
RUP
SWEBOK, BABOK, etc.

GOST 34

According to GOST 34, the technical specification must include the following sections:

1. General information
2. Purpose and goals of creation (development) of the system
3. Characteristics of automation objects
4. System requirements
5. Composition and content of work to create the system
6. Procedure for control and acceptance of the system
7. Requirements for the composition and content of work to prepare the automation object for commissioning of the system
8. Documentation requirements
9. Development sources

When developing technical specifications for government projects, Customers, as a rule, require compliance with this particular standard.

GOST 19

1. Introduction;
2. Reasons for development;
3. Purpose of development;
4. Requirements for the program or software product;
5. Requirements for program documentation;
6. Technical and economic indicators;
7. Stages and stages of development;
8. Procedure for control and acceptance;
9. Applications.

Naturally, GOST 34 (and 19) are already outdated, and I don’t like to use them, but with the correct interpretation of the standards, you can get good technical specifications, see Conclusion.

IEEE STD 830-1998

Describes the content and quality characteristics of a correctly compiled specification of requirements for software(SRS) and provides several SRS templates. This recommended practice is intended to establish requirements for software under development, but can also be used to assist in the selection of proprietary and commercial software products.

According to the standard, the terms of reference must include the following sections:

1. Introduction

• 1. Purpose
• 2. Scope
• 3. Definitions, acronyms and abbreviations
• 4. Links
• 5. Brief overview

• 1. Product interactions (with other products and components)
• 2. Product features (brief description)
• 3. User characteristics
• 4. Limitations
• 5. Assumptions and dependencies

• 1. Requirements for external interfaces
  • 1. User Interfaces
  • 2. Hardware interfaces
  • 3. Software interfaces
  • 4. Interfaces
• 2. Functional requirements
• 3. Performance requirements
• 4. Design Constraints (and References to Standards)
• 5. Non-functional requirements (reliability, availability, security, etc.)
• 6. Other requirements

In fact, it is quite difficult for a beginner to understand what should be contained in these sections according to the above structure (as in the case of GOST), so you need to read the standard itself, which. , however, in English. language.

Well, for those who read to the end, there’s a bonus: an example of technical specifications that I wrote many years ago (now I haven’t been working as an analyst for a long time, and other more successful examples are prohibited from being opened for public viewing by the NDA).

• Presentation by Yuri Buluy Classification of software requirements and its representation in standards and methodologies.
• Analysis of requirements for automated information systems. Lecture 11: Documenting requirements.
• Rules for drawing up Software requirements specification (read along with comments)
• Examples of technical specifications and other documentation for the development of AS for the Ministry of Economic Development
• GOST management style. Gaperton article on correct work with technical specifications according to GOST
• Business Analyst Document Templates from

Federal Law No. 44-FZ on the contract system establishes uniform requirements for the description of the procurement object, which the customer must follow when drawing up procurement documentation, regardless of the method of their implementation (Article 33 44-FZ). Let's consider what rules the customer should follow when drawing up technical specifications.

Technical specification: what is it?

In the terms of reference, the customer describes the requirements for the purchased goods, works, services, and most often it is an annex to the contract, or a document in which the customer describes the procurement object.

The success of the entire event depends on how detailed the customer’s expectations are described. In other words, a technical specification is an instruction for workers that allows you to compare the final result with the planned one.

When describing in the procurement documentation, the customer must be guided by the following rules established by 44-FZ:

• the description of the procurement object must be objective;
• in the description of the procurement object, if necessary, the functional, technical, quality and operational characteristics of the procurement object are indicated;
• the terms of reference must be neutral, that is, not limit the number of potential participants by establishing excessive requirements for goods, works, and services.

The terms of reference must take into account the wishes of the end consumer and not lead to the purchase of luxury goods.

Online course for contract managers, contract service specialists and purchasing commissions. Additional professional program advanced training was developed based on the requirements of the professional standard “Procurement Specialist”.

What is prohibited from being included in the procurement item

The description of the procurement object should not include: requirements or instructions regarding trademarks, service marks, brand names, name of the place of origin of the goods or name of the manufacturer, etc.

Also, the customer is prohibited from establishing requirements for goods, information, works, services, provided that such requirements entail a limitation on the number of procurement participants, unless there is another way that provides a more accurate and clear description of the characteristics of the procurement object (clause 1 Part 1 Article 33).

Indication of GOSTs and technical regulations

It is better to indicate technical regulations, but if they are not specified, they still apply. GOST standards can be indicated in the technical specifications. Even if GOST is optional, but it is specified in the technical specifications, it becomes mandatory for the parties to the contract.

The customer can slightly change the conditions compared to the technical regulations, GOST or SanPiN, but only in the direction of improving the characteristics.

Example
1. In accordance with SanPin 2.4.1.1249-03, the area of ​​landscaping on the territory of the preschool educational institution should be at least 50%, the customer can provide landscaping of at least 60% of the territory.

2. Citric acid can be added to recovery juices in a dosage of no more than 3 g/l (in accordance with technical regulations). The customer can clarify this indicator by reducing its content, for example, to 2 g/l. If the customer refers to GOST, which contains range values, then it is better to write down these values ​​separately so that the participant in his application shows us a specific value from this GOST range.

Provisions of clause 2, part 1, art. 33 of Law No. 44-FZ do not oblige the customer to be guided by GOSTs, standards or technical regulations in absolutely all cases of procurement. The customer uses and justifies the need to use other indicators, requirements, symbols and terminology only if the legislation establishes technical regulations, national standards and other requirements.

In the absence of GOSTs and Technical Regulations, a product for which there is a functioning market, the customer can create a description based on data from manufacturers, quality indicators that the customer needs, data from suppliers on the characteristics of the product due to the lack of established GOSTs, standards and technical regulations for this procurement item ( Letter of the Ministry of Economic Development of Russia dated August 3, 2016 No. OG-D28-9745).

If GOSTs are outdated, then this GOST number should be used, but in the current edition (with a different index after the number).”

Characteristics of TRU

The procurement documentation may indicate trademarks in the event that when performing work or providing services it is intended to use goods the supply of which is not the subject of the contract.

At the same time prerequisite is to include the words “or equivalent” in the description of the procurement object, except for cases of incompatibility of goods on which other trademarks are placed, and the need to ensure the interaction of such goods with goods used by the customer, as well as cases of purchase of spare parts and consumables for machinery and equipment , used by the customer, in accordance with technical documentation for the specified machines and equipment (clause 1, part 1, article 33).

When describing the characteristics of the product, the customer indicates the minimum and (or maximum) values ​​of the indicators. In this case, participants in their applications must indicate the specific meaning inherent in a particular product. In the applications of participants, ambiguous interpretation of the meanings of the words “or equivalent”, “from and to”, “no more”, “no less” is not allowed, except for those cases provided for by State Standards.

How can a customer limit competition through a technical specification?

• Inclusion of heterogeneous products,
• Establishing unrealistic deadlines for deliveries, completion of work, provision of services,
• Establishment of product requirements specific to only one trademark.

All these techniques may be considered illegal and become the basis for initiating administrative proceedings.

What is prohibited from being included in one lot?

It is prohibited to include in one lot goods, works and services that are functionally and technologically unrelated to each other. For example, the customer needs to make repairs to the premises. In the documentation, the customer prescribes a list of works and a list of materials that must be used when performing the work. Such a combination into one lot is legal, since the supply of materials for the work is not the subject of the contract.

For example, the customer announced a request for quotation for the supply of bottled water for coolers and included in the terms of reference a requirement for the provision of related services - maintenance, cleaning and replacement of filters for coolers that are in the customer’s use under the right of legal ownership. Such a combination of the supply of goods and the provision of services into one lot is unlawful, and when considering the complaint, the control authorities will issue an order to disaggregate the lot - to split it into two lots.

1. When drawing up documentation, the description of the procurement object must be objective. That is, a clear and precise description of what exactly the customer needs, not allowing for ambiguity or discrepancies. In addition, to clarify certain points, the supplier may submit a request for clarification.
2. In the description of the item of purchase, the customer describes its functional, technical and other characteristics that are required from the delivered goods (work performed).
3. The terms of reference should be neutral and should not place restrictions on the number of potential participants by prescribing excessive requirements for the products supplied. You cannot “customize” the description only for one specific product from one manufacturer. This is a restriction on competition. The only exception here is the situation when there is no other way to comprehensively describe the properties of the procurement object (clause 1, part 1, article 33).
4. The customer is recommended to indicate in the technical specifications that the supplied product must be new (which has not been used, repaired, including which has not been restored, whose components have not been replaced, whose consumer properties have not been restored), otherwise the customer may receive a used product.

Online course for contract managers, contract service specialists and purchasing commissions.

The technical specifications are the source material for creating information system or other product. Therefore, the technical specification (abbreviated as TK) must first of all contain the main technical requirements to the product and answer the question of what this system should do, how to work and under what conditions.

As a rule, the stage of drawing up technical specifications is preceded by a survey of the subject area, which ends with the creation of an analytical report. It is the analytical report (or analytical note) that forms the basis of the Terms of Reference document.

If the report can state the customer's requirements in general view and illustrated with UML diagrams, the technical specifications should describe in detail all functional and user requirements for the system. The more detailed the technical specifications are, the less controversial situations will arise between the customer and the developer during acceptance testing.

Thus, the technical specification is a document that allows both the developer and the customer to present the final product and subsequently check for compliance with the requirements.

The guiding standards for writing technical specifications are GOST 34.602.89 “Technical specifications for the creation of an automated system” and GOST 19.201-78 “Technical specifications. Requirements for content and design." The first standard is intended for developers of automated systems, the second for software (we discussed the difference between these series in the article “What is GOST”).

So, below we present a list and description of the sections that the technical specifications should contain in accordance with GOSTs.

So, the Technical Specifications document should, in fact, reflect all the requirements for the designed product, identified at the stage of analytical research of the automation object.

Based on the table above, we can highlight the main sections of the technical specifications:

• General information about the system (program);
• Purpose, goals and objectives of the system (program);
• System requirements (functional requirements, user requirements, requirements for the system as a whole, etc.);
• Requirements for types of security;
• Documentation requirements;
• Stages and stages of development;
• The procedure for control and acceptance of the system (program).

General information
This section of the Technical Specification document must contain the full name of the system and all abbreviations that will be used in developing the documentation.

Example:

"IN this document The information system being created is called “Single window of access to educational resources”, abbreviated as SW.
The Single Window for Access to Educational Resources system may be referred to as the Single Window or the System later in this document.”

Also here you should include subsections providing details of the organizations involved in the development (Customer and Contractor).

The subsection “Basis for development” of the Technical Specifications document lists the main documents on the basis of which this work is carried out. For example, for a system commissioned by the Government of a country or another State body, laws, decrees and government regulations must be indicated.

An integral part of the Technical Specifications document should also be a list of terms and abbreviations. It is better to present terms and abbreviations in the form of a table with two columns “Term” and “Full Form”.

Terms and abbreviations are arranged in alphabetical order. First of all, it is customary to decipher Russian-language terms and abbreviations, then English-language ones.

Purpose and goals of creating the system

This section of the Technical Specification document must contain the purpose and goals of creating the system.

Example:

“The information system “Single Window of Access to Educational Resources” is designed to provide users with complete, timely and convenient information regarding the education system of the Russian Federation and organizations performing the function of educational institutions.

The main goal of the System is to create a unified information environment and automate business processes of educational institutions Russian Federation.

The creation of the Single Window information system should ensure:

• providing users with a wide range of information resources;
• level up information security;
• increasing the efficiency of educational institutions and departments by optimizing a number of business processes;
• increasing the efficiency of the process of interaction between information systems and services within the department.

The creation of the System will reduce operating costs as a result of increasing the efficiency of the department.”

System requirements

This section of the Technical Specification document is intended to describe the basic functional requirements of the system. This is the most important part of the technical specification, since it will be your main argument in disputes with the Customer during the process of putting the system into operation. Therefore, it is necessary to approach its writing very carefully.

The Terms of Reference document must contain all the requirements identified at the stage of analysis of the automation object. It is best to highlight the main business processes, which should be disclosed through a description of functional requirements.

Example:

“4.1 Business process “Providing information about educational institutions of the Russian Federation

The following participants are identified in this business process:

Moderator is an employee of the department who is part of the service personnel Systems responsible for the correctness of the data provided

The user is a citizen who needs to receive information about the work of educational institutions of the Russian Federation.

4.1.1 Registration of an educational institution in the System

Registration of an educational institution of the Russian Federation is carried out by the responsible employee of the institution (“Government Decree ...”).

The process of registering an educational institution includes the following steps:

• The author creates a record about the organization;
• The author enters the organization's data;
• The system checks for a license for a given organization

• If the license exists in the database, the System sends a message to the Author about successful registration;
• If the license is not found in the database, the System sends a message to the Author about the absence of a license for this organization.”

If time permits, the information provided in this section should be more fully disclosed in the appendix to the Terms of Reference document. In the appendix to the technical specifications, you can provide a screen form and below describe all the events that are present on it (creation, viewing, editing, deleting, etc.).

Requirements for the system as a whole include a disclosure of its architecture with a description of all subsystems. This part of the Terms of Reference should describe the requirements for integrating the system with other products (if any). Further, the terms of reference should include:

• requirements for system operating modes
• destination indicators
• reliability requirements
• safety requirements
• requirements for the number and qualifications of personnel and their work schedule
• information protection requirements
• requirements for the safety of information in case of accidents
• patent clearance requirements
• requirements for standardization and unification
• etc.

Requirements for types of collateral

This section of the Technical Specification document should contain requirements for mathematical, information, linguistic, software, technical and other types of support (if any).

Documentation requirements

The “Documentation Requirements” section of the technical specification includes a list of design and operational documents that must be provided to the customer.

This section of the technical specification is as important as the description of the functional requirements, so you should not limit yourself to the phrase “The Customer must be provided with all documentation in accordance with GOST 34.” This means that you must provide the entire package of documents including the “Form”, “Passport”, etc. Most of the documents from the list specified in GOST 34.201-89 are not needed by either you or the customer, so it is better to immediately agree on the list at the stage of developing the Technical Specifications document.

The minimum package of documents usually includes:

• Technical specifications;
• Statement of preliminary (technical) design;
• Explanatory note to the Technical Design;
• Description of the organization of the information base;
• User's Guide;
• Administrator's Guide;
• Test program and methodology;
• Acceptance test report;
• Certificate of completed work

It is better to present the list of documents in the technical specifications in the form of a table, which indicates the name of the document and the standard on the basis of which it should be developed.

Stages and stages of development

This section of the Terms of Reference document should provide information about all stages of work that must be carried out.

The description of the stage should include the name, timing, description of work and the final result.

Procedure for control and acceptance of the system

In this section of the Technical Specifications document, it is necessary to indicate the document on the basis of which acceptance tests should be carried out.

If necessary, the technical specification can be supplemented with other sections, or reduced by removing inappropriate items.

When changing the structure of the technical specifications, in order to avoid conflict situations, it must be agreed upon with the customer before the document is developed.

This text was created purely for the sake of the existence of a permanent link, which the author himself, and all of you, could safely send to your future customers, colleagues, relatives and acquaintances in the form of a standardized answer to the question: “Do I need your technical specifications and what in general?” This?"

As they say - “instead of a thousand words”, since each time evangelizing for 4-5 hours on Skype on this topic is already becoming tiresome, and the global tendency to slip outright nonsense into the definition of “Technical Specifications” is only intensifying over the years.

Problem

The fact is that when there is a specific format, as well as a clear and intelligible definition of a term, then all the manipulations and substitutions of it with your own briefs, prototypes, questionnaires invented on the fly, descriptions and simply incoming applications look at least unprofessional. Therefore, we begin with the scientific definition of our concept:

Terms of reference - the original document for the design of a technical object (product). The technical specification establishes the main purpose of the object being developed, its technical specifications, quality indicators and technical and economic requirements, instructions for performing the necessary stages of creating documentation (design, technological, software, etc.) and its composition, as well as special requirements. The terms of reference are legal document- how the application is included in the contract between the customer and the contractor for design work and is its basis: it determines the procedure and conditions of work, including the purpose, objectives, principles, expected results and deadlines. That is, there must be objective criteria by which one can determine whether a particular item of work has been completed or not. All changes, additions and clarifications of the wording of the technical specifications must be agreed with the customer and approved by him. This is also necessary because if inaccuracies or errors in the initial data are discovered in the process of solving a design problem, it becomes necessary to determine the degree of guilt of each of the parties involved in the development and the distribution of losses incurred in connection with this. Technical specification as a term in the field information technology– this is a legally significant document containing comprehensive information necessary for assigning tasks to performers for the development, implementation or integration of a software product, information system, website, portal or other IT service.

Translation into understandable language

1) Technical Assignment - it sets the task. This means it should come before the prototype, sketch, test, design project, because any mindmap, data flow diagram, architecture is already the completion of a certain task, this is the answer to the question. And before the question itself has not yet been asked, formulated and signed by all parties, any answer will be a priori incorrect, right? So, the beginning of any work on any project is the formulation of a problem, and not a frantic search for sketches of a dozen options for solving it.

2) Actually, a new one logically follows from the first point - the text of the TK itself must begin with the chapter “Goals and Objectives,” which clearly formulates what business goals are being pursued by this latest attempt to increase entropy in the world. An aimless task that does not solve any problems, achieves nothing and is done “out of boredom” is not officially considered a Technical Task, and from now on is in the status of “an ordinary piece of paper”.

3) How do you understand whether the proposed design concept or an interactive prototype, or even a ready-to-use website, solves the above business problem? There’s nothing to be done, we’ll have to go back to the definition again: “determines... expected results and deadlines. That is, there must be objective criteria by which one can determine whether this or that item of work has been completed or not.” That is, technical specifications cannot exist without clear measurable indicators in rubles, seconds, ton-kilometers or degrees Celsius. Maybe a brief, or a prototype, or any other absurd piece of paper, but not the Technical Assignment.

From here we conclude that in this TOR there must be a chapter “Acceptance and Evaluation Procedure”, when these same indicators are taken, measured, and the parties either shake hands or send the project for rework.

4) The Technical Assignment must necessarily be consistent with the customer’s overall business plan, its business development strategy and market segment analysis. All this will allow you to set the right goals, derive accurate metrics, which will then be used to adequately accept the finished information product. The absence of a business plan from the customer automatically guarantees unprofessional implementation of the Technical Specifications.

Does an outsourced studio know the business goals and measurable indicators of the business better than its owner? Obviously, no, which means the correct technical specifications should be written by representatives of the Customer, and not by hired employees of the Contractor. It’s absurd when a performer sets a task for himself, then comes up with ways to evaluate it, and in the end gives himself a final mark for the work done. Ideally, such “amateur activity” should not exist, although in practice this is exactly what happens everywhere, as a result of which the Technical Assignment does not provide the necessary assistance to the project, too often being essentially a fictitious document. Don't do that.

5) Each amendment to the finished technical specification must cost money. You cannot freely and endlessly edit the “Constitution of your project” just because one of the parties changed its mind, didn’t get enough sleep, suddenly decided to save money, etc. The price of each change in the technical specifications should also be clearly stated in advance in the relevant chapter.

By the way, in theory, in the same way, every edit in the design or changes to the list of pages or functions should have a clear price, which is paid in advance, before the start of making this change. Personally, I suggest that any editing of the approved technical specification should be estimated at 30% of the entire project budget, but you can do otherwise.

Is it worth mentioning that the terms of reference simply need to indicate in advance the timing and total budget for development, as well as a list of all existing resources and restrictions? - No, it will be too obvious.

So: What are we doing? For what? How will we understand what we have done? How much does each pivot cost? - the answers to all these questions written on a piece of paper are the “silver bullet” that can pull out even the most failed project.

Security questions

1) So, maybe there is also an official GOST for writing Technical Specifications? - Yes, even several.

2) What, the Technical Specification does not include a description of the required pages, the number of buttons, libraries used, guidelines, etc.? - Not in the TOR itself, but you can put all this in the Appendices, of course adjusting all this with the above-described goals, limitations and methods for further assessing the achieved result. Post at least all future content, even a description of typical characters - but not instead of a clear statement of the task, but after it.

3) So maybe I don’t need it like that? - Perhaps today thousands of sites are made without technical specifications at all, just as thousands of people in the world live well, being blind from birth. But if you want to see where you are heading, consciously make decisions and independently evaluate the results obtained, then you cannot do without technical specifications.

4) So you and Wikipedia write that the technical specification is created by the customer. But I don’t know how/I don’t have time/I just don’t want to do it myself. How can this be? - Outsource the development of technical specifications to a third party who is completely familiar with your business, its tasks, target audience and needs, and at the same time thoroughly knowledgeable about all stages of web development. This third party will become a kind of “web notary”, that is, a guarantor that the contractor will not underestimate the indicators you need or will not delay the deadlines, and that the customer will set achievable metrics and at the final acceptance will not subjectively evaluate the created product, changing the previously recorded ones on the fly requirements.

5) And what if the technical specification is a legal document, then I can sue the outsourcer, not pay him, force him to redo everything for the tenth time? - If the document is drawn up correctly, the goals and methodology for assessing their achievement are indicated; if the document is signed by the parties and mentioned in the Agreement (the Terms of Reference itself is not an agreement) - then of course you can. But with the usual brief, prototypes, art-creative layout, Safe deal on FL - no longer.

6) They tell me that the work will be carried out using some kind of Scrum or Agile; which means I no longer need the archaic technical specification. Is that so? - Judge for yourself: they call you an incomprehensible word that clearly masks something, and now, on the basis of an unfamiliar term, they offer to abandon a legally competent document filled with goals and metrics. Agile itself cannot set any goals like “to achieve at least 10,000 visits by the end of the year”, or “to achieve more than 25 orders from the site in a month”, it’s just a way of holding meetings and new organization careless employees. Think several times: “Are they not throwing dust in your eyes?” In fact, professional technical specifications cannot harm any newfangled Scrum, but it is sure to help.