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

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

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

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

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

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

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

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

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

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

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

В этом посте были ссылки, но мы их удалили по правилам Сетки