|
rss_habr
[Перевод] Нефункциональные требования как пользовательские истории (Non-functional Requirements as User Stories)Вторник, 23 Августа 2022 г. 19:31 (ссылка)
В рамках своей работы и ведения подкаста по бизнес-анализу (ссылка на подкаст), я часто получаю вопросы от бизнес-аналитиков. И один из самых частых - как задокументировать нефункциональные требования, если на проекте принят стандарт написания пользовательских историй? Сегодня, я хотела бы поделиться переводом статьи Майка Кона, о том, как описать нефункциональные требования с помощью пользовательских историй. Ссылка на оригинал на английском. Поехали! Распространенной проблемой при написании пользовательских историй является то, как справиться с нефункциональными требованиями к продукту. Это требования, которые касаются не конкретной функциональности («Как пользователь текстового редактора, я хочу вставить таблицу в свой документ»), а скорее атрибута или характеристики системы. Примеры включают надежность, доступность, переносимость, масштабируемость, удобство использования, ремонтопригодность. Примечание: В оригинале статьи дается подсказка, что в английском языке большинство нефункциональных требований заканчиваются на "-ility" с несколькими исключениями. Для тех, кто работает на любом другом языке, эта подсказка не подходит. Для себя я выделила простое правило: все, что описывает, какие функции пользователь может выполнять в системе - это функциональные требования. Все, что описывает то, как быстро, безопасно или в какой среде эти функции выполняются - нефункциональные требования. Но далее, Майк Кон поделится своей шпаргалкой, как он понимает нефункциональные требования. Вспоминая темные века, я могу вспомнить, когда впервые прочитал о «нефункциональных требованиях». Этот термин поставил меня в тупик. Если это нефункционально, то почему меня это волнует? Я уверен, что автор этой книги разъяснил мне это на странице позже, но этот термин всегда казался мне странным. Я предпочитаю думать о нефункциональных требованиях как об ограничениях, которые мы накладываем на систему. Когда владелец продукта (Product owner) говорит, что «система должна адекватно работать, когда в ней одновременно находятся 100 000 пользователей», владелец продукта налагает ограничения на команду разработчиков. Читать далееhttps://habr.com/ru/post/684264/?utm_source=habrahabr&utm_medium=rss&utm_campaign=684264
|
LiveInternet.Ru |
Ссылки: на главную|почта|знакомства|одноклассники|фото|открытки|тесты|чат О проекте: помощь|контакты|разместить рекламу|версия для pda |