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

Модель требований и модель прецедентов фактически обеспечивают две «базы данных функциональных требований». Важно сопоставить эти две модели, чтобы выяснить, нет ли в одной из них чего-то, что не охвачено в другой, и наоборот. Такая постановка вопроса – один из аспектов отображения требований.
Отображение функциональных требований осложняется тем фактом, что между отдельными функциональными требованиями и прецедентами установлены отношения «многие ко многим». Один прецедент будет охватывать множество отдельных функциональных требований, и одно функциональное требование может появляться в нескольких разных прецедентах.
Надеемся, в вашем распоряжении будут инструменты для моделирования, имеющие поддержку отображения требований. Такие инструментальные средства для выработки требований, как RequisitePro и DOORS позволяют связывать отдельные требования в базе данных требований с конкретными прецедентами, и наоборот. Кстати, UML предоставляет достаточно хорошую поддержку отображения требований.
С помощью помеченных значений можно ассоциировать список ID требований с каждым прецедентом. В инструменте выработки требований можно связать один или более идентификаторов прецедентов с конкретными требованиями.
В случае отсутствия такой поддержки в инструменте для моделирования всю эту работу необходимо выполнять вручную. Для этого полезно создать матрицу отображаемости требований. Это простая таблица с номерами ID отдельных требований, расположенными по вертикали, и именами прецедентов (и/или номерами ID) – по горизонтали. Во всех ячейках, где прецедент и требование пересекаются, ставится крестик. Обычно матрицы прослеживания требований создаются в виде электронных таблиц.
Матрица отображаемости требований – полезный инструмент для проверки согласованности. Если существует требование, не отображающееся ни в один прецедент, значит, упущен прецедент. И наоборот, если есть прецедент, которому не поставлено в соответствие ни одно требование, понятно, что набор требований неполный.
С помощью комплекта инструментов SUMR, можно автоматизировать создание матрицы отображаемости потенциальных требований. Идея проста: если термин глоссария проекта встречается и в требовании, и в прецеденте, велика вероятность того, что они как-то связаны между собой. Так создается матрица прослеживания предполагаемых требований. Мы говорим «предполагаемых», потому что в результате такого простого текстового анализа могут появиться ошибки и упущения. Эта матрица нуждается в ручной доработке. Тем не менее она может существенно сэкономить время и помочь разработчикам требований решить трудные задачи, которые в противном случае могли бы быть вообще не реализованы.

Запись опубликована в рубрике Компьютеры и интернет с метками . Добавьте в закладки постоянную ссылку.

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

Ваш e-mail не будет опубликован. Обязательные поля помечены *

*

code