Ограничения

К требованиям данного типа относятся технические ограничения и бизнес-правила. Технические ограничения (constraints) касаются выбора возможности разработки внешнего вида и структуры продукта, используемых языков программирования, технологий и платформ. Бизнес-правила (business rules) включают корпоративные политики, правительственные постановления, промышленные стандарты и вычислительные алгоритмы. Бизнес-правила не являются требованиями к программному обеспечению, потому что они находятся вне границ любой системы. Однако они часто налагают ограничения, определяя, кто может выполнять конкретные требования, или какими функциями должна обладать система, подчиняющаяся соответствующим правилам. Иногда бизнес-правила становятся источником атрибутов качества, которые реализуются в функциональности. Следовательно, можно отследить происхождение конкретных функциональных требований вплоть до соответствующих им бизнес-правил.

Иерархия требований

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

Для отслеживания зависимости требований разных типов друг от друга и прослеживания изменений требований используется понятие трассировки требований. Обычно трассировка требований применяется для того, чтобы показать связь различных типов требований. На рисунке 2 представлена иерархия описанных ранее типов требований со связями трассировки между ними:

Рис 2. Иерархия требований

Стоимость ошибок в требованиях

Цель разработки программного обеспечения состоит в том, чтобы, уложившись в отведенное время и бюджет, разработать качественное программное обеспечение. В большинстве случаев, успех проекта зависит от хорошо организованного процесса разработки и управления требованиями. Ошибки в требованиях являются наиболее встречающимся типом ошибок при разработке систем, а их идентификация и устранение являются наиболее дорогостоящими.

Исследования Standish Group от 1994 года говорит о следующем:

“В США ежегодно тратиться более 250 миллиардов долларов на разработку приложений информационных технологий в рамках примерно 175000 проектов. Средняя стоимость проекта для крупных компаний составляет 2,3 миллиона долларов, для средних - 1,3 миллиона долларов, а для небольших - 430 тысяч долларов”

Исследования Standish Group покали, что 31% проектов будет прекращен до завершения. Затраты на 52,7 % проектов составляют 189% от первоначальной оценки.

Исходя из этого, исследователи Standish Group показали, что американские компании и правительственные учреждения потратят 81 миллиард долларов на программные проекты, которые так и не будут завершены. Эти же организации заплатят дополнительно 59 миллиардов долларов за программные проекты, которые хотя и завершатся, но значительно превысят первоначально отведенное на них время.

К наиболее часто встречающимся факторам, создающим «проблемы» в программных проектах, относятся следующие:

• Недостаток исходной информации от клиента: 13% проектов

• Неполные требования и документы требований: 12% проектов

• Изменение требований и документов требований: 12% проектов.

• Несоответствия технологических навыков: 7% проектов

• Неправильный подбор персонала и выделение ресурсов: 6% проектов

• Нереалистичное составление графиков и планирование времени: 4% проектов

• Другое

Напротив, наиболее важными факторами успеха проектов были выделены следующие:

• Подключение к разработке пользователей: 16% успешных проектов

• Поддержка со стороны исполнительного руководства: 14 %

• Ясная постановка требований: 12%

Европейская инициатива по обучению и совершенствованию процесса программирования (ESPITI) в 1995 году провела исследования и подтвердила результаты StandishGroup. Выявленные ESPITI проблемы в разработке программного обеспечения представлены на рис. 3:

Рис 3. Проблемы разработки программного обеспечения

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

В таблице 1 представлены результаты исследования, проведенного в 1994 году Каперсом Джонсом [1], и в ней приводятся данные о вероятном количестве возможных дефектов и средней эффективности их устранения разработчиками, посредством тестирования, контроля и других методов.

Таблица 1 - Характеристика дефектов

Источник дефектов	Вероятность возникновения	Эффективность устранения	Оставшиеся дефекты
Требования	20%	77%	0,23
Проектирование	25%	85%	0,19
Кодирование	35%	95%	0,09
Документация	12%	80%	0,12
Неправильное внедрение	8%	70%	0,12
В целом	100%	85%	0,75

Ошибки требований занимают первое место среди оставшихся дефектов и составляют примерно одну треть всех оставшихся дефектов, следовательно, ошибки в требованиях - наиболее распространенная категория ошибок при разработке программного обеспечения.

Исследования последних лет показали, что успешные компании тратят на разработку требований 28% своих ресурсов и 38,5% человеко-часов.

Европейское исследование показало, что компании, которые тратят вдвое больше усилий на разработку требований, чем остальные (а среднее значение по индустрии - 14%), разрабатывают продукт быстрее.

Результаты исследований в области оценки стоимости ошибок, возникающих на разных этапах жизненного цикла, приведены на рис 4:

Рис 4. Стоимость устранения ошибок

Из представленного рисунка видим, что при обнаружении ошибок на стадии формирования требований получаем экономию средств в соотношении 200:1 по сравнению с их обнаружением на стадии поддержки.

Эксперты в области разработки программного обеспечения утверждают, что переделывание ошибок в требованиях может обойтись в 25-40% общего бюджета проекта и 70-85% бюджета переделок. В таблице 2 приведен пример переделывания программного проекта [1], подтверждающий данные цифры.

«Представьте приложение, в котором 50000 строк кода. Оно разрабатывается командой из шести программистов, одного руководителя проекта, двух инженеров по тестированию и одного аудитора качества. Для определения сроков разработки предположим, что написание кода - это критический путь (и это верно для большинства проектов). Исходя из продуктивности 350 строк отлаженного кода в месяц, расчетное время разработки составит 24 месяца: т.е. 50000 строк, 350 строк/месяц, 6 человек. При затратах в 10000 долларов на каждого участника разработки в месяц, общий бюджет проекта составит порядка 2,4 миллиона долларов. При такой стоимости, даже если в лучшем случае 30% бюджета проекта будет потрачено на переписывание кода, то цена переделывания составит 720 тысяч долларов. Если 70% от суммы тратиться на устранение ошибок, возникших при составлении требований, то их суммарная стоимость составит больше 500 тысяч долларов».

Таблица 2 - Пример стоимости исправления ошибок

Критерий	Значение
Количество строк кода	50,000
Число разработчиков	6
Человеко-месяцы написания кода	142.9
Время готовности продукта	24 месяца
Затраты на работника в месяц	$10,000
Общая стоимость разработки	$2,400,000
Общая стоимость переделывания (30%)	$720,000
Общая стоимость устранения ошибок ТЗ (≈»70%)	$504,000

В таблице 3 представлены примеры коэффициентов возврата инвестиций при различной эффективности управления требованиями.

Таблица 3 - Коэффициенты возврата инвестиций при снижении ошибок в требованиях

Критерий	Вариант 1	Вариант 2	Вариант 3
Снижение кол-ва ошибок в требованиях (%)	10%	20%	40%
Экономия средств в типовом проекте	$50400	$100800	$201600
Сокращение сроков готовности (месяцы)	1.0	1.7	2.5
Время возврата инвестиций (месяцы)	9.5	4.7	2.4
Окупаемость инвестиций в Первом проекте (%)	153%	407%	913%

Хотя приведенные статистические данные относятся к девяностым годам двадцатого столетия, данная информация остается актуальной и на сегодняшний день. В связи с бурным развитием информационных технологий в Российской Федерации, проблемы, с которыми столкнулись в девяностых годах иностранные компании, сегодня встречаются в большинстве отечественных проектов по разработке программного обеспечения.

Предоставленная информация, еще раз подтверждает важность управления требованиями в процессе разработки программного обеспечения. Для того чтобы избежать подобных ошибок, надо научиться создавать «качественные», безошибочные требования.