Использование Rational Requisite Pro

ВВЕДЕНИЕ

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

1. ОПРЕДЕЛЕНИЕ ТРЕБОВАНИЙ
Требования могут быть определены как:
- характеристики программного обеспечения (ПО), необходимые пользователю для удовлетворения своих потребностей или достижения своих целей;
- характеристики ПО, удовлетворяющие контракту, спецификации, стандарту или другим формальным документам.
По-другому, требования это характеристики, которым должна удовлетворять программная система.
2. ПРОБЛЕМЫ УПРАВЛЕНИЯ ТРЕБОВАНИЯМИ

1. Требования не всегда ясны и имеют много источников своего происхождения;
2. Требования не всегда легко и ясно изложить на словах;
3. Существует множество требований на различных уровнях детализации;
4. Число требований может быть огромным и вследствие этого не управляемым;
5. Требования изменчивы;
6. Требования могут иметь свойства, например, очень важные требования;
7. Требования от различных заинтересованных лиц могут быть противоречивыми.
Для разрешения проблем, связанных с требованиями, коллективам разработчиков следует предпринять следующее:
1. Проанализировать проблему. Сформулировать ее совместно с заинтересованными лицами. Определить границы в рамках, которых решается проблема, и ограничения, накладываемые на ее решение.
2. Определить потребности заинтересованных лиц.
Результатом определения потребностей заинтересованных лиц является описание их потребностей в различной форме.

3. Описать систему. Результатом описание системы является ее описание на естественном языке и в графике.

4. Управлять проектом. Определить ресурсы для управления (время, люди, финансы). При управлении проектом следует учитывать атрибуты требований, например, риск, приоритетность и т.д.;

5. Уточнять описание системы. Результатом уточнения описания системы является более подробное ее описание в различных формах для разных специалистов коллектива разработчиков.

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

3. ХАРАКТЕРИСТИКИ ТРЕБОВАНИЙ

Требования RequisitePro имеют типы.

Тип требования это шаблон требования. Шаблон требования может иметь свои атрибуты. В RequisitePro существуют атрибуты требований по умолчанию: приоритет (priority), состояние (status), стоимость (cost), трудность при реализации (difficulty), стабильность (stability), назначенный (assigned to), источник (origin).

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

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

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

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

Требование родитель:

Система должна отображать информацию о клиенте.

Требования потомка – в системе должна отображаться детально следующая информация о клиенте:

Наименование, Адрес, Год рождения клиента.

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

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

Можно устанавливать связь зависимость

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

Между двумя требованиями может существовать связь зависимость: «обуславливает» (is traced to), «зависит от» (traсed from).

Путь А требование «добавить команду в меню»;

В – протестировать команду в меню.

Связь между А и B следующая А «обуславливает» B A is traced to B;

Связь между B и А следующая: В «зависит от» A, B is traсed from A.

Между требованиями существуют прямые и не прямые зависимости.

Пример не прямой зависимости:

Связь между А и B следующая А «обуславливает»B;

Связь между B и C следующая B «обуславливает» C;

Связь между А и C - не прямая зависимость.

RequisitePro поддерживает не прямые зависимости между требованиями. Но их нельзя модифицировать непосредственно. То есть связь между А и С нельзя изменять непосредственно.

На рис. 1 представлены примеры связей «trace to» обуславливает между потребностями заказчика, функциями программного продукта и требованиями к системе.

Рис. 1. Примеры связей «trace to» (обуславливает) между

потребностями заказчика, функциями программного продукта

и требованиями к программному обеспечению

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

Требования подтипа имеют дополнительные атрибуты в отличие от требования типа.

4. ПРОЕКТ В REQUISITEPRO

Проект в RequisitePro это совокупность базы данных требований и относящихся к ним документов. Проект создается администратором проекта. Администратор определяет структуру проекта и устанавливает права доступа пользователей проекта.

Каждый проект имеет свою собственную БД для хранения всех требований проекта. Требования в БД можно добавлять, редактировать или удалять. Если требования изменяются в документе, то они изменяются и в БД. Часто проект может включать множество документов. Информация из всех документов проекта сохраняется в БД.

В окне просмотра БД требование отражается следующим образом:

Метка(Tag)номер требования:описание требования,

например, функциональное требование в окне просмотра БД может отображаться следующим образом:

UC6:Формировать подтверждение контрагенту

В документе требование отражается следующим образом:

Закладка Метка(Tag)номер требования:описание требования Закладка,

Например,

[UC6:Формировать подтверждение контрагенту]

Иерархические требования и требования родитель-потомок имеют следующую нумерацию в БД и документах:

Номер требования более высокого уровня. Номер требования следующего уровня.

Например,

          SR4:Система должна отображать

          SR4.1:Адрес

          SR4.1:Наименование клиента

          Лист проектов это библиотека проектов RequisitePro конкретного пользователя. Администратор может просматривать всю библиотеку проектов.



          5. РАБОЧИЕ ПРОСТРАНСТВА В REQUISITEPRO

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

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

На рис. 2 представлено изображение палитры инструментов и схематическое изображение рабочих пространств RequisitePro.

          Рабочее пространство WORD это место где RequisitePro создает и модифицирует требования в документе. Рабочее пространство WORD

содержит спецификацию требований в форме документа RequisitePro и документа WORD. RequisitePro встраивается в WORD.

          Рабочее пространство просмотров это окно в БД.

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

Рис. 2. Изображение палитры инструментов и рабочих пространств

RequisitePro.

Существуют три вида просмотров требований в БД.

1. Матрица требований с атрибутами. Отображает все требования и их атрибуты. Требования отражаются в строках, их атрибуты - в столбцах;

2. Матрица связей. Отображает связи между двумя типами требований.

3. Дерево связей. Отображает список зависимых требований определенного типа.

Матрица требований с атрибутами

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

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

Рис. 3. Пример отображения матрицы требований с атрибутами

в RequisitePro

Матрица связей требований

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

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

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

Если в ячейке стрелка указывает вверх на колонку с требованием, то требование в строке обуславливает требование в столбце.

Если в ячейке стрелка указывает вниз на строку с требованием, то требование в столбце зависит от требования в строке.

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

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

Пример отображения требований в БД с использованием матрицы связей представлен на рис. 4.

Рис. 4. Пример отображения требований в БД

с использованием матрицы связей

Дерево связей

Дерево связей требований обеспечивает графическое представление связей требований двух видов: обуславливает (traced to), зависит (traced form). В дополнении к этому дерево связей отображает связи родитель потомок. Связи между требованиями обуславливает (traced to), зависит (traced form) отображаются в дереве связей стрелками.

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

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

Стрелки, перечеркнутые по диагонали, указывают на подозрительные связи (traced to), зависит (traced form).

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

Пример отображения требований в БД с использованием дерева связей представлен на рис. 5.

Рис. 5. Пример отображения требований в БД

с использованием дерева связей

6. ДОКУМЕНТЫ

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

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

На рис. 6. представлена структура программного продукта RequisitePro.

Рис. 6. Структура программного продукта RequisitePro

7. КТО РАБОТАЕТ С REQUISITEPRO

В своей работе RequisitPro могут использовать, например,

- менеджеры проекта;

- бизнес аналитики;

- системные аналитики;

- любой разработчик требований;

- рецензенты требований.

8. МЕТОДИКА УПРАВЛЕНИЯ ТРЕБОВАНИЯ ПРИ РАЗРАБОТКЕ

ПРОГРАММНЫХ СИСТЕМ С ИСПОЛЬЗОВАНИЕМ

REQUISITEPRO

Методика управления требованиями при разработке программных систем с использованием RequisitPro должна включать два этапа:

1. Планирование проекта.

2. Реализацию проекта.

8.1. Планирование проекта

Планирование проекта включает следующие шаги:

1. Выбор методики разработки ПО и определение документов и требований и т.д.;

2. Выбор пользовательской среды (автономный, многопользовательский режим);

3. Выбор СУБД (Acces, SQL Server, Oracle);

4. Определение способа создания требований (только в БД, только в документах, в БД и документах);

5. Определение будут ли импортироваться/экспортироваться требования в проект;

6. Задание названия проекта;

7. Краткое описание проекта;

8. Определение места расположения проекта.

На основе выбранной методики разработки ПО следует определить:

1. Этапы работ по разработке ПО, на которых будет использоваться RequisitPro;

2. Определить документы, которые будут разрабатываться в проекте;

3. Разработать шаблоны документов для каждого из этапов разработки ПО;

4. Определить типы документов, которые будут использоваться в проекте;

5. Определить типы требований в документах и БД;

6. Определить атрибуты требований;

7. Задать зависимости между требованиями.

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

В таблице 1 представлен пример плана проекта.

Таблица 1.

Пример плана проекта

Наименование документа	Тип Документа расширение	Метка требования тип требования	Обуславливает требование	Зависит от требования
Словарь терминов предметной области	Тип: Словарь .GLS	TERM Тип:Термин	Нет	Нет
Бизнес правила предметной области	Тип: Бизнес правила .BRUL	BUS Тип:Бизнес правило	UC	Нет
Техническое задание на АС	Тип: Техническое задние .TT	UC Тип:Функция системы	ТС (тестируемые функции)	NEED (потребности заказчика)

Тип требования имеет атрибуты. В RequisitePro можно для каждого типа требования задать атрибуты по умолчанию. Примеры атрибутов требований по умолчанию приведены в приложении 4.

В RequisitePro можно создавать атрибуты по своему усмотрению следующих типов:

- текстовые данные (textual data);

- значение из списка (single value list type);

- несколько значений из списка (multiple value list type);

- целые числа (integer);

- действительные (real);

- дата (date);

- время (time).

Примеры требований с атрибутами представлены в приложении 5.

8.2. Реализация проекта

Реализация проекта в RequisitPro включает:

1. Создание проекта;

2. Создание шаблонов документов;

3. Задание типов требований;

4. Задание атрибутов типов требований;

5. Задание типов документов;

6. Создание документов;

7. Создание требований в документах и/или в БД и их атрибутов;

8. Создание просмотров требований;

9. Задание связей между требованиями;

10. Слежение за изменениями требований;

11. Создание истории изменений требований;

12. Обеспечение безопасности проекта;

13. Проведение дискуссий по вопросам требований и документов.

Лабораторная работа №1

Запуск RequisitePro

Введение

Целью данной лабораторной работы является добавление нового проекта в список проектов, изучение примера проекта Lerning Project и системы встроенной помощи Help.

Внимание!

Окно RequisitePro Let’s Go RequisitePro

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

Рис. 1. Окно

RequisitePro Let’s Go RequisitePro

В окне Let’s Go

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

При нажатии иконок со следующими наименованиями появляются:

1. RequisitePro Quick Tour - Рекомендации по быстрому освоению RequisitePro;

2. RequisitePro

Tutorial – Учебник по RequisitePro;

3. Requirements Management Tour - Описание управления требованиями;

4. Project Administration Tips - Рекомендации по администрированию проекта;

Из окна

Let’s Go RequisitePro можно вызвать:

- методологию разработки программного обеспечения Rational Unified Process, при нажатии кнопки «Software Engineering Process -- Rational Unified Process»;

- статьи соответственно при нажатии кнопки «Applying Requirements Management with Use Cases», «Traceability Strategies for Managing Requirements with Use Cases» и т.д. (раздел окна White Papers);

- систему встроенной помощи по расширенному интерфейсу RequisitePro, при нажатии кнопки (RequisitePro Extensibility Interface Online Help);

- описание версии RequisitePro при нажатии кнопки «RequisitePro Release Notes»;

- описание улучшенного интерфейса пользователя при нажатии кнопки «Enhanced RequisitePro Enviorement»;

- информацию по технической поддержке RequisitePro, при нажатии кнопки «Contacting Technical Support»;

- информацию по поддержке RequisitePro на веб-сайтах, при нажатии кнопки «RequisitePro Product Support on the Web»;

- информацию о RequisitePro на сайте фирмы Rational Software Corporation, при нажатии кнопки «Rational on the Web»;

- обратиться по интернет к разработчикам при нажатии кнопки «Rational Developer Network».

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

Цели

Целями лабораторной работы являются:

1. Изучение работы со списком проектов RequisitePro;

2. Добавление проектов к списку проектов, просмотр связанных с проектом документов.

3. Изучение работы с окном «Let’s Go RequisitePro» и дополнительным возможностям системы встроенной помощи Help.

Упражнение 1.1 - Добавление проекта к списку проектов

Задачи:

В упражнении 1.1 требуется выполнить следующее:

1. Открыть и закрыть RequisitePro.

2. Просмотреть список проектов RequisitePro в окне «Open Project».

3. Определить расположение файла RequisitePro в формате *.RQS.

4. Удалить проект из списка проектов.

