Comments 15
Очень детальный список. Это я как раз как системный архитектор говорю. И в 100 страниц не уложиться.
Это просто ГОСТ 34.602-2020
Если требований по разделу нет - то так и пишут - "Требований к .... не предъявляется". Потом заказчик не придерется. Собственно в ГОСТ так и написано "Примечание - В случае отсутствия требований по разделу, соответствующий раздел сохраняется, и в нем приводится запись об отсутствии требований." Если раздел будет пропущен, то Заказчик сможет потом предъявить любые требования и отказаться от них будет проблематично
Этой девушке я бы не доверил писать ни ТЗ ни ЧТЗ. Вот только за одну эту фразу "Но по моему опыту могу сказать, что перечень разделов в ЧТЗ внутри отдельно взятой компании будет варьироваться от полного состава до просто необходимых для описания пунктов." , что противоречит самому тексту ГОСТ, см. выше. И ТЗ и ЧТЗ должны писать не "писатели", а архитекторы, которые отвечают за реализуемость проекта.
6.8 Требования к гарантийным обязательствам разработчика
Почему звучит не так — Гарантийные обязательства разработчика?
Потому, что это ТЗ может быть использовано, например, в тендере, где участвуют несколько компаний разработчиков. Они в своём коммерческом предложении перечисляют гарантии. Член тендерного комитета просто сравнивает по чек листу с требованиями: это есть, это есть, это есть. Ок, положим в папку на детальный технический анализ. А у кого-то вот этого пункта из требований нет. Этот пакет в мусор. Даже если там ещё десяток супер классных обещаний и гарантий. "Не соответствует минимальным требованиям".
Точно так же можно сравнивать с гарантийными обязательствами разработчика. Безо всяких требований.
Член тендерного комитета просто сравнивает предложение, в котором перечислены гарантии, с «гарантийными обязательствами разработчика». Если какого-то пункта из «гарантийных обязательств разработчика» нету — тогда в мусор.
Вопрос ведь именно о том, зачем делать сложные названия, если можно делать простые.
тут скорее дело в том, что надо определить какие особенности гарантии важны в рамках проекта. Где-то важна скорость реакции, где-то длительность, где-то авторское сопровождение по месту физического расположения АС…
Частное техническое задание (ЧТЗ) – это документ, который разрабатывается для конкретной функции или задачи в рамках основного технического задания.
Уточнение. ЧТЗ может быть и на небольшую доработку системы после того как ТЗ принято, и даже после запуска системы в продакшен.
Если нужно добавить нескучных обоев, новую форму, новую кнопку или изменить бизнес-процесс в связи с изменением законодательства - не нужно заново писать ТЗ, достаточно ЧТЗ.
Кто чаще всего пишет ЧТЗ? Как пример, разработчик вряд ли знает обо всех гостах оформления документации, тех пис не разбирается в конкретной разработке. Как в итоге их подружить или нужен ещё кто то третий?
Зависит от команды, но вообще по-хорошему любое ТЗ пишет аналитик. Если ТЗ пишет техпис, то он и есть аналитик, просто ему недоплачивают.
Если они не разбираются в том, чем занимаются, то что они все делают в одном месте?
Пример крайне плохой, свалено в кучу несколько документов, тут и ТЗ и элементы ТУ и ПМ...бедолаги, кто возьмется по такой кальке делать ТЗ.
Каждая компания старается наделить тех писа теми обязанностями, в которых нуждается сама компания. Уровень навыков у самого тех писа иногда далеко не совпадает с требованиями. Поэтому все разглагольствования, что кому и что должен - откровенные глупости. каждая компания настраивает процессы под себя так, как ей удобно. И вопрос уже к сотрудниками, готовы они работать по определенным схемам или нет.
Написание Частного технического задания (ЧТЗ)