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

• Работа с концепциями использования и сценариями использования, по которым требования не разрабатывались, а которые использовались разработчиками непосредственно, происходила ещё и быстрее: разные сценарии использования правили и реализовывали разные команды людей-разработчиков, а чтобы результаты работы этих людей объединились между собой – за этим прислеживали архитекторы (понятие архитектуры тоже изменилось, ибо оказалось нельзя изменить только работу с требованиями). Это означает, что командам не надо было ждать друг друга, пока соберутся и затем утвердятся все требования в одном «монолите». Нет, все высказывали свои гипотезы в виде концепции использования (описывали систему как чёрный ящик), критиковали их, проверяли путём создания части системы, реализующей сценарии использования, затем улучшали эти сценарии – и так система создавалась и развивалась непрерывно, бутылочное горлышко «собрать все требования вместе и потребовать их однократного выполнения» исчезло, а работа по созданию системы была распараллелена не только в части собственно проектирования, но и в части понимания того, что должно быть спроектировано – что там за поведение (функции) должен выдавать «чёрный ящик».

• Отказ от требований привёл ещё и к тому, что начали активно использовать A|B тестирование60, когда гипотез выдвигается сразу несколько (требования обычно требуют что-то одно!), и проверяются они все вместе, а потом выбирают вариант, который оказался по каким-то критериям лучше. Если у тебя «гипотезы», а не «требования», то ты с ними поступаешь другим образом: не столько «удовлетворяешь», сколько «проверяешь и постепенно корректируешь».

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