Инженерия требований

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

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

Инженерия требований должна начинаться с управления требованиями. Требование – это некое утверждение, относящееся к части системы. Контрольная точка – это достижение этого требования к какому-то моменту. Существует две группы требований: требования заказчика и требования разработчика. Отличаются они друг от друга степенью проработки описаний. Первичные требования документируют желания и потребности заказчика и пишутся на языке, понятном заказчику. Детальные требования документируют требования в специальной, структурированной форме, они детализированы по отношению к первичным требованиям.

СПЕЦИФИКАЦИЯ ТРЕБОВАНИЙ

• -> 1. Введение

• > 2. Полное описание                  --------------

• Требования

• 3.    Конкретные требования <--------

• разработчика

• 4.    Приложения                      _____________

Рис. 1. Интеграция требований разработчика и заказчика в единую спецификацию требований

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

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

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

• •    ясными (не допускать двоякого толкования, приводящего к искажению смысла пожеланий заказчика);

• •    согласованными (не содержать противоречивых и взаимоисключающих утверждений);

• •    полными (определять всю требуемую функциональность системы).

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

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

Различается два аспекта инженерии требований. Формулировка необходимых требований и их анализ. В процессе выявления необходимых требований компания-разработчик выясняет, что необходимо и почему. Этот процесс относится к дисциплине извлечения необходимых знаний и требует применения многих методов, относящихся к этой дисциплине. Анализ требований, с другой стороны, представляет собой процесс понимания существующих или выявленных требований. Здесь разработчик требований задается вопросами о полноте и структуре полученной информации. Это различие позволяет разделить огромный труд по разработке технических требований на две довольно различные части. Одна часть концентрирует внимание на методах получения знаний и основывается на теории влияния человеческого фактора, гуманитарных системных методах и эргономике. Вторая часть акцентирует внимание на формальных методах системного анализа. В контексте объектно-ориентированных разработок существовало несколько попыток распространить формальные теории на объектноориентированный анализ.

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

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

• •     требование отклоняется — работа с требованием прекращается;

• •     требование принимается к реализации на текущей итерации;

• •     реализация требования откладывается до следующих итераций.

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