Процесс работы над требованиями

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

Пожалуй, надо всё сказанное ранее систематизировать.

Процесс разработки требований на основе спецификаций

На схеме ниже представлена часть процесса разработки ПО (да-да, это не BPMN, и даже не activity), касающаяся работы с требованиями при использовании спецификаций. 

А где же спецификация? Да их тут целых две! И называются они Технические требования и Техническое задание. Впрочем, первого может и не быть, если с концепцией реализации всё понятно.

Обратите внимание, что спека всегда отвечает на два вопроса:

1. Что должно быть реализовано в системе?

2. Как должен быть организован процесс реализации?

Это полностью в духе ГОСТ 34.

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

1. Как будет реализована система?

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

Конечная оценка проекта (согласно Стиву Макконнеллу) даётся с точностью всего лишь 30% даже после детального проектирования. Не густо.

Процесс разработки требований на основе модели сценариев

На следующем рисунке я привёл аналогичную схему, но при использовании модели сценариев использования (по сути, тут приведена схема процесса, выходящего на архитектурную модель Крухтена "4+1"). 

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

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

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

Если модель применяется в рамках гибкой методологии, то точность оценок в рамках спринта может быть ощутимо выше того, что дал бы технический проект в "водопаде"