Поговорим о НФТ

Меня зовут Денис Богданов. Я занимаюсь развитием функций системного анализа, внедрением внутренних процессов и инструментов, а также повышением эффективности работы в компании BIA Technologies. Еще я немного преподаю дисциплины, связанные с бизнес и системным анализом.

Немного о компании, где я работаю.

Мы – крупный системный интегратор и разработчик. Внедряем процессы и софт в компаниях. У нас большая экспертиза в высоконагруженных нетиповых системах на платформе 1С. Ежегодно у нас более 100 крупных проектов для заказчиков из разных отраслей.

В процессе доклада я расскажу:

• почему НФТ – это важно;

• какое место НФТ в классификации требований;

• как классифицируются НФТ (какие они бывают);

• покажу примеры влияния НФТ на конечный результат;

• и дам советы по выстраиванию процесса работы с НФТ.

НФТ – это важно

Знаете ли вы, что такое нефункциональные требования? Сталкиваетесь ли вы с ними в работе? Уделяете ли вы этому особое внимание?

Почему сегодня хочется поговорить об НФТ?

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

• НФТ – это хороший дополнительный предмет для коммуникаций, как внутри команды, так и с заказчиком, с бизнесом, с архитекторами.

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

Примером того, почему НФТ – это важно, можно считать следующие ситуации:

1. Падение «ГосУслуг», когда только начиналась электронная запись в первый класс.

2. Вторая ситуация произошла тогда, когда RuTube подумал, что он может заменить YouTube.

3. И третья ситуация произошла тогда, когда уходила IKEA, у них был очень большой наплыв клиентов на распродаже, они тоже рухнули.

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

Можно ли было это спрогнозировать?

• В случае с IKEA, наверное, нет.

• А в случае «ГосУслуг» – однозначно да. Подсчитать, сколько человек будет записываться в этом году в первый класс – это вполне выполнимая задача.

Место НФТ в классификации требований в целом

Давайте сначала вспомним, что такое функциональные требования и нефункциональные.

• Функциональные требования описывают, какими функциями в целом должна обладать система, как она должна реагировать на какие-то действия пользователя, на какие-то свои внутренние алгоритмы, и какие действия должны быть предоставлены пользователю.

• Нефункциональные требования – это требования к каким-то качествам, свойствам и характеристикам либо системы в целом, либо каких-то отдельных ее функций.

На слайде – знаменитая картинка из Вигерса с разделением на функциональные и нефункциональные требования.

Вигерс выделяет такие виды нефункциональных требований, как:

• бизнес-правила;

• атрибуты качества;

• внешние интерфейсы;

• и ограничения.

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

Бизнес-правила – это некие ограничения, требования, которые продиктованы нам:

• либо бизнесом – выходят из каких-то локальных актов или внутренних правил конкретного бизнеса;

• либо это что-то, что продиктовано законодательством – любыми его актами.

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

Примеры:

• Закон или пакет Яровой – классическое бизнес-правило. Мы обязаны хранить информацию определенное время и т.д. с такими-то условиями. Отсюда будут рождаться нефункциональные требования к времени и особенностям хранения информации.

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

• Так же, например, это могут быть требования в части безопасности. У нас могут быть какие-то внутренние правила. Условно: посылку человек может получить, только предъявив паспорт – отсюда могут появиться какие-то требования к безопасности.

Теперь про переходные требования – это какие-то требования, которые надо выполнить, чтобы перейти из состояния «AS-IS» в состояние «TO-BE». Причем, мы уже говорим не про разработку – разработку мы в целом делаем, чтобы перейти из «AS-IS» в «TO-BE». Переходные требования касаются ситуации, когда нам важно «переключить рубильник» – когда уже все реализовано, но мы это еще не отдали.

К переходным требованиям, как правило, относятся организационно-технические мероприятия:

• импорт данных из старой системы;

• настройка прав перед тем, как запустить функциональность;

• включение новой функциональности на продуктиве;

• обучение людей и проч.

Как правило, переходные требования не влияют на нефункциональные, поэтому не будем на них задерживаться.

Далее – ограничения.

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

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

Про типы нефункциональных требований мы поговорим чуть дальше.

И атрибуты качества.

Напомню, что классификацию, предложенную Вигерсом, я рассматриваю немного иначе – некоторые атрибуты качества (не все) я рассматриваю как уже реализованные нефункциональные требования.

Это значит, что существует некий период времени, пока требование – это еще требование. Но как только оно реализовано, мы должны его хранить и обрабатывать уже как атрибут качества. Например,

• система отрабатывает за такое-то время;

• в ней реализованы такие-то параметры безопасности и т.д.

Это уже становится атрибутом качества.

На самом деле атрибутов качества больше. Подробнее про взгляд на качество в целом можно посмотреть в документации:

• есть стандарт ISO 25010;

• есть стандарт ISO 15504 – правда, он про процессы;

• и есть система сертификации Tick-IT.

Классификация НФТ

