Здравствуйте, newbie_analyst, Вы писали:

_>Этот простенький пример я привёл для того, чтобы проиллюстрировать, что достаточно большая часть функционала (в этом случае одна треть или больше) системы не покрывается вариантами использования.
_>Но, наверное, это действительно не страшно, и дыры можно закрывать функциональными требованиями.

Конечно не страшно. Главное здесь — не употреблять слов вроде "эктор", а писать по человечески. Скажем, "получение параметров от источника". Как только начнете писать человеческим языком — выяснится, что "варианты использования" — это не совсем человеческое описание вашего текста. Не литературно. У незнакомого с понятием Use case человека вызовет недоумение — смысл этого словосочетания на русском предполагает РАЗНЫЕ варианты использования одной штуки (спичкой можно плиту зажигать и в ухе ковыряться), а у вас они не самостоятельны, а взаимодополняющие. Более по человечески будет написать "сценарии взаимодействия" на мой взгляд, или еще как нибудь. Как я и заставил писать своих — в результате читатели моего тз все понимают и счастливы, и до сих пор не обременены знанием "техники юзкейсов". Так и должно быть.

_>Как мне организовать раздел ТЗ № 4.2 "Требования к функциям системы"? Сваливать туда вперемешку варианты использования, функциональные требования, вытекающие из вариантов использования, и функциональные требования, возникшие сами по себе?
_>Либо только варианты использования и самостоятельные функциональные требования, чтобы не дублировать описание одной и той же функциональности и не путать заказчика?
Можно успешно аргументировать за оба варианта. Вообще — когда есть два варианта, как делать, и вы не уверены как лучше — выбирайте простейший. В вашем случае второй.

G>Для пищи к размышлению — даю свою форму документа требований, который после разработки креативно копипастится в ГОСТ-овское ТЗ.
G>1. Требования к окружению — в каком окружении ваша штука будет работать. Структурная схема типового окружения, описание вольным текстом — в составе какой системы/комплекса то должно функционировать.

G>2. Требования к внешним интерфейсам (если они есть). Тут не надо ничего выдумывать — либо специальные требования есть, либо их нет. У вас, скажем, требования — TCP/IP.

G>3. Сценарии/способы использования.
G>Отвечает на вопрос — как ваша штука будет использоваться.
G>Сюда узкейсы вольным текстом — простым и человеческим, в терминах окружения.

G>4. Фукциональные требования
G>"Определение" вашей штуки. Что она умеет делать.

G>5. Прочие требования.
G>Все, что не влезло в предыдущие секции, но существенно.

И будьте уверены — я поправлю эту свою форму при малейших подозрениях, что она мне мешает или плохо подходит для какой-то задачи. Форма — то не более чем удобная группировка информации, помогающая пониманию сути материала. Если эта группировка станет не помогять, а мешать — сделаю другую.