Юрий Дубровский - Живые требования – тот еще фрукт. Актуализируем и реализуем, пока не испортились

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

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

Так почему же дальше проект не всегда движется по плану и достигает намеченного результата?

Что происходит такого, что было упрощено и не продумано явно в момент подписания?

А могло ли быть иначе?

Эти вопросы и ответы на них прямо связаны с жизнью требований.

Начнем с простого представления о требованиях, которое преобладает в практике.

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

Ну, например, нужно сделать диалоговое окно с текстовым сообщением и кнопкой «ОК».

Вроде же всем все понятно? Конечно же, нет.

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

Рис.1. Возможный вид диалога со строкой текста и кнопкой « Ok »

Сформулируем требования более полно и однозначно, дополнив изображением эскиза окна.

– Необходимо вывести диалоговое окно с кнопкой «OK»

– В окне должен быть заголовок «Подтвердите действие»

– В окне должен быть текст «Ваша карточка сохранена!»

– Цвета: текста черный #000000, фона и букв на кнопке белый #FFFFFF, фона кнопки синий #0000AA.

– Шрифты: Arial – для заголовка и кнопки размер 10, для текста – 8.

– При открытии окна обработка останавливается, при нажатии «ОК» окно закрывается, обработка продолжается.

– Эскиз окна приведен на следующем рисунке, размер окна 450х140 пикселов.

Рис.2. Эскиз диалогового окна

Кажется, теперь все на месте (понятно, что можно численно задать расположение кнопки, надписи на ней и далее детализировать, но для примера нам достаточно и этого).

Раз так, требование можно фиксировать и, затем, выполнять.

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

Поставим в соответствие нашим требованиям критерии приемки и вот что получится:

1. Визуально убедиться, что:

– выведено диалоговое окно с кнопкой «OK», окно соответствует эскизу по набору и взаиморасположению компонентов (численно проконтролировать заданные параметры – размер окна 450х140 пикселов);

– заголовок «Подтвердите действие»;

– в окне текст «Ваша карточка сохранена!»;

– форматирование следующее: цвет текста черный #000000, фона и букв на кнопке белый #FFFFFF, фона кнопки синий #0000AA, шрифт: Arial – для заголовка и кнопки размер 10, для текста – 8;

2. Убедиться, что:

– при открытии окна обработка останавливается (попробовать кликнуть мышью по интерфейсу программы вне окна, не должно быть возможно);

– при нажатии «ОК» окно закрывается, обработка продолжается (попробовать кликнуть мышью по интерфейсу программы вне окна, должно быть возможно).

Такова традиционная модель: выясняем у заказчика, что нужно сделать, фиксируем, далее выполняем, проверяем результат на соответствие критериям, передаем результат заказчику.

Жизненный цикл требования состоит из его формулирования (сбора) и выполнения – это и есть простая модель требования.

Традиционная методология водопада отлично согласуется с такой моделью требования.

Поговорим об этом подробнее.

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

Традиционно для каскадной модели фазы следуют в таком порядке:

– определение требований;

– проектирование;

– конструирование;

– воплощение;

– тестирование и отладка;

– инсталляция;

– поддержка.

Переход от одной фазы к другой происходит только после полного и успешного завершения предыдущей.