Комментарии 9
В данном случае много зависит от опыта заказчика( ведь если у него не было опыта заказа какого либо ПО, то это вообще предмет отдельной статьи), его масштаба (малый бизнес, средний или крупный) и опытности тех кто его задачи будет решать. Самый простой пример, клиент говорит, хочу акцию, вопрос она нужна одна или их будет много? ну пока одну, через 2 недели он хочет еще 1, через месяц их стало 7, текущая реализация не могла выполнить эти требования без снижения производительности. А основная проблема была в том, что заказчик не знал своих требований изначально и лучшим решением было поставить в условия предоплаты, оплаты по часам, разбивать работу на этапы и в случае если ожидания и луны не сошлись то все переделывается за счет заказчика ( за исключением реальных багов) и все становится на свои места и думать начинают и требования адекватные появляются после 2-3 переделок. Т.к дешевле потерять клиента, чем потом переделывать клиентскую дурость в течении N (часов, дней, месяцев) за копейки из-за юридических граблей.
Требование — это не функция системы, а описание задачи или проблемы, которую хочет решить конкретный человек.
Вот мне лично эта фраза прям понравилась. Мне кажется, что написать требования и не написать юзкейсы — зря потратить время. Юзкейсы обязательно надо показать заказчику, чтобы он прослезился и сказал: «Да, именно так я и хочу чтобы оно работало».
Не вижу противоречия:) Просто use cases должен писать менеджер по продукту или аналитик, желательно сразу с wire frames или дизайн-макетами, а уже потом показывать Заказчику. Опять же я не встречал Заказчиков, которые могли качественно проверить use case, не видя макетов экранов.
Я имею ввиду, что юзкейсы (с макетами или хотябы без них) очень сильно помогают утрясти собственно сами требования. Без низ риск накосячить гораздо выше. Можно сказать, они как раз и помогают «продать» требования заказчику, так как показывают ему, как будет работать еще не разработанный продукт.
В семантике юзкейсов существуют «абстрактные юзкейсы» с взаимосвязями типа «реализация», которые именно что соответствуют основным «бизнес/маркетинг» задачам, для которых обозначены конкретные юзкесы, которые реализуются уже в сценариях.
На верхнем уровне такой иерархи можно поместить абстрактный юзкейс типа «общение пользователей» или «рассказать о себе» с реализациями типа «директ сообщения», «заполнение профиля», «комментарии к профилю». И всё это на одной схеме.
На верхнем уровне такой иерархи можно поместить абстрактный юзкейс типа «общение пользователей» или «рассказать о себе» с реализациями типа «директ сообщения», «заполнение профиля», «комментарии к профилю». И всё это на одной схеме.
Очень интересный и свежий взгляд на данную тему. Обязательно постараюсь применить на проекте!)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Анализ требований