Возможность построения сколь угодно сложных систем.

Наиболее сложные системы имеют тенденцию содержать в себе программное обеспечение, зачастую очень глубоко интегрированное в компоненты системы. Сложность таких продуктов ограничена только воображением.

Быстрое распространение.

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

Готовые (“ Off-the-shelf”) модули.

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

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

В таких условиях появляется острая необходимость в сокращении цикла разработки и времени выхода на рынок (“time to market”). Однако только лишь этот показатель - время выхода на рынок - не дает достаточного преимущества. Стратегической целью становится время выхода на рынок с «правильным» продуктом (“time to market with the right product”).

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

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

Требования являются основой для любого проекта. Они определяют те потребности «заинтересованных сторон» (stakeholders) - пользователей, потребителей, поставщиков, разработчиков и самого бизнеса, - которые являются для них необходимыми, а также тот функционал, которым система должна впоследствии обладать, чтобы удовлетворить эти потребности.

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

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

Таким образом, без относительно стабильных базовых и согласованных требований проект будет только «барахтаться на волнах». Это как отправляться в путешествие по морю, не зная конечного места назначения и не взяв с собой навигационные карты. Поэтому требования обеспечивают и «навигационные карты», и средства управления кораблем, помогая достигнуть выбранного пункта назначения.

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

Даже если проблема и ее решение определены, необходимо оценить риски, которые могут привести к провалу проекта. Редкий заказчик будет поддерживать проект без убедительной стратегии управления рисками. Организация работы с требованиями позволяет управлять рисками на самых ранних стадиях разработки. Так риск, вытекающий из определенного требования, может быть отслежен, может быть проведена оценка его влияния, вероятность его появления (реализации), и, как следствие, может быть разработан предварительный план по предотвращению и устранению последствий этого риска. И что самое главное, - все это можно выполнить задолго до того, как возникнет необходимость соответствующих затрат.

Следовательно, требования являются базой для:.

• планирования проекта;.

• управления рисками;.

• приемочного тестирования;.

• компромиссов (согласований);.

• управления изменениями.

Наиболее распространенные проблемы, из-за которых «проваливаются» проекты отнюдь не технические.

В таблице 1. 1 приводятся основные причины провалов проектов. Таблица заполнена на основании данных опроса, проведенного Стэндиш Групп (Standish Group) в 1995-96 годах, и показывает процентное соотношение причин, приведших к «смерти» проектов. Точками отмечены причины связанные непосредственно с требованиями.

Перечисленные проблемы можно разделить на три основных категории:.

• Требования - плохо организованы, плохо написаны; слабо связаны с запросами и потребностями заинтересованных сторон (stakeholders); очень быстро изменяются, или изменяются без необходимости; нереалистические ожидания.

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

• Искусство управления - выражается во влиянии на первые две категории.

Все эти проблемы могут быть решены за относительно небольшую цену.

Таблица 1.1 Причины провалов проектов

Источники: Standish Group, 1995 и 1996; Scientific American, September 1994 Таблица 1.2 Факторы успехов проектов

Источники: Standish Group, 1995 и 1996; Scientific American, September 1994.

Факторы, способствующие успеху проектов, приведенные в таблице 1.2, не являются прямой противоположностью причин провальных проектов.

Постоянная поддержка руководства и правильное планирование являются очень важными факторами: чем больше проект по продолжительности и по объему, тем больше шансов провалить его (Scientific American, September 1994).

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

В книге поясняется, в чем состоят различия между требованиями заинтересованных сторон (stakeholders requirements)

и системными требованиями. Объясняется, как применять требования для управления разработкой.

В книге продемонстрировано как организация связей (traceability) - от пользовательских требований (stakeholder requirements) через системные требования (system requirements) к спецификациям системы (design) - и контроль за ними могут быть использованы для оценки развития проекта, управления изменениями и определения рисков.

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

Книга обратит ваше внимание на необходимость организации работ по проектированию (создания спецификаций (designs)) таким образом, чтобы сделать легкой последующие тестирование и интеграцию компонентов системы.

Присутствие в книге Главы 8, «Аспекты управления разработкой требований» обусловлено важностью прослеживающейся связи между управлением требованиями и управлением проектом.