Онтология требований: Проблемы классификации Вигерса и предложенные улучшения

Иннокентий Бодров

Источник: Денис Бесков, основатель школы Systems Education, основной автор профстандартов системного аналитика и менеджера IT-продуктов. Доклад "Что не так с онтологией требований Вигерса и что с этим делать".

1. Общая постановка проблемы и актуальность

Денис Бесков начинает свой доклад с утверждения, что хотя многие считают классификацию требований второстепенной, профессионалы в любой области (например, лыжники, различающие 10 видов снега, или слесари, различающие 8 видов рубанков) детально разбираются в предмете своей деятельности. Для них эти детали представляют собой разные предметы труда, требующие разного подхода. Это применимо и к требованиям в IT.

Он подчеркивает, что Карл Вигерс является де-факто стандартом в прикладной инженерии требований для IT-проектов, и его работа подняла и глубоко проработала эту тему. Бесков сам использует подходы Вигерса около 20 лет и строил на них свои авторские курсы. Однако, он считает, что модель Вигерса имеет недостатки и нуждается в улучшении. Его основной тезис: "давайте не бояться критиковать наших гуру экспертов... опираться на наработки коллег, но их критиковать, развивать, идти дальше".

2. Критика классической модели Вигерса (трехуровневая)

Вигерс предлагает трехуровневую модель требований:

Бизнес-требования (Business Requirements)
Пользовательские требования (User Requirements)
Функциональные требования (Functional Requirements)

2.1. Лингвистический и системный анализ терминологии Вигерса:

Бесков, используя свой опыт в лингвистике и системной инженерии, указывает на парадоксы в терминологии Вигерса:

"Software Requirements" – это требования к ПО.
"System Requirements" – это требования к системе.
Однако "Functional Requirements", "User Requirements", "Business Requirements" лингвистически не следуют этой логике. Они не являются "требованиями к функциям", "требованиями к пользователям" или "требованиями к бизнесу" в прямом смысле.

2.2. Несоответствие сущности "требования":

Бесков утверждает, что:

Бизнес-требования по Вигерсу – это "высокоуровневые цели организации", например, "сократить расходы". Бесков отмечает, что это скорее цели (похожие на SMART-цели или инициативы), а не классические требования, которые должны указывать предмет, характеристику и адресата ("к чему это предъявляется"). Он задается вопросом: "как может софт сократить расходы?".
Пользовательские требования по Вигерсу – это "цели либо задачи класса пользователей". Опять же, это скорее цели, чем требования. Неявно подразумевается, что пользователи являются источниками требований, хотя они не всегда уполномочены их предъявлять.
Только Функциональные требования (например, "система должна отправить письмо") по своей структуре похожи на полноценные требования, описывающие конкретное поведение системы.

Вывод: "Оказывается вот как бы эти вот требования, оказывается, не совсем требования, скорее являются выражением намерения, выражением интереса, выражением цели, но здесь не сказано, кто, чего конкретно они хотят от кого".

2.3. Смешение уровней системной сложности:

Ключевая проблема, по мнению Бескова, в том, что Вигерс, относя все эти уровни к "Software Requirements", смешивает требования к разным "предметам труда":

Software System (программная система): чистый программный код, исполняемые файлы.
Программно-аппаратная система: софт + оборудование.
Человеко-машинное взаимодействие (Human Machine Interaction): технологии + оборудование + софт + люди. Это уже другая система с другими свойствами. "То что может делать софт – это одно, то что может делать человек с помощью софта – это немножко другое".
Организация: включает физические активы, программно-аппаратные системы, людей, процессы и подразделения.

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

3. Предложенные улучшения модели классификации (трехуровневая модель)

Бесков предлагает привести терминологию в соответствие с системным подходом, сохраняя четкую конструкцию "требование к...":

Требования к бизнесу (Business Requirements): Это требования к свойствам организации. Они проистекают из законодательства, миссии компании, стратегии, положения подразделений.

Пример: "Компания должна продавать товары на розничное потребление".

Требования к сотрудникам / пользователям (User Feature Requirements): Это требования к свойствам сотрудников (или пользователей). Они проистекают из положения подразделений, должностных/рабочих инструкций.

Пример: "Сотрудник должен иметь возможность согласовать договор".
Важный сдвиг парадигмы: Это не требования пользователей (что они хотят), а требования к пользователям (что они должны уметь делать, с каким качеством). "Пользователи по большому счёту не уполномочены что-то требовать... только те вещи, которые были с ними оговорены".

Требования к ПО / функциям (Soft Features): Это требования к свойствам софта.

Пример: "Система должна отправлять письмо".

Ключевые преимущества предложенной модели:

