ЛАБОРАТОРНАЯ РАБОТА № 3 РАЗРАБОТКА СТРУКТУРЫ ТЕХНИЧЕСКОГО ЗАДАНИЯ С ПОМОЩЬЮ

REQUISITE PRO

1 Цель занятия

Получение навыков сбора и анализа требований заказчиков и пользователей к

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

2 Общие теоретические сведения

2.1 Требования к ТЗ

Техническое задание должно содержать следующие разделы:

введение;

основания для разработки;

назначение разработки;

требования к программе или программному изделию;

требования к программной документации;

технико-экономические показатели;

стадии и этапы разработки;

порядок контроля и приемки;

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

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

содержание разделов, вводить новые разделы или объединять отдельные из них.

2.2 Стадии разработки ПО

Выделяют следующие стадии разработки программного обеспечения:

1 Стадия технического задания (предпроектная стадия) состоит из:

сбора исходных данных;

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

разрабатываемого ПС;

обоснования и выбора критерия эффективности и качества разработки;

формирования на верхнем уровне состава входной и выходной документации по

решаемой задаче;

выбора принципиальных методов решения задач;

определения требований к комплексу технических средств и операционному окружению;

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

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

выполнения;

разработки документа, называемого «Техническое задание».

2 Эскизное проектирование

На данной стадии выполняется:

детализация состава и структуры входной и выходной информации;

детализация метода решения задач.

На этапе эскизного проектирования нужно создать предварительную версию программного

средства (возможно в виде модели) и выяснить принципиальные вопросы, устраняя возможные

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

определение предварительной технологии решения задачи;

прогнозирование эффективности решения задачи на конкретном объекте;

ведется освоение инструментальных средств (апробирование, обучение персонала).

3 Техническое проектирование (технический проект)

На данном этапе:

окончательно определяется состав и структура информации;

разрабатывается интерфейс во всех его компонентах;

технология решения задачи доводится автоматизма;

полностью определяется конфигурация тех средств, на которых ведется разработка ПС;

определяется структура базы данных, где храниться информация о работе ПС;

разрабатывается тестовый набор для проверки правильности программной реализации;

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

полностью определяется структура ПС (модули, компоненты).

Технический проект может рассматриваться как постановка задачи, передаваемой

специалистом-постановщиком специалисту по программной реализации.

4 Рабочее проектирование (рабочий проект)

Результат рабочего проектирования – получение ПС в состоянии операционной готовности,

в котором устранены синтаксические и семантические ошибки, как в программном коде так и в

программной документации.

Основные работы этой стадии:

программная реализация (написание программного кода, привязка его к специфике

конкретного объекта, адаптация и настройка программных модулей);

отладка (автономная – в лабораторных условиях и комплексная – на объекте);

разработка эксплуатационной документации;

организация внедрения ПС.

5 Внедрение

На этапе внедрения осуществляют:

подготовку персонала к эксплуатации;

подготовку базы данных;

проверку работоспособности ПС на реальных данных (опытная эксплуатация);

доводка – окончательное устранение всех ошибок в коде и документации.

По отдельным компонентам может быть откат на предыдущие стадии.

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

Один из наиболее важных элементов при разработке программного обеспечения –

управление требованиями (Requirements Management, RM). Это систематический подход к сбору,

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

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

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

стадии проектирования, тестирования или выпуска релиза.

Использование инструмента для управления требованиями поможет организовать процесс, а

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

инструментов – это IBM Rational RequisitePro.

Требования к ПО. Требование определяется как «условие или особенность, которой должна

удовлетворять система». Требованием может быть:

Функциональность, необходимая заказчику или пользователю для разрешения проблем

(или получения прибыли).

Функциональность, которая должна быть реализована в системе в соответствии с

контрактом, стандартом, спецификацией, инструкцией или другим официальным документом.

Ограничение, наложенное заинтересованным лицом.

Заинтересованные лица. Обычно под заинтересованным лицом (stakeholder) понимают

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

заинтересованных лиц – это пользователи и заказчики. Пользователи – это лица, которые будут

пользоваться системой. Заказчики – лица, кто заказывает систему и отвечает в дальнейшем за

приемку системы.

В качестве заинтересованного лица можно рассматривать:

