Вигерс Карл. Разработка требований к программному обеспечению

Подождите немного. Документ загружается.

кода, варианты тестирования и файлы справки.

Информация

трасси-

руемое™ облегчает выполнение анализа влияния, помогая вам

опре-

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

нить для реализации предложенного изменения требования.

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

Связи трассируемости помогают следить за равитием требования в

обоих

направлениях—

от первоисточника к реализации и

наоборот

(Gotel

и Finkelstein, 1994). В главе 1 Трассируемость определяется, как

одна из характеристик отличной спецификации требований. Чтобы

реализовать Трассируемость, каждое требование должно быть уни-

кально и последовательно идентифицировано, чтобы вы могли ссы-

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

бования маленькими фрагментами, а не большими абзацами, в кото-

рых содержится множество отдельных функциональных требований -

это приводит к разбросу элементов дизайна и кода.

Потребности

клиента

направлении

к требованиям

в направлении

от требований

Требования

в направлении в направлении

от требоааний к требованиям

Рис. 20-1. Четыре типа трассируемости требований

На рис. 20-1 показаны четыре типа связей трассируемости

(Jarke,

1998).

Потребности клиента отслеживаются в направлении к

требова-

ниям (forward to requirements), чтобы вы смогли определить,

которые

Глава 20. Связи в цепи требований

385

требования будут затронуты, если в течение или после разработки по-

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

ции требований указаны все потребности клиента. И, наоборот, вы мо-

жете проследить в направлении от требований

(backward

from require-

ments) к потребностям клиента, чтобы определить происхождение

каждого требования к ПО. Если вы представите потребности клиента в

форме вариантов использования, то верхняя половина рис. 20-1 будет

показывать трассирование между вариантами использования и функ-

циональными требованиями.

Взглянув на нижнюю часть рис.

20-1,

ясно, что по мере приближе-

ния к

поставке,

вы можете

отележиватьв

направлении от требований,

определив связи между отдельными требованиями и элементами

продукта. Это тип связи гарантирует, что каждое требование удовле-

творено, поскольку вы знаете, какой компонент соответствует каждо-

му требованию. Четвертый тип связи контролирует отдельные эле-

менты продукта в направлении к требованиям для

того,

чтобы вы зна-

ли причину созданию каждого элемента. В большинство приложений

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

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

Предположим, тестеровщик обнаружит незапланированную функ-

циональность при отсутствии соответствующего требования. Этот

фрагмент кода может свидетельствовать, что разработчик реализовал

официальное требование, которое аналитик теперь может добавить к

спецификации. Или же это может быть

код-«сирота»,

украшающий

фрагмент, который не относится к продукту. Связи

трассируем

ости по-

могут вам отсортировать подобные ситуации и получить более полное

представление

о том, как именно фрагменты вашей системы составля-

ют одно целое. И наоборот, варианты тестирования, которые созданы

на основе отдельных требований и которые можно проследить до этих

требований, также представляют собой механизм выявления нереали-

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

дет.

Связи

трассируемости

помогают отслеживать родительские требо-

вания, взаимосвязи и зависимости между отдельными требованиями,

Эта информация показывает влияние изменения, если отдельное тре-

бование удаляется или модифицируется. Если вы сопоставили отдель-

ные требования с задачами в структуре проекта, то эти задачи будут за-

тронуты при изменении или удалении требования.

386 Часть III. Управление требованиями к ПО

лежит в основе

следующего

влияет

Бизнес -

правило

Системное

требование,

ва-

риант

использования,

требо-

вания к внешнему интерфейсу,

атрибут качества

является первоисточником является первоисточником

следующего следующего

Функциональные

требования

к ПО

удовлетворяется

проверяется ведет

следующим следующим к

созданию

Архитектура,

пользовательский интерфейс

или

функциональный

дизайн

проверяется

следующим

Тестирование

системы

реализуется в

Рис. 20-2. Возможные связи трассирования

требований

Глава 20. Связи в цепи требований

387

На рис. 20-2 показано множество типов прямых взаимосвязей трас-

сируемости, возможных в проекте. Вам не нужно определять и управ-

лять всеми этими типами связей трассируемости. Во многих проектах

удается получить 80% преимуществ трассируемости, вложив прибли-

