Работаете ли вы с системными и процессовыми требованиями
Что проверяют
Различаете ли вы уровни требований и умеете ли описывать процесс, а не только экраны. Процессные требования это область, где аналитик работает с регламентами, ролями и исключениями, и её проваливают те, кто писал только функциональные постановки.
Как отвечать
Выстройте иерархию, тогда разница становится очевидной.
- Бизнес-требования: зачем это компании, какую цель закрывает.
- Пользовательские: кто и какую работу выполняет, сценарии использования.
- Системные функциональные: что именно делает система, включая альтернативные ветки и обработку отказов.
- Нефункциональные: время отклика на перцентиле при заданном профиле нагрузки, доступность, сроки хранения, разграничение доступа.
- Процессные: последовательность шагов, роли и точки принятия решения, сроки реакции, что происходит при отклонении и кто разбирает исключения.
Скажите, чем описываете: процесс «как есть» и «как будет» в нотации BPMN, поведение в виде вариантов использования, атрибуты у каждого требования (источник, приоритет, статус, версия) и трассировка от бизнес-цели до проверки. Отдельно расскажите про управление изменениями: где лежит действующая редакция, кто согласует, как узнают смежные команды.
Где спотыкаются
Подменяют требование решением: пишут «система должна использовать очередь» вместо «заявка не теряется, если смежный сервис недоступен». Архитектура оказывается зафиксирована документом, а настоящее ограничение так и не сформулировано.
Описывают только удачный путь. Отказ внешнего сервиса, повторная отправка, отмена уже проведённой операции всплывают на тестировании, когда переделывать дорого.
Пишут «быстро» и «удобно», а результат подпирают выдуманной цифрой вроде роста производительности на треть. Непроверяемое требование не примет ни разработчик, ни тестировщик: нужны величина, способ замера и условия.