Описание области проблем и области решений
Практика показывает, что требования часто формируются без привязки к реальным причинам их возникновения: решения принимаются исходя из субъективного видения конструктора, маркетолога или формулировок заказчика. В результате игнорируется анализ реальных проблем и потребностей, что приводит к неэффективным решениям, перегрузке проекта избыточными требованиями и росту затрат. В итоге даже полностью соответствующее требованиям изделие может не решать задачи пользователей и оказываться невостребованным.
Область проблем и область решений
Для четкого разделения проблемы и способа ее решения, в системной инженерии выделяют две области:
- Область проблем - какую проблему нам нужно решить (какую потребность нужно удовлетворить)
- Область решений - как именно мы будем решать эту проблему (как буде удовлетворять конкретную потребность)
Область Проблем (и описание этой области) — это первый и самый критически важный шаг в проектировании любой технической системы.
В рамках процессов жизненного цикла системы за определение области проблем и области решений отвечает процесс "Анализ бизнеса или назначения". Результатом этого процесса является:
- Описание проблем или возможностей
- Описание вариантов областей решений
- Определение и обоснование предпочтительного варианта решения
Пример:
- Область проблемы: «Нам тяжело и медленно перевозить грузы через реку, и мы зависим от парома».
- Описание вариантов решений:
- Построим капитальный мост
- Построим понтонный мост
- Создать грузовой дирижабль
- Прорыть тоннель
- Определение и обоснование предпочтительного варианта решения: построим понтонную переправу, так как мост нужен на время, это быстрее и дешевле других вариантов.
Определение области проблем и области решения является рекурсивным процессом, который может выполняться на каждом уровне системной декомпозиции
Так для заказчика, область проблем это проблема перевозки грузов через реку, а область решений - это строительство понтонного моста. А для проектировщиков областью проблемы является проектирование моста который должен работать в конкретной эксплуатирующей системе (течении реки, геология дна и берегов, погодные условия, характер перевозим грузов и характер транспортных средств), а областью решения является конкретный технический проект моста и проектная документация.
Для проектировщика сцепного механизма для звеньев моста, областью проблемы является необходимость надежного крепления звеньев моста между собой, а область решений конкретная конструкция крепления. Таким образом область решений одного уровня системной декомпозиции, создает область проблем для другого уровня.
Описание области решений более формализованный процесс чем описание области проблем. В качестве исходных данных к любому проекту, как правило выступает техническое задание, но в нем описывают не проблемы, а уже некую область решений, а описание проблем т(возможностей) можно просто отсутствовать.
Для чего нужно формально описывать Область проблем?
Ошибочно думать, что цель очевидна и всем понятна. Формальное описание области проблем решает несколько ключевых задач:
1. Чтобы решить ту самую проблему, необходимую заинтересованным сторонам, а не ее симптомы
Без четких границ проблемы команда может создать технически совершенное, но абсолютно бесполезное решение.
Описание проблемы помогает не упустить из вида основную цель создания технической системы.
2. Чтобы определить границы и контекст системы
Ни одна система не существует в вакууме. Описание Область проблемы помогает ответить на вопросы:
- С кем/чем система будет взаимодействовать? (внешние системы, пользователи, законодательство, окружающая среда).
- Каковы ограничения? (юридические, экологические, социальные, технические).
- Где заканчивается наша ответственность и начинается зона влияния других?
Это позволяет точно очертить операционную среду будущей системы.
3. Чтобы выявить все заинтересованные стороны и их скрытые потребности и проблемы
Область проблемы — это не только технологии, но и люди. Формальное описание заставляет выявить всех, кого затрагивает проблема и кого коснется решение:
- Прямые пользователи.
- Косвенные пользователи (например, администраторы, обслуживающий персонал).
- Заказчики, спонсоры, регуляторы.
Часто именно у заинтересованных сторон можно обнаружить невысказанные потребности (например, потребность в безопасности, престиже или простоте обучения), которые никогда не прозвучат в формальном техническом задании.
Понимание области проблем позволяет определить перечень заинтересованных сторон их потребностей и в конечном итоге сформировать полный и корректный набор требований к области решений.
Исходные требования заинтересованных сторон должны формулироваться для решения какой либо проблемы или удовлетворения какой либо потребности, а итоговое техническое задание, требует валидации относительно этих проблем и потребностей.
4. Чтобы сформулировать общее видение для команды
Область проблемы — это общая «карта территории» для всех участников проекта: заказчиков, менеджеров, системных инженеров, разработчиков. Она обеспечивает единое понимание того, ЗАЧЕМ мы вообще все это делаем. Это предотвращает ситуацию, когда программист думает, что создает одну систему, а инженер-механик проектирует для нее совсем другие интерфейсы.
5. Чтобы избежать «синдрома золотого молотка»
Это когнитивное искажение, когда у команды есть любимая технология («молоток»), и все проблемы они видят как «гвозди». Тщательное описание Область проблемы заставляет отвлечься от готовых решений и сосредоточиться на сути проблемы. Возможно, проблема решается не новым программным обеспечением, а изменением бизнес-процесса.
6. Чтобы заложить основу для верификации и валидации
В конце проекта мы должны ответить на два вопроса:
- Верификация: «Мы построили систему правильно?» (соответствует ли она ТЗ).
- Валидация: «Мы построили правильную систему?» (решает ли она исходную проблему).
Описание Область проблемы — это и есть эталон для валидации. Без него мы не сможем доказать, что наше блестящее техническое решение действительно кому-то нужно.
Описание области проблем в MBSE
В MBSE, область проблем формализуется в виде модели или совокупности моделей, например, с помощью языка SysML:
- Диаграмма вариантов использования (Use Case Diagram): Определяет, кто и какие цели преследует в системе.
- Диаграмма заинтересованных сторон: Фиксирует всех участников и их интересы.
- Диаграмма областей (Domain Diagram) или блочная диаграмма определения (BDD): Четко очерчивает границы Области проблемы и Области решения, показывая, какие внешние системы и субъекты окружают нашу будущую систему.
В методе ARCADIA (реализуемом инструментом ЛОЦМАН:PLM Архитектурное проектирование), для описания области проблем используется Анализ применения.