5. Добавить проект к списку проектов.

ШАГИ	КОММЕНТАРИИ
1. Для запуска RequisitePro щелкните дважды по иконке с изображение продукта на рабочем столе или выберите RequisitePro через меню «Пуск».	На экране появляется окно помощи Let’s Go Rational RequisitePro. Выберите кнопку «Close» для продолжения упражнения. RequisitePro откроет панель инструментов. На экране появляется окно со списком проектов.
2. Просмотрите список проектов. Убедитесь, что в списке проектов существует обучающий проект Learning Project.	Learning Project является типовым проектом и включает информацию, которую можно использовать при создании собственных проектов.
3. Выберите из списка проектов Learning_Business.	Learning_Business - другой мини-проект, который также можно использовать при создании собственного проекта.
4. Щелкните по кнопке «Remove».	Проект Learning_Business удаляется из списка проектов. Проект больше не виден в списке проектов. Однако проект сохраняется в файловой системе. Проект можно добавить к списку проектов при нажатии кнопки «Add» и выбора директории, в которой хранится проект.
5. Нажмите кнопку «Add».
6. Просмотрите окно «Add Project» и найдите папку с примерами RequisitePro, в которой хранится проект Learning_Business.	Проект размещен в директории C:\ProgramFiIes\ Rational \RequisitePro\ samples \Learning_Project\ Business\ Learning_Business.rqs
7. Выберите файл Leaing_Business.rqs.
8. Нажмите кнопку «Open» для добавления Learning Project обратно в список проектов.
9. Выберите Learning_Business. Нажмите кнопку «Properties».	В появившемся окне «Database Properties» отображаются основные свойства проекта, например, тип используемой базы данных, директории расположения файлов RequisilePro и т.п. Просмотрите свойства проекта.
10. Нажмите кнопку «Configure ...».	В появившемся окне отображается кнопки для работы с БД. Просмотрите их.
11. Для возврата в окно со списком проектов щелкните по кнопке «Cancel», затем в появившемся окне еще раз щелкните кнопке «Cancel».

<

Упражнение 1.2 – Изучение Learning Project

Задачи:

В упражнении 1.2 требуется выполнить следующее:

1. Открыть Learning Project.

2. Открыть связанные с проектом документы.

3. Переключаться между активными документами.

ШАГИ	КОММЕНТАРИИ
1. В списке существующих проектов выберите проект Learning Project. Нажмите кнопку «ОК». Снова нажмите кнопку «ОК».	Открывается окно «Project Logon». В окне отображается имя пользователя «Unknown». Открывается проект Learning Project со списком папок и документов.
2. Нажмите кнопку «ОК».	Открывается проект Learning Project со списком папок и документов.
3. Открыть связанные с проектом документы можно по очереди, выбирая папки и требуемый документ с изображением иконки редактора Word. Просмотрите все документы Word.	Выбранный документ становится «активным» или отображаемым документом в RequisitePro. Просмотрите выбранный документ.
4. В меню File выберите пункт Open Project. В появившемся списке проектов выберите проект QuarterByte Savings Bank Example Project и нажмите кнопку «OK». Снова нажмите кнопку «ОК».	Открывается окно «Project Logon». В окне отображается имя пользователя «Unknown». Открывается проект QuarterByte Savings Bank Example Project со списком папок.
5. Просмотрите типовой проект.	Изучите документы и свойства типового проекта.
6. Закройте проект QuarterByte Savings Bank Example Project.

Упражнение 1.3 – Использование встроенной системы помощи HELP

Задачи:

В упражнении 1.3 требуется выполнить следующее:

1. Вызвать встроенную систему помощи HELP.

2. Рассмотреть разделы справки, содержание и индекс для поиска, окно Let’s Go Rational RequisitePro.

ШАГИ	КОММЕНТАРИИ
1. Используя панель инструментов RequisilePro, выберите пункт меню Help.	Появляется подменю параметров встроенной справочной системы HELP RequisilePro (в дальнейшем по тексту просто HELP).
2. Выберите пункт меню Contents and Index и просмотрите вкладки HELP.	Эта опция - типичный справочный файл помощи Windows с вкладками. После окончания просмотра закройте это окно.
3. Выберите пункт меню Extensibility Interface Reference и просмотрите этот раздел Help.	Появляется информация относительно интерфейса доступа к данным RequisilePro.
4. Выберите меню Help снова и выберите пункт меню Let’s Go Rational RequisitePro…	На экране появляется окно Let’s Go Rational RequisitePro
5. Нажмите на каждую из четырех иконок HELP в окне Let’s Go Rational RequisitePro….	Появляются различные разделы. Просмотрите эти разделы.
6. Нажмите на иконки в разделах Process, White Papers, and Other Links для изучения дополнительных возможностей.	Кнопки, размещенные в нижней части окна Let’s Go Rational RequisitePro обеспечивают доступ к Rational Unified Process, к статьям White Papers, технической поддержке и другим ресурсами сети интернет.
7. По окончании работы закройте окно Let’s Go RequisitePro….	На этом завершаются упражнения Лабораторной работы № 1.

<

Лабораторная работа №2

Создание нового проекта

Введение

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

Цели

Целями лабораторной работы являются:

1. Добавление шаблонов документов для их дальнейшего использования.

2. Изучение параметров конфигурации RequisitePro.

3. Создание проекта.

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

Упражнение 2.1.– Добавление шаблона в директорию

Задачи:

В упражнении 2.1 требуется выполнить следующее:

1. Добавить шаблон в директорию.

2. Определить расположение файлов с шаблонами.

ШАГИ	КОММЕНТАРИИ
1. Закройте RequisitePro, если он открыт. 2. Создайте в Word шаблон технического задания (ТЗ) в соответствие с приложением 1. Сохраните его в файле TZ.dot. 3. Создайте в каком–либо текстовом редакторе файл с наименованием Имя_файла_шаблона.def, например TZ. def.	Файл Имя_файла_шаблона.def должен включать 3 строки, отделенных друг от друга символом перевода строки. В первой строке указывается название шаблона документа, во второй – описание шаблона, в третьей - Имя_файла_шаблона.dot, например, ТЕХНИЧЕСКОЕ ЗАДАНИЕ Описываются требования к системе ШАБЛОН_ТЕХ_ЗАДАНИЯ.dot
2. Скопируйте файлы с шаблонами документов каталог: C:\PROGRAM FILES\RATIONAL\ REQUISITEPRO\OUTLINES: Имя_файла_шаблона.dot Имя_файла_шаблона.def	В этой директории в RequisitePro находятся шаблоны документов.

Упражнение 2.2.– Создание проекта в RequisitePro

Задачи:

В упражнении 2.2 требуется выполнить следующее:

1. Создать проект.

ШАГИ	КОММЕНТАРИИ
1. Для запуска RequisitePro щелкните дважды по иконке с изображение продукта на рабочем столе или выберите RequisitePro через меню «Пуск».	На экране появляется окно помощи Let’s Go Rational RequisitePro. Выберите кнопку «Close» для продолжения упражнения. RequisitePro откроет список существующих проектов.
2. В текущем окне выберите закладку New.
3. Выберите шаблон Blank, нажмите кнопку «OK».	Появляется окно Rational RequisitePro Project Properties для настройки параметров проекта.
4. В поле Name введите название проекта, например, Техническое Задание.
5. Нажмите кнопку «Browse». Задайте каталог проекта. Затем нажмите кнопку «OK».	Используйте путь - C:\PROGRAM FILES\RATIONAL\ REOUISITEPRO\НАЗВАНИЕ ПРОЕКТА
6. В поле Description введите описание проекта, например, «представлены требования к автоматизированной системе».	Вводится любое полезное пояснение.
7. Для создания проекта нажмите кнопку «OK».	Проект будет создан и помещен в список проектов RequisitePro.
8. При появлении сообщения Project directory does not exist. Do you want to create it? нажмите кнопку «Yes».	Сообщение появляется, если каталог проектов не существует.

<

Упражнение 2.3.– Установка параметров конфигурации RequisitePro

Задачи:

В упражнении 2.3 требуется выполнить следующее:

1. Просмотреть параметры конфигурации RequisitePro.

ШАГИ	КОММЕНТАРИИ
	RequisitePro имеет настройки. Например, можно задать параметры дисплея, расположения архива и т.п.
1. На панели инструментов RequisitePro выберите в меню пункты ToolsàOptions ...	На экране появляется окно Options с параметрами конфигурации RequisitePro.
2. Поэкспериментируйте с параметрами конфигурации. Переключая параметры, обратите внимание на поведение панели инструментов. Сбросьте все параметры.	В окне имеются несколько групп параметров конфигурации.
3. Просмотрите другие доступные опции. Для получения дополнительной информации по параметрам конфигурации нажмите кнопку «Help» или F1.	После изучения параметров конфигурации закройте окно Options.
	На этом завершаются все упражнения лабораторной работы № 2.

Лабораторная работа № 3

Создание типов требований и атрибутов типов требований

Введение

Упражнения в Лабораторной работе № 3 включают определение типов требований и настройки RequisitePro

с целью получения специфической информации при управлении требованиями.

Цели

Целями лабораторной работы являются:

1. Определение типов требований.

2. Добавление атрибутов требований и их значений.

Упражнение 3.1.– Создание типов требований

Задачи:

В упражнении 3.1 требуется выполнить следующее:

1. Создать типы требований.

ШАГИ	КОММЕНТАРИИ
	Перед созданием требований нужно определить их типы. В приложении 3 представлены некоторые типы требований для документа ТЗ. Если проект создан на основе имеющегося в RequisitePro проекта, то многие типы требований уже существуют.
1. Используя панель инструментов RequisilePro, откройте созданный проект. Выберите проект из текущего списка проектов.
2. Используя панель инструментов, выберите в меню File пункт Properties …	На экране появляется окно c вкладками для задания различных атрибутов проекта.
3. Выберите вкладку Requirement Types.	На экране появляется окно для создания нового типа требования.
4. Нажмите кнопку «Add...»	Открывается окно Requirement Type.
5. В поле Name введите: Функция системы.	Задается имя новому типу требования.
6. В поле Description введите описание нового типа требования, например, «используется для описания функций системы».	Задается описание требования.
7. Определите в поле Initial Requirement #: первоначальный номер требования По умолчанию номер есть 1.	Задается номер первого требования с таким типом требования.
8. Удостоверитесь, что флаг Allow External Traceability не включен.	Это поле относится к свойству отслеживания связей проектов в RequisitePro.
9. Оставьте пустым поле Requirement Must Contain.	В поле указывается слово или фраза, которая должна присутствовать в каждом требовании этого типа. Оставляя пустым это поле, вы не задаете никаких специфических ограничений на формулировку требований этого типа.
10. В поле Requirement Tag Prefix введите короткий текст, для обозначения требования с таким типом, например, UC для функций системы.	Значение этого поля помещается в дальнейшем в поле Tag (метка), которое предшествует полю с описанием требования этого типа.
11. Примите по умолчанию значения для обоих полей Requirement Color, Requirement Style или задайте их по своему усмотрению.
12. Нажмите кнопку «OK».	На экране появляется окно Requirement Type. Созданный тип требования отображается в поле типов требований.
13. Нажмите Add ... в диалоговом окне Requirement Types и добавьте новый тип требования и его параметры. Например: Name: Приемка системы Description: Описывает правила приемки системы Requirement Tag Prefix: ACT.	Задается имя новому типу требования и прочие характеристики типов требований.
14. Нажмите кнопку «OK».	Новый тип требований будет добавлен к списку типов требований.
15. Используя вышеуказанную процедуру, добавьте еще типы требований в соответствие с приложением 1. Придумайте дополнительные требования для ТЗ. И также добавьте их в проект.	Вводится соответствующая информация для каждого из перечисленных типов требований.
	На этом завершается определение новых типов требований.

<

Упражнение 3.2.– Изучение атрибутов требований

Задачи:

В упражнении 3.2 требуется выполнить следующее:

1. Создать новый атрибут требования.

2. Добавить атрибут к выбранному типу требования.

ШАГИ	КОММЕНТАРИИ
	В этом упражнении Вы научитесь добавлять новые атрибуты и их значения к типам требований. Атрибуты требований используются в RequisitePro для управления требованиями.
