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

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

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

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

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

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

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

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

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

Функциональные требования — это то, что делает система, например «может зарегистрировать заказ» или «может напечатать отчёт». Обсуждение при разработке естественным образом сосредоточивается именно на этом.

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

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

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

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

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

Содержание строится на следующем наборе инструментов.

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

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

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

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

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

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

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

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

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

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

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

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

• Часы работы и влияние остановки на бизнес (доступность)
• Периодичность резервного копирования и то, «до какого момента» и «за сколько часов» нужно восстанавливать данные при сбое (доступность / эксплуатация)
• Текущий объём/количество данных и прогноз на несколько лет вперёд (производительность / масштабируемость)
• Целевые значения времени отклика и времени пакетной обработки. Подойдёт даже «не хуже текущей системы», лишь бы был зафиксирован ориентир (производительность)
• Распределение ответственности за мониторинг, резервное копирование и первичное реагирование на сбой (эксплуатация / сопровождение)

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

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

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

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

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

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

Итог

Соберём ключевые моменты «Градации нефункциональных требований» IPA.

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

Определить заранее, «с каким качеством система должна продолжать работать», так же важно, как определить, «что строить». Это самый дешёвый способ предотвратить и систему, которая работает, но непригодна для использования, и последующие споры вокруг неё.

Тем, кто испытывает трудности с упорядочиванием требований для бизнес-системы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Об авторе

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

Го Комура

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

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