Управління ІТ-проектами / Література / Элизабет Халл. Разработка и управление требованиями

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

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

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

6.3.1 Разработка архитектурной модели системы

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

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

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

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

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

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

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

6.3.2 Получение требований из архитектурной модели системы

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

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

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

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

6.5 Заключение

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

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

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

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

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

7 Расширенные связи и их анализ

Вначале есть «Кто?», «Что?», «Когда?» и «Где?», затем последуют «Куда?», «Откуда?», «По какой причине?» и очень-очень много «Почему?».

Зафод Библброкс из книги «Автостопом по Галактике».

Дуглас Ноэль Адамс (Douglas Noel Adams), писатель, 1952–2001

7.1 Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Из примера конъюнкции на рис. 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 Роль знаний о предметной области.

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