Откуда берутся нефункциональные требования

Откуда берутся нефункциональные требования

Когда ты как продакт понимаешь техническую часть продукта — это непередаваемое ощущение

Поэтому если есть что интересного почитать на эту тему — делюсь тут по возможности.

В канале Системный Сдвиг Юрия Куприянова (программный директор WAW, член ПК Flow, ЛАФ) подсмотрела пост с источниками нефункциональных требований и чуть адаптировала его, чтобы было проще воспринимать.

Продактам будет полезно, чтобы понимать, все ли учтено в требованиях к продукту и избежать переделок.

Основные 4 источника нефункциональных требований:

Бизнес-показатели Сколько у нас данных? Насколько быстро должны выполняться операции? Как долго хранить информацию? Нужно ли быстрее проводить одну транзакцию или обрабатывать тысячи сразу? Ответы на эти вопросы дают бизнес-процессы.

Риски Что произойдет, если система «упадет» на час? Если пропадут данные? Если выбранная технология устареет или специалистов на рынке просто не окажется? Нефункциональные требования помогают снизить эти риски.

Ограничения Совместимость с внешними системами, требования регуляторов и аудиторов, доступные технологии и бюджеты, навыки команды. Всё это напрямую влияет на архитектуру и накладывает ограничения, которые нужно учитывать.

Будущее и развитие Продукт не стоит на месте. Важно понимать, как будут меняться требования, насколько легко будет дорабатывать систему, что мы знаем об ограничениях и перспективах. Эти вопросы тоже формируют нефункциональные требования.

А вообще у Юрия в канале еще много крутых материалов по системной аналитике. Поэтому если хотите прокачаться больше в ней - обязательно заходите и подписывайтесь на канал Юрия Системный сдвиг.

#PG_education