Моделирование требований. Requirements Modeling Language (RML)

12.12.24

Программная инженерия - Работа с требованиями

Requirements Modeling Language (RML) - язык, разработанный специально для визуального моделирования требований. При разработке RML существующие модели были модифицированы для упрощения восприятия информации заинтересованными сторонами. В RML используются только простые и интуитивно понятные символы.

Основная цель применения 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 будет задавать нам границы для дальнейшей работы с  заинтересованными сторонами, чтобы мы могли быть уверены, что не упустим какую-либо заинтересованную сторону при анализе бизнес-процессов или сборе требований.

 

Более подробно каждую категорию моделей рассмотрим в отдельных статьях.

По мере их появления в этой статье ссылки для перехода.

См. также

Работа с заинтересованными сторонами Анализ потребностей и поиск решений Бесплатно (free)

Еще в начале года у меня возникло желание сделать что-то наподобие гайда для начинающих аналитиков, но смена работы, проекты, курсы и конференции отодвинули эту идею в сторонку. Я долго думала, как к ней вернуться, потому что длинные тексты - моя слабая сторона. Решила идти маленькими шагами и публиковать в ТГ канале небольшие посты, а тут собрать их в полноценный гайд. Буду благодарна, если поделитесь этими статьями с начинающими аналитиками. Мне бы очень хотелось, чтобы этот контент принес как можно больше пользы.

11.12.2024    326    0    SerjoginaMaria    2    

2

Личная эффективность Продуктовый подход Работа с заинтересованными сторонами Бесплатно (free)

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

18.11.2024    272    0    Radio_Analyst    0    

2

Анализ предметной области Анализ потребностей и поиск решений Бизнес-аналитик Бесплатно (free)

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

04.09.2024    534    0    alenkaiva    0    

3

Анализ предметной области Анализ бизнес-процессов Работа с заинтересованными сторонами Бесплатно (free)

Успех системы закладывается на предпроекте. Именно на обследовании мы анализируем потребности, перекладываем их в затраты, просчитываем нужное для разработки время и закладываем те функции, что будут в системе. От результатов предпроекта зависит, насколько система будет удовлетворять заказчика и насколько успешно мы систему сдадим. Расскажем о том, как за семь шагов провести обследование, построить концепцию и определить границы системы/проекта.

02.09.2024    1380    0    user1669221    2    

7

Анализ предметной области Анализ потребностей и поиск решений Бизнес-аналитик Руководитель проекта Управленческий учет Бесплатно (free)

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

19.08.2024    1720    0    SergeyN    0    

6

Работа с требованиями Бесплатно (free)

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

29.07.2024    4321    0    user1145928    2    

6

Кейсы проектов Работа с заинтересованными сторонами Бесплатно (free)

Бывают ситуации, когда обновление изрядно измененной 1С с большой базой не составляет особых трудностей — до определенного момента. Таким моментом становится, например, переход на новую подредакцию. После чего приходит понимание, что обновлять, как раньше — уже не получается и нужно что-то менять.

12.07.2024    1161    0    1c-izh    1    

5

Лидерство Личная эффективность Agile Анализ потребностей и поиск решений Бесплатно (free)

В семнадцатом выпуске второго сезона подкаста Радио “Аналитик“ обсудили, что из себя представляет модель Кеневин, чем и в каких ситуациях она может быть полезна тем, кто работает в сфере ИТ и не только.

19.04.2024    1168    0    Radio_Analyst    0    

5
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. SirAlex 12.12.24 10:44 Сейчас в теме
О, оперативно!
А может сюда несколько слайдов для улучшения восприятия, например, по одному для каждой категории? :)
Созинов; SerjoginaMaria; +2 Ответить
2. SirAlex 12.12.24 10:52 Сейчас в теме
Или одну на всех более сжато, например как на слайде во вложении.
Прикрепленные файлы:
4. SerjoginaMaria 93 12.12.24 13:52 Сейчас в теме
(2) Да, здоровски выглядит, дополню :)
3. malikov_pro 1325 12.12.24 13:11 Сейчас в теме
Заголовок не соответствует содержанию, с общего описания свалились в анализ книги

Визуализация - рисовать в visio или подобным неудобно/ сложно в поддержке (изменения), нужны ссылки на инструментарий. Связанность с системами управления требованиями.

И ссылки на свои статьи добавить как расшифровку (Business Objectives Model) https://infostart.ru/pm/1626588/

Желательно указывать первоисточник https://argondigital.com, кроме них особо информации нет.

Интересно состыковывается ли с C4.
Созинов; +1 Ответить
5. SerjoginaMaria 93 12.12.24 13:54 Сейчас в теме
(3) В моем случае первоисточник - книга, о которой речь в статье. Рассказываю только про сам язык, инструментарий может быть любой. Про связь с С4 сложно сказать, сама пока в процессе изучения моделей целей.

https://infostart.ru/pm/1626588/ написана давно, хочу освежить с учетом информации, которую знаю сейчас, позже свяжу статьи :)
Оставьте свое сообщение