Форум Сообщества Аналитиков
Дисциплины => Системный Анализ и Требования => Тема начата: NewbieAnalist от 06 Мая 2016, 17:56:45
-
Привет, коллеги!
Я пробежался по топикам форума, увидел, что многие пишут требования в виде Use case (ВИ). Поделитесь опытом, как вы согласуете их с Заказчиком? С какими проблемами при этом сталкиваетесь и как решаете?
Наша специфика:
Мы занимаемся внедрением и доработкой платформы определенного вендора для различных Заказчиков.
Раньше писали требования "на естественном языке", в виде текста вперемешку с картинками. Заказчиков, это, в принципе, всегда устраивало. Но у такого подхода есть множество минусов, я которых, я думаю, все знают.
Сейчас на одном из проектов начали использовать ВИ. Но заказчик не согласен с таким подходом и хочет чтобы требования были написаны в виде "пользовательской инструкции", т.е. текста с кучей картинок, на которых должны быть обведены кнопки, и поля в которые надо будет тыкать пользователям.
Аргументирует тем, что ВИ непонятны пользователям, т.к. не содержат описания интерфейса, и у пользователей не складывается в голове представление о том, как работать с будущей системой. При этом мы снабжаем ВИ ссылками на макеты формы.
-
Добрый день.
А что Вас смущает ?
То, что у Кокберна написано не тащить интерфейсы в юзкейс?
Не будьте в плену предрассудков. Кокберн имел в виду разработки с нуля.
Если Ваша разработка идёт внутри уже работающей системы с устоявшимся UI, который Вы не планируете ломать - добавляйте в кейсы пользовательского уровня элементы интерфейса. Получите пользовательский мануал. Сразу. Что вроде бы и требуется.
Нужно только предусмотреть 2 варианта визуализации кейса, с картинками и без. Если это позволяет инструмент.
Расшифрую.
Раньше писали требования "на естественном языке", в виде текста вперемешку с картинками. Заказчиков, это, в принципе, всегда устраивало.
А теперь начните писать не просто текст с картинками, а юзкейс с картинками.
Чем отличается юзкейс от простого текста Вы хорошо понимаете ? Правильно, алгоритмичностью. Что позволяет лучше видеть явные пропуски и альтернативы в планируемой разработке. И соответственно уменьшить количество "не учли" и "не подумали" в продуктиве.
Как результат.
Вы сохраните очевидные минусы в скорости разработки документации, связанные с необходимостью прорабатывать элементы интерфейса на ранних стадиях.
Вы сохраните плюсы в виде заказчиков, которые видят постановку в привычной форме, только лучше.
Вы получите новые плюсы в виде готовых пользовательских мануалов.
В итоге всё-равно окажетесь в плюсе за счёт более чёткой постановки задачи и сокращения времени на выход в прод.
-
Андрей, спасибо за развернутый ответ.
Попробуем поиграться с картинками.
А вы как-то разъясняете клиентам, что такое use case, почему в таком формате пишете требования? Или у них не возникает вопросов и "погружение" не нужно?
Кто-то привык видеть в требованиях описание "фич", а мы хотим как раз от этого отойти.
-
А вы как-то разъясняете клиентам, что такое use case, почему в таком формате пишете требования? Или у них не возникает вопросов и "погружение" не нужно?
Кто-то привык видеть в требованиях описание "фич", а мы хотим как раз от этого отойти.
А вы можете чисто для себя и своей команды разъяснить зачем вам понадобились юз-кейсы? Если объяснение будет убедительным, то и заказчик скорее всего поймёт.
Не пытаетесь ли вы "развести" заказчика ради собственного интереса поэкспериментировать с технологией, ради ограничений вашего нового инструмента управления требованиями и прочих неуважительных причин ?
PS: как вариант, можно разрисовать какую-нибудь небольшую задачу юз-кейсами и "по старому" и на этом примере продемонстрировать преимущества вашего подхода.
-
А вы можете чисто для себя и своей команды разъяснить зачем вам понадобились юз-кейсы? Если объяснение будет убедительным, то и заказчик скорее всего поймёт.
...
PS: как вариант, можно разрисовать какую-нибудь небольшую задачу юз-кейсами и "по старому" и на этом примере продемонстрировать преимущества вашего подхода.
Присоединюсь.
Юзкейсы очень хороши для поиска ошибок в требованиях и для управления ходом работ. Если заказчик не желает заниматься ни тем ни другим, то другие формы представления могут оказаться более привлекательными.
-
А вы можете чисто для себя и своей команды разъяснить зачем вам понадобились юз-кейсы? Если объяснение будет убедительным, то и заказчик скорее всего поймёт.
Мы для себя, вроде, выяснили для чего хотим использовать юз-кейсы.
Вопрос не в том, как заказчику обосновать такой подход. Вопрос - нужно ли вообще заказчику заранее рассказывать, что такое юз.кейсы и как мы их пишем?
Вы, в своей практике, проводите какое-нибудь "обучение" Заказчика, при условии, что это новый для вас Заказчик и Проект? Скажем так, чтобы настроить всех на одну волну?
-
Говорите заказчику, что описываете требования в форме сценариев, которые потом можно использовать не только для разработки, но и для тестирования и для пользовательской документации.
Слово «юскейс» не произносите.
Я например щас пишу одно ТЗ по ГОСТ 34, так там прямо в конкурсной документации написано, что в ТЗ должны быть сценарии.
-
Чтобы подготовить заказчика и разработчиков, конечно желательно до начала работ показать ему примеры.
Например, я обычно пишу 1-2 сценария на эту систему в формате юскейсов и показываю Заказчику для согласования (формата).