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

Содержание этой главы без труда подскажет ответы на «очень-очень много “Почему?”», а вот для того, чтобы ответить на вопросы «Куда?», «Откуда?», «По какой причине?», которые относятся к характеристикам связей, мы рассмотрим в этой главе другую тему метрики и параметры связей.

7.2 Элементарные связи.

Существует много способов отображения связей типа «многие-ко-многим». Вот вам случай из реальной жизни.

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

Эта конструкция занимала невероятно много места, требовала много времени, чтобы ее организовать, это было практически невозможно перемещать, это было невозможно поддерживать в актуальном состояние сколь-нибудь долгое время, но это работало!!!.

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

Однако у данного подхода есть также ряд недостатков:.

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

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

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

• Информация о связях требования отделена от сути самого требования.

В качестве альтернативы табличному методу, некоторые используют документы, которые «связаны» гиперссылками (hyperlinks). В этом случае требования могут быть выделены, взаимосвязаны с другими требованиями, и можно «гулять» по этим связям в любом направлении, при условии, что вы достаточно сообразительны.

В данном случае информация о связях (traceability) становится уже видимой в тексте требования, но все же и в этом подходе есть свои недостатки:.

• Для того чтобы провести анализ связей, вам возможно придется «пройти» весь путь, прежде чем вы увидите текст на другом конце этой цепочки.

• Если на другом конце гиперссылки требование было удалено, то на это конце ссылки у вас нет достоверной информации об этом. Постоянная необходимость отслеживать эти «зависшие» связи весьма затрудняет анализ.

Если вы не используете никакие инструментальные (программные) средства для управления связями, то какой бы метод вы не использовали, координировать эту работу вам будет весьма тяжело.

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

В общем и целом, для правильной организации связей между требованиями (в целях дальнейшего их анализа) необходимо иметь следующие возможности:.

• возможность создания связей между требованиями, тем самым формируя «разрешенные» отношения между ними;.

• возможность контролируемого удаления связей;.

• возможность одновременно видеть текст требований (+ атрибуты) на обоих концах выбранной связи;.

• возможность выполнять анализ покрытия (coverage analysis) для выделения тех требования, которые охвачены (или не охвачены) данной связью;.

• возможность выполнять одно- и многоступенчатый (многоуровневый) анализ влияния (impact analysis) для выделения таких наборов требований, которые оказывают влияние друг на друга;.

• возможность проведения одно- и многоуровневого анализа происхождения требования для отображения всей цепочки (дерева) требований: от исходного - до данного;.

• возможность проведения восходящего и нисходящего анализа покрытия для выявления требований покрываемых (или не покрываемых) выбранной связью.

На рис. 7.1 показан пример элементарных связей. Пользовательское требование связано входящими связями с тремя соответствующими системными требованиями. Можно одновременно видеть и текст пользовательского требования, и текст системных требований, которые его удовлетворяют. Рис. 7.2 демонстрирует второй пример простейших связей. Такой подход существенным образом облегчает анализ связей.

Рис. 7.1 Пример элементарных связей: армейский автомобиль.

7.3 Аргументы удовлетворения.

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

Смысл рис. 7.1 и 7.2 заключается в том, чтобы показать, что три системных требования существуют для того, чтобы удовлетворить одно пользовательское требование. Однако для человека, который не является экспертом в этих областях, достаточно сложно оценить обоснованность этих утверждений. А все потому, что на рисунках никак не отражена аргументация (первопричина), обосновывающая такие решения.

Картина была бы намного лучше, если для каждого требования было бы представлено такое понятие, как «аргумент удовлетворения». Из примера элементарных связей, показанного на рис. 7.1, видно, что три системных требования играют определенную роль в удовлетворении пользовательского требования, а вернее в удовлетоворении какого-то параметра (причины), связанного с этим требованием, но нет ничего, что точно показывало бы, что же это за причина и почему вдруг возникла необходимость иметь именно такую формулировку требования.

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