1. Используя панель инструментов RequisilePro, откройте созданный проект. Выберите проект из текущего списка проектов.
2. Используя панель инструментов, выберите в меню File пункт Properties …	На экране появляется окно c вкладками для задания различных атрибутов проекта.
3. Выберите вкладку Attributes.	На экране появляется окно для задания атрибутов требований.
4. Выберите первый тип требования, с которым Вы хотите работать из списка типов требований, например UC: Функция системы.	Нажмите стрелку "вниз" в выпадающем списке требований.
5. Нажмите кнопку «Add ...», для добавления атрибута.	На экране появляется окно Add Attribute для добавления нового атрибута к выбранному типу требований.
6. Введите имя нового атрибута в поле Label, например, Заинтересованное лицо.	Определите краткое и значимое имя. Имена должны быть уникальны только внутри данного типа требования. Таким образом, можно использовать одно и то же имя атрибута в нескольких различных типах требований в одном проекте.
7. Определите тип (Type) нового атрибута из выпадающего списка типов атрибутов. Выберите тип атрибута List (Multiple Value). Введите в поле List Value значения атрибута: Пользователь, Менеджер, Начальник. Ввод каждого значения должен подтверждаться нажатием клавиши «ENTER».	Выбранному типу данных соответствуют различные типы полей ввода или значений по умолчанию.
Совет: Рекомендуется использовать для атрибута требования тип данных список для текстовых типов данных. При использовании списка более удобно управлять типами значений в атрибуте. Например, при использовании списка имен можно контролировать введенные имена.
8. Включите флаг Change affects suspect.	Назначение этого флага будет изучено в последующих лабораторных работах.
9. Нажмите кнопку «OK», для добавления нового атрибута к выбранному типу требования.
	Теперь можно добавлять новые значения к созданному атрибуту.
10. Нажмите на новый атрибут, чтобы отобразить его текущие значения.
11. Нажмите кнопку «Add…», для добавления новых значений атрибутов.	Открывается окно Add Attribute.
12. Введите новое значение атрибута в поле Label по своему усмотрению или в соответствие с приложением 4.	Всегда выбирайте краткие и ясные значения.
13. Определите, требуется ли использовать это значение как значение по умолчанию. Если это так, нажмите на кнопку Default.	Значение по умолчанию устанавливается автоматически всякий раз, когда создается новое требование.
14. Нажмите кнопку «OK». Значение атрибута будет добавлено к базе данных проектов.	Те же самые значения атрибутов могут использоваться в других атрибутах.
15. Добавьте еще несколько атрибутов и их значений.
Рекомендуется для каждого типа требования иметь порядка 6 –10 атрибутов.
	Атрибуты и значения атрибутов также могут быть удалены. Будьте осторожны при их удалении, т.к. при удалении можно уничтожить информацию проекта.
16. Удалите атрибут типа требования. Для удаления значений атрибута выберите значение атрибута, нажмите кнопку «Delete».	Выбранное значение атрибута будет удалено.
17. Нажмите кнопку «OK» в диалоговом окне Project Properties.	На этом завершаются все упражнения лабораторной работы № 3.

<

Лабораторная работа № 4

Импорт требований в RequisitePro

и создание иерархических требований в базе данных

Введение

Упражнения в Лабораторной работы № 4 связаны с созданием иерархических требований и с их импортом в RequisitePro. Рассматривается создание требований в RequisitePro и импорт требований, из других программных продуктов.

Цели

Целями лабораторной работы являются:

1. Создание требований.

2. Импорт требований в

RequisitePro.

3. Создание иерархической структуры требований.

Упражнение 4.1. – Создание новых требований в базе данных

Задачи:

В упражнении 4.1 требуется выполнить следующее:

1. Создать новое требование в базе данных (БД) проекта.

2. Определить расположение существующего требования.

ШАГИ	КОММЕНТАРИИ
	Требования в RequisitePro могут быть созданы непосредственно в базе данных, импортироваться в RequisitePro из другого источника или созданы в документах RequisitePro. В этом упражнении Вы освоите различные методы создания требований.
1. Нажмите на иконку Create a project, package, document, view or requirement в окне Rational RequisitePro.	Или выберите из меню пункты FileàNewàView.
2. В окне View Properties задайте название области просмотра, краткое описание области, папку, в которой следует хранить область просмотра.
4. Выберите из выпадающего списка типов просмотра (View Type) тип просмотра «Attribute Matrix».	Другие типы представлений требований будут изучаться в последующих упражнениях.
5. Выберите тип требования и нажмите кнопку «OK».	На экране справа появляется окно представления требований. Требования пока не определены.
6. Щелкните по полю <Click here to create a requirement>.	Появляется поле ввода наименования требования.
7. Введите в поле ввода наименование требования. Можно вводить функциональные требования к системе, представленные в приложении 2.	Требование вводится в базу данных проектов RequisitePro. В строку таблицы, связанную с наименование требования, можно вводить значения атрибутов требований.
8. Щелкните по столбцу таблицы Requirements.	При создании требования непосредственно в базе данных, изменения фиксируются сразу после щелчка по столбцу таблицы Requirements.
9. Убедитесь, что созданное требование отражается в таблице просмотра требований.	В последующих упражнениях будут изучены методы сортировки и фильтрации требований. Новые требования отражаются в таблице просмотра требований независимо от выбранных параметров фильтрации и сортировки.
10. Прокрутите таблицу отображения требований «вправо» и найдите атрибут требования Location.	Этот атрибут показывает, где было создано требование. Все требования сохраняются в базе данных независимо от того, где они были созданы. Требования, созданные в базе данных, должны в ней же и управляться. К требованиям, созданным в документе, обращаются в соответствующем документе.
11. Добавьте еще несколько требований в базу данных по вашему усмотрению.	При вводе, например, функциональных требований к системе непосредственно в базу данных, мы регистрируем их прежде, чем они будут задокументированы.
12. Выберите созданное требование в таблице просмотра требований.	Помните, что можно манипулировать требованиями, только созданными в базе данных.
13. Отредактируйте название требования и/или атрибуты в таблице просмотра требований.
14. По желанию поэкспериментируйте с требованиями, созданными в базе данных.	Подсказка: Вы всегда можете определить требования, хранимые в базе данных, используя атрибут Location.
15. В окне просмотра элементов проекта выберите требование, которое хотите удалить. В меню Edit выберите пункт Delete.
16. В окне Delete Requirements появляется предупреждающее сообщение Are you sure you want to delete the selected requirement?, нажмите кнопку «Yes».
Совет: Удаление требований повлечет за собой потерю всей хронологии изменения требований. Вместо того чтобы удалять ненужные требования, введите у требования атрибут «Deleted» и сделайте его скрытым для существующих требований и видимым для удаленных требований.

<

Упражнение 4.2. – Импорт требований в БД проекта из документа Word

Задачи:

В упражнении 4.2 требуется выполнить следующее:

1. Импортировать требования в БД из документа Word.

ШАГИ	КОММЕНТАРИИ
Проверьте, что в проекте существует тип требование с наименованием Тип: Бизнес правило и меткой BRUL.	Требования могут быть автоматически созданы в RequisitePro при их импорте извне.
1. Выберите в меню пункты File àImport…
2. Для импорта документа Word включите переключатель Microsoft Word Document и выберите файл \Business_Rules. Выделите этот файл, затем нажмите кнопки Open à Next.	На этом шаге определяется файл, который следует импортировать в RequisitePro.
3. Включите переключатель Requirements only и нажмите кнопку «Next».
4. Включите переключатель Current project database и нажмите кнопку «Next».	Можно использовать импорт требований в документ.
5. Задайте тип требования Тип: Бизнес правило, включите переключатель Word styles. Включите переключатель Show styles All. Выберите заголовок 3. Нажмите кнопку «Add…», затем кнопку «Next».	Вы готовы импортировать некоторые требования в проект RequisitePro.
6. Нажмите кнопку «Yes to All».
7. Нажмите кнопку «Next» и кнопку «Commit», если отображаемая информация правильная.	Import Wizard автоматически зафиксирует требования как окончательные требования.

Упражнение 4.3. – Иерархические требование БД проекта

Задачи:

В упражнении 4.3 требуется выполнить следующее:

1. Создать иерархические требования в БД.

2. Манипулировать иерархическими требованиями в БД.

ШАГИ	КОММЕНТАРИИ
	В этом упражнении будет рассмотрен создание и идентификация иерархических требований.
1. Откройте какую-нибудь область просмотра требований Attribute Matrix или создайте новую область просмотра.	Откроется матрица атрибутов требований.
2. Выберите пункт меню Requirement à New.	Появляется обычное окно ввода наименования требований.
3. В поле наименования требования введите текст Требование Родитель 1.	Вы вводите корневое требование в базу данных проектов. Далее можно вводить атрибуты этого требования.
4. Щелкните по колонке Requirement.	При создании требований непосредственно в базе данных, после щелчка по колонке Requirement, немедленно фиксируются изменения.
5. Выберите пункты меню Requirementà New Child.	Появляется окно ввода наименования требования потомка.
6. В поле наименования требования введите Требование потомок 1.	Вводится в БД проекта требование потомок. Далее можно вводить атрибуты этого требования.
7. Щелкните по колонке Requirement. Затем нажмите на клавишу «Enter».	Обратите внимание на то, что оба требования созданные, в БД отображают их иерархию. Поддерживается иерархия и в нумерации требований.
8. В поле наименования требования введите Требование Родитель 2.	Вы вводите корневое требование в базу данных проектов. Далее можно вводить атрибуты этого требования.
9. Выделите Требование потомок 1. Выберите в меню пункты Requirement àChange Parent.	На экране отображается окно Select New Parent со списком требований.
10. В окне со списком требований выберите новое требование родитель Требование Родитель 2.	На экране появляется окно со списком родительских требований.
11. Нажмите кнопку «OK», чтобы подтвердить выбор Требование родитель 2.	Заметим, что метка родительского требования, отражается и на требовании потомка.
12. Создайте иерархические требования на основе функций 3, 4, 5 в приложении 2.
Поэкспериментируйте с вновь созданными иерархическими требованиями.	На этом завершаются все упражнения Лабораторной работы №4.

<

Лабораторная работа № 5

Создание документов в RequisitePro

Введение

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

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

Цели

Целями лабораторной работы являются:

1. Определение типов документов, связывание типов документов с шаблонами документов.

2. Создание документов в RequisitePro, импортирование информации из внешнего источника в документ RequisitePro, сохранение копии этого документа как документа Word.

Упражнение 5.1 - Создание типов документов в RequisitePro

Задачи:

В упражнении 5.1 требуется выполнить следующее:

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

2. Сопоставить тип документа с шаблоном.

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

4. Ознакомиться со свойствами контроля и фиксации изменений в проекте.

ШАГИ	КОММЕНТАРИИ
	Перед созданием документов в RequisitePro, сначала следует создать тип документа и сопоставить его с существующим шаблоном. Если проект создавался на основе существующего проекта, он уже содержит много различных типов документов.
1. Создайте проект в RequisitePro с названием Техническое задание.
2. На панели инструментов выберите пункты меню File à Project Administration àProperties.	Открывается окно Project Properties c вкладками для внесения изменений в различные части проекта.
3. Выберите вкладку Document Types.
4. Нажмите кнопку «Add».	На экране появляется окно Document Type.
5. В поле Name введите: Техническое задание.	Задается наименование новому типу документа.
6. В поле Description введите описание нового типа документа, например: Данный тип документа используется для описания требований к системе.	Введите любое полезное описание.
7. В поле File Extension введите: DОS – совместимое расширение файла на английском языке, например, TT.	Не следует вводить расширение, которое уже используется в проекте.
8. В поле Default Requirement Type нажмите на «стрелку вниз», чтобы отобразить список доступных типов требований и выберете тип требования: Функция системы.	Определяется тип требования как значение по умолчанию, присоединенное к этому типу документа.
9. В поле Outline Name, нажмите на «стрелку вниз», чтобы отобразить список доступных шаблонов документов и выберете шаблон Техническое задание.	Происходит присоединение стандартного шаблона к новому определенному типу документа. Это означает, что все документы этого типа будут иметь структуру и стиль этого шаблона.
10. Нажмите кнопку «OK», чтобы закончить описание нового типа документа.	На вкладке Document Types появляется созданный тип документа и соответствующее этому типу расширение.
	Добавьте другой тип документа.
11. Снова нажмите кнопку «Add ...» в окне Document Types и как указано выше добавьте новый тип документа, например: Name: Бизнес правила. Description: Данный тип документа используется для описания бизнес правил. File Extension: BRL. Default Requirement Type: Бизнес правило. Outline Name: Бизнес правила.
12. Нажмите кнопку «OK».	Новый тип документа будет добавлен к списку доступных типов документа. На этом завершается определение новых типов документов и заданных по умолчанию типов требований.
	RequisitePro предлагает множество свойств контроля фиксации и изменений записей в проекте, как в конкретном документе, так и в каждом отдельном требовании проекта.
13. Находясь в диалоговом окне Project Properties, выберите вкладку Revision.	Обратите внимание на поле Change Description: в нем отражается история изменений внесенных в проект. Нажмите кнопку «History» для просмотра предыдущих изменений в проекте.
14. Нажмите кнопку «OK» в диалоговом окне Project Properties.	Диалоговое окно Project Properties будет закрыто.

