Пример матрицы трассировки требований
Матрица трассировки — метод визуализации связей между элементами системы в форме таблицы.
Матрица трассировки создается путем связывания бизнес-требований с вариантами использования и сценариями тестирования, которые будут использоваться для их проверки. В процессе трассировки, отношения между бизнес-требованиями и вариантами использования + сценариями тестирования могут иметь следующий вид: один-к-одному, один-ко-многим или многие-к-одному. Трассировка требует уникальных идентификаторов для каждого требования и вариантов использования/сценариев тестирования. Трассировка обеспечивает полноту тестирования и подготавливает основу для планирования тестов. Матрица трассировки может быть самостоятельным документом или может быть включена как часть документации по требованиям или часть плана тестирования.
Примеры картинок с трассировочными матрицами
Пример 1 
Пример 2 
Пример 3 
Пример 4 
Инструкции:
В соответствии с лучшими практиками, бизнес-требования следует декомпозировать до мельчайших пакетов и нумеровать в соответствии со следующими правилами нумерации: BR001, BR002 и т.д. Для каждого бизнес-требования будет одно или несколько функциональных требований, которые должны соответствовать соглашению по нумерации для соответствующего бизнес-требования: FR001.01, FR001.02, FR001.03, FR002 и т.д. Функциональные требования должны быть декомпозированы до мельчайших пакетов.
Для каждого функционального требования будет существовать одна или несколько связанных технических спецификаций, которые должны соответствовать соглашению по нумерации для связанных функциональных требований: TS001.01.01, TS001.01.02, TS001.01.03 и т.д. Технические спецификации должны быть декомпозированы до мельчайших пакетов.
Для простоты, технические спецификации могут храниться в отдельной таблице.
ID Матрицы — уникальная последовательность для идентификации комбинации требований и связанных с ними вариантов использования.
# Бизнес-требования — номер бизнес-требования (в соответствии с документацией по требованиям), который идентифицирует критерии успеха, на основе которых будут выполняться тесты.
# Функциональные требования — идентификационный номер функционального требования (в соответствии с документацией по требованиям), которое исполняет указанное бизнес-требование.
# Вариант использования — идентификационный номер варианта использования, который будет использоваться для проверки соответствия бизнес-требований с функциональными требованиями. Этот параметр должен соответствовать ID в документе по требованиям. Поле является необязательным для заполнения.
# Сценарий тестирования — идентификационный номер тестового скрипта, который будет использоваться для проверки связанных бизнес или функциональных требований.
Вы можете создать таблицу со следующими столбцами и строками:
Трассировка требований что это
С каждым элементом трассируемости связан собственный набор атрибутов (см. Атрибуты требований), который применяется для анализа состояния, преимуществ, рисков и прочих факторов, связанных с элементом.
Назначение трассируемости
Трассируемость позволяет выполнить следующее:
Трассируемость помогает понять, как входные требования, такие как бизнес-правила и запросы заинтересованных лиц, преобразуются в спецификации ключевых потребностей заинтересованных лиц и пользователей и системные функции, как описано в документе Видение. В свою очередь, модель варианта использования описывает, как эти возможности реализуются в функциональной системе. Особенности взаимодействия системы с внешней средой описаны в вариантах использования, наряду с прочими важными требованиями, в том числе и не относящимися к функциям, и ограничениями проекта согласно вспомогательным спецификациям. Трассируемость также обеспечивает возможность контроля за тем, как эти спецификации воплощаются в проекте, как они тестируются, и как документируются для пользователя. Для больших систем варианты использования и вспомогательные спецификации вместе могут составить спецификацию требований к программному обеспечению (SRS) для какой-либо функции или подсистемы.
Ключевым в работе с изменениями требований является понятие «недостоверной» связи трассируемости. Когда изменяется требование или другой элемент трассируемости, все связи трассируемости, ведущие к этому элементу, помечаются как недостоверные. Ответственные за эти связи должны будут изучить изменение и определить, требуется ли изменение также и соответствующих элементов. Это понятие также способствует анализу влияния потенциальных изменений.
Элементы трассируемости также позволяют ответить на следующие вопросы:
В документе Видение для системы по утилизации отходов может быть указана следующая возможность:
FEAT10: распознавание новых типов бутылок системой.
Эта возможность трассируется в варианте использования «Добавить новый тип бутылки»:
В варианте использования Добавить новый тип бутылки оператор настраивает машину на распознавание новых типов бутылок.
Такая трассируемость позволяет удостовериться, что все возможности были учтены в вариантах использования и вспомогательных спецификациях.
Типичные элементы трассируемости
Ниже перечислены наиболее распространенные элементы трассируемости:
| Потребности пользователей и заинтересованных лиц (из документа Видение, могут быть далее сведены к запросам заинтересованных лиц) |
| Возможности продукта (из документа Видение). |
| Вспомогательные требования (из документа Вспомогательные требования.) |
| Вариант использования |
| Раздел варианта использования (подробные описания варианта использования). |
| Элемент проекта (из документа модель проекта). |
| Комплект тестов (или, возможно Тестовый набор). |
Полезно также трассировать и другие элементы, такие как бизнес-правила и замечания.
Типичный вариант трассируемости показан на следующей схеме:
Эта диаграмма отражает трассируемость только в отношении требований. Могут также существовать и другие элементы трассируемости, не показанные на схеме: элементы проекта трассируются в элементах реализации, могут быть предусмотрены тестовые наборы для проекта и реализации и т.д.
© Copyright IBM Corp. 1987, 2006. Все права защищены..
Методы определения требований в программной инженерии
3.1.5. Трассировка требований
Одной из главных проблем сбора требований является проблема их изменения. Требования создаются итерационно путем постоянного общения представителей заказчиков с аналитиками и разработчиками будущей системы в целях выявления потребностей. Требования изменяются в зависимости от задач и условий их определения, а также постоянного уточнения на этапе заключения договора на создание системы. На момент заключения договора состав требований, их виды и свойства становятся более полными, т.е. соответствуют взглядам заказчика на создаваемую систему [3.4].
Методы трассировки базируются на формальных спецификациях связей между элементами требований либо ограничиваются описаниями функций, ситуаций, контекста и возможных решений. Основу трассировки составляют:
Процедура трассирования состоит в следующем:
Условием принятия решения о возможных модификациях требований и результатов промежуточного проектирования, является обновленная информация о связях между различными частями системы и первоначально заданными требованиями к ним. Трассировка обеспечивает:
Трассировка может быть выборочной для отдельных объектов или связанной с другими объектами, а также с возможными переходами от одной модели проектирования к другой путем проверки трансформации одних объектов в другие.
3.2. Объектно-ориентированная инженерия требований
3.2.1. Сценарный подход
Одним из методов построения проектной модели системы, логической и физической моделей являются сценарии use case, используемые для визуального представления требований в проектной модели системы. Эта модель уточняется и дополняется новыми сценариями для получения логической и физической моделей. Термин сценарий обозначает некоторый вариант представления модели выполнения системы [3.1, 3.5].
При применении сценарного подхода общая цель системы декомпозируется на отдельные подцели, для которых определяются функциональные или нефункциональные требования и проектные решения. Цели, как источники требований к системе, позволяют выявить противоречия и ограничения на выполнение функций и установить зависимости между ними, устранить конфликты между целевыми функциями, а также объединить некоторые из них между собою в определенные отношения.
После выявления целей определяются носители интересов, которым отвечает каждая цель, и возможные варианты удовлетворения составных целей в виде сценариев работы системы, которые помогают пользователю получить представление о назначении и функциях системы. Это соответствуют первой итерации определения требований к разработке системы.
Далее производится последовательная декомпозиция сложной проблемы к виду совокупности целей, каждая из которых трансформируется в совокупность возможных сценариев использования системы, а затем в совокупность взаимодействующих объектов.
Т.е. имеем цепочку трансформаций:
проблема 
цель сценарий объект.
Она отражает степень концептуализации анализируемой проблемы, и ее декомпозицию с помощью вариантов использования для снижения сложности системы. Трансформация данной цепочки выражается в терминах базовых понятий проблемной области и активно используется для представления и развития моделей системы.
Каждый сценарий инициирует актор, выступающий в роли пользователя определенной работы в системе, представленной этим сценарием. Фиксацию ролей акторов можно рассматривать как определенный шаг при выявлении целей системы и постановщиков задач, для решения которых создается система.
ПС, то он будет представлять ее интересы. При этом одно лицо может быть экземпляром нескольких акторов.
Если актор находится вне системы, то он взаимодействует с ней через сценарий, который инициализирует последовательность операций для выполнения системы. Когда пользователь, как экземпляр актора, вводит определенный символ для старта экземпляра соответствующего сценария, то это приводит к выполнению ряда действий в системе, которые заканчиваются тогда, когда экземпляр сценария находится или в состоянии ожидания очередного входного символа или завершения сценария
Экземпляр сценария существует, пока он выполняется и его можно считать экземпляром класса, он имеет состояние и поведение. Взаимодействие между актором и системой порождает новый сценарий или объект, которые изменяют внутреннее состояние системы. Если несколько сценариев системы имеют одинаковое поведение, то их можно рассматривать как класс сценариев.
Можно выделить базовую цель событий, существенную для сценария, и альтернативную в случае ошибок пользователя и др. Для задания модели сценариев используется специальная графическая нотация со следующими правилами:
Пример диаграммы сценариев для читателя библиотеки в роли актора, который запускает заданный сценарий при обращении к автоматизированной системе обслуживания библиотеки, представлен на рис. 3.4.
Все сценарии, которые включены в систему, обведены рамкой, определяющей границы системы, а актор находится вне рамки, являясь внешним фактором по отношению к системе.
Confluence в жизни аналитика — Часть 2
Всех с наступившим 2015 Годом! В прошлом году мы с вами познакомились с базовыми возможностями Confluence и немного рассмотрели его с позиции “просто пользователя”.
Сегодня приготовим теплый напиток, устроимся удобнее у камина после праздничной суеты и, наслаждаясь спокойствием долгожданных выходных, рассмотрим Confluence в работе бизнес-аналитика, чтобы ты, дорогой читатель, мог начать первую рабочую неделю с прочтения этой самой статьи.
Трассировка требований в работе аналитика
Если провести опрос, то наверняка большинство наших с вами коллег знают, что такое матрица трассируемости, и при этом большинство не использует её на практике. Причины понятны: если в проекте несколько тысяч требований, не так просто осилить матрицу такой размерности. Никого не хочу обидеть, но для меня матрица трассируемости так и осталась академическим понятием. Однако это совсем не означает, что не нужно решать проблему взаимного влияния одних требований на другие. Ещё как надо! Чем больше проект и чем вы ленивее, тем более остро может стоять такая задача.
Поскольку Confluence изначально не является инструментом управления требованиями, он не предлагает готовое решение, как, например, готовая матрица трассируемости. Зато у него есть кое-что получше… 😉
Итак, как же упростить поддержку требований? Как работать так, чтобы описание можно было использовать повторно, не копируя каждый раз и не исправляя одно и то же в куче мест в спецификации?
Признаюсь, то что предлагает для этого Confluence – одна из моих любимых особенностей работы с этим инструментом.
Прежде чем рассказать о трассируемости, хочется сказать про возможность встроить одну страницу в другую с помощью макроса
Так вот, есть и другое решение для упрощения поддержки требований, которое позволяет разместить все нужное в одном месте без нанесения ущерба структуре документа.
Представьте себе ситуацию классического изменения требования: спонсор продукта захотел, чтобы дата создания заказа в системе управления заказами повсюду отображалась не просто датой, как раньше, а датой со временем. Более того: в специально указанном формате!
Положим, у вас на проекте принят такой стиль описания требований, который предполагает, что каждый экран интерфейса пользователя и элементы управления имеют подробное текстовое описание каждого поля. У вас же:
100500 страниц системы работы с заказами.
вы хотите обновить требование к одному из важнейших полей заказа.
здоровая аналитическая лень отбивает всякое желание обновлять 100500 страниц спецификации, где упоминается дата заказа.
Создадим страницу для описания объекта “Заказ”. Тут опишем все поля объекта, включая поле “Дата заказа”. Каждому полю присвоим уникальный идентификатор (для даты заказа у нас будет идентификатор БО-ПЗ-80),
Во всех местах спецификации, где используется Дата Заказа, делаем ссылку на описание данного поля с указанием придуманного выше идентификатора БО-ПЗ-80, обозвав его, например, “Источник данных” – намекнем тем самым на структуру базы, что особо оценят программисты.
И немного волшебства: добавим колонку “Где Используется”, которая динамически отобразит список страниц, в которых упомянута наша дата (поле БО-ПЗ-80), решив тем самым проблему трассировки!
Страница описания объекта может выглядеть примерно так (на иллюстрации смотрим нижнюю строчку и колонку “Где используется”):
А так выглядит страница описания экрана со ссылками на описание полей бизнес-объекта (на иллюстрации смотрим колонку “Источник данных” и ищем строчку про дату заказа):
Таким образом, в последней колонке “Где используется” у вас всегда найдётся список страниц, который можно смело отдавать в тестирование для проверки того, что новый формат даты успешно изменён везде, как и требовалось в нашей задаче.
Чтобы овладеть магией, вам понадобятся только два макроса:
Справедливости ради надо отметить, что интересный способ связи требований предлагают автоты плагина Requirement Yogi (видео 2:15 https://www.youtube.com/watch?v=mHC13NVg3KA).
А что если он захочет подписать документ?
Все скептики говорят примерно одно и то же: “Ваша вики это, конечно, модно и молодёжно, но мой заказчик требует пачку бумаги на стол, которую можно полистать и подписать”. На самом деле, этого же зачастую желают и руководители наших коллег, так что посыл, как говорят, понятен 🙂
Что касается темы подписи, то можно заморочиться и предложить рассмотреть дополнения, призванные настроить процесс работы с каждой страницей, процесс её утверждения и публикации. Примеры таких плагинов:
Однако понятно, что на самом деле вопрос о подписании документов задают не для того чтобы поговорить о реализации процессов жизненного цикла требований, а о возможности представить требования в старом добром и понятном виде документа, который можно пролистать от начала и до конца. Так вот, Confluence предлагает ряд возможностей для получения документов в удобном для печати олдскульном виде.
Опции для экспорта контента доступны из меню пользователя Tools:
Export to PDF – сохранить текущую страницу как PDF.
Export to Word – сохранить текущую страницу как Word-документ.
Export Page Tree to Word – сохранить дерево страниц как Word-документ – самая популярная возможность, когда нужно подписать целую спецификацию, состоящую не из одной, а из множества страниц вики.
А такие опции доступны администраторам:
Организация требований, и какие бывают правила
Так вот, Confluence не навязывает никаких правил. Немного выше мы с вами создали страничку для описания бизнес-объекта и несколько страниц для функциональных требований, просто потому что нам с вами так захотелось, исходя из целесообразности в конкретной задаче.
Если вам не понравилась получившаяся иерархия страниц, то страницы можно легко отсортировать, как вам нравится: например, отделить Бизнес-Объекты от Функциональных Требований.
Кроме создания иерархии требований бывает необходимо унифицировать структуру самих страниц. Например, вы хотите, чтобы все страницы, описывающие функциональные требования, содержали секцию с кратким описанием, секцию с макетом или эскизом экрана, секцию с бизнес-правилами, описание элементов управления, которые присутствуют на странице, и, возможно, тексты сообщения для пользователя, которые могут встретиться при работе с описываемым на странице экраном.
Для этого постройте шаблон страницы, и впоследствии вы не только сэкономите себе время, создавая новую страницу с использованием этого шаблона, но и облегчите задачу начинающим коллегам.
Шаблон можно настроить в рамках вашего проекта или глобально для всех проектов, если вы администратор.
Впоследствии ваш шаблон будет отображён в списке выбора, который появляется при попытке создания страницы.
В Atlassian Market можно найти массу существующих бесплатных шаблонов. Начиная с некоторого времени, они стали называться Blueprint. Подробнее об этом пишут на сайта документации от Atlassian:
Таким образом, используя Confluence, вы в праве сами определять правила оформления требований. В тоже время для неприхотливой аналитики, можно вполне обойтись и готовым решением от Confluence “из коробки”.
Про работу с Jira и заморозку версий спецификации
Приходилось ли вам сталкиваться с жалобами команды на то, что они запутались и не могут разобраться в спецификации, а именно: непонятно, что из написанного нужно читать и кому именно это нужно, а что следует проигнорировать. Например, с точки зрения специалистов по контролю качества, может быть неочевидно как подойти к написанным требованиям, когда часть задокументированного функционала уже реализована и должна быть проверена, а другая часть ещё в разработке.
Если такой вопрос поднялся, то это не что иное, как увесистый камень в чудесный сад управления процессами на проекте. Часто случается, что именно аналитик отвечает если и не за все процессы, то, как минимум, за процесс управления требованиями. И действительно, коллеги, ввиду особенностей нашей с вами профессии мы склонны генерировать много контента, не всё из которого предназначено для немедленного прочтения каждым участником команды. Как известно, один из признаков эффективного стиля работы – умение беречь время своих коллег.
Так вот, если вернуться к тому, что от нас требуют, простыми словами, то от нас требуется понятно обозначить нужное и ненужное, важное и неважное, сделать это с учётом актуальной ситуации, особенностей проекта и роли на нём каждого отдельно взятого читателя проектной документации.
Для решения такой задачи можно традиционно предложить два подхода, как минимум. Один краше другого — выбирайте любой или комбинируйте, смотря чего вы на самом деле добиваетесь 🙂
Вариант “внедрить и задействовать систему управления задачами”.
Вариант “задействовать версионность, которая присутствует в арсенале Confluence”.
Рассмотрим оба подхода.
В первом случае нам нужна система управления задачами, коей Confluence не является. Конечно, можно написать строчку текста, сказать, что эта строчка – на самом деле, задача, назначить ей дату исполнения и ответственного. Действительно, если это можно сделать в Excel, то почему это делать в Confluence?
Однако я настаиваю на том, что Confluence – это инструмент для совместной работы, но никак не система управления задачами. Поэтому в первом подходе мы предположим, что на вашем проекте задействована некая система управления задачами, которая позволяет контролировать сроки, назначать виновных и в целом, отслеживать прогресс на проекте. Jira – одна из таких систем, но если у вас TFS, IBM Rational, Mantis, Bugzilla, Redmine или что-нибудь ещё, что позволяет управлять задачами – это всё равно отлично сработает.
Идея в том, чтобы в Confluence держать подробное описание требований, а в системе управления задачами вести задачу со всеми её атрибутами и контролировать статус её выполнения в пределах жизненного цикла задачи в указанной системе. Простыми словами, в Jira мы указываем, что в рамках задачи Задача-Х100500 нужно добавить дату и указываем тут же, в подробностях задачи, ссылки на описание соответствующих страниц в Confluence с идентификаторами требований, касающихся даты:
Затем задача Задача-Х100500 в состоянии “Назначена” уходит к своему счастливому обладателю.
С другой стороны, в Confluence в каждом из указанных требований мы укажем идентификатор задачи, в рамках которой она должна быть выполнена (на иллюстрации смотрим колонку “Задача”).
Теперь для того, чтобы понять, реализовано ли поле “Дата”, будет достаточно взглянуть на статус соответствующей задачи в системе управления задачами. Статус задачи может быть, допустим, “Назначена”, “Выполнена”, “Закрыта” или, скажем, “Переоткрыта” – в зависимости от внедрённой системы управления задач и настроенного в ней процесса со статусами. Таким образом, пометка идентификатора задачи напротив требования позволяет нам судить о том, как относиться к каждому требованию: как к реализованному или, например, только как к запланированному пока что.
Всё-таки нужно упомянуть дополнительно Jira за особо глубокую интеграцию, которая позволяет не только создавать Jira Issues из Confluence, но также с помощью макроса
Второй подход, про версионность – это примерно то, что делает сам Atlassian в своей документации. Каждый раз, когда выходит новая версия продукта, документация для предыдущей версии остаётся, но волшебным образом появляется и новая, очень похожая на старую, только более актуальная документация к последней выпущенной версии продукта!
На одном из проектов в моей практике накопилось слишком много разных цветных замечаний к каждому требованию. Особенность того проекта была такова, что для одних и тех же требований создавалось очень много изменений, которые в конце концов сильно засоряли документацию. Действительно, когда напротив описания требования к дате вы встретите более 2-х задач (где первая задача была на создание поля, а вторая – на его изменение), то становится проблематично определить, какова же судьба этого требования сейчас. Тогда было принято решение скопировать всю проектную документацию в новое пространство, очистить в скопированной версии все упоминания о будущем функционале и заморозить получившуюся копию, присвоив ей соответствующий номер релиза. Таким образом, у нас получилась документация, актуальная для определённого релиза нашего проекта.
В текущей версии мы удалили упоминание всех “устаревших” выполненных и закрытых задач, обеспечив тем самым “чистоту” описания и читабельность. У нас была “активная” версия документации, которая развивалась вместе с проектом и было несколько замороженных версий.
Если вы откроете любую статью документации Confluence (для примера, https://confluence.atlassian.com/display/DOC/Start+your+trial), то вверху страницы вы обнаружите текст о том, к какой версии продукта относится статья, которую вы сейчас смотрите. Там же вы найдёте ссылку на все имеющиеся версии.
В нашем случае мы сделали даже интереснее: добавили в аналогичный блок ещё ссылку на эту же страницу в самой последней версии. Такая ссылка “Открыть это требование для последней версии продукта” у нас была доступна из старых “замороженных” версий документации. Вы тоже можете её сделать с помощью макроса
Такой процесс “Cрез версии” достигается копированием всего пространства в момент заморозки кода, а все описанные ссылки на другие версии настраиваются администратором как разметка страницы на уровне пространства вашего проекта. Таким образом, пояснение про версию отображается динамически на каждой странице пространства, и никому не нужно писать об этом, каждый раз создавая нужную страницу.
Так работает дополнение “Copy Space”:
Настройка разметки страницы:
К сожалению, последняя версия Confluence не поддерживает дополнение Copy Space Plugin, однако вероятно, что это только вопрос времени, когда выйдет обновление для плагина: https://marketplace.atlassian.com/plugins/com.atlassian.confluence.plugin.copyspace/versions#b22
А если не выйдет, то же самое можно попробовать сделать через экспорт и импорт всего пространства.
Идеологически мне очень нравится этот подход, но только при условии чтобы НЕ мне пришлось заниматься “зачистками” после каждой “заморозки” документации 🙂
Всё-таки описанный процесс предполагает существенные временные затраты на поддержание чистоты в момент поставки каждой новой версии документации.
Кажется, мы рассмотрели всё самое популярное из того, что мне нравится в работе с Confluence.
В качестве заключения надо сказать, что Confluence следует рассматривать, в первую очередь, как к средство совместной работы над контентом, коим являются в нашем случае требования. Прочие функции, такие, как управление задачами, планирование и контроль работ на проекте, разумно оставить специально предназначенным для этого другим инструментам, многие из которых могут быть успешно интегрированы с Confluence.
Наряду с таким пониманием, самым главным преимуществом Confluence для меня является свобода организации контента. Вы сами решаете, какой будет структура документации на вашем проекте или у вас в организации.
Таким образом, научившись “правильно готовить контент” так, как это нравится именно вам, Confluence сослужит вам отличную службу.
Было бы интересно увидеть ваши примеры использования Confluence в работе BA и в любой другой работе 🙂
Автор:
Денис Ардабацкий
