🔹 Бизнес-требования, которые отражают ожидания бизнеса к продукту. Такие требования располагаются на верхушке айсберга и преследуют улучшение показателей бизнеса – выручки, оборотов, притока клиентов и так далее.
Например:
Необходимо создать продукт, который позволит увеличить приток начинающих специалистов в сообщество GetAnalyst и повысит узнаваемость бренда.
🔸 Пользовательские требования, которые отражают интересы сторон, использующих продукт. Этот уровень требований уже более детально раскрывает бизнес-требования, но отражает интерес потребителей бизнеса – пользователей и клиентов.
Например:
Как пользователь приложения Get Analyst, я хочу видеть познавательный контент на тему анализа в IT, в одном месте, чтобы процесс обучения был ещё удобнее.
🔹 Функциональные требования, которые описывают возможности, которые должен содержать IT-продукт. Такие требования возникают после проработки бизнес- и пользовательских требований и именно этот тип требований необходимо передавать в разработку.
Например:
Необходимо реализовать своевременную интеграцию контента сообщества GetAnalyst с различных платформ в приложение.
🔸 Нефункциональные требования, которые отражают ожидание заинтересованных лиц в качестве и надёжности выполнения функций. Такие требования не влияют на функциональные возможности продукта напрямую, но улучшают их результат: скорость его получения, безопасность процесса при выполнении функции и так далее. Этот тип требований тоже готов к передаче в разработку, потому что достаточно детализирован.
Например:
В приложении должна быть возможность подключить двухфакторную аутентификацию, чтобы снизить риск утечки персональных данных пользователя.
🔹 Требования переходного периода, которые содержат требования к процессу работы системы в период, пока планируемое изменение не станет доступным для пользователей. Иными словами, требования переходного периода – это как «подстелить соломку» перед выходом проектируемого изменения в общий доступ. Эти требования ближе к функциональным требованиям и чаще всего их не выделяют в отдельный тип, а формулируют, как требования к первой итерации* продукта.
Например:
Пока двухфакторная аутентификация недоступна, необходимо авторизовать пользователя в приложении по номеру телефона и паролю.
🤪🤪куда так много требований
Ну как, держитесь ещё? Завтра и послезавтра хотим подробнее рассказать вам про два самых популярных типа требований в работе аналитика: бизнес-требования и функциональные требования.
А в конце будет классный КВИЗ, где вы сможете закрепить свои знания (кажется, вы их любите. Мы тоже!💥).
Признавайтесь, ждёте? 😉
Например:
Необходимо создать продукт, который позволит увеличить приток начинающих специалистов в сообщество GetAnalyst и повысит узнаваемость бренда.
🔸 Пользовательские требования, которые отражают интересы сторон, использующих продукт. Этот уровень требований уже более детально раскрывает бизнес-требования, но отражает интерес потребителей бизнеса – пользователей и клиентов.
Например:
Как пользователь приложения Get Analyst, я хочу видеть познавательный контент на тему анализа в IT, в одном месте, чтобы процесс обучения был ещё удобнее.
🔹 Функциональные требования, которые описывают возможности, которые должен содержать IT-продукт. Такие требования возникают после проработки бизнес- и пользовательских требований и именно этот тип требований необходимо передавать в разработку.
Например:
Необходимо реализовать своевременную интеграцию контента сообщества GetAnalyst с различных платформ в приложение.
🔸 Нефункциональные требования, которые отражают ожидание заинтересованных лиц в качестве и надёжности выполнения функций. Такие требования не влияют на функциональные возможности продукта напрямую, но улучшают их результат: скорость его получения, безопасность процесса при выполнении функции и так далее. Этот тип требований тоже готов к передаче в разработку, потому что достаточно детализирован.
Например:
В приложении должна быть возможность подключить двухфакторную аутентификацию, чтобы снизить риск утечки персональных данных пользователя.
🔹 Требования переходного периода, которые содержат требования к процессу работы системы в период, пока планируемое изменение не станет доступным для пользователей. Иными словами, требования переходного периода – это как «подстелить соломку» перед выходом проектируемого изменения в общий доступ. Эти требования ближе к функциональным требованиям и чаще всего их не выделяют в отдельный тип, а формулируют, как требования к первой итерации* продукта.
Например:
Пока двухфакторная аутентификация недоступна, необходимо авторизовать пользователя в приложении по номеру телефона и паролю.
🤪🤪
Ну как, держитесь ещё? Завтра и послезавтра хотим подробнее рассказать вам про два самых популярных типа требований в работе аналитика: бизнес-требования и функциональные требования.
А в конце будет классный КВИЗ, где вы сможете закрепить свои знания (кажется, вы их любите. Мы тоже!💥).
Признавайтесь, ждёте? 😉