Любого, участвующего в разработке системы (бизнес-аналитики, дизайнеры,

кодировщики, тестеры, менеджеры проектов, менеджеры по внедрению, дизайнеры сценариев

использования, графические дизайнеры).

Любого, кто привносит свои знания в систему (эксперты предметной области, авторы

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

которые были предоставлены).

Руководство (президент компании, которого представляют заказчики, директор отдела

информационных технологий компании, проектирующей и разрабатывающей систему).

Лица, вовлеченные в управление, настройку и сопровождение системы (хостинговая

компания, справочная служба).

Поставщики стандартов и регламентов (стандарты устанавливаются поисковыми

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

налогообложения в конкретном штате).

Пирамида требований. В зависимости от формата, источника и общих характеристик,

требования могут быть разделены на различные типы. Эти типы требований могут быть

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

Рисунок 1 – Пирамида требований

«Хорошее» требование. Требование должно удовлетворять нескольким критериям для того,

чтобы считаться «хорошим требованием». Хорошее требование должно иметь следующие

характеристики.

Недвусмысленность: должен существовать только один путь интерпретации требования.

Иногда двусмысленность проявляется в виде неопределенных акронимов.

Тестируемость (Возможность Проверки): тестеры должны иметь возможность проверить,

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

Чтобы быть пригодным для тестирования, требование должно быть ясным, точным и

недвусмысленным.

Ясность (Краткость, Сжатость, Простота, Точность): требования не должны содержать

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

Корректность: если требование содержит факты, эти факты должны быть достоверны.

Понятность: требования должны быть грамматически правильные, написаны в

соответствующем стиле. Должны быть использованы стандартные соглашения. Слово «должен»

должно быть использовано вместо «будет», «обязан» или «может».

Правдоподобность (Реальность, Выполнимость): требование должно быть выполнимо в

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

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

Элементарность: требование должно содержать отдельный трассируемый элемент (для

которого возможно отслеживание связи).

Необходимость: в требовании нет необходимости, если ни одному заинтересованному лицу

требование не нужно или удаление требования не повлияет на систему.

Независимость от Реализации (Абстрактность): требования не должны содержать ненужной

информации о дизайне и реализации системы.

Постоянство: не должно существовать конфликтов между требованиями. Конфликты могут

быть прямые и косвенные.

Немногословность: каждое требование должно быть обозначено только один раз, и не

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

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

Этапы управления требованиями. Самое простое описание процесса управления

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

– Формирование плана управления требованиями.

– Сбор требований.

– Разработка документа Концепции (Vision).

– Создание сценариев использования (Use Cases).

– Дополнительная спецификация.

– Создание тестовых сценариев (Test Cases) из сценариев использования (Use Cases). – Создание тестовых сценариев (Test Cases) из дополнительной спецификации. – Проектирование системы.

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

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

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

связи с группой аналитиков.

Запросы заинтересованных лиц могут быть собраны с использованием различных методов:

– Интервью (индивидуальный диалог с заинтересованным лицом).

– Анкеты (набор вопросов, отправленный большому количеству заинтересованных лиц).

– Семинары (заинтересованные лица собираются на определенный период для

интенсивных, насыщенных дискуссий).

– Сценарии приложения (использование визуальных/графических инструментов для

демонстрирования поведения системы).

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

одного из пользователей).

– Сессии с применением метода «мозгового штурма» (Brainstorming sessions - групповой

метод решения вопросов путем изложения идей в течение непродолжительных, интенсивных

сессий).

– Использование прототипов (разработка прототипов для получения отклика о системе).

– Сценарии использования (Use Cases – взаимодействие между пользователем и системой,

представленное в виде последовательности шагов).

– Анализ существующих документов (извлечение информации из документов Microsoft

Word, электронной почты и записей).

– Наблюдение и демонстрирование задач (наблюдение за пользователями, выполняющими

определенную задачу).

– Анализ существующих систем (сбор требований от морально устаревших заменяемых

систем или от систем, разработанных в ходе конкуренции).

Документ Запросов Заинтересованного лица. Вся полученная в процессе сбора

требований информация должна быть документально оформлена в документ Запросов

Заинтересованного Лица (Stakeholder Requests).

Можно создать один документ, который будет содержать в себе запросы всех

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

