Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
3_Вимоги_1 / 09.17.12 / 4_Качество требований.doc
Скачиваний:
289
Добавлен:
08.06.2015
Размер:
1.14 Mб
Скачать

Коммуникатор

Коммуникатор отвечает за организацию, проведение, моделирование и протоколирование совещаний, фокус-групп и мозговых штурмов.

Основные шаги процесса

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

Рисунок 2. Шаги процесса управления требованиями

Каждый представленный выше шаг в процессе управления может повторяться множество раз, причем, переходы от шага к шагу могут быть прямыми и обратными. Обратная связь позволяет уточнять, дорабатывать и корректировать требования. Процесс управления требованиями приведен на рисунке 3:

Рисунок 3. Процесс управления требованиями

Далее подробно рассмотрим каждый шаг процесса.

Планирование процесса

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

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

Как было сказано выше, на этапе планирования также создаются шаблоны необходимых документов: глоссария, технического задания, документа-концепции. При работе с государственным заказчиком для описания требований чаще всего используется техническое задание, разработанное в соответствие с ГОСТ 34.602-89 или ГОСТ 19.201-78. Если нет жестких требований со стороны заказчика на соответствие государственным стандартам, можно использовать спецификацию требований на основе стандарта IEEE 830-1998.

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

Более подробно о планировании процесса управления требованиями можно прочитать во втором выпуске журнала Analyze IT

Выявление требований

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

  • документы, описывающие существующие или конкурирующие продукты;

  • существующие спецификации требований к системе;

  • отчеты об ошибках и запросы от пользователей по совершенствованию системы;

  • результаты маркетинговых исследований;

  • существующая документация с описанием процессов деятельности заказчика и др.

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