<

Упражнение 5.2 – Создание документов в RequisitePro

Задачи:

В упражнении 5.2 требуется выполнить следующее:

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

2. Ознакомиться со свойствами контроля и фиксации изменений в документе.

ШАГИ	КОММЕНТАРИИ
	В предыдущем упражнении были созданы два типа документов (им соответствуют заданные по умолчанию типы требований). В этом упражнении, следует создать фактические документы, привязанные к типам документов. Документы можно создавать в отдельных папках.
1. Щелкните правой клавишей по изображению проекта в виде «пирамидки». В появившемся меню выберите пункт меню New, а затем Package (папка). Поименуйте Package как «Техническое задание». Нажмите кнопку «OK».	На экране появляется окно Package Properties.
2. Щелкните правой клавишей по пакету с наименованием «Техническое задание». В появившемся меню выберите пункт меню New, а затем Document…
3. В поле Name окна Document Properties введите название фактического документа в соответствие с приложением 2, например: АС ФОРМИРОВАНИЯ ДОКУМЕНТОВ ПО СДЕЛКАМ ПОКУПКИ/ПРОДАЖИ ДРАГОЦЕННОГО МЕТАЛЛА (техническое задание).	Вы создаете и называете новый документ.
4. В поле Description введите описание нового документа, например: В документе представлены требования к системе.	Введите любое полезное описание.
5. В поле File Name введите имя файла, в котором будет храниться документ.	Имя файла должно быть уникально. Если введённое вами имя файла существует, появится диалоговое окно, сообщающее Вам об этом. RequisitePro автоматически создаёт имя документа, добавляя расширение, определенное для этого типа документа.
6. Убедитесь, что флаг Show Tags включен.	Включение этого флага приводит к отображению метки требования в документе.
7. Задайте директорию для хранения документа в поле Directory.	Нажмите кнопку «Browse» для задания директории.
8. В поле Document Type нажмите «Стрелку вниз», и выберите тип документа Техническое задание.	Все документы, созданные в проекте должны иметь определенный тип документа.
9. Нажмите кнопку «OK».	Новый документ создан! Новый документ содержит шаблон Технического задания.
10. Просмотрите документ вWord.
11. Снова используя панель инструментов RequisitePro, создайте новый документ – Бизнес правила предметной области. По желанию можно поместить этот документ в отдельную папку.	Теперь добавим другой документ.
12. В окне Document Properties напечатайте следующие значения для полей: Name: Бизнес правила предметной области. Description: Описываются бизнес правила предметной области. Filename: введите имя файла, в котором будет храниться документ. Directory: согласитесь с предложенным расположением или задайте директорию по своему усмотрению. Document Type: Тип:Бизнес правила.
13. Нажмите кнопку «OK».	Вы создали два документа. Оба документа открыты в Word.
	RequisitePro предлагает множество средств контроля, фиксации и записи изменений документов в проекте.
14. На панели инструментов RequisitePro в Word выберите пункты DocumentàProperties… Далее выберите вкладку Revision.	Обратите внимание на поле Change Description: поле представляет список, изменений в документе. Нажмите кнопку «History» для просмотра предыдущих изменений в документе.
15. Нажмите кнопку «OK», когда закончите просмотр.

<

Упражнение 5.3 - Импорт и экспорт документов из внешних источников

Задачи:

В упражнении 5.3 требуется выполнить следующее:

1. Научиться переключаться между активными документами, используя панель инструментов RequisitePro.

2. Импортировать документ в проект RequisitePro. Извлечь Word копию документа RequisitePro

и сделать её доступной вне RequisitePro.

ШАГИ	КОММЕНТАРИИ
	RequisitePro представляет возможность использовать документы, созданные в других программах. В этом упражнении Вы вставите в RequisitePro документы из внешних источников.
1. Проверьте, что документ ТЗ активен. Поместите курсор в место, в которое следует вставить новый документ.	Убедитесь, что документ открыт в Word.
2. Если документ ТЗ – не активен, выберите на панели инструментов RequisitePro в Word пункты Windowà ТЗ.	Вы сделаете документ активным.
3. На панели инструментов RequisitePro в Word выберите пункты DocumentàSave As… и введите имя файла.	Использование пункта меню Save As… в RequisitePro позволяет сохранить документ в формате Word.
4. Создайте копию документа из приложения 2 в виде отдельного файла Word.
5. В меню Word выберите пункты Insert à File. Выберите файл c копией документа из приложения 2, и нажмите кнопку «Insert».	Появится окно, в котором следует выбрать файл для вставки.
6. При внесении изменений в документе, появляется диалоговое окно для подтверждения изменений. Для подтверждения изменений нажмите «Yes».
7. Нажмите кнопку «Save». Появится диалоговое окно с сообщением о сохранении документа. Нажмите кнопку «OK».	Копия документа RequisitePro сохраняется в формате Word с расширением doc.
Совет: В RequisitePro обычно установлен в режим, в котором все документы создаются в RequisitePro. Свойство DocumentàSave As следует использовать в RequisitePro для создания документов Word для сторонних пользователей.
8. Закройте документ, выбрав на панели инструментов RequisitePro в Word пункты Document à Close.	Появляется окно с замечаниями об обнаруженных изменениях. Нажмите «Yes».

<

Упражнение 5.4 - Создание новых требований в документах

Задачи:

В упражнении 5.4 требуется выполнить следующее:

1. Создать новые требования в документах.

ШАГИ	КОММЕНТАРИИ
	Требования в RequisitePro могут создаваться в документе, импортироваться из внешнего источника или добавляться непосредственно в базу данных.
1. Выберите в меню RequisitePro в Word пункты DocumentàOpen ... В окне Open Document выберите документ ТЗ и нажмите кнопку «OK».	Выбранный документ откроется в окне Word.
2. Отредактируйте ТЗ в Word в соответствие с приложением 2. Перейдите к разделу документа с описание конкретных функций системы.
3. Установите курсор в месте, где будет находиться первая функция. Выберите в меню RequisitePro, встроенного в Word, пункты меню RequirementàNew.	Появляется окно с вкладками описания требования.
Предупреждение: RequisitePro позволяет использовать нетекстовые объекты в требованиях (таблицы Excel или диаграммы), однако RequisitePro не может прослеживать изменения для нетекстовых объектов и не может сохранять их в базе данных проектов.
Предупреждение: RequisitePro может ошибаться при определении требований, созданных в Word, содержащих различные конструкции поля, скрытый текст и т.д. Полужирный и курсивный текст воспринимается правильно.
Предупреждение: Не пытайтесь создавать требования внутри текстового поля Word, так как RequisitePro не сможет обратиться к ним правильно при последующем использовании требования.
4. На экране появляется окно Requirements Properties для создания требования. Просмотрите поля и информацию на всех вкладках. Введите название первой функции и ее описание в соответствие с приложением 2, например: Наименование: Регистрация сделок покупки драгоценного металла. Описание: Функция используется для регистрации сделок покупки драгоценного металла в системе. Нажмите кнопку «OK».
5. Аналогичным образом создайте новую функцию системы в соответствие с приложением 2 (Вторая функция в описании).
	Имеется другой способ создания требования в документе.
6. Выделите текст, который Вы хотите сделать требованием. Далее выберите в меню пункты RequirementàNew на панели инструментов RequisitePro, встроенного в Word. Создайте требование.	Не выделяйте уже созданное требование. Выбирайте текст, еще не являющийся требованием.
7. Выберите в меню RequisitePro, встроенного в Word, пункты DocumentàSave. Все изменения требований зафиксируются в базе данных.	Обратите внимание, что все ждущие обработки требования теперь зафиксированы как официальные требования.
8. Закройте документ. В меню RequisitePro, встроенного в Word, выберите пункты меню DocumentàClose.	Закрытие документа увеличивает рабочее пространство и максимизирует системные ресурсы.
9. Сохраните документ, используя меню RequisitePro, встроенного в Word.	Изменение требований зафиксируется в базе данных.

<

Упражнение 5.5 – Импорт документов и требований

Задачи:

В Упражнении 5.5 требуется выполнить следующее:

1. Импортировать требования и документ, используя ряд методов, позволяющих вставлять их в проект RequisitePro из внешних источников.

ШАГИ	КОММЕНТАРИИ
	Требования могут автоматически создаваться путём импорта данных из внешних источников или документов, относящихся к разным проектам RequisitePro.
1. Выберите в меню пункты File àImport…	Появляется окно Import Wizard.
2. При импорте документа Word, в окне Import Wizard включите переключатель Microsoft Word Document. В поле Name of the document to import выберите файл Business_Rules c документом и далее нажмите OpenàNext.
3. Включите переключатель Requirement and document и снова нажмите на кнопку «Next».
4. В появившемся окне задайте наименование документа в проекте, описание документа, файл, в котором документ будет храниться, тип документа и нажмите кнопку «Next».
5. В появившемся окне Import Wizard нажмите кнопку «Now», затем в следующем окне – кнопку «Yes».
6. Далее в следующем окне Import Wizard задайте тип требования Тип: Бизнес правило, включите переключатель Word styles. Включите переключатель Show styles All. Выберите заголовок 3. Нажмите кнопку «Add…», затем «Next».
7. RequisitePro импортирует документ и создаёт требования по установленным критериям. Каждое найденное требование будет отображаться в окне Requirement Found. Если отображаемая информация верна, нажмите кнопку «Yes» или «Yes to All».	Нажатие кнопку «Yes to All» подтверждает выбор всех требований.
8. Последнее окно Import Wizard отображает все предложения, являющиеся требованиями. Если отображаемая информация правильна, нажмите кнопку «Commit», и требования будут включены в базу данных.	В отличие от ручного создания требований в предыдущем упражнении, Import Wizard автоматически фиксирует все обнаруженные требования как конечные, а не как ждущие обработки.
9. Просмотрите документ и его требования.	При просмотре вы можете увидеть неправильно выбранные требования. Это может быть связанно с отсутствием ключевых слов, их неправильным местоположением или с другими проблемами автоматического создания требований.
10. После просмотра закройте документ.

<

Упражнение 5.6 - Общее управление требованиями

Задачи:

В упражнении 5.6 требуется выполнить следующее:

1. Рассмотреть управление требованиями, содержащимися в документе.

2. Удалить и снять выделение существующих требований.

ШАГИ	КОММЕНТАРИИ
	В этом упражнение Вы научитесь управлять требованиями в проекте.
1. Щелкните правой клавишей мыши по изображению проекта или какой-либо папки и в появившемся меню выберите пункт New, а затем View….	Открывается окно View Properties.
2. Задайте какое-либо название области просмотра, описание области просмотра и тип области просмотра - «Attribute Matrix».
3. Выберите тип требования Тип: Функция системы и нажмите «OK».	На экране отображается матрица просмотра функциональных требований.
4. Дважды щелкните по требованию в окне просмотра. При этом происходит переход к документу, в котором содержится требование. Требование в документе помечается цветом.	Подсказка: Расположение требования отображается в атрибуте Location Attribute.
Предупреждение: обратите внимание, что существует много вариантов доступа к функциям Cut/Copy/Paste, но какие из них Вы используете? Этот вопрос особенно важен для последующих шагов этого упражнения. Панель инструментов RequisitePro в Word предназначена для обработки требований внутри Word. Так, если Вы находитесь в Word, используйте панель инструментов RequisitePro для операций Cut/Copy/Paste с требованиями и панель инструментов Word для обработки текста.
	Предположим, что Вы хотите переместить требование, созданное в документе, в базу данных. В действительности вы хотите удалить требование из документа, при этом сохранив его.
5. Поместите курсор на требование, находящееся в документе Word. Выберите Requirement на панели инструментов RequisitePro, а затем - Cut.	Перейдите в Word, если Вы ещё не там.
6. Перейдите в окно просмотра матрицы атрибутов требований.
7. Выберите пункт меню Edit, а затем Past.	Требование будет вставлено в БД.
	Теперь проведем обратную операцию, перемещая требования из базы данных в документ.
8. Создайте в матрице с атрибутами требований новое требование, например функцию системы: формирование открытой валютной позиции.
9. Из матрицы атрибутов вырежьте это требование.	Вырезанное требование в матрице атрибутов отображается с пометкой (cat).
11. Установите курсор в документе окна Word там, где Вы хотите вставить требование.
12. Выберите пункт Requirement в Word, а затем Paste.	После этого действия требование будет находиться и в документе, и в базе данных.
13. Выберите на панели инструментов в Word RequisitePro пункт Requirement àGo To...	Перемещаться между требованиями, можно используя это способ.
	При выполнении следующих действий Вы научитесь удалять и снимать выделение требований в проекте.