Теперь поговорим о классификации нефункциональных требований.

Где можно вдохновиться?

• Все тот же ISO 25010;

• Еще есть такая вещь, как FURPS – это аббревиатура от типов требований: Functional, Usability, Reliability, Performance и Supportability;

• Дальше BABOK – там тоже указана классификация

• (внезапно) статья NFR из Википедии – автор статьи собрал материал из разных источников, тоже можно посмотреть.

Я предложу вот следующую классификацию.

Выделить можно четыре большие области:

• Runtime Quality – это все, что в целом относится к возможностям системы выполнять свои функции (мы по ним дальше пройдемся отдельно).

• Design Quality – это требования к тому, как система должна быть спроектирована, на каких принципах построена, требования к архитектуре.

• User Quality – это требования к удобству использования.

• System Quality – это поддерживаемость и тестируемость.

Теперь чуть подробнее о Runtime Quality и User Quality.

• Здесь можно выделить производительность – это требования к тому, насколько те или иные функции системы должны быстро отрабатывать. Сюда же в отдельный подтип можно выделить требования к постоянной и пиковой нагрузкам.

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

• Надежность – это время восстановления от сбоев.

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

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

• Масштабируемость. Как только мы говорим о том, что система, скорее всего, будет развиваться, масштабироваться на какие-то другие рынки, другие филиалы и так далее, мы должны это прогнозировать и закладывать в реализацию.

• Совместимость с ПО. Например, наша система должна работать на какой-то определенной версии операционной системы либо уметь интегрироваться с каким-то другим программным обеспечением – мы можем эти требования задавать. Либо совместимость, например, с железом. Если мы понимаем, что система будет запускаться на каком-то специфическом железе, и мы должны сделать так, чтобы эта система гарантированно на нем работала.

• И особенности хранения данных – это все, что связано с резервированием, с доступом к данным, со скоростью доступа к данным. Скорость доступа может немного граничить с производительностью, но здесь имеются в виду скорее какие-то организационные вещи. Допустим, что получение данных не должно быть дольше 1 часа, например.

Теперь Design Quality.

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

• Возможность повторного использования – если мы делаем не что-то уникальное на один раз, а собираемся это переиспользовать в дальнейшем. Возможно, это какая-то библиотека или какой-то подключаемый модуль. Мы можем задать требования к тому, как это переиспользование должно происходить: сложно или легко, что для этого нужно сделать, и так далее.

• Ремонтопригодность – это возможность быстрого внесения изменений в систему, насколько сложно внести какие-либо изменения. Это могу быть требования к тому, что система должна позволять вносить изменения без кодинга, только через настройки.

И System Quality.

Здесь поддерживаемость и тестируемость.

• Требование к поддерживаемости – это требование к логированию ошибок и к сбору информации, который в итоге поможет поддерживать систему, анализировать ошибки и так далее.

• И требование к тестируемости – к тому, насколько легко тестировать нашу систему, нужны ли для этого какие-то специальные инструменты, софт или, например, к возможности автоматизированного тестирования.

Как работа с НФТ влияет на реализуемые продукты?

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

Ситуация №1

Делали систему. Условно: сидят операторы, получают на вход от людей некие анкеты, заявления и дальше их каким-то образом вносят в систему (не МФЦ, но примерно так выглядит).

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

К чему привело: в итоге операторы стали работать дольше, чем работали до этого. Хотя вроде бы мы бились за то, чтобы ускорить процесс.

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

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

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

Ситуация №2

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

Проблема: Сделали новый отчет. При выкатывании на прод служба безопасности сказала: «Нельзя!». Выяснилось, что в новом отчете есть чувствительная финансовая информация и всем ее видеть нельзя.

К чему привело: не смогли перевести доработки на продуктивную среду, сорвали сроки по задаче.

Как можно было избежать:

• Нужно было лучше изучить перечень данных, который подлежит защите в этой компании;

• Предъявить к решению требования к безопасности – в данном случае, отчеты с финансовой информацией должны закрываться по правам доступа на какие-то отдельные роли и выдаваться только тем пользователям, которые имеют доступ к этой информации.

Ситуация №3

Третья ситуация – позитивная, она показывает, что аналитик очень хорошо поработал с требованиями.

Проблема: Есть очень большой объем документов – ежедневно генерятся тысячи штук. И эти документы нужно хранить, потому что регулятор может их периодически запрашивать – хотя это происходит редко. При анализе выявили, что при запросе документов регулятором дается несколько дней, чтобы эту информацию собрать. Зафиксировали это в требованиях к особенностям хранения, что хранить нужно пять лет, притом доступ может быть не очень быстрый.

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

Ситуация №4

Делали приложение для школ, организующее некую интерактивность для учителя, чтобы он мог вести уроки. Разработали дизайн систему, сделали все красиво, посмотрели у себя – все отлично, протестировали в двух школах Москвы – все шикарно.

