Методологии и стандарты, регламентирующие работу с требованиями
Среди основополагающих нормативных документов в области работы с требованиями можно выделить следующие.
1. Разработки IEEE:
- IEEE 1362 "Concept of Operations Document".
- IEEE 1233 "Guide for Developing System Requirements Specifications".
- IEEE Standard 830-1998, "IEEE Recommended Practice for Software Requirements Specifications"
- IEEE Standard Glossary of Software Engineering Terminology/IEEE Std 610.12-1990
- IEEE Guide to the Software Engineering Body of Knowledge (1) - SWEBOK®, 2004.
2. Отечественные ГОСТ:
- ГОСТ 34.601-90. Информационная технология. Автоматизированные системы. Стадии создания.
- ГОСТ 34.602-89. Информационная технология. Техническое задание на создание автоматизированной системы
- ГОСТ 19.201-78. Единая система программной документации. Техническое задание. Требования к содержанию и оформлению.
Свойства требований
Ф. Брукс в своем, теперь уже ставшим классическим, эссе1), следующим образом охарактеризовал роль требований в разработке программного обеспечения.
Строжайшее и единственное правило построения систем программного обеспечения (ПО) - решить точно, что же строить. Никакая другая часть концептуальной работы не является такой трудной, как выяснение деталей технических требований, в том числе и взаимодействие с людьми, с механизмами и с иными системами ПО. Никакая другая часть работы так не портит результат, если она выполнена плохо. Ошибки никакого другого этапа работы не исправляются так трудно.
Наука извлечения и формализации качественных (иногда говорят "хороших", "правильных") требований носит во многом эмпирический характер. Однако, в практике разработки программных систем накопились определенные представления о том, какими свойствами должны обладать требования к программной системе. Это:
- полнота,
- ясность,
- корректность,
- согласованность,
- верифицируемость,
- необходимость,
- полезность при эксплуатации,
- осуществимость,
- модифицируемость,
- трассируемость,
- упорядоченность по важности и стабильности,
- наличие количественной метрики.
Большинство из этих свойств раскрыто в первом разделе стандарта IEEE [3.1] и широко обсуждается в работах [3.3,3.5]. Рассмотрим указанные выше свойства подробнее.
Полнота.
Как известно из теории искусственного интеллекта, неполнота - одно из фундаментальных свойств человеческого знания. При создании программных систем нам приходится иметь дело с характеристиками еще несуществующей системы. Идея о том, что необходимо сформулировать все требования полностью, т.е. исчерпывающим образом, до начала проектирования, а тем более - реализации системы, изжила себя вместе с так называемым каскадным подходом2) [3.2], который поддерживал последовательную модель реализации системы. Спиральный3) [3.2] подход, на котором базируется большинство современных методологий, предусматривает поэтапное выделение и детализацию требований на всем протяжении цикла разработки системы.
Тем не менее, требование полноты предъявляется к требованиям, формулируемым к системе. Надо понимать, что данное требование - это скорее тенденция, цель, к которой нужно постараться максимально приблизиться на как можно более ранних стадиях проекта.
Требование полноты можно рассматривать в двух аспектах: полнота отдельного требования и полнота системы требований.
Полнота отдельного требования - свойство, означающее, что текст требования не требует дополнительной детализации, то есть в нем предусмотрены все необходимые нюансы, особенности и детали данного требования.
Полнота системы требований - свойство, означающее, что совокупность артефактов, описывающих требования, исчерпывающим образом описывает все то, что требуется от разрабатываемой системы.
Дата добавления: 2020-11-18; просмотров: 1370;