Анализ требований Иерархия типов требований

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

Отношения между требованиями

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

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

Способность отследить отношения между требованиями называется прослеживаемостью и определяется отношениями трассировки между требованиями. Прослеживаемость обеспечивает способность понимания того, как изменения одного требованию могут повлиять на другие требования (анализ влияния), а также может помочь в определении того, полны ли требования (анализ полноты учета). Правила трассировки между требования также должны быть занесены в план управления требованиями.

Анализ влияния

Анализ влияния, прежде всего, предназначены для того, чтобы управлять изменениями требований. Он ясно показывает, как изменение одного требования может воздействовать на другие. С помощью связей между требованиями аналитик принимает решения о том принять или отклонить изменения требований. Например, если кто-то желает изменить ключевую возможность, и связь влияния показывает, что такое изменение вызовет изменения в нескольких вариантах использования (повлияет на график проекта), необходимо взвесить все «за» и «против» изменения ключевой возможности и принять правильное решение. Анализ влияния легче всего осуществлять с помощью матрицы и дерева трассировок, которые показывают отношения между требованиями. На рисунках 6 и 7 приведены матрица трассировки и дерево трассировки, созданные в среде IBM Rational RequisitePro 7.

Рисунок 6. Матрица трассировки требований

Рисунок 7. Дерево трассировки требований

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

Анализ сферы деятельности

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