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

Описание

Нефункциональные требования описывают качественные характеристики системы RetailFlow.

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

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

1. Удобство использования

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

Требования:

– основные действия должны выполняться за минимальное количество шагов;

– сотрудник должен быстро находить задачи своей смены;

– статус задачи должен быть визуально понятен;

– форма передачи смены должна быть простой и структурированной;

– кнопки и разделы должны иметь понятные названия;

– сообщения об ошибках должны быть написаны простым языком;

– интерфейс должен быть удобен для работы на ПК и планшетах.

2. Доступность

Система должна быть доступна пользователям в течение рабочего времени магазина.

Требования:

– система должна быть доступна 24/7;

– пользователь должен иметь возможность открыть систему с рабочего устройства;

– система должна поддерживать современные браузеры;

– при временных сбоях пользователь должен получить понятное сообщение;

– данные не должны теряться при кратковременных сбоях соединения.

3. Производительность

Система должна быстро обрабатывать действия пользователей.

Требования:

– основные страницы должны открываться без заметной задержки;

– список задач должен загружаться за приемлемое время;

– изменение статуса задачи должно сохраняться быстро;

– загрузка фотоотчёта не должна блокировать работу пользователя;

– отчеты за выбранный период должны формироваться за приемлемое время;

– система должна корректно работать при одновременной работе нескольких пользователей магазина.

4. Безопасность

Система должна защищать данные пользователей, задач, смен и отчетов.

Требования:

– доступ к системе должен выполняться через авторизацию;

– у каждого пользователя должна быть своя учетная запись;

– права доступа должны зависеть от роли пользователя;

– сотрудник не должен иметь доступ к административным функциям;

– руководитель должен видеть данные только в рамках своей зоны ответственности;

– пароли должны храниться в защищенном виде;

– действия пользователей должны фиксироваться в истории;

– система должна защищать данные от несанкционированного изменения.

5. Разграничение прав доступа

В системе должны быть разные уровни доступа для пользователей.

Требования:

– сотрудник магазина видит свои задачи и информацию по смене;

– старший смены видит задачи сотрудников и может подтверждать выполнение;

– руководитель видит отчеты, историю смен и аналитику;

– администратор управляет пользователями, ролями и справочниками;

– пользователь не должен видеть функции, которые не относятся к его роли.

6. Надежность

Система должна обеспечивать сохранность данных о сменах и задачах.

Требования:

– данные о задачах должны сохраняться после изменения статуса;

– комментарии и фотоотчёты не должны теряться;

– запись передачи смены должна сохраняться после отправки;

– история смен должна храниться централизованно;

– при сбое пользователь должен понимать, какие данные были сохранены;

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

7. Масштабируемость

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

Требования:

– должна быть возможность добавлять новых сотрудников;

– должна быть возможность добавлять новые магазины;

– должна быть возможность добавлять новые роли;

– должна быть возможность добавлять новые типы задач;

– система должна поддерживать расширение отчетности;

– структура данных должна позволять добавлять новые сущности при развитии проекта.

8. Поддерживаемость

Система должна быть удобной для сопровождения и дальнейшего развития.

Требования:

– структура системы должна быть логичной и разделённой по ролям;

– справочники задач должны редактироваться без изменения программного кода;

– ошибки должны фиксироваться для дальнейшего анализа;

– данные должны храниться в структурированном виде;

– новые функции должны добавляться без нарушения работы базовых сценариев.

9. Совместимость

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

Требования:

– поддержка современных браузеров: Chrome, Edge, Firefox;

– корректное отображение интерфейса на ПК;

– корректное отображение интерфейса на планшетах;

– адаптивность интерфейса для разных размеров экранов;

– отсутствие необходимости установки сложного дополнительного ПО на рабочие устройства.

10. Требования к интерфейсу

Интерфейс должен быть единообразным и понятным.

Требования:

– единый стиль оформления экранов;

– понятная навигация между разделами;

– визуальное различие статусов задач;

– наличие фильтров и поиска в списках;

– понятные уведомления о новых задачах и проблемах;

– минимальное количество кликов для частых действий;

– возможность быстро перейти от задачи к деталям смены.

11. Требования к хранению данных

Система должна хранить данные в централизованной базе.

Требования:

– хранение пользователей;

– хранение ролей;

– хранение смен;

– хранение задач;

– хранение статусов задач;

– хранение комментариев;

– хранение ссылок на фотоотчёты;

– хранение проверок руководителя;

– хранение истории изменений.

12. Требования к отчетности

Отчетность должна формироваться на основе актуальных данных системы.

Требования:

– отчеты должны строиться по выбранному периоду;

– отчеты должны учитывать статусы задач;

– данные в отчетах должны соответствовать данным в системе;

– руководитель должен видеть дату и период формирования отчета;

– отчеты должны быть понятны без дополнительной ручной обработки.