Получение требований и стратегии проверки

из "Разработка и управление требованиями "

Существует множество различных вариантов использования моделей в целях получения требований. Однако простейший случай, который можно рассматривать как базовый, - это получение требований к компонентам на основании архитектуры системы. В этом случае появляется возможность определить, какие именно требования должны быть удовлетворены каждым из компонентов системы. Некоторые из требований для компонентов системы могут совпадать с одним или более входящими требованиями, другие же могут быть получены из входящих требований таким образом, чтобы распределить выполнение входящих требований между несколькими компонентами системы. Другой набор требований может быть порождением ограничений, накладываемых архитектурой системы или самими входящими требованиями. Этими ограничениями могут быть ограничения конкретных интерфейсов, возможные физические ограничения, такие как масса, объем, потребляемая электрическая мощность, теплоотдача и т.д. [c.45]
Разумеется, на практике некоторая работа по получению или классификации требований для компонентов системы может выполняться еще и до окончательного согласования входящих требований и принятия стратегии их проверки. Однако эта работа не может считаться завершенной до получения окончательно согласованных входящих требований и стратегии проверки для них. [c.45]
При этом абсолютно недостаточно убедиться лишь в самом факте наличия связей типа удовлетворяет/удовлетворяется , например, при помощи матрицы связей. Здесь важно, чтобы для каждой из этих связей заранее устанавливалось собственное обоснование - некий мотивирующий аргумент. [c.46]
Очевидно, что в процессе получения требований из моделей, в последних могут обнаружиться либо пробелы, либо ошибки. Такие случаи ведут к генерации запросов на изменение, поступающих (возвращающихся) к командам, разработавшим ту или иную модель. Соответствующая команда будет вынуждена либо скорректировать непосредственно модель, либо запросить уточняющие разъяснения, либо направить запрос на изменение входящего требования. Таким образом, процесс эскалации запроса на изменение может продолжаться. [c.46]
Как обсуждалось выше, связи типа удовлетворяет/удовлетворяется отражают процесс получения производных требований из входящих требований - спецификацию системы. В отличие от этого, стратегия проверки определяет план того, как каждое требование будет тестироваться на каждом уровне. [c.46]
Стратегия проверки состоит из набора проверочных мероприятий, каждое из которых может быть определенного вида исследованием, тестом или инспекцией. Возможно даже, что несколько проверочных мероприятий будут разработаны для проверки лишь одного требования. [c.46]
План проверки может быть структурирован исходя либо из фазы (стадии проекта), либо типа проверочных мероприятий. [c.47]
Системные требования для корабля разделены на два требования для разных подсистем -для корпуса и силовой установки. Соответственно, два различных теста запланированы для требования на системном уровне, и два других - на уровне подсистем. [c.48]
Следовательно, для полного понимания того, как требования будут проверяться, необходимо наличие связей удовлетворяющего типа и стратегии проверки. Нетрудно заметить, что для того, чтобы отобразить статус проверки требований высокого уровня, необходимо учитывать результаты проверки связанных требований со всех нижних уровней с помощью связей удовлетворяющего типа и связей проверяющего типа. [c.48]
Степень отклонения состояния каждого из требований от этого идеального статуса характеризует величину риска, которому подвергается проект с точки зрения управления требованиями, и, в тоже время, отражает объем работы, который необходимо выполнить для того, чтобы привести все требования к идеальному состоянию. [c.49]

Вернуться к основной статье