Лекция 8

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

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

Пример
ТРЕБОВАНИЯ ЗАКАЗЧИКА
1. ПО должно обеспечить средства для ввода и сохранения разнообразных данных
абонента-пользователя.
ТРЕБОВАНИЯ РАЗРАБОТЧИКА
1.1. Пользователь должен иметь возможность определять тип вводимых данных.
1.2. Для каждого типа данных должно иметься соответствующее средство, обеспечивающее ввод и сохранение элемента данных этого типа.

Пример
1.3. Каждый тип данных должен представляться соответствующей пиктограммой на дисплее пользователя.
1.4. Пользователю должна предлагаться пиктограмма для каждого типа данных. Кроме
того, должна предлагаться возможность самостоятельного выбора пиктограммы для
каждого типа данных.
1.5. При выборе пользователем пиктограммы типа данных к элементу данных должно
быть применено средство, ассоциированное с указанным типом.

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

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

Виды требований
Функциональные требования. Они описывают поведение системы и сервисы (функции), которые она должна выполнять.
Нефункциональные требования. Эти требования относятся к характеристикам
системы и ее внешнего окружения.

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

Нефункциональные требований
Группы:
Требования к программной системе. Описывают свойства и характеристики системы.
Организационные требования. Отображают вопросы работы и организации взаимодействия заказчика и разработчика.
Внешние требования. Учитывают факторы внешней среды.

Формирование требований
Шаг 1. Определение представителей заказчика.
Шаг 2. Проведение опроса представителей заказчика.
Шаг 3. Документирование результатов опроса.
Шаг 4. Проверка требований.

Проверка требований
1) предметная область проекта описана корректно;
2) разработчик и заказчик имеют одинаковые представления о целях системы;
З) анализ внешней среды и риска разработки подтверждает возможность создания
системы;

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

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

Анализ требований
Шаг 1. Организация первичных требований.
Шаг 2. Преобразование первичных требований в детальные требования.
Шаг З. Аттестация детальных требований.

Желаемые характеристики детального требования
Прослеживание.

Желаемые характеристики детального требования
Тестируемость.
Однозначность.
Приоритетность.
Полнота.
Согласованность.

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

Выгоды
Создать основу для соглашения между заказчиками и разработчиками по поводу функций, которые должен выполнять программный продукт.
Уменьшить объем работ по разработке.
Обеспечить основу для оценки расходов и графиков работ.
Обеспечить основу для аттестации (валидации) и верификации.
Облегчить передачу пользователям.
Служить в качестве основы для расширения.

Управление требованиями
Нужно решить следующие вопросы:
Распознавание и учет требований.
Управление внесением изменений.
Стратегия трассировки.