group-telegram.com/kozlovaabout/324
Last Update:
Разделение функциональных требований и требований к GUI
🔗 Начинающие аналитики часто не видят разницы между тем, ЧТО должна делать система и КАК это должно выглядеть. Это может происходить, когда:
▪️аналитик сам делает GUI;
▪️аналитик пишет требования к уже готовому GUI;
▪️заказчик приходит с готовым решением;
▪️аналитик пишет требования для MVP.
🔗 Кажется, что написать объединенные требования проще, но в результате может появиться такое:
Плохой пример ФТ
Пользователь должен иметь возможность авторизоваться в системе, введя логин и пароль в поля формы в левом верхнем углу и нажав на большую синюю кнопку.
Плохой пример Use case
1. Пользователь открывает панель для авторизации
2. Пользователь вводит логин и пароль
3. Пользователь нажимает большую синюю кнопку «Войти»
🔗 По таким требованиям можно написать код и тест-кейсы и даже ПО будет работать, но их придется переписывать, если:
1. Заказчику не понравится GUI;
2. ПО нужно адаптировать для разных ОС мобильных и десктопных устройств;
3. Потребуется разный фирменный стиль для разных клиентов;
4. ПО должно работать через API или командную строку.
🔗 А как же написать функциональные требования, чтобы их не пришлось переписывать из-за изменения требований к GUI?
Давайте на простых примерах определим разницу между функциональными требованиями и требованиями к GUI.
Функциональные требования — это ЧТО именно должна делать система. Это бизнес-логика, основные возможности, которые нужны пользователям.
Пример:
1. Система должна позволять пользователю авторизоваться.
2. Система должна проверять логин и пароль для авторизации пользователя.
Требования к GUI — это КАК именно должен выглядеть интерфейс, как пользователь должен взаимодействовать с системой.
Пример:
1. Форма для авторизации должна находиться в правом верхнем углу;
2. Кнопка входа должна быть синего цвета и большого размера.
Правильный Use case
1. Пользователь вводит логин и пароль и запрашивает авторизацию;
2. Система проверяет данные и авторизует пользователя.
Если дизайнер в дальнейшем изменит требования к GUI, то:
▪️Раздел с функциональными требованиями и Use Case останется без изменений.
▪️Мы сэкономим ресурсы: время, деньги и нервы на изменение и пересогласование этих требований.
🔗 Конечно, требования к GUI придется изменить. Но это будет сделать гораздо легче, чем изменять все требования. Давайте перечислим преимущества разделения:
▪️Отделяем важное от второстепенного: сначала функции и бизнес-логика, потом детали интерфейса.
▪️Упрощаем адаптацию для разных устройств и ОС.
▪️Облегчаем тестирование функциональности, т.к. отделяем баги функциональности от багов интерфейса.
▪️Экономим ресурсы при изменении дизайна.
▪️Повышаем качество продукта.
🔗 Как же разделить требования?
Правильный способ – провести бизнес-анализ:
1. Найти проблему, которую решает система
2. Выявить пользователей и их операции
3. Определить бизнес-правила
4. Сформулировать функциональные требования
5. Разработать mockup и требования к интерфейсу
Быстрый способ:
1. Прочитать требование;
2. Мысленно заменить описанный интерфейс на другой;
3. Если смысл остался — выделить функциональную часть;
4. Остальное — это GUI.
🔗 И держите чек-лист для самопроверки:
Функциональное требование:
▪️Описывает действие или бизнес-правило;
▪️Не содержит цветов, размеров, расположения;
▪️Актуально при смене дизайна;
▪️Отвечает на вопрос "ЧТО система должна уметь?";
▪️Можно протестировать независимо от интерфейса.
GUI требование:
▪️Описывает внешний вид интерфейса;
▪️Содержит визуальные характеристики;
▪️Отвечает на вопрос "КАК это выглядит?";
▪️Можно изменить без влияния на функциональность.
Участвую в конкурсе #продолжи_мысль_SE от @systems_education
BY Козлова обо всем
Warning: Undefined variable $i in /var/www/group-telegram/post.php on line 260
Share with your friend now:
group-telegram.com/kozlovaabout/324