Когда и как стоит писать функциональные требования для реализации системы

В прошлых постах я писал, что для начала работ по внедрению системы достаточно сценариев использования и реестра компонентов системы.

Напомню:

▪️Сценарии описывают действия пользователей в системе;
▪️Реестр содержит объекты, которые нужно создать или доработать.

Однако в некоторых случаях требуется больше информации — например, когда:

▪️ В процессах большое количество ролей, отчетов, вычислений;
▪️ Проект необходимо описать более подробно для согласования со стейкхолдерами.

В этих случаях можно дополнить документацию функциональными требованиями.

Возможная структура функциональных требований

▫️ Оглавление
▫️ Цели автоматизации
▫️ Термины
▫️ Описание ролей пользователей
▫️ Сценарии использования
▫️ Номер и название каждого требования
▫️ Описание каждого требования
▫️ Описание и макеты интерфейсов
▫️ Алгоритмы определения значений ключевых переменных
▫️ Требования к отчетности
▫️ Ориентировочное количество пользователей

➡️ Следите, чтобы функциональные требования не были слишком объемными — так их сложнее будет прочитать, согласовать и полностью реализовать.