Просмотр сообщений
61
Системный Анализ и Требования / Re: Давайте поговорим про Use Case и функции. В чем отличия?
« : 22 Июля 2016, 17:14:37 »Во-первых, посетителя сайта нельзя считать персоналом - составной частью АС. Он не винтик машины, обеспечивающий выполнение каких-то функций, а потребитель услуги.
Так их и не надо считать традиционным персоналом. Персонал АС-сайта это админы, контент-менеджеры и прочие копирайтеры. Ну, как я это вижу.
"Посетители" - это отдельная категория, которую и окучивать надо отдельно.
Это существенное отличие: действия персонала можно регламентировать, его можно и нужно обучать, для чего разрабатывается целый комплект документации.
Ну так-то да, посетитель у нас ходит, где хочет (а не куда ему разрешают или куда его за ручку водят), пишет в поля ввода что хочет (а не что разрешено по ФЛК), и туториалов для посетителей никто в глаза не видел.
Ну и персонал, конечно, не платит за услугу эксплуатации АС, а наоборот, платят обычно ему за то, что он с этой АС мучается.
Согласен. Прогресс не стоит на месте, и за право эксплуатировать АС уже денег берут. Не говоря уже о том, что это большая честь. Марк Твен обзавидовался бы.
Потребителя услуги регламентировать нельзя. Если продукт предназначен для решения сравнительно сложных специальных задач, можно дать ему рекомендации в виде руководства пользователя. Но не в том составе и не в тех форматах, которые предлагаются стандартами для АС. Иначе он проголосует ногами и деньгами за продукты конкурентов.
Ну как сказать... Если банковский вклад хотя бы на один процент выше, чем у конкурентов, посетителей сайта можно строить как угодно. Проверено, не разбегутся. Будут колоться, плакать, но продолжать.
Зачем для посетителей писать "в том составе и тех форматах", что и для специально обученных людей "при исполнении"? В рамках документирования АС вполне можно изготавливать легкие и непринужденные памятки. А то и комиксы.
Во-вторых, АС изначально ориентирована на автоматизацию определённых функций. Просто исходя из этого определения, функциональные требования выходят на первый план, а нефункциональные рассматриваются как ограничения, которые накладываются и на разработку, и на способы эксплуатации.
Не соглашусь. АС изначально ориентирована на достижение определенной цели, посредством (а может, и нет) решения определенных задач. А автоматизированные функции лишь служат этой цели.
В вебе то, что у аналитиков принято называть "нефункциональными требованиями", сейчас обычно является не ограничениями, а конкурентными преимуществами.
Тоже довольно спорно. Нефункциональные ограничения по пропускной способности, например, и в вебе никуда не делись. А вот "конкурентные преимущества" - они да, появились. Ибо в плановой экономике, откуда выросли наши АС, конкуренция была неактуальна. Но честно говоря не вижу, почему бы благородным донам просто не расширить список нефункциональных требований/возможностей новой категорией.
всё ради функциональности, без которой банк просто не сможет работать. Этим, кстати, объясняются кошмарный (с точки зрения обычного пользователя) UI абсолютного большинства банковских систем: функциональность всегда в приоритете, архитектуру поменять можно только путём разработки новой системы, а на всякие эти ваши юзабилити не остаётся ни времени, ни сил.
Просто бизнес, ничего личного. Так дешевле тому, кто весь этот банкет оплачивает. В очевидно подсчитываемых деньгах дешевле, по крайней мере.
А персонал можно и обучить, ему за это деньги платят.
Логично же.
В вебе такое отношение к пользователям не пройдёт.
Ну так и не надо. Это "традиционный" персонал дро... строить надо. А пользователя никто не запрещает облизывать, пока тот не отдаст все, что у него есть. Добровольно и с песней. Желательно даже, чтобы залез в долги и отдал больше, чем есть.