Бывает часто (всегда) ситуация, когда пользователь что-то не договорил или думал, что сказал или имел ввиду что это само самой разумеющиеся, конечно программист на фикси обязан знать компанию изнутри и, если есть возможность предвидеть,дополнять и избегать ошибок постановщика, но всё знать невозможно и не всегда удается прочитать мысли пользователя.

Возникла идея насколько правильно заставить писать пользователей требования? конечно не по госту или другому стандарту, а по более простому шаблону (на просторах интернета пока не нашел подобное наверно плохо искал), или вариант второй составлять подобные требования самому и давать на утверждение заказчику.

Насколько данные варианты правильны? как у вас на предприятиях? шаблоны или примеры подобных случайно нет у вас?

Должен быть "главный по бизнес-процессам", который разрабатывает и утверждает/отклоняет все ТЗ.

Любое планируемое изменение БП просто нужно чтоб согласовывалось начальниками всех участвующих в этом БП отделов

(1) нет такого человека
(2) Согласен

(3) Если такого человека нет, то попробуй стать им. Это практически безграничная власть. Перед этим предупреди руководство что если возложить данную задачу на тебя, то всем остальным ты будешь заниматься намного меньше. А без согласования изменений БП, будет автоматизация бардака и в результате получите автоматизированный бардак. Вопрос что им нужно?

правильно. Писать они не смогут и количество работы сократится вдове.

(4) у нас был бизнес аналитик, его заклевали и откровенно говорили не учи нас как работать... руководству откровенно превать на БП.

Сейчас задача прикрыть себе зад. когда пользователь на тебя смотрит широкими глазами и говорит почему этого нет или почему это так работает , а не иначе.Плюс возможность показать пользователю что он дурак (если это так) так как изначально он сам этот бред предложил.

(5) они могут еще жаловаться, особенно если это топы

Конечно самому. Попутно сам больше вникнешь вопрос и вероятно выяснится, что нужно было совсем другое.
Да и когда появится человек, отвечающий за составление подобных требований легче не станет. Ибо этот человек должен будет работать хорошо, чтобы полностью оградить тебя от заявок. Но, как показывает практика, таких людей чертвоски мало и на составлении ТЗ они долго не задерживаются.

(7) Типичный бардак. Если не выходит стать тем, кто принимает решение, то остается делать хотелки и тыкать потом в них носом заказчиков.

Прими как данность, что готовый продукт выходит только после трех-четрыех итераций

(6) ты в газпроме работаешь? Странно такое слышать. Ваш аналитик общаться не умел.
А заявки у вас на через дверь в коридор оговариваются устно, или все таки есть нечто вроде хелпдеска?

(4) и будет как в анекдоте "Да все тоже самое, только ПИСАНИНЫ прибавилось"

(0) И так и так. Часть пользователей без проблем напишет свои требования, часть вообще откажется писать - не царское это дело. Для подстраховки пишешь ТЗ как сам понял, даешь на подпись, потом предъявляешь. Но есть еще более хитросделанные, которые отказываются и ипсать и подписывать, чтобы всегда иметь поле для маневров. С такими труднее всего, но и таких можно заставить жить по правилам. Делать их задачи самыми последними, делать их долго, ссылаясь на отсутствие четкого ТЗ.

(10) согласен что в современном мире принята итерационная модель разработка и я этого понимаю, не понимает заказчик который счетает что каждая итерация это наш косяк.

Частенько ГБ даёт задание на словах. Пишу письмо с описанием на утверждение. всё

(7) К этим товарищам (топам) нужно вырабатывать персональный подход. Тогда особых проблем не будет.

Пользователи пишут бизнес-требование, утверждают со своим руководством (и с задетыми подразделениями, если таковые имеются). Специально обученные люди перерабатывают бизнес-требование в тех.задание. Разработчик оценивает тех.задание. Оценка, ТЗ и БТ утверждаются всем составом в бумажном или электронном виде.
Специально обученными людьми при необходимости могут выступать разработчики. Пользователи не могут и не должны.
А на счет "подумал, что сказал", у меня в нормативках даже есть примерно такой пункт: если текст задания может толковаться по-разному, разработчик его толкует по своему усмотрению.

(14) а ты тз составляешь вообще? его подписывают?

давно не было проблем, но со сменой работы похоже появились люди которые делают круглые глаза и заявляют что "такого разговора не было".
от таких требовать буду формулировать письменно.
если остаются непонятные места - письменно же уточнять до тех пор пока не станет полностью все понятно.

(19) такие люди в тихаря капают руководству, что 1сник тупой и надо бы его поменять ))

(14) Квалификация специалиста 1С определяется умением убедить заказчика в обратном.

(21) это точно... вот чтобы это было сделать проще нужна некая бумажка

Готового решения нет. Многое зависит от сложности самой задачи (и соответственно рисков ошибочной реализации), квалификации заказчика (а способен ли он в принципе написать полноценную постановку), требований к качеству выполненных работ (допустимо ли в последующем корректировка под не утвержденные требования на этапе тестирования и приёмки).

В идеале схема такая.
1. Заказчик (пользователь) формулирует потребность в терминах предметной области с описанием для чего ему это нужно. Назовём это "заявка на доработку".
2. Исполнитель проводит интервью всех пользователей с целью сбора всех требований по заявленной потребности. При необходимости дополняет или уточняет заявку заказчика.
3. Исполнитель пишет полноценное ТЗ в терминах системы.
4. Заказчик утверждает (согласовывает) ТЗ.

Приём готовой разработки должен проводиться в строгом соответствии с подписанным высокими сторонами ТЗ. Что там написано должно работать. Чего там явно не описано - реализуется (или НЕ реализуется) на усмотрение исполнителя.

(22)Если ваши пользователи до того никогда ничего не писали, готовьте папку для коллекционных экземпляров. Помню, первые бумажки, которые мне приносили. "Хочу чтоб был виден количество коробок". После уточняющих вопросов, было дополнение: "Сразу, как захожу в 1С, чтоб был виден".

(14) > ...не понимает заказчик, который считает что каждая итерация это наш косяк.

Надо документировать каждую итерацию.
В преамбуле к каждому протоколу передачи на тестирование должно быть большими буквами написано, что исправления и доработки выполненные в рамках этой доработки не были предусмотрены изначальной постановкой и являются дополнительным требованием заказчика к сходному ТЗ.

А еще следует стучать руководству на постановщиков, не способных ясно и полноценно сформулировать задачу. Жаловаться на возрастающую нагрузку, вызванную  необходимостью додумывать за заказчика и многократное переделывание ранее согласованного.

(23) я бы дополнил "после подписания этих дополнений Заказчиком". Плюс денежку за подготовку ТЗ, если не фикси

(24) самое классное, когда фича нужна двоим сразу. Там такая интерференционная картина возникает, местами цунами и цугундер

(0) всех требований не учтешь, полюбому нужно чаще общаться с постановщиком задач. Недавно так одна задача почти полностью изменилась. Нарисовал диаграмки BPMN что должны делают юзеры и прога, показал сотруднице, она сходу полсхемы поменяла.

(27)О, да... Сейчас скушно, сейчас у нас есть отдельный отдел, который устраивает эти бои без правил - согласует и расставляет приоритеты. Разработчики получают готовую утвержденную очередь.