Discussion of article "How to create Requirements Specification for ordering an indicator"
Based on the results of discussions in several threads, I started to write an article for customers, which would be a kind of questionnaire when ordering a robot or indicator. I only went through the part about ordering an indicator, it turned out to be more than 7 pages. That's why I decided to make two smaller articles instead of one big one - one about ordering indicators and the second one about ordering a robot.
I ask all interested to express here suggestions/desires/criticism of the current version. In my opinion, the article is already 95-99% ready, but I may have forgotten some points and artificially added some.
The last point is not finished - Acceptance and testing of the indicator - no special thoughts on this issue yet. After discussion the article will be published in a standard way, so that it can be used by Customers and Developers of trading applications. This is not yet a TOR constructor, but it is already an attempt to make a simple instruction understandable for the Customer.
I've probably never seen a more sensible and lyrical https://www.mql5.com/en/articles/235.
The first post doesn't really show the plan or the essence of it.
- 2011.03.30
- Andrey Khatimlianskii
- www.mql5.com
Strange structure of the article - there were never any problems (in orders, of course) with indicator styles, colours, etc. design, with the output of necessary settings, with styles of screens in the TOR, redraws (if the logic of what is ordered implies redraws, then of course the customer should be aware of it), calculations on each tick (and why does the user need to know it?) - it is clear that if you can reduce calculations, you should do it that way.
The most common confusion is the numbering of bars, what are buffers and how they differ from graphical objects, why it is not necessary to do on graphical objects (if it is possible, of course), in which folder to put the resulting file, what is the difference between the source and executable file, it would be good that examples of the panel that you need to draw somewhere in paint, because mostly it sounds "I need three buttons to open, close and something else".
When an error occurs, it is necessary to understand the cause of its occurrence. This means that you should try to get all the details for investigation. In this case, you should not only show the situation with screenshots or videos, but also provide the developer with the logs of the program and the terminal itself. Therefore, you should not only know where the platform logs are located, but also determine in advance in the Terms of Reference what exactly the program should output and in what format the messages about its operation should be.
No, to begin with you would write "what was expected. why this was expected" and "here's what happened - on some bar some value is wrong" + on the screenshot the date and symbol are still often faded + net to all this.... But the main thing is the first two things, and then you can ask the customer to send more log and set, etc., sometimes it is not necessary. And if you ordered a few weeks ago and just saw something wrong - a link to the order. Often in general in messages one screenshot pops up and guess what is wrong and what the order in general.
And where "too small drawings" - I would say, if I saw in the ToR, "why these drawings?", but in no way I do not interfere with their design. Often it happens in the TOR like this and drawn peaks, troughs, etc. and customers hope that somehow magically the programmer all clearly defined as in their head, there are no definitions of how to look for it.
I mean that the TOR should not be abstract concepts that can be interpreted in two ways - this is the main thing, and that there is something small - does not interfere at all
Probably the cleverest and most lyrical https://www.mql5.com/en/articles/235 I've ever seen.
Here in the first post is not very much plan and essence is visible
You don't need lyrics - you need a fairly dry text that can be read by the customer.
I tried to write briefly, but still got quite a lot.
You don't need lyrics - you need a fairly dry text that the Customer can finish reading.
I tried to write briefly, but I still got quite a lot.
if this article is an attempt to systematise for the future"mql5 master" the TOR, then it is necessary to remove and remove
if it is to clarify the customer what is needed, then add and add.
Now from the text is not clear the ultimate goal. The view is such, like pieces from the screens of the "master" got, hinting style.
And for an expository article it is not suitable at all
Strange structure of the article - never had any problems (in orders of course) with indicator styles, colours, etc. design, with the output of necessary settings, with styles of screens in the TOR, redraws (if the logic of what is ordered implies redraws, then of course the customer should be aware of it), calculations on each tick (and why does the user need to know it?) - it is clear that if you can reduce calculations, you should do it that way.
The idea was that the Customer comes and says:"I want an indicator that:
- draw two red lines and one histogram
- the histogram changes colour according to such an algorithm
- the indicator should use such prices and such an indicator
- calculations should be done only at the bar opening
- the composition and names of input parameters are such and such
- send me a Push when the colour changes
- write in the log this and that
- the control requires a panel with such parameters
- here are pictures with explanations."
A potential Contractor will look at it, quickly calculate labour costs and give the initial cost of the work without a long study of the TOR text.
That is, to make it easier for the Contractor to process potential orders. Imagine, as in McDonald's you make an order.
A potential Contractor will look, calculate labour costs and give the initial cost of the work without a long study of the text of the TOR.
That is, to make it easier for the Contractor to process potential orders. Imagine, as in McDonald's make an order.
Here is as an executor I say that it is useless, other problems with customers. And there as you see fit.
What is the main thing in an indicator? Not lines, gitograms, colours, how to count (the programmer should know it, not the customer), not alerts or fluffs, but LOGIC exactly what the customer is trying to put into the indicator, what he wants to get with the help of the indicator, what functions the indicator should perform. So that the customer can adequately explain it, and the rest can be agreed later. Except that the presence and functions of the panel should be known in advance, and what kind of appearance it will have there can be learnt later.
And you have it all the other way round, no logic is mentioned at all....
If it's to explain to the customer what is needed, then add and add.
I'm afraid no one will end up reading it. Most won't make it to the finish line
What is the main thing in an indicator? Not lines, gitograms, colours, how to count (this should be known by the programmer, not by the customer), not alerts or fluffs, but LOGIC, exactly what the customer is trying to put into the indicator, what he wants to get with the help of the indicator, what functions the indicator should perform.
And you have everything just the opposite, you don't say anything about logic at all....
Logic - it's hard to come up with a template here. According to your experience, how to formalise it?
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
You agree to website policy and terms of use
New article How to create Requirements Specification for ordering an indicator has been published:
Most often the first step in the development of a trading system is the creation of a technical indicator, which can identify favorable market behavior patterns. A professionally developed indicator can be ordered from the Freelance service. From this article you will learn how to create a proper Requirements Specification, which will help you to obtain the desired indicator faster.
Formulating the Requirements Specification as an algorithm
Every indicator reflects an idea. Therefore, first you need to describe the idea, in words and pictures, if possible. If the idea is not explained, it will be much more difficult for the developer to understand what the customer wants.
Now you can proceed with the description of the indicator operation/calculation/display algorithm. Describe the algorithm as a sequence of operations. The developer will be able to write an appropriate code based on the described algorithm. If the description of the idea and the algorithm contains terms, you should explicitly define them to make sure both parties equally understand their meaning.
Divide the algorithm into stages and arrange them in the same sequence as you want them to work. Do not jump between different parts of the Requirements Specification, make sure to properly describe one block, module or step before switching to the next one.
Use lists to describe terms, as follows:
To define stages, use numbers, lists and bold font.
Try to present the Requirements Specification as a series of actions that occur one after another, in the same order they should be performed in the final program. Some examples of Requirements Specifications are shown below.Author: MetaQuotes Software Corp.