Трассировка требований что это

Трассировка требований что это

С каждым элементом трассируемости связан собственный набор атрибутов (см. Атрибуты требований), который применяется для анализа состояния, преимуществ, рисков и прочих факторов, связанных с элементом.

Назначение трассируемости

Трассируемость позволяет выполнить следующее:

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

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

Элементы трассируемости также позволяют ответить на следующие вопросы:

В документе Видение для системы по утилизации отходов может быть указана следующая возможность:

FEAT10: распознавание новых типов бутылок системой.

Эта возможность трассируется в варианте использования «Добавить новый тип бутылки»:

В варианте использования Добавить новый тип бутылки оператор настраивает машину на распознавание новых типов бутылок.

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

Типичные элементы трассируемости

Ниже перечислены наиболее распространенные элементы трассируемости:

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

Типичный вариант трассируемости показан на следующей схеме:

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

© Copyright IBM Corp. 1987, 2006. Все права защищены..

Источник

Трассируемость требований

Содержание

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

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

Назначение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник

Матрица трассабилити

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник

Пример матрицы трассировки требований

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

Примеры картинок с трассировочными матрицами
Пример 1

Пример 2

Пример 3

Пример 4

Инструкции:
В соответствии с лучшими практиками, бизнес-требования следует декомпозировать до мельчайших пакетов и нумеровать в соответствии со следующими правилами нумерации: BR001, BR002 и т.д. Для каждого бизнес-требования будет одно или несколько функциональных требований, которые должны соответствовать соглашению по нумерации для соответствующего бизнес-требования: FR001.01, FR001.02, FR001.03, FR002 и т.д. Функциональные требования должны быть декомпозированы до мельчайших пакетов.

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

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

ID Матрицы — уникальная последовательность для идентификации комбинации требований и связанных с ними вариантов использования.

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

# Функциональные требования — идентификационный номер функционального требования (в соответствии с документацией по требованиям), которое исполняет указанное бизнес-требование.

# Вариант использования — идентификационный номер варианта использования, который будет использоваться для проверки соответствия бизнес-требований с функциональными требованиями. Этот параметр должен соответствовать ID в документе по требованиям. Поле является необязательным для заполнения.

# Сценарий тестирования — идентификационный номер тестового скрипта, который будет использоваться для проверки связанных бизнес или функциональных требований.

Вы можете создать таблицу со следующими столбцами и строками:

Источник

Методы определения требований в программной инженерии

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник