16.4. Разработка требований к системе

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

Основой разработки требований является модель системных прецедентов, отражающая выполнение конкретных обязанностей внутренними и внешними исполнителями с использованием ИС.

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

  1. заголовок (название прецедента, ответственный за исполнение, дата создания шаблона/внесения изменений);

  2. краткое описание прецедента;

  3. ограничения;

  4. предусловия (необходимое состояние системы или условия, при которых должен выполняться прецедент);

  5. постусловия (возможные состояния системы после выполнения прецедента);

  6. предположения;

  7. основная последовательность действий;

  8. альтернативные последовательности действий и условия, их инициирующие;

  9. точки расширения и включения прецедентов.

В процессе создания модели системных прецедентов осуществляется преобразование и перенос компонентов бизнес-моделей на новые диаграммы. Типовые преобразования по технологии Rational Unified Process приведены в таблица 12.1 .

Таблица 12.1.

Элементы бизнес-модели

Элементы модели системных прецедентов

Бизнес-прецеденты

Подсистемы

Внешние исполнители

Исполнители

Внутренние исполнители

Исполнители или прецеденты

Процессы, выполняемые внутренними исполнителями

Прецеденты

На рис. 12.9 представлена модель системных прецедентов для бизнес-прецедента «Оказание медицинской помощи». Исходя из цели создания системы, в модели системных прецедентов отражены только те действия исполнителей, которые связаны с предоставлением доступа и обновлением клинических записей.

Рис. 12.9. Модель системных прецедентов

Описываемые моделью функции характерны только для одного вида деятельности - оказания медицинской помощи, и в основном не используются в других видах деятельности Центра. Это позволяет объединить выделенные функции в некую единую подсистему проектируемой ИС.

Внутренний исполнитель «Персонал центра» (см. рис. 12.4 , рис. 12.7 ) и выполняемый им ручной процесс преобразован в системный прецедент «Предоставление доступа к клиническим записям».

Внешние исполнители (например, «Производитель медицинского оборудования») непосредственно взаимодействуют с проектируемой системой, т.е. превращаются в исполнителей.

В модели отражены два специальных типа связи между прецедентами (на рис. 12.9 соответствующие прецеденты выделены тенью):

  1. «включает» - один прецедент в процессе своего исполнения обязательно выполняет некий блок действий, составляющих другой прецедент;

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

Прецедент «Проверка прав доступа» впервые появился на диаграммах и реализуется средствами разрабатываемой ИС. Поэтому для него приходится разрабатывать диаграмму последовательностей, описывающую его исполнение ( рис. 12.10 ). В результате в проектируемой ИС появляются два новых объекта - программный модуль «Менеджер защиты» и информационный блок «Набор прав».

Рис. 12.10. Диаграмма последовательностей для прецедента «Проверка прав»

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