Третий вариант. Функциональные требования отражают интересы заказчика в лице бизнеса и/или пользователей. Если проектная команда будет создавать систему только исходя из интересов бизнеса, лояльность пользователей к продукту будет снижаться. А ноу юзерс, ноу ханей, ю ноу? 🍯🐝



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



Четвёртый вариант. CRUD-модель работы с данными (создание, чтение, изменение и удаление) действительно упрощает первичный сбор требований с заказчика. Тут действует принцип Парето (Vilfredo Federico Damaso Pareto), где 20% усилий в виде четырёх вопросов к функциональным возможностям внутри решения дают 80% результата. Пробуйте применить в работе – будете приятно удивлены 😊



Кстати, четвёртый вариант будет верным высказыванием. Пикачу, выбираем тебя ☑️





А сейчас перерыв на чашечку чая (или что там у вас в субботу?🙃) и через пару часов продолжаем.