Комментарии 7
По моему опыту, нефункциональные требования - это хороший пример серой зоны разграничения задач по управлению продуктом и его реализации. Должно ли быть требование по быстродействию отдельный "НФТ", или частью функционального требования. Или менее очевидное требование всегда использовать сторонние компоненты без критических уязвимостей. Является ли оно "НФТ" или должно быть часть руководства по безопасной разработке.
Согласен, НФТ - это действительно зачастую серая зона требований, в которую никто не хочет погружаться.
По отнесению к НФТ - быстродействие не является функцией системы, поэтому оно и относится к нефункциональным требованиям. Безопасность обычно тоже не является отдельной функцией, а некой общей характеристикой системы, поэтому тоже относится к НФТ.
Если начать уточнять пользователей, то в итоге все "НФТ" можно свести к пользовательским, условно функциональным, требованиям. Те же требования безопасности могут быть критериями к продукту от отдела ИБ клиента. Я ориентируюсь на свой пузырь корпоративных аппаратных продуктов. И часто требования типа "обеспечить удаленное включение" и "обеспечить соответствие ФСТЭК" находятся в одной группе, без разделения на функциональные и не функциональные. Так как первое от пользователя "Администратор", а второе от пользователя "директор по IT"
У любого требования должен быть источник. Да, например персона, которой это больше всех надо. Но классификация FT / NFT про другое. Здесь важнее отделить "что" от "как", конкретную полезную функцию от ограничений уровня всей системы.
Польза в разделении труда, экспертизы и полномочий. Иначе люди начинают лезть со своими подходами в области, где они ни чего не понимают, и перестают приносить value.
Сейчас поймал себя на мысли, что непонятна цель классификации. Перечитал статью, и тоже не нашел ответа "зачем" кроме того, что их важно не упускать. Если мы идем от персоны, и ценности, то в итоге и получаем требование. Требование оцениваем по любой методике и ставим в очередь. Какая разница функциональное оно или нет.
Скорее всего надо начинать от определения "функция". Что именно подразумевается. Если взять ваш пример с велосипедом ниже, то функциональность видимая со стороны наблюдателя может быть разной, в зависимости от наблюдателя, и того, что он хочет получить.
В классификации от HP на которой ссылается в статье приводится следующий пример Architectural Requirement (именно такой термин используется): The persistence will be handled by a relational database. Но указание типа базы данных важно, если в этом есть ценность, т.е. есть персона, которая эту ценность получает. В случае реализации пользовательского сценария вообще неважно что именно внутри. До тех пор пока это укладывается в экономику производства и сопровождения продукта.
Архитектура в большей степени определяется НФТ. Условный велосипед для индивидуальных гонок или для шаринга в условиях города это принципиально два разных девайса. Хотя функциональность, видимая со стороны наблюдателя, практически ни чем не отличается.
Фактически, проект, где есть только функциональные требования и нет НФТ это прототип. На практике такая проблема часто возникает из-за своеобразного подхода к сетапу команд. Например, на проекте есть бизнес-аналитик и нет архитектора, а у разработчиков нет права голоса для принятия решений по существу. В результате все как очумелые пилят фичи, а при сдаче эксплуатацию все разваливается.
ФункциАнальные и нефункциАнальные?
Вы серьёзно?
Зачем нужны нефункциональные требования к ПО и откуда их взять