Рис. 7.3 Пример расширенных связей: армейский автомобиль.

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

удовлетворения пользовательского комбинируются системные требования. Для этих целей используется пропозициональный оператор:.

• использование конъюнкции (& = и) (conj uncti ОП) показывает, что для реализации параметра удовлетворения необходимо выполнение всех системных требований;.

• использование дизъюнкции (or = или) (di S uncti on) показывает, что для реализации параметра удовлетворения необходимо выполнение любого из системных требований.

Из примера конъюнкции на рис. 7.3 становится ясно, что пользовательское требование UR 21 может быть удовлетворено только в том случае, если будут реализованы все и каждое из системных требований - SR 15, SR 32 и SR 53.

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

Рис. 7.4 Пример расширенных связей: плита.

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

Теперь вы можете сравнить (и отметить разницу) пример на рис. 7.2 и его развитие на рис. 7.4. Если в первом случае было вовсе и неясно, что системные требования представляют собой два альтернативных решения, то уже на рис. 7.4 это абсолютно очевидно. Напрашивается и соответствующее решение - в случае, если невозможно будет сделать плиту с электрической конфоркой, ее можно будет заменить на газовую.

С применением концепции расширенных связей авторы впервые столкнулись на проекте модернизации сети железнодорожных дорог западного побережья Великобритании (Network Rail, - в последствии Railtrack - West Coast Route Modernization). Работая над этим проектом, специалисты компании Praxis Critical Systems разрабатывали процесс управления требованиями и моделью данных, используя принцип «обоснования спецификаций» (design justifications).

Этот же самый принцип лежит в основе многих других методов и подходов, в которых аргументы удовлетворения могут иметь разное название, например: «уточнение требований», «обоснование связей», «стратегия» и т.д.

Следует заметить, что аргумент удовлетворения может быть связан не только с требованиями (более низкого уровня). На рис. 7.5 показано, как аргумент удовлетворения дополняется знаниями о предметной области (DK = Domain Knowledge).

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

Рис. 7.5 Роль знаний о предметной области.

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

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

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

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

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

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

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

Рис. 7.6 Роль моделирования.

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

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

Рис. 7.7 Расширенные связи для нескольких уровней требований.

7.4 «Спуск» требований.

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

При этом, если известно, что требование нижнего уровня напрямую (без изменения) «спущено» с верхнего уровня, то процесс внесения изменений в требования может быть сильно упрощен. Другими словами, все изменения в требовании верхнего уровня могут быть автоматически «спущены» на нижние уровни.

Небольшое и простое дополнение к расширенным связям позволяет отражать суть подобных операций. Для иллюстрации этого в дополнение к операторам «or» и «&» в аргументах удовлетворения может использоваться оператор «тождества», изображающийся символом «=».

На рисунке 7.8, который является развитием предыдущего, показан пример использования этого оператора.

Рис. 7.8 Спуск требования с использованием оператора «тождество».

7.5 Анализ связей.

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

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

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

Рис. 7.9 Программное средство анализа аргументов удовлетворения.

7.6 Язык написания аргументов удовлетворения.

При работе с аргументами удовлетоворения, было бы весьма полезно иметь - по аналогии с требованиями - унифицированный подход для формулировки выражения аргументов. Ключевым принципом, который можно принять здесь на вооружение, является правило начинать предложение с фразы: «Это требование будет удовлетворяться ... ...», что помогает сосредоточиться на сути аргумента удовлетворения и сформулировать его более корректно.

В то время, как требования должны быть «атомарными» (см. главу 4), аргументы удовлетворения не должны быть столь сильно ограничены. Однако, если формулировка.

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

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

7.7 Анализ расширенных связей.

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

Более того, использование пропозициональных операторов (& и or) в аргументах удовлетворения дает дополнительную возможность для проведения анализа других типов. Так, например, структура связей может быть проанализирована на предмет определения числа степеней свободы, которые необходимы для достижения определенной цели.

