Разумеется, на практике некоторая работа по получению или классификации требований для компонентов системы может выполняться еще и до окончательного согласования входящих требований и принятия стратегии их проверки. Однако эта работа не может считаться завершенной до получения окончательно согласованных входящих требований и стратегии проверки для них.
Следует отметить, что при получении требований для компонентов системы необходимо выполнить определенную дополнительную работу - установить связи типа «удовлетворяет/удовлетворяется» между входящими и производными требованиями. Такие связи показывают: какие входящие требования удовлетворяются какими производными требованиями, что может быть использовано для утверждения того, что:.
• все входящие требования удовлетворены;.
• все производные требования необходимы (т.е. они прямо или косвенно удовлетворяют.
одно или более входящих требований).
Рис. 2.13 Процесс получения требований и стратегии проверки.
При этом абсолютно недостаточно убедиться лишь в самом факте наличия связей типа «удовлетворяет/удовлетворяется», например, при помощи матрицы связей.
Здесь важно, чтобы для каждой из этих связей заранее устанавливалось собственное обоснование - некий мотивирующий аргумент.
Очевидно, что в процессе получения требований из моделей, в последних могут обнаружиться либо пробелы, либо ошибки. Такие случаи ведут к генерации запросов на изменение, поступающих (возвращающихся) к командам, разработавшим ту или иную модель. Соответствующая команда будет вынуждена либо скорректировать непосредственно модель, либо запросить уточняющие разъяснения, либо направить запрос на изменение входящего требования. Таким образом, процесс эскалации запроса на изменение может продолжаться.
Получение стратегии проверки.
Как обсуждалось выше, связи типа «удовлетворяет/удовлетворяется» отражают процесс получения производных требований из входящих требований - спецификацию системы. В отличие от этого, стратегия проверки определяет план того, как каждое требование будет тестироваться на каждом уровне.
Стратегия проверки состоит из набора проверочных мероприятий, каждое из которых может быть определенного вида исследованием, тестом или инспекцией. Возможно даже, что несколько проверочных мероприятий будут разработаны для проверки лишь одного требования.
Каждое проверочное мероприятие должно подразумевать следующие аспекты:.
• тип мероприятия, который должен соответствовать требованию;.
• фаза, на которой должно проводиться мероприятие - чем раньше, тем лучше;.
• специальное оборудование, которое может понадобиться для проведения мероприятия;.
• описание того, что будет являться успешным результатом мероприятия.
План проверки может быть структурирован исходя либо из фазы (стадии проекта), либо из типа проверочных мероприятий.
Рис. 2.14 Проверка требований.
Проверочные мероприятия должны в обязательном порядке соответствовать конкретному уровню требований. Другими словами, пользовательские требования (требования заказчика) должны служить основой для разработки программы приемочных исследований и испытаний. В то время как системные требования должны служить основой для разработки системных тестов, которые должны предварять опытные испытания. Таким образом, нет необходимости разрабатывать системные тесты для пользовательских требований, поскольку для пользовательских требований должны существовать полученные из них системные требования, для которых и существуют системные тесты.
Рассмотрим пример, приведенный на рис. 2.14.
Системные требования для корабля разделены на два требования для разных подсистем для корпуса и силовой установки. Соответственно, два различных теста запланированы для требования на системном уровне, и два других - на уровне подсистем.
Следовательно, для полного понимания того, как требования будут проверяться, необходимо наличие связей «удовлетворяющего» типа и стратегии проверки.
Нетрудно заметить, что для того, чтобы отобразить статус проверки требований высокого уровня, необходимо учитывать результаты проверки связанных требований со всех нижних уровней с помощью связей «удовлетворяющего» типа и связей «проверяющего» типа.
2.7 Заключение.
В этой главе мы рассмотрели общий процесс разработки требований, который одновременно применяется на каждом уровне разработки системы. Основным преимуществом общего процесса является то, что он определяет общие действия, характерные для каждого уровня:.
• согласование входящих требований с заказчиком;.
• анализ входящих требований для определения рисков и потенциальных проблем, связанных с удовлетворением требований;.
• создание одной или нескольких моделей для исследования возможных стратегий получения последующих требований;.
• формирование требований, полученных из входящих требований при помощи результатов анализа и моделирования;.
• согласование производных требований с командой (командами) сотрудников, ответственных за их реализацию;.
• установление связей «удовлетворяющего» типа между входящими и производными требованиями;.
• установление связей «проверяющего» типа между производными требованиями и соответствующей стратегией проверки.
Все эти действия приводят к организации информации таким образом, как она была описана в информационной модели общего процесса. Текущее состояние информации используется для измерения прогресса в работе, оценки влияния предлагаемых изменений и определения показателей выполнения проекта.
Например, состояние требования может характеризоваться его тремя атрибутами (свойствами):.
• согласование;.
• удовлетворение;.
• проверяемость.
Идеальное состояние любого требования в любой системе заключается в том, что это требование:.
• согласовано между заказчиком и исполнителем;.
• имеет согласованную стратегию его проверки;.
• удовлетворяется требованиями более низкого уровня (или спецификацией системы).
Степень отклонения состояния каждого из требований от этого идеального статуса характеризует величину риска, которому подвергается проект с точки зрения управления требованиями, и, в тоже время, отражает объем работы, который необходимо выполнить для того, чтобы привести все требования к идеальному состоянию.