Чтобы в продукте появилась новая функция, сначала нужно правильно сформулировать задачу разработчику (ну или нейросети). Один из подходов для этого - метод EARS (Easy Approach to Requirements Syntax). Этот метод позволяет формулировать требования к программным продуктам понятно, структурированно и без двусмысленностей. Разработал его в 2009 товарищ Алистар Мавин для компании Rolls-Royce. Вот, кстати, его сайт, там и про EARS есть. Метод выделяет пять основных шаблонов для описания различных сценариев поведения системы: 🔹Постоянные требования (Ubiquitous) действуют постоянно без условий - [Система] должна [действие]. 🔹Управляемые состоянием (State-driven) активны при определенном состоянии - Пока [состояние], [система] должна [действие]. 🔹Управляемые событиями (Event-driven): срабатывают в момент триггера - Когда [событие], [система] должна [действие]. 🔹Требования с доп. условиями (Optional-feature) применимы при наличии конкретной функции - Где [функция или возможность], [система] должна [действие]. 🔹Требования при нежелательном поведении (Unwanted-behaviour) описывают реакцию на ошибки - Если [нежелательное условие], [система] должна [действие]. Пример: Когда пользователь нажимает кнопку «Сохранить», система должна добавить вакансию в список избранного пользователя. Это требование понятно разработчику, тестировщику и заказчику. Вот тут подробнее. #process