зительно 20% усилий. Возможно, вам нужно только отслеживать тес-

тирование системы до

функциональных

требований или вариантов ис-

пользования. Решите, какие связи уместны в вашем

проекте,

и вы в

значительной степени поспособствуете успешной разработке и эф-

фективному обслуживанию. Не просите членов команды тратить много

времени на фиксирование информации, если у вас нет четкого пред-

ставления о использовании этой информации.

Мотивация для трассируемости требований

Однажды у меня был неудачный опыт: я написал программу, а потом

понял,

что случайно упустил из виду требование. Оно было в

спецификации — я просто не заметил его. Мне пришлось вернуться и

написать дополнительный код, а я думал, что уже закончил с програм-

мированием. Пропуск требования — это нечто более, чем просто про-

мах, если клиент не удовлетворен или в готовом продукте отсутствует

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

уровне трассирование требований предоставляет способ продемон-

стрировать соответствие контракту, спецификации или правилу, На

более сложном уровне это позволяет улучшить качество

продуктов,

снизить затраты на поддержку и облегчить повторное использование

(Ramesh, 1998).

Трассирование требований — это трудоемкая задача, выполняемая

вручную, для которой необходимо организационное согласование,

Для обновления информации о связях по мере разработки и обслужи-

вания системы необходима дисциплина. Если информация трассируе-

мости устаревает, вероятнее всего, вам никогда не удастся заново

воссоздать ее. Кроме того, из-за этого разработчики и сотрудники

службы поддержки напрасно тратят время, следуя по неверному пути

Именно поэтому для использования трассируемости у вас должна

быть веская причина

{Ramesh

и др., 1995). Далее перечислены воз-

можные преимущества реализации трассируемости требований.

1 Сертификация. Вы можете воспользоваться информацией

трас-

сируемости при сертификации продукта с особыми требованиями к

безопасности, чтобы продемонстрировать, что все требования бы-

ли реализованы — хотя это не доказывает, что они реализованы

388 Часть III. Управление требованиями к ПО

корректно и полностью! Естественно, если требования некорректны

или отсутствуют ключевые требования, то вам не

помогут

даже са-

мые лучшие данные трассируемости.

Анализ влияния изменения. Без информации

трассируемое!

возрастает вероятность того, что

из

внимания будет упущен сис-

темный элемент, которого коснется добавление, удаление или из-

менение определенного требования.

Поддержка. Надежная информация трассируемости облегчает

со-

ответствующее и полное внесение изменений в ходе

обслуживании,

что повышает производительность. Часто при изменении корпора-

тивных политик или государственных правил, приложения ПО нуж-

даются в обновлении. Таблица, в которой показано, где соответст-

вующее бизнес-правило было реализовано в функциональном тре-

бовании,

дизайне и коде, упрощает

соответствующее

внесение

изменений.

з Трассирование проекта. Если в ходе разработки вы тщательно

фиксируете данные трассируемости, у вас будет точное представ-

ление о состоянии реализации запланированной функционально-

сти. Отсутствующие связи указывают на рабочие продукты,

которые

еще не созданы.

1 Повторная разработка. Вы можете перечислить функции в преды-

дущей версии системы, которую вы заменяете, и

указать,

каким но-

вым системным требованиям и компонентам ПО они адресованы.

Определение связей трассируемости

—

это способ зафиксировать

определенный опыт, полученный при переработке существующей

системы.

I Повторное использование. Информация трассируемости

упро

щает повторное использование компонентов продукта,

определяя

пакеты связанных требований, дизайна, кода и тестов,

I Снижение риска. Документирование взаимосвязей

компонентов

уменьшает риск возникновения проблем, если вдруг ключевой член

команды, обладающей важной информацией о системе,

покидав"

проект (Ambler, 1999).

Тестирование. Если тестирование дает неожиданный результат, то

связи между тестами, требованиями и кодом укажут на наиболее

вероятные части кода, которые необходимо проверить на

наличие

дефектов. Информация о том, какие тесты проверяют какие

требо-

вания,

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

Многие из вышеперечисленных относятся к долгосрочным

выгодам,

которые снижают общую стоимость жизненного цикла продукта,

хотя

при этом увеличиваются затраты на сбор и управление

информации

Глава 20. Связи в цепи требований 389

