2.3. Выявление и анализ требований

Фаза с таким или сходным названием (чаще всего применяют термин «разработка требо­ваний») присутствует во всех известных моделях жизненного цикла. Более того, совре­менные тенденции в технологии программирования таковы, что данная фаза все чаще рас­сматривается не только как первая, но и как главная, а иногда и решающая фаза жизнен­ного цикла. Дело в том, что заметные успехи технологии программирования позволяют, при наличии адекватных требований, организовать выполнение других фаз, если и не как автоматический, то, во всяком случае, как управляемый и измеримый процесс. Другими словами, если современные программисты точно знают, что именно нужно сделать, они это, скорее всего, сделают. Верно и обратное: если требования к программному обеспече­нию не определены, или недостаточно определены, то, скорее всего, успешной разработка не будет. Об этом свидетельствует статистика, собранная при анализе проведения проек­тов — большая часть причин неуспешного выполнения конкретных проектов была квали­фицирована как ошибки или недоработки на фазе анализа требований.

2.3.1. Требования к программному обеспечению

Если мы поймем, что такое требование к программной системе, то сможем определить и то, что делается в фазе «Выявление и анализ требования». Существует большой диапазон решений этой проблемы.

• Простое решение. Понятие «требование» не определяется. Разработчик и заказчик полагаются, в этом случае, на здравый смысл. Риск такого решения определяется тем, что бизнес-цели, опыт и квалификация у заказчика и разработчика различны.

• Обычное решение. Дать какое-либо, возможно не очень точное или не очень по­нятное определение. Например,

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

Или

Требования - это высокоуровневые обобщенные утверждения о функциональных возмож­ностях и ограничениях системы.

Риск этого решения примерно такой же, как и для предыдущего случая.

• Стандартное решение. Использовать стандартное определение понятия «Требова­ние». Стандарты IEEE используют следующее определение требований.

• Функциональность, необходимая пользователю для решения проблемы или дости­жения цели.

• Функциональность, которая должна быть получена (достигнута) системой или ее компонентами для соответствия контракту, стандарту, спецификации или другим фор­мальным документам.

• Документальное представление пп. 1 - 2.

Таким образом, понятие «требование» в этом определении апеллирует либо к пользовате­лям, либо к формальным документам. В любом случае подчеркивается обязательность до­кументального представления.

Например, стандарт ГОСТ 12207 дает другое решение проблемы, в котором понятие «требование» определяется перечислением тех видов требований, которые предъявляются к программному продукту и, практически, не требуют расшифровки.

В соответствии со стандартом ГОСТ 12207 на стадии «Анализ требований» должен быть выполнен анализ требований к программным средствам. Эта работа состоит из следую­щих задач: разработчик должен установить и документально оформить следующие требования к программным средствам:

• функциональные и технические требования, включая производительность, физиче­ские характеристики и окружающие условия, под которые должен быть создан программ­ный объект;

• требования к внешним интерфейсам программного объекта;

• квалификационные требования;

• требования безопасности, включая требования, относящиеся к методам эксплуата­ции, сопровождения, воздействию окружающей среды и травмобезопасности персонала и т. д.

Всего расшифровка понятия «требования» в ГОСТ 12207 занимает несколько стра­ниц.

• Сложное решение. Проводится формализация (математическое описание) пред­метной области и требования формулируются как формальные математически строгие утверждения.

Разумеется, такие требования наилучшим образом описывают программную систему. Од­нако в промышленных технологиях программирования сложное решение применяется не часто. Дело в том, что формальные математические требования оказываются больше по объему, требуют больше трудозатрат на разработку, и требуют более высокой квалифика­ции разработчиков, чем обычное программирование. Поэтому разработка строгих матема­тических требований к программе оказывается дороже разработки самой программы, при­чем может быть даже на несколько порядков дороже. В специальных случаях приходится идти на такие затраты, но в типовом программировании для автоматизации бизнес-процессов этого не делают.