14. В окне Word поместите курсор внутри требования, созданного в документе.	Используйте пункт меню Window на панели инструментов RequisitePro, чтобы в случае необходимости перейти к окну Word.
15. На панели инструментов RequisitePro выберите пункты меню Requirement àDelete - Unmark. При появлении запроса о подтверждении действия, нажмите Yes.	Это действие снимает выделение требования. Требование сохраняется в документе Word как текст.
16. Установите курсор в тексте любого требования.
17. На панели инструментов RequisitePro в Word выберите пункты RequirementàDelete - Remove. При появлении запроса о подтверждении действия, нажмите Yes.	В отличие от функции Delete - Unmark, функция Delete - Remove удаляет и требование, и текст. Обратите внимание на различие между ними.
18. В окне просмотра матрицы атрибутов требований выделите требование, созданное в базе данных. Выделить требование можно щелчком левой кнопки мыши по требованию.	Найти требование, созданное в базе данных, можно просматривая атрибут требований Location Attribute.
19. Выберите пункты меню Edit àDelete в области просмотра. При появлении запроса о подтверждении действия, нажмите Yes.	Обратите внимание, что действия в области просмотра не требуют от Вас сохранения документа для подтверждения изменений.
Предупреждение: При удалении требований (через Delete -Unmark, Delete - Remove или Requirement Delete теряется вся хронология изменений и параметры настройки атрибутов требований. Вместо того, чтобы удалять ненужные требования, рассмотрите возможность сохранения их в базе данных с, например, атрибутом «удаленный».

<

Упражнение 5.7 - Иерархические Требования

Задачи:

В упражнении 5.7 требуется выполнить следующее:

1. Создать иерархические требования в проекте.

ШАГИ	КОММЕНТАРИИ
	В этом упражнении изложены понятия идентификации и обозначения иерархических требований.
1. Откройте документ, в котором следует разместить иерархические требования. Выберите в RequisitePro, встроенном в Word пункты меню DocumentàOpen. Далее выберите документ ТЗ и нажмите кнопку «OK».
2. Создайте первое требование какого либо типа, например требование Вид обеспечения, например система должна функционировать на технических средствах включающих в себя.	Используйте это требование как требование - родитель.
3. Создайте второе требование, например, система должна функционировать в архитектуре клиент-сервер с использованием СУБД Oracle.	Используйте это требование как требование - родитель.
4. Создайте третье требование, например, сетевой лазерный принтер производства фирмы HewlettPaccard с картриджем русских шрифтов.	Используйте это требование как требование - потомок.
5. Выберите в меню RequisitePro DocumentàSave. Требования зафиксируются в базе данных.
	RequisitePro позволяет быстро назначать нового родителя к существующему требованию-потомку и менять местами требование-родителя и потомка.
6. Выделите созданное требование-потомок. Выберите в RequisitePro, встроенном в Word, пункты Requirement àProperties…	Появляется окно с вкладками требования.
7. Нажмите на вкладку Hierarchy и выберите для требования потомка родителя: система должна функционировать на технических средствах включающих в себя.
8. Сохраните документ.	Требование будет зафиксировано в базе данных.
9. Нажмите на вкладку Hierarchy и выберите для требования потомка нового родителя: система должна функционировать в архитектуре клиент-сервер с использованием СУБД Oracle.
10. Выберите в меню RequisitePro DocumentàSave. Требования зафиксируются в базе данных.
11. Просмотрите другие функции работы в RequisitePro с иерархическими требованиями самостоятельно.	Иерархические требования требуют особого рассмотрения. Например: что произойдет с требованием-потомком при удалении родительского требования?
	RequisitePro предлагает широкий набор свойств фиксации и записи изменений каждого требования в проекте.
	На этом завершаются все упражнения Лабораторной работы №5.

<

Лабораторная работа № 6

Установка системы безопасности

Введение

При использовании RequisitePro

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

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

Некоторые проекты не нуждаются в средствах управления доступом.

Цели

Целями лабораторной работы являются:

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

2. Установка уровней системы безопасности в проекте, документе и требовании.

Упражнение 6.1 - Применение системы безопасности RequisitePro

Задачи:

В упражнении 6.1. требуется выполнить следующее:

1. Задать пароль администратору.

2. Изучить возможности системы безопасности.

ШАГИ	КОММЕНТАРИИ
	Создание уполномоченных пользователей проекта, определение группы пользователей с определенными полномочиями требуется только для тех проектов, в которых Вы хотите ограничить доступ пользователей. В любое время после создания системы безопасности проекта, Вы можете полностью ее отключить или добавить/изменить/ удалить пользователей и группы.
1. Откройте созданный проект ТЗ. Если он уже открыт, закройте все, открытые в нем документы.
2. Выберите в меню пункты File àProject AdministrationàSecurity ...	На экране появляется окно Project Security.
3. Установите флаг Enable security for this project.	В окне отображаются три группы управления доступом.
4. Щелкните по группе Administrators.
5. Нажмите на кнопку «Edit» в списке Users of Group. Не перепутайте с кнопкой «Edit» в окне Group.	На экране появляется окно Edit User.
6. Напечатайте слово Password в качестве пароля администратора и нажмите кнопку «OK» для его подтверждения.	Предостережение: Запомните пароль, который Вы ввели. Если Вы забудете его (и нет других администраторов), Вы лишитесь доступа к проекту, как Администратор (и, следовательно, не сможете выполнять функции администратора).
Совет: рекомендуется назначать двух администраторов проекта.
7. После ввода пароля, выберите в списке Groups: Usersà Edit. Просмотрите доступные параметры.	Диалоговое окно Group Permissions позволяет определять права всех пользователей в группе (каждый пользователь должен принадлежать только одной группе). Обратите внимание на права, которые можно изменять: можно разрешать/запрещать пользователям группы управлять структурой проекта (например, добавлять/редактировать/удалять типы требований). Можно разрешать/запрещать пользователям группы управлять системой безопасности проекта (например, добавлять/удалять пользователей, изменять права пользователя группы и включать/отключать систему безопасности проекта). Для каждого типа документа, можно назначить пользователям группы различные виды доступа: запретить доступ к документам, доступ только для чтения, доступ чтение – редактирование, разрешить создавать документы определенного типа и удалять их. Для каждого типа требования можно разрешить пользователям группы читать (но не редактировать) требования этого типа, редактировать, создавать требования этого типа, удалять их.
8. Нажмите Cancel, чтобы закрыть окно Group permission.

<

Упражнение 6.2 - Управление системой безопасности RequisitePro

Задачи:

В упражнении 6.2. требуется выполнить следующее:

1. Добавить новых пользователей проекта.

2. Познакомиться с различными правами доступа.

ШАГИ	КОММЕНТАРИИ
	Добавим несколько пользователей и групп.
1. Выберите кнопку «Add» в списке Groups. Добавьте новую группу с именем Аналитики. Предоставьте им полный доступ к документу ТЗ.	Вы увидите, что группа имеет права "r/u/c/d" для документов этого типа.
2. Выберите кнопку «Add» в списке Groups. Добавьте новую группу с именем Заинтересованные лица. Предоставьте им доступ на просмотр документа ТЗ.
3. Нажмите «OK» для подтверждения прав и перейдите к окну Group Permissions.	Вы увидите новую группу пользователей в списке Groups.
4. Добавьте пользователей к группе Аналитики, Заинтересованные лица, выбрав кнопку «Add...» рядом со списком Users of Group. Введите имя пользователя (например: User1) и пароль (например: User1). Добавьте несколько новых пользователей.	Добавлять новых пользователей очень просто.
5. Добавьте другие группы пользователей, и пользователей групп по своему усмотрению. Нажмите кнопку «OK» в окне Project Security.
6. Закройте и вновь откройте проект.	Проверьте установленную систему безопасности. Теперь при открытии проекта, Вы должны будете вводить имя пользователя и пароль.
	На этом завершаются все упражнения лабораторной работы № 6.

Лабораторная работа № 7

Отслеживание зависимых требований

Введение

Упражнения лабораторной работы №7 позволят вам познакомиться с требованиями, зависимыми в проекте, используя возможности RequisitePro

по их отслеживанию.

В RequisitePro

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

Указанные изменения отображается в просмотрах (Traceability Views).

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

Цели

Целями лабораторной работы являются:

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

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

Упражнение 7.1 – Установление связей между требованиями

Задачи:

В упражнении 7.1. требуется выполнить следующее:

1. Установить в проекте связи между требованиями.

ШАГИ	КОММЕНТАРИИ
	В этом упражнении Вы установите связи между двумя типами требований.
1. Откройте проект Quarter Byte savings Bank Example project.
2. Создайте в проекте область просмотра Traceability Matrix с названием Просмотр зависимостей.	Можно выбрать в меню пункты FileàNew View...
3. Выделите в типах требований строку: PR:Pruduct Requirement Type и столбец SR:Software Requirement Type и нажмите кнопку «OK».	Появляется окно просмотра связей.
6. Выберите пустую ячейку, щелкните правой кнопкой мыши по ячейке и выберите в появившемся меню пункт Trace To.	Вы установили связи между требованиями.
7. Установите связи между другими требованиями.	Внизу окна просмотра связей отображаются наименования связываемых требований.
Предупреждение: RequisitePro позволяет Вам устанавливать связи, двух видов "Trace-from" или "Trace-to". Хорошим стилем является использование в просмотре только одного типа связей.
8. Не закрывайте область просмотра.

Упражнение 7.2 – Изучение подозрительных связей

Задачи:

В упражнении 7.2. требуется выполнить следующее:

1. Изучить подозрительные связи между требованиями.

ШАГИ	КОММЕНТАРИИ
	В этом упражнении Вы изучите подозрительные связи, появившиеся после изменений, сделанных в проекте.
1. Дважды щелкните по требованию.	Вы перейдете в документ Word, содержащий это требование.
2. Измените текст в нескольких требованиях в документе Word по вашему усмотрению. Cохраните документ. В окне Change Requirement напечатайте несколько примечаний и нажмите кнопку «OK».	Не забывайте использовать функцию DocumentàSave или пиктограмму Save на панели инструментов RequisitePro в Word. В появившемся окне Change Description введите соответствующую информацию и нажмите кнопку «OK».
3. Вернитесь в область просмотра строка: PR:Pruduct Requirement Type и столбец SR:Software Requirement Type.	Вы увидите, что связи для отредактированных требований отмечены как подозрительные.
4. Просмотрите связи между требованиями.
5. Щелкните правой клавишей по ячейке с подозрительной связью и изучите пункты в открывшемся меню.
6. Удалите подозрительные связи. Щелкните правой кнопкой мыши по подозрительной связи и выберите в меню Clear Suspect.	Это действие должно быть выполнено только после того, как каждое из требований, соединенных такой связью, было рассмотрено.
7. Закройте все окна.

Упражнение 7.3 – Изучение множественных связей

Задачи:

В упражнении 7.3. требуется выполнить следующее:

1. Задать множественные связи за один шаг.

2. Удалить множественные связи.

ШАГИ	КОММЕНТАРИИ
	В этом упражнении Вы установите связи между одним требованием одного типа и несколькими требованиями другого типа (множественные связи).
1. Вернитесь в область просмотра строка: PR:Pruduct Requirement Type и столбец SR:Software Requirement Type.
2. Выберите несколько пустых ячеек на правой панели, удерживая нажатой клавишу CTRL или SHIFT и щелкая по пустым ячейкам мышью.	С использованием клавиши CTRL можно выбирать любые ячейки, с использованием клавиши SHIFT -смежные ячейки. Поупражняйтесь с обеими клавишами.
3. После выбора нескольких ячеек, поместите указатель мыши в одну из них. Щелкните правой клавишей мыши по ячейке. В появившемся меню выберите связь Trace To.	Вы установили связи между требованиями за один шаг.
	Этот способ может быть также использован для установления и отмены "подозрительных" связей.
4. Выберите еще несколько пустых ячеек на правой панели, удерживая нажатой клавишу CTRL или SHIFT и щелкая по пустым ячейкам мышью.
5. После выбора нескольких ячеек, поместите указатель мыши в одну из них. Щелкните правой клавишей мыши по ячейке. В появившемся меню выберите пункт Mark Suspect.	Выбранные связи отобразились как подозрительные.
6. Выберите еще несколько пустых ячеек на правой панели, удерживая нажатой клавишу CTRL или SHIFT и щелкая по пустым ячейкам мышью.
7. После выбора нескольких ячеек, поместите указатель мыши в одну из них. Щелкните правой клавишей мыши по ячейке. В появившемся меню выберите пункт Clear Suspect.	С выбранных связей снялась пометка «подозрительные связи».
11. Оставьте область просмотра открытой.

<

Упражнение 7.4. - Изучение областей просмотра связей

Задачи:

В упражнении 7.4. требуется выполнить следующее:

1. Изучить области просмотра связей, при использовании команд Filter и Sort.

ШАГИ	КОММЕНТАРИИ
	В этом упражнении для управления связями Вы используете запросы к базе данных в окне просмотра.
1. В области просмотра строка: PR:Pruduct Requirement Type столбец: SR:Software Requirement Type нажмите на иконку Query row requirements. Выберите в окне Query Criteria тип требования и какое-либо значение атрибута, нажмите «OK». Далее задайте параметры сортировки и нажмите «OK».
2. В области просмотра строка: PR:Pruduct Requirement Type столбец: SR:Software Requirement Type нажмите на иконку Query column requirements. Выберите в окне Query Criteria тип требования и какое-либо значение атрибута, нажмите «OK». Далее задайте параметры сортировки и нажмите «OK».
3. Снова выберите иконку Query row requirements, выделите запрос и, щелкнув по кнопке Remove, нажмите «OK».	Это действие удаляет запрос и возвращает область просмотра к её первоначальному виду – просмотру по строкам. Обратите внимание, что первоначальный запрос можно изменить, если нажать кнопку «Modify».
4. Снова выберите иконку Query column requirements, выделите запрос и, щелкнув по кнопке Remove, нажмите «OK».	Это действие удаляет запрос и возвращает область просмотра к её первоначальному виду – просмотру по столбцам. Обратите внимание, что первоначальный запрос можно изменить, если нажать кнопку «Modify». Чтобы вернуть область просмотра к первоначальному виду должны быть удалены все запросы, как по строкам, так и по столбцам.
	Теперь изучите другие способы просмотра связей.
5. Создайте «дерево» связей Traced out of..: В меню выберите пункты FileàNew View... Выберите тип области просмотра Traceability Tree (Traced out of…). Выберите тип требования SR и нажмите кнопку «OK».	Появляется дерево связей.
6. Выберите в меню пункты ViewàExpand All.	На экране отображается дерево связей полностью.
7. Создайте «дерево» связей Traced in to..: В меню выберите пункты FileàNew View... Выберите тип области просмотра Traceability Tree (Traced in to…). Выделите тип требования SR и нажмите «OK».
Выберите в меню пункты ViewàExpand All.	На экране отображается дерево связей полностью.
8. Закройте все окна.
	На этом завершаются упражнения лабораторной работы № 7.

<

Лабораторная работа № 8

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

Введение

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

RequisitePro представляет возможность экспорта информации в другие прикладные программы, например, MSWORD, Excel, Access. Экспортированная информация может быть использована для управления данными или тестирования прикладных программ и т.п.

Цели

Целями лабораторной работы являются:

1. Управление атрибутами требований.

2. Формирование запросов к БД требований.

3. Экспорт данных в различных форматах, включая форматы CSV, MSWord и SQA.

Упражнение 8.1 – Основные методы управления требованиями

Задачи:

В упражнении 8.1. требуется выполнить следующее:

1. Освоить приемы управления требованиями в RequisitePro.

2. Просмотреть иерархические требования с использованием опций расширения и сжатия.

ШАГИ	КОММЕНТАРИИ
	В этом упражнении Вы научитесь использовать RequisitePro для выполнения стандартных задач по управлению требованиями: - управление из палитры RequisitePro; - установка значений атрибута; - расширение и сжатие области просмотра иерархических требований.
1. Если проект не открыт, нажмите на пиктограмму Open a project или выберите в меню File пункт Open Project. Далее из списка проектов выберите требуемый проект.	Откройте любой проект по своему усмотрению, например, QuarterByte savings Bank Example project или Learning_Project.
2 Выберите в меню RequisitePro пункты FileàNew àView... (не в меню Word).	На экране отображается окно View Properties с атрибутами области просмотра.
3. Задайте какое-либо наименование области и ее тип - Attribute Matrix.
4. В строке требований Row Requirement Type выберите тип требования, например SR или FEAT.
5. Нажмите кнопку «OK».	Появившееся окно отображает требования выбранного типа SR или FEAT в левом столбце и атрибуты SR или FEAT в столбцах, расположенных правее.
6. Попробуйте поменять размеры строк и столбцов.
7. Поупражняйтесь с расширением и сжатием области просмотра иерархических требований. Используя левую клавишу мыши, нажмите на «+» или «-», находящийся рядом с иерархическим требованием.
8. Дважды щелкните на требовании, созданном в документе - это действие немедленно перенесет Вас в документ, содержащий выбранное требование.	Вы можете просматривать и редактировать требование, созданное в документе.
9. Вернитесь к окну и поупражняйтесь с пунктами меню WindowàActive View на панели инструментов RequisitePro.	Обратите внимание, что кнопка Window позволяет Вам перемещаться среди всех открытых документов.
10. Установите значения атрибутов в окне просмотра, дважды щелкнув на изменяемом значении атрибута в матрице атрибутов (но не в тексте требования). Измените значения в появляющемся раскрывающемся списке. Проделайте указанные действия для нескольких атрибутов требований.	Обратите внимание, что изменение происходит только при переходе от одной ячейки к другой.
	При рассмотрении иерархических требований в матрице связей Traceability Matrix View, возникает особая ситуация. Исследуем некоторые из этих особых случаев.
	Предупреждение: внимательно читайте команды перед началом их выполнения.
12. Создайте область просмотра требований Traceability Matrix.	Можно выбрать пункты меню FileàNewàView… в окне RequisitePro.
13. Задайте типы требований в строке и в столбце, например PR и SR для проекта QuarterByte savings Bank Example project. Нажмите «OK».	Появляется окно просмотра матрицы связей.
14. Найдите корневое иерархическое требование и удостоверитесь, что строка или столбец, содержащие его, полностью расширены.	Подсказка: удостоверитесь, что видна кнопка «-», находящаяся рядом с иерархическим требованием.
15. Установите связь от иерархического требования - потомка (не корневого) к некоторому другому требованию.	Подсказка: Щелкните правой кнопкой мыши на нужной ячейке, чтобы вызвать меню для установки связи.
16. Полностью сверните иерархический каталог.	Нажмите на кнопку «-», находящуюся рядом с корневым иерархическим требованием.
17. Вы увидите «+», который появился в ячейке со связью.	Запись «+» в ячейке показывает, что в иерархии существуют связи. Вы не видите их, так как иерархия не отображается.
18. Щелкните правой кнопкой мыши на ячейке «+» и выберите в появившемся меню опцию Expand.	Опция Expand позволяет Вам легко отображать иерархию, чтобы рассмотреть скрытые в ней связи.

<

Упражнение 8.2 – Запросы управления требованиями

Задачи:

В упражнении 8.2. требуется выполнить следующее:

1. Изучить доступные параметры запроса для управления данными.

2. Удалить запросы.

ШАГИ	КОММЕНТАРИИ
1. Откройте матрицу атрибутов с требованиями какого-либо типа, например SR или PR или создайте ее заново.
2. Выберите в меню View пункт Query row requirement, далее выберите атрибут Priority, далее в появившемся окне выберите тип атрибута, например, High и дважды нажмите кнопку «OK».	В матрице атрибутов отображаются требования с атрибутами Priority со значением High. Обратите внимание, что можно задавать не одно значение атрибута.
3. Снова выберите в меню View пункт Query row requirement. Удалите старый запрос. Выберите кнопку «Remove», нажмите кнопку «OK». Эти действия удаляют запрос и возвращают окно к начальному состоянию.	Эти шаги – стандартное действие по восстановлению области просмотра.
4. Сформируйте запрос так, чтобы в матрице требований отображался только атрибут Status со значением Incorporated. Удалите этот запрос.
5. Сформируйте запрос так, чтобы отображался только атрибут Difficulty со значением Low. Удалите этот запрос.
6. Сформируйте запрос так, чтобы отображался только атрибут Stability со всеми значениями в порядке убывания. Удалите этот запрос.
7. Создайте новое окно и используйте Ваши навыки для выбора и сортировки требований с другим типом требований.	Критерии сортировки определите сами.

Упражнение 8.3 – Запрос на управление изменением

Задачи:

В упражнении 8.3. требуется выполнить следующее:

1. Определить измененные требования.

ШАГИ	КОММЕНТАРИИ
	В этом упражнение вы научитесь находить измененные требования.
1. Создайте матрицу просмотра связей в проекте QuarterByte savings Bank Example project. Задайте строку PR и столбец SR в Traceability Matrix. Выберите в меню View пункт Query row requirements и значение атрибута Traced-to. Нажмите кнопку «OK». Далее выберите тип требования SR. Дважды нажмите «OK».	Атрибут Traced-to автоматически поддерживается системой RequisitePro на основе связей, установленных ранее. На экране отображается окно с зависимыми требованиями.
2. Пометьте одну из связей как подозрительную.
3. Выберите в меню View пункт Query column requirements и значение атрибута Traced-from. Нажмите кнопку «OK». Далее выберите тип требования PR.
4. Включите кнопку «Traced», и установите флаг Suspect only. Дважды нажмите кнопку «OK»	На экране отображается матрица атрибутов требований с подозрительными связями.

<

Упражнение 8.4 – Запрос о состоянии проекта

Задачи:

В упражнении 8.4. требуется выполнить следующее:

1. Сформировать запрос к БД проекта для определения состояния информации в областях просмотра требований.

ШАГИ	КОММЕНТАРИИ
	В этом упражнении Вы узнаете, как просмотреть информацию в областях просмотра для определения состояния проекта.
1. Создайте область просмотра в виде дерева связей. Для этого: выберите в меню пункты FileàNew View... Выберите тип требования SR. Задайте тип области просмотра Traceability Tree (Traced to…).	Появляется дерево связей с корневым типом требования SR.
2. Выберите в меню View пункт Query row requirements. Убедившись, что отображается требования типа SR Requirement Type, выберите атрибут Traced-from и нажмите кнопку «OK».	Появляется окно Query Requirement, Select Attribute.
3. Снова выберите в меню View пункт Query row requirement.	Область просмотра отсортированных требований при этом должна быть выделена.
4. Нажмите кнопку «Add» в окне Query Root Requirements.	Добавьте дополнительный запрос для его выполнения одновременно с первым запросом.
5. В окне Select Attribute выберите тип требования SR.	Обратите внимание, что атрибуты отображают значения типа требования SR.
5. Выберите атрибут Status и нажмите кнопку «OK».
8. Выберите значение атрибута Validated и нажмите «OK», чтобы закрыть окно. Снова нажмите «OK», чтобы выполнить запрос. Просмотрите появившуюся в результате область просмотра.	Просмотр отображает только те требования, которые отвечают параметрам запроса.

Упражнение 8.5 – Экспорт областей просмотра

Задачи:

В упражнении 8.5. требуется выполнить следующее:

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

2. Получить навыки работы с сервисными функциями сохранения областей просмотра.

ШАГИ	КОММЕНТАРИИ
	В этом упражнении Вы научитесь извлекать информацию из области просмотра, печатать ее или экспортировать ее в файл, который можно использовать в другой прикладной программе.
1. Подготовьте область просмотра.
2. Выберите в меню пункты FileàPrint....	Примечание: не используйте в этих упражнениях кнопку «Print» на панели инструментов, если у Вас нет присоединенного принтера. Если Вы выберите кнопку «Print» на панели инструментов, RequisitePro распечатает область просмотра на заданный по умолчанию принтер.
3. Если принтер не подсоединен к компьютеру, не выполняйте шаг 2. В противном случае нажмите Cancel.
4. Выберите в меню пункты FileàExport, чтобы экспортировать выбранную область просмотра в следующие форматы: - формат CSV, - формат Word Document.	Атрибуты и расположения столбцов будут экспортированы. Документы будут сохранены в текущем каталоге проектов.
5. Закройте RequisitePro. Просмотрите все экспортированные файлы.	Обратите внимание, что экспортированные таблицы формата Word созданы с помощью программы Word, установленной на Вашем компьютере.
	RequisitePro предлагает несколько удобных утилит, чтобы сохранить область просмотра для её дальнейшего использования.
6. Перезапустите RequisitePro, откройте снова какой-либо проект. Создайте область просмотра по своему усмотрению.
7. Сохраните область просмотра, выбрав в меню пункты FiIeàSave View As...
8. Задайте области просмотра имя и сохраните её как одну из Ваших личных областей просмотра. Нажмите «OK»
9. Закройте текущее окно просмотра.
10. В окне просмотра элементов проекта снова выберите сохраненную область просмотра.	Появляется определенная Вами область просмотра. При перезагрузке области просмотра перезагружаются управляющие элементы, изображение и выбранные характеристики. Текущая база данных RequisitePro анализируется в соответствие критериями области просмотра, после чего отображаются новые результаты.
12. Закройте проект и RequisitePro.	На этом завершаются упражнения Лабораторной работы № 8.

<

Лабораторная работа № 9

Утилиты поддержки требований

Цели

Целями лабораторной работы являются:

1. Изучение утилит поддержки требований.

Упражнение 9.1 – Утилиты поддержки требований

Задачи:

В упражнении 9.1. требуется выполнить следующее:

1. Освоить приемы по изменению нумерации требований.

2. Освоить приемы восстановления поврежденных требований.

3. Освоить приемы по обновлению стилей требований.

ШАГИ	КОММЕНТАРИИ
	В этом упражнении Вы научитесь восстанавливать поврежденные требования. В дальнейшем эти функции Вам понадобятся при случайном повреждении требований в проекте.
1. Убедитесь, что Ваш проект открыт.
2. На панели инструментов RequisitePro выберите пункты меню Project Administration àRenumber Requirements.	Иногда нужно перенумеровать требования. Это легко сделать, но в зависимости от размера проекта это может потребовать некоторого времени. Обратите внимание на имеющиеся параметры изменения нумерации и поупражняйтесь с ними.
3. Откройте какой-либо документ в проекте.
4. Удалите в Word часть метки требования в выбранном Вами документе.
5. Выберите DocumentàRebuild Tags на панели инструментов RequisilePro.	Поврежденная метка требования восстанавливается.
	Иногда, при редактировании документа могут случайно изменяться стили и внешний вид требований внутри документа. Например, Вы могли случайно установить другой цвет требования, отличный от того, который Вы определили для этого типа требования. RequisitePro предлагает простую функцию установления стилей требований документа, применимую к стандартам проекта.
6. В текущем документе специально измените внешний вид некоторых требований (например: цвет, подчеркивание и т.д.).
7. Выберите пункты меню DocumentàRefresh Requirements на панели инструментов RequisitePro.	Это действие возвращает ранее определенные стили всех идентифицированных требований внутри документа (например: цвет, подчеркивание и т.д.).

<

Упражнение 9.2 – Утилиты создать/удалить блок (Block Create/Delete)

Задачи:

В упражнении 9.2. требуется выполнить следующее:

1. Используйте утилиту New Wizard для быстрой идентификации и создания требований.

2. Используйте утилиту Block Delete для быстрого удаления выбранных требований.

ШАГИ	КОММЕНТАРИИ
	Предположим, что Вы решили сначала создать документ в RequisitePro без требований. Кроме того, в Вашем документе все требования, (даже если Вы первоначально не отмечали их как таковые), имеют специфическую структуру или формат, например, выделены квадратными скобками. Вы можете использовать утилиту RequisitePro Block Create (создание требования блоком), чтобы быстро сформировать все требования.
1. Откройте какой-либо документ проекта.
2. Добавьте 5 строчек текста в документе, каждую из которых отделите от другой с помощью клавиши ENTER. Выделите строчки квадратными скобками.
3. Выделите в Word все пять строчек.
4. Выберите в меню пункты Requirementà New Wizard.	На экране появляется мастер создания требований New Requirements Wizard.
5. Включите переключатель Text delimiters. В поле Begin delimiter поместите открывающуюся квадратную скобку, в поле End delimiter поместите закрывающуюся квадратную скобку. Нажмите кнопки «Add» и «Create»
6. RequisitePro создает требования, на основе заданных критериев. Каждое найденное требование будет отображаться в окне Requirement Found. Если отображаемая информация правильна, нажмите кнопку «Yes».	Можно обойти подтверждение каждого требования, нажав кнопку «Yes to All».
7. Последнее окно New Requirements Wizard отображает все требования. Если отображаемая информация верна, нажмите кнопку «Close» для обновления базы данных.	New Requirements Wizard автоматически не фиксирует все обнаруженные требования как конечные, оставляя их в состоянии ожидания.
8. Просмотрите требования и документ.	RequisitePro предлагает утилиту удаления блока требований за один раз.
9. Выделите в Word блок требований.	Выделенная область может включать и требования, и обычный текст.
10. Выберите в меню пункты RequirementàBlock Delete (Unmark)	Обратите внимание, что при удалении требования, его текст остается в документе.
11. Выберите Yes в окне Block Delete (Unmark).
13. После создания и удаления требований, закройте документ.	Во время закрытия документа Вы можете сохранять или не сохранять изменения.

<

Упражнение 9.3 - Дополнительные функции области просмотра

Задачи:

В упражнении 9.3. требуется выполнить следующее:

1. Быстро заполнить выбранный набор атрибутов требований с общим значением.

2. Обновите область просмотра в многопользовательской среде.

ШАГИ	КОММЕНТАРИИ
	В этом упражнении Вы выполните некоторые операции, способствующие быстрым изменениям в группах требований.
1. Откройте какой-либо проект, например, ТЗ или QuarterByte Savings Bank Example Project.
2. Создайте область просмотра Attribute Matrix с типом требований SR.	Появилось окно, отображающее требования с типом SR в первом столбце и атрибуты типа требования SR в остальных столбцах.
3. Сформируйте запрос для выбора требований, имеющих различные приоритеты.	Представьте, что Вы хотите установить общие значения всем требованиям с атрибутом приоритет (например, High).
4. Выделите столбцы, в которых следует установить одно и тоже значение атрибута.
5. Щелкните правой клавишей мыши и в появившемся окне выберите значение требуемого атрибута.	Появляется окно Set Value.
6. В раскрывающемся меню выберите новое значение: High.
7. Нажмите на кнопку «OK», чтобы подтвердить изменение.	Обратите внимание, что все выбранные значения атрибута изменились.
	Предположим, что Вы находитесь в многопользовательской среде, и другие пользователи работают в том же проекте что и Вы. Далее предположим, что у Вас есть предварительно подготовленная область просмотра какой-то части требований проекта. Так как другие пользователи могут активно изменять требования, находящиеся в Вашем окне просмотра, нужно убедится, что у Вас отображается текущая версия требований.
8. Нажмите на иконку Refresh the view.	Это действие обновляет область просмотра требований.

Упражнение 9.4 – Специальная обработка подозрительных связей между иерархическими требованиями

Задачи:

В упражнении 9.4.

требуется выполнить следующее:

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

ШАГИ	КОММЕНТАРИИ
RequisitePro осуществляет специальную обработку подозрительных связей между иерархическими требованиями. RequisitePro рассматривает все требования – как потомки, неявно связанными с требованиями родителей. Эти неявные связи отслеживаются автоматически при замене или изменении требования – родителя. В этом случае RequisitePro предполагает то, что Вы неявно установили подозрительную связь между требованием – родителем и всеми требованиями - потомками, связанными с измененным родителем. В этом упражнении исследуются технические приемы и формы записи подозрительных связей.
1. Откройте проект, например, Quarter Byte savings Bank Example project.	В первой части этого упражнения Вы создадите область просмотра связей.
2. Создайте область просмотра требований с использованием матрицы связей Traceability Matrix.
3. Выделите в cтроке и столбце типы требования SR и нажмите «OK».
4. Нажмите «OK».	Появляется окно, отображающее в строках и столбцах требования с типом SR.
5. Найдите корневое иерархическое требование и удостоверитесь, что строка или столбец, содержащие его, полностью раскрыты.	Подсказка: удостоверитесь, что видна кнопка “–”, расположенная рядом с иерархическим требованием. В противном случае нажмите на “+”, чтобы полностью отобразить иерархию требований.
6. Отредактируйте корневое требование.
7. Обратите внимание на появление флажков в ячейках, отображающих связь между требованием родителя и требованиями потомков. Флажок указывает на подозрительную связь.	Флажок используется, чтобы показать "подозрительную связь" между измененным требованием - родителем и его потомками.
8. Вы можете щелкнуть правой кнопкой мыши по ячейке с подозрительной связью, выбрать в меню пункт Clear Suspect, и удалить подозрительную связь.
9. Полностью сверните иерархический связи.	Нажмите на кнопку “–”, расположенную рядом с иерархическим требованием.
10. Вы увидите в ячейке запись “+”, относящуюся к только что установленной Вами связи.	Запись “+” в ячейке указывает на то, что в иерархии имеются неявные связи (и подозрительные связи), которые Вы не можете видеть, так как иерархия свернута.
11. Щелкните правой кнопкой мыши на ячейке с записью “+” и выберите пункт Expand в вызванном меню.	Пункт Expand позволяет Вам легко развернуть иерархию, чтобы рассмотреть неявные и подозрительные связи, спрятанные в иерархии.
	На этом завершаются упражнения Лабораторной работы № 9.

<

СПИСОК ЛИТЕРАТУРЫ

1. The Rational Unified Process.

2. Ed Yourdon. Managing Software Requirements ISBN 0-201-61593-2.

3. Гост 34.602-89 Техническое задание на создание автоматизированной системы.

4. Roger Oberg, Leslee Probasco, Maria Ericsson. Applying Requirements Management with Use Cases. White Papers in RUP.

5. Ian Spence, Rational U.K., and Leslee ProbascoTraceability Strategies for Managing Requirements with Use Cases. White Papers in RUP.

6. Using Rational RequisitePro. Rational the e-development company.

7. Installing Rational RequisitePro. Rational the e-development company.

ПРИЛОЖЕНИЕ 1

ПРИМЕР ШАБЛОНА ТЕХНИЧЕСКОГО ЗАДАНИЯ

<НАИМЕНОВАНИЕ ОРГАНИЗАЦИИ ЗАКАЗЧИКА>

УТВЕРЖДЕН

<НАЗВАНИЕ АВТОМАТИЗИРОВАННОЙ СИСТЕМЫ>

ТЕХНИЧЕСКОЕ ЗАДАНИЕ

Листов (количество листов)

2001 г.

СОДЕРЖАНИЕ

1. Общие сведения

2. Назначения и цели разработки АС

3. Характеристики объекта автоматизации

4. Требования к АС

Требования к АС в целом

Требования к функциям, выполняемым АС

Требования к видам обеспечения

5. Требования к документации

6. Порядок и контроль приемки системы

ПРИЛОЖЕНИЯ

1. ОБЩИЕ СВЕДЕНИЯ

1.1. Настоящее техническое задание (ТЗ) разработано на автоматизированную систему (АС) <наименование автоматизированной системы>, в связи с отсутствием таковой в <наименование автоматизируемой организации>, существующим оформлением документации и т.п.

АС должна функционировать в архитектуре клиент-сервер с использованием СУБД <наименование СУБД>. Предполагается на сервере хранить ограничения целостности в виде процедур и триггеров, определение базы данных (БД) и сами данные, а на клиентском месте загрузочный модуль, реализующий алгоритм приложения, а также локальные данные, полученные как результат запросов к БД.

1.2. Полное наименование системы – «Полное наименование системы».

Условное обозначение системы – «Условное обозначение системы».

1.3. Разработчик системы – «Наименование фирмы разработчика системы».

Заказчик системы – «Наименование фирмы заказчика системы».

1.4. Основанием для разработки являются: договор между «Наименование фирмы разработчика системы» и «Наименование фирмы заказчика системы» N <номер договора> на создание научно-технической продукции от <дата заключения договора>.

1.5. Срок окончания работ <дата окончания договора>.

1.6. Порядок оформления и предъявления Заказчику работ в рамках настоящего ТЗ приведен в разделах 5, 6 данного технического задания.

1.7. АС будет использоваться в отделе <наименование отдела>.

2. НАЗНАЧЕНИЕ И ЦЕЛИ РАЗРАБОТКИ АС

2.1. Целью разработки АС является повышение производительности и качества труда сотрудников и безошибочная подготовка документов.

2.2. Назначение АС состоит в автоматизации процесса оформления документов.

3. ХАРАКТЕРИСТИКИ ОБЪЕКТА АВТОМАТИЗАЦИИ

3.1. Объектом автоматизации является <наименование автоматизируемого подразделения>

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

4. ТРЕБОВАНИЯ К АС

4.1. Требования к АС в целом

АС <сокращенное наименование> должна работать с базой данных <наименование автоматизируемого отдела>

АС является автономной.

Ввод информации осуществляется вручную сотрудниками <наименование автоматизируемого отдела>

Квалификация персонала, работающего с АС, должна соответствовать умению работы Windows 98, Excel, свободному владению клавиатурой персональных ЭВМ.

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

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

Защита информации от несанкционированного доступа осуществляется средствами сетевой операционной системы AIX, СУБД <наименование СУБД> и организационными мерами, предотвращающими доступ посторонних лиц в помещения, где находится сервер базы данных и проводятся работы пользователей с АС.

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

4.2. Требования к функциям, выполняемым АС

Функциями, разрабатываемой АС являются:

1. Описание функции 1;

2. Описание функции 2;

3. Описание функции N.

Функциональная модель системы представлена в приложении 1.

Алгоритм функционирования АС есть реализация указанных выше функций.

4.3. Требования к видам обеспечения

Настоящая АС должна функционировать с сетевой операционной системой <наименование операционной системы> или выше на файл-сервере и с операционной системой <наименование операционной системы> на рабочих станциях.

АС должна функционировать в архитектуре клиент-сервер с использованием СУБД <наименование СУБД>.

АС должна разрабатываться с использованием методологии <наименование методологии> и CASE-средства <наименование CASE-средства>и среды разработки <наименование среды разработки>, что позволит обслуживать и сопровождать АС силами специалистов Заказчика.

АС должна функционирует на технических средствах, включающих в себя:

- сервер БД на базе <тип ЭВМ > с оперативной памятью не менее <объем ОП>, дисковым накопителем, объемом не менее <объем>, сетевой платой <тип сетевой платы>;

- рабочие станции (по числу рабочих мест), каждая из которых имеет процессор не хуже <тип процессора>, оперативную память не менее <объем ОП>, дисковый накопитель, объемом не менее <объем> цветной монитор <тип монитора> с разрешением не менее <тип разрешения>, сетевую плату <тип сетевой платы>;

- сетевую разводку на тонком кабеле или на витой паре;

- сетевой лазерный принтер производства фирмы <тип требования> с картриджем русских шрифтов;

- источник резервного питания для файл-сервера.

5. ТРЕБОВАНИЯ К ДОКУМЕНТАЦИИ

5. 1. Документация на разрабатываемую систему должна включать:

- текст программ на магнитных носителях;

- руководство пользователя;

- руководство системного программиста;

- руководство администратора базы данных;

- программу и методику испытаний.

Документация должна соответствовать требованиям РД 50-34.698-90, ГОСТ 19.106-78, ГОСТ 19.503-78.

6. ПОРЯДОК И КОНТРОЛЬ ПРИЕМКИ СИСТЕМЫ

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

6.2. Сдача и приемка АС в постоянную эксплуатацию производится в соответствии с документом "Программа и методика испытаний", который должен быть представлен Исполнителем, согласован и утвержден Заказчиком.

6.3. Заказчик принимает АС при условии, что испытания продемонстрируют, что АС выполняет операции в соответствии с "Программой и методикой испытаний" и соответствует требованиям данного технического задания.

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

6.5. Приемка в постоянную эксплуатацию завершается оформлением "акта приемки в постоянную эксплуатацию АС " и актом приемки в фонд алгоритмов и программ (ФАП) документации и МН Заказчика.

ПРИЛОЖЕНИЕ 2

ПРИМЕР ТЕХНИЧЕСКОГО ЗАДАНИЯ

БАНК «РАССВЕТ»

УТВЕРЖДЕН

АВТОМАТИЗИРОВАННАЯ СИСТЕМА (АС)

ФОРМИРОВАНИЯ ДОКУМЕНТОВ ПО СДЕЛКАМ

ПОКУПКИ/ПРОДАЖИ ДРАГОЦЕННОГО МЕТАЛЛА

ТЕХНИЧЕСКОЕ ЗАДАНИЕ

Листов (70)

2000 г. Москва

СОДЕРЖАНИЕ

1. Общие сведениЯ

2. НазнаЧение и цели разработки АС

3. Характеристики объекта автоматизации

4. ТребованиЯ к АС

4.1. Требования к АС в целом.

4.2. Требования к функциям, выполняемым АС

4.3. Требования к видам обеспечения

5. ТребованиЯ к документации

6. Порядок и контроль приемки системы

ПРИЛОЖЕНИЯ

Функциональная модель системы

1. ОБЩИЕ СВЕДЕНИЯ

1.1. Настоящее техническое задание (ТЗ) разработано на автоматизированную систему (АС) формирования документов по сделкам покупки/продажи драгоценного металла, в связи с отсутствием таковой в отделе драгоценных металлов Банка «Рассвет», существующим оформлением документации по сделкам покупки/продажи драгоценного металла лишь с использованием интегрированных таблиц и редакторов текста, а также внедрением в Банке «Расвет» системы SWFIT для передачи сообщений.

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

1.2. Полное наименование системы – «Автоматизированная система формирования документов по сделкам покупки/продажи драгоценного металла».

Условное обозначение системы - GOLD1.0.

1.3. Разработчик системы – ОАО ФАВОРИТ - СИСТЕМЫ.

Заказчик системы - Банк «Рассвет».

1.4. Основанием для разработки являются: договор между ОАО ФАВОРИТ - СИСТЕМЫ и Банком «Рассвет» № 00-1-029-118 на создание научно-технической продукции от 15 сентября 2000 г.

1.5. Срок окончания работ - 10.06.2001г.

1.6. Порядок оформления и предъявления Заказчику работ в рамках настоящего ТЗ приведен в разделах 5, 6 данного технического задания.

1.7. АС формирования документов по сделкам покупки/продажи драгоценного металла будет использоваться в отделе драгоценных металлов банка «Рассвет»

2. НАЗНАЧЕНИЕ И ЦЕЛИ РАЗРАБОТКИ АС

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

2.2. Назначение АС состоит в автоматизации процесса оформления документов по сделкам покупки/продажи драгоценного металла на основе тикета сделки.

3. ХАРАКТЕРИСТИКИ ОБЪЕКТА АВТОМАТИЗАЦИИ

3.1. Объектом автоматизации является отдел драгоценных металлов Банка «Рассвет».

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

4. ТРЕБОВАНИЯ К АС

4.1. Требования к АС в целом

АС GOLD 1.0 должна работать с базой данных операций покупки/продажи драгоценного металла отдела драгоценных металлов Банка «Рассвет».

АС является автономной, обмен информацией с другими подразделениями Банка осуществляется посредством передачи мемориальных ордеров на бумаге в ОПЕРУ и подтверждений и телеграмм в формате телекса и SWIFT на бумаге и по сети в отдел телекса и SWIFT.

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

Квалификация персонала, работающего с АС, должна соответствовать умению работы Windows 98, свободному владению клавиатурой персональных ЭВМ.

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

Такая периодичность обеспечит реальные сроки восстановления работоспособности АС. Для обеспечения работоспособности и поддержания системы необходимо постоянное наличие одного сотрудника - специалиста по вычислительной технике.

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

Защита информации от несанкционированного доступа осуществляется средствами сетевой операционной системы AIX, СУБД Oracle и организационными мерами, предотвращающими доступ посторонних лиц в помещения, где находится сервер базы данных и проводятся работы пользователей с АС.

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

4.2. Требования к функциям, выполняемым АС

Функциями, разрабатываемой АС являются:

1) регистрация сделок покупки драгоценного металла;

