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

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

-- некоторые характеристики великолепных требований.

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

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

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

 

 

Одна из  проблем существующих в индустрии программного обеспе-
чения, — это отсутствие общепринятых определений терминов, кото-
рыми мы пользуемся для описания нашей работы. Разные эксперты,
говоря об одном и том же документе, называют его и требования поль-
зователя, и требования к ПО, и функциональные требования, и сис-
темные требования, и технологические требования, и бизнес-требова-
ния, и требования к продукту. Заказчики зачастую считают, что требо-
вания -- это развитая концепция продукта, предназначенная для
разработчиков. Те, в свою очередь, полагают, что в отношении клиен-
тов это детальная разработка интерфейса пользователя. Такое много-
образие ведет к сумятице и раздражающим проблемам коммуникации.
Основной закон: требования должны быть документированы. Одна-
жды я занимался проектом, который делала опытнейшая команда, од-
нако ее состав постоянно менялся. Заказчик впал в неистовство, когда
к нему пришел еще один аналитик требований и сказал: «Мы должны
поговорить о том, что же вам нужно». На что заказчик ответил: «Я уже
излагал свои требования. А теперь постройте мне систему!» Дело в
том, что никто не документировал собранную информацию, поэтому
каждому новому аналитику приходилось начинать с набросков. Пол-
ный бред объявлять о готовности требований, если на самом деле у
вас куча электронных писем, голосовых сообщений,  записок, про-
токолов совещаний и неясных воспоминаний о беседах в коридоре.

Консультант Brian Lawrence предположил, что требования — это «неч-
то такое, что приводит к выбору дизайна" (Lawrence, 1997). Многие
категории информации попадают в эту категорию. IEEE Standard
sary of Software Engineering Terminology определяет требования
как:
1.условия или возможности, необходимые пользователю для реше
ния проблем или достижения целей;
2. условия или возможности, которыми должна обладать система или
системные компоненты, чтобы выполнить контракт или удовлетво-
рять стандартам, спецификациям или другим формальным доку-
ментам;
3.документированное представление условий или возможностей для
пунктов 1 и 2.