трассируемое™.

Рассматривайте

трасс

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

вестицию, увеличивающую шансы поставить продукт, который удовле-

творяет все основные требования клиента. Хотя это трудно измерить,

вы будете получать дивиденды каждый

раз,

когда вам понадобится из-

менить, расширить или заменить продукт. Определить связи трасси-

руемости несложно, если вы собираете информацию по мере разра-

ботки, однако делать это для уже завершенной системы утомительно и

дорого.

Матрица трассируемости требований

Наиболее типичный способ представления связей между требования-

ми и другими элементами системами — матрица трассируемости тре-

бований, которую также называют матрицей отслеживания требова-

ний или таблицей трассируемости (requirements traceability matrix)

(Sommerville

и Sawyer,

1997).

В табл. 20-показана часть такой матрицы

для Chemical Tracking System. Когда я раньше создавал такие матри-

цы, я делал копию базовой версии спецификации требований и удалял

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

создавал таблицу, отформатированную так

же,

как табл.

20-1,

и запол-

нял только столбец Функциональное требование. Далее мы постепен -

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

Таблица

20-1.

Один из типов матрицы трассируемости требований

Пользова-

тельское

требование

UC-28

UC-29

Функциональное

требование

catalog

.query.sort

catalog, query.

import

Элемент

дизайна

Каталог

класса

Каталог

класса

Модуль

кода

catalog.sortO

catalog.

import()

catalog.validate(]

Вариант

тестирования

search.7

search.

search. 12

search. 13

search. 14

В табл. 20-1 показано, как каждое функциональное требование свя-

зано с определенном вариантом использования (в направлении назад)

и с одним или более элементами дизайна, кода и тестирования (в на-

правлении вперед). Элементы дизайна могут быть объектами в таких

моделях

анализа, как диаграммы потока данных, таблицы в реляцион-

ной модели данных или классах

объектов.

Ссылки кода могут быть

390

Часть III. Управление требованиями к ПО

методами класса, хранимыми процедурами, именами файлов исходно-

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

вправе добавить дополнительные столбцы для расширения ссылок на

другие рабочие продукты, например на документацию справочной

сие

темы. Добавление деталей трассируемое™ — дополнительная работа.

но

так вы получаете точные расположения связанных элементов ПО,

что экономит массу времени при анализе влияния и обслуживании.

Заполняйте информацию по мере выполнения работы, а не по

мер*?

планирования. То есть вводите

«catalog.sortO»

в столбец Модуль кода

первой строки в табл.

20-1,

только когда код в этой функции

написан,

прошел тестирование элементов и уже интегрирован с базовой

вереи

ей исходного кода продукта. Таким образом, читающий матрицу

буде~

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

указывают на работу, которая уже выполнена. Обратите внимание, что

перечисление вариантов тестирования для каждого требования не

указывает на то, что ПО протестировано. Это просто означает, что

оп-

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

ствующее время. Трассирование состояния

тестов—

это

отдельная

проблема.

Нефункциональные требования, такие, как задачи по производи-

тельности и атрибуты качества не всегда прослеживаются напрямую

до кода. Требование к времени отклика может диктовать выбор

опре-

деленного оборудования, алгоритмов, структур баз данных или архи-

тектуры. Требование к легкости перемещения может ограничить функ-

ции языка, используемые программистом, однако не приведет к соз-

данию определенных фрагментов кода, которые активизируют

эту

возможность. Другие же атрибуты качества действительно реали-

зуются в коде. Требования к целостности для аутентификации поль-

зователей активизирует создание производных функциональных тре-

бований, которые реализуются, с помощью, скажем, паролей

или

биометрических параметров. В этих случаях следует трассировать со-

ответствующие функциональные требования в обратном направлении,

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

прямом,

до готового продукта. На рис. 20-3 показана возможная цепь

трассируемости с участием нефункциональных требований.

Связи трассируемости могут определить отношения «один к одно-

му», «один ко многим» или

«многие

ко многим» между элементами сис-

темы. Формат в табл. 20-1 предусматривает это, позволяя вводить не-

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

возможных связей.

Глава 20. Связи в цепи требований 391

"Один к одному»: один элемент дизайна реализуется в одном

мо-

дуле кода.

«Один ко многим»: одно функциональное требование