2) регистрация сделок продажи драгоценного металла;

3) формирование подтверждений по сделкам покупки/продажи драгоценных металла в формате факса, телекса, SWIFT МТ600;

4) формирование инструкций в банк, обслуживающий счет UNALLOCATED на драгоценный металл, на передачу/получение драгоценного металла в формате телекса, SWIFT МТ604/605;

5) формирование инструкций в банк-корреспондент на поставку/получение валюты в формате телекса МТ202,203/210, SWIFT МТ202,203/210;

6) формирование описи по сделкам покупки/продажи драгоценного металла;

7) формирование мемориального ордера по сделке покупки/продажи драгоценного металла;

8) формирование позиций по счетам НОСТРО по сделкам покупки/продажи драгоценного металла;

9) формирование позиций по счетам UNALLOCATED на драгоценный металл;

10)формирование реестра расчетов в валюте по операциям с драгоценными металлами;

11)ведение справочников контрагентов, агентов, металлов, стран, валют, праздников, установок.

Функциональная модель данных по операциям покупки/продажи драгоценного металла, разработанная с использованием CASE-средства Rational Rose, представлена в Приложении 1..

Алгоритм функционирования АС есть реализация указанных выше функций.

4.3. Требования к видам обеспечения

Настоящая АС должна функционировать с сетевой операционной системой AIX 4.1 или выше на файл-сервере и с операционной системой Windows NT на рабочих станциях.

