Comments 2
Тут остается вопрос с пользовательскими требованиями. Зачастую требования к результату сводятся к одной кнопке "сделать все". А в последнее время добавилось: "нам просто нужна замена ..., которые ушли с рынка России"
"Сделать все" - эта проблема стара как мир :) А классические проблемы требуют классического решения. Если заказчик не может или не хочет детализировать требования стоит применить старое доброе интервьюирование и технику "5 почему".
Проблема импорта замещения не так стара, она стала актуальна последние лет 10. Тем не менее, если обратится к классикам и на этот вопрос тоже можно найти ответ :) Так Том ДеМарко в своей книге "Deadline. Роман об управлении проектами" описывает особенности работы над проектом QuicckerStill, функционал которого практически полностью копирует функционал уже имеющихся на рынке решений. Для того чтобы сократить сроки реализации, команда проекта отказалась от этапов выявления и анализа требования и сразу приступила к проектированию системы. При этом основным источником пользовательских и функциональных требований выступало руководство пользователя уже реализованного, успешного на рынке аналога.
Лично мне, такой подход кажется удачной идеей. Не нужно изобретать велосипед, если кто-то уже сделал это за вас. Более того меня как конечного пользователя продуктов разработанных как аналоги ушедших с рынка, очень радует копирование функционала и использование похожих элементов интерфейса. Потому что я могу быстро начать использовать новый продукт, пере использовать свой пользовательский опыт и не тратить время на обучение.
В целом, мне кажется что описанные вами проблемы больше относятся к работе с возражениями, чем к выявлению требований.
Гайд для системного аналитика: как управлять требованиями на разных этапах проекта. Часть 2: планирование и исполнение