Выводы к первой части

Данная часть является вводной и предназначалась для знакомства читателя с понятием требований, их роли в процессе разработки программного обеспечения. Здесь были даны определения требований, описаны основные типы требований и приведены данные о стоимости «плохих» требований.

Типы требований, описанные в данном разделе, появились в результате сопоставления трех основных методологий по работе с требованиями [2], [3], [4] и их сопоставления (адаптацией) с ГОСТ 34.602-89.

Цена ошибки в требованиях довольно велика, и необходимо попытаться сократить стоимость подобных ошибок.

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

Литература

[1] Д. Леффингуэлл, Д. Уидриг, Принципы работы с требованиями к программному обеспечению. Унифицированный подход, Вильямс, 2002 [2] К. Вигерс. Разработка требований к программному обеспечению, Русская Редакция, 2004 [3] IIBA,AguidetotheBusinessAnalysisBodyofKnowledge,v1.6, 2006 [4]IBM,RationalUnifiedProcessv. 2003.

Часть 2. Управление требованиями

Рубрика: Качество требований,Статья,Требования

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

Ранее опубликованные материалы можно посмотреть здесь:Управление качеством требований. НачалоУправление качеством требований. Часть 1. Требования

Управление требованиями

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

Роли

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

Рисунок 1. Коммуникации системного аналитика

Согласно RationalUnifiedProcessв процессе сбора и управления требованиями к разрабатываемой системе участвуют системный аналитик и спецификатор требований.RUPподразумевает, что анализом бизнес - процессов и выявлением бизнес - требований занимается бизнес-аналитик.

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