запросы нескольких заинтересованных лиц в одном документе.

Документ Запросов Заинтересованного Лица не содержит специально выделенного места для

размещения требований типа STRQ (Stakeholder Requests или Запросы Заинтересованного лица).

Требования могут быть вложены в качестве ответов на вопросы интервью, либо собраны в

последнем параграфе, названным «Резюме Аналитика».

Главными атрибутами требования являются Text (Текст, обязательный атрибут) и Name

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

Вам не надо создавать отдельное Name. Если описание Text длинное, тогда стоит создать краткое

название для требования. Если указано Name, оно используется для идентификации требования.

Если Name не указано, для идентификации используется Text. Для большей точности лучше

использовать название для всех требований одного типа, либо не использовать название ни для

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

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

содержательными.

Представления. Views (или представления) используются для отображения требований, а

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

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

отчет. RequisitePro имеет три типа представлений:

– Attribute Matrix (Матрица Атрибутов)

– Traceability Matrix (Матрица Трассировки)

– Traceability Tree (Дерево Трассировки)

Описание задачи

Бюро космических путешествий Space Travel предоставляет своим клиентам туристические

услуги абсолютно нового уровня – космические перевозки. На туристическом рынке они совсем

недавно, а потому еще не успели обзавестись всеми атрибутами качественной компании. У

компании нет своего веб-сайта, все операции выполняются в локальной сети, доступ к которой

имеют только сотрудники.

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

либо звонят по телефону агенту. Информацию об услугах компании клиенты получают из

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

предоставляют сотрудники компании по запросам клиентов. Информацию о дополнительных

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

В компании несколько отделов: обслуживания клиентов, маркетинга, финансового

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

координирует работу всех функциональных подразделений.

В компании нет своих программистов, поэтому они вынуждены заказать разработку веб-

сайта. Задачи сайта сотрудники видят весьма обобщенно: информация о рейсах, бронирование и пр.

Поэтому необходим анализ и работа с каждой из категорий пользователей для построения

эффективного сайта.

Заказчиком проекта является руководитель бюро путешествий, а пользователями – сам

руководитель, сотрудники отделов, клиенты компанию, а также те, кто будет отвечать за

сопровождение сайта.

Условные обозначения и сокращения

ф. – форма кн. – кнопка конт. меню – контекстное меню выбр. – выбрать → – переход

← – ввод значения

| – действие на текущей форме

3 Методика выполнения работы

А. Настройка проекта

1. Создание нового проекта в Requisite Pro

Пуск → Программы → IBM Rational Requisite Pro →

File → New → Project… → ф. Create Project | выбр. Use-Case Template → Ok →

ф. Rational RequisitePro Project Properties | Name ← SpaceTravel_группа (например, SpaceTravel_ПИ200); Directory ← выбрать расположение директории проекта; Database ←

Ms Access; кн. Ok →

Ф. Create Rational RequisitePro Project | The RequisitePro Project was successfully created; кн. Close →

Ф. Project Logon | Username ← ввести свои фамилии

2. Составить перечень всех заинтересованных в проекте лиц (не менее 5) и внести их в

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

бюро путешествий, разработчик, администратор, пользователь и пр.:

конт. меню SpaceTravel → Properties → ф. Project Properties | выбр. вкладку Attributes; выбр. Origin (источник требования); выбр. Values per Attribute | выбр. Help Desk; кн. Delete → сообщение «Rational RequisitePro» («Do you want to attempt to gain exclusive access to the project now?») | кн. «Да» → ф. Project Properties (Exclusive) | кн. Add → ф. Attribute Value | Value ← Пользователь; кн. Ok.

Аналогичным образом для остальных значений атрибута Origin.

3. Добавить атрибут Status для обозначениястатуса каждого требования:

конт. меню SpaceTravel → Properties → ф. Project Properties | выбр. вкладку Attributes | кн. Add → ф. Add Attribute

Label ← Status; Type ← List (Single Value);

List Values ← Получен Подтвержден Включен Отклонен

(каждое значение с новой строки); кн. Ok → ф. Project Properties | кн. Ok

Б. Сбор требований к программному обеспечению

1. Создание документа Запросов Заинтересованного Лица: Проводник | SpaceTravel | Stakeholder Requests | конт. меню New → Document… → ф. Document Properties | Name ←

