Управление версиями
Следующая функция, направленная на поддержание целостности, точности и актуальности спецификации требования – это управление версиями спецификации.
Управление версиями требует выполнения следующих видов деятельности:
Определение конфигурации требований: именование отдельных требований и версий спецификации.
Определение состава версии спецификации.
Управление процессом внесения изменений.
Хранение истории каждой версии спецификации, содержащей сведения о внесенных изменениях.
Проведение аудита для обеспечения целостности имеющихся требований.
За время выполнения проекта спецификация требований изменяется путем включения новых требований и изменения (получения новых редакций, или версий) существующих требований. Управление версиями позволяет разработчикам иметь спецификацию, содержащую только те требования, которые должны быть реализованы в конкретном выпуске системы и в нужной их редакции.
Наиболее надежный способ контроля версий – это использование соответствующих программных средств.
Управление связями требований
Результатом проекта должна быть программа, которая удовлетворяет требованиям, перечисленным в спецификации. Если четко контролировать выполнение каждого требования от проекта до кода, реализующего требование, то эта цель достигнута. Возможность отображать каждое требование на соответствующие части проекта называется трассированием, или прослеживанием требований.
Трассируемость требований позволяет решить следующие задачи.
Продемонстрировать, что все требования проекта реализованы.
Снизить вероятность того, что при внесении изменений будет упущено требование, на которое оказывает влияние изменение.
Упростить внесение изменения на поздних фазах проектирования, а также фазе эксплуатации и сопровождения продукта.
Зафиксировать опыт проектирования, упростить повторное проектирование и повторное использование.
Упростить поиск, локализацию и исправление ошибок при тестировании.
Многие из перечисленных выгод относятся к долгосрочным выгодам, снижающим общие стоимость жизненного цикла продукта. За них нужно платить увеличением затрат на сбор и управление информации трассируемости, поэтому при принятии решения о трассировании требований нужно помнить о том, что трассирование – это сложный и трудоемкий процесс, который будет отвлекать разработчиков от проектирования.
Трассирование требований выполняется вручную, поэтому процедуры сбора, хранения и управления информацией о трассируемости должны быть документированы, и выполняться всеми разработчиками на всех этапах выполнения проекта. Если информация о трассируемости устареет, то восстановить ее будет невозможно.
Матрица трассируемости требований
Трассирование требований – это определение связей между требованием и другими артефактами проекта. Такая информация обычно представляется в виде матрицы [1, 4]. На рис. 7.3 приведен один из возможных форматов такой матрицы.
Рис. 7.3
Строки матрицы поименованы идентификаторами требований пользователя. Первый столбец содержит имена функциональных требований, с которым связано данное пользовательское требование. Этот столбец заполняется по спецификации требований. Остальные столбцы получают свои значения по мере выполнения проектирования. Можно добавить деталей трассируемости для повышения точности расположения связанных с требованием элементов проекта, но объем работы по управлению трассированием при этом возрастет.
Дополнительным достоинством матрицы является то, что по ней можно выполнять как прямую (от требования к коду и далее) трассировку, так и обратную трассировку. Кроме этого, разрешив определять несколько позиций в ячейке матрицы, мы получаем возможность фиксировать не только бинарные отношения, но и связи вида «один ко многим» или «многие ко многим». Дело в том, что одно функциональное требование, например, может проверяться несколькими вариантами тестирования, а несколько вариантов использования могут порождать множества функциональных требований, пересечение которых не пусто. Другие варианты матриц трассируемости требований можно найти в [4].
Трассируемость нефункциональных требований – более сложная проблема. Например, требования к производительности определяют выбор структур данных и алгоритмов обработки и могут быть не связаны с определенным кодом. Требования мобильности определяют инструментальные средства и не приводят к написанию какого-либо кода и т.д. Трассировка нефункциональных требований должна основываться на анализе этих требований и отдельном решении для каждого требования.
Ранее было сказано, что трассирование требований выполняется вручную. На самом деле вручную выполняется заполнение ячеек матрицы трассируемости. Поддержание матрицы в актуальном состоянии без использования средств управления требованиями возможно только для очень небольших проектов. Связано это с большими объемами информации, хранить которую в документальном виде, а также обновлять, вносить изменения, хранить и обрабатывать множество атрибутов и т.д. невозможно.
Существующие средства управления требованиями позволяют: импортировать требования из исходных документов, определять значения атрибутов, контролировать связи трассирования требований, соединять требования с элементами, хранящимися в других средствах разработки и т.д. В [4] правильно замечено, что, несмотря на большой объем функций, выполняемых этими средствами, они не являются средствами разработки требований, а значит, не могут помочь в определении заинтересованных лиц (пользователей) или выявлении и сборе требований.