Виды, взаимосвязь и свойства требований
Что такое «требование»?
Разработка программной системы начинается с того, что заказчики и разработчики должны понять, что эта система должна делать. Соответствующая стадия входит во все возможные модели жизненного цикла и называется «Разработка и анализ требований». Ключевое понятие этой стадии поименовано словом «Требование ». Если мы поймем, что такое требование к программной системе, то сможем определить и то, что понимается под разработкой и анализом «Требования ». Как же решить эту проблему?
Простое решение. Понятие «требование» не определяется. Разработчик и заказчик полагаются, в этом случае, на свой здравый смысл. Риск такого решения в том, что бизнес-цели, опыт и квалификация у заказчика и разработчика различаются.
Обычное решение. Дать какое-либо (возможно не очень точное) определение. Например, «Требование – это документированное указание потребности или цели пользователей либо условия и возможности, которым должен обладать продукт, чтобы удовлетворить такие возможности ил и цели» или «Требования – это высокоуровневые обобщенные утверждения о функциональных возможностях и ограничениях системы». Риск этого решения такой же, как и для предыдущего случая.
Правильное решение. Использовать стандартное определение понятия «Требование».
Существующие международные стандарты содержат различные определения понятия «требования», поэтому всегда можно выбрать определение, удовлетворяющее всех заинтересованных в разработке лиц.
Например, стандарты IEEE используют следующее определение требований.
Требования к программной системе – это:
1. Функциональность, необходимая пользователю для решения проблемы или достижения цели.
2. Функциональность, которая должна быть получена (достигнута) системой или ее компонентами для соответствия контракту, стандарту, спецификации или другим формальным документам.
3. Документальное представление пп. 1 – 2.
Стандарты определяют только функциональные требования, которые должны быть дополнены нефункциональными требованиями.
Другое определение дает стандарт ISO 12207, в котором понятие «требование» определяется перечислением тех видов требований, которые предъявляются к программному продукту и, практически, не требуют расшифровки. В соответствии с этим стандартом на стадии жизненного цикла «Анализ требований» должен быть выполнен анализ требований к программным средствам.
Разработчик должен установить и документально оформить следующие требования к программным средствам:
· функциональные и технические требования, включая производительность, физические характеристики и окружающие условия, под которые должен быть, создан программный объект;
· требования к внешним интерфейсам программного объекта;
· квалификационные требования;
· требования безопасности, включая требования, относящиеся к методам эксплуатации, сопровождения, воздействию окружающей среды и травмобезопасности персонала;
· и т.д.
При выборе того или иного подхода к определению понятия «Требование» заинтересованные лица должны учитывать риски, связанные с возможными различающимися интерпретациями этого понятия.
Виды требований
В литературе приводится довольно большое число классификаций требований. Требования называются функциональными и нефункциональными, пользовательскими и системными, C – требованиями и D – требованиями, требованиями к интерфейсу, к окружению и т.д. При разработке требований важно понимать разницу между требованиями, описывающими функциональность, и требованиями, определяющими дополнительные свойства системы. Кроме этого нужно учитывать уровень требований [1].
Все требования разбиваются на три уровня:
1. Бизнес-требования. Бизнес-требования определяются целями и политикой организации их высказывают те, кто финансирует проект.
2. Требования пользователей. Определяют цели и задачи, которые позволит решить система, или что пользователи смогут делать с помощью системы. Пользовательские требования должны соответствовать бизнес-требованиям в противном случае их не следует включать в проект.
3. Системные требования. Определяют функциональность и характеристики системы, которую должны построить разработчики, для того чтобы пользователи смогли выполнить свои задачи (в рамках бизнес-требований).
Полезность такого представления требований в том, что оно показывает с чего (и с кого!) нужно начинать выявление требований, кто и какого уровня может принимать решения.
Каждая система требований (бизнес-требования, требования пользователей и системные требования.) включает в себя функциональные и нефункциональные требования.
Функциональные требования
Функциональные требования определяют функции, которые выполняет система, и зависят от потребностей пользователей и типа решаемой задачи. Функциональные пользовательские требования описывают функции в обобщенном виде. Выполняя детализацию этих требований, разработчики формируют более подробное и точное описание сервисов системы – функциональные системные требования.
Особое внимание при документировании требований нужно уделить их точному описанию. Неточности в описании будут интерпретироваться пользователями и разработчиками по-разному. Такое положение приведет к разработке новых требований или изменению существующих требований, а, значит, к внесению изменений в систему и ее удорожанию.
Спецификация требований, содержащая пользовательские и системные требования должна быть комплексной и непротиворечивой. В ней должны быть определены все функции системы, и не должно быть несовместимых и взаимоисключающих определений функций.