Полнота.

Предмет: Разработка и эксплуатация АИС.

Лекция 4.

Для студентов гр. АСУ 4-го курса.

Тема: Свойства требований и

роль требований в разработке программного обеспечения.

Цель: Разобраться в особенностях требований, свойствах требований.

1. Прочитать, кратко законспектировать лекцию.

2. Составить 20 (или более) вопросов к лекции по основным моментам, и на них же самостоятельно ответить.

3. Сделать выводы.

4.Отправить вопросы с ответами в электронном варианте преподавателю

Свойства требований

Ф. Брукс в своем, теперь уже ставшим классическим, эссе, следующим образом охарактеризовал роль требований в разработке программного обеспечения.

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

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

· полнота,

· ясность,

· корректность,

· согласованность,

· верифицируемость,

· необходимость,

· полезность при эксплуатации,

· осуществимость,

· модифицируемость,

· трассируемость,

· упорядоченность по важности и стабильности,

· наличие количественной метрики.

Большинство из этих свойств раскрыто в первом разделе стандарта IEEE и широко обсуждается в работах. Рассмотрим указанные выше свойства подробнее.

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

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

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

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

Полнота системы требований - свойство, означающее, что совокупность артефактов, описывающих требования, исчерпывающим образом описывает все то, что требуется от разрабатываемой системы.