АС должна функционировать в архитектуре клиент-сервер с использованием СУБД Oracle.

АС разрабатывается с использованием методологии Rational Unified Process и CASE средства Rational Rose и среды разработки POWERBUILDER, что позволит обслуживать и сопровождать АС силами специалистов Банка «Рассвет».

АС функционирует на технических средствах, включающих в себя:

- сервер БД на базе ЭВМ RS 6000 с оперативной памятью не менее 64 Мб, дисковым накопителем, объемом не менее 2 Гб, сетевой платой Ethernet для RS 6000;

- рабочие станции (по числу рабочих мест), каждая из которых имеет процессор не хуже 486DX2/66 МГц, оперативную память не менее 32 Мб, дисковый накопитель, объемом не менее 540Мб, накопитель на гибких дисках 3,5", цветной монитор SVGA с разрешением не менее 640*480, сетевую плату Eternet;

- сетевую разводку на тонком кабеле или на витой паре;

- сетевой лазерный принтер производства фирмы Hewlett-Packard с картриджем русских шрифтов;

- источник резервного питания для файл-сервера.

5. ТРЕБОВАНИЯ К ДОКУМЕНТАЦИИ

Документация на разрабатываемую систему должна включать:

- текст программ на магнитных носителях;

- руководство пользователя;