Если в качестве примера взять структуру аргументов удовлетворения, изображенную на рис. 7.4, то пропозициональная структура для требования UR3 может быть выражена следующим образом:.

SR37 or (SR 31 & SR41).

Тогда, используя правила пропозициональной логики, эта запись, - не меняя ее смысла, может быть преобразована в несколько альтернативных выражений, каждое из которых отражает свой собственный способ возможной реализации (удовлетворения) требования:.

[SR37 & (not SR 31) & (not SR41)] или [SR37 & SR 31 & (not SR41)] или [SR37 & (not SR 31) & SR41] или [SR37 & SR 31 & SR41] или [(not SR37) & SR 31 & SR41].

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

7.8 Использование расширенных связей для тестирования.

Метод расширенных связей может применяться в отношении связей любого типа. Хотя до сих пор речь, в основном, шла о связях типа удовлетворение, тем не менее этот метод может также применяться и в отношении связей типа проверка. В этом случае термин «аргумент удовлетворения» может быть заменен термином «обоснование проверки» или «аргумент проверки». При этом все преимущества метода расширенных связей также будут проявляться и в области стратегии проверки.

7.9 Реализация метода расширенных связей.

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

7.9.1 Одноуровневые расширенные связи.

Данный подход проиллюстрирован на рис. 7.10.

Каждое требование верхнего уровня имеет единственную формулировку удовлетворения или стратегии в качестве атрибута. А несколько требований уровня ниже могут вытекать из него, образуя отношения «удовлетворяет» типа многие-ко-многим (стрелки связей показывают направление удовлетворения).

Для того, чтобы классифицировать этот аргумент как конъюнкцию (&) или дизъюнкцию (or), используется другой атрибут (на рисунке не показан).

Рис. 7.10 Одноуровневая расширенная связь.

7.9.2 Многоуровневые расширенные связи.

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

Главный аргумент «привязан» к требованию либо как атрибут, либо через отношение «устанавливает». А требования более низкого уровня, в свою очередь, связаны с аргументами низкого уровня связью типа «участвует», как это показано на рис. 7.11.

Рис. 7.11 Многоуровневая расширенная связь.

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

7.10 Проектная документация системы.

Проницательный читатель, наверняка, уже заметил, что идея аргументов удовлетворения весьма напоминает основную идею «сэндвича» управления требованиями, представленного на рис. 1.9, - только здесь «начинкой» между слоями являются аргументы удовлетворения. Далее - проще: если все аргументы удовлетворения собрать в единый документ, то все вместе они сформируют аналитическую и проектную документацию. Эта документация и будет являться связующим звеном между требованиями и моделированием.

Рис. 7.12 Аналитическая и проектная документация.

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

Рис. 7.12 иллюстрирует данный подход. Между уровнями требований располагаются проектные документы. Результаты моделирования на каждом уровне формируют данные, на которые ссылается соответствующий проектный документ. Тонкие стрелки обозначают потоки информации, а толстые стрелки - связи (трассировку).

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

Рис. 7.13 Раздел «Основные понятия».

Последовательность рисунков этого раздела иллюстрирует выдержки из документа «анализ потребностей», который описывает модель системы регистрации багажа в области проблем. Модель, если можно так выразится, располагается «между» документом, описывающим «перечень потребностей» и документом, отражающим «пользовательские требования» (см. рис. 7.12), и использует графическую нотацию и язык моделирования UML 2 для отображения анализа в визуальной форме.

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

Основные понятия. Для отображения основных понятий из области проблем и отношений между ними используется диаграмма классов UML. Каждое понятие изображается в виде класса UML, а каждое отношение - в виде ассоциации UML. И классы и ассоциации являются компонентами документа и отображаются в нем в текстовой форме. На рис. 7.13 показан пример системы регистрации багажа. Значок слева от параграфа обозначает, что эта часть документа соответствует определенному объекту в UML модели. Заинтересованные стороны. Данный раздел документа перечисляет все заинтересованные стороны, которые были определены в результате анализа, и содержит диаграмму классов, показывающую отношения между ними. Рис. 7.14 иллюстрирует пример системы с двумя заинтересованными сторонами и одним отношением между ними.

