Денис Бесков

Обсуждение и визуализация назначения и границ системы

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

Быстрое выявление функциональных системных требований

Второе её назначение — служить источником для быстрой генерации первичного набора системных функциональных требований при необходимости проектирования системы не «сверху-вниз», от бизнес-модели, бизнес-требований, модели деятельности организации, требований заинтересованных лиц, модели использования, как предлагает нам системная инженерия, а «из середины».

Контекстная диаграмма относится к категории диаграмм, описывающих систему на уровне «чёрного ящика» — а именно, только внешние свойства (в данном случае — потоки данных), но не содержание системы.

Контекстная диаграмма содержит 3 основных компонента:

1. Проектируемый объект (например, система)
   
2. Взаимодействующие с проектируемым объектом элементы окружения (группы пользователей, смежные системы)
   
3. Потоки данных (исходящие и входящие)

Потоки данных могут передаваться между окружением и (программной) системой любым образом — с помощью графического пользовательского интерфейса (GUI), командной строки (CLI), программных вызовов (API), почтовых сообщений и т.д.

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

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

Контекстная диаграмма может разрабатываться в ходе рабочего семинара, в ходе серии интервью или на основе результатов серии интервью.

Контекстную диаграмму можно рисовать на маркерной доске, в среде проектирования или в онлайн-инструменте (Google Draw, Draw.io, Miro и т.д.). Мы рекомендуем маркерную доску или онлайн-инструмент с совместным редактированием.

Порядок разработки контекстной диаграммы на рабочем семинаре:

1. Из числа заинтересованных лиц собирается рабочая группа (обычно от 3 до 5 человек)
   
   
2. Рабочая группа фиксирует в центре диаграммы название конкретной системы
   
   
3. Рабочая группа выдвигает и отображает группы пользователей, которые должны взаимодействовать с системой, обсуждает их перечень, дополняет его
   
   
4. Рабочая группа выдвигает и отображает смежные системы, которые должны взаимодействовать с системой, обсуждает их перечень, дополняет его
   
   
5. Рабочая группа последовательно проходит по каждому элементу окружения и описывает потоки данных, связывающие его с системой
   
   
6. Рабочая группа проводит тестирование контекстной диаграммы, дополняя диаграмму по ходу тестирования
   
   

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

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

Тестирование контекстной диаграммы с помощью парных соответствий

Контроль соответствия входных и выходных данных системы опирается на принцип (aka «Закон сохранения данных»), что если в систему попадают какие-то данные (входной поток), они должны как-то использоваться для как минимум одного выходного потока.

И наоборот, если есть выходной поток, то система либо должна генерировать эти данные согласно каким-то правилам (например, случайно) или формировать их на основе каких-то других входных данных.

Более формально парные соответствия можно проконтролировать через таблицу, например:

Тестирование контекстной диаграммы с помощью сквозного сценария

В зависимости от сложности системы, можно проводить неформальное или формальное тестирование диаграммы через сквозной сценарий её использования.

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

1. Система загружает реестр пользователей из AD
   
   
2. Администратор настраивает полномочия пользователей
   
   
3. и т.д.

Фактически такой рассказ служит своеобразной «нарративной» формой изложения концепции (использования) системы, наколеночно, но тем не менее достаточно эффективно подменяет создание полной модели использования для целей контекстной диаграммы.

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

При желании такой сквозной сценарий можно разработать и записать, сделав его приложением к контекстной диаграмме, иллюстрирующим текстом работу системы.

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

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

Выявление и контроль полноты (функциональных) системных требований

При создании системных требований возникает риск упустить что-то важное или наоборот, избыточно проработать очевидное.

Чтобы не упустить что-то важное среди системных функций, можно применять:

1. Трассировку системных требований на требования заинтересованных лиц
   
   
2. Модель использования системы (обычно в форме набора сценариев использования, use case'ов)
   
   
3. Контекстную диаграмму системы

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

Наибольшие гарантии даёт применение всех 3-х методов, однако контекстная диаграмма — это самый простой и дешёвый их них, поэтому часто стоит начинать проработку системных требований именно с неё.

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

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