).

DOORS (Dynamic Object Oriented Requirements System - динамическая объектноориентированная система для работы с требованиями) является на сегодняшний день лидирующим на рынке продуктом, который используется десятками тысяч специалистов во всем мире. Первоначально продукт был разработан компанией QSS Ltd (Оксфорд), а впоследствии приобретен, поддерживается и продолжает развиваться компанией Telelogic.

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

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

9.2 Необходимость управления требованиями.

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

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

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

9.3 Архитектура DOORS.

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

Вся информация в базе данных DOORS храниться в виде модулей (module) (см. рис. 9.1). Проекты (project) и папки (folder) используются в DOORS для более организованного представления модулей. Проект, по сути, является той же папкой, но предназначен для хранения всей информации, относящейся к данному проекту или подпроекту.

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

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

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

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

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

• descriptive (описательный) - модуль, используемый для хранения неструктурированной первичной информации (переписка, заметки сделанные в ходе интервью);.

• link (связи) - модуль, содержащий взаимосвязи и информацию о них между элементами данных.

Пользовательский интерфейс DOORS во многом напоминает интерфейс Windows Explorer (Проводник) и позволяет легко и удобно просматривать данные в системе.

9.4 Проекты, модули и объекты.

9.4.1 Окно базы данных DOORS.

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

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

9.4.2 Формальные модули.

Для создания в DOORS нового формального модуля необходимо выполнить следующую последовательность команд из главного меню: File ► New ► Formal Module, как это показано на рис. 9.3.

Рис. 9.3 Создание нового формального модуля.

Далее необходимо ввести имя модуля в поле Name (обязательно!) и описание в поле Description (рекомендуется). Поскольку для каждого нового объекта внутри модуля система автоматически будет создавать уникальный идентификационный номер, то в этом же окне можно задать число, с которого будет начинаться нумерация объектов модуля (Start at:). Помимо номера идентификатор объекта может содержать префикс (Prefix), который также можно задать при создании модуля. Префикс используется для более наглядного отображения содержимого модуля; например, для модуля, содержащего пользовательские требования, можно было бы задать префикс ПТ. Если для каждого формального модуля, входящего в конкретный проект, задать свой уникальный префикс, то простым способом мы получим уникальную идентификацию всех объектов всех модулей внутри данного проекта. В этом случае можно (и это проще) ссылаться на идентификатор объекта без указания названия модуля и всем будет понятно, какой именно модуль имеется в виду.

Если же открыть существующий формальный модуль, то, по умолчанию, слева будет окно структуры данных модуля (Module Explorer), а справа окно с данными, содержащимися в модуле (см. рис. 9.4).

Рис. 9.4 Вид формального модуля (по умолчанию).

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

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

DOORS дает возможность отображать данные в различном формате (см. рис. 9.5).

В формате Standard View объекты всех уровней просто отображаются в виде документа. При этом пользователь, при желании, может ограничить объем отображаемой информации, выбрав другой вид, например, формат Outl i ne Vi ew. В этом случае DOORS отобразит только заголовки, скрыв другие детали объектов. Этот вид похож на раздел книги, который называется «Оглавление». Вид Explorer View весьма удобен для отображения иерархической структуры модуля и поиска нужного объекта в модуле.

Рис. 9.5 Режимы отображения формального модуля.

Графический режим Graphics Mode позволяет отобразить информацию, содержащуюся в модуле, в виде иерархического дерева (см. рис. 9.6). Это значительно облегчает навигацию и поиск, если необходимая информация «спрятана» в больших объемах данных. В качестве названия элемента иерархии в этом случае используется заголовок объекта (Object Heading) и сокращенный текст самого объекта (Object Text).

Рис. 9.6 Графический режим.

9.4.3 Объекты.

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

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

Первая колонка показывает идентификатор объекта (Object Identifier), который автоматически присваивается DOORS. Идентификатор объекта состоит из двух частей:.

• префикс (обычно это аббревиатура, характерная для данного набора требований);.

• уникальный номер, присваиваемый DOORS.

Уникальный номер представляет собой целое число, присваивается системой автоматически и исключительно последовательно (1, 2, 3 и т.д.) каждому вновь создаваемому объекту и служит ключевой характеристикой объекта. Номер объекта уникален (единственен) внутри данного модуля.

Вторая колонка называется главной (Main) или текстовой (Text) и содержит сочетание трех различных атрибутов:.

Номера разделов присваиваются только тем объектам, которые имеют заголовок.

Рис. 9.7 Отображаемая информация.

Объект, выделенный сверху и снизу более темными горизонтальными линиями, носит название «текущего объекта» (Current Obj^). Большинство функций в системе DOORS, выполняемых в рамках данного модуля (напр., создание нового объекта, вставка объекта, перемещение объекта и т.д.), выполняются по отношению к текущему объекту.

Зеленые, желтые и красные полоски с левой стороны текстовой колонки являются индикаторами изменений (Change Bars). Зеленая полоска обозначает, что объект ни разу не изменялся с тех пор, когда данный вариант модуля был зафиксирован в качестве очередной версии (baseline). Желтая обозначает, что со момента последнего сохранения версии модуля в объект вносились какие-либо изменения. Красная же полоска обозначает, что изменения объекта, выполненные в текущей сессии, пока еще не сохранены в базе данных.