Рис. 7.14 Раздел «Заинтересованные стороны».

Статическое окружение. Целью этого раздела (рис. 7.15) является идентификация окружения, в котором существует система регистрации багажа. На диаграмме классов система регистрации багажа, наряду с окружающими и составляющими ее внутренними системами, изображается в виде класса. Для моделирования отношений между этими системами используются ассоциации и включения. Как уже отмечалось выше, каждый класс и ассоциация появляются в документе в виде текстового описания.

Рис. 7.15 Раздел «Окружение».

4.1.2 Поездка с багажом: нормальный ход событий.

Описание нормального хода событий для этого прецедента.

Рис. 7.16 Раздел «Функциональность».

• Функциональность. В этом разделе описываются основные (верхнего уровня) прецеденты для системы. Для этого используется серия диаграмм прецедентов, каждая из которых имеет одну или более диаграмм последовательностей. На рис. 7.16 показана всего одна диаграмма прецедента и соответствующая ей диаграмма последовательностей, иллюстрирующие нормальный ход развития событий сценария. Диаграмма последовательностей отражает взаимодействие между заинтересованными сторонами (некоторые из которых являются внешними системами) и рассматриваемой системой (системой регистрации багажа), что позволяет определить границы системы, суть ее работы и внешние интерфейсы.

• Обоснования. Данный раздел обобщает результаты анализа и моделирования и дает развернутые обоснования тому, каким образом потребности будут удовлетворяться возможностями системы. Одним из способов представления этой информации является использование «аргумента удовлетворения» для каждого из входящих требований (потребностей). Это именно здесь устанавливается связь, идущая к требованиям высокого уровня и идущая от требований нижнего уровня. В сущности, аргумент удовлетворения призван объяснить здесь, каким образом формулировка потребности декомпозируется на утверждения возможностей (см. рис. 7.17).

Левая колонка приведенной таблицы содержит формулировку потребности, средняя колонка содержит формулировку логического обоснования, правая колонка подтверждение обоснованности выбранного решения в виде ссылок на модель и требования, на основании которых эта обоснованность и выводится. Табличное представление, в сущности, является еще одним «сэндвичем»: два слоя требований, а между ними слой, подтверждающий обоснованность выбранных решений.

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

7.11 Параметры и метрики связей.

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

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

• Широта: насколько хорошо связи данного уровня «охватывают» требования верхнего (или нижнего) уровней треб ований?.

• Глубина: насколько глубоко вниз (или высоко вверх) через уровни продолжается выбранная связь?.

• Нарастание: насколько широко «разрастается» связь через уровни?.

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

• Фазовые метрики: это оценки, применимые к одной из фаз процесса разработки требований (напр., только к фазе разработки системных требований).

• Глобальные метрики: это оценки, которые могут характеризовать сразу несколько фаз процесса разработки требований.

Давайте рассмотрим теперь более подробно все три параметра, а также соотношение между ними.

7.11.1 Широта.

Этот параметр характеризует «покрытие» (степень охвата) и по сути является фазовой метрикой. Как обсуждалось в главе 1, «покрытие» может использоваться для количественной оценки хода работ, в рамках которых создаются связи между требованиями. Этот параметр оценки соотносится с одним (каждым) уровнем требований и показывает степень покрытия для уровня находящегося или выше, или ниже (или «рядом», если рассматривается степень покрытия требований этого уровня тестами).

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

7.11.2 Глубина.

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

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

7.11.3 Нарастание.

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

Рассмотрим рис. 7.18, на котором приведены четыре характерных примера.

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

Какую разницу между двумя требованиями характеризует в данном случае параметр ? Вполне возможно, что:.

