52

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

4.2.2 Процессы работы с требованиями

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

Раздел «Извлечение (выявление) требований» освещает вопросы сбора требований с точки зрения как организации процесса, так и определения источников, откуда поступают требования. Определение заинтересованных лиц в создании ПО, выявление их служебных обязанностей, описание бизнес-процессов – все это является ключевыми вопросами, без четкого и однозначного ответа на которые даже не стоит думать об успешности проекта.

Один из ключевых принципов программной инженерии заключается в обеспечении взаимодействия между пользователями и разработчиками. Прежде всего, специалисты «по требованиям» – системные аналитики определяют способы коммуникаций и взаимопонимания между заказчиками и исполнителями, которые необходимы для решения задач проекта. Далее необходимо идентифицировать все возможные источники требований, значимые для решения задач проекта (описание функциональных обязанностей, должностных инструкций, договоров, материалов аналитиков по задачам и функциям системы и т. д.). Идентифицировав источники требований, необходимо перейти к сбору требований с использованием методов: дерева целей, анкетирования, разработки сценариев, интервьюирования и т. д.

53

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

Анализ требований включает:

1)процессы изучения потребностей и целей пользователей;

2)классификацию требований и их преобразование к требованиям программного обеспечения и общесистемному аппаратно-программному обеспечению;

3)установление и разрешение конфликтов между требованиями;

4)определение приоритетов требований с точки зрения их внешней согласованности со средой функционирования, внутренней согласованности между программными элементами, тестируемости, реализуемо-

сти в составе программного проекта, влияния на процессы функционирования и сопровождения ПП.

Результаты этапа отражаются в специальном документе – техническом задании. Именно этот документ будет определять технические спецификации программного продукта, его функциональность и требования к эксплуатационным характеристикам. Любая ошибка или любое упущение, допущенные при разработке ТЗ, приводят к дополнительным затратам на исправление или доработку готового программного продукта.

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

Проверка (аттестация) требований. Аттестация требований – это про-

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

54

будущего ПО, анализ масштабов изменения требований, измерение объема функциональности, трудозатрат и стоимости.

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

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

На основании требований к ПП разрабатывается подробное техническое задание (ТЗ). Именно этот документ будет определять технические спецификации программного продукта, его функциональность и требования к эксплуатационным характеристикам. Любая ошибка или любое упущение, допущенные при разработке ТЗ, приводят к дополнительным затратам на исправление или доработку готового программного продукта.