Ещё одно хорошее правило: представьте, что разрабатываемая система содержит только кнопки, нажимая на которые пользователь достигает своей цели.

Отличная идея!

Прошу указать на мои недочеты

"Укажу" по части функционала.

Если в этом магазине не предполагается навороченной системы лояльности с баллами, мини-играми и девушками службы поддержки клиента, то вам совершенно не нужно заставлять посетителя сайта регистрироваться на нем. Плюсы:
- Потенциальный покупатель не будет отделен от покупок неприятной процедурой.
- Не надо разрабатывать соответствующие экранные формы и механизмы бэкэнда.

Вам не авторизовать посетителя надо, а всего лишь идентифицировать (все равно без предварительного созвона уже никто никуда ничего не везет). Идентифицировать достаточно легко: например, по номеру контактного телефона. "Клиентскую карточку" в БД оформите автоматически из данных, которые покупатель введет для доставки в первый раз.

Любить клиента нужно нежно.

"Укажу" по части функционала.

Если в этом магазине не предполагается навороченной системы лояльности с баллами, мини-играми и девушками службы поддержки клиента, то вам совершенно не нужно заставлять посетителя сайта регистрироваться на нем. Плюсы:
- Потенциальный покупатель не будет отделен от покупок неприятной процедурой.
- Не надо разрабатывать соответствующие экранные формы и механизмы бэкэнда.

Вам не авторизовать посетителя надо, а всего лишь идентифицировать (все равно без предварительного созвона уже никто никуда ничего не везет). Идентифицировать достаточно легко: например, по номеру контактного телефона. "Клиентскую карточку" в БД оформите автоматически из данных, которые покупатель введет для доставки в первый раз.

Любить клиента нужно нежно.

+1
Регистрация действительно сильно снижает конверсию. Поэтому она нужна:
* Для накопительной системы баллов
* Отслеживания статусов заказов на сайте (иногда это удобно)
* Защиты от ботов, накручивающих/скручивающих отзывы и оценки
* и т.д.

А для покупателя удобнее всего "купить в один клик". Вот идеальный функционал с моей точки зрения для книжного магазина:
* На форуме uml2.ru увидел линк на книгу по анализу, нажал
* Попал на описание товара
* начал "купить"
* ввел номер телефона и подтвердил желание купить
* закрыл броузер
Все, моя работа с сайтом закончилась.
Через 1 минуту мне перезвонили, мы договорились, каким почтоматом я воспользуюсь (это стоит всего 50 руб, в отличии от курьерки http://www.ozon.ru/context/detail/id/20171026/), вечером, возвращаясь с работы сунул в терминал наличку и забрал заказ.
От заказа до получения - 2 часа.
При повторном заказе оператор спросит: "Вам в тот же почтомат?"

Тот, кто сделает это первым в своем секторе рынка, получит преимущество перед конкурентами.

Сергей, а оплата — при получении в почтомате?
А, вижу. Мне удобней оплатить сразу, без налички )

Сергей, а оплата — при получении в почтомате?
А, вижу. Мне удобней оплатить сразу, без налички)

Правильно. Мы с тобой разные, нам удобно по разному.
Поэтому естественно нужно поддержать множество вариантов оплаты: оплата с счета в банке, при помощи карты и Pidion1300 принесенный курьером, вебмани, пайпал, банковский счет (говорить карта в корне неверно), со своего счета на сайте (заработок при помощи партнерки) и т. д.
Но это лучше не в ВИ. это другая категория требований.


PS. Кстати, популярную некогда партнерку забыли. А это еще куча ВИ.

Всем спасибо за советы! Особенно по "регистрации", буду реализовывать. Пока ДВИ отодвинулась на второй план, но когда я продолжу её корректировку, обязательно обращусь к Вам за советом.

Вам очень поможет введение понятия "Уровень ВИ".
* "авторизация" - уровень ниже уровня моря. И действительно, часто его лучше не включать. Это уровень программиста. Но. Авторизация может оказаться сильно не тривиальной и ее реализация может потребовать более 2 недель. В этом случае имеет смысл внести ее в реестр, как единицу планирования, а потом отдельно расписать.
* "добавить товар в корзину" - уровень моря, основная единица планирования (как правило).
* "Управление товаром в корзине" - обобщающий сценарий. Включает от 5 сценариев уровня моря

