Здравствуйте. Я начинающий аналитик, и я хотел бы получить помощь опытных людей, если можно) Я пишу юскейс по редактированию данных в оборудовании, используя описываемое мной ПО. Сначала я получил данные, они отображаются в ПО. Теперь я хочу какие-то данные подправить и отослать обратно в оборудование, но есть два варианта записи - записать все данные и записать только измененные. Я хочу, чтобы был выбран второй вариант. Должен ли я вообще это указывать, ведь вроде бы это является нефункциональным требованием? Меня беспокоит, что если я в юскейсе сделаю шаг "Система даёт команду оборудованию на запись только измененных атрибутов ", это будет пользовательский уровень требований.
Если что, можно в личку.

Здравствуйте. Я начинающий аналитик, и я хотел бы получить помощь опытных людей, если можно) Я пишу юскейс по редактированию данных в оборудовании, используя описываемое мной ПО. Сначала я получил данные, они отображаются в ПО. Теперь я хочу какие-то данные подправить и отослать обратно в оборудование, но есть два варианта записи - записать все данные и записать только измененные. Я хочу, чтобы был выбран второй вариант. Должен ли я вообще это указывать, ведь вроде бы это является нефункциональным требованием? Меня беспокоит, что если я в юскейсе сделаю шаг "Система даёт команду оборудованию на запись только измененных атрибутов ", это будет пользовательский уровень требований.
Если что, можно в личку.

Всем откликнувшимся большое спасибо!🤝 Я думаю, действительно сделать две функции, по обоим вариантам, нам это пригодится.

А вот это действительно, как сказал Andrey правильнее решать разработчикам. Потому что иногда лучше сделать отдельно, а иногда добавить параметрами и одной функцией. Решать разработке.

Ну да, с этим нет проблем когда Use Case передается на обсуждение с внутренними архитекторами. Трудности могут быть, если он готовится для окончательной фиксации "на бумаге", сразу уходит в договор и отдается в стороннюю разработку.

Да, и тут надо различать варианты: для пользователей и для разработки. Они в общем случае не равны. Вот как в приведенном выше примере, если написать одна функция с параметрами, то пользователь (иногда ошибочно) может запустить весь объем. И это может подвесить систему на несколько часов, дней в самый неподходящий момент первых дней внедрения. Поэтому иногда стОит сделать две функции наружу при одной функции внутри.

Ну да, с этим нет проблем когда Use Case передается на обсуждение с внутренними архитекторами. Трудности могут быть, если он готовится для окончательной фиксации "на бумаге", сразу уходит в договор и отдается в стороннюю разработку.

Ну если разрабы работают так тупо - "что аналитик написал, то и сделаем", даже в условиях сторонней разработки...

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