Алоха! Сегодня продолжаем разбирать вопросы, которые любят задавать на собеседовании на роль BA/SA и поговорим про требования к системе:
#вопросыссобеседования | @ba_and_sa
Часть 17:
📍Вопрос 1: Что такое документирование требований? Для чего документировать требования?
✅Краткий ответ:
Документирование требований – это процесс формального записывания требований к проекту или продукту. Это включает в себя определение функциональных и нефункциональных требований, а также требований к качеству и ограничений.
Документирование требований необходимо для того, чтобы:
1. Сформулировать и утвердить конкретные требования к продукту или процессу.
2. Определить стандарты, условия и критерии оценки, с которыми должны согласиться все заинтересованные стороны.
3. Установить точные границы и ограничения проекта или продукта.
4. Сведения требований к единым и однозначным формулировкам для всех участников проекта.
5. Улучшить коммуникацию между заказчиком и исполнителем.
6. Предотвратить внесение ошибок или недопониманий в процессе разработки.
7. Обеспечить возможность проверки выполнения задач.
8. Сохранить и передать знания о требованиях к продукту или процессу для текущих и будущих участников проектов….
📎Материалы по теме:
- Документирование требований
- Документирование требований: мелкие ошибки, порождающие крупные проблемы
📍Вопрос 2: Какие вы знаете методы / способы документирования требований?
✅ Краткий ответ:
1. Use Case диаграммы - представляют сценарии использования системы через взаимодействие актеров (пользователей) с системой.
- Каждый сценарий описывает, как система и пользователь взаимодействуют для достижения определенной цели.
- В основном используется для описания функциональных требований системы и их взаимосвязей
2. Entity Relationship диаграммы (ER-диаграммы) - описывают структуру данных в системе и их взаимосвязи.
- Моделируют сущности (объекты) и их атрибуты, а также связи между сущностями.
- Используется для документирования требований к базе данных и хранению информации.
3. UML (Unified Modeling Language) диаграммы - представляют различные аспекты системы, включая структуру, поведение, взаимодействие компонентов и т.д.
- Включают в себя Class диаграммы, Sequence диаграммы, Activity диаграммы, и др.
- Используется для визуализации и анализа требований, моделирования различных аспектов системы.
4. Моделирование Бизнес-процессов - описывают последовательность действий, необходимых для достижения определенной цели в рамках бизнес-процесса.
- Включают в себя процессы, ресурсы, участников и взаимодействие между ними.
- Используется для документирования бизнес-требований и процессов.
5. Технические спецификации - включают в себя подробные описания функциональных и нефункциональных требований, а также технические аспекты реализации системы.
- Описывают методы, алгоритмы, архитектуру, интерфейсы и т.д.
- Используется для передачи требований разработчикам и инженерам.
6. Прототипы и мокапы - представляют собой визуальные модели интерфейсов системы.
- Используются для визуализации и проверки пользовательских требований, а также для обсуждения идей и обратной связи.
Каждый из этих методов имеет свои особенности и может использоваться в зависимости от конкретных потребностей проекта и предпочтений команды.
Что такое требования к системе или какие они бывают, мы рассматривали раннее в 3 части
Источник: @ba_and_sa
‼️Предыдущие части смотрите по #собеседование #вопросыссобеседования
#вопросыссобеседования | @ba_and_sa
Часть 17:
📍Вопрос 1: Что такое документирование требований? Для чего документировать требования?
✅Краткий ответ:
Документирование требований – это процесс формального записывания требований к проекту или продукту. Это включает в себя определение функциональных и нефункциональных требований, а также требований к качеству и ограничений.
Документирование требований необходимо для того, чтобы:
1. Сформулировать и утвердить конкретные требования к продукту или процессу.
2. Определить стандарты, условия и критерии оценки, с которыми должны согласиться все заинтересованные стороны.
3. Установить точные границы и ограничения проекта или продукта.
4. Сведения требований к единым и однозначным формулировкам для всех участников проекта.
5. Улучшить коммуникацию между заказчиком и исполнителем.
6. Предотвратить внесение ошибок или недопониманий в процессе разработки.
7. Обеспечить возможность проверки выполнения задач.
8. Сохранить и передать знания о требованиях к продукту или процессу для текущих и будущих участников проектов….
📎Материалы по теме:
- Документирование требований
- Документирование требований: мелкие ошибки, порождающие крупные проблемы
📍Вопрос 2: Какие вы знаете методы / способы документирования требований?
✅ Краткий ответ:
1. Use Case диаграммы - представляют сценарии использования системы через взаимодействие актеров (пользователей) с системой.
- Каждый сценарий описывает, как система и пользователь взаимодействуют для достижения определенной цели.
- В основном используется для описания функциональных требований системы и их взаимосвязей
2. Entity Relationship диаграммы (ER-диаграммы) - описывают структуру данных в системе и их взаимосвязи.
- Моделируют сущности (объекты) и их атрибуты, а также связи между сущностями.
- Используется для документирования требований к базе данных и хранению информации.
3. UML (Unified Modeling Language) диаграммы - представляют различные аспекты системы, включая структуру, поведение, взаимодействие компонентов и т.д.
- Включают в себя Class диаграммы, Sequence диаграммы, Activity диаграммы, и др.
- Используется для визуализации и анализа требований, моделирования различных аспектов системы.
4. Моделирование Бизнес-процессов - описывают последовательность действий, необходимых для достижения определенной цели в рамках бизнес-процесса.
- Включают в себя процессы, ресурсы, участников и взаимодействие между ними.
- Используется для документирования бизнес-требований и процессов.
5. Технические спецификации - включают в себя подробные описания функциональных и нефункциональных требований, а также технические аспекты реализации системы.
- Описывают методы, алгоритмы, архитектуру, интерфейсы и т.д.
- Используется для передачи требований разработчикам и инженерам.
6. Прототипы и мокапы - представляют собой визуальные модели интерфейсов системы.
- Используются для визуализации и проверки пользовательских требований, а также для обсуждения идей и обратной связи.
Каждый из этих методов имеет свои особенности и может использоваться в зависимости от конкретных потребностей проекта и предпочтений команды.
Что такое требования к системе или какие они бывают, мы рассматривали раннее в 3 части
Источник: @ba_and_sa
‼️Предыдущие части смотрите по #собеседование #вопросыссобеседования
Алоха! Я тут решила провести небольшой анализ по сайту найма и посмотреть, что сейчас актуально и что хотят от бизнес-аналитиков, за основу взяла всеми известный hh.
#анализ #вакансии | @ba_and_sa
Мой анализ будет разделен по уровням опыта (без опыта, от 1-3 лет, от 3-6 лет, и более 6 лет)
❗️ Что опишу: 👇🏼
- требования, которые чаще всего встречаются в вакансиях. Тут вы можете сказать, что почти все вакансии с разными требованиями, и тут я с вами соглашусь, ведь все работодатели ищут кандидата под свою деятельность и под свои потребности. Но!! я выделю требования, которые встречаются почти во всех вакансиях, ну или многих.
- приведу небольшую статистику по ЗП
- укажу количество вакансий
Привязываться к конкретному городу не буду, в наше время можно работать из любого уголка)))
В планах:
- откликнуться на n-количество вакансий разного уровня, так же привлеку своих знакомых со своими резюме
- пройти несколько собеседований на разный уровень и узнать, что в наше время спрашивают на них. Может появятся новые вопросы в моей рубрике про собеседование.
Вам интересны мои планы? делать пост про итоги прохождения собесов?
#анализ #вакансии | @ba_and_sa
Мой анализ будет разделен по уровням опыта (без опыта, от 1-3 лет, от 3-6 лет, и более 6 лет)
- требования, которые чаще всего встречаются в вакансиях. Тут вы можете сказать, что почти все вакансии с разными требованиями, и тут я с вами соглашусь, ведь все работодатели ищут кандидата под свою деятельность и под свои потребности. Но!! я выделю требования, которые встречаются почти во всех вакансиях, ну или многих.
- приведу небольшую статистику по ЗП
- укажу количество вакансий
Привязываться к конкретному городу не буду, в наше время можно работать из любого уголка)))
В планах:
- откликнуться на n-количество вакансий разного уровня, так же привлеку своих знакомых со своими резюме
- пройти несколько собеседований на разный уровень и узнать, что в наше время спрашивают на них. Может появятся новые вопросы в моей рубрике про собеседование.
Вам интересны мои планы? делать пост про итоги прохождения собесов?
Please open Telegram to view this post
VIEW IN TELEGRAM
Алоха! Сегодня продолжаем разбирать вопросы, которые любят задавать на собеседовании на роль BA/SA:
#вопросыссобеседования | @ba_and_sa
Часть 18:
📍Вопрос 1: Что такое Code First и для чего и где его используют?
✅Краткий ответ:
Code First - это подход к разработке программного обеспечения, который заключается в создании кода приложения сначала, а затем автоматической генерации базы данных и моделей на основе этого кода.
Этот подход обычно используется в случаях, когда разработчики хотят быстро создать прототип или MVP приложения. Однако, недостатком Code First является то, что API может не соответствовать требованиям клиентов или стандартам безопасности.
Для чего нужен подход Code First? Он позволяет разработчикам сосредоточиться на создании бизнес-логики и функциональности приложения, не тратя время на создание и поддержание схемы базы данных. Кроме того, Code First позволяет более гибко изменять структуру базы данных, так как изменения в коде сразу отражаются в базе данных.
➕ Преимущества подхода Code First:
1. Быстрая разработка - разработчики могут быстро создавать и изменять модели данных, без необходимости написания SQL запросов или изменения схемы базы данных.
2. Гибкость - изменения в структуре базы данных можно легко вносить, не нарушая целостность данных.
3. Простота в поддержке - разработчики могут легко создавать и обновлять миграции базы данных для обновления схемы.
➖ Недостатки подхода Code First:
1. Недостаточный контроль - генерация базы данных автоматически может привести к недостаточному контролю над структурой и индексами.
2. Не всегда оптимальная производительность - автоматически сгенерированные запросы могут быть не всегда оптимальными по производительности.
3. Сложность масштабирования - при большом количестве данных и сложной структуре базы данных, могут возникнуть проблемы с масштабируемостью.
📎Материалы по теме:
- Разработка REST API — что такое Code First подход?
📍Вопрос 2: Что такое Contract First и где его используют?
✅ Краткий ответ:
Contract First - это подход к разработке программного обеспечения, который заключается в определении и создании спецификации интерфейса API (например, формата передачи данных, структуры сообщений) до начала разработки кода приложения. Этот подход обычно используется для обеспечения соответствия API стандартам, требованиям клиентов и улучшения коммуникации между разработчиками и заказчиками.
Для чего нужен подход Contract First? Он помогает более предсказуемо определить структуру API и обеспечить согласованность между разработчиками и клиентами. Кроме того, Contract First упрощает тестирование API, так как спецификация уже определена заранее.
➕ Преимущества подхода Contract First:
1. Повышение качества - задание структуры API заранее помогает избежать недочетов и ошибок в разработке.
2. Совместимость - спецификация API может быть использована для генерации кода на разных языках программирования.
3. Улучшенная коммуникация - заказчики и разработчики имеют общее обозначение структуры и функциональности API.
➖ Недостатки подхода Contract First:
1. Дополнительные трудозатраты - создание спецификации API может потребовать дополнительного времени и ресурсов.
2. Ограничения гибкости - изменения в API могут потребовать корректировки спецификации, что может занять дополнительное время.
📎Материалы по теме:
- Разработка REST API — что такое Contract First?
📍Вопрос 3: В чем разница между Code First и Contract First?
✅ Краткий ответ:
Разница между Code First и Contract First заключается во времени начала создания API. Code First начинается с написания кода приложения, а затем автоматической генерации API на его основе, в то время как Contract First начинается с создания интерфейса API и определения спецификации, затем код приложения создается на основе этой спецификации.
В след раз поговорим о других подходах😉
Источник: @ba_and_sa
‼️Предыдущие части смотрите по #собеседование #вопросыссобеседования
#вопросыссобеседования | @ba_and_sa
Часть 18:
📍Вопрос 1: Что такое Code First и для чего и где его используют?
✅Краткий ответ:
Code First - это подход к разработке программного обеспечения, который заключается в создании кода приложения сначала, а затем автоматической генерации базы данных и моделей на основе этого кода.
Этот подход обычно используется в случаях, когда разработчики хотят быстро создать прототип или MVP приложения. Однако, недостатком Code First является то, что API может не соответствовать требованиям клиентов или стандартам безопасности.
Для чего нужен подход Code First? Он позволяет разработчикам сосредоточиться на создании бизнес-логики и функциональности приложения, не тратя время на создание и поддержание схемы базы данных. Кроме того, Code First позволяет более гибко изменять структуру базы данных, так как изменения в коде сразу отражаются в базе данных.
1. Быстрая разработка - разработчики могут быстро создавать и изменять модели данных, без необходимости написания SQL запросов или изменения схемы базы данных.
2. Гибкость - изменения в структуре базы данных можно легко вносить, не нарушая целостность данных.
3. Простота в поддержке - разработчики могут легко создавать и обновлять миграции базы данных для обновления схемы.
1. Недостаточный контроль - генерация базы данных автоматически может привести к недостаточному контролю над структурой и индексами.
2. Не всегда оптимальная производительность - автоматически сгенерированные запросы могут быть не всегда оптимальными по производительности.
3. Сложность масштабирования - при большом количестве данных и сложной структуре базы данных, могут возникнуть проблемы с масштабируемостью.
📎Материалы по теме:
- Разработка REST API — что такое Code First подход?
📍Вопрос 2: Что такое Contract First и где его используют?
✅ Краткий ответ:
Contract First - это подход к разработке программного обеспечения, который заключается в определении и создании спецификации интерфейса API (например, формата передачи данных, структуры сообщений) до начала разработки кода приложения. Этот подход обычно используется для обеспечения соответствия API стандартам, требованиям клиентов и улучшения коммуникации между разработчиками и заказчиками.
Для чего нужен подход Contract First? Он помогает более предсказуемо определить структуру API и обеспечить согласованность между разработчиками и клиентами. Кроме того, Contract First упрощает тестирование API, так как спецификация уже определена заранее.
1. Повышение качества - задание структуры API заранее помогает избежать недочетов и ошибок в разработке.
2. Совместимость - спецификация API может быть использована для генерации кода на разных языках программирования.
3. Улучшенная коммуникация - заказчики и разработчики имеют общее обозначение структуры и функциональности API.
1. Дополнительные трудозатраты - создание спецификации API может потребовать дополнительного времени и ресурсов.
2. Ограничения гибкости - изменения в API могут потребовать корректировки спецификации, что может занять дополнительное время.
📎Материалы по теме:
- Разработка REST API — что такое Contract First?
📍Вопрос 3: В чем разница между Code First и Contract First?
✅ Краткий ответ:
Разница между Code First и Contract First заключается во времени начала создания API. Code First начинается с написания кода приложения, а затем автоматической генерации API на его основе, в то время как Contract First начинается с создания интерфейса API и определения спецификации, затем код приложения создается на основе этой спецификации.
В след раз поговорим о других подходах
Источник: @ba_and_sa
‼️Предыдущие части смотрите по #собеседование #вопросыссобеседования
Please open Telegram to view this post
VIEW IN TELEGRAM
Алоха! Сегодня продолжаем разбирать вопросы, которые любят задавать на собеседовании на роль BA/SA и поговорим на тему интеграции и проектирования:
#вопросыссобеседования | @ba_and_sa
Часть 19:
📍Вопрос 1: Что такое брокеры сообщений? Приведи пример
✅Краткий ответ:
Брокеры сообщений - это программные компоненты, которые используются для обмена информацией между различными приложениями или сервисами. Они работают как посредники, принимая сообщения от одного приложения и передавая их другому.
Брокеры сообщений позволяют создавать асинхронные системы, где отправитель и получатель не нужно быть одновременно доступными. Они также обеспечивают надежную доставку сообщений и могут обрабатывать большие объемы данных.
Примером брокера сообщений является
- Apache Kafka
- RabbitMQ
- Redis
Они позволяют разным компонентам системы обмениваться информацией без необходимости знать друг о друге напрямую.
📎Материалы по теме:
- Брокеры сообщений - что это, из чего состоят, плюсы и минусы: сравниваем APACHE KAFKA, REDIS и RABBITMQ
- Message broker per service
📍Вопрос 2: Что такое корпоративная шина? Приведи пример
✅ Краткий ответ:
Корпоративная сервисная шина (ESB) – это архитектурный паттерн в информационных технологиях, который представляет собой программное обеспечение, обеспечивающее интеграцию различных систем и приложений внутри компании. ESB позволяет легко связывать и обмениваться данными между разными сервисами, приложениями и устройствами, что облегчает работу и повышает эффективность бизнес-процессов.
ESB используется в различных областях и применяется для интеграции корпоративных систем, автоматизации бизнес-процессов, обмена данными между приложениями и устройствами, а также для создания централизованной точки управления всеми сервисами компании.
Примеры ESB:
- Mule ESB - одна из самых популярных открытых платформ для интеграции приложений и систем.
- Apache ServiceMix - еще одна популярная открытая платформа, основанная на Apache Camel, Apache ActiveMQ и Apache CXF. ServiceMix предоставляет решения для интеграции, маршрутизации и обмена данными между различными системами.
- IBM Integration Bus - универсальная платформа для интеграции различных систем и приложений в предприятии.
📎Материалы по теме:
- ESB (Корпоративная сервисная шина)
- Разработка сервисной шины предприятия (ESB)
📍Вопрос 3: Чем брокер сообщений отличается от корпоративной шины?
✅ Краткий ответ:
Брокеры сообщений и корпоративные сервисные шины (ESB) - это два различных подхода к интеграции систем в предприятии. Вот основные различия между ними:
1. Назначение:
- Брокер сообщений обеспечивает асинхронную коммуникацию между различными компонентами системы путем пересылки сообщений через посредника (брокера) без прямого взаимодействия компонентов.
- Корпоративная сервисная шина, с другой стороны, предоставляет интегрированную платформу для создания, управления и контроля интеграционных процессов и приложений в предприятии.
2. Архитектура:
- Брокер сообщений имеет типичную централизованную архитектуру, где все сообщения проходят через брокера перед доставкой получателю.
- Корпоративная сервисная шина, в свою очередь, использует распределенную архитектуру, позволяющую создавать сложные интеграционные процессы и маршрутизировать сообщения между различными системами.
3. Функциональность:
- Брокер сообщений прежде всего ориентирован на передачу и обработку сообщений, не предоставляя большого количества инструментов для обработки данных и выполнения бизнес-логики.
- Корпоративная сервисная шина обладает обширным набором функций, таких как маршрутизация, преобразование сообщений, мониторинг и управление интеграционными процессами.
В целом, брокер сообщений обеспечивает простой механизм для обмена сообщениями, в то время как корпоративная сервисная шина предоставляет более мощные средства для интеграции систем и управления интеграционными процессами в предприяти
Источник: @ba_and_sa
‼️Предыдущие части смотрите по #собеседование #вопросыссобеседования
#вопросыссобеседования | @ba_and_sa
Часть 19:
📍Вопрос 1: Что такое брокеры сообщений? Приведи пример
✅Краткий ответ:
Брокеры сообщений - это программные компоненты, которые используются для обмена информацией между различными приложениями или сервисами. Они работают как посредники, принимая сообщения от одного приложения и передавая их другому.
Брокеры сообщений позволяют создавать асинхронные системы, где отправитель и получатель не нужно быть одновременно доступными. Они также обеспечивают надежную доставку сообщений и могут обрабатывать большие объемы данных.
Примером брокера сообщений является
- Apache Kafka
- RabbitMQ
- Redis
Они позволяют разным компонентам системы обмениваться информацией без необходимости знать друг о друге напрямую.
📎Материалы по теме:
- Брокеры сообщений - что это, из чего состоят, плюсы и минусы: сравниваем APACHE KAFKA, REDIS и RABBITMQ
- Message broker per service
📍Вопрос 2: Что такое корпоративная шина? Приведи пример
✅ Краткий ответ:
Корпоративная сервисная шина (ESB) – это архитектурный паттерн в информационных технологиях, который представляет собой программное обеспечение, обеспечивающее интеграцию различных систем и приложений внутри компании. ESB позволяет легко связывать и обмениваться данными между разными сервисами, приложениями и устройствами, что облегчает работу и повышает эффективность бизнес-процессов.
ESB используется в различных областях и применяется для интеграции корпоративных систем, автоматизации бизнес-процессов, обмена данными между приложениями и устройствами, а также для создания централизованной точки управления всеми сервисами компании.
Примеры ESB:
- Mule ESB - одна из самых популярных открытых платформ для интеграции приложений и систем.
- Apache ServiceMix - еще одна популярная открытая платформа, основанная на Apache Camel, Apache ActiveMQ и Apache CXF. ServiceMix предоставляет решения для интеграции, маршрутизации и обмена данными между различными системами.
- IBM Integration Bus - универсальная платформа для интеграции различных систем и приложений в предприятии.
📎Материалы по теме:
- ESB (Корпоративная сервисная шина)
- Разработка сервисной шины предприятия (ESB)
📍Вопрос 3: Чем брокер сообщений отличается от корпоративной шины?
✅ Краткий ответ:
Брокеры сообщений и корпоративные сервисные шины (ESB) - это два различных подхода к интеграции систем в предприятии. Вот основные различия между ними:
1. Назначение:
- Брокер сообщений обеспечивает асинхронную коммуникацию между различными компонентами системы путем пересылки сообщений через посредника (брокера) без прямого взаимодействия компонентов.
- Корпоративная сервисная шина, с другой стороны, предоставляет интегрированную платформу для создания, управления и контроля интеграционных процессов и приложений в предприятии.
2. Архитектура:
- Брокер сообщений имеет типичную централизованную архитектуру, где все сообщения проходят через брокера перед доставкой получателю.
- Корпоративная сервисная шина, в свою очередь, использует распределенную архитектуру, позволяющую создавать сложные интеграционные процессы и маршрутизировать сообщения между различными системами.
3. Функциональность:
- Брокер сообщений прежде всего ориентирован на передачу и обработку сообщений, не предоставляя большого количества инструментов для обработки данных и выполнения бизнес-логики.
- Корпоративная сервисная шина обладает обширным набором функций, таких как маршрутизация, преобразование сообщений, мониторинг и управление интеграционными процессами.
В целом, брокер сообщений обеспечивает простой механизм для обмена сообщениями, в то время как корпоративная сервисная шина предоставляет более мощные средства для интеграции систем и управления интеграционными процессами в предприяти
Источник: @ba_and_sa
‼️Предыдущие части смотрите по #собеседование #вопросыссобеседования
Алоха! Как вы знаете, у меня на канале есть рубрика «вопросы с собеседований», где я делюсь вопросами, которые задают аналитикам на собеседованиях, и краткими ответами на них. И я подготовила вторую часть вопросов с ответами в одном посте
❗️🤓 Часть 1 или вопросы с 1 по 27- если кто забыл)))
#вопросыссобеседования
Требования:
28 - Какой подход вы используете в своей работе, чтобы повысить точность определения требований и лучшего их понимания заказчиками и пользователем?
Или
Что такое прототипирование и визуализация и для чего вы используете их в своей работе?
29 - Что значит «требование хорошего качества» или как определить качество требований? Опиши критерии оценки требований
30 - Кто такие стейкхолдеры и как с ними работать?
31 - Какие стратегии вы применяете для управления заинтересованными сторонами?
32 - Что такое Use Case и какие оттеним написания вы знаете
33 - Напишите пример Use Case
34 - Что такое User story? Какие критерии их написания вы знаете?
35 - Приведите пример User story
36 - Что означает аббревиатура INVEST и как с ней работать?
37 - Что такое USM - User Story Mapping?
38 - Что такое CJM - Costomer Journey Map?
39 - Что такое документирование требований и для чего оно нужно?
40 - Какие вы знаете методы/способы документирования требований
Интеграция / Архитектура ПО:
41 - Что такое интеграция систем и зачем она нужна в ИС?
42 - Какие преимущества и недостатки вы можете выделить при интеграции систем?
43 - Какие методы интеграции могут использоваться при обмене данными между различными системами?
44 - Что такое Code First и для чего и где его используют?
45 - Что такое Contract First и где его используют?
46 - В чем разница между Code First и Contract First?
47 - Что такое брокеры сообщений? Приведи пример
48 - Что такое корпоративная шина? Приведи пример
49 - Чем брокер сообщений отличается от корпоративной шины?
Источник: @ba_and_sa
Ждите продолжения!
❗️
#вопросыссобеседования
Требования:
28 - Какой подход вы используете в своей работе, чтобы повысить точность определения требований и лучшего их понимания заказчиками и пользователем?
Или
Что такое прототипирование и визуализация и для чего вы используете их в своей работе?
29 - Что значит «требование хорошего качества» или как определить качество требований? Опиши критерии оценки требований
30 - Кто такие стейкхолдеры и как с ними работать?
31 - Какие стратегии вы применяете для управления заинтересованными сторонами?
32 - Что такое Use Case и какие оттеним написания вы знаете
33 - Напишите пример Use Case
34 - Что такое User story? Какие критерии их написания вы знаете?
35 - Приведите пример User story
36 - Что означает аббревиатура INVEST и как с ней работать?
37 - Что такое USM - User Story Mapping?
38 - Что такое CJM - Costomer Journey Map?
39 - Что такое документирование требований и для чего оно нужно?
40 - Какие вы знаете методы/способы документирования требований
Интеграция / Архитектура ПО:
41 - Что такое интеграция систем и зачем она нужна в ИС?
42 - Какие преимущества и недостатки вы можете выделить при интеграции систем?
43 - Какие методы интеграции могут использоваться при обмене данными между различными системами?
44 - Что такое Code First и для чего и где его используют?
45 - Что такое Contract First и где его используют?
46 - В чем разница между Code First и Contract First?
47 - Что такое брокеры сообщений? Приведи пример
48 - Что такое корпоративная шина? Приведи пример
49 - Чем брокер сообщений отличается от корпоративной шины?
Источник: @ba_and_sa
Ждите продолжения!
Please open Telegram to view this post
VIEW IN TELEGRAM