Фаза начало посвящена границам проекта и его целям, подтверждению целесообразности продолжения работ.

Цель 1: Понять, что создавать.

1. Согласовать высокоуровневую Концепцию, включающую в себя:

а. Возможности и преимущества проекта.
б. Проблемы, решаемые проектом.
в. Кто является конечным пользователем.
г. Что будет делать продукт на самом высоком уровне (выражения в форме высокоуровневых свойств или обзора ключевых use case-ов).
д. Некотор. наиб. существ. нефункциональные требования: ОС, БД, треб. надежность, масштабируемость, качество и т.д.

2. Создать широкое, но неглубокое описание системы:

а. Определить и кратко описать актеров (типичные пользователи, др. системы, с которыми взаимодействует проект).
б. Определить и кратко описать use case-ы (какие актеры будут взаимодействовать с системой).

Цель 2: Выяснить ключевые функции системы. Важно решить какие варианты использования являются наиболее критичными с помощью след. критериев:

1. Функциональность является ключевой для приложения или используется ключевые интерфейсы системы. Архитектор определяет такие use case-ы путем анализа стратегии резервирования управления, рисков, стратегий безопасности данных.

2. Ф-ть обязательно д.б. реализована (она определяет суть системы).
3. Ф-ть охватывает область архитектуры, не охваченную никаким др. критичным use case-ом.

Цель 3: Выявить хотя бы одно возможное решение. Анализируя желаемую функциональность, совместимость с другими приложениями и требования к эксплуатации и поддержке, можно понять, какие из вариантов жизнеспособны.

1. Какие другие сходные системы создавали и какие технологии и архитектуру использовали? Какова была стоимость?
2. Существующая архитектура с т.з. эволюции имеющейся системы является удовлетворительной или ее нужно развивать?
3. Какие технологии будем использовать, есть ли, риски связанные с этим?
4. Какие программные компоненты требуются, можно ли их приобрести, можно ли их будет использовать в др. проекте, стоимость, риски?

Цель 4: Оценить стоимость, риски, сроки. Необходимо выяснить экономическое обоснование проекта – инструмент для получения адекватного финансирования проекта.

Цель 5: Решить какому процессу следовать и какие use-case-ы использовать. Обязательно следует упростить процесс, чтобы минимизировать ненужные накладные расходы.

Итерации:

Как правило одна, но может потребоваться и больше (1.если проект велик и команде трудно понять границы системы; 2. Система не имеет аналогов). Если итераций больше одной, то первая концентрируется на целях 1-3 (что создавать?), остальные - на 4-5 (как создавать?).