7) Есть подходы которые за написание тесткейзов заранее. Школа RST преимущественно против тесткейзов, за чеклисты, или гибкие тесткейзы, или их откладывание. Одного подхода заведомо нет. Где-то можно и полезно писать их подробно, где-то не нужно, где-то на них вообще нет времени и условий.  

Вообще каждый раз когда ты думаешь про "правильный" подход, хорошо бы и подумать где и почему он может быть правильным, неправильным, подходить (по условиям-ресурсам), не подходить, как оно может быть не так.

8) А ещё можешь вспомнить примеры книжек-док которые тебе нравятся, и делать как там. Но всё равно кому-то не понравится. :)

А чего контакты писать, в джире и конфлюэнсе же и так все видно, не?

Всяко бывако. Иногда в джире и конфлюэнсе ты deleted user , а по факту ты ещё на том же аккаунте, просто команду сменил. Или две.

Ого, не встречалась, спасибо

Но по сути написанного опять согласна)

А кто работал с требованиями к проектам. Возник такой вопрос, у меня вот есть юзер стори, требования и прочее. Но в первую же очередь надо по факту как можно больше претензий найти и задать вопросы по исключительным ситуациям которые не описаны, в ту сторону копаю ?
Если на примере интернет магазина - юзер может выбрать товары и их заказать. Про флоу отказа(отмены) заказа ничего не написано.
Правильно ли я думаю что мне надо уточнить конкретнее как будет этот флоу работать и что делать если скажем - заказ оплачен но отменен юзером?

Просто помню что в первую очередь позитивные проверки, в контексте требований - задать вопросы по тому что уже написано и уточнить как это будет правильно работать.
А потом уже пытаться "сломать систему" не типичными ситуациями ? Или этот этап вынести на потом? 🙄

Куа юа что то не особо захотели ответить ))) Мож тут эксперты есть ? )

да, все норм =)

Я не знаю, как на это ответить. Вдруг у тебя стартап и спасибо и на том, что хоть что-то в требованиях есть

да не, тут просто вопрос. Моя цель это доебаться до всего, или лучше сделать упор на бизнес флоу от заказчика который он описал на сегодня а исключительные ситуации оставить на потом и не выносить это всё на первые созвоны чтоб не пугать заказчика ? )

Так-то нужно
1. Чтобы все работало в случае ожидаемого поведения (товары в корзину добавлялись, например)
И уже 2. Чтобы в случае неожиданного поведения все не ломалось а тоже как-то адекватно работало

А почему отмена заказа єто не бизнес флоу?

Я б спросила, когда лучше уточнять неописанное

Может там другой состав участников на встрече нужен

бизнес флоу, но тут вопрос про эксепшен ситуейшон. Когда скажем произшла какая то хуйня. Скажем два заказа на один товар а он один на складе, и кто изних получит этот товар(имею ввиду админ не успел обновить наличие)

Ну скажи что у тебя много вопросов и спроси когда их удобнее обсудить, все равно же когда-то придётся

Возможно на встрече-знакомстве не стоит этого делать

Мы же рил не знаем твоих процессов