Чтобы не забыть решить, за сколько секунд система должна отвечать — нефункциональные требования по «Градации» IPA

«Жалуются, что переходы между экранами медленные, а ни в договоре, ни в спецификации нет договорённости о времени отклика»

«Ночной batch перестал успевать к утру, а как за годы вырастет объём данных, никто не оценивал»

«Только когда из-за сбоя сервера система простояла полдня, стало ясно: при заказе так и не спросили, за сколько часов эта конфигурация вообще должна восстанавливаться»

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

Официальный инструмент, который как раз не даёт это упустить, — «Градация нефункциональных требований» IPA (Information-technology Promotion Agency). В статье разбираем, что внутри набора и как им реалистично пользоваться для бизнес-системы малого и среднего предприятия — языком, понятным и заказчику.

1. Сначала вывод

• Нефункциональные требования — это не «что система делает», а «с каким качеством и на каких условиях она работает». В классификации IPA их сводят к шести крупным категориям: доступность, производительность и масштабируемость, эксплуатация и сопровождение, миграция, безопасность, системная среда и экология
• «Градация нефункциональных требований» — бесплатный набор инструментов IPA, который исчерпывающе перечисляет пункты по этим шести категориям и даёт заказчику и исполнителю согласовать их по шести уровням, от 0 до 5. Определения уровней из первоисточника вынесены в п. 3.1
• Заполнять все пункты не нужно. Предполагается другой порядок: выбрать «модельную систему», близкую к своей, и корректировать важные пункты под реалии компании
• Чем выше уровень нефункционального требования, тем выше стоимость. Вместо того чтобы «на всякий случай требовать высокий уровень», уровень выбирают от обратного — от влияния на бизнес
• Зафиксированный результат нужно оставить в документе определения требований. Именно эти предпосылки потом позволяют сравнивать сметы и отсекают споры «сказал — не сказал» после запуска

На схеме сплошная линия обозначает отношение, которое выполняется всегда, а пунктирная — условное отношение (условия указаны в пояснении к каждому отношению на странице сведений). Полный список отношений (всего 16, с доказательствами и степенью уверенности) и определения основных понятий собраны на странице сведений карты знаний (на японском). Данные: JSON-LD / Turtle

2. Что такое нефункциональные требования — между «работает» и «можно пользоваться»

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

Следующие вопросы в списке функций не появляются.

• С какого часа до какого эта система должна работать? По субботам и воскресеньям? Во время ночного batch?
• Если она встанет из-за сбоя, за сколько часов её нужно поднять, иначе бизнес остановится? До какого момента по времени данные ещё допустимо откатить?
• Сколько человек работают одновременно и сколько операций проходит за день? Насколько вырастет объём данных через пять лет?
• Кто ведёт мониторинг, кто снимает резервные копии, кто первым узнаёт о сбое?
• Какие данные старой системы и в каком объёме переносим в новую?

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

3. Что такое «Градация нефункциональных требований»

«Градация нефункциональных требований» — набор инструментов, который IPA публикует, чтобы заказчик и исполнитель не расходились в понимании нефункциональных требований. Первая версия вышла в апреле 2010 года. Актуальная — «Градация нефункциональных требований 2018» (апрель 2018), в ней учтены изменения вокруг безопасности и виртуализации (облака). Сейчас набор лежит на архивной странице сайта IPA, но как ориентир «ничего ли не пропустили в нефункциональных требованиях» на практике он по-прежнему остаётся привычным инструментом.

Внутри — такой набор рабочих материалов.

У каждой метрики задан набор ступенчатых уровней. Требование можно выразить не словами вроде «высокий / низкий», а выбором уровня — в этом и состоит особенность.

3.1. Что такое уровень — смотрим таблицу градаций как есть

«Ступенчатые уровни» сами по себе плохо представляются, поэтому посмотрим первоисточник. Уровней шесть, от 0 до 5: чем больше число, тем сложнее реализовать, и как правило тем выше стоимость разработки и эксплуатации. Но не у всех метрик шесть ступеней: у части пунктов вариантов всего три (0–2).

Например, первый пункт доступности «время эксплуатации (обычный режим)» (пункт A.1.1.1) определён так. Время в скобках — пример, а не само условие выбора уровня.

