Сбор требований к ИТ‑системе: пошаговая инструкция

Сбор требований к ИТ‑системе — ключевой этап проекта, от которого зависит успех внедрения. Ниже — структурированная методика с конкретными шагами и инструментами.

1. Определение целей и контекста

Что делать:

• Выявить бизнес‑цели системы: зачем она нужна, какие проблемы решает, какую ценность приносит.
• Описать текущий процесс (as‑is): кто участвует, какие действия выполняются, где «узкие места».
• Сформулировать ожидаемый результат (to‑be): как изменится работа после внедрения.

Пример:

«Система автоматизирует оформление договоров. Сейчас менеджеры тратят 2 часа на один договор из‑за ручного заполнения и поиска шаблонов. Цель — сократить время до 30 минут».

2. Выявление стейкхолдеров

Кто участвует:

• Заказчики (руководство, владельцы процессов).
• Конечные пользователи (операторы, менеджеры, клиенты).
• Интеграторы (если система взаимодействует с другими ПО).
• Регуляторы (если есть нормативные требования).

Как работать:

• Составить список всех ролей.
• Определить их интересы и «боли».
• Назначить ответственных за согласование требований.

3. Сбор первичных требований

Методы:

• Интервью (один на один или в группе). Подготовьте сценарий: открытые вопросы + уточнение деталей.
• Анкетирование — для массового сбора мнений. Используйте закрытые вопросы с вариантами ответов.
• Наблюдение за работой пользователей («полевая работа»).
• Анализ документов: регламенты, инструкции, отчёты, логи систем.
• Мозговой штурм с командой для генерации идей.

Ключевые вопросы:

• Какие задачи вы решаете сейчас?
• Что мешает работать эффективнее?
• Какие функции абсолютно необходимы?
• Какие интеграции нужны (1С, CRM, почта и т. д.)?

4. Классификация требований

Разделите собранные данные на категории:

1. Бизнес‑требования
   Пример: «Сократить время обработки заявок на 40%».
2. Пользовательские требования
   Пример: «Менеджер должен видеть список текущих договоров в одном окне».
3. Функциональные требования
   Пример:
   Система должна автоматически заполнять реквизиты клиента из базы.
   Отправлять уведомление при просрочке подписания договора.
4. Нефункциональные требования
   Примеры:
   Время отклика системы — не более 2 сек.
   Поддержка 100 одновременных пользователей.
   Резервное копирование каждые 4 часа.

5. Документирование

Формат: спецификация требований (SRS) в виде документа или wiki‑страницы.

Что включить:

• Цели и границы проекта.
• Роли и их права.
• Список функций с приоритетами (MoSCoW: Must have, Should have, Could have, Won’t have).
• Схемы процессов (BPMN, UML).
• Примеры интерфейсов (скриншоты/макеты).
• Ограничения (бюджет, сроки, технологии).

Инструмент: Confluence, Google Docs, специализированные ПО (например, Jira + ReqView).

6. Проверка и согласование

Шаги:

1. Провести воркшоп с ключевыми стейкхолдерами: разобрать требования, устранить противоречия.
2. Оформить протоколы согласований.
3. Получить подпись заказчика на финальной версии SRS.

Критерии качества требований:

• Ясность: понятно даже неспециалисту.
• Полнота: учтены все сценарии.
• Тестируемость: можно проверить выполнение.
• Приоритезированность: что делать в первую очередь.

7. Управление изменениями

Правила:

• Любые правки проходят через комитет по изменениям (Change Control Board).
• Фиксируйте историю изменений (версия, дата, автор, причина).
• Обновляйте документацию синхронно с разработкой.

Инструменты и техники

• MoSCoW — расстановка приоритетов.
• User Stories («Как менеджер, я хочу искать договоры по номеру, чтобы сократить время на поиск»).
• Use Cases — описание сценариев взаимодействия.
• Wireframes/Mockups — визуализация интерфейсов (Figma, Balsamiq).
• Матрица трассировки (traceability matrix) — связь требований с тестовыми сценариями.

Типичные ошибки

• Собираете требования только от руководства, игнорируя пользователей.
• Формулируете слишком абстрактно («система должна быть удобной»).
• Не учитываете интеграцию с существующими системами.
• Меняете требования без документирования.

Итог

Чек‑лист готового пакета требований:

1. Определены цели и границы проекта.
2. Составлен список стейкхолдеров.
3. Требования классифицированы (бизнес/пользовательские/функциональные/нефункциональные).
4. Документация согласована и подписана.
5. Заведён процесс управления изменениями.

Подписаться | Канал в дзене | Наш сайт | ВК | YouTube