Трассировка требований к ас полезна для

Borland Caliber – одно из специализированных средств управления требованиями, поддерживающее трассируемость

Трассируемость позволяет описывать и отслеживать связи между различными артефактами требований — бизнес-требованиями, системными требованиями в различных формах (в том числе в виде вариантов использования), а в широком смысле и артефактами процесса разработки вообще.

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

Назначение

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

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

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

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

Разновидности

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

В более сложном случае, связь может принадлежать к одному из предопределенных фасетов (например “тестируется с помощью”, “вытекает из”, “является частью”). Таким образом увеличивается гибкость возможных выборок по связям между артефактами, однако, это происходит за счёт существенного усложнения модели. Очевидно, что использование второго подхода может быть оправдано только для крупных проектов со сложной структурой требований.

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

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

Инструментальная поддержка

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

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

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

Специализированные семейства программных продуктов управления жизненным циклом ПО обычно включают средства управления требованиями с поддержкой трассируемости. Отличительной чертой таких средств является включение или интеграция средств импорта требований из различных источников, поддержка визуального моделирования (в основном, на основе UML), тесная интеграция со средствами документирования. При этом автоматизирована работа с трассировками — анализ изменений и генерация отчетности о них (в том числе матриц трассировок), настраиваемые механизмы уведомлений заинтересованных лиц об изменениях, с учётом зон ответственности и зависимостей. В целом, такие средства позволяют снизить трудозатраты на поддержку механизма трассировок, при этом обеспечивая более гибкое их использование. Успех их применения, однако, как и многих других средств автоматизации, зависит от особенностей конкретного проекта, качеств команды разработчиков, степени зрелости процесса разработки ПО в компании в целом.

К специализированным средствам управления требованиями, поддерживающим трассируемость, относятся, в частности, средства Borland Caliber, IBM Rational RequisitePro, (IBM) Telelogic DOORS, Sparx Enterprise Architect, 3SL Cradle,

В рамках проекта Eclipse инициировано создание Open Source Requirements Framework, предназначенного для создания модели управления требованиями, а также инструментов на её базе.

Источники

Open Source Requirements Framework project. ORMF Requirements model 2.0
Wikipedia Contributors. Requirements Traceability

Источник

3.1.5. Трассировка требований

Одной из главных проблем сбора требований является проблема их изменения. Требования создаются итерационно путем постоянного общения представителей заказчиков с аналитиками и разработчиками будущей системы в целях выявления потребностей. Требования изменяются в зависимости от задач и условий их определения, а также постоянного уточнения на этапе заключения договора на создание системы. На момент заключения договора состав требований, их виды и свойства становятся более полными, т.е. соответствуют взглядам заказчика на создаваемую систему [3.4].

Одним из инструментов установления зависимости между сформулированными требованиями и их изменениями является трассировка, т.е. поддерживается развитие и обработка требований с прослеживанием идентифицированных связей, которые должны быть зафиксированы по двум направлениям – от источника требований к реализации и, наоборот (рис. 3.3.). Выявляются причины появления разнообразных неточностей, добавлений и определяется необходимость внесения изменений в требования в одном из приведенных направлений.

Рис.
3.3.
Типы трассируемости требований

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

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

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

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

Процедура трассирования состоит в следующем:

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

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

ввод более сложных отношений вместо простых связей или специфических отношений;
использование разных путей трассировки (между моделями или иерархическими связями);
ведение базы данных объектов трассировки и отношений между ними.

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

3.2. Объектно-ориентированная инженерия требований

В объектно-ориентированных подходах и методах разработки программных систем главным является объект. Объектно-ориентированный подход, в частности UML моделирование позволяет с помощью вариантов использования задавать требований. Основные средства UML к формированию и представлению требований к системе и к ПО – это use case сценарии или прецеденты.

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

3.2.1. Сценарный подход

Одним из методов построения проектной модели системы, логической и физической моделей являются сценарии use case, используемые для визуального представления требований в проектной модели системы. Эта модель уточняется и дополняется новыми сценариями для получения логической и физической моделей. Термин сценарий обозначает некоторый вариант представления модели выполнения системы [3.1, 3.5].

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

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

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