Запрос_Руководитель; Description ← «Документ предназначен для сбора требований от руководителя бюро космических путешествий»; Document Type ← Stakeholder Request; кн. Ok →

окно MS Word с шаблоном документа

2. Заполнение документа Запросов Заинтересованного Лица

2.1. Заполнение свойств документа

Шаблон MS Word | кн. Office → Подготовить → Свойства → ф. Свойства:

Запрос_Руководитель.STR |

Название ← Требования руководителя; Тема ← Бюро космических путешествий;

Автор ← Student (фамилии); Организация ← University; кн. Ok

2.2. Автозаполнение полей документа требований:

Окно «Запрос_Руководитель.STR – Microsoft Word» | колонтитул <Company Name> | уст.

курсор на серое поле → кн. F9 (в результате вместо Company Name должен появиться текст

University). Аналогичным образом заполнить поля <Project Name>, Stakeholder Requests, <Company

Name> (найдите их в документе).

2.3. Заполнение раздела Introduction в документе Запросов Заинтересованного Лица

Окно «Запрос_Руководитель.STR – Microsoft Word» | заменить заголовок Stakeholder

Requests на «Требования руководителя»; заменить заголовки разделов Introduction, Purpose, Scope и Definitions, Acronyms and Abbreviations на Введение, Цель, Обзор, Определения, акронимы и аббревиатуры. Удалить разделы References и Overview.

2.3.1. Заполнить подраздел Введение

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

который позволит оптимизировать работу с клиентами

2.3.2. Заполнить подраздел Цель

Цель настоящего документа – описание требований к сайту руководителя бюро космических путешествий

2.3.3. Заполнить подраздел Обзор

В рамках настоящего проекта предполагается реализация функций получения информации

и выбора рейсов, покупки и бронирования билетов, указания дополнительных опций

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

БКП – Бюро космических путешествий

2.4. Заполнение раздела Establish Stakeholder or User Profile

Окно «Запрос_Руководитель.STR – Microsoft Word» | заменить заголовок Establish

Stakeholder or User Profile на «Анкета руководителя бюро космических путешествий». Заменить

англоязычный текст анкеты на следующий:

• Имя: Иван Иванов.

• Компания/Область: Бюро космических путешествий Space Travel.

• Должность: Руководитель.

• Каковы Ваши основные обязанности? Руководство агентством, увеличение прибыли от

продаж.

• Какие услуги Вы предоставляете? Для кого? Бронирование перелета на конкретную дату и

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

отзывов клиентов о качестве услуг, заказ DVD с записью полета.

• Каким образом определяется успешность деятельности? Прибылью от продаж и от

привлеченных средств.

• Какие проблемы препятствуют Вашему успеху? Без веб-сайта мы ограничены в

предоставлении услуг.

• Какие направления (если есть) делают Вашу работу легче или сложнее? Интернет дает

нам возможность находить много новых клиентов.

2.5. Заполнение раздела Assessing the Problem

Окно «Запрос_Руководитель.STR – Microsoft Word» | заменить заголовок Assessing the

Problem на «Описание проблемы». Заменить англоязычный текст на следующий:

• Для каких проблем Вам необходимо хорошее решение? Он-лайн продажи.

• Как Вы решаете ее сейчас? В настоящее время заказчики звонят, чтобы сделать заказ.

• Как бы Вы хотели решить ее? Мы бы хотели, чтобы клиенты имели возможность

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

2.6. Заполнение раздела Understanding the User Environment

Окно «Запрос_Руководитель.STR – Microsoft Word» | заменить заголовок Understanding the

User Environment

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

• Кто является пользователем системы? Всякий, кто хочет купить билет на космический

полет.

• Какое у них образование? Разное.

• Какое у них компьютерное образование? Пользователи.

• Есть ли у пользователей опыт работы с приложением данного типа? Да.

• Какие платформы они используют? Приложение будет доступно через браузер.

• Каковы Ваши ожидания в плане удобства использования продукта? Система должна быть

проста в использовании.

• Каковы Ваши ожидания в плане выделения времени на тренинги? Время для изучения

должно быть минимальным, а навигация - простой.

• Какие печатные копии и он-лайн документация Вам необходимы? Он-лайн помощь для