проверяется

множеством вариантов

тестирования.

«Многие

ко многим»: каждый вариант использования порождает

множество функциональных требований, а определенные функцио-

нальные требования являются общими для нескольких вариантов

использования. Подобным образом общие или повторяющиеся

элементы дизайна могут удовлетворить несколько

функциональных

требований. В идеале стоило бы зафиксировать все эти взаимосвя-

зи, однако на практике отношениями

трассируем

ости типа «многие

ко многим» сложно и трудно управлять.

Бизнес-правило:

корпоративная политика

безопасности

Атрибут

качества

целостности,

имеющий отношение к

аутенти-

фикации

идентификатора

пользователя

Функциональные

требования

для

пароля

Дизайн для модуля

управления паролем

Код, реализующий

функции пароля

Рис. 20-3. Пример цепи

трассируемости

для требований, касающихся

безопасности приложения

Другой способ представить информацию трассируемости — с по-

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

системы, например:

392

Часть III. Управление требованиями к ПО

i один тип требования с другим требованием этого же типа;

1 один тип требования с требованием другого типа;

I один тип требования с вариантами тестирования.

Вы можете использовать эти матрицы для определения различных

взаимоотношений, возможными между парами требований, например

«указывает/указан»,

«зависит от», «является родительским

для»

и «ог-

раничивает/ограничен»

(Sommerville

и Sawyer,

1997).

В табл. 20-2 показана двусторонняя матрица трассируемости. Боль-

шинство ячеек матрицы не заполнены. Каждая ячейка на

пересечении

двух связанных компонентов помечена для указания соединения. Вы

можете использовать различные символы в ячейках, чтобы явно опре-

делить «трассируется до» и «трассируется от» или другие взаимоотно-

шения. В табл. 20-2 стрелка указывает, что данное

функциональное

требование отслеживается от определенного варианта использова-

ния. Эти матрицы более поддаются автоматизации средствами под-

держки,

чем

те, что показаны в табл.

20-1.

Таблица 20-2. Матрица для трассирования требований, показывающая связи

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

Функциональное требование (ФР) Вариант использования

(ВИ)

ВИ-1

ВИ-2 ВИ-3 ВИ-4

ФР-1

ФР-2

ФР-3

ФР-4

ФР-5

ФР-6

Связи трассируемости должны быть определены любым

лицом,

имеющим доступ к соответствующей информации. В табл. 20-3

опре-

делены некоторые стандартные источники информации о связях меж-

ду различными типами исходных и целевых объектов. Определите

ро-

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

сируемости для вашего проекта. Будьте готовы к тому, что занятые

люди, которых аналитик или менеджер проекта попросит

предоставить.

эти данные, будут отнекиваться. Этим специалистам стоит объяснить,

Глава 20. Связи в цепи требований 393

что такое трассирование требований, чем оно ценно и почему именно

этих специалистов просят внести вклад в процесс. Подчеркните, что

увеличение затрат на фиксирование информации трассируемости во

время выполнения невелики; в основном это вопрос привычки и дисци-

плины.

Ловушка За сбор и управление данными трассируемости требований должны

отвечать

определенные лица, или оно просто не будет выполнено. Обычно аналитик

требований или специалист по проверке соответствия качества собирает, сохраняет

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

Таблица 20-3. Вероятные источники информации о связи трассируемости

Тип объекта

источника ссылки

Тип объекта

целевой

ссылки

Источник

информации

Системное требование

Вариант использование

Функциональное требование

Элемент дизайна

Бизнес-правило

Требование к ПО

Функциональное требование

Вариант

тестирования

Элемент архитектуры ПО

Другие элементы дизайна

Кол

Функциональное требование

Системный инженер

Аналитик требований

Специалист

по тестированию

Архитектор ПО

Дизайнер

или разработчик

Разработчик

Аналитик требований

Средства трассирования требований

В главе 21 описано несколько коммерческих средств управления тре-

бованиями, обладающих значительными возможностями трасси-

рования требований. Вы можете сохранить требования и другую

ин-

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

ными типами сохраненных объектов, включая равноценные ссылки

между двумя требованиями одного типа. Некоторые инструменты по-

зволят вам различить отношения «трассируется до» и «трассируется

394

Часть III. Управление требованиями к ПО