Т.е. имеем цепочку трансформаций:

проблема цель сценарий объект.

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

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

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

ПС, то он будет представлять ее интересы. При этом одно лицо может быть экземпляром нескольких акторов.

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

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

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

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

актор обозначается иконой человека, под которой указывается название;
сценарий изображается овалом, в середине которого указывается название иконы;
актор связывается стрелкой с каждым овалом запускаемого им сценария.

Пример диаграммы сценариев для читателя библиотеки в роли актора, который запускает заданный сценарий при обращении к автоматизированной системе обслуживания библиотеки, представлен на рис. 3.4.

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

Рис.
3.4.
Пример диаграммы сценариев

Источник

Когда требования на проекте меняются “на лету” и у вас нет под рукой средства контроля за реализацией каждого отдельного требования по фиче или модулю, перед вами встает вопрос: как проводить анализ покрытия? Одним из таких инструментов, который использует наша команда QA на подобных проектах — матрица трассируемости (traceability matrix).

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

Что же такое матрица трассируемости?

По определению матрица трассируемости — двумерная таблица, содержащая соответствие функциональных требований продукта (functional requirements) и подготовленных тестовых сценариев (test cases).

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

Таким образом, таблица дает визуальное отображение двух параметров:

наличие в системе требований, которые еще не покрыты (если у требования нет ни одного пересечения с тест-кейсами (достаточное условие);
есть ли в системе избыточное тестирование — если требования имеет несколько пересечений (необходимое условие).

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

Поэтому матрица имеет вид таблицы, каждая строка которой содержит:

номер и описание задачи на разработку из таск трекера;
логический блок, к которому принадлежит задача (опционально);
атомарное требование или приемочный критерий (acceptance criteria);
приоритет;
номер и описание соответствующего тестового артефакта.

Так как мы используем таск трекер Jira, Zephyr by Jira для тестовой документации и систему управления требованиями Сonfluence, все сущности синхронизируются и такая трассируемость позволяет нам:

визуализировать актуальное состояние реализации;
разбивать требования на более атомарные и структурировать их;
отслеживать, есть ли требования, на которые еще не запланирована разработка (пропуск реализации);
отслеживать, реализовано ли требование в данный момент;
отслеживать, покрыто ли требование тест-кейсом (пропуск тестирования);
наглядно отображать приоритезацию требований.

Варианты связей в матрице трассируемости

Привязка требования и тест-кейса может быть:

1 к 1 (атомарное требование, которое покрывается одним тест-кейсом, данный тест-кейс покрывает только это требование);
1 к n (требование, которое покрывается несколькими тест-кейсами, данные тест-кейсы покрывают только это требование);
n к n (требование, которое покрывается несколькими тест-кейсами, данные тест-кейсы покрывают это и другие требования).

По поводу последнего пункта хочется отметить, что

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

У нас на проекте есть такие случаи, когда одно требование покрывается несколькими тестами и один тест может покрывать несколько требований (связи “1 к n” и” n к n”).

Специфика оценки покрытия с помощью матриц трассируемости

Если для оценки покрытия мы используем метрику “отношение количества требований к количеству тестовых артефактов”, то связи в матрице должны быть “1 к 1”, а требования максимально декомпозированы.

Пример. Имеем неатомарное требование: “Пользователь должен иметь возможность изменять и форматировать письмо в текстовом редакторе”. Одного тест-кейса явно будет недостаточно, но если в матрице будет прилинкован только один артефакт, визуально будет представление, что требование покрыто.

Поэтому лучше:

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

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

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

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

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

Оценка покрытия также рассчитывается отдельно для каждого модуля или фичи.

При таком подходе мы можем использовать метрику, описанную выше: “количество требований к количеству тестовых артефактов”. Даже если у нас есть связи 1 к n, n к n, у нас есть несколько компонентов, каждый из которых может быть использован в нескольких модулях. Требования и приемочные критерии описываются в каждой матрице, а тестовый артефакт используется один.

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

Создание и ведение матрицы

Создание матрицы включено в наш воркфлоу работы над задачами по аналитике.

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

И здесь можно выделить следующие этапы составления Traceability Matrix:

В начале требования декомпозируются и подлежат приоритезации командой QA иили product-owner. Результатом этапа становится структурированный и приоритезированный список всех требований по данной функциональности.
Вторым этапом будет общение с командой разработки и проставление задач из таск трекера на разработку в матрицу к соответствующим требованиям. В результате мы можем отследить трассируемость требований и задач на разработку.
Третий этап — разработка тест-кейсов и чек-листов.
Данный этап проводится или перед тестированием или во время тестирования конкретной задачи.
Если функциональность новая, и интерфейс будет изменяться, то могут быть кейсы, в которых шаги лучше описывать непосредственно перед началом тестирования задачи.
Если же функциональность по реализации схожа с одной из уже существующих фич, то мы может приступить к описанию тест-кейсов с шагами сразу после ревью и декомпозиции требований.
4 этап — заполнение матрицы тест-кейсами.
По результатам всего процесса мы получаем задачи на разработку, тест-кейсы на тестирование и матрицу трассируемости, объединяющую их и требования.
Задача на разработку требований закрывается.
5 этап — поддержка матрицы в актуальном состоянии. Изменения должны вноситься при любых модификациях требований. Также следует учитывать интеграционные связи между двумя матрицами, которые описывают разные фичи или модули, и при изменении в одной обязательно проверять, нет ли необходимости правки второй.

Сложности в работе с матрицей трассируемости

Актуализация
Матрица будет полезна только при условии, что она будет поддерживаться всегда в актуальном состоянии. На нашем проекте с часто меняющимися требованиями актуализация занимала много времени, но если матрицу не актуализировать, она становится не только бесполезной, но и вносит путаницу.
Как решали:
Частично решили проблему с частым изменение требований и перенесли этап создания матрицы на момент, когда требования уже просмотрены командой и подтверждены заказчиком.
Командой было принято решение, что аналитик будет актуализировать требования не только на самой странице с описанием фичи, но находить и актуализировать их в матрице, выделяя другим цветом. Это помогло всей команде не потерять изменения, а команде QA в частности — видеть какие тест-кейсы требуют актуализации.
Временные ресурсы
На проекте может быть срочный релиз и работа с новыми требованиями в одно и то же время, и все QA ресурсы направляются на тестирование, а не работу с требованиями. Таким образом, возрастает долг по тестовой документации.
Как решали:
Если все QA-специалисты заняты тестированием приоритетных задач, мы переносим создание матрицы по конкретной фиче. Максимально он переносится на момент тестирования первой задачи по этой фиче и в таком случае матрица заполняется тест-кейсами по мере тестирования задач, в которых реализована фича.
QA-специалист закладывает в оценку время не только на написание самих тест-кейсов, но и время на разработку матрицы.
Эффективность.
Если проект небольшой и все требования оформлены в виде структурированного ТЗ, а тест-кейсы создаются на каждое требование сразу, матрица трассируемости в нашем виде будет только дублировать информацию и будет лишней тратой ресурсов.
Поэтому нужно использовать стандартную матрицу, описанную в определении, для оценки покрытия.

Приятности

Матрица позволяет контролировать реализацию требований, отслеживать, что все требования разработаны и протестированы и ничего не пропущено.
Матрица помогает команде QA отслеживать, есть ли долг по тестовой документации, и какие именно требования еще не покрыты тест-кейсами.
Инструмент используется аналитиком и QA-командой для контроля измененных требований.
На проекте матрицы трассируемости стали использоваться не только нами, но и product-owner со стороны заказчика. Так они убеждались, что все требования есть и они корректны, и отслеживали с помощью матрицы, что уже реализовано. Матрицы позволили нам сделать процесс разработки и тестирования в какой-то степени более прозрачным.

Источник