How to write a technical task for the development of a mobile application?

Question

Android

It is necessary to write a technical task for the development of a mobile application, but the problem is that I am going to write it for the first time, and since the budget is important to me, and not just that the application will be "somehow" , I began to google how to design it correctly and convey it to the programmer his idea in TK . On Harbre, everyone refers to GOSTs, but as I understand it, having started reading them, there are a lot of things that don’t fit, maybe someone knows examples or brief descriptions of a good technical specification for a mobile application?
Py.sy. Other useful links may also help.

Answer 1

Did you write an essay at school? The same thing, an essay on the topic HOW I SEE THE APPLICATION * NAME_APPLICATION * and that’s all, they found something to worry about and what to ask O_O, you don’t write a diploma.
Write briefly and clearly in your own language how you see your application, then the programmer will ask himself if something is not clear.
If the budget is important, then write a short essay, not an abstract, it all depends on the functionality, everything is simple and logical, and it doesn’t matter if you know how to write a technical specification correctly. or not.

Answer 2

Some ideas (not all) when writing technical specifications for mobile (NOT according to GOST)
Development stages (assuming that there is already a concept):
Survey
Interviewing
Prototyping
Description of requirements
Survey:
Assess the scope of the application - determine the structure
Prepare a plan of questions for the project - evaluate possible "white spots" It is
recommended to organize a survey plan for large projects
Outline use cases, relate to a specific target audience
Determine how the application will work (standalone, via network, combined)
Determine the technical requirements for the application: platform (android, IOS, etc.), screen layout (for a smartphone, for a tablet, etc.), layout type (fluid layout, responsive design), screen orientation (horizontal, vertical), etc. e
Interview (skip)
Prototyping:
Match the sizes of the interface elements of the prototype to the actual screen sizes
If possible, use images in layouts - this facilitates visual perception, but note that the prototype must be a prototype so that it is not mistaken for a design
Consider the convenience of touch zones on a mobile device - display the most frequently used items in the easy-to-touch zone on the screen
Highly demanded features and content to the fore, hide secondary in the menu
Think about how to correctly place the application monetization points - they should be visible, but not an eyesore
In navigation, implement a return to the previous screen (Back) where it can help correct incorrect or erroneous user input
Description of the requirements:
When developing the TOR, determine which sections its structure will consist of, whether it is possible to optimize this structure Avoid repetition in the description
, including putting common elements into a separate description complex data structure
If the application implies access restriction for different categories of users, write down the requirements for roles and access separately Set up
business processes separately description to prescribe the input and output of the processes performed on it When describing interface elements, you can adhere to the structure (Approach the question with your head, do not describe the structure where it is not needed): composition - a description of the composition of the element if it contains several elements (for example, a field with a hint ) description - what the element does, additional properties, capabilities
data source - where the data for the element is loaded from: locally or from the API, where they go: in the API to the CASH
update mode - the frequency of updating data, in some cases, put in the general description of the activity (based on the screen structure)
of the function - user actions on the state element
- description of possible states, statuses, modes, visibility
access mode
This is only a small part of what should be taken into