Теоретическая часть. Практическое занятие № 1

Практическое занятие № 1

УПРАВЛЕНИЕ ТРЕБОВАНИЯМИ К ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ. СБОР ТРЕБОВАНИЙ ЗАИНТЕРЕСОВАННЫХ ЛИЦ

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

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

Теоретическая часть

1.1.1 Управление требованиями. Один из наиболее важных элементов при разработке программного обеспечения – управление требованиями (Requirements Management, RM). Это систематический подход к сбору, организации, документированию и отслеживанию требований системы. Надлежащее управление требованиями помогает проверять систему, управлять изменениями и анализировать статус проекта. Намного дешевле исправлять проблемы в течение процесса анализа требований, чем на стадии проектирования, тестирования или выпуска релиза.

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

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

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

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

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

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

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

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

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

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

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

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

Рис.1.1 – Пирамида требований

«Хорошее» требование. Требование должно удовлетворять нескольким критериям для того, чтобы считаться «хорошим требованием». Хорошее требование должно иметь следующие характеристики.

Недвусмысленность: должен существовать только один путь интерпретации требования. Иногда двусмысленность проявляется в виде неопределенных акронимов.

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

Ясность (Краткость, Сжатость, Простота, Точность): требования не должны содержать ненужных выражений или информации. Они должны быть изложены кратко и просто.

Корректность: если требование содержит факты, эти факты должны быть достоверны.

Понятность: требования должны быть грамматически правильные, написаны в соответствующем стиле. Должны быть использованы стандартные соглашения. Слово «должен» должно быть использовано вместо «будет», «обязан» или «может».

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

Независимость: чтобы понять требование, не нужно знать какое-либо другое требование.

Элементарность: требование должно содержать отдельный трассируемый элемент (для которого возможно отслеживание связи).

Необходимость: в требовании нет необходимости, если ни одному заинтересованному лицу требование не нужно или удаление требования не повлияет на систему.

Независимость от Реализации (Абстрактность): требования не должны содержать ненужной информации о дизайне и реализации системы.

Постоянство: не должно существовать конфликтов между требованиями. Конфликты могут быть прямые и косвенные.

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

Завершенность: требование должно быть описано для всех возможных условий.