Функциональная и нефункциональная стороны продукта

Текстовая расшифровка четвёртого видеоурока курса Введение в профессию аналитика.

Очень часто (и мы тоже будем использовать этот термин) используется такое понятие как нефункциональные требования. Я опять заглянул в Википедию, чтобы повторить путь человека, который хочет найти какое-то определение в интернете, и нашёл такое.

Нефункциональные требования — это требования, определяющие свойства, которые система должна демонстрировать, или ограничения, которые она должна соблюдать, не относящиеся к поведению системы.

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

Я вам уже показывал картинку из книги Вигерса, перерсисованную мной, но соответствующую его иллюстрации в третьем издании. А здесь приведена это же картинка из первого издания. Она изначально выглядела вот так.

То есть он чётко делил все требования на функциональные и нефункциональные. Но, правда, в этом случае термин «функциональные требования» использовался два раза. Во-первых, он определял всю левую сторону картинки. А во-вторых, так ещё назывался отдельный вид требований, который, как мы только уже выяснили, тоже на самом деле очень много чего в себе содержит, причём трудно классифицируемого.

Я думаю, что Вигерсу по этому поводу задавали слишком много вопросов, так что он в последующих редакциях своей книги и в других книгах от этого чёткого деления отказался. Но, тем не менее, оно нам даёт идею, которая заложена в определении функциональных требований. Есть требования, которые определяют способ реализации функций продукта, а есть ещё требования, которые определяют его другие свойства. Которые явно не задействованы в реализации этих функций, но, тем не менее, тоже важны.

Для того, чтобы лучше понять, в чём разница, давайте вспомним, что такое автоматизированные cистемы, о которых я говорил в самом начале курса.

Вот это определение. Кстати, в отличие от Википедии, оно мне очень нравится. Оно очень чётко и не вызывает дополнительных вопросов. Я взял его из стандарта ГОСТ 34.

Автоматизированная система — система, состоящая из персонала и комплекса средств автоматизации его деятельности, реализующая информационную технологию выполнения установленных функций.

Самые главные слова я тут выделил жирным. Как я говорил, концепция автоматизированных систем появилась в эпоху больших машин, когда люди только начали искать способы автоматизации своей деятельности с помощью компьютеров. Что значит автоматизация? Ускорение, повышение эффективности и так далее.

Есть персонал. Это люди. Они выполняют определенную деятельность. Деятельность предполагает какие-то цели. И для того, чтобы людям позволить эффективно этих целей достигать, собственно, и делается автоматизированная система. Для чего в ней реализуется набор функций.

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

Почему я это определение привёл? Потому что оно даёт нам понять, что в эпоху автоматизированных систем функциональная сторона системы считалась главной. То есть система создавалась именно для того, чтобы люди могли какие-то функции реализовывать.

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

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

Есть функциональная сторона продукта, отвечающая на вопрос, ЧТО продукт делает. И есть нефункциональная сторона продукта, отвечающая на вопрос, КАК он это делает. С каким качеством, с какой скоростью, с какими ограничениями и так далее.

И в данном случае это картинка, скорее, показывает, к какой стороне больше тяготеет определённый вид требований.

Большинство интернет-продуктов не подходит под определение автоматизированной системы. Как вы видели из определения, персонал считается частью системы. Персонал — значит, люди подневольные. Они будут делать всё, что им скажут, с одной стороны. А с другой стороны, если они являются частью системы, то это люди специально обученные. Если уж их включили в систему, значит, их обеспечивают какими-то возможностями по реализации функций, для которых эта система предназначена. То есть это специально обученные люди с соответствующими инструкциями, соответствующей документацией, и достигающие каких-то целей, скорее всего, потому они работают на какую-то организацию.

Если говорить про интернет-продукты, то типичного пользователя сайта нельзя считать частью автоматизированной системы, потому что вы не можете заставить его что-то делать в рамках вашей системы. Вы не можете использовать старые подходы к определению того, каким образом он должен взаимодействовать с вашим сайтом. Если вы такую попытку предпримете, он просто очень быстро уйдёт на другой сайт. Хотя в некоторых случаях (мы о них будем говорить в курсе) этот подход применим и к интернет-продуктам.

А вторая особенность в том, что нефункциональные требования всё больше выходят на первый план. Мы в качестве одного из примеров рассматривали систему поиска и бронирования дешёвых билетов. Функция у этой системы одна, и достаточно простая: найти все маршруты по заданному направлению и сравнить их. Или даже просто представить их в определённом порядке пользователю для того, чтобы он смог из них выбрать. То есть, если говорить о функциональных требованиях, наверное, мы можем сравнительно просто эту функцию описать. Но что при этом становится важным?

Во-первых, количество компаний, с которыми вы взаимодействуете. (У них там есть свои агрегаторы, вам не обязательно взаимодействовать буквально с каждой авиакомпанией, но мы сейчас не будем в это вдаваться.) Чем больший выбор вы предоставляете на своём сайте, тем ваш сайт более конкурентоспособен. В этом случае у нас выползают на первый план требования, которые в нашей классификации называются внешними интерфейсами. Чем больше этих интерфейсов вы подключите, тем лучше.

Вторая особенность, очень важная сейчас, — это удобство использования. Если сайт реализует эту функцию и взаимодействует со всеми этими системами, но он неудобен — например, вы ввели запрос, прошла минута, и вы не понимаете, что там происходит, ищет он или не ищет, завис сайт или нет, — вы просто с него уйдёте к конкуренту, который эту функцию реализует более удобно. В этом случае на первый план выходит такая нефункциональная характеристика, как удобство использования или юзабилити.

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

Функциональная сторона в таких ситуациях исполняет, можно сказать, гигиеническую функцию. То есть без неё нельзя, но она у всех одинаковая. А различия всё больше кроются на нефункциональной стороне, и уже там идет борьба за предпочтения пользователей по тем атрибутам качества, которые для пользователей важны.

Предыдущий урок: Виды требований к программному продукту

Следующий урок: Атрибуты качества программного продукта