Однозначность и устойчивость структуры: "указан субъект требования, указано какое-то ключевое поведенческое свойство... указаны там какие-то дополнительные атрибуты, которые фактически являются обстоятельствами действия".
Трассировка: "Есть прямая трассировка между требованием бизнесом и софтом, потому что некоторые требования бизнеса могут реализовываться через софт в обход человека".
Разделение ответственности: За первые два уровня (бизнес и сотрудники/пользователи) отвечают бизнес-аналитики и продакт-менеджеры, а за третий уровень (софт) – системные аналитики.

4. Критика расширенной модели Вигерса и предложение по классификации ограничений

Бесков также критикует более "развесистую" схему Вигерса, где появляются "business rules, quality attributes, external interfaces, constraints" и т.д., называя ее "запутанной картинкой с какими-то медузами". Он сравнивает ее с шуточной классификацией собак Борхеса, которая "не сбалансирована, неоднозначна".

Он утверждает, что правая часть требований у Вигерса (бизнес-правила, атрибуты качества, внешние интерфейсы, ограничения) на самом деле является различными видами ограничений (constraints) на способности (capabilities).

Бизнес-правила: описание логики бизнеса, часто включают ограничения (например, сроки).
Атрибуты качества: характеристика работы, опять же, ограничение на способность (например, пропускная способность).
Внешние интерфейсы: тоже ограничение на функцию (например, "отправляем заявки только со смартфона").

Предложенная полная модель Бескова (с учетом способностей и ограничений):

На каждом из трех уровней (Организация, Сотрудник/Пользователь, ПО/Софт) существуют:

Способности (Capabilities / Features): Что субъект может делать.
Ограничения (Constraints): Условия, при которых субъект действует, или параметры, ограничивающие его способности (например, скорость, качество, эргономика, надежность, объем данных). Эти ограничения могут быть макро- (платформа) или микро- (конкретная функция).

"У всех у них есть схожие свойства как у системы, поэтому можно применять очень похожие подходы... есть способности, у нас есть ограничения, которые можем отдельно продумывать, разрабатывать и трассировать на следующий уровень".

5. Применение на практике и рекомендации

Бизнес-требования:"Прокапывать целиком все необходимые внешние и внутренние бизнес-требования, которые есть в компании" (из законов, регламентов, соглашений, уставов, миссий).
Использовать ИИ для формализации этих требований из текстов законов и документов.
Полное покрытие бизнес-функций организации позволяет обеспечить трассировку к более низким уровням.
Пользовательские требования (к пользователям):Выдвигаются владельцами процессов, а не самими пользователями. Владелец процесса определяет, какими способностями должен обладать пользователь для выполнения работы.
В продуктовой разработке роль владельца процесса выполняет продакт-менеджер, который отвечает за успех продукта и определяет, какие возможности должны быть у клиентов.
Контроль качества и трассировка:Полный перечень бизнес-требований на верхнем уровне позволяет "достаточно хорошо делать трассировку" на нижние уровни. Если бизнес-требования проработаны качественно, то "будет описаны все бизнес-функции организации, что она делает", что облегчает выявление пользовательских задач и возможностей.
Унификация подходов:Поскольку все три уровня рассматриваются как системы (бизнес-система, человеко-машинная система, программно-аппаратная система), к ним применимы схожие подходы системного мышления.
Можно использовать общие чек-листы, а затем детализировать их для каждого уровня.

Финальные рекомендации:

Изучать стандарты по системной инженерии: "там очень много есть интересного прикольного".
Изучать Enterprise-архитектуру: Например, концепцию "Capability Map" (Карта способностей) в TOGAF и ArchiMate, которая не просто переименовывает функции, а является "очень важной штукой".
Быть системно последовательным: Применять системный подход к классификации требований.
Не бояться критиковать: "Опираться и на наработки профессионалов, и на фундаментальные стандарты, но в общем-то не бояться... обоснованно, аккуратно, вежливо, логично критиковать... и находить какие-то изъяны, предлагать какие-то улучшения".

6. Распределение зон ответственности (Системный аналитик, Бизнес-аналитик, Продукт-менеджер)

Первые два уровня (требования к бизнесу и требования к сотрудникам/пользователям): Это зона ответственности бизнес-аналитиков и продакт-менеджеров. Они определяют цели, мотивы организации и пользовательские задачи, которые должны быть решены.
Третий уровень (требования к ПО): Это зона ответственности системных аналитиков.
Бесков отмечает, что в России часто системные аналитики могут "залезать" в область бизнес-анализа (или даже архитектуры), но это скорее экономически обусловленная ситуация на рынке труда, чем идеальное разделение ролей. Он подчеркивает, что ему важнее "культура проектирования систем", а не жесткие рамки профессий.

Денис Бесков в целом призывает к более строгому, системному и лингвистически последовательному подходу к онтологии требований, основанному на принципах системной инженерии, для повышения качества и ясности работы с требованиями в IT-проектах.