Разработка и управление требованиями к системе

От бизнес-прецедентов к архитектуре системы

После построения бизнес-модели и модели бизнес-прецедентов следующий шаг — определение требований к информационной системе. Рекомендации RUP позволяют формализовать этот переход.

На основе выявленных бизнес-прецедентов формулируется архитектура системы и выделяются подсистемы:
• Подсистема обеспечения оказания медицинской помощи — выполняет действия, связанные с заполнением и передачей документов о состоянии пациента.
• Подсистема финансового учёта — логично обособлена, так как практически не связана с первой.
• Подсистема документального обеспечения — проверяет соблюдение требований к организации медицинского обслуживания.
• Подсистема доступа в единую сеть медучреждений — автономная задача, легко отделяемая от остальных.

В подсистеме оказания помощи выделяются задачи:
1. Предоставление доступа к клиническим записям (информация о пациентах). Автоматизация позволяет исключить персонал, ранее выполнявший эту функцию.
2. Ввод предписаний — внесение врачом корректировок и рекомендаций по лечению в клинические записи.

Моделирование действий: диаграмма последовательности

Последовательность работы с клинической записью можно описать диаграммой последовательности. Взаимодействуют:
• Отправитель запроса — объединённый класс, вобравший несколько действующих лиц;
• Персонал центра (на этапе анализа ещё присутствует);
• Клинические записи.

Поток действий:
1. Отправляется запрос на получение клинической записи.
2. Нужная запись выбирается.
3. Отправитель анализирует запись.
4. В запись вносятся изменения.
5. Изменённая запись возвращается в хранилище.

Структура клинической записи

Клиническая запись — сложный информационный объект. Она является абстрактным классом и может быть одного из трёх видов (связь «обобщение»):
• Внешняя — информация из других учреждений.
• Архивная — записи о предыдущих обращениях в этом же центре.
• Новая — создаётся при текущем обращении.

Каждая запись — агрегат, включающий:
• Минимальный набор данных — сведения о пациенте (имя, фамилия, год рождения и т.д.).
• Результаты анализов (от 0 до N, анализы могут отсутствовать или проводиться многократно).
• Предписания врача, выданные на основе анализов.
• Другие блоки.

Клинические записи со временем перемещаются в архив — единственный в системе, содержащий произвольное количество записей. На данном этапе атрибуты и методы классов не детализируются, важен лишь общий взгляд на структуру информации.

Модель анализа и проектирование

В результате формируется модель анализа — набор диаграмм, с которых начинается проектирование архитектуры:
• Диаграммы сценариев исполнения действий.
• Диаграммы разделения системы на подсистемы и их функции.
• Диаграммы последовательностей, описывающие выполнение функций.
• Диаграмма структуры данных (классов), с которыми работает система.

При детализации классов проявляется их универсальность — они описывают и пользователей, и приложения, и фрагменты базы данных. Пример для подсистемы защиты доступа:
• Отправитель запроса — обладает идентификатором и паролем, выполняет запрос информации, вход в систему.
• Вход реализуется через запрос доступа к Менеджеру защиты — программе, проверяющей соответствие идентификатора и пароля.
• Менеджер защиты обращается к набору прав (фрагмент БД), после чего выносит решение о допуске.

Такое детальное описание даёт согласованную логическую модель в виде диаграммы классов. Она синхронизирует разработку приложений и проектирование базы данных на единой основе.

От логической модели к базе данных

При преобразовании логической модели в реляционные таблицы возникают сложности с отображением иерархий. Возможны два подхода:
1. Каждому элементу иерархии сопоставить отдельную таблицу и установить связи — решение неэкономичное и громоздкое.
2. Ввести дополнительный атрибут (например, «тип работника»), который позволит хранить все подклассы в одной таблице, различая их по значению атрибута. Это более изящное решение без лишних элементов и связей.

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

Таким образом, от первоначальных «квадратиков» без атрибутов и методов проект постепенно наращивает степень детализации. Полная спецификация классов становится основой для разработки и базы данных, и приложений.

Управление требованиями

Вторая важная тема — управление требованиями. Изменения требований неизбежны в любом проекте, и задача состоит в том, чтобы управлять ими, не допуская разрушения проекта.

По данным Standish Group, 52% причин провалов проектов так или иначе связаны с формированием и управлением требованиями. Это объясняет необходимость серьёзного отношения к дисциплине.

Требование — описание условий, которым должна удовлетворять система, или её возможностей. Требования делятся на две большие группы:
• Функциональные — описывают, что система должна делать. Хорошо извлекаются из бизнес-процессов.
• Нефункциональные — определяют, как система должна работать в конкретной среде. Их трудно вывести из бизнес-моделей; они опираются на опыт разработки и эксплуатации, анализ психофизиологических особенностей операторов и т.п.

Международная модель классификации известна как FURPS+:
• Functionality — функциональные требования.
• Usability — применимость (удобство работы пользователя, а не выгода заказчика).
• Reliability — надёжность.
• Performance — производительность.
• Supportability — поддержка.
• «+» — ограничения конкретного проекта.

