23. Технологический процесс управления требованиями

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

• Разработчики системы вместе с заказчиками и другими заинтересованными сторонами должны выработать единое мнение о том, что должна делать система. Что и зачем!

• Разработчики должны полнее понять системные требования.

• Должны быть определены границы системы.

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

• Исходя из нужд и целей пользователей, должен быть определен пользователь­ский интерфейс системы

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

Требование — это условие или характеристика, которой должна соот­ветствовать система.

Функциональные требования

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

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

Нефункциональные требования

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

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

• Практичность

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

• Надежность

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

• Производительность

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

■ Возможность поддержки

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

Исполнители

Системный аналитик

Системный аналитик координирует процессы извлечения требований и моде­лирования прецедентов и управляет ими. Для этого он очерчивает функцио­нальные возможности системы и определяет ее область действия.

■ Спецификатор прецедентов

Спецификатор прецедентов уточняет все функциональные возможности систе­мы или их часть путем описания элементов требований одного или нескольких прецедентов.

■ Разработчик пользовательского интерфейса

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

• Управление требованиями отражает совместные усилия по установлению и поддержанию единого мнения заинтересованных сторон и команды разработ­чиков относительно того, что должна делать система.

• В типичном проекте можно рассматривать несколько типов требований, в том числе высокоуровневые свойства, а также подробные функциональные и нефункциональные требования и прецеденты.

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

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

• Инструментальные средства Rational способствуют сбору, визуальному модели­рованию требований и их атрибутов и управлению ими, а также повышают воз­можность оперативного контроля.