
- •Часть 1 13
- •Глава 1 14
- •Глава 2 29
- •Часть 2 36
- •Глава 3 37
- •5.6 Заключение 86
- •Глава 6 87
- •6.4 Заключение 108
- •Глава 7 108
- •7.9 Заключение 129
- •Глава 8 130
- •8.7 Заключение 155
- •Глава 9 157
- •9.6 Заключение 176
- •Глава 10 178
- •10.10 Заключение 194
- •Глава 11 195
- •11.4 Заключение 218
- •Глава 12 220
- •14.5 Заключение 246
- •Часть 4 246
- •Глава 15 247
- •3.1 Документы 251
- •Часть 1 Обзор
- •Глава 1
- •1.1 Определение Требования и Заинтересованного Лица
- •1.2 Пирамида Требований
- •1.3 Трассировка (Связь) между Требованиями
- •1.4 Характеристики Хорошего Требования
- •1.5 Обзор Процесса Управления Требованиями
- •Глава 3 «Формирование Плана Управления Требованиями» детально описывает все эти пункты.
- •Глава 8 «Дополнительная Спецификация» детально описывает этот тип требований.
- •1.6 Заключение
- •Глава 2
- •2.1 Интерфейс
- •Окно Проводника Панель Инструментов Область Представлений Описание
- •Views (Область Представлений)
- •2.2 Рабочее Пространство Word
- •2.3 Документы
- •2.4 Требования
- •2.5 Заключение
- •Часть 2
- •Глава 3
- •3.1 Когда Создается Документ rmp
- •3.2 Решения, Которые Могут Быть Оформлены в Документе rmp
- •Глава 1 «Управление Требованиями» перечисляет решения, которые должны быть приняты при создании документа rmp. В следующих пунктах мы обсудим каждое решение и влияющие на него факторы.
- •Глава 12 «Документация» содержит более детальное описание документов, которые, возможно, будет необходимо создать.
- •3.4 Заключение
- •Глава 4
- •4.3 Заключение
- •Глава 5
- •5.6 Заключение
- •Глава 6
- •6.4 Заключение
- •Глава 7
- •7.9 Заключение
- •Глава 8
- •Время ответа
- •Время обработки
- •Число одновременных пользователей
- •Время обработки отчета
- •8.7 Заключение
- •Глава 9
- •9.6 Заключение
- •Глава 10
- •10.10 Заключение
- •Глава 11
- •11.4 Заключение
- •Глава 12
- •12.4 Заключение
- •Часть 3
- •Глава 13
- •13.6 Заключение
- •Глава 14
- •14.5 Заключение
- •Часть 4
- •Заключение
- •Глава 15
- •3.1 Документы
Часть 1 Обзор
Управление Требованиями
Обзор RequisitePro
Глава 1
Управление
Требованиями
Данная глава начинается с определения понятий требования и заинтересованных лиц (stakeholders). Далее мы опишем, какие типы требований могут существовать в проекте. Отношения между этими требованиями представляются в форме пирамиды. Также представлено понятие трассировки (или связей: какое требование - откуда было получено). Приведены характеристики хороших требований. Даны примеры проблемных требований вместе с некоторыми инструкциями по их исправлению. Показаны главные стадии управления требованиями (Requirements Management - RM) в течение жизненного цикла проекта. Главные стадии проходят через пирамиду требований сверху вниз.
1.1 Определение Требования и Заинтересованного Лица
Требование определяется как «условие или особенность, которой должна удовлетворять система». Требованием может быть:
Функциональность, необходимая заказчику или пользователю для разрешения проблем (или получения прибыли).
Функциональность, которая должна быть реализована в системе в соответствии с контрактом, стандартом, спецификацией, инструкцией или другим официальным документом.
Ограничение, наложенное заинтересованным лицом.
Рассмотрим понятие заинтересованного лица, т.к. это слово встречается в книге много раз. Обычно под заинтересованным лицом (stakeholder) понимают личность, на которую оказывает влияние разрабатываемая система. Два главных типа заинтересованных лиц – это пользователи и заказчики. Пользователи – это лица, которые будут пользоваться системой. Заказчики – лица, кто заказывает систему и отвечает в дальнейшем за приемку системы. Обычно заказчики платят за разработку системы. Важно различать между этими двумя группами заинтересованных лиц, потому что иногда требования этих двух групп конфликтуют между собой. В большинстве таких конфликтов, запросы заказчика имеют преимущество над запросами пользователя. В используемом в данной книге примере веб-сайта агентства путешествий, заказчик – владелец агентства путешествий, а пользователи – люди, кто будет пользоваться этим веб-сайтом через Интернет. Кроме заказчиков и пользователей, нельзя забывать про многие другие типы заинтересованных лиц.
В интересах данной книги, мы будем называть заинтересованным лицом любого, кто имеет отношение к системе (как в процессе разработки, так и после его завершения), а также любого, у кого могут быть какие-либо требования к системе.
В качестве заинтересованного лица можно рассматривать:
Любого, участвующего в разработке системы (бизнес-аналитики, дизайнеры, кодировщики, тестеры, менеджеры проектов, менеджеры по внедрению, дизайнеры сценариев использования, графические дизайнеры).
Любого, кто привносит свои знания в систему (эксперты предметной области, авторы документов, которые были использованы для сбора требований, собственники веб-сайтов, ссылки на которые были предоставлены).
Руководство (президент компании, которого представляют заказчики, директор отдела информационных технологий компании, проектирующей и разрабатывающей систему).
Лица, вовлеченные в управление, настройку и сопровождение системы (хостинговая компания, справочная служба).
Поставщики стандартов и регламентов (стандарты устанавливаются поисковыми механизмами согласно содержанию веб-сайта, политическим нормам, а также порядку налогообложения в конкретном штате).