pomoev.u,

По моему опыту, важно получить исходное ТЗ, чтобы у проекта была четкая цель. И еще важнее понимать, что это ТЗ наверняка получится неполным или неправильным :)

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

Поэтому те 5 пунктов годятся только для подготовки изначального ТЗ. А развитие системы скорее выглядит так:
1. Аналитик захотел странного, например, у клиента раньше был один домашний адрес, а стало много
2. Базу доработали под новое требование. Количество переписанных запросов должно быть минимально, приложения ВООБЩЕ не должны пострадать.
3. если у клиента стало много адресов, значит это кому-нибудь нужно. Интерфейс доступа к данным дорабатывается таким образом, чтобы он мог возвращать много адресов и при этом не ломал существующих клиентов. Потом дорабатываются приложения, которым эти много адресов интересны. Потом, опционально, на новый интерфейс переводятся остальные приложения.