Описание функций. Часть 1

Рекомендуем

Please reload

Описание распространенных функций | Просмотр и редактирование профиля

13.12.2018

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

 

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

 

User Story

 

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

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

 

Помните, что пользовательские истории обязательно должны содержать цель. Ответьте на вопрос, для чего пользователю что-то нужно делать? Какую пользу это ему принесет, какую проблему мы пытаемся решить. Безусловно цели могут различаться из проекта в проект.

 

Роли и права доступа

Роли и разрешения также зависят от Бизнес и пользовательских потребностей. Мы советуем всегда помнить про роль Администратора. Обратите внимание, что мы разделили возможность редактирования общих, авторизационных и платежных данных. Не всегда разрешения по ним будут совпадать. 

 

Описание

Просмотр своего профиля (пользователь)

Пользователь системы должен иметь возможность посмотреть следующую информацию в с воем профиле:

  • ФИО

  • Фото

  • Номер телефона

  • Email

  • Город

  • ....

  • Список привязанных для оплаты карт

 

В некоторых системах, для обеспечения доп. безопасности стоит указать, что данные доступны для просмотра и изменения после введения некоторого пароля. 

Очень часто упускается из виду то, что функции посмотреть свой профиль и посмотреть чужой профиль отличаются, не забудьте указать в чем именно заключается различие. 

Данные для просмотра и редактирования не всегда совпадают, например, пользователь не должен иметь возможность посмотреть свой пароль, но может его отредактировать.

Редактирование общей информации (пользователь)

Пользователь может изменить только редактируемую информацию указанную в таблице с данными.

 

Пример описания: Изменение номера телефона

Процесс смены номер телефона следующий:

 

Пред. условия

  • Пользователь авторизовался в своем профиле

  • Пользователь перешел в настройки профиля

 

Основной процесс

1. Пользователь начинает изменение номера телефона;

2. Система сравнивает новый телефон с предыдущим, если отличается, то предлагает подтвердить номер

2.1. Если такой телефон уже существует в системе, то она уведомляет об этом пользователя и просит сменить номер;

3. Пользователь решает подтвердить номер;

4. Система высылает СМС на указанный новый номер телефона со случайно сгенерированным кодом из 4х цифр

4.1. Пользователь может запрашивать новый код не чаще чем раз в 1 минуту;

5. Пользователь вводит код проверки;

6. Система проверяет код

6.1. Если пользователь 3 раза ввел код не правильно, то система высылает новый код по СМС. Максимальное число сообщений, отправленных системой 5, затем возможность изменить номер у пользователя блокируется на 24 часа;

6.2. Если код введен верно, система сохраняет новый телефон в базе и уведомляет пользователя об успешном изменении;

 

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

 

Входные/выходные данные

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

 

Список ошибок и подтверждений

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

 

UI

 
Просмотр профиля
 
Редактирование номера телефона

 

 

Все прототипы сделаны в программе Adobe XD с помощью шаблона Wires для мобильных устройств.

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

 

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

Please reload

Контакты

ИП Теселкина Ксения Валерьевна

ИНН 540202590009

+7-913-720-63-13

analystlife@gmail.com