По 34 ГОСТу перед ТЗ есть ещё 2 этапа:
1. Формирование требований к АС
2. Разработка концепции АС
http://standards.narod.ru/gosts/gost34/34-601-90.htm

имхо пользовательские истории более уместны в отчете по первому этапу (формирование требований), чем в ТЗ. Как вариант решения, если просто хочется "чтобы было по ГОСТу", создайте этот отчёт. Там много пересечений с ТЗ, требования к содержанию отчета есть здесь: http://standards.narod.ru/gosts/gost34/50-34698-90.htm, приложение 1.

Да, мы в курсе про этап формирования требований.
Но дело в том, что не просто " хочется чтобы было по ГОСТу", а чтобы было как я написал в исходном вопросе: чтобы ПИ были добавлены в ТЗ.

Мы все время уходим от моего главного вопроса, пытаемся его обойти.
Я попросил высказать свои мнения о том, в какое место ТЗ лучше всего вставить ПИ с учетом логики изложения ТЗ и особенностей ПИ.
Я предложил добавить новый раздел между разделом "3. Характеристика объекта автоматизации" и разделом "4. Требования к системе".
Есть лучший вариант?

Еще остался вопрос: могут ли пользовательские истории иметь отношение не к системе в целом, а к какой-то ее части?

Ну и еще появился вопрос чисто по формулировке ПИ - но это лучше в отдельной теме обсудить

А какой документ для требований создается " ... в ситуации быстро меняющихся и уточняемых по ходу разработки продукта требований ..."?
Если "...это будет уже не ТЗ"?

В том-то и дело, что "документ" в привычном виде не создаётся. Для таких условий Agile и придумали.

User stories обычно пишут на отдельных листочках. Можно загнать их в какой-то инструмент для представления в электронном виде (сейчас таких всё больше благодаря росту популярности распределённой разработки). Например, в devprom. Оттуда их даже можно, наверное, экспортировать в .doc файл. Но при правильном использовании user stories этот "документ" будет изменяться постоянно: еженедельно или ежедневно. Его создание оказывается бессмысленным: работать с историями в онлайн-инструменте намного удобнее (можно искать, группировать, обсуждать, просматривать историю изменений и т. п.)

ГОСТ же изначально ориентирован на бумажный документооборот. Во-первых, потому что во времена, когда он писался, других инструментов обмена информацией ещё не было. Во-вторых, потому что ГОСТ стандартизирует отношения не людей, а организаций.

Мы поэтому и не можем дать ответа на "главный вопрос": как втиснуть user stories в ТЗ по ГОСТу. Там для них просто нет места.

Но если руководство требует, то вставляйте в любое. А лучше оформите в виде приложения.

А разве user stories и ФТ не должны быть согласованы между собой когда они находятся в разных документах?
Кто-то же их сверяет.

Мне таких случаев не представлялось, но полагаю, что за их консистентность должен отвечать автор.

И какая тогда принципиальная разница с тем, если они находятся в одном документе?

А разве другие части ТЗ не должны быть согласованы между собой?
Да и не только ТЗ...
В проекте много документации, и все документы должны быть согласованы друг с другом.
Кто-то же сидит и читает все это и при обнаружении разногласий - исправляют.
Им - этим "читателям" проектной документации - получается тоже больше заняться нечем?

Вы написали так критерии приёмки, что их них получается, что консистентность контролирует не автор.
Если контролировать её будете вы, то тогда получится, что просто им придётся делать двойную работу по вычитке.

Почему же нельзя сделать проверку того, что ФТ учитывают все что было описано в ПИ?

Конечно нужно, если вы мешаете мягкий подход с жёстким.

В целом, насколько я понимаю, проблема не стоит выеденного яйца.

Какая разница, куда вы вставите и как назовёте?

Коллеги правы, сущностно US ближе к описанию функций из документа требований заказчика, на уровне ТЗ можно создавать любые приложения.

ОК, я все понял, спасибо

Прошу тогда еще обсудить следующий вопрос, на который мы не обратили внимания.
Пользовательские истории имеют отношение к системе в целом, или к программному обеспечению системы?

Вроде получается так.
ПИ могут относиться как к системе в целом так и к ПО.
На стадии формирования требований к АС, т.е. когда еще не ясна архитектура всей системы, их следует рассматривать как описание работы пользователя с системой в целом.
А дальше, уже при формировании требований к ПО, когда становится ясно какой функциональностью нужно "наделить" ПО, часть ПИ "перекочует" в описание работы пользователя с ПО.

Что думаете?

Я попросил высказать свои мнения о том, в какое место ТЗ лучше всего вставить ПИ с учетом логики изложения ТЗ и особенностей ПИ.

В "Приложение [буква]".

Пользовательские истории имеют отношение к системе в целом, или к программному обеспечению системы?

Если в истории будут слова, что пользователь посидел на стуле, входящем в комплект АРМ, и почитал Положение об отделе, в котором он работает, а потом поклацал кнопками (или наоборот) - то ко всей системе. Если только поклацал - можно к ПО.

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

Да. Но конкретное ТЗ(ЧТЗ) - про вполне конкретные составляющие системы.

Какая разница, куда вы вставите и как назовёте?

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

Если отношения ведутся в официальном ключе и с соблюдением стандартов…

То при чём тут user story? Тут, как говорится, надо или крестик снять или трусы надеть.

То при чём тут user story? Тут, как говорится, надо или крестик снять или трусы надеть.

User story совершенно не при чем, дело в общем подходе.
В официальное ТЗ надо вставить нечто чужеродное, что имеет тенденцию часто меняться. Зачем надо -  я обсуждать не готов, вот такая забористая дурь в команде автора. Что реально могу - ответить автору на его вопрос "куда вставить последнюю..." так, чтобы потом не было мучительно больно.

А так... Если начальник/заказчик возжелал сделать что-то непотребное, платит за это достаточно денег и не ведется на вразумления, скорее всего придется плясать в крестике, без трусов и в шапке-ушанке. Или отказаться от работы, что не каждый работник/организация может себе позволить.

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

спасибо за понимание

Я бы добавил user stories в раздел Требования к Системе в подраздел Требования к функциональным характеристикам.

Я бы добавил user stories в раздел Требования к Системе в подраздел Требования к функциональным характеристикам.

понятно, спасибо за помощь