Переходим к серии вопросов по всей теме типов требований.
1️⃣ Верно ли, что бизнес-требования имеют средний уровень детализации ожидаемых возможностей к ПО?
Нет, неверно. Средний уровень детализации имеют пользовательские, но никак не бизнес-требования. «Они настолько верхнеуровневые, что даже Гулливер задирает голову» 😁
2️⃣ Верно ли, что требования переходного периода реализуются для того, чтобы переход между текущим состоянием системы и её будущим состоянием произошёл с меньшими осложнениями?
Эбсолютли райт! 🎉 Чтобы подготовить систему к новому состоянию, можно ещё до выхода функциональности в продакшн внести изменения в существующие процессы.
Например:
Если в приложении для доставки блюд не выводился состав блюд, но в рамках новой функциональности эта возможность планируется, то уже сейчас можно запрашивать эту информацию у ресторанов и сохранять в системе.
Вот вам и плавный переход между состояниями системы.
3️⃣ Верно ли, что пользовательские требования чаще всего формулируются по шаблону пользовательских историй?
Запрос пользователя безусловно можно сформулировать в формате, ближе к функциональным требованиям.
Например:
Пользователь должен иметь возможность указывать банковскую карту для оплаты.
Но если бы мы знали цель пользователя (чтобы что?): удобно и быстро проводить оплату без повторного ввода номера карты, то функциональное требование бы изменилось на:
Пользователь должен иметь возможность привязывать банковскую карту к личному профилю.
В первом случае пользователь будет иметь возможность указывать банковскую карту каждый раз для проведения оплаты (что не решает его проблему, которая не указана), а во втором – сможет указать её единожды и постоянно оплачивать с помощью неё доставку.
Именно поэтому пользовательские требования лучше формулировать по шаблону User story.
4️⃣ Верно ли, что нефункциональные требования влияют на функциональные возможности проектируемой системы?
Нефункциональные требования влияют на результат функциональных требований, но не на сами алгоритмы выполнения функции. Процесс всё равно выполнится – успешно или неуспешно, но он будет завершён. Огромное вам спасибо за обсуждение в комментариях – там мы постарались разобрать формулировку вопроса и аргументировать разные точки зрения (это было супер!) 🖤
1️⃣ Верно ли, что бизнес-требования имеют средний уровень детализации ожидаемых возможностей к ПО?
Нет, неверно. Средний уровень детализации имеют пользовательские, но никак не бизнес-требования. «Они настолько верхнеуровневые, что даже Гулливер задирает голову» 😁
2️⃣ Верно ли, что требования переходного периода реализуются для того, чтобы переход между текущим состоянием системы и её будущим состоянием произошёл с меньшими осложнениями?
Эбсолютли райт! 🎉 Чтобы подготовить систему к новому состоянию, можно ещё до выхода функциональности в продакшн внести изменения в существующие процессы.
Например:
Если в приложении для доставки блюд не выводился состав блюд, но в рамках новой функциональности эта возможность планируется, то уже сейчас можно запрашивать эту информацию у ресторанов и сохранять в системе.
Вот вам и плавный переход между состояниями системы.
3️⃣ Верно ли, что пользовательские требования чаще всего формулируются по шаблону пользовательских историй?
Запрос пользователя безусловно можно сформулировать в формате, ближе к функциональным требованиям.
Например:
Пользователь должен иметь возможность указывать банковскую карту для оплаты.
Но если бы мы знали цель пользователя (чтобы что?): удобно и быстро проводить оплату без повторного ввода номера карты, то функциональное требование бы изменилось на:
Пользователь должен иметь возможность привязывать банковскую карту к личному профилю.
В первом случае пользователь будет иметь возможность указывать банковскую карту каждый раз для проведения оплаты (что не решает его проблему, которая не указана), а во втором – сможет указать её единожды и постоянно оплачивать с помощью неё доставку.
Именно поэтому пользовательские требования лучше формулировать по шаблону User story.
4️⃣ Верно ли, что нефункциональные требования влияют на функциональные возможности проектируемой системы?
Нефункциональные требования влияют на результат функциональных требований, но не на сами алгоритмы выполнения функции. Процесс всё равно выполнится – успешно или неуспешно, но он будет завершён. Огромное вам спасибо за обсуждение в комментариях – там мы постарались разобрать формулировку вопроса и аргументировать разные точки зрения (это было супер!) 🖤