7. Матрица требований. Разработка матрицы требований
Сбор требований является начальным и неотъемлемым этапом процесса разработки программных систем. Он заключается в определении набора функций, которые необходимо реализовать в продукте. Процесс сбора требований реализуется частично в общении с заказчиком, частично посредством мозговых штурмов разработчиков. Результатом является формирование набора требований к системе, именуемой техническим заданием.
Фиксация требований (Requirement Capturing), с одной стороны, определяется желаниями заказчика в реализации того или иного свойства. С другой стороны в процессе сбора требований может обнаружиться ошибка, которая приведет к определенным последствиям, устранение которых заберет непредвиденные ресурсы –дополнительное кодирование, перепланирование.
Ошибка может быть тем серьезней, чем позже она будет обнаружена, особенно если это связано с множеством спецификаций. Поэтому одной из составляющей этапа фиксации требований, наряду со сбором является верификация требований, а именно проверка их на непротиворечивость и полноту.
Автоматизированная верификация требований может производиться лишь после спецификации или формализации требований.
Спецификация требований к ПО – процесс формализованного описания функциональных и нефункциональных требований, требований к характеристикам качества в соответствии со стандартом качества ISO/IEC 12119-94, которые будут учитываться при создании программного продукта на этапах ЖЦ ПО. В спецификации требований отражается структура ПО, требования к функциям, показателям качеству, которых необходимо достигнуть, и к документации. В спецификации задается в общих чертах архитектура системы и ПО, алгоритмы, логика управления и структура данных. Специфицируются также системные требования, нефункциональные требования и требования к взаимодействию с другими компонентами (БД, СУБД,протоколы сети и др.).
Формализация включает в себя определение компонентов системы и их состояний; правил взаимодействия компонентов и определения условий в формальном виде, которые должны выполняться при изменении состояний компонентов. Для формального описания поведения системы используются языки инженерных спецификаций, например, UML. В качестве формальной модели для описания требований используются базовые протоколы, которые позволяют использовать дедуктивные средства верификации в сочетании с моделированием поведения систем путем трассирования.
Валидация (аттестация) требований - это проверка требований, изложенных в спецификации для того, чтобы убедиться, что они определяют данную систему и отслеживание источников требований. Заказчик и разработчик ПО проводят экспертизу сформированного варианта требований с тем, чтобы разработчик мог далее проводить разработку ПО. Одним из методов аттестации является прототипирование, т.е. быстрая отработка отдельных требований на конкретном инструменте и исследование масштабов изменения требований, измерение объема функциональности и стоимости, а также создание моделей оценки зрелости требований.
Верификация требований – это процесс проверки правильности спецификаций требований на их соответствие, непротиворечивость, полноту и выполнимость, а также на соответствие стандартам. В результате проверки требований делается согласованный выходной документ, устанавливающий полноту и корректность требований к ПО, а также возможность продолжить проектирование.
Полагая, что все требования четко идентифицированы и пронумерованы, можно сконструировать матрицу зависимостей требований (requirements dependency matrix) (или матрицу взаимодействия (interaction matrix требований)). В столбце и строке заголовка перечислены упорядоченные идентификаторы требований, как показано на рис. 7.1.
|
Требование |
Т1 |
Т2 |
Т3 |
Т4 |
|
Т1 |
Х |
Х |
Х |
Х |
|
Т2 |
Конфликт |
Х |
Х |
Х |
|
Т4 |
|
|
Х |
Х |
|
Т4 |
|
Перекрытие |
Перекрытие |
Х |
Рис. 7.1. Матрица зависимостей требований
Верхняя правая часть матрицы (над диагональю включительно) не используется. Оставшиеся ячейки указывают на то, перекрываются ли два любых требования, противоречат друг другу или независимы друг от друга (пустые ячейки). Противоречивые требования необходимо обсудить с заказчиками и при возможности переформулировать для смягчения противоречий (фиксацию противоречия, видимую для последующей разработки, необходимо сохранить). Перекрывающиеся требования также должны быть сформулированы заново, чтобы исключить совпадения.
Матрица зависимости требований представляет собой простой, но эффективный метод обнаружения противоречий перекрытий, когда количество требований относительно невелико. В противном случае описанный метод все же можно применить, если удается сгруппировать требования по категориям, а затем сравнить их отдельно в пределах каждой категории.
Матрица соответствия требований - это двумерная таблица, содержащая соответсвие функциональных требований (functional requirements) продукта и подготовленных тестовых сценариев (test cases). В заголовках колонок таблицы расположены требования, а в заголовках строк - тестовые сценарии. На пересечении - отметка, означающая, что требование текущей колонки покрыто тестовым сценарием текущей строки.
Матрица соответсвия требований используется QA-инженерами для валидации покрытия продукта тестами (валидация – согласно стандарту ГОСТ Р ИСО 9000-2008 (соответствует ISO 9000:2005), валидация определена следующим образом: «Подтверждение на основе представления объективных свидетельств того, что требования, предназначенные для конкретного использования или применения, выполнены»). Матрица соответсвия требований является неотъемлемой частью тест-плана.
Матрица трассировки (матрицы трассируемости) (traceability matrix) - если разбить слово трассируемость на составный станет легче понять и запомнить, трассируемость
(от англ. Traceability, Trace - хвост, ability – способность). Прослеживаем зависимости (хвосты) между требованиями и тестами.
Матрица трассировки (матрицы трассируемости) - способ визуализации связей между элементами системы в форме таблицы.
В процессах сбора требований и проектирования программно-технических систем матрицы трассировки используются для быстрой оценки связей между артефактами проектирования, такими как:
- требования и тесты,
- заказчик и релизы (спринты)*,
- требования и подсистемы,
- требования и функциональные спецификации,
- функциональные и нефункциональные требования,
- требования и модели системы,
- варианты использования (Use Cases) и подсистемы,
- ошибки и тесты,
- ошибки и модули системы.
Примечание:*Спринт - итерация в скраме (скрам (Scrum) — это набор принципов, на которых строится процесс разработки, позволяющий в жёстко фиксированные и небольшие по времени итерации, называемые спринтами (sprints), предоставлять конечному пользователю работающее ПО с новыми возможностями, для которых определён наибольший приоритет. Возможности ПО к реализации в очередном спринте определяются в начале спринта на этапе планирования и не могут изменяться на всём его протяжении. При этом строго фиксированная небольшая длительность спринта придаёт процессу разработки предсказуемость и гибкость.), в ходе которой создаётся функциональный рост программного обеспечения. Жёстко фиксирован по времени. Длительность одного спринта от 2 до 4 недель. В отдельных случаях, к примеру согласно Scrum стандарту Nokia, длительность спринта должна быть не более 6 недель. Тем не менее, считается, что чем короче спринт, тем более гибким является процесс разработки, релизы выходят чаще, быстрее поступают отзывы от потребителя, меньше времени тратится на работу в неправильном направлении. С другой стороны, при более длительных спринтах команда имеет больше времени на решение возникших в процессе проблем, а владелец проекта уменьшает издержки на совещания, демонстрации продукта и т. п. Разные команды подбирают длину спринта согласно специфике своей работы, составу команд и требований, часто методом проб и ошибок. Для оценки объема работ в спринте можно использовать предварительную оценку, измеряемую в очках истории. Предварительная оценка фиксируется в бэклоге проекта. На протяжении спринта никто не имеет права менять список требований к работе, внесённых в бэклог спринта.
Конкретный набор матриц трассировки определяется составом проектных данных - типами используемых артефактов, которые в свою очередь определяются принятой в организации методологией сбора требований и проектирования.
Для построения матрицы трассировки используется следующий подход:
1) Выбираются элементы рассматриваемой системы для строк и столбцов.
2) При наличии связи требуемого типа между элементом строки и элементом столбца в соответствующей ячейке ставится любой удобный символ.
Более сложные матрицы трассировки могут отражать не только факт наличия связи, но и ее атрибуты.
Рассмотрим простой и наглядный пример.
Этот пример знаком всем со времени обучения в школе, техникуме, университете. В данном примере система — курс обучения. А интересующая нас матрица трассировки — табель посещаемости занятий.
Столбцами данной матрицы являются элементы системы — занятия, строками — элементы системы — студенты. Если студент посещал занятие, то ставится отметка о посещении. Таким образом, мы отражаем связь студента и занятия.
Рис. 7.2. Иллюстрация матрицы трассировки — табель посещаемости
Связи могут иметь и дополнительные характеристики, например, студент был, но болтал. Тогда мы можем добавить в ячейку не просто факт наличия связи, а ее характеристику — болтал, таким образом, мы сделаем матрицу трассировки более информативной.
По данной матрице с практической точки зрения можно оценить общую ситуацию по группе. Насколько группа в целом посещает занятия. Если матрица разрежена, то, как правило, общий объем знаний мал, качество конспектов плохое и делиться друг с другом им будет не чем, а значит группа плохо сдаст зачет и экзамен и, скорее всего, придется назначать дополнительные занятия и будет много работы на доп. сессии. С точки зрения дисциплины это означает увеличение ресурсов и длительности проекта.
Если из 10-12 человек нет троих, которые посещали все занятия, это означает, что у группы нет полного и достоверного конспекта. Это также приведет к сложностям на экзамене. А значит преподавателю необходимо планировать либо предупреждающие меры, либо потом бороться с последствиями увеличения нагрузки в сессию.
Если матрица сильно разрежена, необходимо срочно принимать меры и прежде всего необходимо понять по каким причинам группа не ходит — не интересно? Не успевают? Не сдали предыдущие работы? Нет мотивации? Вынуждены работать и пропускать занятия?
Также можем оценить частную ситуацию по каждому студенту и адекватно реагировать на действия студентов, понимая с каких позиций они осуществляются.
Трассировка обеспечивает полноту тестирования и подготавливает основу для планирования тестов. Матрица трассировки может быть самостоятельным документом или может быть включена как часть документации по требованиям или часть плана тестирования.
Примеры картинок с трассировочными матрицами:
Пример 1:
Пример 2:
Пример 3:
Пример 4:
Рис. 7.3. Примеры матрицы трассировки
Инструкции:
В соответствии с лучшими практиками, бизнес-требования следует декомпозировать до мельчайших пакетов и нумеровать в соответствии со следующими правилами нумерации: BR001, BR002 и т.д. Для каждого бизнес-требования будет одно или несколько функциональных требований, которые должны соответствовать соглашению по нумерации для соответствующего бизнес-требования: FR001.01, FR001.02, FR001.03, FR002 и т.д. Функциональные требования должны быть декомпозированы до мельчайших пакетов.
Для каждого функционального требования будет существовать одна или несколько связанных технических спецификаций, которые должны соответствовать соглашению по нумерации для связанных функциональных требований: TS001.01.01, TS001.01.02, TS001.01.03 и т.д. Технические спецификации должны быть декомпозированы до мельчайших пакетов.