Цели разработки требований: создание взаимосогласованного документа (заказчик и разработчик одинаково понимают систему); понимание разработчиком того, что действительно требуется; получение оснований для планирования ресурсов и сроков.

Процесс формирования требований в RUP

RUP предлагает схему:
1. Анализ проблемы, которую должна решить система (или проблем существующей системы).
2. Определение системы — формирование требований к создаваемому продукту.
3. Проверка реализуемости — оценка наличия ресурсов. Если ресурсов недостаточно, возвращаемся на шаг назад для корректировки требований.

Процесс можно представить как слоёный пирог:
• Верхний уровень: потребности заказчика (неформализованные).
• После моделирования использования: пользовательские требования.
• После моделирования функционирования: системные требования.
• С учётом нагрузочной и реальной эксплуатации: дополнительные нефункциональные требования.

Изменения на любом уровне обязательно пронизывают все остальные. Требования также делятся по областям: область проблем (потребности → пользовательские) и область решений (системные). Любые требования по ходу работы меняют статус, становясь то входящими, то производными: например, потребности — входящие, пользовательские — производные, затем они сами становятся входящими для системных.

Атрибутирование и связи требований

Для систематизации каждое текстовое требование снабжается атрибутами (реквизитами): приоритет, версия, статус рецензирования и др. Фактически формируется база данных с текстовым полем и множеством дополнительных характеристик, позволяющих отбирать и группировать требования.

Требования образуют граф, где стрелка означает, что требование нижнего уровня поддерживает верхнее. Анализ связей даёт три инструмента:
• Анализ влияния (по входящим связям): какие требования затронет изменение данного.
• Анализ последствий (по исходящим связям): поддерживает ли требование что-либо на верхнем уровне. Если поддержки нет, требование может быть излишним.
• Анализ покрытия: все ли требования обеспечены тестами.

Изменение одного требования распространяет «подозрительность» на связанные узлы, но при рассмотрении целые области графа быстро отсеиваются, и фронт работ сужается. Количество подозрительных требований меняется пилообразно, что отражает этот процесс.

Качество требований и работа с заинтересованными сторонами

Хорошие требования должны быть:
• чёткими (без многозначности);
• исполнимыми в рамках проекта;
• проверяемыми (с определёнными показателями выполнения);
• структурированными в документе;
• точно отражающими суть и допускающими установление связей.

При сборе требований важно задавать правильный вопрос заказчику. Неудачные формулировки: «Что вы хотите, чтобы система делала?» и «Какие задачи она должна решать?» — заставляют заказчика, не являющегося IT-специалистом, брать на себя несвойственные функции. Правильный вопрос: «Что вы хотите делать с помощью системы?» На основе полученных неструктурированных потребностей IT-специалист через бизнес-моделирование строит формализованные пользовательские требования, циклически уточняя их.

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

Общая последовательность: пользовательские требования → моделирование системы → системные требования → требования к компонентам. Её нарушение приводит к некорректным спецификациям.

Расширенные связи и метрики

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

Появляется возможность вычислять метрики:
• Широта — полнота охвата требований соседнего уровня.
• Глубина — расстояние прохождения требования вверх или вниз по уровням.
• Нарастание — степень разрастания связей через уровни.

Структурный анализ метрик позволяет находить дефекты, не вчитываясь в текст: слишком абстрактные требования (могут быть удалены), излишне детализированные (требуют укрупнения), а также нетипичные требования, выбивающиеся из гистограмм нисходящего и восходящего фактора нарастания. Такие требования подлежат обязательному дополнительному анализу.

Роли в управлении требованиями

Для эффективного управления в проектной команде необходимо выделять роли:
• Автор — формулирует требование.
• Издатель — отвечает за итоговый документ.
• Цензор — проверяет требования по качеству формулировки и содержанию.
• Аналитик (разработчик) — реализует систему на основе утверждённых требований.

Без явного закрепления этих ролей грамотное управление изменениями затруднено.

Заключение

В курсе были рассмотрены моделирование бизнес-процессов и информационных систем, стандарты создания систем и, наконец, управление требованиями. Полученные знания позволяют осмысленно начинать работу в проектах, однако дальнейшее совершенствование требует накопления собственного опыта и углубления знаний.

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

Следующий смысловой блок посвящён управлению требованиями как критическому фактору успеха проекта. Подчёркнуто, что функциональные требования сравнительно легко извлекаются из бизнес-процессов, тогда как нефункциональные требуют особого внимания, поскольку лежат в плоскости удобства, надёжности и эксплуатационных ограничений, невидимых в моделях деятельности. Модель FURPS+ структурирует эти категории. Логика формирования требований представлена как многоуровневый итеративный процесс: от аморфных потребностей заказчика через формализацию к системным и компонентным спецификациям. Ключевое правило — правильный вопрос заказчику, ориентированный на его действия, а не на функции системы.

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