Размытое «хотим, чтобы система работала 24 часа» на этой таблице становится конкретным выбором: «берём уровень 5». И в тот же момент видно, что за этим выбором идут смена дежурных и стоимость отказоустойчивой конфигурации.

Ещё один пункт, который заказчику удобно обсуждать цифрами, — «коэффициент готовности» (пункт A.1.5.1). В примечании к таблице градаций для каждого уровня даже указан ориентир годового простоя.

Может казаться, что 99% и 99,9% «почти одно и то же». По годовому простою это 87,6 часа против 8,76 часа — разница между полными сутками и чуть меньше половины суток. Настоящая польза «Градации нефункциональных требований» как раз в том, что она ставит рядом цифры: на словах требования близки, а влияние на бизнес отличается в десять раз.

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

Берёте столбец модели, близкой к вашей системе, и от него двигаетесь: «у нас есть ночной batch — поднимем ещё на ступень», «зато коэффициент готовности нам до такого уровня не нужен». Так и пользуются таблицей градаций.

3.2. Три модельные системы

Вторая особенность — три модельные системы, разделённые по тому, насколько сильно остановка системы бьёт по обществу.

• Система, общественное влияние которой практически отсутствует
• Система с ограниченным общественным влиянием (например, базовая система предприятия)
• Система с чрезвычайно большим общественным влиянием (например, социальная инфраструктура)

В таблице градаций ориентировочный уровень по каждой модели уже заполнен. То есть обсуждение не начинают с нуля: сначала прикидывают «наша система ближе к этой модели», затем поднимают или опускают уровни под свои условия.

4. Шесть крупных категорий — переводим на язык заказчика

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

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

5. Как пользоваться на практике — не пытайтесь заполнить все 238 пунктов

В перечне показателей 238 метрик, но разбирать каждую по отдельности на проекте малого и среднего предприятия нереально, и руководство такого использования не предполагает. Заложен такой порядок.

1. Выбрать модельную систему
   (к какому масштабу влияния ближе ваша система)
        ↓
2. По важным пунктам таблицы градаций
   скорректировать ориентировочный уровень модели под реалии компании
        ↓
3. Детализировать только нужные части по перечню показателей

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

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

6. Связь с договором и сметой

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

Сначала сравнение смет. Если взять оценки у нескольких компаний, не выровняв нефункциональные предпосылки, может оказаться, что компания А заложила отказоустойчивую конфигурацию, а компания Б — один сервер. Заказчик уже не отличит, чем вызвана разница в сумме: разной конфигурацией или просто слишком оптимистичной оценкой.

Затем приёмка и период после запуска. Если договорённости о времени отклика и резервном копировании есть в документе, спор «медленно» против «мы этого не ждали» превращается в сверку фактов с зафиксированным критерием.

«Модельные сделки и договоры для информационных систем» IPA тоже исходят из того, что результатом этапа определения требований будет документ по нефункциональным требованиям. «Градацию нефункциональных требований» естественно встроить в многоэтапную схему, где определение требований ведут по договору оказания услуг, а разработку уже по зафиксированному содержанию — по договору подряда. О форме такого договора см. статью о «Модельных сделках и договорах» IPA.

Итог

Кратко по «Градации нефункциональных требований» IPA.

• Нефункциональные требования — это требования о том, с каким качеством и на каких условиях система работает. Без них она всё равно «работает», но пробелы всплывают спорами уже после запуска
• «Градация нефункциональных требований» — бесплатный набор инструментов IPA, по которому согласовывают шесть крупных категорий (доступность, производительность и масштабируемость, эксплуатация и сопровождение, миграция, безопасность, системная среда и экология) и 238 метрик по ступенчатым уровням
• Уровней шесть, от 0 до 5. Например, по коэффициенту готовности 99% (87,6 часа простоя в год) — это уровень 2, а 99,99% (52,6 минуты в год) — уровень 4: на словах близкие требования встают рядом цифрами (глава 3)
• От ориентировочных уровней трёх модельных систем идут к важным пунктам и корректируют их. Заполнять все пункты не нужно
• Содержание шести крупных категорий — в основном вопросы про бизнес. Ответы на них есть у заказчика
• Чем выше уровень, тем выше стоимость. Баланс выбирают от влияния на бизнес и оставляют результат в документе определения требований

