Анализ требований при проектировании порталов

Мне нравится проектировать порталы. Я всегда с удовольствием берусь за такие проекты. Мне они интересны тем, что, как правило, создание портала сопряжено с решением разнородных технических задач (таких, как интеграция, управление контентом, публикация, UXD, реализация workflow и т.п.).

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

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

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

Различие этих типов заключается в технической реализации их публикации.

Статический и периодически обновляемый контент требует использования CMS, поскольку механизмы управления и публикации этого контента будут одинаковы для всех бизнес-доменов / потребностей.

Динамический контент подразумевает необходимость интеграции, логика его формирования и публикации будет уникальна для каждой потребности. Сервисы — это про реализацию полноценных интерфейсов «действие — отклик», что тоже подразумевает уникальную проработку и интеграцию со смежными системами в случае каждой потребности.

Соответственно разработка требований к порталу сводится к решению следующих задач:

• Определение требований к содержанию портала — какую информацию портал должен содержать для каждого бизнес-домена. На этом этапе не критично разделение на страницы и т.п. Важно структурирование информации по бизнес-смыслу. И важно понимание, откуда будет браться информация — вводиться пользователями или формироваться динамически из внешних источников. В результате должна быть получен граф, показывающий структуру публикуемой информации. 
• Если проектируемый портал — реально портал, с виджетами, то на основе структуры публикуемой информации определяем состав библиотеки виджетов.
• Определение схемы навигации портала (разделы — подразделы — страницы). Исходя из структуры публикуемой информации разрабатывается схема навигации портала. При этом делается маппинг структуры информации на схему навигации. А затем мапаем виджеты на страницы. Также можно выделить шаблоны типовых страниц.
• Классификация виджетов по типу публикации контента (см. список выше).

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

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

Разработка требований к сервиам — классическая задача системного анализа. В этом случае каждый виджет — уникальный компонент.

С учетом всего выше сказанного в целом процесс проектирования портала обретает следующий вид: