уточняемую и детализируемую до сценариев использования/use cases – они отличаются прежде всего вот этим онтологическим статусом, но не только. В концепции использования и дальше в сценариях использования описывают поведение системы как «чёрного ящика», то есть описывают функции системы, её роль в окружении – описывают на статусе гипотезы, что это правильно угаданное поведение успешной системы.

Примерно до 2015 года в системной инженерии даже был отдельный метод инженерия требований, сейчас его нет. Проверьте: до 2015 года в год выходил чуть ли не десяток учебников по вариантам метода инженерии требований, а потом как отрезало – по инерции ещё выпускают книжку в год, но это просто «старички» удовлетворяют спрос других «старичков». Более подробно эта история перехода от инженерии требований к разработке концепции использования рассказана в курсе «Системная инженерия».

Главное тут:

• Исполнители роли инженеров по требованиям (часто они назывались аналитиками) вклинивались между разработчиками и внешними проектными ролями на основании идеи, что «не надо отвлекать разработчиков от разработки, да ещё эти разработчики с клиентами разговаривать не умеют, это должны делать специально обученные люди». Выяснилось, что эти «специально обученные люди» (аналитики) просто создают ситуацию испорченного телефона (клиент говорит одно, аналитик слышит другое, документирует третье, разработчик вычитывает из требований четвёртое), вреда это приносит больше, чем вред от «отвлечения разработчиков от дела», а время «вычитывания из клиента» и «вычитывания из требований» примерно одинаково. Дополнительно появляется задержка во времени на передачу информации через дополнительное звено и ещё утеря контекста и обоснований появления тех или иных требований.

• Требования появлялись как раз из концепций использования, которые постепенно детализировались. Самые разные требования для тех или иных фич медленно собирались вместе в огромный строго согласованный между собой «монолит» (как это сейчас говорят архитекторы), утверждались – и дальше этот «монолит» передавался в разработку для «безусловного удовлетворения». Вот это «собрать всё, утвердить, передать в работу» оказалось дико медленно, хотя и было сильно лучше исторически предыдущей ситуации, когда проектирование системы шло вообще без требований. Тогда было всё так плохо, что об этом лучше не вспоминать. «Много лучше с требованиями, чем без них» – это было чистой правдой! Но и с требованиями получилось не так хорошо. Первая задержка шла от согласования разнородных требований между собой: участвовали внешние проектные роли, инженеры по требованиям, разработчики, архитекторы. Эти требования утверждались, и все понимали, что они – огромная ценность, ведь в них вложено огромное количество труда, их нельзя менять, они же с таким трудом были согласованы! Поэтому при обнаружении очевидных ошибок в требованиях, или при обнаружении изменения ситуации, при которой надо бы было менять требования – требования предпочитали не менять. И делали систему заведомо хуже, чем могли бы сделать. То, что «у нас есть процедуры изменения требований» – это фикция и отговорки, эти процедуры были запретительно дорогими по времени, к тому же за невыполнение требований наказывали, а за выполнение кривых требований вроде как наказать нельзя.

• После того, как требования попадали к разработчикам, они пытались выполнить обратное действие: понять, что там реально будет полезно внешним проектным ролям, которых разработчики в глаза не видели, а видел их только аналитик. При этом беда была не только в том, что при обнаружении ошибки в требованиях было сложно их менять, но и в том, что сами разработчики считали, что они должны с этими требованиями сработать однократно, а испытания планировались не для того, чтобы продемонстрировать пригодность системы для клиента (потом разобрались, назвали их