Замечания по документации проекта и содержанию
1. По-моему совсем было бы не лишним предоставить документ требования (запросы) заказчика или оценка целевой организации. Это дает более четкое ощущение контекста и понимание проблематики
2. Анализ проблем отсутствует и проблемы сразу объявлены. Кроме того проблем слишком много, а корневые причины не определены
3. Цели заявленные во многом качественные, а критерии достижения? измеримость?
например: 2.1.9 Увеличить контролируемость Закупок и улучшить планирование Закупок - это что будет значить, как это определить, что контролируемость увеличена и планирование улучшено?
далее выпишу за счет:
за счет консолидации информации и удобного пользовательского интерфейса
за счет консолидирования информации и повышения доступности документов
за счет консолидирования всех Заявок и возможности постоянного контроля со стороны руководства
за счет консолидирования информации
за счет быстрого получения необходимых требований (Заявки) Клиента
за счет консолидирования информации и хранения полной (всей) информации по работе с Заявками Клиента
Как видно основная проблема - отсутствие консолидирования информации, сложный доступ к хранимой информации, слабый контроль исполнения заявок. Как следствие:
забывают обрабатывать Заявки
забывают закупать оборудование - какого? откуда вдруг про оборудование вылезла информация
тормозят подписание документов - почему?
все валят друг на друга
сложность проведения статистики - что понимается под статистикой, что она позволяет сделать?
Далее напомню, что CRM классифицируется на оперативный, аналитический и коллаборационный. Вопрос: какого типа cRM планируется внедрять? оперативный насколько я понял. с элементами аналитического, коллаборационный как я понимаю не катит...
Ошибки по тексту:
3.1.2 Менеджер проекта (МП)
Выполняет работы по обработке Заявки от Клиентов, контролирует процесс выполнения Заявок на более низком, чем Руководитель, уровне.
3.2.6 Сметчик (С)
Будет создавать ТУ, ТЗ, ТП, ИД и КП по Заявке от МП.
3.2.9 Курьер (К)
Курьер будет поставлять оборудование в Компанию и доставляет его Клиентам.
не согласованность времен
3.2.10 Секретарь(С)
Будет заводить новую Заявку и необходимую информацию о Клиенте
Заводить Клиента, это наверное важное действо, но к делу не относящееся
3.3.1 1С
Требует большой настройки Системы и, следовательно, дорогое решение. Нет веб интерфейса.
какая версия имеется в виду, не рассмотрена система 1С Битрикс, не приведены цены, не приведены цифры внедрений CRM от 1С.
Функциональные характеристики описаны как-то по-школьному что ли.
Заведение? Может уж сразу управление (ввод, хранение, изменение, удаление, просмотр, поиск)
Смотрим domain model - на мой взгляд модель слишком бедная. Что касается заявки. Заявок много все-таки, заявки исполняются менеджерами, есть какой-то список заявок на исполнение, распределенный по менеджерам, по сути есть некий график - на модели никак это не обозначено. Мне кажется слишком рано проведено обобщение.
Модель вариантов использования слабенькая, ни ранжирования ВИ, ни распределения ВИ по пользователям, вообще название ВИ не нравятся, что это значит Завести Заявки....
Войти в систему:
2.3.1.3.1 Пользователь запускает программу (Систему)
2.3.1.3.2 Система показывает форму авторизации, см. ПИ
2.3.1.3.3 Пользователь вводит свои имя и пароль и нажимает кнопку ОК
2.3.1.3.4 Система подтверждает введенные имя пользователя и пароль и показывает пункты меню, доступные для данного пользователя, см. БП
Все - никаких если, никаких проверок - типичная ошибка начинающего техписа по ВИ, смотри КОБЕРНА
2.3.1.4 Альтернативные сценарии
2.3.1.4.1 Пользователь ввел неверные имя и пароль, п. 2.3.1.3.4
2.3.1.4.1.1 Если пользователь ввел неверные имя и пароль, то Система показывает соответствующее сообщение
2.3.1.4.1.2 Пользователь нажимает ОК на Сообщении
2.3.1.4.1.3 Выполнение продолжается с п. 2.3.1.3.2 основного сценария
Слишком рано и похоже на реализацию
Данные введенные пользователем не верны!
Система выдает соответствующее сообщение и перенаправляет пользователя на страницу входа
Сразу вопрос, а сколько раз можно данные вводит в одном сеансе? Какова предполагаемая защита от роботов и т.п.
2.3.1.4.2 Пользователь нажимает кнопку ОТМЕНА, п. 2.3.1.3.3
2.3.1.4.2.1 Если Пользователь нажал кнопку ОТМЕНА, то Система закрывает приложение
Это же веб приложение, имеет ли смысл вот так раз и закрывать приложени, по сути не приложение будет закрыто а браузер
2.3.1.5 Выходные условия
Пользователь успешно вошел в Систему
вовсе нет, пользователю предоставлен доступ к информации в соответствии с правами доступа!
2.3.2.3.2 Система показывает форму Справочника, которая показывает отображает лучше все элементы Справочника с полями в соответствии с выбранной ф-тью:
нужно все-таки стараться писать литературно, но точно
Сценарий описан по сути как дерево решений: если - то, может так и писать? а не через ВИ? Мне не нравится, смотри выше. Коберну икается
4. Применимость
Специальных требований нет.
а как же насчет за счет удобного пользовтельского интерфейса
Про бизнес-процессы. Мне кажется их следует описывать в стиле событие - действие событие - то есть eEPC или BPMN.
Нет общей картины, бизнес-плана...
Описание требований к CRM