Особенности разработки
требований к ПО
«Привет, Фил, это Мария из отдела персонала. нас проблема
с системой, которую вы разрабатывали для нас. Одна из со-
трудниц изменила имя на  Спак Старлайт, а система не прини-
мает это изменение. Ты можешь помочь?»
Юна вышла замуж за парня по имени Старлайт?» 
" нет..она просто взяла другое имя, — ответила Мария. — В
этом-то и проблема. Как будто мы можем брать другое имя
только при изменении семейного положения».
" Да..я не предусмотрел такой возможности. Я не помню, чтобы
и ты говорила мне о ней, когда мы обсуждали систему. Вот по-
этому-то диалоговое окно «Изменить имя» доступно только из
окна «Изменение семейного положения», — сказал Фил.
«Я полагаю,  ты знаешь, что люди могут законным образом ме-
нять имена, когда захотят, — ответила Мария. — Мы должны исправить
это к пятнице, а то Спакл не сможет обналичить чек.
Ты сможешь исправить этот дефект к такому сроку?»
"Это не дефкт" -  резко парировал Фил. Я и не знал, что вам
нужна эта функциональность. Сейчас я занимаюсь оценкой
производительности системы. Думал  что потребуется менять что то
другое».(Шелест бумаги) да здесь есть еще кое-
что. Я, вероятно, смогу исправить это в конце месяца, но не на
этой неделе. Извини меня. Но в следующий раз с такими
просьбами звони пораньше и, пожалуйста, описывай их».
«А что же я скажу Спакл? — возмутилась Мария. — Ей придется
залезать в долги, если она не сможет обналичить чек».
«Эй, Мария, это не моя вина, — запротестовал Фил. — Если ты
не сказала мне при первом осуждении, что вам понадобится

изменять имена в любое время, этого и нет в системе. Ты не
можешь винить меня за то, что я не умею читать мысли в твоей
голове».
Сердитая и смирившаяся, Мария отрывисто сказала: «Это как
раз то, из-за чего я ненавижу компьютерные системы.
Позвони  мне, как только сможешь исправить недостаток».
Если вы когда-либо бывали в шкуре клиента на переговорах, подобных
этому, то знаете, как расстраиваются пользователи продукта  кото-
рый не позволяет выполнять основные задачи. Разработчики испытывают
 чувство разочарования, когда узнают о функциональности, кото-
рую пользователи ожидали получить, только после развертывания сис-
темы. Точно также раздражает, если приходится прерывать работу
за необходимости модифицировать систему, так как она не выполняет
те задачи о которых вы говорили еще в самом начале разработки.
Масса проблем с ПО возникает из-за несовершенства способов
которые люди применяют для сбора, документирования, согласования
и модификации требований к ПО. Как в случае с Филом и Марией,
проблемы могут возникать из-за неформального сбора информации
предполагаемой функциональности, ошибочных или несогласованных
предположений, недостаточно определенныхтребований и бессистем-
ного изменения процесса.
Большинство людей при строительстве дома даже не интересуются
подрядчиками, пока в полном объеме не обсудят свои потребности и
желания и не уточнят все детали. Покупатели понимают, что внесение
изменений влечет за собой изменение цены; им это не нравится, но
они это понимают. Однако люди весело ищут оправдания, когда дело
касается разработки ПО. Ошибки, допущенные на стадии сбора требо-
ваний, составляют от 40 до 60% всех дефектов проекта (Davis, 1993;
1997). Две наиболее распространенные проблемы, о
рых сообщается в большом Европейском обзоре индустрии ПО, — оп-
ределение и управление требованиями заказчика (ESPITI,
не менее многие организации еще применяют неэффективные методы
на этих стадиях разработки ПО. Типичный исход — неожидаемые про-
белы, а также различия между тем, что разработчики собираються
строить, и тем, в чем клиенты реально нуждаются. Концепции и приемы, обсуждаемые здесь, применимы к ПО любого вида и к ПО,
элементы, которые вы строите.
Нигде более, как на стадии сбора требований, так тесно не связаны
интересы всех заинтересованных в проекте лиц с успехом проекта.
К заинтересованным в проекте лицам относятся:

1 заказчики, которые финансируют проект или приобретают продукт
для решения каких-то бизнес-задач;

2 пользователи, которые взаимодействуют напрямую или не напря-
мую с приложением (подкласс заказчиков); 

3 аналитики требований, которые пишут требования и передают их
разработчикам; 

4 разработчики, которые создают, разворачивают и поддерживают продукт

5 тестеры которые определяют соответствие поведения ПО желае-
мому;

5 технические писатели, которые отвечают за создание руководства пользователей,
тренировочные материалы и справочную систему; 

6 менеджер по проекту, который планирует процесс и руководит ко-
мандой разработчиков вплоть до успешного выпуска продукта;

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

8 производственники, которые должны построить продукт, содержа-
щий данное ПО; 

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

Хорошо справившись с этой стадией  процесса вы получите отлич-
ный продукт, восхищенных заказчиков и удовлетворенных разработчи-
ков. В противном случае вам грозит непонимание, разочарование и
разногласия, которые подрывают веру в продукт и его ценность. Так
как требования представляют собой основу для действий и разработ-
чиков и менеджеров проекта, все заинтересованные в проекте лица
должны быть вовлечены в создание этого документа.
Но разработка требований и управление ими — трудный процесс!
Здесь нет быстрых или волшебных решений. Однако многие организа-
ции борются с одними и теми же трудностями, для преодоления ко-
торых мы можем найти общие прикмы, годные в различных ситуациях.
В этой книге описаны дюжины таких приемов. Их рекламируют для по-
строения абсолютно новых систем, однако они отлично подходят для
поддержки проектов и выбора коммерческих готовых решений (см.
главу Не используйте эти приемы только для модели «водопада»,