Анализ требований

[Phoenix-lib]

В данном случае много зависит от опыта заказчика( ведь если у него не было опыта заказа какого либо ПО, то это вообще предмет отдельной статьи), его масштаба (малый бизнес, средний или крупный) и опытности тех кто его задачи будет решать. Самый простой пример, клиент говорит, хочу акцию, вопрос она нужна одна или их будет много? ну пока одну, через 2 недели он хочет еще 1, через месяц их стало 7, текущая реализация не могла выполнить эти требования без снижения производительности. А основная проблема была в том, что заказчик не знал своих требований изначально и лучшим решением было поставить в условия предоплаты, оплаты по часам, разбивать работу на этапы и в случае если ожидания и луны не сошлись то все переделывается за счет заказчика ( за исключением реальных багов) и все становится на свои места и думать начинают и требования адекватные появляются после 2-3 переделок. Т.к дешевле потерять клиента, чем потом переделывать клиентскую дурость в течении N (часов, дней, месяцев) за копейки из-за юридических граблей.

[master1312]

Требование — это не функция системы, а описание задачи или проблемы, которую хочет решить конкретный человек.

Вот мне лично эта фраза прям понравилась. Мне кажется, что написать требования и не написать юзкейсы — зря потратить время. Юзкейсы обязательно надо показать заказчику, чтобы он прослезился и сказал: «Да, именно так я и хочу чтобы оно работало».

[amokryshev]

Не вижу противоречия:) Просто use cases должен писать менеджер по продукту или аналитик, желательно сразу с wire frames или дизайн-макетами, а уже потом показывать Заказчику. Опять же я не встречал Заказчиков, которые могли качественно проверить use case, не видя макетов экранов.

[master1312]

Я имею ввиду, что юзкейсы (с макетами или хотябы без них) очень сильно помогают утрясти собственно сами требования. Без низ риск накосячить гораздо выше. Можно сказать, они как раз и помогают «продать» требования заказчику, так как показывают ему, как будет работать еще не разработанный продукт.

[amokryshev]

Ну да, тоже согласен:) Что не отменяет необходимости иметь список того «Зачем» нужна система, а не только того «Как она должна работать».

[master1312]

А, Вы наверное подумали, что я предлагаю от требований отказаться? Не-не-не, требования — это мастхэв номер 1, и спорить даже не буду. :) Нет требований — нет проекта.

[qmax]

В семантике юзкейсов существуют «абстрактные юзкейсы» с взаимосвязями типа «реализация», которые именно что соответствуют основным «бизнес/маркетинг» задачам, для которых обозначены конкретные юзкесы, которые реализуются уже в сценариях.

На верхнем уровне такой иерархи можно поместить абстрактный юзкейс типа «общение пользователей» или «рассказать о себе» с реализациями типа «директ сообщения», «заполнение профиля», «комментарии к профилю». И всё это на одной схеме.

[pastuh9090]

Очень интересный и свежий взгляд на данную тему. Обязательно постараюсь применить на проекте!)

[amokryshev]

Спасибо:)