Данные vs документы при разработке и управлении требованиями

Чтобы управлять требованиями, их нужно идентифицировать - эта простая идея лежит в основе всех систем управления требованиями.

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

Сравните активное хранение требований и их связей в системах управления требованиями и пассивное хранение требований в документах.

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

Или с помощью матрицы трассировки проконтролировать покрытие функций тестами, как показано на рисунке 3.

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

Каждая система управления требованиями может похвастаться своим набором аналитических представлений. Ниже несколько примеров таких представлений из 3SL Cradle, Devprom и IBM DOORS.

Пример 1. Автоматически построенная матрица трассировки (Рисунок 4), отражающая статус User Story, в которых заинтересован конкретный заказчик (3SL Cradle, схема настройки для Scrum, щелкните для увеличения):

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

Пример 2. Автоматически построенная матрица трассировки (Рисунок 5), отражающая метод и статус тестирования для системных требований в развертке по подсистемам (3SL Cradle, демо-проект):

По этой матрице легко оценить общий прогресс тестирования как в разрезе по требованиям, так и по подсистемам. Например, мы видим, что все тесты по подсистеме Propeller пройдены, а вот с Main Battery наблюдаются некоторые проблемы.

Пример3. Несколько иной разворот проектных данных - автоматическое представление (Рисунок 6), отражающее покрытие требований тестами, а также результат выполнения тестов  - пройден/не пройден. Представление развернуто от тестов к требованиям и за счет того, что выводится еще и тип требования, легко понять, на какие параметры системы повлияют непройденные тесты. В данном случае - на производительность.

Пример 4. Это автоматическое представление (Рисунок 5), отражает покрытие требований функциями и тестами (Devprom, демо-проект) и позволяет быстро оценить полноту проработки проекта:

Пример 5. И еще одна автоматическая развертка (Рисунок 6), полученная на основании связей и  отражающая покрытие пользовательских требований функциональными требованиями и функциональными тестами (IBM DOORS):

На этом представлении легко заметить ошибку - требование пользователя UR-151 осталось не охваченным при проектировании.

Все представленные примеры соответствуют так называемому data-centric подходу - подходу к разработке и управлению требованиями, ориентированному на данные. Сегодня это наиболее востребованный подход (3), поскольку именно он позволяет справляться меньшими силами с большими объемами требований и проектных данных.

В противовес data-centric подходу при документо-ориентированном подходе (document-centric) идентифицируются только документы в целом, а не отдельные требования (2). Требования и связи хранятся в документе и неотделимы друг от друга и как следствие:

• все атрибуты: статусы, приоритеты и др., присваиваются документу в целом, а не отдельным требованиям/связям, а значит точность управления проектом невысока.
• Все функции командной работы: блокировка на редактирование (check in/out), дискуссии и др., работают только для документа в целом, а значит сложно распараллелить работу.
• Права доступа и область видимости настраиваются только для документа в целом.
• Управление версиями тоже выполняется относительно целого документа.

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

Теперь легко понять ответ на вопрос, который прозвучал в комментариях к статье "Мозг системного аналитика глазами команды": почему в обзоре систем управления требованиями не учтен Confluence?

В той статье было проведено сравнение систем управления требованиями по гибкости информационной модели -  возможности настроить свою модель проекта (6). Это важный параметр системы управления требованиями, который определяет:

• возможность настройки инструмента под процессы конкретной организации.  Это касается и стартовой модели проекта и возможности ее расширения, ведь какая бы ни была начальная модель управления требованиями, со временем все равно захочется ее расширить. Это возможно будет сделать ровно настолько, насколько позволит выбранная система управления требованиями.
• Аналитические возможности системы. Например, если в системе управления требованиями допускается использование только одного типа связи, то чтобы найти, конфликтующие требования, необходимо пересмотреть все требования, связанные с данным, а их может быть довольно много! Если система позволяет настроить свои типы связей, то отфильтровать связанные требования по типу связи КОНФЛИКТУЕТ можно будет за один клик.

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

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

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

С точки зрения работы с требованиями Word, Google Docs, Confluence, а также другие wiki - это всё документо-ориентированные системы. Нет никаких сомнений в том, что в Confluence устанавливать связи между документами удобнее, чем в Word, но технологические принципы, и, как следствие, технологические ограничения у них одни и те же (7).  И это ключевое их отличие от систем: 3SL Cradle, Axiom, Devprom, JIRA, DOORs, Redmine, в которых используется технология, ориентированная на данные.

Поэтому  участие  Confluence в сравнении в этом классе систем было бы некорректно. Его необходимо сравнивать с системами такого же класса, т.е. документо-ориентированными, например, MediaWiki.

Примечания.

(1) Конкретные аналитические возможности зависят от системы и выбранной модели трассировки требований.

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

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

(4) Распространенные типы связей: часть-целое, класс-подкласс, источник-следствие, дублирование, конфликт, реализовано в.

(6) Примеры таких моделей можно посмотреть в статье "Зоопарк трассировки".

(7) Именно поэтому Confluence часто используется в связке с системой того же производителя - JIRA. Аналитическая мощность этой связки равна аналитической мощности JIRA, т.к. в данном случае она выступает как система управления требованиями.

Литература

1. Мадорская Ю.М. Зоопарк трассировки. Обзор, классификация, рекомендации. [электронный ресурс]/Ю.М. Мадорская, 2012. - Режим доступа: http://edu.reqcenter.pro/?p=1539, свободный. - Загл. с экрана