Оранжевый и темно-коричневый треугольники с правой стороны текстовой колонки показывают наличие связей данного объекта с другими объектами (Link Indicator). Оранжевый треугольник, направленный влево (внутрь объекта), обозначает наличие входящих связей, а темно-коричневый треугольник (не показан), направленный вправо (наружу из объекта), обозначает наличие исходящих связей.

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

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

Создание новых объектов в DOORS выполняется достаточно легко (см. рис. 9.8) новый объект просто вставляется на одну из двух возможных позиций относительно текущего объекта:.

• новый объект создается на том же уровне иерархии, что и текущий объект (команды Insert ► Object), или.

• новый объект создается как первый дочерний объект по отношению к текущему объекту (команды Insert ► Object Below).

Рис. 9.8 Создание объектов.

DOORS также предлагает мощные средства для редактирования структуры модуля. Например, древовидная структура модуля может быть скорректирована с помощью функций вырезки и вставки (Cut и Paste).

Рис. 9.9 Вырезка и вставка объектов.

Операция «вырезать» (Cut) убирает текущий объект и все его дочерние (!) объекты из структуры модуля. Это операция вызывает автоматическое обновление нумерации заголовков всех объектов в модуле так, чтобы устранить образовавшийся разрыв в структуре. Вырезанный объект может быть затем вставлен (Paste) либо после текущего объекта на том же уровне иерархии, либо в качестве первого дочернего объекта по отношению к текущему (см. рис. 9.9).

9.4.4 Графические объекты.

DOORS поддерживает OLE-технологию (Object Linking and Embedding) для вставки в текстовый атрибут любых объектов, в том числе, и графических. Такие объекты вставляются в модуль точно так же, как это делается, например, в MS Word. С помощью этой технологии в документ с требованиями можно вставлять рисунки, диаграммы, графики, документы, электронные таблицы, а также множество другой информации, необходимой для пояснения того, что утверждается в требовании.

9.4.5 Таблицы.

Зачастую требования, или связанная с ними информация, отображаются в виде таблицы.

Рис. 9.10 Создание таблицы.

В этом случае таблица может быть создана либо до/после выбранного объекта, но на одном иерархическом уровне с ним, либо просто в пустом модуле на самом верхнем уровне. При создании таблицы необходимо задать количество колонок и строк, как это показано на рис. 9.10.

Следует заметить, что каждая ячейка таблицы, создаваемой в DOORS, представляет собой отдельный объект (в отличие от таблицы Excel, которая может быть вставлена в модуль как OLE-объект). Таблица может быть удалена, только в том случае, если нет связей ни с ней, ни с одной из ее ячеек.

9.5 История изменений и версии.

9.5.1 История изменений.

DOORS сохраняет историю изменений всех модулей, объектов и их атрибутов.

Запись любого изменения отобразит автора изменения, дату и время изменения, а также состояние объекта и его атрибутов до и после внесенного изменения. История модуля содержит все события, которые имели место по отношению к модулю.

Рис. 9.11 Окно истории изменений объекта.

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

9.5.2 Версии.

Версия (baseline) - это «замороженная» копия модуля.

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

Каждой зафиксированной версии модуля в DOORS присваивается номер и название. Версии модуля существуют в DOORS только для просмотра (read-only) и их нельзя редактировать.

После создания версии вся история изменений объектов и их атрибутов сохраняется (остается) вместе с зафиксированной версией, в то время как для текущей версии модуля история изменений объектов отсутствует (становиться пустой) и вновь начинается с нуля. Таким образом, история жизни модуля сохраняется в виде серии версий.

9.6 Атрибуты и виды.

9.6.1 Атрибуты.

Атрибуты являются тем средством, которое позволяет «привязывать» к модулям и объектам информацию, относящуюся к ним.

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

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

По умолчанию в DOORS уже заложены и могут использоваться различные стандартные типы атрибутов, называемых также базовыми типами. Это дает возможность создавать и определить атрибуты такие, например, как целое число (integer), вещественное число (real ), дата (date), строка (string), текст (text), имя пользователя (user name). Но при этом пользователь также может создавать и свои собственные типы атрибутов.

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

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

9.6.2 Виды.

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

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

9.7 Связи и их анализ.

Doors дает возможность создавать связи между объектами, а также предоставляет средства для их анализа.

9.7.1 Связи.

В DOORS предусмотрена возможность связывать объекты между собой. В терминах DOORS связь называтся Link.

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

DOORS предлагает несколькими способов создания связей и последующей работы с ними. Индивидуальная связь между двумя объектами может быть создана с помощью.

технологии drag-and-drop (обычно так создаются связи между двумя объектами в одном или разных модулях). Для создания наборов (блоков) связей предпочтительнее воспользоваться другим способом. Например, функция copy and I i nk позволяет скопировать необходимый набор объектов и тут же связать каждую копию с ее оригиналом.

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

9.7.2 Отчеты о связях.

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

