Многие методологии требуют сначала описать требования к системе как черному ящику и лишь затем переходить к проектированию и построению моделей. Способам такого описания посвящена инженерия требований. Однако, это присуще и Agile-методам, ведь User Story тоже описывает систему как черный ящик. Целью такого подхода была гарантия, что разработанная система будет пригодна для использования, внедрение пройдет гладко. Проблема в том, что так — не работает. А значит, нет смысла чересчур углубляться в требования, а стоит быстро переходить к моделям системы, которые можно строить по-разному.

В замысле было написать одну статью о разных вариантах работы с требованиями и моделями, но материал получился слишком большой, поэтому будет серия. Подходу Domain Driven Design, который основан на работе с моделями, будет посвящена вторая статья, а light-методы написания требований при применении Agile-методов организации разработки — третья. А в этой статье мы обратимся к первоначальным идеям и методологиям классической инженерии требований.

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

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

Таким образом, мы имеем ситуацию, когда разработчики и заказчики говорят на разных языках, и этот разрыв необходимо преодолеть. Желательно без ошибок и искажений перевода. Был предложен следующий метод: опишем будущую систему как черный ящик на языке требований таким образом, чтобы заказчики смогли по описанию проверить: если система будет удовлетворять требованиям, она будет пригодна для использования. А после проектирования устройства системы проверим, что если систему реализовать по проекту, то требования будут выполнены. Таким образом, всю неопределенность проекта унесем на этап проектирования, и после разработки система, если она удовлетворяет требованиям, окажется пригодна для использования. Схематично это отражено на слайде из моего доклада на SECR-2018 «Мыслить проектно: история и современность»

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

Классическая книга по разработке требований — Карл Вигерс, «Разработка требований к программному обеспечению», 1999

Каким же образом ее предлагали решать? Первый вопрос: а каким образом писать требования? Очень быстро выяснилось, что обычный, естественный язык для этого слабо пригоден, потому что слова неоднозначны, употребление зависит от контекста. А замысел требовал, чтобы была возможность достаточно формальной проверки.

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

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

Описание бизнес-процессов не единственный способ описания бизнес-архитектуры компании. Различным способам описания был посвящен мой доклад на ЛАФ-2022 «Бизнес-архитектура: от цепочки создания ценности до автоматизации бизнес-процессов»

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

Простая схема интерфейсов: таблицы с фильтром для просмотра информационных объектов и выполнения действий над ними, карточки для создания и изменения одного объекта. Позднее, с развитием ООП, такая форма интерфейсов была названа Naked Objects, при этом возможными действиями являются вызовы методов объектов

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

Устойчивая форма требований: схема бизнес-процессов и информационных объектов — документов и справочников, привязка к шагам бизнес-процесса действий с информационными объектами. Дополняется диаграммами состояний для документов, которые отражают, на каком шаге бизнес-процесса сейчас выполняется обработка документа

Что касается организации кода, то тут предлагается использовать наработанные архитектурные шаблоны. Одна из классических книг, посвященных этому, — Мартин Фаулер, «Шаблоны корпоративного приложения» — опубликована в 2002 и развивает его же книгу 1996 года Analysis Patterns: Reusable Object Models.

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

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

Внимание к интерфейсам породило средство описания — сценарии использования системы пользователем, use case. В них прорабатывается, как именно взаимодействует пользователь с системой для достижения своих целей. Этот метод предложен Иваром Якобсоном в 1987, классическая книга Алистера Коберна была опубликована в 2001, а в 2011 Ивар Якобсон предложил существенное развитие use case 2.0, адаптированное для итеративной разработки.

Классическая книга по написанию use case — Алистер Коберн, Writing effective use cases, в русском переводе «Современные методы описания функциональных требований к системам», 2001

Работа над интерфейсами породила новые специализации: дизайнера интерфейсов, а затем специалиста по эргономике, usability. Много позднее, после широкого распространения public web, появилась следующая специализация — UX-специалист, который отвечает за то, чтобы в интерфейсах не просто было удобно работать, а чтобы эта работа была интуитивно понятна и могла быть освоена пользователями без обучения.

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