Пример ТЗ. Лендинговая страница кредитной карты

Очередной раз попалось задание из вакансии вида "Системный аналитик". Выкладываю сюда свое решение.

Задание: Нужно написать ТЗ (функциональные требования) на разработку лендинговой страницы по продаже премиальной кредитной банковской карты банка Х. Техническую часть (например, используемый движок) описывать необязательно, структуру страницы можно выбрать по своему усмотрению.
На выходе мы ожидаем получить:
Функциональные и бизнес требования к странице в виде законченного документа (формат не имеет значения).
Список вопросов, которые вы бы задали заказчику при встрече.
Допущения, которые были вами сделаны (если таковые были).
Любые прочие соображения, предложения или идеи.

Решение:
Документ начинаем с описания самого документа. О чем он вообще. Всего пара фраз, но она поможет нам в будущем, когда вдруг придется вернуться к документу. И новым людям, которые с мороза придут читать документ.

Общее описание

Документ описывает функциональные требования на разработку лендинговой страницы по продаже премиальной кредитной карты банка на букву Х.

Далее в документе делаем раздел "Обоснование", где указываем текущую ситуацию и проблему, которую надо решить. То есть, должно быть понятно, зачем мы вообще городим этот огород с ИТ-системой.
Вместо проблемы может быть описан вызов, который надо принять. Например, новые возможности для зарабатывания денег на рынке.
Обычно этот раздел пишется со слов спонсора - то есть того человека, который заказывает музыку и оплачивает разработку. Если это не заказная разработка, то спонсор - это тот человек, который принимает решение о выделение ресурсов на проект.

Обоснование

В банке Х есть продукт - премиальная кредитная карта. В данный момент она
распространяется в оффлайне через отделения банка и через партнеров. По предположению
маркетологов карта может быть интересна интернет-пользователям. Отдел маркетинга
проведет рекламную кампанию в интернете. Реклама будет вести на лендинговую страницу.
Требуется проверить гипотезу, что через интернет карту закажут как минимум 50% от
оффлайн-заказов за первый месяц.


Далее описываем заинтересованные стороны - это те люди, которые могут наступить на ногу нашей системе или же, наоборот, кому наша система может наступить на ногу. Образно говоря так :).
Желательно описывать роль в проекте, конкретного человека, интересы роли и можно тут же добавлять вопросы и ответы. Но главное соотнести интересы с ролями. Это поможет при определении приоритетов разработки и при добавлении/удалении требований.

Заинтересованные стороны и их интересы

Роли Представители и должность Интересы Вопросы/ответы
Спонсор
Заказчик
Владелец
системы
Леонтьев Валерий Яковлевич, руководитель отдела маркетинга Силами ~5 человек за 2 недели запустить лендинг, чтобы проверить гипотезу: продажи в интернете составят как минимум 50% от оффлайн-заказов за первый месяц. 1. Зачем вам эта страница?
2. Какие конкретно проблемы она должна решить?
3. Как вы будете оценивать, достигнуты цели или нет?
...

По ходу общения с заинтересованными сторонами возникает понимание рамок системы. То есть что наша система делает, что она не делает и с какими другими системами взаимодействует. Удобно изобразить на схеме.

Заявки передаются во внешнюю систему
1. Отчеты во внешней системе (яндекс.метрика)
2. Заявки передаются в карточную систему и систему КЦ
3. Внутри храним тексты, логотипы, правовую информацию, заявки


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

Просмотр инфо

Назначение

Предоставить пользователю информацию для оценки полезности премиальной кредитной карты

Действующее лицо:

o Пользователь

Предусловия

o Лендинговая страница запущена 🙂

Постусловия

o Пользователь ознакомился с информацией о карте

Инициирующие событие

o Пользователь заходит на веб-страницу

Основной поток

1. Система подтягивает информацию из конфигурационных файлов и отображает в браузере пользователя (см. Раздел "Перечень отображаемой информации" в Нефункциональных требованиях). В калькуляторе выставлены значения по умолчанию.
2. Поток завершается

Альтернативные потоки

1a. Пользователь нажимает "Показать больше" в разделе с партнерами.
Система выводит только перечень всех партнеров в порядке их следования в конфигурационном файле Parteners.txt
1b. Пользователь нажимает "Заказать". Начинается сценарий "Заказ карты".
1c. Пользователь нажал на логотип страницы. Система возвращает пользователя на начальный экран
1d. Пользователь изменил значения калькулятора. Система производит перерасчет.


Из сценариев рождаются функциональные требования (что делает система) и нефункциональные требования (как хорошо система делает свои функции).

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

