TOR for software development?

Question

Programming

Colleagues, please share links to high-quality technical specifications for the development of a typical SaaS product.
It is possible in English. Thank you!

Answer 1

I would advise you to take the simplified PMBoK recommendations for the project as a template for a good TOR, namely: 1. Development of
the project charter (documenting the initial requirements, business case, list of stakeholders)
we determine in the first approximation how the development will be carried out and how the control will be carried out.
3. We collect requirements.
4. We define the content, break it down into operations, estimate the resources and time for each operation.
4.1. Technical details, how the system should behave in certain cases, describe the design requirements.
5. Estimate the entire development budget.
6. It is desirable to somehow describe the quality (some characteristics, such as request processing time) of the final product.
7. We prepare a detailed estimate for the project (including the employees who will work on the project and their salaries for the duration of the project).
8. List of persons who are responsible for monitoring the progress of the work and the quality of the work performed.
All information is summarized in a single document. Then the problems will be at a minimum.
In PMBoK, I would also advise you to look at the section on risks and how to properly document them in order to reduce their possible onset and consequences.
All this is relevant regardless of the development methodology.

Answer 2

I have always adhered to the principle that an ideal spherical TOR in a vacuum is such a document that in the future will become product documentation.
Depending on the task, we have both general concepts (turning into some base classes), and examples of using the product, which turn into prototypes, and detailed documentation for each small feature, which turns into technical specifications for each small section, and even agreements and restrictions, which turn into corresponding constraints on the input data, and so on.
The instruction can always be easily and quickly turned into a TK. And if you are not ready to write instructions, then you are not ready to write technical specifications, i.e. do not yet have a sufficient understanding of the structure, tasks, etc. Maybe she will appear in the process of writing ...

Answer 3

"Template TK" sounds like "template invention." It's funny. It's all signed, chief.

Answer 4

The template is something like this:
1. Business task. Explain in layman's terms why this is necessary.
2. Business cases. “Why” is clothed in “how”. Work scenarios.
3. Design, taking into account point 2
You can use the “what, where, when, how” methodology. Simply, we uncover these questions one by one.
If the TOR is more than a couple of pages, then it needs to be broken into smaller pieces until each of them becomes elementary enough for one developer to understand.

Answer 5

I think that it is better to move away from this notorious TK, at least in that form. in which it is usually understood.
I would advise you to first make lists:
1. A list of general requirements for the functionality of the system
2. A list of business tasks that the application should solve
3. A list of use cases, i.e. what users can do on the site.
After that, group the items in the most logical way. For example, use cases can be grouped by site pages. After grouping, describe each item in more detail, so that it is clear what exactly it is.
And in principle, at the end you will get a completely suitable work plan. Of course, some points depend on the specifics of the project. But such a document will be easier for the development team to analyze.