Изначально ТЗ - это приложение к контракту на создание (доработку) системы. В нём фиксируются требования высокого уровня, задающего основные функции системы и рамки проекта (то, что сейчас принято называть бизнес-требованиями). Заказчик при приёмке системы руководствуется тем, что написано в ТЗ (для этого на основе ТЗ "по классике" делается программа и методика испытаний, ПМИ).

Use Cases обычно используют для описания требований более низкого уровня - пользовательского. Если включить их в ТЗ, то разработчик теряет всю гибкость в выборе методов реализации бизнес-требований.

Формат User Stories вообще не предполагает фиксации на ранних этапах. Главная сила User Stories - в  обсуждении с заказчиком и внутри команды непосредственно во время реализации. Это чистая Agile-практика, использовать stories без Agile бессмысленно.

Сейчас, конечно, всё перемешалось, но смысл ТЗ как документа, задающего рамки системы в контракте, в целом сохраняется. Если у вас (как у исполнителя) возникают идеи включить в ТЗ Use Cases или User Stories, значит вы наверняка не договорились с заказчиком "на берегу" о том, что же он хочет получить. И придётся договориваться уже вдали от берега.

два пива этому человеку :)

У нас в ТЗ UCD, AD, форматы сообщений, эскизы интерфейсов. И для клиента, и для разработчиков все закрывает.

Hello @polishukme
You are in read-only mode. To get access to the chat you have to pass a test, please answer few questions.
Click on the button at the bottom of this message to start a test.

а можете написать отличия спецификации (в том виде, который вы вкладвываете в этот тип документа) и ТЗ?

Разработчик!=разработчики, в таком контексте. Когда бэк, фронт веб и фронт мобайл - совсем разные люди, в разных городах и договариваться между собой не обязаны, всё по ТЗ.
А ТЗ архитектор/тимлид согласует и в разработку отдаёт, потом разруливает разногласия.

а то сейчас мне вообще не понятно, что за сущность/документ эта спецификация

Спецификация чего? Ранее приводился пример спецификации к загрузочной секции - документы, детали.

ранее это где? И я больше у Виталия спрашиваю, так как он не хочет смешивать спецификацию и ТЗ

а я не могу понять что же там в спецификации есть вообще, что ее в какие то моменты можно смешать с ТЗ

для меня спецификация это документ, описывающий какой либо стандарт

мы в свое время для почты РФ делали спецификацию требований, примерно, листов на 1800. я, честно, и сам хз зачем оно надо было, но писать пришлось(гос.тендер, все дела).
внутри были: требования к железу, требования к ПО, требования к рабочим местам, требования к внутренним апи, требования к взаимодействию с внешними, способы проверки этих требований, там же раздел про сертификацию и безопасность. далее там же функциональные/нефункциональные требования по всей системе, макеты, описание стилей и обоснования таковых. далее в разрезе каждого блока функционала был описан полный базовый набор юзкейсов. и в приложениях к спецификации еще куча всего.

Я бы предложил составить глоссарий терминов, которыми называют документацию, для начала😎

+

вот короче для меня это ТЗ

данунах))

прикинь в таком формате ТЗ писать на функционал авторизации)

листов на 80 вырисовывается

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

на функционал ТЗ не пишут мне кажется, для это как раз есть UC и US