Заранее решить, с каким качеством система должна продолжать работать, так же важно, как решить, что именно строить. Это самый дешёвый способ не получить систему, которая работает, но пользоваться ею нельзя, — и не спорить об этом потом.

Справочные ссылки

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

• Усиление верхних этапов построения систем (Градация нефункциональных требований) ─ входная страница в архиве IPA. Отсюда переходят к отдельным материалам
• Страница с описанием «Градации нефункциональных требований» ─ состав набора и порядок работы: от выбора модельной системы к уровням важных пунктов
• Условия использования основного комплекта «Градации нефункциональных требований» (японская версия) ─ скачивание руководства («Пояснение», «Использование», «Применение»), таблицы градаций, перечня показателей, дерева классификации и рабочего листа (Excel). Именно это стоит скачать в первую очередь
• Условия использования руководства «Применение», 2-е издание, «Градация нефункциональных требований 2018» ─ часть «Применение», пересмотренная в марте 2019 года
• Условия использования учебных материалов по «Градации нефункциональных требований» ─ комплект, которым можно пользоваться на внутренних семинарах
• Модельные сделки и договоры для информационных систем ─ материалы IPA о связи договора и определения требований, о которых речь в главе 6

Определения уровней и ориентиры годового простоя, процитированные в главе 3, взяты из рабочего листа в указанном выше «основном комплекте (японская версия)» (пункт A.1.1.1 «время эксплуатации (обычный режим)» и пункт A.1.5.1 «коэффициент готовности»).

Тем, кому нужно разобрать требования к бизнес-системе

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

KomuraSoft LLC при консультациях по заказной разработке и доработке Windows-приложений для бизнеса и веб-систем вместе с заказчиком ещё на этапе требований разбирает производительность, эксплуатацию и поведение при сбое — в том же ключе, что описан в этой статье. Можно начать и раньше: «текущая система постепенно становится медленнее» или «хотим пересмотреть эксплуатационные договорённости заодно с обновлением».

Похожие статьи

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

Связанные темы

Эти страницы показывают тему статьи в более широком контексте услуг и решений.

Услуги по этой теме

Статья напрямую связана со следующими услугами.

Частые вопросы

Вопросы, которые часто возникают при консультациях по теме статьи.

Что такое нефункциональные требования?

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

Можно ли пользоваться «Градацией нефункциональных требований» бесплатно? Где её взять?

Её можно бесплатно скачать с сайта IPA. В комплекте — таблица градаций, перечень показателей, дерево классификации, рабочий лист и руководство (три части: «Пояснение», «Использование», «Применение»). Актуальная версия — «Градация нефункциональных требований 2018», опубликованная в апреле 2018 года. Сейчас на сайте IPA страница лежит в архиве, но на практике набор по-прежнему широко используют как ориентир, чтобы проверить, не пропущены ли нефункциональные требования.

Нужно ли определять все 238 пунктов?

Нет. Даже руководство не предполагает, что каждую метрику будут разбирать по отдельности. Заложен поэтапный порядок: сначала выбрать модельную систему, близкую к своей, и задать общий ориентир; затем скорректировать важные пункты таблицы градаций под реалии компании; и только в нужном объёме детализировать их по перечню показателей. Для бизнес-системы малого и среднего предприятия уже одного согласования важных пунктов достаточно, чтобы отсечь большую часть споров из-за незафиксированных решений.

Когда следует определять нефункциональные требования?

На этапе определения требований. Цели по доступности и производительности задевают саму основу серверной конфигурации и архитектуры, поэтому менять их уже в ходе разработки дорого и по деньгам, и по срокам. «Модельные сделки и договоры для информационных систем» IPA тоже исходят из того, что результатом этапа определения требований будет документ не только по функциональным, но и по нефункциональным требованиям. Если перед сравнением смет не выровнять нефункциональные предпосылки, заказчик уже не отличит, чем вызвана разница в сумме — разной конфигурацией или просто слишком оптимистичной оценкой.

Об авторе

Страница с профилем автора статьи.

Го Комура

Представитель KomuraSoft LLC

Специализируется на разработке программного обеспечения для Windows, техническом консалтинге и расследовании сбоев, особенно в проектах с унаследованными системами и трудно воспроизводимыми ошибками.