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

  • Tutorial

Situation


  • At the entrance to the studio, the client (virtually / really is not important).
  • The client wants to order something from us - a system, website, application, app, anything - everything that can be developed and even then crossbreed a bulldog with an anteater, 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 / count / ask questions and then everywhere, expecting in response to receive a very specific exact number and term (as an example) clinic) when it is ready.
  • Waiting.


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

In this design, the dialogue does not look too aggressive and there is always a smooth transition to the next step of the funnel - a positive dialogue about what is TK and what should be there, what else needs to be stated to the client, and especially what does not need to be stated 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 heads of customers.
  • Wishes are an artifact of design.
  • Requirements - wishes consistent with reality.
  • Environment Physics - in the case of the site, these are all the components from which it can be made according to the w3c consortium. In the case of a mobile application, this is the apple developer program or andriod development, etc.
  • An architectural solution is a verbally formulated proposal for the implementation of the requirement, without using elements of the physics of the final environment (we are talking about screens, not talking about the screens of an iPhone or an android specifically).
  • Terms of Reference - a detailed configuration of the system under construction with a description of the properties of the characteristics of the purposes of each element and component, a task document for production, and a document for acceptance testing.


Flies separately - cutlets separately.



Consider the very short life cycle of any plan and its implementation into reality:

  1. Design (what) -> I would like wine
  2. Wishes (formulated fixed) -> whether to send us a messenger for a bottle of wine
  3. Requirements (milestone) -> dry red french
  4. Architectural solution -> we will consume bottled houses and not bottled from a barrel in a restaurant.
  5. Terms of Reference -> in store number 5, redeem 2 bottles of French for 5 rubles each.
  6. Construction (production, execution) -> went bought brought show
  7. Receipt (verification) -> accepted on demand, details verified with tk if necessary.
  8. Commissioning -> open the bottle
  9. Operation -> pour into glasses, consume benefits.


Once again with the site or mobile application:

  1. The idea (what) -> I wanted a super service that can do business
  2. Wishes (formulated fixed) -> we need a service that does this thing X, Y, Z
  3. Requirements (checkpoint) -> the service should do X, Y, and Z is not possible with 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 a form.
  5. Terms of Reference -> X 5 screens (drawn), 24 elements (marked, all data is described), purpose of each (exit from work), behavioral scenarios of each (clicked, won, won), operating characters (manager, housewife on iPad), results from the execution of such and such (the information has been received, the completion has been completed, the letter has been sent, the product information has been transferred to the assembly in the warehouse system, etc. ...)
  6. Construction (production, execution) -> coding, assembly, testing according to the technical specifications, script run.
  7. Receiving (verification) -> deployment (deployment to operational environment, appstore, amazon ...)
  8. Commissioning -> accepted work, send banners advertising, registration.
  9. Operation -> the service is working, conversions are growing, the cache goes to the cashier.


Who owes what to whom?



Speaking about what the client usually can state, these are always wishes, even some of them (a small part) - because a person who is not a specialist is not able to describe all the wishes simply by definition - not his context, and he should not understand it.

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

image

If you have a plan, you need to remove it from your head to start work - they understand what we want and write it down. These are wishes. Artifacts of the client’s intention - only the client can do this, the idea is his part of the work.

Usually, a plan is in the form of a wish and is sent to the post by mistake calling it a technical task, and this is not even a requirement.

The client starts expressing wishes in any format - we do not recommend drawing a lot of things and sending huge projects at this moment - all of them will go to development anyway starting with a simple list of requirements, and therefore you should not just waste time on it.

Note to the hostess : the expectation that a contractor company will take your technical specifications into production without processing (if, for example, there is, for example, a well-developed technical component that is well-developed for the details) is just talking about the quality of the process in this company - if they can change from the outside, so they work randomly, by eye.

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 that the executor is not only a guarantee of the quality of the result, but and in general, getting the final result and not burying the budget in wires.

In general, the technical task is a document in its essence is not so important for work on a project by the client, how important is the ability at any time to contact any of the elements of the system and see how it will work, as well as accept its readiness for the declared document.

