Forwarded from Business | System analyst
Алоха! Сегодня продолжаем разбирать вопросы, которые любят задавать на собеседовании на роль BA/SA и затронем тему Use cases:
#вопросыссобеседования | @ba_and_sa
Часть 13:
📍Вопрос 1: Что такое Use Case и какие критерии написания вы знаете?
✅Краткий ответ:
Use case - это текстовое представление взаимодействия между действующими сторонами (actors - пользователями, системами или внешними сущностями) и системой или программным приложением.
Другими словами Use case - это часть требований к ПО. Он помогает разработать качественный продукт, от которого пользователь получит ожидаемый результат.
Use case состоит из:
- Заголовок
- Участники
- Предусловие
- Шаги (описание сценария)
- Результат или гарантии успеха
- Альтернативные сценарии
- Постусловие
Критерии для написания use case:
Вот некоторые из них:
1. Ясность и простота: Use case должен быть написан четко и лаконично, избегая технической терминологии, чтобы его можно было легко понять как техническими, так и не-техническими заинтересованными сторонами.
2. Ориентированность на цель: Каждый use case должен четко определять основную цель или задачу, которую он должен выполнить. Он должен фокусироваться на конкретных действиях пользователя и ответах системы, связанных с этой целью.
3. Модульность: Use case должен быть модульным и независимым друг от друга. Он должен описывать отдельный, самодостаточный сценарий без перекрытий или общих шагов.
4. Обработка исключений: Включите альтернативные и исключительные сценарии для предвидения и описания того, как система должна вести себя при неожиданных действиях пользователя или ошибке системы.
5. Интересы заинтересованных сторон: Учитывайте интересы и требования всех заинтересованных сторон, вовлеченных в проект, включая конечных пользователей, администраторов и техническую поддержку, при написании use case.
В целом, хорошие use cases должны быть ясными, основываться на реалистичных условиях и описывать все важные аспекты взаимодействия пользователя с системой. Эти критерии помогут бизнес-аналитику создавать полезные и эффективные сценарии использования.
📎Материалы по теме:
- Use case. Инструкция по работе со сценариями использования для молодого аналитика
- Как сделать удобный продукт: на примерах разбираем критерии хорошего Use case
📍Вопрос 2: Напишите пример Use Cases
✅ Краткий ответ:
Use Case: Регистрация пользователя
Описание:
Этот use case показывает, как новый пользователь может зарегистрировать аккаунт на интернет-магазине.
Основной actor: Новый пользователь
Предусловия:
- Пользователь открыл страницу регистрации.
- Пользователь находится на странице регистрации.
Шаги:
1. Пользователь открывает форму регистрации.
2. Пользователь вводит свое полное имя, адрес электронной почты и желаемый пароль.
3. Пользователь нажимает кнопку "Зарегистрироваться".
4. Система проверяет введенные данные.
5. Система проверяет, не зарегистрирован ли уже указанный адрес электронной почты.
6. Система отправляет пользователю письмо для подтверждения.
7. Пользователь получает письмо для подтверждения и переходит по указанной ссылке.
8. Система проверяет адрес электронной почты и подтверждает его.
9. Система выводит сообщение о подтверждении и автоматически выполняет вход пользователя в приложение.
Альтернативные сценарии:
- Если адрес электронной почты уже зарегистрирован, система выводит сообщение об ошибке и предлагает пользователю войти непосредственно или сбросить пароль.
- Если пользователь не получает письмо для подтверждения, он может запросить его повторно.
Постусловия:
- Пользователь зарегистрирован и авторизован на интернет-магазине.
📎Материалы по теме:
- Use case - что это + 3 примера
- Use case. Что это такое и зачем они нужны? С примерами
Источник: @ba_and_sa
‼️Предыдущие части смотрите по #собеседование #вопросыссобеседования
#вопросыссобеседования | @ba_and_sa
Часть 13:
📍Вопрос 1: Что такое Use Case и какие критерии написания вы знаете?
✅Краткий ответ:
Use case - это текстовое представление взаимодействия между действующими сторонами (actors - пользователями, системами или внешними сущностями) и системой или программным приложением.
Другими словами Use case - это часть требований к ПО. Он помогает разработать качественный продукт, от которого пользователь получит ожидаемый результат.
Use case состоит из:
- Заголовок
- Участники
- Предусловие
- Шаги (описание сценария)
- Результат или гарантии успеха
- Альтернативные сценарии
- Постусловие
Критерии для написания use case:
Вот некоторые из них:
1. Ясность и простота: Use case должен быть написан четко и лаконично, избегая технической терминологии, чтобы его можно было легко понять как техническими, так и не-техническими заинтересованными сторонами.
2. Ориентированность на цель: Каждый use case должен четко определять основную цель или задачу, которую он должен выполнить. Он должен фокусироваться на конкретных действиях пользователя и ответах системы, связанных с этой целью.
3. Модульность: Use case должен быть модульным и независимым друг от друга. Он должен описывать отдельный, самодостаточный сценарий без перекрытий или общих шагов.
4. Обработка исключений: Включите альтернативные и исключительные сценарии для предвидения и описания того, как система должна вести себя при неожиданных действиях пользователя или ошибке системы.
5. Интересы заинтересованных сторон: Учитывайте интересы и требования всех заинтересованных сторон, вовлеченных в проект, включая конечных пользователей, администраторов и техническую поддержку, при написании use case.
В целом, хорошие use cases должны быть ясными, основываться на реалистичных условиях и описывать все важные аспекты взаимодействия пользователя с системой. Эти критерии помогут бизнес-аналитику создавать полезные и эффективные сценарии использования.
📎Материалы по теме:
- Use case. Инструкция по работе со сценариями использования для молодого аналитика
- Как сделать удобный продукт: на примерах разбираем критерии хорошего Use case
📍Вопрос 2: Напишите пример Use Cases
✅ Краткий ответ:
Use Case: Регистрация пользователя
Описание:
Этот use case показывает, как новый пользователь может зарегистрировать аккаунт на интернет-магазине.
Основной actor: Новый пользователь
Предусловия:
- Пользователь открыл страницу регистрации.
- Пользователь находится на странице регистрации.
Шаги:
1. Пользователь открывает форму регистрации.
2. Пользователь вводит свое полное имя, адрес электронной почты и желаемый пароль.
3. Пользователь нажимает кнопку "Зарегистрироваться".
4. Система проверяет введенные данные.
5. Система проверяет, не зарегистрирован ли уже указанный адрес электронной почты.
6. Система отправляет пользователю письмо для подтверждения.
7. Пользователь получает письмо для подтверждения и переходит по указанной ссылке.
8. Система проверяет адрес электронной почты и подтверждает его.
9. Система выводит сообщение о подтверждении и автоматически выполняет вход пользователя в приложение.
Альтернативные сценарии:
- Если адрес электронной почты уже зарегистрирован, система выводит сообщение об ошибке и предлагает пользователю войти непосредственно или сбросить пароль.
- Если пользователь не получает письмо для подтверждения, он может запросить его повторно.
Постусловия:
- Пользователь зарегистрирован и авторизован на интернет-магазине.
📎Материалы по теме:
- Use case - что это + 3 примера
- Use case. Что это такое и зачем они нужны? С примерами
Источник: @ba_and_sa
‼️Предыдущие части смотрите по #собеседование #вопросыссобеседования
🔥13👍6❤3👏3
Как на ранних стадиях проекта получить максимум информации от заказчика за минимум времени, USM как способ снизить риски
Читать статью | Analyst IT
Читать статью | Analyst IT
Хабр
Как на ранних стадиях проекта получить максимум информации от заказчика за минимум времени, USM как способ снизить риски
Введение Данная статья вторая из цикла про создание Карт процессов. Как и в предыдущей статье я буду касаться применения гибких методологий в проектах Waterfall, то в данном материале я покажу как...
❤3
От концепции до внедрения: пошаговый гид создания системы управления знаниями с нуля. Опыт «ОАК»
Читать статью | Analyst IT
Читать статью | Analyst IT
Хабр
От концепции до внедрения: пошаговый гид создания системы управления знаниями с нуля. Опыт «ОАК»
Старые песни о главном Привет! Это Виталий Чесноков, сооснователь TEAMLY . Мы делаем нашу альтернативу Confluence и Notion, а ещё собираем успешные кейсы управления знаниями в российских...
❤6👍3
Подходы к роботизации процессов в госсекторе: кейс применения программных роботов
Читать статью | Analyst IT
Читать статью | Analyst IT
Хабр
Подходы к роботизации процессов в госсекторе: кейс применения программных роботов
Ни для кого не секрет, что госсектор живет по своим правилам. Правила эти довольно специфичны и зачастую ограничений здесь гораздо больше, чем в коммерческом секторе. Требования законодательства и...
Forwarded from BApedia | Бизнес-анализ
О критериях качества требований
Тема критериев качества требований затрагивается во многих статьях и публикациях, но, к сожалению, часто сводится к перечислению критериев и определений к ним. Именно поэтому автор хотел бы затронуть более практические аспекты.
Перейти к статье | BApedia
Тема критериев качества требований затрагивается во многих статьях и публикациях, но, к сожалению, часто сводится к перечислению критериев и определений к ним. Именно поэтому автор хотел бы затронуть более практические аспекты.
Перейти к статье | BApedia
❤3👍3
Forwarded from Business | System analyst
API (Application Programming Interface) – это набор правил и протоколов, позволяющих различным программным системам взаимодействовать друг с другом. В современном мире разработки программного обеспечения API стал неотъемлемой частью системной архитектуры, позволяя разделить функциональность программ на логические блоки и предоставлять возможность использования этих блоков другими системами, как внутренними, так и внешними.
При разработке и эксплуатации API одним из наиболее важных и часто недооцениваемых аспектов является его документирование. Хорошо задокументированное API может стать ключевым фактором успеха проекта, упростив интеграцию с ним и ускорив процесс разработки.
Документирование API представляет собой процесс создания достаточно подробной и понятной документации, которая описывает все функции, структуру данных, методы взаимодействия и требования для его использования. Документация должна быть доступной и понятной для разработчиков, которые будут интегрировать свои системы с API.
Важными аспектами при документировании API являются:
✍🏼1. Описание ресурсов и методов: Документация должна содержать описание всех доступных ресурсов и методов, которые поддерживает API. Каждый ресурс должен быть подробно описан, включая его структуру данных, список полей, доступные методы и возможные запросы/ответы.
📌2. Примеры использования: Хорошая документация должна содержать множество примеров использования API. Примеры помогут разработчикам быстрее разобраться в функциональности и особенностях API, а также позволят им быстрее начать пользоваться им.
🌐3. Схемы данных: Для каждого ресурса API должны быть предоставлены схемы данных, описывающие структуру объектов, передаваемых по API. Схемы данных могут использоваться в процессе валидации запросов и ответов, а также для генерации моделей данных в клиентском коде.
😨4. Ошибки и исключения: Документация должна содержать список возможных ошибок и исключений, которые могут возникнуть при работе с API. Каждая ошибка должна быть подробно описана, включая информацию о причинах ее возникновения и возможные способы ее решения.
🔢5. Версионность: Важным аспектом документации API является указание версии API, чтобы разработчики могли быть уверены, что они используют актуальную версию. Необходимо предоставлять возможность переключения на более новые версии, сохраняя обратную совместимость с предыдущими версиями.
⏱6. Частые обновления: Документация API должна быть актуальной и регулярно обновляться с выпуском новых функций и исправлениями. Это поможет снизить степень путаницы у разработчиков и повысит удовлетворенность пользователей API.
📑7. Интерактивная документация: Для удобства использования API стоит предусмотреть возможность создания интерактивной документации, где разработчики могут отправлять запросы и видеть результаты в реальном времени, а также иметь возможность пробовать различные последовательности запросов.
Правильное документирование API является важным шагом для обеспечения успешной интеграции и сотрудничества с другими системами. Четкая, полная и понятная документация может значительно упростить жизнь разработчикам и сэкономить время и усилия при работе с API.
Материалы по теме:
- Документирование API
- Что такое API документация и как ее правильно составить и использовать?
- How to Write Good API Documentation
При разработке и эксплуатации API одним из наиболее важных и часто недооцениваемых аспектов является его документирование. Хорошо задокументированное API может стать ключевым фактором успеха проекта, упростив интеграцию с ним и ускорив процесс разработки.
Документирование API представляет собой процесс создания достаточно подробной и понятной документации, которая описывает все функции, структуру данных, методы взаимодействия и требования для его использования. Документация должна быть доступной и понятной для разработчиков, которые будут интегрировать свои системы с API.
Важными аспектами при документировании API являются:
✍🏼1. Описание ресурсов и методов: Документация должна содержать описание всех доступных ресурсов и методов, которые поддерживает API. Каждый ресурс должен быть подробно описан, включая его структуру данных, список полей, доступные методы и возможные запросы/ответы.
📌2. Примеры использования: Хорошая документация должна содержать множество примеров использования API. Примеры помогут разработчикам быстрее разобраться в функциональности и особенностях API, а также позволят им быстрее начать пользоваться им.
🌐3. Схемы данных: Для каждого ресурса API должны быть предоставлены схемы данных, описывающие структуру объектов, передаваемых по API. Схемы данных могут использоваться в процессе валидации запросов и ответов, а также для генерации моделей данных в клиентском коде.
😨4. Ошибки и исключения: Документация должна содержать список возможных ошибок и исключений, которые могут возникнуть при работе с API. Каждая ошибка должна быть подробно описана, включая информацию о причинах ее возникновения и возможные способы ее решения.
🔢5. Версионность: Важным аспектом документации API является указание версии API, чтобы разработчики могли быть уверены, что они используют актуальную версию. Необходимо предоставлять возможность переключения на более новые версии, сохраняя обратную совместимость с предыдущими версиями.
⏱6. Частые обновления: Документация API должна быть актуальной и регулярно обновляться с выпуском новых функций и исправлениями. Это поможет снизить степень путаницы у разработчиков и повысит удовлетворенность пользователей API.
📑7. Интерактивная документация: Для удобства использования API стоит предусмотреть возможность создания интерактивной документации, где разработчики могут отправлять запросы и видеть результаты в реальном времени, а также иметь возможность пробовать различные последовательности запросов.
Правильное документирование API является важным шагом для обеспечения успешной интеграции и сотрудничества с другими системами. Четкая, полная и понятная документация может значительно упростить жизнь разработчикам и сэкономить время и усилия при работе с API.
Материалы по теме:
- Документирование API
- Что такое API документация и как ее правильно составить и использовать?
- How to Write Good API Documentation
👍10❤5🔥5
Какой должна быть user_story, и что общего у системных аналитиков и голливудских сценаристов
Читать статью | Analyst IT
Читать статью | Analyst IT
Хабр
Какой должна быть user_story, и что общего у системных аналитиков и голливудских сценаристов
«Тарас, за что ты получаешь свои деньги? Ты же просто рассказываешь истории!» За то, что я хорошо их рассказываю. С user story всё как в Голливуде: кажется, что многие сериалы похожи друг на друга, но...
👍6🔥4❤3
Forwarded from Product management | IT
This media is not supported in your browser
VIEW IN TELEGRAM
Когда отправил заказчику макет сайта на утверждение, а он предъявляет, что на сайте ничего не работает
😁47🤣18💯5👍1
Планировать нельзя сойти с ума: как не забыть ни про проекты, ни про людей
Читать статью | Analyst IT
Читать статью | Analyst IT
Хабр
Планировать нельзя сойти с ума: как не забыть ни про проекты, ни про людей
Привет, я Вика Синельникова — руководитель отдела спецпроектов в KTS . Рассказываю, как еженедельно планировать команду на большой объем проектов и не сойти с ума. Что в статье: Как планирование...
❤5👍5
Forwarded from Business | System analyst
Алоха! Сегодня продолжаем разбирать вопросы, которые любят задавать на собеседовании на роль BA/SA и затронем тему пользовательских историй / user story
#вопросыссобеседования | @ba_and_sa
Часть 14:
📍Вопрос 1: Что такое user story? Какие критерии их написания вы знаете?
✅Краткий ответ:
User story - это краткое и затрагивающее интересы пользователя описание конкретной функциональности или возможности, отражающее потребности и ожидания конечного пользователя. Оно обычно составляется простым и нетехническим языком и имеет определенный формат, обеспечивающий ясность и эффективность коммуникации между заинтересованными сторонами и командами разработки
Критерии написания user story:
1. Ориентированность на пользователя или ценность: User story должна фокусироваться на потребностях, мотивациях и целях конечных пользователей. Она должна ясно формулировать, чего пользователь хочет достичь и почему это важно для него.
2. Независимость и малая размерность: User story должна быть достаточно маленькой, чтобы быть завершенной в рамках одной итерации разработки, обычно 1-2 недели. Она также должна быть независимой от других историй, чтобы обеспечить гибкость в их приоритезации и планировании.
3. Тестуемость: Каждая user story должна быть написана таким образом, чтобы ее критерии приемки могли быть четко определены и протестированы. Это помогает убедиться в том, что команда разработки и заинтересованные стороны имеют общее понимание успешной реализации.
4. Общая гранулярность: Избегайте слишком детализированных или мелких user story. Лучше фокусироваться на высокоуровневой функциональности, оставляя возможность для команды разработки определить детали при реализации.
5. Оцениваемость: Каждая User Story должна быть оцениваемой. Команда должна иметь возможность оценить сложность и объем работы, необходимых для реализации каждой истории. Это помогает команде планировать и управлять процессом разработки.
📎Материалы по теме:
- Пользовательские истории в разработке
- Как писать User Stories и зачем они нужны
- Как разработать критерии приёмки для User Story
📍Вопрос 2: Приведите пример user store
✅ Краткий ответ:
Пример хорошо написанной пользовательской истории:
User story строится исходя из шаблона:
«Как» - «Я хочу» - «Чтобы»
Как зарегистрированный пользователь,
Я хочу иметь возможность сбросить свой пароль,
Чтобы я мог восстановить доступ к своему аккаунту, если я его забуду.
Критерии приемлемости:
- На странице входа должна быть ссылка «Забыли пароль».
- Щелчок по ссылке «Забыли пароль» должен перенаправить пользователя на страницу сброса пароля.
- Страница сброса пароля должна предлагать пользователю ввести свой зарегистрированный адрес электронной почты.
- После отправки адреса электронной почты система должна отправить электронное письмо со ссылкой для сброса пароля.
- Щелчок по ссылке сброса пароля в электронном письме должен перенаправить пользователя на страницу, где он может ввести новый пароль.
- При успешном сбросе пароля пользователь должен получить подтверждение и быть перенаправленным на страницу входа
📎Материалы по теме:
- User Story: пора применять правильно
- Пользовательские истории с примерами и шаблоном
Источник: @ba_and_sa
‼️Предыдущие части смотрите по #собеседование #вопросыссобеседования
#вопросыссобеседования | @ba_and_sa
Часть 14:
📍Вопрос 1: Что такое user story? Какие критерии их написания вы знаете?
✅Краткий ответ:
User story - это краткое и затрагивающее интересы пользователя описание конкретной функциональности или возможности, отражающее потребности и ожидания конечного пользователя. Оно обычно составляется простым и нетехническим языком и имеет определенный формат, обеспечивающий ясность и эффективность коммуникации между заинтересованными сторонами и командами разработки
Критерии написания user story:
1. Ориентированность на пользователя или ценность: User story должна фокусироваться на потребностях, мотивациях и целях конечных пользователей. Она должна ясно формулировать, чего пользователь хочет достичь и почему это важно для него.
2. Независимость и малая размерность: User story должна быть достаточно маленькой, чтобы быть завершенной в рамках одной итерации разработки, обычно 1-2 недели. Она также должна быть независимой от других историй, чтобы обеспечить гибкость в их приоритезации и планировании.
3. Тестуемость: Каждая user story должна быть написана таким образом, чтобы ее критерии приемки могли быть четко определены и протестированы. Это помогает убедиться в том, что команда разработки и заинтересованные стороны имеют общее понимание успешной реализации.
4. Общая гранулярность: Избегайте слишком детализированных или мелких user story. Лучше фокусироваться на высокоуровневой функциональности, оставляя возможность для команды разработки определить детали при реализации.
5. Оцениваемость: Каждая User Story должна быть оцениваемой. Команда должна иметь возможность оценить сложность и объем работы, необходимых для реализации каждой истории. Это помогает команде планировать и управлять процессом разработки.
📎Материалы по теме:
- Пользовательские истории в разработке
- Как писать User Stories и зачем они нужны
- Как разработать критерии приёмки для User Story
📍Вопрос 2: Приведите пример user store
✅ Краткий ответ:
Пример хорошо написанной пользовательской истории:
User story строится исходя из шаблона:
«Как» - «Я хочу» - «Чтобы»
Как зарегистрированный пользователь,
Я хочу иметь возможность сбросить свой пароль,
Чтобы я мог восстановить доступ к своему аккаунту, если я его забуду.
Критерии приемлемости:
- На странице входа должна быть ссылка «Забыли пароль».
- Щелчок по ссылке «Забыли пароль» должен перенаправить пользователя на страницу сброса пароля.
- Страница сброса пароля должна предлагать пользователю ввести свой зарегистрированный адрес электронной почты.
- После отправки адреса электронной почты система должна отправить электронное письмо со ссылкой для сброса пароля.
- Щелчок по ссылке сброса пароля в электронном письме должен перенаправить пользователя на страницу, где он может ввести новый пароль.
- При успешном сбросе пароля пользователь должен получить подтверждение и быть перенаправленным на страницу входа
📎Материалы по теме:
- User Story: пора применять правильно
- Пользовательские истории с примерами и шаблоном
Источник: @ba_and_sa
‼️Предыдущие части смотрите по #собеседование #вопросыссобеседования
🔥11❤4👍4