Методологии и стандарты, регламентирующие работу с требованиями
Среди основополагающих нормативных документов в области работы с требованиями можно выделить следующие.
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] подход, на котором базируется большинство современных методологий, предусматривает поэтапное выделение и детализацию требований на всем протяжении цикла разработки системы.
|
|
|
Тем не менее, требование полноты предъявляется к требованиям, формулируемым к системе. Надо понимать, что данное требование - это скорее тенденция, цель, к которой нужно постараться максимально приблизиться на как можно более ранних стадиях проекта.
Требование полноты можно рассматривать в двух аспектах: полнота отдельного требования и полнота системы требований.
Полнота отдельного требования - свойство, означающее, что текст требования не требует дополнительной детализации, то есть в нем предусмотрены все необходимые нюансы, особенности и детали данного требования.
Полнота системы требований - свойство, означающее, что совокупность артефактов, описывающих требования, исчерпывающим образом описывает все то, что требуется от разрабатываемой системы.
Ясность (недвусмысленность, определенность, однозначность спецификаций).
Каждый из совладельцев4 разрабатываемой системы обладает своим личным опытом восприятия событий внешнего мира. Слово, произнесенное вслух, вызывает индивидуальные ассоциации в семантическом пространстве каждого отдельного воспринимающего субъекта. То, что является ясным, допустим, для кардиохирурга, совсем необязательно будет таковым для специалиста в области программной инженерии.
|
|
|
Соответственно, требование обладает свойством ясности, если оно сходным образом воспринимается всеми совладельцами системы. На практике ясность требований достигается в том числе и в процессе консультаций, в ходе которых происходит "выравнивание тезаурусов" совладельцев системы. Хорошим подспорьем в этом служит согласованный сторонами глоссарий ключевых понятий предметной области.
К.Вигерс [3.3] дает следующий совет по повышению ясности документов: "Пишите документацию просто, кратко и точно, применяя лексику, понятную пользователям".
Еще одной стороной понятия "ясность требования" является его прослеживаемость (см. также понятие трассируемости ниже по тексту). Требование, которое сформулировано ясно, может быть прослежено, начиная от того документа, где оно сформулировано впервые, вплоть до рабочих спецификаций.
Дата добавления: 2021-03-18; просмотров: 666; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!