В личку напишу

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

И, конечно, в ТЗ должны быть выделены новые функции.

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

Тут, по-моему, уже вылезает вопрос - в рамках каких работ какое ТЗ писать?  Полное ТЗ и ТЗ на доработки.
Объемы работ, сроки, бюджеты.

Прикол в том что нет никакой гарантии что старые фичи сейчас работают.

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

Хотел про URS-FS-TS спросить, но в итоге возникло дополнение:
Если нам нужно будет валидировать систему, то придется делать URS, FS, TS на всю систему заново в достаточном для проведения валидации объеме. Но в первоначальном вопросе про валидацию не было речи, поэтому просто дополнение на случай "а вдруг".

Вот и у меня возникла такая идея, т.к. подрядчику для доработки нужно понимание как устроена система.

Спасибо всем за советы!!!

Всем привет) а кто какие средства автоматизации написания документации использует в работе? Хотим сделать составления документации не такой долгой..

На ум пока приходит asciidoc + plantuml чтобы можно было делать доку в одном репозитории с кодом
Может у кого-то есть что получше..

Subversion? Confluence?

Конфа есть, но туда мало кто хочет писать)

Мало кто хочет !=инструмент не подходит. Есть прекрасные макросы для выгрузки содержимого конфы в doc-файлы с нужным оформлением.

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

Конфа+джира+битбакет

К конфлюэнсу ещё прикручивается инструмент по управлению требованиями, и вуаля - вы восхитительны

Вот это поищу, хорошая мысль. Кофа джира и битбакет тоже есть)

А ещё хипчат, бамбу для сборок продукта, и при желании интеграция с Sparx. Минус только один - бесплатных пирожных не бывает)

Спаркс нее, это ещё большее усложнение