Предложение 1. На ДВИ лучше выносить ВИ одного уровня.
Предложение 2. Есть метод "Зачем <-> как". Один из вариантов - описываете бизнес идею сначала как результат, потом как набор действий, затем декомпозируете.
Например.
Книги по IT тематике стоят в США очень дорого. О, идея! В Индии полно дешевых репринтов. Наш интернет магазин будет позволять американцам дешево купить индийский репринт. Теперь нужно написать самый верхнеуровневый сценарий. Пишите.

Идея скорее всего не сработает, т.к. ЕМНИП ввоз в США книг очень сильно ограничен. Но для курсовой, сойдет.
Идея пересылать дешевые репринты в РФ (переводчики такие переводчики) тоже скорее всего не сработает, т.к. наши инженеры, "в булочную на такси не ездят книг по специальности не читают".

Некрокоммент: Местная озабоченность надуманным принципом "одна ДВИ -- один уровень всех ВИ на ней" позволила не заметить основные дефекты диаграммы: просматривать каталог гость и зарегистрированный пользователь обязаны, взявшись за руки; искать (?найти?) товары можно только в том случае, если этим займётся пара админ + зареганный пользователь. А всё почему, потому что в вузах плохо учат UMLю, якобы. 

Некрокоммент: Местная озабоченность надуманным принципом "одна ДВИ -- один уровень всех ВИ на ней" позволила не заметить основные дефекты диаграммы: просматривать каталог гость и зарегистрированный пользователь обязаны, взявшись за руки; искать (?найти?) товары можно только в том случае, если этим займётся пара админ + зареганный пользователь. А всё почему, потому что в вузах плохо учат UMLю, якобы.

Тут есть один момент. Научить нельзя, научиться можно. В ВУЗах может и правильному учат, только вот студенты не научаются, а потом на производстве им говорят, да какая разница, правильно или неправильно нарисовано, главное же тебя поняли

а потом на производстве им говорят, да какая разница, правильно или неправильно нарисовано, главное же тебя поняли

Даже не знаю, как на такое ответить. Может быть, авторы профстандартов недоглядели, не оборонили землянскую софтверную индустрию от такого непрофессионального подхода.

Даже не знаю, как на такое ответить. Может быть, авторы профстандартов недоглядели, не оборонили землянскую софтверную индустрию от такого непрофессионального подхода.

по-моему в землянском стандарте нет явных требований по знанию UML, и вообще еще в далеком 2011 году один землянский философ (известный правда в своих особых кругах), сказал, что поезд UML стоит в тупике, где ему и следует быть
В архитектурном канале регулярно вижу как те или иные диаграммы UML обругиваются. Не так давно ругали диаграмму классов, а вот диаграмму последовательности хвалят.

Кажись, UML гостировали. А нафига, если профи его не нужно знать, если профи позволительно рисовать и понимать какой-то псевдоUML под видом настоящего? [Марсианская риторика, если что.]

Кажись, UML гостировали.

А есть какие-то признаки? Это ведь должен быть докУмент какой-то?

А нафига, если профи его не нужно знать, если профи позволительно рисовать и понимать какой-то псевдоUML под видом настоящего? [Марсианская риторика, если что.]

А вот не знаю. Слушал выступление Александра Лучкова. Он определенно заявил, что тот не архитектор, если он не знает UML и не только его, и не может его использовать правильно.
Но даже на Linkendin интерес к теме UML как-то сильно угас.

А есть какие-то признаки? Это ведь должен быть докУмент какой-то?

Нету, ни признаков, ни докУментов. Приврало, по марсианскому обычаю. 
Как курьёз, есть геоинформационный ГОСТ Р 57668 -- калька с ISO 19115 и там содержится кусочек UMLя. Т. к. переводили геоспецы, то их ксенолингвист породил принцип Анти-Лизковы, согласно которому подклассы заменяются суперклассами. Теперь так, по ГОСТу.

Нету, ни признаков, ни докУментов. Приврало, по марсианскому обычаю. 
Как курьёз, есть геоинформационный ГОСТ Р 57668 -- калька с ISO 19115 и там содержится кусочек UMLя. Т. к. переводили геоспецы, то их ксенолингвист породил принцип Анти-Лизковы, согласно которому подклассы заменяются суперклассами. Теперь так, по ГОСТу.

Хахаха