Описание в его функциональной части должно демонстрировать, что система «наносит непоправимую пользу», работая в составе надсистемы, в конструктивной части – что оно реализуемо (можно сделать!), в части пространственной – что система может поместиться там, где она должна работать, в части совокупной стоимости владения – что строить и эксплуатировать систему будет выгодно.
«Предпринимательская гипотеза» – это как раз оно, гипотеза о том, что наш «чёрный ящик» будет полезен и дёшев, поэтому будет хорошо продаваться и инвестирование в его разработку и изготовление прямо сейчас даст прибыль позже. Это визионерство::метод/практика (слово «предпринимательство» мы избегаем употреблять, хотя речь тут идёт строго о «предпринимателе по Шумпетеру», но предпринимательство мало кто понимает «строго как у Шумпетера», и каждый тут фантазирует что-то своё. Так что мы табуируем термин «предприниматель», практику «предпринимательство», а бытовое понимание того, что там происходит, раскладываем на несколько ролей. Визионер::роль – это и есть «предприниматель по Шумпетеру», но это не основатель фирм, не человек с особым складом ума, склонным к риску, не богатый человек, не изобретатель, ничего из обычных ассоциаций с «предпринимателем». Но он оценит, будет ли проект прибыльным: выдаст об этом гипотезу. И если он::роль будет считать, что прибыли не будет – проекта не будет).
Если мы меняем модальность системного описания «чёрного ящика» с доксической (веры) на деонтическую (запреты и разрешения, предписания), то описание чёрного ящика называют системными требованиями (system requirements). И раньше в конечном итоге разрабатывали именно системные требования, а сейчас разрабатывают концепцию использования/concept of operations, уточняемую и детализируемую до сценариев использования/use cases – они отличаются прежде всего вот этим онтологическим статусом, но не только. В концепции использования и дальше в сценариях использования описывают поведение системы как «чёрного ящика», то есть описывают функции системы, её роль в окружении – описывают на статусе гипотезы, что это правильно угаданное поведение успешной системы.
Примерно до 2015 года в системной инженерии даже был отдельный метод инженерия требований, сейчас его нет. Проверьте: до 2015 года в год выходил чуть ли не десяток учебников по вариантам метода инженерии требований, а потом как отрезало – по инерции ещё выпускают книжку в год, но это просто «старички» удовлетворяют спрос других «старичков». Более подробно эта история перехода от инженерии требований к разработке концепции использования рассказана в курсе «Системная