пользователей.

2.7. Заполнение раздела Recap for Understanding

Окно «Запрос_Руководитель.STR – Microsoft Word» | заменить заголовок Recap for

Understanding на «Обобщение для понимания». Заменить англоязычный текст на следующий:

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

билетов через Интернет. Отражает ли это Ваши текущие проблемы с существующими решениями?

Нет, на сегодняшний день у нас нет возможности реализовать он-лайн продажи

• С какими проблемами Вы уже встречались (если есть)? Мы теряем клиентов из-за

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

2.8. Заполнение раздела Analyst’s Inputs on Stakeholder’s Problem (validate or invalidate

assumptions)

Окно «Запрос_Руководитель.STR – Microsoft Word» | заменить заголовок Analyst’s Inputs on

Stakeholder’s Problem (validate or invalidate assumptions) на « Взгляд аналитика на проблемы

заинтересованного лица ». Заменить англоязычный текст на следующий:

• Какие (если есть) проблемы, связанные с работой организации? Отсутствие онлайн

продаж.

• Для каждой предложенной проблемы, задайте следующие вопросы:

• Это реальная проблема? Да.

• Каковы причины данной проблемы? Отсутствие веб-сайта.

• Каким образом Вы решаете эту проблему? С помощью телефонных звонков.

• Как бы Вы хотели решить проблему? Осуществлением продаж через веб-сайт.

2.9. Заполнение раздела Assessing Your Solution (if applicable)

Окно «Запрос_Руководитель.STR – Microsoft Word» | заменить заголовок Assessing Your

Solution (if applicable) на «Оценка Вашего решения». Заменить англоязычный текст на следующий:

• Что если бы Вы могли….(суммирование главных возможностей предложенного Вами

решения).

• Как бы Вы оценили значимость этого?

2.10. Заполнение раздела Assessing the Opportunity

Окно «Запрос_Руководитель.STR – Microsoft Word» | заменить заголовок Assessing the

Opportunity на «Оценка возможности». Заменить англоязычный текст на следующий:

• Кому необходимо данное приложение в Вашей организации? Главная польза будет для

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

обслуживания клиентов.

• Насколько много пользователей данного типа будут пользоваться приложением? Один

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

• Как бы Вы оценили успешное решение? Оценка успеха: количество продаж через

Интернет.

2.11. Заполнение раздела Assessing Reliability, Performance and Support Needs

Окно «Запрос_Руководитель.STR – Microsoft Word» | заменить заголовок Assessing

Reliability, Performance and Support Needs на «Определение надежности, производительности и

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

• Каковы Ваши ожидания в плане надежности? Сопоставимо с другими коммерческими

веб-сайтами в этом плане.

• Каковы Ваши ожидания в плане производительности? Сопоставимо будет сопоставима с

другими коммерческими веб-сайтами в этом плане.

• Будете ли Вы сами осуществлять сопровождение продукта или ее будет осуществлять

иные лица? Требуется поддержка со стороны организации-разработчика

• Есть ли у Вас какие-либо специальные требования к сопровождению? Стандартное

сопровождение сайта.

• Каковы требования к безопасности? Все пользователи системы должны проходить

процедуры идентификации и аутентификации.

• Каковы требования к установке и конфигурированию системы? Установка на

пользовательских компьютерах не требуется.

• Есть ли специальные требования по лицензиям? Нет.

• Каким образом будет осуществляться распространение системы? Система будет

установлена на сервере хостинговой компании.

• Каковы требования к маркировке и оформлению пакета требований? Нет.

• Каковы (если есть) Ваши требования к инструкциям или среде? Должна ли

осуществляться поддержка стандартов? Нет.

• Есть ли еще какие-либо требования, о которых мы должны знать? Система должна быть

разработана в течение трех месяцев.

2.12. Заполнение раздела Wrap-Up

Окно «Запрос_Руководитель.STR – Microsoft Word» | заменить заголовок Wrap-Up на

«Подведение итогов». Заменить англоязычный текст на следующий:

• Есть ли какие-либо другие вопросы, которые я должен задать Вам? Нет. • Если я должен

задать сопутствующие вопросы, я могу звонить Вам? Да.

• Хотели бы Вы участвовать в обзоре требований? Да.

