Проблемы оперирования требованиями

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

Независимо от уровня первоначальной проработки требований к проекту не стоит думать, что требования всегда будут оставаться неизменными. Необходимо быть готовым к тому, что в любой момент могут появиться новые требования, одни старые требования изменятся, другие — отпадут. Но основная сложность управления процессом изменения требований заключается не в этом, а в том, что изменения одних требований влияют на другие, и такие влияния нужно отслеживать. Влияние изменений требований естественным образом распространяется на все рабочие продукты проекта, в том числе на программные рабочие продукты.

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

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

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

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

• требования должны быть заданы в виде, допускающем однозначное представление в моделях уровня анализа и конструирования, и способ такого представления должен быть унифицирован для всего проекта;
• в проекте должны инструментально поддерживаться связи между требованиями и между требованиями и другими компонентами рабочих продуктов, и эта поддержка должна быть обеспечена.

Представление требований и пожеланий, исходящее от инициаторов работ, ни в коей мере не способствует соблюдению указанных условий. Следовательно, они должны быть трансформированы, т.е. преобразованы к виду, приспособленному для анализа. Прохождение исходного требования через последовательность трансформаций от одного представления к другому, сопровождающееся соответствующим анализом, называется трассировкой требования. Основное назначение трассировки в том, чтобы в любой момент развития проекта сохранялась целостность и непротиворечивость конструируемой системы, реализующей принятые требования^{1Следует обратить внимание, что целостность и непротиворечивость — не характеристика принимаемых требований, а качества, которыми должна обладать конструируемая система. Противоречия предъявляемых требований есть следствие различий интересов инициаторов работ, очень часто именно они становятся стимулом для поиска новых решений, для перехода от одной версии системы к другой, т.е. являются источником развития системы (см. предыдущий раздел).} .

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

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

1. Исходное представление — текстовое описание пожеланий к системе, заданное в свободной форме. Это описание, в частности, может фактически содержать несколько требований, отражающих разные аспекты проекта, — элементарные составляющие требования.
2. Унифицированные представления — исходное представление требования разбивается на элементарные составляющие, которые описываются в базовом виде, приспособленном для дальнейшего использования на всех проектных уровнях. В частности, здесь могут применяться формализованные описания элементарных составляющих требования. Во всяком случае, на уровне унифицированного представления достигается однозначность понимания требований.
3. Типизированное представление — каждое из элементарных составляющих требования приписывается к некоторому типу. В результате формируется набор атрибутов элементарных требований и их значений. Эта информация допускает почти формальное сопоставление элементарных требований с различными требованиями, уже представленными в проекте. Сопоставление проводится на разных уровнях иерархии типов требований к системе.
4. Модельные представления уровня анализа — образы элементарных требований как элементы аналитических моделей системы. Если следовать RUP (похоже, что сегодня это становится общепринятым), то нужно говорить о моделях ситуаций использования и динамики взаимодействий, которые применяются для оценки требований.

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

   Если требование принимается на уровне анализа, то трассировка продолжается на следующих уровнях и можно говорить о продолжении последовательности трансформаций в реализации требования в компонентах программного изделия:
5. Модельные представления уровня конструирования — образы элементарных требований в диаграммах классов, состояний и других компонентах архитектуры системы. На этом уровне требования принимаются или отклоняются в зависимости от их соответствия уже разработанной части проекта.
6. Программные представления — программные рабочие продукты и их фрагменты, которые рассматриваются в качестве образов требований, представленных очередной версией системы.
7. Документные представления — фрагменты документов, сопровождающих программный код и предназначенных для поддержки деятельности пользователей.

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

Иерархия типов требований представлена на рисунке следующим образом. Верхний уровень — это абстрактный тип, свойства которого присущи требованиям всех типов (они сводятся к стандартизованному набору операций объединения, пересечения атрибутов, сравнения значений атрибутов и др.). Можно сказать, что Т_абстр задает регламент, которого следует придерживаться при оперировании требованиями. Следующий уровень содержит четыре обязательных типа: Т_экон, Т_функ, Т_инт и Т_эфф, которые объединяют требования экономического характера (пределы стоимости, рентабельность и пр.), функциональные требования, требования к интерфейсу и эффективности (производительности). Многоточием обозначены типы, которые, добавляются из-за специфики проекта. Т_a(a1,...,an_a), Т_b(b1,...,bn_b), Т_c(c1,...,cn_c), ..., Т_z(z1,...,zn_z) — это конкретные типы, которым приписываются элементарные составляющие требований (в скобках указаны их атрибуты).

Модельные представления уровней анализа и конструирования изображены в виде условных схем различных видов. Программные и документные представления — это текстовые файлы, пиктограммы которых показаны на рисунке.

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

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

увеличить изображение
Рис. 12.1. Схема трансформации требований