Where this document is more important for 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 presented by me to any technical task:

Terms of Reference


  1. The terms of reference should be
  2. It is written by the contractor as opposed to the agreed requirements and signed by the parties.
  3. The terms of reference contain a complete and comprehensive description of the created system in the terminology of solution physics, in its operational environment and clearly give unequivocal answers to the questions:
  4. exactly how, in steps, responding to specific user influences, any element of the system will work.
    1. how will he look
    2. what is its purpose throughout the system
    3. how this element will be serviced during operation and by whom
    4. etc.

  5. It contains the criteria for accepting the result - which, in 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. It is written in a pair with a specialist (with confirmed qualifications) in the field of systems engineering requirements and a specialist in the design of interaction with the system.


About requirements



Requirements - this is the description (model) of the system to which on the side we attribute the deontic modality. (Anatoly Levenchuk)

It is worth noting separately that business requirements are demands for how the system should proceed.

Requirements differ from wishes by a simple principle: requirement = desire + justification.


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

All requirements are recorded 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 - the requirements are a specific requirement for extradition from the system to the outside world - that the system must issue at a particular point in time and place.

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

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

Examples of requirements from real projects:

  • The catalog should show (in the eyes) the goods
  • The logistics system must issue a route (on paper, in an e-mail, again to the eyes and brain) - in order for delivery to proceed according to plan.
  • SMS about training should come to phones (devices) - so as not to call everyone.
  • The product page should transmit specific information xyz (in the eyes) - to decide on ...


In the third column, I ask you to indicate the vision of the solution - how the client sees that his solution could work, in his 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 will be transferred to the section of the document called “Limitations on the solution”.

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 indicate that this is some kind of hint for us as if the client was more pleasant or more convenient to solve a particular problem.

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

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

The requirements are always and always consistent with each other, justifications are formulated, their feasibility is checked, tracing is done, etc.

The requirements must be justified - that you have not sucked everything out of your finger. Documents, decisions, and other artifacts are always welcome.

Requirement tracing is a tool that allows you to show the degree to which the requirement is developed and the effect on the system components.

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

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

If we talk about common misconceptions about the need to always formulate the benefits of creating a product or function, you always need to keep in mind that we are talking only about part of the work on putting the system into operation and operation, and we have never talked about business strategy or business requirements.

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

Therefore, when we talk about demand and terms of reference, we always say - not benefit, but extradition.
It should be understood that the purpose of the terms of reference is a control point at the entrance to and exit from production.

The purpose of the requirements document is to work out the wishes and control the result.

If your TK is really just expectations or unfulfilled wishes - ask yourself the question - how do you control the exit from production of a sufficiently comprehensive product?

Where to get the requirements?


  • Sitting down and writing is nothing complicated at all. Requirements are your expectations.
  • If it’s very difficult, you can order the requirements, who takes how much for it (this is interviewing you, where everyone decides how and how to do it - I do it only in the studio and for the money), here is a cross between the work of the secretary + typist. Well, of course, control questions from us)
  • Decisions can be made on the collected requirements - but only on each decision can there be already a price and terms. It is possible for 5 rubles and it is possible for 50 lyam. Then someone will offer you something on the market, what are your needs and situation.
  • Wait and demand the most detailed specification from the contractor.
  • Only after a clear understanding is the system allowed to enter the structure (development).
  • That’s all, I can add on my own that I can happily work out with your public debriefing your technical tasks and requirements for free (or privately as an examination, paid).


Questions, comments are welcome.

Found typos are corrected, new ones are added.

Only registered users can participate in the survey. Please come in.

What is the average temperature in the hospital now?

  • 17.8% We do not fix the requirements, do not write technical specifications, we work live on technical specifications or according to the client. 10
  • 44.6% We do not fix the requirements, we work on the terms of reference that we ourselves wrote together with the client. We do not share TK and requirements. 25
  • 37.5% We fix the requirements, separate from the statement of work (production document), work as it should. 21

Also popular now: