We also have a technical task for the system / site / application / project ...

Situation

• At the entrance to the studio client (virtually / really not important).
• The client wants to order something from us — the system, the site, the application, the app, whatever — everything that can be developed and even then crossed the bulldog with a moor for example (1C bitrix, just 1C, other systems and our development).
• He sends us something (as we see it), calling it “TZ” (as he sees it) and says - evaluate / calculate / ask questions and then everywhere, expecting in response, as a rule, to get a very specific exact figure and time (take an example extreme clinic) when it will be ready.
• Is waiting.

Over the years I came to a working construction in this part of the funnel of my sales - I always answer such letters - excellent, I received, I see your wishes for solutions in the letter and, and you forgot to attach?

In such a design, the dialogue does not look too aggressive and a smooth transition to the next funnel step always happens - a positive dialogue about what is and what should be there, what else needs to be stated to the client, and especially what not to be told to the client, and we should do it.
')


Terminology Agreement

• An artifact is a physical representation in the real world of something created by man.
• The idea is what is in the head or the heads of the clients.
• Wishes are an artifact of design.
• Requirements - wishes agreed with reality.
• Physics of the environment - in the case of the site, these are all components from which it can be manufactured according to the w3c consortium. In the case of a mobile application, this is the apple developer program or andriod development, etc.
• The architectural solution is a verbally formulated proposal to implement the requirement, without using elements of the physics of the finite environment (we are talking about screens, not talking specifically about iPhone or android screens).
• Terms of Reference - detailed configuration of the system under construction with a description of the properties of the characteristics of the assignments of each element and component, the document of the task into production, as well as the document for acceptance testing.

Flies separately - cutlets separately.

Consider a very short life cycle of any design and its implementation into reality:

1. The idea (what) -> I would like wine
2. Wishes (formulated fixed) -> Do not send us a messenger for a bottle of wine
3. Requirements (reference point) -> dry red french
4. The architectural solution -> we will consume at home from the bottle and not in the pouring from the barrel in the restaurant.
5. Technical task -> in the store number 5, buy 2 bottles of French for 5 rubles each.
6. Construction (production, performance) -> went bought bought show
7. Receipt (verification) -> accepted on demand, the details were checked with TC as needed.
8. Commissioning -> open bottles
9. Operation -> poured into glasses, consume the benefits.

Once again with the site or mobile app:

1. The idea (what) -> would like a super service that can do business
2. Wishes (formulated fixed) -> we need a service that does this business X, Y, Z
3. Requirements (reference point) -> the service should do X, Y, and Z is not possible with the presence of X and Y, let's better H. OK.
4. Architectural solution -> X we will do as a page. Y will be like a game, and H will be like a request through the form.
5. The technical task -> X 5 screens (drawn), 24 elements (marked, all data are described), purpose of each (exit from work), scenarios of behavior of each (clicked on saw won), operating characters (manager, housewife on ipeda), results from performing such and such (information is received, progress is completed, a letter is sent, information about the product has been transferred to the assembly to the warehouse system, etc. ...)
6. Construction (production, execution) -> coding, assembly, testing on the TC, run scripts.
7. Receiving (verification) -> deployment (deployment to operational environment, appstore, amazon ...)
8. Commissioning -> accepted work, went banners advertising, registration.
9. Operation -> service works, conversions grow, cash goes to the cashier.

Who owes what?

Speaking of what a client can usually state, these are always wishes, even some of them (a small part) - because a person is not an expert who cannot describe all wishes simply by definition - not his context, and he should not understand him.

For clarity, I presented to one of the clients a life cycle diagram of one (!) Requirement, and to this day I show to answer the question what to do:



If there is a plan, then it must be taken out of my head to get started - understand what we want and write it down. These are wishes. Artifacts of the client's plan - only the client can do this, the plan is his part of the work.

Typically, the plan in the form of wishes and sent to the post office mistakenly calling it a technical task, and this is not even a requirement.

The client starts presenting wishes in any format - we do not recommend at this moment to draw a lot of something and send huge projects - all of them will still go into elaboration starting with a simple list of requirements, and therefore you shouldn’t just spend time on it.

Mistress note : the expectation that some company contractor will take into production without processing your TC (if suddenly, for example, there is a well-worked on the details of TC - to itself in the process) only speaks about the quality of the process in this company - if they can change from the outside, so they work randomly, by sight.

Practice shows that in complex (from the word addition, complex) projects (and this is any development or implementation of any business system - from the company's website to complex implementations of multiple systems) - it is the quality and smoothness of the process at the contractor is not only a guarantee of the quality of the result, but and in general, to obtain the final result and not to bury the budget in the wire.

In general terms of reference, this document is not so important in essence for the project work on the part of the client, how important is the opportunity to contact any of the system elements at any time and see how it will work, and also to accept its readiness on the declared document.

Where this document is most important for the production within the contractor’s company, as well as for controlling the output product for compliance with all stated requirements and restrictions, this is how we get quality.

Here are the simple rules shown by me to any technical task:

Requirements for the technical task

1. Terms of reference should be
2. It is written by the performer in contrast to the agreed requirements and signed by the parties.
3. The terms of reference contains a complete and exhaustive description of the system being created in the terminology of the physics of the solution, in its operational environment and clearly unambiguously answers the questions:
4. how exactly steps responding to specific user actions will work any element of the system.
   
   1. how will it look like
   2. what is its purpose throughout the system
   3. how this item will be serviced during operation and by whom
   4. etc.
   
   
5. Contains the criteria for the acceptance of the result - what exactly within the framework of the physics of the system gives a clear understanding that a particular element or scenario of the system works correctly and successfully.
6. Written in a pair with a specialist (with a confirmed qualification) in the field of system engineering requirements and a specialist in the design of interaction with the system.

About requirements

Requirements is a description (model) of the system to which we attribute the Deontic modality to the side. (Anatoly Levenchuk)

Separately, it is worth noting that the Business requirements are the requirements for how the system should operate.

Requirements differ from the wishes on a simple principle: requirement = wish + justification.

In order to justify the requirement, it is necessary to provide artifacts of confirmations that the requirements are determined by the real need and their implementation will override (consistent with) the mission of the entire project.

All requirements are written in a list in one large table in three columns:

| 1. requirement | 2. for what you need | 3. possible solution |

There are no second-order requirements, or nested ones — requirements are a specific requirement for issuing from the system to the outside world — what the system should issue at a specific point in time and place.

Requirements are always located at the output of the results of the system function and entering the real world - in which the user of the system operates it.

The most important thing is to indicate what it is doing (I ask you to indicate it in the second column, and this is the most important thing that can be) - since the requirements are written with the client - we always help to formulate it, sometimes it is a difficult process for many.

Examples of requirements from real projects:

• The catalog must show (in the eyes) goods
• The logistics system must issue a route (on paper, in an electronic letter again to the eyes and the brain) - in order for the delivery to go according to plan.
• SMS about training should come on the phone (device) - so as not to call everyone.
• The product page must convey specific information xyz (in the eye) - to make a decision about ...

In the third column, I ask you to specify the vision of the solution - how the client sees that the solution could work in their own words - let it be like on this site (usually it happens), or we would like this part to open in a separate window. Everything should be blue.

If any wish from the vision of the solution becomes extremely important - it pumps over to the section of the document called “Restrictions on the decision”.

It is worth noting that restrictions always complicate the process of creating a solution and are not always dictated by the needs of the outside world, so we write them in the third column and try to point out that this is some kind of hint for us, as if the client were more pleasant or more convenient to solve this or that problem.

All this allows us to synchronize the ontology of the client’s world and ours for a clearer mutual understanding.

When we have requirements - then everything is worked out on the machine - the process is simply executed. There is already a matter of technology - as a rule, a good performer will not rust.

Requirements are necessarily and always consistent with each other, justifications are formulated, their feasibility is checked, tracing is done, and so on.

Requirements must be justified - that you are not all sucked from the finger. Documents, decisions and other artifacts are always by the way.

Requirements tracing is a tool that allows you to show the degree of development and the impact of requirements on system components.

At this point, you can understand the degree of influence requirements. Requirements have changed - the configuration has changed - also indicates the trace and the degree of influence.

Requirements are signed by the parties. Requirements are easily changed and supplemented constantly in the process of work, it is fixed and does not interfere with work. Requirements are written by the client - agreed by the performer, signed by the parties.

If we talk about common misconceptions about what you should always formulate the benefits of creating a product or function, you should always keep in mind that we are talking only about some of the work on building the system in life and operation, and never talked about business strategizing or business requirements.

A little more on finding a solution through the Job Stories I wrote here deppkind.livejournal.com/3259.html .

Therefore, when we talk about the requirement and technical specifications, we always say - not a benefit but an issue.
It should be understood that the assignment of a technical task is a control point at the entrance to production and exit from it.

The purpose of the document requirements is the elaboration of the wishes and control of the result.

If you really only have expectations or unproduced wishes, ask yourself a question - how will you control the output of a fairly comprehensive product out of production?

Where to get the requirements?

• Sit down and write - there is nothing difficult in this at all. Requirements are your expectations.
• If it’s very difficult - the requirements can be ordered, who takes what for it (everyone interviews you, where and how to do it - I do it only in the studio and for money), then there is a mix of secretary + typists. Well and control questions of course from us)
• It is possible to give solutions to the collected requirements - but only for each decision can there be already price and time. You can for 5 rubles and you can for 50 Lyamov. Then who will offer you on the market, what are your needs and situation.
• Wait and demand detailed TZ from the artist.
• Only after a clear understanding to start in the construction (development) of the system.
• That's all, from myself I can add that I can work with pleasure with a public debriefing of your technical specifications and requirements for free (or privately as an examination for a fee).

Questions, comments are welcome.

Found typos are corrected, new ones are added.