Наиболее простым способом получения экранного отчета о связях (или, как еще говорят, - о трассировке) является использование анализатора связей (в главном меню нужно выбрать Analysis ► Traceability Explorer), который дает возможность пользователю в одном окне видеть связи сразу между многими документами (см. рис. 9.12).

Рис. 9.12 Анализатор связей (Traceability Explorer).

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

Для создания в DOORS такого вида необходимо воспользоваться пунктом меню Analysis ► Wizard, который вызовет программу-мастера, позволяющую пошагово определить информацию о каких именно связях и атрибутах объектов необходимо отобразить. Колонки трассировки, в которые выводится эта информация, имеют динамическую природу и автоматически обновляются каждый раз, как только создается новая связь или изменяются данные на другом конце существующей связи. Использование этого подхода позволяет «собирать» информацию из различных модулей в единый отчет, с которым можно работать и на экране, и который легко распечатывается на принтере.

На рис. 9.13 показан пример вида, содержащего колонки трассировки.

Рис. 9.13 Колонки трассировки, показывающие удовлетворяющие требования.

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

В качестве примера использованы расширенные связи и в колонках вида (слева направо) представлены:.

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

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

• оператор расширенной связи (атрибут пользовательского требования из текущего модуля);.

• аргумент удовлетворения (атрибут пользовательского требования из текущего модуля);.

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

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

Рис. 9.14 Колонки трассировки для исходящих связей.

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

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

9.8 Импорт и экспорт.

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

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

Рис. 9.15 Экспорт в DOORS из MS Word.

Так, например, на рис. 9.15 показана передача данных из документа MS Word в DOORS. Эту операцию можно легко выполнить с помощью специальной иконки на панели инструментов Export to DOORS, которая появляется в Word при инсталяции DOORS. В появившемся диалоговом окне следует лишь указать название модуля (возможно, нового), в который будут добавлены требования и внести его описание. При этом DOORS сохранит структуру исходного документа, т.е. Заголовок 1 (Heading 1) станет в DOORS объектом первого уровня (а границы объекта будет определять значок параграфа).

Аналогично, DOORS предоставляет возможность и экспорта в различные форматы, обеспечивая этим возможность передачи информации в ряд приложений. В качестве примера на рис. 9.16 показан экспорт данных из DOORS в Word.

Рис. 9.16 Экспорт из DOORS в MS Word.

Эта операция является обратной предыдущей. При этом документ в Word сохранит ту же структуру, что и модуль в DOORS - заголовки первого уровня в иерархии объектов DOORS становятся заголовками первого уровня в Word и т.д., по уровням (в Word при выводе текста будет автоматически использоваться нормальный стиль - Normal style).

DOORS поддерживает функции экспорта и импорта для большого количества приложений и форматов, включая RTF, Word, WordPerfect, Excel, Lotus, Access, Plain Text, HTML, PowerPoint, MS Project, Outlook и многих других.

9.9 Моделирование на UML с помощью DOORS/Analyst.

DOORS/Analyst это результат интеграции DOORS с продуктом Telelogic TAU G2 (системой моделирования на UML).

Таким образом, DOORS/Analyst позволяет создавать UML модели и диаграммы непосредственно в формальных модулях DOORS, размещая их внутри объектов.

Рис. 9.17 Моделирование на UML c помощью DOORS/Analyst.

Более того, такие объекты могут быть помечены как элементы UML, например актеры, классы, состояния. И тогда, если какие-либо диаграммы с помощью опций главного меню вызываются и вставляются в модуль DOORS, то объекты, помеченные таким образом синхронизируются с элементами, которые появляются в диаграммах. Немаловажный результат такого подхода - возможность иметь трассировку требований вплоть до элементов внутри диаграммы.

На рис. 9.17 показан пример модуля DOORS, в котором для маркировки объектов в качестве элементов UML и вставки UML диаграммы классов использовался DOORS/Analyst. При этом объекты, маркированные как «UML element», не только помечаются специальными пиктограммами слева от основной колонки, но и справа от нее в столбце «Object Type» (тип объекта) указывается сущность UML элемента.

Двойное нажатие мышкой на UML диаграмме, запускает редактор диаграмм DOORS/Analyst, показанный на рис. 9.18.

Рис. 9.18 Редактор UML диаграмм DOORS/Analyst.

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

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

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

В качестве примера того, как средство для моделирования может дополнить пакет для управления требованиями (или наоборот), был представлен инструмент DOORS/Analyst.

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

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

Средства к существованию. От выражения: «зарабатывать на хлеб с маслом»

UML - Unified Modeling Language (

) - универсальный язык моделирования. Методология и нотация проектирования ПО, разработанная OMG-группой (Object Management Group,

), в состав которой входит и Telelogic.

прим. переводчика. Квартиль - граница на шкале измеряемого (тестируемого) параметра, отделяющая 25% испытуемых от общей выборки. Различаются три квартиля: Q1 - первые 25%, Q2 - 50% (медиана), Q3 - 75%.

прим. переводчика: В оригинале книги рассматривается версия 7.1, но мы приняли решение отступить от оригинала и использовать для изложения примеры, выполненные на базе последней версии DOORS - 8.0.