Школа
системного анализа
и проектирования
системного анализа
и проектирования
Systems Education
Школа системного анализа
и проектирования
Школа системного анализа
и проектирования
Оглавление
Профессия «Системный аналитик информационных систем для бизнеса»
Автор: Денис Бесков
Это универсальное пособие для всех, кто связан с системным анализом: оно охватывает весь путь информационной системы — от идеи и требований до внедрения и развития. Новичкам книга подскажет, как войти в профессию; джуны поймут свою роль в проекте; мидлы смогут восполнить пробелы и увереннее вести переговоры; сеньоры сравнят свои подходы с альтернативными мнениями, а руководители отделов анализа получат обзор ключевых навыков, инструментов и актуальных трендов. По сути, это настольная книга, к которой стоит обращаться по мере возникновения новых задач и вопросов.
Автор: денис бесков
Профессия «Системный аналитик информационных систем для бизнеса»
Раздел II. Анализ информационных систем для бизнеса
Раздел II рассказывает, как именно системный аналитик «залезает под капот» будущей системы и превращает бизнес-идеи в чёткие требования и концептуальные схемы. При этом не нужно читать подряд все главы — достаточно открыть ту, которая к вам ближе по текущим задачам.
Скажем, в главе 9 вы узнаете, как «прочувствовать» бизнес: провести бизнес-анализ, смоделировать процессы и правильно оформить бизнес-требования.
В главе 10 речь пойдёт о надсистемном анализе: где заканчиваются границы системы и чем она взаимодействует «снаружи» (особенно полезно, когда вы запутались в окружении).
Глава 11 — «Ах, вот почему все ругают требования!» — покажет, что вы не один.
В 12-й главе анализируется, зачем нам моделирование «до уровня UML» и почему Domain-Driven Design спасает, когда UML-модели перестают быть полезными.
Если же вы застряли в вопросах интерфейсов или пользовательских сценариев, загляните в главу 13 — проектирование использования, UI/UX. Надо разобраться с концептуальным дизайном?
Глава 14 расскажет, как разложить систему на части ещё до детальной проработки.
И наконец, в 15-й главе — внутрисистемный анализ с разработкой функциональных требований, выявлением технических ограничений и критериев качества.
Возможные инсайты с Вашей стороны: «Подождите, то есть сценарии использования — не просто красивый текст, а инструмент для реального UX?» и «М-да, если бы мы если бы мы сделали концептуальное проектирование в прошлом проекте, не пришлось бы потом переделывать половину интеграций».
Скажем, в главе 9 вы узнаете, как «прочувствовать» бизнес: провести бизнес-анализ, смоделировать процессы и правильно оформить бизнес-требования.
В главе 10 речь пойдёт о надсистемном анализе: где заканчиваются границы системы и чем она взаимодействует «снаружи» (особенно полезно, когда вы запутались в окружении).
Глава 11 — «Ах, вот почему все ругают требования!» — покажет, что вы не один.
В 12-й главе анализируется, зачем нам моделирование «до уровня UML» и почему Domain-Driven Design спасает, когда UML-модели перестают быть полезными.
Если же вы застряли в вопросах интерфейсов или пользовательских сценариев, загляните в главу 13 — проектирование использования, UI/UX. Надо разобраться с концептуальным дизайном?
Глава 14 расскажет, как разложить систему на части ещё до детальной проработки.
И наконец, в 15-й главе — внутрисистемный анализ с разработкой функциональных требований, выявлением технических ограничений и критериев качества.
Возможные инсайты с Вашей стороны: «Подождите, то есть сценарии использования — не просто красивый текст, а инструмент для реального UX?» и «М-да, если бы мы если бы мы сделали концептуальное проектирование в прошлом проекте, не пришлось бы потом переделывать половину интеграций».
Глава 9. Бизнес-анализ, бизнес-моделирование и бизнес-проектирование
Важная часть работы системного аналитика — понимание сути бизнеса, для которого создаётся или совершенствуется информационная система. Без ясного представления о бизнес-процессах, стратегических целях и ключевых проблемах нельзя адекватно определить требования к системе. Именно поэтому в профессии СА тесно переплетены элементы бизнес-анализа, бизнес-моделирования и бизнес-проектирования.
В этой главе мы рассмотрим, как аналитик исследует и понимает бизнес, выявляет потребности и формирует бизнес-требования, а также как обосновывает и защищает концепцию решения.
В этой главе мы рассмотрим, как аналитик исследует и понимает бизнес, выявляет потребности и формирует бизнес-требования, а также как обосновывает и защищает концепцию решения.
9.1. Исследование и понимание бизнеса
Рис.9.1.1. — Этапы исследования бизнеса
Первый шаг в любом проекте автоматизации бизнеса — понять, что представляет собой организация (или рынок, если речь идёт о внешнем продукте), и какие у неё цели:
1. Изучение отрасли
2. Анализ стратегии и ключевых показателей
3. Сбор исходных данных
1. Изучение отрасли
- Каковы типичные процессы, регуляторные требования, тенденции в этой сфере?
- Кто основные конкуренты, какими технологиями они пользуются?
2. Анализ стратегии и ключевых показателей
- Какие высокоуровневые цели ставит топ-менеджмент? Рост выручки, выход на новые рынки, снижение издержек, повышение клиентской удовлетворённости?
- Какие KPI (ключевые показатели эффективности) отслеживаются?
3. Сбор исходных данных
- Изучение внутренней документации: отчёты, регламенты, инструкции.
- Проведение интервью с топ-менеджментом, руководителями отделов.
- Анализ метрик и статистических отчётов, если уже ведётся учёт показателей.
Задача системного аналитика здесь — составить общую картину: что из себя представляет бизнес, какие проблемы и возможности видит руководство, как новая или улучшенная система должна помочь достичь целей.
9.2. Моделирование процессов
Рис.9.2.1. — Этапы моделирования бизнес-процессов
Один из центральных инструментов бизнес-анализа — это описание и анализ бизнес-процессов. Процессы отражают, как организация производит продукт, оказывает услугу или выполняет внутренние функции (бухгалтерия, закупки, кадры).
Ключевые моменты при моделировании процессов
1. Выбор нотации
2. Сбор информации о шагах процесса
3. Поиск неэффективностей
4. Формирование текущей (AS-IS) и целевой (TO-BE) модели
Ключевые моменты при моделировании процессов
1. Выбор нотации
- BPMN (Business Process Model and Notation) — стандарт де-факто для визуализации процессов.
- UML Activity Diagram — упрощённый вариант, но тоже популярен в ИТ.
- EPC, IDEF0 — альтернативные методологии, применяемые в некоторых отраслях.
2. Сбор информации о шагах процесса
- Как начинается процесс, какие есть входные данные, кто (какая роль) отвечает за каждый шаг, какие документы или системы используются?
- Важно фиксировать реальные шаги, а не «как должно быть по инструкции». Часто реальность расходится с формальными регламентами.
3. Поиск неэффективностей
- «Узкие места»: стадии, где скапливаются запросы, большие задержки.
- Дублирование или ручной ввод данных, когда один и тот же блок информации вводят в разные системы.
- Излишние согласования, которые растягивают время выполнения процесса.
4. Формирование текущей (AS-IS) и целевой (TO-BE) модели
- Текущая модель показывает, как процесс устроен сейчас.
- Целевая модель описывает, как будет выглядеть процесс после внедрения изменений или новой ИС.
Результаты моделирования помогают определить, какие бизнес-процессы нужно автоматизировать или оптимизировать, и какая функциональность необходима в новой системе.
Рис.9.2.2. — Пример процесса утоления голода в нотации BPMN
Читайте наши статьи по теме:
9.3. Структурное моделирование бизнеса
Рис.9.3.1. — Структурное моделирование бизнеса
Помимо процессов, важно понимать организационную и информационную структуру бизнеса:
1. Оргструктура
2. Роли и иерархии
3. Анализ данных
4. Взаимосвязь бизнес-процессов
1. Оргструктура
- Какие подразделения (отделы, департаменты) существуют, как они связаны?
- Какие роли и зоны ответственности закреплены за каждым подразделением?
2. Роли и иерархии
- Кто принимает стратегические решения?
- Какова схема подчинения (линейная, матричная, проектная)?
3. Анализ данных
- Какие основные сущности (клиенты, заказы, товары, контракты)?
- Как данные хранятся и кто отвечает за их актуальность?
4. Взаимосвязь бизнес-процессов
- Один процесс может зависеть от результатов другого (например, оформление заказа зависит от статуса склада, финансов, согласования договора).
- Выявление «пересечений» процессов помогает понять, где нужна интеграция в рамках информационной системы.
Структурное моделирование даёт системному аналитику «карту» бизнеса, на которой видны ключевые объекты, их взаимосвязи и ответственные лица. Это особенно важно при сложных проектах, где задействованы несколько отделов и систем.
9.4. Выявление и моделирование потребностей
Рис.9.4.1. — Выявление и моделирование потребностей
Как только аналитик имеет общее представление о бизнесе и его процессах, наступает очередь выявления потребностей (Needs):
1. Выявление «болей»
2. Формулирование целей
3. Приоритизация
4. Моделирование потребностей
1. Выявление «болей»
- Где бизнес несёт наибольшие затраты или теряет клиентов из-за ручных процессов или задержек?
- Какие «узкие места» мешают компании масштабироваться или повышать качество?
2. Формулирование целей
- Цели могут быть количественными (сократить время обработки заказа на 30%, повысить конверсию с сайта на 15%) или качественными (улучшить удобство пользования системой для операторов колл-центра).
- Важно договариваться со стейкхолдерами о конкретных метриках, которые позволят понять, достигнута ли цель.
3. Приоритизация
- Потребности стоит распределять по степени важности и срочности.
- Варианты методик приоритизации: MoSCoW (Must, Should, Could, Won’t), Kano, Weighted Shortest Job First (SAFe) и т. п.
4. Моделирование потребностей
- Можно использовать Use Case (сценарии) или User Story (формат «Как [роль], я хочу [действие], чтобы [результат]»), дополняя их бизнес-контекстом.
- Создание Customer Journey Maps для понимания пути клиента или сотрудника при взаимодействии с системой.
9.5. Анализ бизнес-проблем
Рис.9.5.1. — Диаграмма Исикавы по анализу корневых причин неэффективности бизнес-процессов
Часто в ходе работы выясняется, что корень проблемы не всегда в отсутствии функционала. Возможно:
- Неверные KPI: компания измеряет показатели, которые искажают мотивацию сотрудников.
- Сложная оргструктура: слишком много «горизонтальных» или «вертикальных» согласований.
- Нехватка компетенций: сотрудники не умеют эффективно пользоваться существующими системами.
- Недостаточно данных для принятия решений (отсутствие аналитической надстройки над базовыми операциями).
Роль аналитика — обратить внимание на истинные причины, а не только на «симптомы». Иногда решение может заключаться вовсе не в новой информационной системе, а в изменении регламентов работы или обучении персонала.
9.6. Бизнес-требования
Рис.9.6.1. — Составные части бизнес-требований
Бизнес-требования — это высокоуровневые заявления о том, каких целей хочет достичь организация и какие ограничения существуют. Они задают «рамку» для будущего решения.
1. Формат бизнес-требований
2. Соответствие стратегии
3. Связь с финансами
1. Формат бизнес-требований
- Документ Vision & Scope (видение и границы проекта), где описываются ключевые цели, целевая аудитория, ключевые возможности и ограничения.
- Краткие «epic»-уровневые описания, которые далее декомпозируются в более детальные требования.
2. Соответствие стратегии
- Бизнес-требования должны согласовываться со стратегическими целями и принципами компании.
- Например, если стратегия — «максимально ориентироваться на клиента», то система должна обеспечивать быструю обратную связь, хранение истории взаимодействий и т. д.
3. Связь с финансами
- Часто в бизнес-требованиях присутствует указание на бюджет, ROI (окупаемость инвестиций), рентабельность или сроки выхода продукта на рынок.
- Эти финансовые аспекты тоже нужно учитывать при дальнейшей детализации.
Рис.9.6.2. — Пример дробного описания бизнес-требования
Читайте наши статьи по теме:
9.7. Экономический анализ и моделирование
Рис.9.7.1. — Оценка стоимости проекта
Крупные проекты требуют экономического обоснования. Системный аналитик вместе с бизнес-аналитиком или финансовым подразделением может участвовать в:
1. Оценке стоимости проекта
2. Расчёте выгод
3. Построении моделей ROI, TCO
4. Сценарном анализе
1. Оценке стоимости проекта
- Затраты на разработку/внедрение, инфраструктуру, лицензии, обучение персонала.
- Дополнительные скрытые затраты (сопротивление изменениям, временный спад производительности в период перехода и т. д.).
2. Расчёте выгод
- Сокращение времени цикла процессов, уменьшение ручного труда, снижение количества ошибок и возвратов.
- Увеличение конверсии продаж, повышение среднего чека, выход на новые рынки.
3. Построении моделей ROI, TCO
- ROI (Return on Investment) показывает, когда проект окупится и какую прибыль принесёт в перспективе.
- TCO (Total Cost of Ownership) учитывает полные затраты владения системой (включая поддержку, обновления, масштабирование).
4. Сценарном анализе
- Оптимистический, пессимистический и средний сценарии реализации.
- Учёт рисков (например, возможные задержки, изменение курса валют, уход ключевых сотрудников).
9.8. Постановка бизнес-целей и бизнес-ограничений проекта автоматизации
Рис.9.8.1. — Определение бизнес-целей и ограничений проекта автоматизации
На основе проведённого анализа формируются конкретные бизнес-цели (Business Objectives) и ограничения (Constraints) проекта автоматизации:
Пример целей и ограничений проекта:
1. Цели
2. Ограничения
У системного аналитика должно быть чёткое представление о том, как ограничение может влиять на архитектурные или процессные решения.
Пример целей и ограничений проекта:
1. Цели
- «Увеличить продажи в онлайн-магазине на 20% за год».
- «Сократить время выпуска финансового отчёта с двух недель до трёх дней».
- «Повысить удовлетворённость клиентов до N баллов по опросу NPS».
2. Ограничения
- Сроки (например, релиз к конкретной дате или событию).
- Бюджет (строгий лимит на разработку/лицензии).
- Регуляторика (соответствие стандартам безопасности, защите персональных данных).
- Технологические (необходимость использовать определённые платформы, совместимость с существующими системами).
У системного аналитика должно быть чёткое представление о том, как ограничение может влиять на архитектурные или процессные решения.
9.9. Разработка вариантов решения бизнес-задачи
Рис.9.9.1. — Подходы к внедрению программного обеспечения
После того как определены потребности, цели и ограничения, следует рассмотреть возможные варианты решения. Это может быть:
1. Закупка готового продукта (COTS — Commercial Off-The-Shelf)
2. Доработка существующего ПО
3. Разработка с нуля
4. Комбинированный подход
1. Закупка готового продукта (COTS — Commercial Off-The-Shelf)
- Например, известная ERP-система или CRM-платформа.
- Плюсы: проверенный функционал, поддержка производителя, быстрее «с нуля». Минусы: может потребоваться сложная кастомизация, дорогостоящие лицензии.
2. Доработка существующего ПО
- Если в компании уже есть система, которая покрывает часть потребностей, возможно, выгоднее расширить её функционал.
- Важно понять, не превысит ли стоимость доработок и поддержания технического долга выгоду от такого решения.
3. Разработка с нуля
- Полная свобода проектирования под нужды бизнеса.
- Однако более длинные сроки и риски, требующие высокой компетенции команды разработки.
4. Комбинированный подход
- Например, использовать готовую платформу, но интегрировать её с внутренними модулями и микросервисами для специфических задач.
9.10. Оценка, сравнение и выбор вариантов решения бизнес-задачи
Рис.9.10.1. — Выбор вариантов решения
Для того чтобы выбрать оптимальный вариант, аналитик вместе со стейкхолдерами проводит сравнение альтернатив:
1. Критерии оценки
2. Методы сравнения
3. Принятие решения
1. Критерии оценки
- Финансовые: стоимость, ROI, срок окупаемости.
- Технологические: соответствие IT-ландшафту, масштабируемость, надёжность.
- Организационные: сложность внедрения, обучаемость сотрудников, поддержка менеджмента.
- Сроки и риски.
2. Методы сравнения
- Табличное сравнение (matrix), где каждая альтернатива оценивается по ряду параметров.
- Взвешенное голосование (Weighted Scoring), когда каждому критерию присваивается «вес», а затем суммарный балл указывает на предпочтительный вариант.
3. Принятие решения
- Итоги сравнения презентуются руководству, ключевым заказчикам.
- Иногда решение принимается коллегиально, иногда — единолично спонсором проекта.
- Важно документировать, почему выбран один путь и отклонён другой.
9.11. Обоснование, оформление и защита концепции решения
Рис.9.10.1. — Подготовка и защита концепции решения
Когда вариант решения выбран, системный аналитик готовит концепцию решения (Solution Concept), которая служит базой для дальнейших этапов — детального проектирования, технической реализации:
1. Содержание концепции
2. Формат защиты
3. Фиксация решений
1. Содержание концепции
- Описание бизнес-проблемы, которую решаем.
- Бизнес-цели и ограничения.
- Краткое описание целевых бизнес-процессов (TO-BE).
- Выбранный вариант решения и его основные характеристики (архитектура, ключевой функционал).
- Ожидаемые выгоды и метрики успеха.
2. Формат защиты
- Презентация концепции стейкхолдерам (менеджмент, ключевые пользователи, спонсоры, технические специалисты).
- Ответы на вопросы и возражения, демонстрация макетов или пилотного прототипа.
- Согласование плана реализации: сроки, бюджет, этапы, возможные риски и резервы.
3. Фиксация решений
- Протокол совещания, утверждённый документ Vision & Scope, решение совета директоров (в зависимости от масштаба и культуры компании).
- Все заинтересованные стороны должны иметь доступ к финальным материалам и понимать, какие компромиссы были заложены.
Вывод по главе 9
Рис.9.10.2. — Процесс бизнес-анализа
Бизнес-анализ, бизнес-моделирование и бизнес-проектирование — это фундамент, на котором строится дальнейшая работа по созданию или улучшению информационной системы. Системный аналитик в этой области:
Грамотное выполнение всех этих этапов позволяет убедиться, что создаваемая система действительно будет иметь бизнес-смысл, принесёт ощутимую пользу организации и впишется в её долгосрочные планы.
- Исследует и понимает бизнес, его цели, процессы, проблемы и ограничения.
- Выявляет и описывает потребности, формирует бизнес-требования.
- Моделирует текущие и целевые процессы, структуру данных и организацию.
- Оценивает варианты решений с точки зрения экономики, технологии и стратегических задач.
- Оформляет и защищает концепцию решения перед руководством и стейкхолдерами, обосновывая её ценность и реализуемость.
Грамотное выполнение всех этих этапов позволяет убедиться, что создаваемая система действительно будет иметь бизнес-смысл, принесёт ощутимую пользу организации и впишется в её долгосрочные планы.
Глава 10. Надсистемный анализ и проектирование
Когда мы говорим о проектировании информационной системы, важно учитывать не только её внутреннюю структуру и логику, но и то, какое у неё окружение, как она встраивается в общую архитектуру и взаимодействует с внешними системами или процессами. Понимание границ системы, а также моделирование её взаимодействий «снаружи», не вдаваясь в детали внутренней реализации, помогает получить целостную картину, избежать дублирования функций и выявить потенциальные конфликты или пробелы.
В этой главе мы рассмотрим инструменты «надсистемного» анализа, позволяющие взглянуть на проектируемую систему с более высокого уровня: определить границы, описать окружение и смоделировать «чёрный ящик» системы.
В этой главе мы рассмотрим инструменты «надсистемного» анализа, позволяющие взглянуть на проектируемую систему с более высокого уровня: определить границы, описать окружение и смоделировать «чёрный ящик» системы.
10.1. Выделение границ системы
Рис.10.1.1. — Определение границ системы
Первый шаг к любому архитектурному проектированию — понять, что включается в создаваемую систему, а что остаётся вне её рамок. Это помогает расставить приоритеты и избежать «раздувания» функционала.
1. Определение области ответственности
2. Связь с бизнес-целями
3. Учет интеграций
4. Документирование границ
1. Определение области ответственности
- Системный аналитик и стейкхолдеры совместно решают, какие процессы система должна покрывать.
- Какие данные, функции и модули будут внутри, а что будет вынесено наружу (внешние сервисы, ручные процедуры, смежные системы).
2. Связь с бизнес-целями
- Границы должны соответствовать бизнес-требованиям и бюджету: нет смысла включать слишком много функций, которые не критичны для основных целей.
- Лучше сконцентрироваться на реальных «болях» и «узких местах», которые система призвана устранить.
3. Учет интеграций
- Если часть функционала уже реализована во внешней системе (например, система бухгалтерского учёта), возможно, есть смысл оставить её «за границами» и лишь наладить обмен данными.
- Это сохраняет ресурсы и снижает риск дублирования.
4. Документирование границ
- Часто границы фиксируют в виде контекстной диаграммы (Context Diagram) или в разделе «Scope» спецификации.
- Важно, чтобы все стейкхолдеры понимали и соглашались, где заканчивается зона ответственности проектируемой системы.
10.2. Описание окружения системы
Рис.10.2.1. — Описание окружения системы
После того, как границы определены, системный аналитик описывает окружение, то есть внешние объекты, с которыми система будет взаимодействовать.
1. Внешние системы
2. Пользователи и роли
3. Внешние события и триггеры
4. Инфраструктурные ограничения
1. Внешние системы
- Это может быть ERP, CRM, платёжные сервисы, государственные порталы и т. д.
- Нужно описать, какие данные туда передаются и какие данные получаются.
- Уточнить форматы, протоколы и регламенты взаимодействия (например, REST API, SOAP, файлы, очереди сообщений).
2. Пользователи и роли
- Часто к окружению относят и человеческих пользователей, которые взаимодействуют с системой через интерфейс.
- Важно определить роли (администратор, оператор, менеджер, клиент) и каналы доступа (веб, мобильное приложение, терминал).
3. Внешние события и триггеры
- Иногда систему запускают внешние события (пришёл запрос от смежного сервиса, пользователь нажал на кнопку, наступила определённая дата по расписанию).
- Система может реагировать на эти события, обрабатывать их и возвращать результат.
4. Инфраструктурные ограничения
- Какие сетевые, аппаратные или облачные окружения будут задействованы.
- Нужно понимать, есть ли особые требования к безопасности, пропускной способности, доступности (SLA), резервированию.
Описание окружения помогает заранее увидеть точки интеграции и понять, какие требования к надёжности, скорости и формату данных нужно учитывать на уровне архитектуры.
10.3. Моделирование «чёрного ящика»
Рис. 10.3.1. — Модель чёрного ящика в системном анализе
Модель «чёрного ящика» показывает систему как единый блок со входами и выходами, не раскрывая при этом её внутреннее устройство. Такой подход полезен, чтобы стейкхолдеры и аналитики:
1. Сосредоточились на внешнем поведении
2. Упростили общение с бизнесом
3. Легче управляли границами
4. Облегчили переход к детальному проектированию
Пример использования
1. Сосредоточились на внешнем поведении
- Что система принимает на вход (данные, команды, запросы) и что отдаёт на выход (результаты, ответы, сообщения)?
- Не нужно обсуждать внутренние алгоритмы на этом этапе — важно согласовать интерфейсы и логику взаимодействия.
2. Упростили общение с бизнесом
- Бизнес-пользователям не всегда интересно, какова структура БД или из чего состоит API. Им важно, какие функции выполняет система и какие результаты они могут получить.
- Модель «чёрного ящика» даёт им понятную диаграмму, где видно, какие внешние факторы влияют на систему и какие выгоды (outputs) она генерирует.
3. Легче управляли границами
- Если мы решим, что некий функционал (например, формирование отчётов) находится внутри системы, то он будет отображён как часть «чёрного ящика».
- Если же этот функционал реализуется внешним сервисом, значит, на диаграмме «чёрный ящик» будет иметь соответствующий вход/выход к этому сервису.
4. Облегчили переход к детальному проектированию
- Когда команда согласует «чёрный ящик», уже понятны ключевые входные и выходные потоки.
- Далее можно «раскрывать» систему изнутри: как устроены модули, классы, базы данных, алгоритмы.
Пример использования
- Нарисуйте прямоугольник, обозначающий систему.
- Вокруг него расположите «акторы» (внешних пользователей, системы) и отразите стрелками, какие данные или команды поступают внутрь, и что возвращается наружу.
- Это может быть как простая схема (2–3 стрелки и пара акторов), так и более детальная (множество интеграционных точек, различные роли).
Вывод по главе 10
Понимание границ системы, а также моделирование её взаимодействий «снаружи», не вдаваясь в детали внутренней реализации, помогает получить целостную картину, избежать дублирования функций и выявить потенциальные конфликты или пробелы.
Надсистемный анализ и проектирование — это важный этап, позволяющий системному аналитику и команде:
- Определить, что включается в будущую систему, а что остаётся за её границами (scope).
- Описать окружение, выделив все внешние системы и пользователей, с которыми придётся взаимодействовать.
- Смоделировать «чёрный ящик», фиксируя основные входы, выходы и поведение системы «снаружи» без детализации внутренней структуры.
Глава 11. Инженерия требований и её кризис
Инженерия требований (Requirements Engineering) — это дисциплина, которая исследует, каким образом правильно определять, документировать и согласовывать требования к будущей системе. Сюда же относится управление изменениями требований на протяжении всего жизненного цикла проекта. Казалось бы, тема хорошо изучена: существуют методологии, стандарты, рекомендации. Однако на практике именно требования часто становятся «ахиллесовой пятой» проектов. Несогласованные или неполные требования приводят к конфликтам, срывам сроков, перерасходу бюджета и, в итоге, к недовольству заказчиков.
В данной главе мы рассмотрим основные положения инженерии требований, разницу между бизнес-требованиями и «пользовательскими», а также обсудим, почему в реальности «всё не так гладко», как описано в учебниках, и какую научную критику предъявляют к классической парадигме требований, в частности Paul Ralph.
В данной главе мы рассмотрим основные положения инженерии требований, разницу между бизнес-требованиями и «пользовательскими», а также обсудим, почему в реальности «всё не так гладко», как описано в учебниках, и какую научную критику предъявляют к классической парадигме требований, в частности Paul Ralph.
11.1. Основные положения инженерии требований
Рис. 11.1.1. — Модель чёрного ящика в системном анализе
В классическом понимании инженерия требований состоит из следующих этапов:
1. Сбор (elicitation)
2. Анализ
3. Документирование (specification)
4. Валидация и согласование
5. Управление изменениями (change management)
В идеальном мире, когда все эти шаги выполняются корректно, проект должен получить чёткое, полное и реалистичное описание того, что и как нужно реализовать. На практике же возникает множество сложностей: требования могут постоянно меняться, заказчики не всегда знают, чего хотят, а разработчики — не всегда понимают язык бизнеса.
1. Сбор (elicitation)
- Определение источников (стейкхолдеры, документы, законы и стандарты).
- Проведение интервью, воркшопов, анкетирования, анализа существующих систем.
2. Анализ
- Уточнение и приоритизация полученной информации.
- Проверка на противоречивость, полноту, реалистичность.
3. Документирование (specification)
- Формальное или полуформальное описание требований.
- Использование различных форматов: User Stories, Use Cases, SRS (Software Requirements Specification), диаграммы (UML, BPMN), прототипы интерфейсов.
4. Валидация и согласование
- Проверка требований вместе с бизнес-заказчиками, пользователями, командой разработки и другими стейкхолдерами.
- Утверждение окончательного списка требований (baseline).
5. Управление изменениями (change management)
- Отслеживание версий и истории правок.
- Оценка влияния новых или изменённых требований на сроки, бюджет, архитектуру.
- Согласование изменений со стейкхолдерами.
В идеальном мире, когда все эти шаги выполняются корректно, проект должен получить чёткое, полное и реалистичное описание того, что и как нужно реализовать. На практике же возникает множество сложностей: требования могут постоянно меняться, заказчики не всегда знают, чего хотят, а разработчики — не всегда понимают язык бизнеса.
11.2. Бизнес-требования в проектах автоматизации
Рис. 11.2.1. — Классификация бизнес-требований
В контексте проектов автоматизации бизнес-требования проекта обычно отражают стратегические цели и ценность для организации, ради которых запускается проект. Обычно они сформулированы на высоком уровне абстракции:
Бизнес-требования отвечают на вопрос: зачем компании нужна та или иная система или её доработка? Они могут описываться в документах типа Vision & Scope, где говорится о том, какие выгоды проект должен принести и какие существуют ограничения (бюджет, сроки, ресурсы).
Для системного аналитика бизнес-требования служат «северной звездой»: приоритеты и смысл любой дорабатываемой функции должны вытекать из них.
NB: Стоит отметить, что бизнес-требования существуют не только для проекта, но и для организации — например, общие требования к организации, требования к отдельным подразделениям, процессам и бизнес-ролям. Такие бизнес-требования выявляются, создаются и развиваются не в проектах автоматизации, а в проектах организационного развития в целом:
- Повысить продажи на 20% за год.
- Сократить время обработки заявок с двух дней до четырёх часов.
- Улучшить качество обслуживания клиентов (увеличить NPS до 70).
- Соблюдать новые нормы законодательства (например, GDPR, стандарты бухучёта).
Бизнес-требования отвечают на вопрос: зачем компании нужна та или иная система или её доработка? Они могут описываться в документах типа Vision & Scope, где говорится о том, какие выгоды проект должен принести и какие существуют ограничения (бюджет, сроки, ресурсы).
Для системного аналитика бизнес-требования служат «северной звездой»: приоритеты и смысл любой дорабатываемой функции должны вытекать из них.
NB: Стоит отметить, что бизнес-требования существуют не только для проекта, но и для организации — например, общие требования к организации, требования к отдельным подразделениям, процессам и бизнес-ролям. Такие бизнес-требования выявляются, создаются и развиваются не в проектах автоматизации, а в проектах организационного развития в целом:
- Организация должна оказывать услуги доставки частным лицам
- Организация должна сдавать налоговую отчётность
- Организация должна обеспечивать проекты необходимым количеством персонала
- и т.д.
11.3. «Пользовательские» требования
Рис. 11.3.1. — Цели разработки бизнес-требований и пользовательских требований
Очень часто считают, что «пользовательские» требования (user requirements) описывают, что конкретно хотят конечные пользователи или заинтересованные группы (stakeholders) от системы.
Однако я придерживаюсь позиции, что user requirements по аналогии с software requirements (требования к ПО) лучше переводить как «требования К пользователям», в том смысле, что организации нужно, чтобы её сотрудники могли выполнить какие-то задачи с помощью создаваемой информационной системы, а в случае создания сервиса, а не системы — свои задачи могли выполнить её клиенты и партнёры.
И в случае сотрудников их рабочие интересы определяются бизнес-процессами, технологией деятельности и бизнесом в целом, а не сами по себе. Кроме того, только организация имеет бюджет и полномочия что-то требовать и заказывать, а сотрудники, клиенты и партнёры могут требовать только того, что есть в законах и заключённых ими договорах (трудоустройства, оферты, покупки, аренды и т.д.)
Если бизнес-требование формулируется на уровне показателей и выгоды для бизнеса, то пользовательские — на уровне задач сотрудников и необходимого им функционала и сценариев:
1. User Stories
2. Use Cases (сценарии использования)
3. Формальные требования
Почему важно отделять бизнес-требования от пользовательских?
Однако я придерживаюсь позиции, что user requirements по аналогии с software requirements (требования к ПО) лучше переводить как «требования К пользователям», в том смысле, что организации нужно, чтобы её сотрудники могли выполнить какие-то задачи с помощью создаваемой информационной системы, а в случае создания сервиса, а не системы — свои задачи могли выполнить её клиенты и партнёры.
И в случае сотрудников их рабочие интересы определяются бизнес-процессами, технологией деятельности и бизнесом в целом, а не сами по себе. Кроме того, только организация имеет бюджет и полномочия что-то требовать и заказывать, а сотрудники, клиенты и партнёры могут требовать только того, что есть в законах и заключённых ими договорах (трудоустройства, оферты, покупки, аренды и т.д.)
Если бизнес-требование формулируется на уровне показателей и выгоды для бизнеса, то пользовательские — на уровне задач сотрудников и необходимого им функционала и сценариев:
1. User Stories
- Формат: «Как [роль пользователя], я хочу [действие], чтобы [бизнес-ценность или результат]».
- Пример: «Как менеджер по продажам, я хочу иметь возможность создавать персонализированные коммерческие предложения из CRM в один клик, чтобы сократить время подготовки документа».
2. Use Cases (сценарии использования)
- Более формальное описание: актор, прецедент (взаимодействие), потоки событий, альтернативные ветки.
- Пример: «Прецедент: «Сформировать коммерческое предложение». Основной поток: (1) Пользователь открывает карточку клиента, (2) нажимает «Создать КП», (3) система подтягивает реквизиты…»
3. Формальные требования
- Список пунктов, структурированных по шаблону: «Требование №, Описание, Приоритет, Критерий приёмки».
- Удобно, если нужна детальная спецификация (например, для Fixed Price контрактов или сложных интеграций).
Почему важно отделять бизнес-требования от пользовательских?
- Бизнес-требования позволяют держать фокус на ценности, которую получит организация.
- Пользовательские требования помогают понять, как именно эта ценность достигается через конкретные функции системы.
- Когда они противоречат друг другу, нужно возвращаться к целям проекта и искать компромисс (например, не все пожелания пользователей могут быть целесообразны с точки зрения ROI).
Читайте наши статьи по теме:
11.4. Трассировка требований
Рис. 11.4.1. — Связь требований
Трассировка (traceability) — это связь между различными уровнями и видами требований, а также между требованиями и другими артефактами проекта (тест-кейсами, задачами разработки, архитектурными решениями).
1. Зачем нужна трассировка?
2. Инструменты
3. Уровни трассировки
1. Зачем нужна трассировка?
- Для того чтобы убедиться, что каждое требование имеет корреляцию с бизнес-целями и не появляется «само по себе».
- Для того чтобы в процессе разработки и тестирования не терять из виду ни одного важного требования.
- Для того чтобы понимать влияние изменений: если меняется бизнес-требование, какие пользовательские требования (и какой код) придётся переписывать?
2. Инструменты
- Системы управления требованиями (Jama, Polarion, Rational DOORS).
- Создание таблиц трассировки в Excel или Confluence, где каждому требованию присваивается уникальный идентификатор и указываются связанные элементы.
3. Уровни трассировки
- Бизнес-требования ↔ Пользовательские требования ↔ Системные требования.
- Требования ↔ Тестовые сценарии.
- Требования ↔ Архитектурные компоненты (или задачи разработки).
11.5. Качество требований
Рис. 11.5.1. — Обеспечение качественных требований
Требования считаются качественными, если они отвечают ряду критериев:
1. Полнота
2. Однозначность
3. Проверяемость
4. Согласованность
5. Реализуемость
6. Необходимость и ценность
1. Полнота
- Достаточны для понимания того, что нужно делать; не пропущены критические аспекты.
- Необязательно, что все мелкие детали зафиксированы в начале проекта, но крупные области должны быть отражены.
2. Однозначность
- Исключение двусмысленных формулировок («быстро», «удобно», «безопасно» — это всё субъективно, лучше указывать конкретные параметры).
- Избегание терминов, которые могут трактоваться по-разному.
3. Проверяемость
- Можно ли объективно проверить, выполнено требование или нет (есть чёткие критерии приёмки)?
- «Время отклика не более 2 секунд при 100 одновременных пользователях» проверяемо, а «система должна работать быстро» — нет.
4. Согласованность
- Нет внутренних противоречий (одно требование не говорит «Отправлять отчёт по email каждый день», а другое — «Отправлять отчёт по email один раз в месяц»).
- Термины и названия сущностей используются единообразно.
5. Реализуемость
- Учитываются реальные технические, ресурсные, временные ограничения.
- Если требование «обрабатывать миллион транзакций в секунду», нужно убедиться, что инфраструктура и бюджет позволяют.
6. Необходимость и ценность
- Требование должно приносить бизнес-пользу или быть обусловленным регуляторными нормами, а не просто «хотелкой».
11.6. Что не так с требованиями: повседневная практика и научная критика
Рис. 11.6.1. — Как лучше подходить к управлению требованиями в проектах ИТ?
Несмотря на обилие методик и инструментов, «кризис требований» остаётся распространённой проблемой. Почему?
1. Заказчики не знают, чего хотят
2. Слишком формальная документация
3. Чрезмерная гибкость (Agile-заблуждение)
4. Отсутствие управления изменениями
5. Недостаток взаимодействия бизнеса и IT
Научная критика от Paul Ralph
Учёный-исследователь в области программной инженерии и проектирования, Paul Ralph, в ряде своих работ указывает, что концепция «требований» может быть слишком упрощённой и даже иллюзорной по своей природе. Ниже ключевые тезисы его критики:
1. Проектирование как творческая деятельность
2. Размытая грань между «требованиями» и «решениями»
3. «Requirements» vs. «Desiderata»
4. Комплексный и эволюционный характер
1. Заказчики не знают, чего хотят
- Часто бизнес понимает проблему, но не всегда ясно представляет, какое именно решение поможет.
- Когда «видение» туманно, формулировать чёткие требования сложно, они могут постоянно меняться.
2. Слишком формальная документация
- Некоторые команды тратят много времени на создание громоздких документов (сотни страниц), которые никто толком не читает.
- В итоге фактические требования «живут» в устных обсуждениях и чатах, а документ быстро устаревает.
3. Чрезмерная гибкость (Agile-заблуждение)
- Есть мнение, что в Agile можно вообще не писать требования и «просто общаться».
- На практике без хотя бы минимальной фиксации (user stories, acceptance criteria) команда начинает путаться, что и как делать.
4. Отсутствие управления изменениями
- Требования меняются в ходе проекта, это нормально. Но если нет процесса согласования и оценки влияния, команда оказывается в хаосе.
- Сроки срываются, бюджет растёт, разработчики устают от постоянных переделок.
5. Недостаток взаимодействия бизнеса и IT
- Если аналитик «отрывается» от бизнеса и не получает регулярный фидбэк от пользователей, требования могут уйти в неверном направлении.
- Нужны постоянные встречи, ревью, демо, чтобы поддерживать «живой» контакт.
Научная критика от Paul Ralph
Учёный-исследователь в области программной инженерии и проектирования, Paul Ralph, в ряде своих работ указывает, что концепция «требований» может быть слишком упрощённой и даже иллюзорной по своей природе. Ниже ключевые тезисы его критики:
1. Проектирование как творческая деятельность
- Ralph утверждает, что процесс создания ПО — это не просто сбор уже «готовых» требований, а творческое проектирование (design). Требования не всегда «открываются», а зачастую создаются и эволюционируют параллельно с архитектурой и дизайном.
2. Размытая грань между «требованиями» и «решениями»
- С традиционной точки зрения, мы сначала собираем требования (что нужно), а потом предлагаем решение (как это сделать).
- По мнению Ralph, в реальных проектах «что» и «как» смешиваются с самого начала: заказчики могут предлагать готовое техническое решение, а команда может формировать «требования», исходя из своих идей о дизайне.
3. «Requirements» vs. «Desiderata»
- Ralph предлагает заменять привычные «requirements» более гибким термином — «desiderata» (от лат. «желаемое»), указывая, что в проектном процессе мы имеем дело не столько с жёсткими требованиями, сколько с списком пожеланий, приоритетов и компромиссов.
- Список desiderata может меняться и подлежит переосмыслению, когда появляются новые технологические возможности или меняются бизнес-условия.
4. Комплексный и эволюционный характер
- Современные IT-проекты живут в условиях высокой неопределённости. Бизнес может менять стратегию, рынок может диктовать новые требования к скорости разработки.
- По мнению Ralph, классическая инженерия требований, которая подразумевает стабильный набор «неизменных» входных данных, неадекватно описывает реальность в условиях постоянных изменений.
Таким образом, научная критика (в частности, от Paul Ralph) ставит под сомнение идею, что требования — это фиксированный список того, что «объективно» нужно пользователям и бизнесу. Скорее, требование в реальном проекте — это подвижная цель, которая формируется на стыке идей, технологических ограничений, креативных решений и эволюционирующего понимания задачи.
Вывод по главе 11
Рис. 11.6.2. — Балансировка гибкости и структуры в инженерии требований
Инженерия требований по-прежнему является одной из самых сложных и ответственных частей IT-проекта. Несмотря на то что существует множество методик и стандартов, на практике именно работа с требованиями часто приводит к кризисам: меняются запросы бизнеса, заказчик не всегда знает, чего хочет, а команда разработки не успевает подстраиваться под новые условия. Это порождает путаницу, перерасход бюджета и нарушение сроков.
При этом, как подчёркивает научная критика (например, позиция Paul Ralph), требования – это не статичный список, который можно выявить один раз и навсегда; они скорее «desiderata» (пожелания, совместно формируемые бизнесом и командой), которые эволюционируют вместе с пониманием задачи. Системному аналитику нужно постоянно балансировать между формальной стороной (документация, спецификации, трассировка) и живым процессом проектирования, где «что» и «как» тесно переплетены.
Таким образом, грамотный системный аналитик:
При этом, как подчёркивает научная критика (например, позиция Paul Ralph), требования – это не статичный список, который можно выявить один раз и навсегда; они скорее «desiderata» (пожелания, совместно формируемые бизнесом и командой), которые эволюционируют вместе с пониманием задачи. Системному аналитику нужно постоянно балансировать между формальной стороной (документация, спецификации, трассировка) и живым процессом проектирования, где «что» и «как» тесно переплетены.
Таким образом, грамотный системный аналитик:
- Не ограничивается формальной фиксацией требований, а понимает их как подвижный ориентир, требующий регулярного пересмотра.
- Активно сотрудничает со стейкхолдерами, чтобы корректировать приоритеты по мере развития проекта и появления новых данных.
- Использует инструменты трассировки и управления изменениями (сколько бы их ни было) не ради бюрократии, а ради прозрачности и контроля качества.
- Учитывает, что споры о «полноте» требований часто упираются в более глубокие вопросы: бизнес может не до конца осознавать свои нужды, а команда – испытывать дефицит времени и ресурсов.
Таким образом, современный системный аналитик должен владеть не только теорией инженерии требований, но и мягкими навыками коммуникации, фасилитации и быстрой адаптации к изменениям, а также осознавать, что «требования» нередко рождаются из диалога, компромисса и креатива.
Глава 12. Моделе-ориентированное проектирование и его кризис
В процессе анализа и проектирования информационных систем аналитики и архитекторы часто используют различные виды моделей: диаграммы, схемы, описания на формальном языке (UML, BPMN и др.). Идея «моделе-ориентированного проектирования» (Model-Driven Design / Model-Driven Engineering) предполагает, что такие модели могут стать основой для автоматической (или полуавтоматической) генерации исходного кода и максимально облегчат процесс разработки.
Однако история массового применения UML и других формальных нотаций показывает, что практика далеко не всегда оправдывает теорию. В этой главе мы рассмотрим, почему модель-ориентированное проектирование изначально казалось «серебряной пулей», и почему в реальности оно пережило определённый кризис. Кроме того, мы поговорим о концепции Domain-Driven Design (DDD), которая стала ответом на чрезмерное увлечение формальными моделями в отрыве от реального бизнеса.
Однако история массового применения UML и других формальных нотаций показывает, что практика далеко не всегда оправдывает теорию. В этой главе мы рассмотрим, почему модель-ориентированное проектирование изначально казалось «серебряной пулей», и почему в реальности оно пережило определённый кризис. Кроме того, мы поговорим о концепции Domain-Driven Design (DDD), которая стала ответом на чрезмерное увлечение формальными моделями в отрыве от реального бизнеса.
12.1. Взлёт и падение UML
Рис. 12.1.1. — Нотация UML для моделирования систем
UML (Unified Modeling Language) в конце 1990-х — начале 2000-х годов позиционировался как универсальный язык для визуального моделирования систем. Предполагалось, что разработчики, аналитики и архитекторы смогут:
Почему UML стал популярным
«Падение» UML и кризис формальных моделей
Со временем обнаружилось, что создание детализированных UML-моделей для всего проекта требует колоссальных ресурсов и почти не даёт экономии в написании кода.
- Единообразно описывать структуру, поведение и взаимодействие компонентов системы, используя множество типов диаграмм (Class, Sequence, Use Case, Activity и т. д.).
- Автоматизировать часть разработки, преобразуя UML-модель в готовый каркас кода (Model-Driven Architecture, MDA).
- Улучшить коммуникацию между бизнесом и IT, так как диаграммы должны быть понятны «не-техническим» стейкхолдерам.
Почему UML стал популярным
- Стандартизированный подход: до UML существовало множество разрозненных методологий (OMT, Booch, Jacobson). UML объединил лучшие идеи под эгидой OMG (Object Management Group).
- Богатый набор диаграмм: позволял формализовать практически любой аспект системы (от требований и процессов до программных классов и развёртывания).
- Поддержка в инструментах: начали появляться популярные средства (Rational Rose, Enterprise Architect, Visual Paradigm), позволяющие рисовать диаграммы и генерировать код.
«Падение» UML и кризис формальных моделей
Со временем обнаружилось, что создание детализированных UML-моделей для всего проекта требует колоссальных ресурсов и почти не даёт экономии в написании кода.
- Сложность актуализации: при изменении требования или архитектуры нужно было править множество диаграмм, иначе модель «стареет» и перестаёт отражать действительность.
- Избыточность: многие команды сочли, что для уточнения логики им достаточно пары «легковесных» диаграмм (например, Sequence или BPMN) и простого описания, чем вести полный UML-пакет, который почти никто не читает.
- Недостаток инструментальной поддержки на практике: автоматическая генерация качественного кода из UML-моделей (и обратно) оказалась менее популярной, чем думали изначально; большинство проектов предпочитали писать код «вручную» и делать документацию «под код».
В результате UML остался актуальным и полезным в выборе отдельных диаграмм, но всё меньше компаний пытаются моделировать все аспекты системы «до уровня кнопки». Формальная модель перестала рассматриваться как универсальная основа, а стала лишь инструментом, помогающим при сложных сценариях или архитектурных вопросах.
12.2. Domain-Driven Design
Рис. 12.2.1. — Проектирование, ориентированное на домен (DDD)
На рубеже 2000-х появился подход Domain-Driven Design (DDD), предложенный Эриком Эвансом. Он сосредоточен на том, чтобы:
- Глубже понять предметную область (домен), а не механически рисовать UML-диаграммы.
- Создать единый язык (Ubiquitous Language), которым пользуются и разработчики, и бизнес-эксперты.
- Сосредоточиться на модели домена, отражающей сущности, агрегаты, значения, а не распыляться на все аспекты кода или инфраструктуры.
- Общая терминология (Ubiquitous Language): все участники проекта (аналитики, архитекторы, бизнес) договариваются об одинаковых названиях сущностей, процессов и атрибутов.
- Bounded Context: крупный бизнес-домен делится на отдельные «контексты», где термины имеют точное значение, и эти контексты «стыкуются» друг с другом при помощи чётко определённых моделей интеграции.
- Модель предметной области: в центре внимания — бизнес-правила, которые кодируются в ядре приложения (Core Domain). Важна правильная проектировка сущностей, сервисов, репозиториев, чтобы они точно отражали бизнес-логику.
- Фокус на смысл, а не на формальную нотацию: DDD позволяет выбрать любые диаграммы или вовсе обойтись без них, если все участники понимают язык домена.
- Гибкость и итеративность: модель домена может эволюционировать вместе с бизнес-пониманием. Это соответствует Agile-принципам, где изменения являются нормой.
- Прикладное применение: DDD концентрируется на том, чтобы код действительно отражал бизнес-логику, а не просто «превращал нарисованные квадратики в классы».
Вместо попытки описать «всё и сразу» с помощью UML, DDD стимулирует команду работать тесно с экспертами предметной области, многократно уточнять и развивать модель. При этом можно использовать легковесные диаграммы (Context Map, Domain Model диаграммы), но их цель — уточнять совместное понимание домена, а не выполнять генерацию кода.
Вывод по главе 12
Рис. 12.2.2. — Выберите лучший подход к проектированию систем для гибкости и согласования с бизнесом
Идея модель-ориентированного проектирования (MDA, UML) имела впечатляющий старт, когда казалось, что единая формальная модель станет основой автоматизированной разработки и снизит сложность проектов. Но на практике:
Domain-Driven Design частично «заместил» классический подход к моделированию, сместив акцент на смысл и бизнес-логику (домен), а не на формальное описание каждой детали системы. DDD предлагает более гибкий и эволюционный путь, где модели постоянно уточняются при тесном сотрудничестве бизнеса и разработчиков, сохраняя при этом логику предметной области в центре внимания.
- Полный охват UML оказался слишком затратным и громоздким,
- Инструментальная поддержка не оправдала ожиданий,
- Команды предпочли «точечное» использование диаграмм или вовсе отказались от обширной формальной моделировки в пользу более гибких и понятных методов.
Domain-Driven Design частично «заместил» классический подход к моделированию, сместив акцент на смысл и бизнес-логику (домен), а не на формальное описание каждой детали системы. DDD предлагает более гибкий и эволюционный путь, где модели постоянно уточняются при тесном сотрудничестве бизнеса и разработчиков, сохраняя при этом логику предметной области в центре внимания.
Таким образом, «кризис» модель-ориентированного проектирования не означает, что UML или другие нотации совсем не нужны. Это означает лишь, что использовать их стоит осознанно, учитывая реальное «вписывание» в процессы разработки и реальные потребности команды. А подходы вроде DDD показывают, как можно проектировать систему, уделяя больше внимания богатству доменной модели и качеству кода, чем стремлению к формальной стопроцентной описательной нотации.
Читайте наши статьи по теме:
Глава 13. Проектирование использования и пользовательских интерфейсов
При создании любой информационной системы или программного продукта важно не только учесть потребности бизнеса и заложить правильную архитектуру, но и обеспечить удобство для конечных пользователей. От того, насколько грамотно спроектированы сценарии использования и пользовательский интерфейс, напрямую зависит удовлетворённость пользователей, успешность внедрения и окупаемость решений.
В этой главе мы рассмотрим основные принципы проектирования использования (Use Case, User Stories) и концепции UI/UX (пользовательский интерфейс и опыт взаимодействия), а также важность сценариев и прототипирования.
В этой главе мы рассмотрим основные принципы проектирования использования (Use Case, User Stories) и концепции UI/UX (пользовательский интерфейс и опыт взаимодействия), а также важность сценариев и прототипирования.
13.1. Сценарии использования
Рис. 13.1.1. — Компоненты сценария использования
Сценарий использования (Use Case) описывает последовательность шагов, которую выполняют пользователь или система, чтобы достичь конкретной цели. Это один из ключевых инструментов, помогающих понять, как пользователи будут взаимодействовать с системой.
Зачем нужны сценарии использования
Как описывается Use Case
Зачем нужны сценарии использования
- Фокус на потребностях: вместо абстрактного списка функций сценарии показывают реальную задачу пользователя («Сформировать заказ», «Провести платёж»).
- Проще анализировать исключительные и альтернативные ветки: что, если пользователь ошибся при вводе, или система не смогла подтвердить данные?
- Основа для тестирования: тестировщики могут создавать тест-кейсы, опираясь на эти сценарии; сразу видны основные пути и ответвления.
Как описывается Use Case
- Название: коротко отражающее цель (например, «Создать счёт»).
- Актор(ы): роли пользователей или внешние системы, которые участвуют в сценарии.
- Предусловия: что должно быть выполнено до начала сценария (например, пользователь залогинен, у него есть права).
- Основной поток: пошаговое описание действия акторов и реакции системы.
- Альтернативные потоки (опционально): что произойдёт, если в ходе основного потока случится ошибка или выбор другого пути.
- Постусловия: результат, которого мы добиваемся (например, счёт создан, уведомление отправлено).
Пример сценария использования:
13.2. Истории пользователей
Рис. 13.2.1. — Описание потребности в виде User Story
В Agile-подходах, таких как Scrum или Kanban, популярны User Stories — краткие формулировки потребностей пользователей:
«Как [роль], я хочу [действие], чтобы [бизнес-ценность].»
Преимущества User Stories
«Как [роль], я хочу [действие], чтобы [бизнес-ценность].»
Преимущества User Stories
- Простота и гибкость: короткая формулировка легко корректируется, при этом содержит ключевые элементы (кто, что, зачем).
- Уточнение в диалоге: подробности проясняются в процессе общения с пользователями и командой разработки.
- Возможность итеративной приоритизации: истории можно упорядочивать по важности, добавлять, убирать, разбивать на более мелкие задачи.
- «Как менеджер, я хочу видеть список всех заказов за неделю, чтобы контролировать продажи.»
- Список включает дату и сумму заказа, статус, контактные данные клиента;
- Можно фильтровать по статусу («Новый», «Оплачен», «Отменён»);
- Доступен экспорт в Excel.
Таким образом, User Stories помогают аналитикам и всей команде оставаться сфокусированными на ценности и результате, а не на бесполезной детализации без учёта реальных потребностей.
Читайте наши статьи по теме:
13.3. Виды и особенности пользовательских интерфейсов
Рис. 13.3.1. — Виды пользовательских интерфейсов
Пользовательский интерфейс (UI) — это среда, в которой пользователь и система обмениваются информацией и командами. Интерфейсы бывают:
1. Web-интерфейсы
2. Desktop-приложения
3. Мобильные приложения
4. Терминальные интерфейсы
5. Голосовые и чат-интерфейсы
1. Web-интерфейсы
- Доступны через браузер (Chrome, Safari, Firefox и т. д.).
- Нужно учитывать кросс-браузерную совместимость, адаптивность (desktop, планшет, мобильный).
- Часто используется протокольное взаимодействие HTTP/HTTPS, а визуал может работать на фреймворках типа React, Vue, Angular.
2. Desktop-приложения
- Устанавливаются на компьютер (Windows, macOS, Linux).
- Позволяют более глубокий доступ к ресурсам ОС, но требуют сложной дистрибуции и обновлений.
3. Мобильные приложения
- Запускаются на смартфонах и планшетах (iOS, Android).
- Ограниченные размеры экрана, сенсорное управление, доступ к функциям устройства (камера, GPS).
4. Терминальные интерфейсы
- Специфические решения для банкоматов, киосков самообслуживания, промышленного оборудования.
- Главное — стабильность, простота, высокая защита от ошибок.
5. Голосовые и чат-интерфейсы
- Ассистенты типа Alexa, Google Assistant, чат-боты в мессенджерах.
- Акцент на распознавание речи и естественный язык.
При проектировании UI аналитик и дизайнер должны учитывать физические ограничения (размер экрана, устройства ввода), специфику контекста (веб-трафик, оффлайн-доступ), тип пользователей (техническая грамотность, частота использования).
13.4. Моделирование навигации по пользовательскому интерфейсу
Рис. 13.4.1. — Инструменты проектирования пользовательского интерфейса
Часто недостаточно описать только отдельные экраны или функции. Важно понять, как пользователь будет переходить между экранами, какие действия доступны на каждом шаге. Для этого:
1. User Flow (карта потока пользователей)
2. Wireframes (макеты), прототипы
3. Information Architecture (IA)
1. User Flow (карта потока пользователей)
- Графическая схема, показывающая, какие экраны есть и как пользователь может из одного экрана попасть в другой.
- Отражает точки входа в систему, альтернативные ветки, возвращение назад, всплывающие окна и т. д.
2. Wireframes (макеты), прототипы
- Прикидочные наброски расположения элементов (кнопки, поля ввода, меню) без детальной графики.
- Помогают рано проверить логику и удобство перед тем, как вкладываться в детальный UI-дизайн.
3. Information Architecture (IA)
- Структура меню, разделов, каталогов, тегов.
- Старайтесь сделать путь пользователя к цели минимально сложным: меньше кликов, простые и говорящие названия элементов.
Модели навигации позволяют выявить несогласованность (когда нет логичного пути к нужному экрану), лишние дублирующие пути, слишком сложные переходы. Чем яснее структура, тем проще пользователю ориентироваться.
13.5. Принципы проектирования пользовательских интерфейсов
Рис. 13.5.1. — Ключевые принципы создания эффективного UI/UX Интерфейса
Современные продукты и системы должны быть интуитивными, эффективными и приятными. Основные принципы UI/UX:
1. Консистентность
2. Простота
3. Ясная обратная связь
4. Гибкость
5. Доступность (Accessibility)
6. Тестирование с реальными пользователями
1. Консистентность
- Единый стиль оформления, одинаковое поведение похожих элементов.
- Если кнопка «Сохранить» всегда справа внизу, пользователь не запутается.
2. Простота
- Минимизируйте количество кликов и экранов, не перегружайте интерфейс деталями.
- Используйте понятные иконки и лаконичные тексты.
3. Ясная обратная связь
- При нажатии кнопки система должна реагировать: показывать загрузку, подтверждать результат, выводить ошибки, если они есть.
- Пользователь должен понимать, что происходит.
4. Гибкость
- Дайте возможность настроить интерфейс под себя, если у пользователей разные сценарии и частоты использования.
5. Доступность (Accessibility)
- Учёт людей с ограниченными возможностями (цветовая палитра для дальтоников, озвучка, масштабирование текста).
- Юридические аспекты: в некоторых странах это регулировано законом.
6. Тестирование с реальными пользователями
- Чем раньше проведёте юзабилити-тесты и соберёте обратную связь, тем лучше поймёте, что нужно доработать.
Читайте наши статьи по теме:
Вывод по главе 13
Проектирование использования (Use Cases, User Stories, сценарии) и проектирование пользовательских интерфейсов — два неотделимых аспекта системного анализа. Успешное решение не только закрывает бизнес-потребности, но и обеспечивает удобство и эффективность для конечных пользователей.
- Сценарии использования дают понимание, что и как пользователь будет делать в системе, какие шаги проходят в типичной и альтернативной ветке.
- User Stories позволяют описать элементарные пользовательские потребности с точки зрения реальной ценности, а критерии приёмки — проверить, что требуемая функциональность действительно сделана.
- Детальный UI/UX-дизайн и принципы удобного интерфейса помогают превратить функциональные сценарии в понятный, приятный и продуктивный опыт работы с системой.
- Прототипирование и тестирование макетов — критический этап, позволяющий вовремя скорректировать логику, пока она не воплощена в коде.
Глава 14. Концептуальное проектирование
Концептуальное проектирование — это этап, на котором формируется общее представление о том, из каких основных блоков (модулей, подсистем) будет состоять будущая система и как они связаны друг с другом. Главная цель концептуального проектирования — заложить «скелет» будущего решения, понять его ключевые элементы и взаимодействия, не вдаваясь в детальную реализацию на уровне кода, интерфейсов или инфраструктуры.
В данной главе мы рассмотрим, какие задачи решает концептуальное проектирование, почему важно «моделировать и проектировать состав» будущей системы, и как это влияет на согласование интересов бизнеса и технических команд.
В данной главе мы рассмотрим, какие задачи решает концептуальное проектирование, почему важно «моделировать и проектировать состав» будущей системы, и как это влияет на согласование интересов бизнеса и технических команд.
14.1. Моделирование и проектирование состава
Рис. 14.1.1. — Эффективная структура системы для интеграции и моделирования
«Состав» системы (или компонентная структура) показывает, из каких крупных частей (субсистем, модулей, сервисов) состоит решение и как эти части взаимодействуют друг с другом. Это может включать описание:
Почему «состав» важен?
Инструменты для моделирования состава
- Основных функциональных блоков (например, «Модуль управления заказами», «Модуль расчёта тарифов», «Модуль аналитики»);
- Сервисов или микросервисов, если используется сервис-ориентированная или микросервисная архитектура;
- Подсистем, связанных с разными бизнес-направлениями (закупки, логистика, продажи, маркетинг и т. д.);
- Интеграционных шлюзов (ESB, API Gateways, message brokers), через которые система связывается с внешними решениями.
Почему «состав» важен?
- Упрощение понимания: заинтересованные стороны (бизнес, руководство, разработчики) видят, как решение «разбито» на крупные части и почему именно такое деление выбрано.
- Распределение ответственности: каждая подсистема или модуль может иметь своего владельца/команду. В крупных компаниях так проще контролировать развитие каждого направления.
- Определение границ: уже на концептуальном уровне понятно, где заканчивается функциональность одного модуля и начинается функциональность другого. Это позволяет избежать конфликтов, дублирования и пересечений.
- Подготовка к интеграции: если известно, что в системе есть, к примеру, отдельный «Модуль учёта оплаты», заранее понятно, как он будет взаимодействовать с «Модулем управления заказами» и внешними платёжными сервисами.
Инструменты для моделирования состава
- UML Component Diagram: показывает систему в виде крупных компонентов (component) и связи между ними (interfaces, ports).
- C4-модель (контекст, контейнеры, компоненты, классы): популярный подход в современной архитектуре для структурирования представления о системе на нескольких уровнях детализации.
Простые блок-схемы (Block diagrams): если не нужны формальные нотации, можно отразить основные блоки на схеме «прямоугольник—стрелки», сопровождая их описанием.
14.2. Роль концептуального проектирования в согласовании интересов
На концептуальном уровне часто встречаются конфликты или разные видения того, как система должна быть устроена:
Концептуальное проектирование, отражающее состав системы, помогает:
- Бизнес-заказчик может считать, что ему нужен «один единый модуль, который решает всё сразу».
- Техническая команда может предпочитать микросервисную архитектуру, разделяя функциональность на десятки сервисов ради гибкости и независимых релизов.
- Руководство может волновать вопрос «А сколько это будет стоить и не превысит ли бюджет?»
Концептуальное проектирование, отражающее состав системы, помогает:
- Показывать, как бизнес-требования раскладываются на модули. Например, «Подсистема для сбора аналитики» отвечает за KPI и отчётность, «Модуль клиентского портала» закрывает задачу повышения удобства для клиента.
- Оценивать сложность и стоимость. Разделение на компоненты даёт понимание, какие блоки придётся разрабатывать с нуля, что можно купить как готовое решение (COTS), что можно взять в виде open-source библиотеки.
- Согласовывать сроки. Если критичен быстрый выход на рынок (Time to Market), приоритизируется разработка отдельных модулей, без которых бизнес-эффект не реализуется. Менее приоритетные части можно внедрять на следующей фазе.
Таким образом, «проектирование состава» служит площадкой для диалога между всеми стейкхолдерами. Аналитик может визуализировать несколько альтернативных вариантов структуры и вместе с командой выбрать оптимальный, исходя из целей, рисков и ограничений.
14.3. Связь концептуального проекта с дальнейшей детализацией
Когда концептуальная схема структуры системы принята, возникают естественные вопросы:
Ответы на эти вопросы даёт следующий уровень проектирования — системные требования, техническая архитектура, детальный дизайн. Однако без чёткого концептуального фундамента есть риск, что команда уйдёт в технические детали, не имея единого представления о «большой картине».
Процесс итеративного развития
Часто концептуальное проектирование не заканчивается одним документом. Это живой процесс, где модель состава дополняется и пересматривается, если:
- «Как внутри каждого модуля будут организованы данные, классы, бизнес-логика?»
- «Как эти модули будут деплоиться и масштабироваться?»
- «Какие протоколы использовать для взаимодействия между сервисами?»
Ответы на эти вопросы даёт следующий уровень проектирования — системные требования, техническая архитектура, детальный дизайн. Однако без чёткого концептуального фундамента есть риск, что команда уйдёт в технические детали, не имея единого представления о «большой картине».
Процесс итеративного развития
Часто концептуальное проектирование не заканчивается одним документом. Это живой процесс, где модель состава дополняется и пересматривается, если:
- Меняются бизнес-требования, появляются новые функции, которые требуют отдельного модуля.
- Выявляются технологические ограничения, заставляющие изменить структуру (например, объём данных слишком велик, что требует вынести аналитику в отдельный high-load сервис).
- Проект переходит на новую фазу (например, интеграция с внешними системами), где нужно уточнить границы ответственности модулей.
Вывод по главе 14
Концептуальное проектирование — важный шаг, который помогает системному аналитику и всей команде увидеть высокоуровневую структуру будущей системы, определить ключевые модули (подсистемы, сервисы) и их взаимосвязи. На этом уровне:
- Закладываются границы: что входит в систему, а что остаётся во внешних компонентах.
- Формируется понятная карта для стейкхолдеров (бизнес, IT, менеджмент), позволяющая согласовать приоритеты и ответственность.
- Определяется направление дальнейшего детального проектирования и архитектуры.
Без чёткого концептуального видения команда рискует «утонуть» в деталях и создавать систему, где нет ясного разделения ролей и функций. А продуманная модель состава служит прочным фундаментом для дальнейшего системного анализа, инженерии требований и детального проектирования.
Концептуальное проектирование — важный шаг, который помогает системному аналитику и всей команде увидеть высокоуровневую структуру будущей системы, определить ключевые модули (подсистемы, сервисы) и их взаимосвязи. На этом уровне:
- Закладываются границы: что входит в систему, а что остаётся во внешних компонентах.
- Формируется понятная карта для стейкхолдеров (бизнес, IT, менеджмент), позволяющая согласовать приоритеты и ответственность.
- Определяется направление дальнейшего детального проектирования и архитектуры.
Без чёткого концептуального видения команда рискует «утонуть» в деталях и создавать систему, где нет ясного разделения ролей и функций. А продуманная модель состава служит прочным фундаментом для дальнейшего системного анализа, инженерии требований и детального проектирования.
Глава 15. Внутрисистемный анализ
Когда общая концепция системы уже определена и основные модули (подсистемы) зафиксированы, наступает время внутрисистемного анализа: более детального определения требований и проектирования функционала внутри границ самой системы. На этом этапе системный аналитик, совместно с архитекторами и разработчиками, прорабатывает, как именно будет работать каждый модуль, какие функции он должен выполнять, какие ограничения существуют по качеству и инфраструктуре, и как всё это в итоге будет согласовываться между собой.
15.1. Системные требования
Системные требования — это специфические описания того, какой должна быть будущая система, чтобы удовлетворять потребности пользователей и соответствовать бизнес-требованиям. Если на уровне концептуального проектирования мы определяли состав и взаимодействие основных блоков, то теперь речь идёт о том, что входит в каждый блок и какую конкретную функциональность он должен предоставлять.
Виды системных требований:
1. Функциональные
Виды системных требований:
1. Функциональные
- Описывают логику работы, сценарии, данные, которые обрабатываются, и бизнес-правила.
- Например: «Система должна позволять оператору видеть детализированную информацию о заказе», «В случае нехватки товара на складе система блокирует отправку».
- Относятся к производительности, безопасности, масштабируемости, удобству поддержки и т. д.
- Например: «Время отклика на запрос не должно превышать 2 секунд при 100 одновременно активных пользователей».
- Требования к технологиям, окружению, интеграционным протоколам.
- Например: «Решение должно работать в Docker-контейнерах под управлением Kubernetes», «Формат данных обмена — JSON, протокол — HTTPS».
Читайте наши статьи по теме:
15.2. Функциональное проектирование
После того как сформулированы системные требования, нужно выработать детальное понимание функциональной логики. Функциональное проектирование фокусируется на том, какие функции система должна выполнять и как (на уровне логики, а не кода).
Методики и инструменты:
1. Use Case и Activity Diagrams
2. Сценарии взаимодействия (Sequence Diagrams)
3. Схемы данных (ER-диаграммы, если речь о реляционных БД)
4. Прототипирование
Результат функционального проектирования — более детальное описание для команды разработки, которое позволяет однозначно понять, какие именно функции нужно реализовать и как они согласованы между модулями.
Методики и инструменты:
1. Use Case и Activity Diagrams
- Позволяют описать последовательность действий (внутренний «workflow») и уточнить бизнес-правила обработки данных.
- Показывают, какие шаги выполняет система в ответ на действия пользователя или внешнего сервиса.
2. Сценарии взаимодействия (Sequence Diagrams)
- Описывают, в каком порядке вызываются методы, сервисы, какие сообщения передаются между объектами или микросервисами.
- Удобно для сложной логики, где важно понять очередность взаимодействий.
3. Схемы данных (ER-диаграммы, если речь о реляционных БД)
- Проектирование сущностей и их связей (таблицы, поля, отношения).
- Уточнение ключевых атрибутов (например, «У заказа есть статус, дата создания, сумма»).
4. Прототипирование
- Если часть функционала связана с пользовательским интерфейсом, создаются макеты (wireframes), чтобы проверить логику экранов и переходов.
Результат функционального проектирования — более детальное описание для команды разработки, которое позволяет однозначно понять, какие именно функции нужно реализовать и как они согласованы между модулями.
Читайте наши статьи по теме:
15.3. Выявление и формализация функций системы
Функции — это «способности» системы, позволяющие ей обрабатывать запросы, управлять процессами, хранить и трансформировать данные. Системный аналитик должен:
1. Собрать все предполагаемые функции
2. Уточнить входы и выходы для каждой функции
3. Определить бизнес-правила и ограничения
4. Приоритизировать
Задача аналитика — обеспечить, чтобы каждая важная функция была не только «названа», но и достаточно подробно описана, чтобы разработчики понимали, что от них требуется, а тестировщики могли проверить результат.
1. Собрать все предполагаемые функции
- Часто отталкиваются от бизнес-процессов (TO-BE), user stories и сценариев использования, выявленных на предыдущих этапах.
- Формируют список или декомпозицию (Functional decomposition).
2. Уточнить входы и выходы для каждой функции
- Какие данные функция принимает на вход, что выдаёт на выход?
- Как она реагирует на ошибки, нетипичные ситуации?
3. Определить бизнес-правила и ограничения
- Правила расчёта, проверки, валидации.
- Например: «Функция «Расчёт скидки» учитывает статус клиента (новый, постоянный), текущие промоакции и остатки на складе».
4. Приоритизировать
- Не всегда все функции нужны сразу. В Agile-проектах делают «построение по мере необходимости» (MVP, затем дальнейшее развитие).
- В классических проектах может быть «этап 1», «этап 2», где часть функционала откладывают из-за бюджета или сроков.
Задача аналитика — обеспечить, чтобы каждая важная функция была не только «названа», но и достаточно подробно описана, чтобы разработчики понимали, что от них требуется, а тестировщики могли проверить результат.
15.4. Выявление и формализация атрибутов качества
Атрибуты качества (или нефункциональные требования) определяют, какой должна быть система с точки зрения производительности, надёжности, удобства поддержки и т. д. Часто их упускают из виду, сосредотачиваясь на функционале, и потом сталкиваются с проблемами на этапе внедрения или эксплуатации.
Примеры атрибутов качества:
1. Производительность (Performance)
2. Надёжность/Отказоустойчивость (Reliability)
3. Безопасность (Security)
4. Удобство сопровождения (Maintainability)
5. Удобство масштабирования (Scalability)
Формализация в нефункциональных требованиях
Примеры атрибутов качества:
1. Производительность (Performance)
- Количество обработок в секунду, время отклика при определённом уровне нагрузки, время выполнения периодических задач.
- Критично для high-load систем, онлайн-сервисов.
2. Надёжность/Отказоустойчивость (Reliability)
- Допустимое время простоя (SLA), механизм резервирования, восстановление после сбоев.
- Может включать географическую репликацию данных.
3. Безопасность (Security)
- Требования к аутентификации, авторизации, шифрованию, защите от SQL-инъекций и иных уязвимостей.
- Соответствие стандартам (PCI DSS для платёжных систем, HIPAA для медицины и т. д.).
4. Удобство сопровождения (Maintainability)
- Требования к структуре кода, документированию, метрикам, логированию, форматам обновления.
- Может определять, что код должен быть покрыт определённым процентом тестов, либо что все интеграции описаны в Confluence.
5. Удобство масштабирования (Scalability)
- Как система должна реагировать на рост количества пользователей, объёма данных?
- Распределённая архитектура, микросервисы или возможность горизонтального масштабирования.
Формализация в нефункциональных требованиях
- Важно указывать конкретные цифры, показатели, SLA, а не писать абстрактно «система должна быть быстрой».
- Пример: «Среднее время отклика не более 2 секунд при 5000 запросах в час», «Система должна восстанавливаться после сбоя не более чем за 10 минут».
15.5. Выявление и формализация технических ограничений
Технические ограничения могут исходить от организации (политики ИТ-департамента), поставщиков, регуляторов или сложившейся инфраструктуры. Системному аналитику важно собрать и учесть их, чтобы потом не пришлось «переделывать» систему:
1. Среда и платформы
2. Стандарты и регламенты
3. Лицензирование
4. Требования к аппаратным ресурсам
Формализация таких ограничений на ранних этапах позволяет архитекторам и разработчикам проектировать решение, учитывая реальные рамки, и не предлагать вариант, который не будет принято ИТ-службой или руководством.
1. Среда и платформы
- «Нужно, чтобы решение работало на Windows Server 2019» или «Все сервисы должны быть контейнеризированы в Docker».
- «БД — только Oracle, потому что корпоративный стандарт».
2. Стандарты и регламенты
- «Код должен соответствовать внутреннему стандарту код-ревью», «Документация — в Confluence».
- «Интеграционный протокол — только REST, SOAP-подход не допускается».
3. Лицензирование
- «Использовать только open-source решения» или, напротив, «запрет на использование библиотек, несовместимых с корпоративной лицензией».
- В госорганах может быть требование «только отечественное ПО» (в некоторых юрисдикциях).
4. Требования к аппаратным ресурсам
- «Ограничение по памяти, CPU, дисковому пространству».
- «Должно работать на существующих серверах без закупки нового оборудования».
Формализация таких ограничений на ранних этапах позволяет архитекторам и разработчикам проектировать решение, учитывая реальные рамки, и не предлагать вариант, который не будет принято ИТ-службой или руководством.
Читайте наши статьи по теме:
Вывод по главе 15
Внутрисистемный анализ — это детальное погружение в логику и характеристики системы, чтобы она соответствовала ожиданиям пользователя и бизнесу. На этом этапе:
- Системные требования превращаются из высокоуровневых идей и концепций в чёткие спецификации: функциональные, нефункциональные, технические.
- Функциональное проектирование обеспечивает понимание, какие именно операции и сценарии будет выполнять система, какова их логика и бизнес-правила.
- Атрибуты качества и технические ограничения не менее важны, чем функционал, ведь система может формально «уметь» всё, что нужно бизнесу, но быть неприемлемо медленной, небезопасной или слишком дорогой в эксплуатации.
