Требования к готовым (коробочным) решениям · Конспекты по бизнес-анализу

Главные идеи#

Чем отличаются такие проекты#

Функции и экраны уже спроектировал вендор, поэтому детальные функциональные требования бессмысленны. Вигерс и Битти советуют работать на уровне вариантов использования или пользовательских историй и проверять, какой пакет их покрывает.
Вы адаптируете свои бизнес-процессы к пакету. При заказной разработке ПО подстраивается под процесс; здесь в основном наоборот.
Есть четыре типа внедрения, по возрастанию трудоёмкости: использование как есть; настройка (параметры, без кода); интеграция с существующими системами (обычно с некоторым объёмом собственного кода); расширение (разработка недостающих функций). Даже вариант «как есть» может потребовать изменений в среде, например обновлений операционной системы.

Усилия — по ставкам#

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

Что специфицировать#

Пользовательские требования: варианты использования или истории для важных задач.
Бизнес-правила: можно ли настроить пакет под ваши политики? Кто обновляет глобальные правила, например расчёт налогов, когда они меняются, и стоит ли это дополнительных денег?
Требования к качеству: производительность (время отклика, число одновременных транзакций), удобство использования (привычные соглашения, обучение от вендора), гибкость (интерфейсы для расширения и сохранятся ли ваши доработки при обновлениях), функциональная совместимость, целостность и безопасность. Для SaaS внимательно изучите соглашение об уровне обслуживания (SLA).

Балльная оценка кандидатов#

Авторы приводят метод из четырёх шагов, который предложили Лоулис (Lawlis) и коллеги: 1. Задайте вес важности каждого требования от 1 до 10. 2. Оцените, насколько каждый пакет выполняет каждое требование: 1 — полностью, 0,5 — частично, 0 — не выполняет. Используйте документацию, ответы на ваш запрос предложений (RFP) и практические проверки. Требования с высоким приоритетом всегда проверяйте сами: ответы на RFP могут не совпадать с реальностью. 3. Сложите взвешенные оценки по каждому пакету. 4. Отдельно оцените стоимость, репутацию вендора, поддержку, внешние интерфейсы и соответствие техническим ограничениям. Сравнивайте стоимость после функционального соответствия, а не вперемешку с ним.

Добавьте тесты на основе высокоприоритетных вариантов использования, включая ошибочные ситуации, и прогоните их на каждом кандидате — это «операционный профиль» в терминах Мусы (Musa). Пусть хотя бы один человек участвует во всех оценках, чтобы баллы толковались одинаково.

Если кандидатов много, оценивайте в несколько раундов. В случае, который описывают авторы, 60 вендоров и 200 функций сократили до 16 кандидатов по 30 самым важным критериям, которые лучше всего различали варианты; затем до пяти финалистов по всем 200; каждого финалиста затем опробовали на реальном проекте. Практическая работа с реальными данными выявила расхождения между заявленным и фактическим поведением.

Требования к внедрению#

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

Типичные трудности#

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

Пример#

«Мастерская», вымышленная сеть веломастерских, сравнивает три вымышленных пакета для записи.

Требование	Вес	Пакет A	Пакет B	Пакет C
Клиент записывается на время в выбранную мастерскую	10	1	1	1
Стойка приёма оформляет клиентов, пришедших без записи, и звонящих по телефону	8	1	0,5	1
SMS при изменении статуса ремонта	7	0,5	1	0
Поиск запчастей через интерфейс поставщика	6	0	1	0,5
Настраиваемые правила отмены	4	1	0,5	1
Взвешенная сумма (максимум 35)		25,5	29	25

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

Чек-лист#

Бизнес-цели определяют, что значит «достаточно хорошо».
Ключевые варианты использования и требования к качеству записаны, детальные функции — нет.
У каждого требования есть вес, и один и тот же оценщик участвует во всех сессиях.
Требования с высоким приоритетом проверены на практике.
Стоимость сравнивается после функционального соответствия.
По каждому разрыву принято решение: отказаться, изменить процесс или расширить пакет.
Доработки переживут обновления.
Сопоставление данных и допустимые потери данных согласованы.
Пользователи участвуют в выборе и в изменении процессов.

Источники и что почитать#

K. Wiegers, J. Beatty. Software Requirements, 3rd ed. Microsoft Press, 2013. Рус. изд.: К. Вигерс, Дж. Битти. Разработка требований к программному обеспечению, 3-е изд. М.: Русская редакция; СПб.: БХВ-Петербург, 2014. Гл. 22 (включая ссылки авторов на Лоулиса и соавторов и на Мусу).