2.13. Заполнение раздела Analyst’s Summary

Окно «Запрос_Руководитель.STR – Microsoft Word» | заменить заголовок Analyst’s Summary

на «Резюме аналитика». Данный раздел предназначен для перечисления требований от

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

имеющейся в тексте цифры 1 ввести текст требования:

Система должна предоставлять возможность бронирования рейса на определенную дату и время

Аналогичным образом ввести еще два требования:

2. Пользователь должен иметь возможность купить билет через веб-сайт

3. Пользователь должен иметь возможность выбрать определенное место в салоне

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

их в документ.

2.13. Сохранить документ:

Окно «Запрос_Руководитель.STR – Microsoft Word» | Вкл. Надстройки → RequisitePro → Document → Save; Закрыть MS Word

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

заинтересованных лиц. В каждом документе должно быть не менее 10 требований.

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

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

ф. Rational RequisitePro – SpaceTravel | Stakeholder Requests → выбр. документ (например, Запрос_Руководитель), нажать [Enter] → окно «Запрос_Руководитель.STR – Microsoft Word»

2. Перейти к разделу «Резюме аналитика».

3. Создать требование:

Выделить текст требования → вызвать конт. меню →

выбр. пункт New Requirement… → ф. Requirement Properties: STRQpending1 | Type ← SRTQ:

Stakeholder Request, Name ← Бронирование рейса; кн. Ok →

Соответствующее требование в тексте будет выделено серым цветом шрифта и помещено

между прямыми скобками с индексом STRQpending1.

Аналогичным образом создать остальные требования в документе.

4. Сохранение требований в базу данных:

Окно «Запрос_Руководитель.STR – Microsoft Word» | Вкл. Надстройки → RequisitePro → Document → Save → во всех требованиях STRQpending будет заменен наSTRQ. Закрыть

MS Word

В окне RequisitePro в иерархии проекта проследить наличие сформированных требований.

5. Задать значения свойств требований:

ф. Rational RequisitePro – SpaceTravel | Stakeholder Requests → выбр. требование

(текст с префиксом STRQ) → конт. меню → Properties… →

ф. Requirement Properties | вкл. Attributes | Stakeholder Priority ← Medium, Origin ← Руководитель, Status ← Получен; кн. Ok

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

заинтересованного лица.

Г. Создание представлений

1. Создать новое представление

ф. Rational RequisitePro – SpaceTravel | Features and Vision | вызвать конт. меню New → View… → ф. View Properties | Name ← StrQ, View Type ← Attribute Matrix, Row Requirement Type ← STRQ:

Stakeholder Request, кн. Ok → просмотреть результат в RequisitePro

2. Создать запрос к представлению, извлекающий только требования от руководителя

предприятия:

ф. Rational RequisitePro – SpaceTravel | представление из прошлого задания | Requirements |

контекстное меню → выбр. Query... →ф. Select Attribute |

выбр. Origin → ф. Query Requirements | выбр. Руководитель; кн. Ok →

ф. Query Row Requirements | кн. Ok → просмотреть результат в RequisitePro

4 Задачи для самостоятельного решения студентами

4.1 Открыть RequisitePro и выполнить все шаги методики из раздела 3 для

приведённого примера.

4.2 Получить у преподавателя вариант бизнес-процесса, для которого

необходимо написать ТЗ на ПО из следующих: фирма по заказу гостиниц или квартир;

фирма по предоставлению машины на прокат;

фирма по оформлению микрозаймов;

фирма по мед. обследованию для справок (ГИБДД, бассейн, трудоустройство и т.д.);

фирма по страхованию авто и жизни;

фирма по оказанию юридических консультаций;

фирма по развитию ребёнка до школы.

Примечание

1 Услуга клиенту должна включать следующие обязательные элементы:

оформление договора;

оформление акта приёмки работ;

механизм оплаты работ;

систему учёта работ;

систему учёта клиентов;

систему учёта сотрудников.

2 Обязательные параметры в ТЗ:

наличие не менее 3 заинтересованных лиц;

наличие 35 - 45 функций, реализуемых в проектируемой системе (например,

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

требований (документа Запросов Заинтересованного Лица).

4.4 Сформировать формальные требования к программного средства.

4.5 Сформировать представления.

5 Контрольные вопросы

1