Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Управление требованиями (M. Lines).doc
Скачиваний:
0
Добавлен:
01.05.2025
Размер:
10.04 Mб
Скачать

Часть 1 Обзор

  1. Управление Требованиями

  1. Обзор RequisitePro

Глава 1

Управление

Требованиями

Данная глава начинается с определения понятий требования и заинтересованных лиц (stakeholders). Далее мы опишем, какие типы требований могут существовать в проекте. Отношения между этими требованиями представляются в форме пирамиды. Также представлено понятие трассировки (или связей: какое требование - откуда было получено). Приведены характеристики хороших требований. Даны примеры проблемных требований вместе с некоторыми инструкциями по их исправлению. Показаны главные стадии управления требованиями (Requirements Management - RM) в течение жизненного цикла проекта. Главные стадии проходят через пирамиду требований сверху вниз.

1.1 Определение Требования и Заинтересованного Лица

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

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

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

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

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

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

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

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

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

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

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

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