Terms of Reference or Prototype?

Question

Project management

Custom development. Tired of writing boring technical specifications. We decided to move on to prototyping. It is clear that it will not be possible to completely get away from some, albeit minimal, documentation, but everyone seems to benefit from this. The customer clearly sees an example of what he will receive as a result + the opportunity to "poke into this thing." Engagement is the most important metric here. Well, we are less likely to write texts that the customer, as usual, will wave without reading, or will begin to read and ask again, or even worse - will accept, and later begin to read and reformulate everything in his own way. However, the question arose from the management - how can these prototypes be documented by the customer, so that if something happens, then this statement can be used to argue the fact of accepted work?

Answer 1

Both the prototype and the terms of reference. A prototype is needed so that the customer understands what is at stake, and a technical task is needed to fix the functionality.

Answer 2

The prototype is MVP (Minimum Value Product). So that the customer would evaluate the concept of the final product before months or years of development pass and he will understand whether he needs it or not. Most often, prototypes are written on the simplest frameworks that will allow you to show scenarios and processes, and then, having approved, they start writing in a specific framework / language / platform from scratch.
What you write about is a model. Mockup and Wirefram's older sister.
You can make simple projects using it, but without technical specifications you will mess up. No matter how detailed you draw this model.
Everyone is tired of writing TK, but it is necessary.
The model should go in parallel with the TK, as a visualization of the TK.
It allows you to simplify the communication of tasks, or stakeholders / features of the project, both to developers and to customers who have problems reading documents on a large number of pages.

Answer 3

A prototype is the same part of design solutions (according to GOST 34, layouts belong to the stage of the Technical Design), as well as the requirements of the TOR. Are the drawings signed?
The prototype captures the decisions:
1. What screens the system will have
2. How the screens will be interconnected
3. What blocks will be on each screen
4. What will be the relative position (arrangement) of blocks on the screen.
5. What will be the relative proportions of blocks and elements
6. What will be the behavior of blocks and elements (if the prototype is dynamic)
But please note that prototypes do not describe requirements for quality attributes, constraints, APIs, platform, algorithms, etc., but these are all very important components of the properties of an industrial system / software.

Answer 4

First, there is a technical task from the client. Usually it looks like shit, and according to it, 50% of the entire project will have to be thought out by ourselves. This is a normal situation and there is no need to deal with it.
It is solved as follows:
1) We take a list of the client's Wishlist (he usually calls it TK)
2) We write a normal TK (the prototype is included in the TK)
3) We approve
4) We work
TK implies a prototype with a description of the scenarios.