Просмотр сообщений
256
Системный Анализ и Требования / Re: Классификация требований
« : 22 Мая 2013, 15:22:09 »Конечно является, ведь именно его деятельность (поиск и покупка товара) автоматизирует система. А вот тут что посадите, то и вырастет. Хотите получить АРМ, будет у вас АРМ. А хотите получить распределенную информационную систему с архитектурой "клиент-сервер" - формулируйте соответствующие требования.
Конечно, я имею в виду в первую очередь разработку и оформление требований по ГОСТу (всерьёз обсуждать этапы эскизного и технического проекта, методики и программы испытаний применительно к интернет-магазинам я пока морально не готов
.Нет, покупатель не является "персоналом". А если выйти немного за рамки ГОСТа, он также не является и обычным "пользователем" в концепции ролей пользователей. Его цели не выводятся логическим путём из бизнес-целей создания системы (потому что цель системы - продавать, а не покупать). И поэтому подход к выявлению потребностей покупателей и трансформации их в требования к системе нужен другой.
Проектировщиков сбивает с толку то, что некоторые побочные виды деятельности покупателя действительно хорошо автоматизируются. Например, поиск товара, как здесь было сказано, а я бы к нему добавил ещё и сравнение товаров. Они очень хорошо ложатся на диаграмму юзкейсов, по ним наработан большой опыт разработки. Результат, например, такой: я (и не только я) с удовольствием использую прекрасный интернет-магазин mvideo.ru для поиска и сравнения товаров по характеристикам, а, совершив выбор, покупаю его в другом месте (иду, например, на яндекс.маркет и там выбираю уже по цене, или заезжаю в MediaMarkt по дороге домой, чтобы подержать товар в руках перед окончательным решением о покупке).
Чтобы мотивировать меня покупать тут же, не уходя с сайта, нужны новые подходы. Они есть, конечно, и в первую очередь их прорабатывают в новой отрасли, которую сейчас называют "юзабилити" или "проектирование пользовательского взаимодействия", и которая уже тесно связана с психологией (поэтому я и говорю, что современные подходы выявления и разработки требований переползают в гуманитарную область). Но тут на первый план выходит нефункциональная сторона системы. Нефункциональные требования (юзабилити) оказываются важнее, их проработка обходится дорого, и они порождают в конечном итоге очень большую долю программного кода при разработке.
А в АС функциональная сторона по определению стоит на первом месте (реализует информационную технологию выполнения установленных функций). И ментальные модели, сформировавшиеся у людей, привыкших или обученных разрабатывать "автоматизированные системы", приводят к их осознанному или неосознанному сопротивлению. Что видно, например, на том же сайте РЖД: система отвергает попытки очеловечить интерфейс покупки билетов онлайн. Но им хорошо, они монополисты, и пока могут себе это позволить.
Но бог с ними, с интернет-магазинами. Осознание того, что нефункциональная сторона стала важнее функциональной, приходит и в энтерпрайз. Интерфейсы всех современых автоматизированных банковских систем, например, ужасны. Это бесконечные перекрывающиеся таблицы, формы из десятков элементов, огромное количество непонятных условных обозначений. И уже есть спрос на "АБС с человеческим лицом". И я думаю, что та компания-производитель АБС, которая первой решится на коренную переработку подхода к проектированию, совершит революцию в своём сегменте типа той, которую в массовом масштабе совершила Apple.
