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

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

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

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

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

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

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

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

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

– Проектирование системы.

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

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

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

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

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

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

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

– Сессии с применением метода «мозгового штурма» (Brainstorming sessions - групповой метод решения вопросов путем изложения идей в течение непродолжительных, интенсивных сессий).

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

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

– Анализ существующих документов (извлечение информации из документов Microsoft Word, электронной почты и записей).

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

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

1.1.3 Документ Запросов Заинтересованного лица. Вся полученная в процессе сбора требований информация должна быть документально оформлена в документ Запросов Заинтересованного Лица (Stakeholder Requests).

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

Документ Запросов Заинтересованного Лица не содержит специально выделенного места для размещения требований типа STRQ (Stakeholder Requests или Запросы Заинтересованного лица). Требования могут быть вложены в качестве ответов на вопросы интервью, либо собраны в последнем параграфе, названным «Резюме Аналитика».

Главными атрибутами требования являются Text (Текст, обязательный атрибут) и Name (Название, не обязательный). Если Text – короткий (описание состоит из одного предложения), то Вам не надо создавать отдельное Name. Если описание Text длинное, тогда стоит создать краткое название для требования. Если указано Name, оно используется для идентификации требования. Если Name не указано, для идентификации используется Text. Для большей точности лучше использовать название для всех требований одного типа, либо не использовать название ни для одного из них. В нашем проекте мы создадим названия, потому что некоторые потребности заинтересованных лиц довольно обширные. Названия требований должны быть короткими, но содержательными.

Представления. Views (или представления) используются для отображения требований, а также для управления требованиями, их атрибутами и их взаимоотношениями с другими требованиями. Вы можете сортировать и фильтровать требования, чтобы получить необходимый отчет. RequisitePro имеет три типа представлений:

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

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

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

Пример