Основная цель применения RML - помочь заинтересованным сторонам эффективнее решать задачи, связанные с документированием и обсуждением большого количества требований. Но, прежде чем говорить про RML, давайте разберемся с авторами и главным источником информации об этом языке - книгой «Visual Models for Software Requirements».
Картинки даются легко, слова - сложно
В книге «Visual Models for Software Requirements» Джой Битти и Энтони Чен раскрывают этот тезис с разных ракурсов.
Визуализация – это возможность преодолеть проблему ограниченности нашей краткосрочной памяти.
Интересный пример этого – история одного из авторов, как сотрудница ресепшен отеля объясняла маршрут до номера на словах, упоминая множество «налево», «направо» и различных предметов, которые надо заметить, чтобы не пройти свой поворот. Автора этот объем информации поставил в ступор, но сотрудница отеля исправила ситуацию и нарисовала карту с маршрутом до лифта.
Как карта с маршрутом в ситуации выше, модели требований позволяют визуально сгруппировать разрозненную информацию таким образом, чтобы можно было быстро ее проанализировать.
О чем эта книга
По первым ощущениям она про здравый смысл в работе с требованиями. Авторы приводят различные примеры, когда и в каком виде визуализация может помочь быстрее достигнуть понимания.
Затрагивают проблемы связанные с ограничениями наших когнитивных способностей. Например, длинные списки требований и объемные бэклоги среднестатистическому человеку достаточно сложно удержать в голове, потому что срабатывает ограничение Магического числа Миллера.
В 1950-х годах когнитивный психолог Джордж А. Миллер обнаружил, что люди способны запоминать и обдумывать 7 ± 2 пункта одновременно. Более поздние исследования показали, что это число, возможно, составляет 3 или 4 пункта.
В книге приведено интересное сравнение списка требований со списком покупок для похода в магазин. Если нам нужно купить 15 разных товаров и мы храним их список только в своей голове, то велика вероятность что-то забыть. Аналогично и с требованиями. Если они представляют собой длинный список или множество задач в бэклоге, то без упорядочивая и группировки их будет сложно удержать в уме для представления общей картины.
Кто такие Джой Битти и Энтони Чен
Джой Битти — известная личность в области бизнес-анализа и инженерии требований. Соавтор книги «Требования к программному обеспечению», упоминая которую обычно вспоминают только Карла Вигерса.
Энтони Чен — эксперт в области инженерии требований, разработал программу обучения требованиям, используемую на международном уровне, и помог создать ключевые концепции моделирования требований.
В начале книги есть рекомендация читать ее после прочтения книги «Требования к программному обеспечению». И это абсолютно обоснованно, потому что есть достаточно много отсылок к теории, не понимая которые сложно сориентироваться.
Зачем потребовался еще один язык моделирования и чем не подошел UML
Основные причины – отсутствие моделей, с помощью которых можно показать связь требований с ценностью для бизнеса и моделей, которые представляют систему с точки зрения конечного пользователя.
Еще один аспект – сложность для понимания представителями бизнеса, так как UML ориентирован на технический дизайн и архитектуру программного обеспечения.
UML может быть приспособлен для моделирования требований, которые фокусируются на выгоде для бизнеса, бизнес-правилах и действиях пользователя, но модели наиболее полезны, когда они фокусируются на одном или двух аспектах решения.
Поэтому для моделирования требований был создан RML (Requirements Modeling Language) с простым синтаксисом, который позволяет передать информацию в доступном для понимания виде всем заинтересованным сторонам.
При этом RML не сможет заменить текстовое описание требований. Модели служат дополнительным артефактом, благодаря которому можно в том числе выявить новые требования.
Модели RML делятся по категориям: цели, люди, системы и данные.
Для их обозначения применяют аббревиатуру OPSD (Objectives, People, Systems, Data)
- Модели целей описывают ценность системы для бизнеса и помогают расставить приоритеты для фичей и требований на основе их ценности.
- Модели людей описывают заинтересованные стороны системы, их бизнес-процессы и цели.
- Модели систем описывают, какие системы существуют, их пользовательский интерфейс, поведение систем и их взаимодействие с другими системами.
-
Модели данных описывают взаимоотношения основных сущностей или структур данных, которые используются в рамках бизнеса или организации для выполнения различных задач или бизнес-процессов (клиенты, продукты, заказы, счета, транзакции и т.д.) с точки зрения конечного пользователя, жизненный цикл данных и то, как эти данные используются в отчетах для принятия решений.
В каждой категории есть ограничивающая модель, которая помогает задать границы анализа:
- Для целей - Business Objectives Model
- Для людей - Org Chart
- Для систем - Ecosystem Map
- Для данных - Business Data Diagram
Как работают эти модели
Рассмотрим на примере Org Chart. По сути это аналог орг. структуры, но строится эта модель для другой цели. Она может помочь определить заинтересованные стороны, с которыми нам нужно взаимодействовать в рамках проекта.
Для Org Chart мы можем использовать существующую орг. структуру компании, для которой мы реализуем проект. В процессе создания Org Chart мы анализируем не только тех, кто использует систему, но и тех, кто управляет системой, разрабатывает или обслуживает систему. Таким образом Org Chart будет задавать нам границы для дальнейшей работы с заинтересованными сторонами, чтобы мы могли быть уверены, что не упустим какую-либо заинтересованную сторону при анализе бизнес-процессов или сборе требований.
Более подробно каждую категорию моделей рассмотрим в отдельных статьях.
По мере их появления в этой статье ссылки для перехода.
