Comments 9
Мой опыт работы с требования заказчика показывает, что заказчики как правило не различают разницу между функциональными и не функциональными требованиями. Более того, заказчики очень любят изменять требования во время завершения работы над системой.
Поэтому самое главное при работе с любыми требованиями, их обязательная фиксация в письменном виде под обязательную роспись со стороны заказчика. А уж функциональные они или нет, это дело десятое.
а потом приходят заказчики и жалуются, что эти айтишники не различают роспись и подпись)
и потом у них в системе документооборота какое-то жостово )
РО́СПИСЬ
Женский род
УСТАРЕЛОЕ
Письменный перечень чего-н. устар..
"Р. государственных доходов и расходов"
Живопись на стенах, потолках.
"Древнерусские росписи"
давайте ссылаться на материалы друг друга?
а то сейчас происходит какой-то контентный аутизм и солипсизм, компании делают вид, что никаких других наработок по теме в этом же пространстве нет, есть только её взгляд
https://habr.com/ru/post/661331/
У вас есть какие-нибудь best practise по change managementу нефункциональных требований в режиме agile? К примеру, разработали функционал и на 5 спринте видно, что система начинает грузиться по 5 секунд при активации ключевого функционала?
Обнаружили баг, далее разработчик анализирует код, к обсуждению подключается аналитик и другие члены команды (по возможности). Если есть возможность оптимизации - оптимизирует, нет - эскалирует проблему тимлиду. Затем уже тимлид анализирует и оптимизирует, если есть возможность, если нет - эскалирует продакту, детально описывая проблемы и указывая возможные риски. Далее продакт обсуждает проблемный пункт НФТ с бизнесом. Обычно находим нужные доводы и приходим к компромиссу.
Но, по нашему мнению, нефункциональные требования не нужно менять из-за того, что система им не соответствует. Наоборот, это систему надо менять. Если вы видите, например, в kibana или в Sentry, что она не справляется - зовите девопсов. А еще лучше в коде заранее предусмотреть контрольные точки, на которых могут возникать проблемы, и при их возникновении получать соответствующие алерты. Но тут опять же мы говорим не об изменении НФТ под систему, а о внесении изменений в систему под НФТ.
Конечно много очевидного, но собрано и подано очень понятно, примеры 5+. Спасибо за статью.
Книге лет наверное уже 15, если не все 20 :)
Нефункциональные требования: как не пустить систему ко дну