1. Система должна проверять заполненные поля заявки на корректность.
2. Система должна иметь кнопочку "Обновить", по которой все тексты, ссылки и логотипы обновляются
3. Система должна предоставлять пользователю калькулятор.
a. Параметры и значения по умолчанию для калькулятора задаются в файле
calc.txt.
b. Параметры - "Count" (Сколько вы тратите в месяц). Далее 5 категорий, доля от общей суммы и % кэшбека. Пример:
count – 50 000
azc - 10% - 3%
travel – 15% -3%
cafe – 15% - 3%
other – 40% - 1%
partners – 20% - 1%
c. При отображении в интерфейсе названия категорий подтягиваются из файла
categories.csv.
d. При отображении суммы по категориям умножаются на % кэшбека и выводится как отдельные суммы кэшбека по категориям, так и суммарный кэшбек за месяц и за год (== 12*кэшбек за месяц).
e. При отображении в интерфейсе для каждой категории рассчитывается соответствующая сумма на основе долей. Пользователь может менять как общую сумму, так и значение суммы в каждой из 5 категорий. В первом случае пересчитываются суммы категорий на основе долей, во втором - только общая сумма. При любом изменении пересчитывается сумма кэшбека за месяц и за год.
4. Система должна генерить случайные коды для подтверждения номера. Срок действия кода - 15 минут.
5. Система должна проверять корректность капчи перед отправкой заявки от пользователя
6. Система должна проверять корректность смс-кода перед сохранением заявки

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

1. Система должна выдерживать нагрузку в 20 000 пользователей в день.
2. Система должна в пике держать 5 rps.
3. Страница должна прогружаться в 99.5% случаев за 2 сек. На ПК Intel Core i-5, 2Гб и более мощных
4. Список поддерживаемых браузеров:
Chrome от …
Mozilla от …
5. Страница должна быть адаптивной для разных разрешений и мобильных устройств (от 5")
6. Язык ввода и вывода русский, храним и передаем в кодировке utf-8
7. Система запоминает значения для неотправленных заявок в куках и выводит их при следующем поседении страницы
8. Система должна быть развернута в ДЦ в РФ
9. URI должен быть вида supercard.bankx.ru

Здесь же, в нефункиональных требованиях и макеты, и описание сущностей (на логическом уровне). Макеты, кстати, можно и раньше описывать и делать. Чуть ли не вместе с вопросами к заинтересованным лицам. Для многих людей система и интерфейс - это синонимы. И говорить про систему гораздо проще с нагляными макетами.

Перечень отображаемой информации:

• Категории и проценты кэшбека по ним. Задаются в файле categories.csv. (название
категории, проценты кэшбека). Выводятся все.
• Партнеры и проценты кэшбека по ним. Задаются в файле parnters.txt. Название партнера, ссылка на логотип, проценты кэшбека.
• Логотипы партнеров. Хранятся в папке /logos. В формате .png, не более 100Мб, разрешение до 400x400.
• Правовая информация. Условия программы карты (отдельный файл card_program.pdf).
• Правила проведения и условия акций (отдельные файлы .pdf по каждой акции) + текстовый файл actions.txt с названиями и ссылками на файлы акций.
• Согласие на обработку персональных данных (отдельный файл compliance.pdf)

В конце допущения - это уже просто для задания, как будто бы обсуждали эти моменты и пришли к каким-то соглашениям. В обычной жизни они могут быть как открытые вопросы, которые не удалось разрешить в ходе проработки ТЗ.

Допущения

1. Все обоснование построено на допущениях: В данный момент она распространяется в оффлайне через отделения банка и через партнеров. По предположению маркетологов карта может быть интересна интернет-пользователям. Отдел маркетинга проведет
рекламную кампанию в интернете. Реклама будет вести на лендинговую страницу.
Требуется проверить гипотезу, что через интернет карту закажут как минимум 50% от оффлайн-заказов за первый месяц.
2. Интересы заинтересованных сторон - это тоже допущения
3. Для обновления информации на странице решили не делать отдельных интерфейсов, дали доступ соответствующим людям до конфигурационных файлов, научили нажимать кнопку "Обновить" для применения изменений
4. Систему отчетов решили не делать, подключились к яндекс.метрики и можно смотреть из систем КЦ и карточной системы. Этого показалось достаточно
5. Системы карт и КЦ могут принимать заявки патчами. Форматы передачи условны и удобны (внимания на них не заострял)
6. Решили не делать личный кабинет с историей заявок и сохранением персональных данных
7. Онлайн проверки в БКИ решили не делать.


Вот на этом успокаиваюсь и отправляю результат на проверку. Буду рад любым комментариям с конструктивной критикой. В конце прикладываю итоговый файл

lending_test_task

Вам также может понравиться

About the Author: admin

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

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Яндекс.Метрика