Практика

3.11 Функциональные требования и информационная архитектура

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

Функциональные требования

Разрабатываемая система должна:

  • обеспечивать безопасный и авторизованный доступ к своим сервисам;
  • помогать новичкам знакомиться с возможностями системы;
  • помнить информацию о следующих предпочтениях пользователей:
    • параметры авторизации,
    • используемые каналы для оповещений,
    • способы и пункты оплаты;
  • информировать пользователя о текущем состоянии счета;
  • прогнозировать с заданной точностью дату списания последних средств со счета и отключения услуг связи;
  • пополнять счет в долг (совершать обещанный платеж);
  • дистанционно информировать пользователя:
    • о приближении средств на счете к заданной отметке,
    • об успешном совершении автоматического платежа,
    • о невозможность совершить автоматический платеж,
    • о пополнении счета в ручном режиме,
    • о текущем состоянии счета (по запросу);
  • сообщать о недоступности или неработоспособности привычных пунктов платежей и предлагать альтернативные варианты;
  • позволять пользователю остановить оказание услуг связи на определенный период с последующим возвращением в нормальный режим работы.

Превращаем выявленные функциональные требования в информационную архитектуру.

Информационная архитектура

1. Авторизация

  • логотип,
  • форма авторизации,
  • ссылки на главный сайт провайдера.

2. Сервисы

  • номер договора,
  • баланс счета + дата следующего платежа,
  • список выбранных способов оплаты + форма добавления внешнего счета,
  • форма совершения обещанного платежа,
  • карта с информацией о пунктах приема платежей,
  • форма блокировки оказания услуг на определенный период,
  • форма настроек каналов оповещения.

Данная информационная архитектура не окончательная и будет итеративно уточняться параллельно с созданием прототипа.

Реклама
Стандартный

3 ответ. на "3.11 Функциональные требования и информационная архитектура"

  1. Есть подход в проектировании информационной архитектуры и функциональных возможностей сайта одновременно — проектирование через URL.

    Берешь и описываешь карту всех возможных путей для сайта, например приложение «блог»

    /blog/ — все записи блога
    /blog/tags/ — все теги блога (по алфавиту)
    /blog/tags/php/ — записи блога с тегом «php»

    и так далее.

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

    • Да, Никита, метод неплохой, но слишком программерский :). Он сразу предлагает нам думать над урлами, а это — особенности и детали реализации.

      На данном же этапе пока рано обдумывать такие детали, как урлы или внутренняя архитектура серверного кода. Это может сбивать с правильного пути проектирования. Детализация должна происходить постепенно.

      Впереди еще только прототип.

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход /  Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход /  Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход /  Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход /  Изменить )

Connecting to %s