Спрашиваешь... так делают процентов 90. Другое дело - правильно ли они поступают при этом? Часто документацию путают с проектированием. Это разные вещи и у них разные цели.
Проектировать нужно обязательно, это существенно удешевляет разработку. При этом можно использовать UML или банальные блок-схемы, не имеет значение. Иногда это может поместиться в голове, но чаще это лучше где-то записать. И тут мы плавно приходим к документации.
Плюсы документации в том, что проектное решение можно подготовить сейчас, а реализацию перенести на потом (и ничего важного не забудится по дороге), либо можно обсудить решение с кем-то, выявить риски, передать на реализацию кому-то.
Минусы документации в том, что она быстро устаревает и ее поддерживать довольно дорого и затратно по времени.
Таким образом, ключевым является вопрос о целях документации. Из этого будут ответы и по указанным пунктам.
1. Зависит от сложности/объема задачи. Если все помещается в голове, то для чего тогда документация? Любая, UML или текст, не важно. Если что-то нужно продумать, то можно записать на доске/бумаге, сфоткать, потом выбросить.
2. Без требований мы не знаем что должно было получиться. Для начальной стадии продукта это вполне приемлемо. Основной риск - в регрессе функциональности. Смотрим код и не понимаем для чего он тут нужен и как оно должно работать, меняем как-то и в итоге ломаем ранее реализованную функциональность. Такие риски необязательно решаются документированием требований в форме ТЗ, можно обходиться и автоматизированным тестированием.
3. Уважительной причиной чего-то не делать будет четкое понимание того, как связанные с этим риски минимизируются. Долой догмы. Если в среднесрочной перспективе мы четко осознаем, что фиксация/документирование требований не принесет пользы, то зачем тратить на это время/ресурсы?
Сложный
Простой
