Заказчик не может предоставить качественные функциональные требования. Если он сам не является разработчиком. Функциональные требования требуют понимания принципов работы системы. И сформулировать их должен исполнитель. Заказчик лишь может предоставить свои бизнес-требования, цели и иногда потребности пользователей. Т.е. пользовательские требования
Подробные "технические понятия и задачи" - это уже этап проектирования. Или по ГОСТу "Технический проект". ГОСТом для этого этапа предусмотрен отдельный документ - пояснительная записка к техническому проекту. Если вы говорите, что ТЗ должен быть понятен заказчику, зачем же туда вкладывать информацию об используемых библиотеках? Вложив это в отдельный документ на последующем этапе вы можете дать его заказчику или оставить для внутреннего использования (в этом случае можно обойтись без документа, просто вести wiki)
Ксения, не соглашусь с вами. 1. Функциональные требования Заказчик описывает достаточно понятно для первоначальной работы, а по ходу написания ТЗ все вопросы будут закрыты. То есть Заказчик знает (не всегда может сформулировать, но точно знает и мы помогаем правильно сформулировать) какие цели он хочет достичь. Также, он знает какое поведение системы должно быть (например, уведомить пользователя при создании Заказа в интернет-магазине, отправить поздравление о ДР клиенту и многое другое). Но Заказчик очень часто не может сформулировать в терминах какой-либо информационной системы, но это и не нужно, для этого есть Исполнитель.
2. Мы делаем проекты и описываем по ГОСТ 34 (в частности 34.602–89 (а теперь уже 34.602–2020), но на 80% больших и на 100% маленьких проектах это избыточно и дорого. По факту, мы описываем систему не настолько формально как по ГОСТу, но учитываем все нюнсы, особенно ПМИ (Программа и методика испытаний) Таким образом, наше "обычное" ТЗ не равно ТЗ согласно ГОСТу на ТЗ, а включает нечто большее (ТЗ, Техпроект, РД, ввод в тестовую и промышленную эксплуатации и т.д.), но оно гораздо меньше по объему и более понятное.
Я в своей практике видел, как ТЗ по ГОСТу создавали уже после разработки и внедрения системы, только для того, чтобы сдать систему, но во время проектирования и реализации использовали более простые документы, которые намного проще понять всем участникам проекта.
Заказчик не может предоставить качественные функциональные требования. Если он сам не является разработчиком. Функциональные требования требуют понимания принципов работы системы. И сформулировать их должен исполнитель. Заказчик лишь может предоставить свои бизнес-требования, цели и иногда потребности пользователей. Т.е. пользовательские требования
Подробные "технические понятия и задачи" - это уже этап проектирования. Или по ГОСТу "Технический проект". ГОСТом для этого этапа предусмотрен отдельный документ - пояснительная записка к техническому проекту. Если вы говорите, что ТЗ должен быть понятен заказчику, зачем же туда вкладывать информацию об используемых библиотеках? Вложив это в отдельный документ на последующем этапе вы можете дать его заказчику или оставить для внутреннего использования (в этом случае можно обойтись без документа, просто вести wiki)
Ксения, не соглашусь с вами.
1. Функциональные требования Заказчик описывает достаточно понятно для первоначальной работы, а по ходу написания ТЗ все вопросы будут закрыты.
То есть Заказчик знает (не всегда может сформулировать, но точно знает и мы помогаем правильно сформулировать) какие цели он хочет достичь. Также, он знает какое поведение системы должно быть (например, уведомить пользователя при создании Заказа в интернет-магазине, отправить поздравление о ДР клиенту и многое другое). Но Заказчик очень часто не может сформулировать в терминах какой-либо информационной системы, но это и не нужно, для этого есть Исполнитель.
2. Мы делаем проекты и описываем по ГОСТ 34 (в частности 34.602–89 (а теперь уже 34.602–2020), но на 80% больших и на 100% маленьких проектах это избыточно и дорого. По факту, мы описываем систему не настолько формально как по ГОСТу, но учитываем все нюнсы, особенно ПМИ (Программа и методика испытаний)
Таким образом, наше "обычное" ТЗ не равно ТЗ согласно ГОСТу на ТЗ, а включает нечто большее (ТЗ, Техпроект, РД, ввод в тестовую и промышленную эксплуатации и т.д.), но оно гораздо меньше по объему и более понятное.
Я в своей практике видел, как ТЗ по ГОСТу создавали уже после разработки и внедрения системы, только для того, чтобы сдать систему, но во время проектирования и реализации использовали более простые документы, которые намного проще понять всем участникам проекта.