А что в вашем понимании ФТ, а что системные требования?

А чем по твоему они отличаются?

ресурсы не знаю, как техпис отвечу.. ФТ из серии "реализовать возможность делать то-то" (где "делать" - бизнес-операция типа ведения учета, формирования отчета или документа согласно НПА), а СТ из серии "сделать с такими-то объектами такие-то действия", где действиями будут системные функции-операции типа модернизировать документ ХХХ, добавив контроль такой-то и поле такое-то, значение которого берется из справочника, реализовать справочник такой-то,  и тд  и тп

ФТ часть СТ, некорректно из сравнивать. Помимо ФТ к СТ относятся и не ФТ

Елена @davvol, я думаю как Марина ))
Есть общая схема, что должно вытечь из ФТ, вот она:

Функциональная область, не равна ФТ к системе

Спасибо за интрес к моему вопросу) постараюсь конкретнее задать вопрос:
Есть ФТ и есть нужда сделать СТ.
Куда мне пойти, чтоб выполнить эту задачу (новую для меня)

+100500)
Есть устав, в уставе распределены по структурным подразделениям функциональности (крупные блоки функций)
в Инструкциях подразделений  они делятся на мелкие бизнес-функции
вот эти мелкие бизнес-функции, если они автоматизируются, и будут "реализовать возможность мелкой бизнес-функции" - ФТ

А бизнес-требования тогда здесь что?

только уровень детализации функций разнится, в идеале его на одном уровне выдерживать

бизнес-требования, видимо, пользовательские характеристики...из серии показателей назначения =)   т.к. я не аналитик, то не настаиваю на такой точке зрения

Мне кажется на этой схеме смешали котлеты с компотом.
Функциональная область - это домен в рамках которого мы работаем с нашей системой.
Функциональные требования - это требования к поведению системы, вне контекста полезности или цели этого поведения.

Т.е. они уже не тождественны.

С моей точки зрения такие вещи как описание логики контролей, правил заполнения полей и прочего - это наитиповые ФТ.
А вот проектирование куда какую таблицу засунуть и какого типа поля сделать и т.д. - это уже задача разработчиков когда они будут ФТ эти реализовывать.

И опять же, с моей точки зрения, наличие некоей химерной сущности СТ, при наличии ФТ - это симптом кривизны процесса, где команда теряет время и силы непонятно на что.

спс! прочитал, как воды напился)

Вот вам Вигерса немного:

У Вигерса системные требования это совсем другое:)
Вот цитатка
"Some people use the term “system requirements” to mean the detailed requirements for a software system, but that’s not how we use the term in this book."

Там дальше пример "система" - это, например, рабочее место кассира где два вида сканнеров баркодов, клавиатура, касса, экран и платежный терминал. И всё это всё вместе и есть одна "система". И требования к этой системе как совокупности харда и софта влияют на ФТ конкретного элемента который мы сейчас описываем

И это ближе к SyRS по ISO?
https://www.iso.org/obp/ui/#iso:std:iso-iec-ieee:29148:ed-2:v1:en

Да, Вигерс так дословно и пишет "System requirements describe the requirements for a product that is composed of multiple components or subsystems (ISO/IEC/IEEE 2011)"

И кстати в этом месте опечатка, так как никакого ISO/IEC/IEEE 2011 нет, есть ISO/IEC/IEEE 29148:2011

он же ISO/IEC/IEEE 29148:2018