К чему привело: раскатали это приложение на всех, и из регионов прилетает, что работать невозможно. Оказалось, что в регионах проекторы постарше и в целом похуже, что местами где-то солнце бьет в окно, штор нет и вообще ничего не видно и т.д.

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

Как можно было избежать: здесь явно возникло НФТ к совместимости с оборудованием, на котором это все будет работать.

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

Советы по выстраиванию процесса работы с НФТ

В конце хотел бы дать советы по выстраиванию процесса работы с нефункциональными требованиями.

Процесс достаточно простой.

Есть аналитик, он собирает и уточняет требования заинтересованных сторон и в итоге формирует «Реестр уточненных требований ЗС».

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

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

Если вам говорят, что этот отчет должен формироваться за одну секунду, и вы понимаете, что это будет дорого или технически сложно, надо понять «А зачем?». Что поменяется, если он будет формироваться не одну секунду, а одну минуту? В большинстве случаев оказывается, что ничего не поменяется: человек просто запустит отчет и будет параллельно делать что-то другое.

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

В конце расскажу про основной верхнеуровневый процесс:

• Если у нас новая система, мы:

  • собираем и уточняем требования;

  • явно выделяем и классифицируем нефункциональные требования – отделяем их от функциональных и классифицируем по разным типам, потому что с разными типами нужно по-разному работать (об этом немного поговорим далее),

  • коммуницируем с командой,

  • проверяем целостность собранных НФТ – все вопросы закрываем и в итоге их фиксируем.

  • т.е. когда у нас система новая, наша основная задача – это выявить все НФТ и не упустить ничего;

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

 

По зонам ответственности:

• Производительность лучше всего обсуждать с архитектором – в разных компаниях это может быть как-то по-разному.

• С точки зрения удобства использования – с дизайнером.

• С точки зрения безопасности – здесь и архитектор, и служба безопасности.

• Масштабируемость, надежность, совместимость – тоже скорее всего к архитектору.

• Доступность и особенности хранения данных – архитектор и служба поддержки, как мы уже ранее обсуждали.

Небольшой чек-лист о том, как не упустить нефункциональные требования:

1. Формализация процесса и методики работы с НФТ. Все, что я ранее рассказал, у вас в компании должно быть описано с какой-то вашей спецификой. Это должно быть доступно и доведено до ваших аналитиков, чтобы они этим пользовались.

2. Шаблонизация всех артефактов, содержащих информацию о нефункциональных требованиях. Если у вас есть шаблон технического задания, выделите там отдельный раздел под НФТ, чтобы тому, кто заполняет, пришла в голову мысль, что с этим нужно поработать отдельно. Лучше, если там будут выделены отдельные разделы под разные типы НФТ, тогда у него сразу же будет подсказка, что по каждому из них нужно пойти и задать нужные вопросы (какие, сейчас проговорим). В этом случае больше шансов, что ничего не будет забыто, и все требования будут учтены.

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

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

5. Уточнять, какие данные критичны/не критичны, чувствительны/не чувствительны для отображения – в этом случае вы сразу получаете требования к защите, безопасности и к особенностям хранения данных.

6. Всегда задаваться вопросом «когда и как часто вы это делаете?», «при каких условиях или триггерах вы идете и выполняете эту функцию или смотрите эти данные?». У вас тогда сразу будет НФТ и к доступности, и надежности, и к особенностям хранения данных, и к производительности – они будут потихоньку рождаться;

7. Если речь идет о каком-то большом количестве данных или большом количестве пользователей, нужно сразу понимать, сможет ли система их переварить – это НФТ к производительности и к масштабируемости;

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

9. Как только обсуждается ИТ-ландшафт или какие-то ограничения ИТ-ландшафта, здесь сразу же рождаются требования Design Quality и System Quality. Условно, если ландшафт построен на каком-то стеке, у вас сразу же рождаются требования концептуальной целостности. Вы понимаете, что, скорее всего, ваше решение должно быть реализовано на этом стеке или как-то встраиваться в него.

10. И последнее: куда система будет развиваться дальше? Здесь рождаются требования к масштабируемости, Design Quality и System Quality.

Вопросы и ответы

Если аналитик изначально дорабатывает уже реализованную функциональность, под которую отсутствует четкая спецификация, потому что функциональность некритичная, нужно ли аналитику задумываться о требованиях в этой ситуации? Или можно упустить этот момент?

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

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

Вопрос про зоны ответственности. Если в проекте нет как такового дизайнера или архитектора, заказчик не знает, чего он хочет, и ты один принимаешь решения за все – нужно ли вообще брать ответственность?

Брать на себя ответственность за то, что вы не можете гарантировать, конечно, не стоит.

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

Если заказчик не знает, чего он хочет – так он всегда не знает, что он хочет. Для этого аналитики и есть, чтобы попытаться где-то подсказать, где-то вытащить это из заказчика. Нужно с этим работать – попытаться ему помочь с точки зрения НФТ.

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

*************

Статья написана по итогам доклада (видео), прочитанного на конференции "Анализ & Управление в ИТ-проектах".