- руководство системного программиста;

- руководство администратора базы данных;

- программу и методику испытаний.

Документация должна соответствовать требованиям РД 50-34.698-90, ГОСТ 19.106-78, ГОСТ 19.503-78.

6. ПОРЯДОК И КОНТРОЛЬ ПРИЕМКИ СИСТЕМЫ

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

6.2. Сдача и приемка АС GOLD1.0 в постоянную эксплуатацию производится в соответствии с документом "Программа и методика испытаний", который должен быть представлен Исполнителем, согласован и утвержден Заказчиком.

6.3. Заказчик принимает АС при условии, что испытания продемонстрируют, что GOLD1.0 выполняет операции в соответствии с "Программой и методикой испытаний" и соответствует требованиям данного технического задания.

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

6.5. Приемка в постоянную эксплуатацию завершается оформлением "акта приемки в постоянную эксплуатацию GOLD1.0 и актом приемки в фонд алгоритмов и программ (ФАП) документации и МН Банка «Рассвет».

ПРИЛОЖЕНИЕ 3

ТИПЫ ДОКУМЕНТОВ И ТРЕБОВАНИЙ

Наименование типа документа	Расширение	Наименование типа требования	Расширение
Тип: Техническое задание	TT	Тип: Функция системы	UC
Тип: Приемка системы	ACC
Тип: Документация по системе	DSYS
Тип: Вид обеспечения	RH
Тип: Бизнес правило	BUS

ПРИЛОЖЕНИЕ 4

ПРИМЕРЫ ТИПОВ АТРИБУТОВ ТРЕБОВАНИЙ

ПО УМОЛЧАНИЮ

Тип атрибута	Значение атрибута
Состояние (State)	Предполагаемый (Proposed)
Утвержденный (Approved)
Включенный (Incorporated)
Преимущество (Benefit)	Критическое(Critical)
Важное (Important)
Полезное (Useful)
Подтвержденное (Valideted)
Трудозатраты (Effort)	Очень высокие (High)
Средние (Medium)
Низкие (Low)
Риск (Risk)	Очень высокий (High)
Средний (Medium)
Низкий (Low)
Стабильность (Stability)	Очень высокая (High)
Средняя (Medium)
Низкая (Low)
Назначенный (Assigned to)	Список назначенных лиц
Обоснование (Reason)	Список обоснований

<

ПРИЛОЖЕНИЕ 5

ПРИМЕР СТРУКТУРЫ ПРОЕКТА

Метка требования Тип требования	Тип документа расширение	Наименование документа	Обуславливает требование	Зависит от требования
TERM Тип: Термин	Тип: Словарь .GLS	Словарь терминов предметной области	Нет	Нет
BUS Тип: Бизнес правило	Тип: Бизнес правла .BRUL	Бизнес правила предметной области	UC	Нет
UC Тип: Функция системы	Тип: Техническое задание .TT	Техническое задание на АС	ТС (тестируемые функции)	NEED (потребности заказчика)

ПРИЛОЖЕНИЕ 6

Примеры требований Типа: Функция системы с атрибутами

Требования Тип: Функция системы	Приоритет	Риск	Состояние	Трудозатраты
1. Регистрировать конверсионные операции	Очень высокий	Высокий	Включенная	Средние
2. Формировать открытую валютную позицию	Очень высокий	Высокий	Включенная	Высокие