• требование верхнего уровня (b) плохо сформулировано и, видимо, нуждается в разбиении на несколько отдельных декомпозиционных требований.

• требование верхнего уровня (b) более сложное по сути, чем требование (а), и, следовательно, ему нужно уделить больше внимания, расписав подробней;.

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

Рис. 7.18 Широта связей.

Конечно же, это явное расхождение в значении фактора нарастания на данном уровне можно компенсировать, спустившись еще на один уровень ниже. Это иллюстрируется примерами (с) и (d), где значения фактора нарастания уже одинаковы на втором нижнем уровне.

Итак, какие выводы можно сделать из этих примеров?.

Возможно, что:.

• требование верхнего уровня (с) было слишком абстрактно и требовало «расшифровки»;.

• требования среднего уровня (d) были излишне подробны для этого уровня.

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

7.11.4 Равномерность.

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

Другими словами, основной задачей является выявление требований, имеющих «ненормально» высокий или «ненормально» низкий фактор нарастания. Такие требования необходимо подвергнуть дополнительной тщательной проверке.

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

Рис. 7.19 Частотное распределение фактора нарастания требований.

По горизонтальной оси располагается фактор нарастания, а высота столбика по вертикальной оси соответствует количеству требований, которые имеют данное значение фактора. Как видно из рисунка, для большинства требований фактор нарастания лежит в диапазоне от 2 до 6, и только лишь небольшое количество требований имеют фактор нарастания либо равный 1, либо больший, чем 6. Последние явно нуждаются в более пристальном и особом внимании.

Следует заметить, что все приведенные выше рассуждения относились к случаю, когда нарастание «идет вниз», т.е. мы выясняли какое количество требований «вытекает» из определенного требования (нисходящий фактор нарастания). Однако, это не единственно возможное направление анализа. Вполне возможно провести анализ и в обратном направлении, т.е. выяснить какое количество требований «втекает» в данное требование.

Давайте рассмотрим рис. 7.20, не забывая о том, что связи между требованиями имеют характер «многие-ко-многим».

Два требования нижнего уровня (обозначены, как 2 и 3) имеют более одной исходящий связи, т.е. каждое из них «втекает» в более, чем одно требование высокого уровня. Что особенного можно сказать об этих требованиях? Возможно, эти требования более важны (критичны), чем остальные, поскольку от них зависит удовлетворение сразу нескольких требований выше и, следовательно, им нужно уделить больше внимания.

Рис. 7.20 Критичность требований.

Для выявления такого рода требований и может использоваться анализ распределения восходящего фактора нарастания. Рис. 7.21 демонстрирует типичное распределение значений фактора нарастания для этого случая.

Рис. 7.21 Частотное распределение критичности требований.

7.11.5 Влияние изменения.

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

После того, как в отношении данного требования появляется запрос на изменение (change request), все остальные требования, связанные с ним, должны автоматически становиться «подозрительными» (или сомнительными - suspect) до тех пор, пока специалистыпроектировщики не проанализирует реальное влияние изменения.

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

Даже на простом примере рис. 7.22 нетрудно заметить насколько сложной и запутанной может быть воздействие на систему потенциального изменения.

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

Рис. 7.22 Потенциальные изменения, вызванные запросом на изменение.

Часть (а) показывает возможное влияние изменения, которое выявляется с помощью анализа связей по направлению вниз (требования, которые необходимо проанализировать на предмет влияния на них этого изменения, показаны прямоугольниками с белым кружками). Часть (b) показывает вероятное влияние изменения, которое выявляется с.

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

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

Очень быстро становиться ясно, что все требования в приведенном примере являются «подозрительными» только из-за одного единственного запроса на изменение!.

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

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

Рис. 7.23 демонстрирует вышесказанное, - после формирования запроса на изменение, количество подозрительных требований резко возрастает, образуя пик, а затем - по мере анализа - это количество идет на спад.

Рис. 7.23 Обработка запросов на изменение.

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

7.12 Заключение.

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

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

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

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

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