Разработка требований к программному обеспечению

Изобретательный бизнес-аналитик всегда найдет способ применить свой опыт, каким бы он ни был до этого

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

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

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

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

Неполные, несогласованные, невыполнимые или двусмысленные требования также не поддаются проверке.

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

Два вероятных виновника нереализованных ожиданий:

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

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

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

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

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

Этап определения приоритетов атрибутов служит двум целям:

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

При написании трабований преследуются две важных цели:

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

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