А вот и мыыыы👋
Вчера мы поговорили с вами про бизнес-требования и даже прошли небольшой КВИЗ. Сегодня мы немного детальнее разберём функциональные требования и их связь с другими требованиями.
Функциональные требования – это описание ожидаемых возможностей в рамках проектируемого решения.
Вот так просто? Ну да 😊
❗️Функциональные требования определяют, что должны спроектировать разработчики, но не то, как именно они должны это спроектировать.
Очень важно, чтобы формулировка требования не содержала конкретное техническое решение.
Например:
🔹 Система должна получить информацию о clientId, clientFIO, clientNumber, clientLogin, clientPassword из POST-метода системы партнёра и сформировать личный кабинет клиенту с помощью метода CreateLK.
Глядя на такое требование вы не только ограничиваете разработчика, но и предлагаете не оптимальное решение(не надо так). Ведь скорее всего для создания личного кабинета достаточно меньшего количества полей. Оставьте конкретную реализацию команде разработки.
☝️Задача аналитика – обозначить конечную цель, ресурсы для её достижения, а также факторы, которые влияют на проектируемый процесс. А задача разработчика – определить лучший способ достижения этой цели и спроектировать обозначенную возможность в соотношении цена / качество.
Таков путь 🥷
А теперь разберём наш пример с приложением GetAnalyst.
В прошлый раз мы получили следующее требование от заказчика:
🔸 Необходимо создать продукт, который позволит увеличить приток начинающих специалистов в сообщество GetAnalyst и повысит узнаваемость бренда.
В ответ мы, как аналитики, предложили множество вариантов для достижения этой бизнес-цели. И конечный выбор пал на приложение. А какие конкретно функции мы ожидаем в этом приложении? Идём к заказчику 🏃♀️🏃♂️
Один из самых популярных способов формулирования функциональных требований – это проектирование вопросов по CRUD-модели:
🔹 Create: Можно ли в приложении вести свой блог и создавать записи? Или создавать комментарии под записями? А есть ли у пользователя личный кабинет с персональной информацией? Закрыли функциональное требование на создание данных.
🔹 Read: Можно ли читать записи? Кстати, а откуда эти записи появляются? Закрываем требование по чтению данных и тут же по интеграции с другими платформами.
🔹 Update: Можно ли изменять созданные записи, комментарии или реакции? Как насчёт возможности менять свой ответ в викторинах? А редактирование данных в личном кабинете? Получили требования к изменению данных.
🔹 Delete: Можно ли удалять комментарии? А удалить свой личный кабинет? То есть узнали про возможность удаления данных.
И так далее.
Благодаря этой технике на начальном этапе у аналитика возникает множество вопросов на тему того, а что же система должна уметь делать по мнению заказчика.
Полученный ответ формулируется в виде утверждения со словами «должен», «должна» или «необходимо» + глагол + ожидаемый результат.
Например:
🔸 В системе должна быть возможность создать личный кабинет в приложении с указанием персональных данных.
И ниже можно приложить список обязательных персональных данных, которые необходимо иметь в системе по каждому пользователю:
- Фамилия Имя Отчество
- Номер телефона (с указанием формата)
- Пароль (с указанием ограничений по длине и допустимым символам)
и так далее.
‼️ Функциональные требования напрямую связаны с другими типами требованиями. Ведь если спроектировать ПО, которое не представляет ценности для бизнеса (бизнес-требования) и пользователей (пользовательские требования), то ресурс на разработку был затрачен зря – такой продукт будет не нужен.
Вчера мы поговорили с вами про бизнес-требования и даже прошли небольшой КВИЗ. Сегодня мы немного детальнее разберём функциональные требования и их связь с другими требованиями.
Функциональные требования – это описание ожидаемых возможностей в рамках проектируемого решения.
❗️Функциональные требования определяют, что должны спроектировать разработчики, но не то, как именно они должны это спроектировать.
Очень важно, чтобы формулировка требования не содержала конкретное техническое решение.
Например:
🔹 Система должна получить информацию о clientId, clientFIO, clientNumber, clientLogin, clientPassword из POST-метода системы партнёра и сформировать личный кабинет клиенту с помощью метода CreateLK.
Глядя на такое требование вы не только ограничиваете разработчика, но и предлагаете не оптимальное решение
☝️Задача аналитика – обозначить конечную цель, ресурсы для её достижения, а также факторы, которые влияют на проектируемый процесс. А задача разработчика – определить лучший способ достижения этой цели и спроектировать обозначенную возможность в соотношении цена / качество.
А теперь разберём наш пример с приложением GetAnalyst.
В прошлый раз мы получили следующее требование от заказчика:
🔸 Необходимо создать продукт, который позволит увеличить приток начинающих специалистов в сообщество GetAnalyst и повысит узнаваемость бренда.
В ответ мы, как аналитики, предложили множество вариантов для достижения этой бизнес-цели. И конечный выбор пал на приложение. А какие конкретно функции мы ожидаем в этом приложении? Идём к заказчику 🏃♀️🏃♂️
Один из самых популярных способов формулирования функциональных требований – это проектирование вопросов по CRUD-модели:
🔹 Create: Можно ли в приложении вести свой блог и создавать записи? Или создавать комментарии под записями? А есть ли у пользователя личный кабинет с персональной информацией? Закрыли функциональное требование на создание данных.
🔹 Read: Можно ли читать записи? Кстати, а откуда эти записи появляются? Закрываем требование по чтению данных и тут же по интеграции с другими платформами.
🔹 Update: Можно ли изменять созданные записи, комментарии или реакции? Как насчёт возможности менять свой ответ в викторинах? А редактирование данных в личном кабинете? Получили требования к изменению данных.
🔹 Delete: Можно ли удалять комментарии? А удалить свой личный кабинет? То есть узнали про возможность удаления данных.
И так далее.
Благодаря этой технике на начальном этапе у аналитика возникает множество вопросов на тему того, а что же система должна уметь делать по мнению заказчика.
Полученный ответ формулируется в виде утверждения со словами «должен», «должна» или «необходимо» + глагол + ожидаемый результат.
Например:
🔸 В системе должна быть возможность создать личный кабинет в приложении с указанием персональных данных.
И ниже можно приложить список обязательных персональных данных, которые необходимо иметь в системе по каждому пользователю:
- Фамилия Имя Отчество
- Номер телефона (с указанием формата)
- Пароль (с указанием ограничений по длине и допустимым символам)
и так далее.
‼️ Функциональные требования напрямую связаны с другими типами требованиями. Ведь если спроектировать ПО, которое не представляет ценности для бизнеса (бизнес-требования) и пользователей (пользовательские требования), то ресурс на разработку был затрачен зря – такой продукт будет не нужен.