Исходя из сценариев взаимодействия персонажей с вымышленной и идеальной биллинговой системой, можно составить перечень требований к функциональному и информационному обеспечениям.
Функциональные требования
Разрабатываемая система должна:
- обеспечивать безопасный и авторизованный доступ к своим сервисам;
- помогать новичкам знакомиться с возможностями системы;
- помнить информацию о следующих предпочтениях пользователей:
- параметры авторизации,
- используемые каналы для оповещений,
- способы и пункты оплаты;
- информировать пользователя о текущем состоянии счета;
- прогнозировать с заданной точностью дату списания последних средств со счета и отключения услуг связи;
- пополнять счет в долг (совершать обещанный платеж);
- дистанционно информировать пользователя:
- о приближении средств на счете к заданной отметке,
- об успешном совершении автоматического платежа,
- о невозможность совершить автоматический платеж,
- о пополнении счета в ручном режиме,
- о текущем состоянии счета (по запросу);
- сообщать о недоступности или неработоспособности привычных пунктов платежей и предлагать альтернативные варианты;
- позволять пользователю остановить оказание услуг связи на определенный период с последующим возвращением в нормальный режим работы.
Превращаем выявленные функциональные требования в информационную архитектуру.
Информационная архитектура
1. Авторизация
- логотип,
- форма авторизации,
- ссылки на главный сайт провайдера.
2. Сервисы
- номер договора,
- баланс счета + дата следующего платежа,
- список выбранных способов оплаты + форма добавления внешнего счета,
- форма совершения обещанного платежа,
- карта с информацией о пунктах приема платежей,
- форма блокировки оказания услуг на определенный период,
- форма настроек каналов оповещения.
Данная информационная архитектура не окончательная и будет итеративно уточняться параллельно с созданием прототипа.
PEREDELKA 
Есть подход в проектировании информационной архитектуры и функциональных возможностей сайта одновременно — проектирование через URL.
Берешь и описываешь карту всех возможных путей для сайта, например приложение «блог»
/blog/ — все записи блога
/blog/tags/ — все теги блога (по алфавиту)
/blog/tags/php/ — записи блога с тегом «php»
и так далее.
Сразу видна иерархия приложения, зависимости и необходимые затраты для разработки.
Да, Никита, метод неплохой, но слишком программерский :). Он сразу предлагает нам думать над урлами, а это — особенности и детали реализации.
На данном же этапе пока рано обдумывать такие детали, как урлы или внутренняя архитектура серверного кода. Это может сбивать с правильного пути проектирования. Детализация должна происходить постепенно.
Впереди еще только прототип.
ну и где??