Comments 12
При описании сценария использования важно соблюдать пошаговый план действий пользователя, указывая физическое действие пользователя.
Например, формулировка “добавил товар в корзину” неверная.
Правильно: “нажимает на кнопку “Добавить товар в корзину” и далее- реакцию системы на действия пользователя.
Почему второй вариант правильный? Кнопка - это уже конкретная реализация сценария. Или был UC с другим уровнем абстракции, где спроектировали, что будет кнопка?
В данном примере я хотела показать насколько детально необходимо описывать UC. Конечно, данный UC возможно описать либо при наличии макетов, либо при взаимной работе с дизайнером.
Я хотела сделать акцент именно на описание детальности шагов пользователя. Потому что формулировка "Добавил товар в корзину" - не объясняет, каким образом пользователь добавил товар в корзину
Анастасия, в качестве примера Вы использовали один из антипаттернов :((
Описывая в юзкейсе конкретную реализацию, мы сильно ограничиваем разработчиков в том, что они могли бы предложить лучшее решение (да и вообще, приносить решение в то время, когда выявляются и описываются требования - это тоже антипаттерн)
А вообще статья интересная, очень понравилась структурированность; объяснять вещи с нуля - это супер
Спасибо за комментарий! Мое главное правило в работе- коммуникация. И при написании ТЗ я всегда обращаюсь к команде разработки- для обсуждения и выбора подходящего решения. На основании этого- в ТЗ можно зафиксировать требования именно так, как необходимо их реализовывать. Видимо, это нужно было отметить в данной статье!
Конечно же, если нет возможности обсудить с разработчиками верность решения (и реализация не однозначна), то, действительно, не стоит ограничивать разработчиков в решении.
@AnastasiaKu, полностью согласен с @ValeryGL, пример не совсем удачный и является антипаттерном проектирования use cases. В своей практике стараюсь описывать без привязки к интерфейсу и конкретным решениям, которых может быть много. Мне показалось, что не хватает конкретных системных описаний (той же валидации), не увидел точек расширения и их отличий от альтернативных сценариев. Но, если статья для новичков, то многое описано хорошо и структурно. Спасибо большое за статью)
Деловой сценарий использования не затрагивает технологий, рассматривает систему как «черный ящик» и описывает бизнес-процесс
Зачем плодить понятия? Если есть бизнес-процесс, то пусть он им и останется - в этом случае будет описание бизнес-процесса.
Системный сценарий использования описывает что актер может сделать взаимодействуя с системой.
Я бы и это тоже делал через бизнес-процессы. А вот системные сценарии пишутся для проверки требований. Это позволит во первых проверить систему на соответствие ТЗ, а во вторых - получить готовый материал для ПМИ.
Я думаю, здесь можно применять как описание БП, так и использовать UC. Здесь на усмотрение аналитика, который работает над документацией. Я же просто привела примеры, как можно использовать UC.
В данной статье я рассматривала только один артефакт- UC. Я не вела в данной статье сравнение UC и бизнес-процесса, рассуждений, когда какой артефакт лучше использовать. Эта тема достойна отдельной статьи. Поэтому не до конца понимаю вашей претензии.
Вы серьезно не понимаете разницы между бизнес процессом и Use Case?
Согласна, что есть правило, что сценарий использования (основной и альтернативные) должен позволять достичь цели, а ошибки - выносить в ограничения/допущения/риски. Но по опыту работы в команде, и тестировщикам и разработчикам легче ориентироваться в ТЗ, когда в основном сценарии также отработаны альтернативные сценарии с ошибками. Это мое личное наблюдение.
Считаю, что аналитикам необходимо придерживаться правил и методологий, но всегда адаптировать свое ТЗ под команду и проект. Потому что в первую очередь- ТЗ должно быть легким к прочтению и понимаю для команды.
Я часто вижу, что дополнительным пунктом выносятся ошибки и исключения, в которых описываются действия, которые приводят к невыполнению сценария. Т.е. отличие от альтернативных сценариев в том, что альтернативные сценарии позволяют достичь поставленной цели, ошибки и исключения - нет.
В данном кейсе в ошибки и исключения можно вынести сценарий, когда пытается зарегистрироваться уже зарегистрированный в системе пользователь (у вас это альтернативный сценарий №2)
Use Case. Инструкция по работе со сценариями использования для молодого системного аналитика