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

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

1. Координация работ по управлению требованиями в проекте возлагается на одного члена рабочей группы – Аналитика, на протяжении всего жизненного цикла проекта.

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

3. Документ, содержащий требования к разрабатываемому продукту, должен быть письменно утвержден Заказчиком[1]. После утверждения требований Заказчиком технические риски, связанные с формулировкой требований принимает на себя Заказчик.

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

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

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

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

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

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

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

11. Документ, описывающий требования к ПО – Техническое Задание должен находиться под конфигурационным контролем.

12. Группа обеспечения качества в соответствии со своим планом проводит проверки и аудит процедур управления требований.

 

 

<== предыдущая лекция | следующая лекция ==>
Принципы реализации пользовательского интерфейса | Обеспечение процессов управления требований


Дата добавления: 2017-12-05; просмотров: 18; ЗАКАЗАТЬ НАПИСАНИЕ РАБОТЫ


Поиск по сайту:

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

Поделитесь с друзьями:

Если вам понравился данный ресурс вы можете рассказать о нем друзьям. Сделать это можно через соц. кнопки выше.
helpiks.org - Хелпикс.Орг - 2014-2018 год. Материал сайта представляется для ознакомительного и учебного использования. | Поддержка
Генерация страницы за: 0.01 сек.