Как задавать требования к качеству ПО в цифрах?

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

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

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

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

При этом остаётся прагматический вопрос — а что именно писать в требования, чтобы они были полезными, измеримыми, реализуемыми?

С точки зрения системной инженерии, требования к качеству программной системы являются разновидностью системных ограничений (constraints) и в этом они отличаются от требований к способностям (capabilities) системы, в мире ИТ обычно называемых «функциональными».

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

Давайте попробуем сделать это хотя бы ремеслом.

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

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

1. Если вы работаете на стороне заказчика, нужно обезопасить себя от того, что система формально выполняет все необходимые функции, но работает слишком медленно, слишком неудобна для пользователя, теряются данные или, например, планировалась одновременная работа 1000 пользователей, а система может поддерживать максимум 100.
2. Если вы работаете на стороне подрядчика, требуется аргументировано объяснить заказчику, почему при выборе определённого решения (более безопасного или более отказоустойчивого) стоимость или сроки разработки увеличиваются, какие плюсы заказчик получит в случае выбора этого решения, а также, нужно ли вообще для требуемой системы такое улучшение.
3. Если вы поддерживаете/дорабатываете систему, нужно иметь возможность оценивать её, выявлять зоны развития и слабые места, при необходимости сравнивать с аналогичными продуктами конкурентов.
4. В любом случае, если вы делаете требования к системе, нужно подчеркнуть необходимые моменты в спецификации для разработчика и поставить задачи так, чтобы быть уверенным, что ПО действительно будет отвечать поставленной цели, а не просто формально соответствовать спецификации.
5. И заказчику, и подрядчику нужен список чётких, проверяемых, известных заранее критериев, которым должна соответствовать система, чтобы избежать споров при сдаче.

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

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

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

Из десятков возможных атрибутов качества стоит начать с наиболее важных в большинстве проектов:

1. Важнейшие характеристики качества при эксплуатации (Run-Time), также называемого внешним качеством (external quality):

• Производительность
• Масштабируемость
• Доступность
• Надёжность
• Информационная безопасность

2. Важнейшие характеристики качества при модернизации (Design-Time), также называемого внутренним качеством (internal quality):

• Безошибочность кода
• Изменяемость кода
• Переносимость кода

3. Специалисты по пользовательским интерфейсам, человеко-машинному взаимодействию также предлагают характеристики качества, называемые «качество в использовании» (Quality in Use).

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

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

• Результативность применения
• Обучаемость
• Эффективность применения
• Точность применения
• Утомляемость при применении
• Удовлетворённость применения

В этой статье дальше мы рассмотрим только формулирование требований к первым 4-м аспектам внешнего качества.

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

Про качество в использовании также читайте в отдельной статье.

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

Давай рассмотрим несколько вариантов действий по выявлению и формулированию требований к качеству:

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

Скорее всего, заказчик честно скажет, что хочет быстрое, надёжное и удобное ПО. При попытке уточнить детали, вы получите либо размытые требования («должна быть обеспечена безопасность передаваемых данных»), либо завышенные.

Завышенные требования — это требования, озвученные без понимания того, нужны ли они для конкретной системы и к каким временным и материальным затратам приведет их выполнение (например, требование к доступности, звучащее как «система должна быть доступна 24/7»).

Требования, полученные таким образом и не проработанные аналитиком дополнительно, будет невозможно протестировать при сдаче ПО заказчику, либо их будет очень сложно реализовать.

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

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

2. Второй вариант, идеальный: расчёты

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

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

3. Вариант третий: сформировать требования к качеству своей системы на основе имеющихся стандартов

Однако, предлагаемые в различных стандартах (например в семействе стандартов ISO/IEC) и литературе (например в The Quest for Software Requirements, Roxanne E. Miller) списки критериев качества часто оказываются слишком громоздкими или их тяжело использовать на практике. Приводимая в них классификация систем может быть устаревшей или неактуальной для вашей области, а предлагаемые характеристики качества часто тяжело «переводить» на язык заказчика для обсуждения.

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

4. Вариант четвёртый: привлечь отдельных специалистов
(например, эксперта в области информационной безопасности)

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

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

5. Вариант пятый: проанализировать показатели качества в аналогичных системах

Такой подход называется benchmarking — измерение аналогичных показателей систем-конкурентов, имеющих схожую сферу применения и параметры среды.

Тогда требование можно формулировать как:

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

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

6. Вариант шестой: использовать типовые профили качества

В каждом из описанных выше вариантов есть здравое зерно, однако в чистом виде применять их сложно.

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

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

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

Производительность (П) — характеристика, которая отвечает за то, какое количество каких операций и как быстро может выполняться в системе, насколько система подходит для одновременной работы нескольких пользователей (или взаимодействия с несколькими системами).

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

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

Дополнительно можно разделить атрибут Производительность на два под атрибута: Пропускная способность (throughput) и Задержка (latency).

Пропускная способность может измеряться в:

• Количестве обрабатываемых запросов в единицу времени или
• Количестве одновременно работающих пользователей

Пример требования к пропускной способности:

Это требование можно брать в работу, если сопроводить его допущением, что каждый пользователь производит в среднем не более 1 запроса в 20 секунд (3 запроса в минуту).

Задержка обычно измеряетя средним временем исполнения запроса.

Пример прагматичного требования к задержке:

Кроме того, очень часто бывает важным оговорить не только и не столько количество запросов, но и объём данных, которые хранит или обрабатывает система.

Масштабируемость (М) показывает, насколько можно увеличить мощность системы и сколько это будет стоить. Чем больше ресурсов придётся вкладывать дополнительно, тем менее масштабируемой считается система.

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

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

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

Обычно эти характеристики ухудшаются, вопрос только в том, насколько быстро.

Базовым требованием к масштабируемости является принципиальная масштабируемость:

Это может показаться странным, но иногда встречаются программные архитектуры, которые принципиально не позволяют подключаться к системе большему, чем N, числу пользователей, что приводит к отказам в обслуживании для всех M > N пользователей.

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

Давайте рассмотрим эти 4 варианта зависимости подробнее:

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

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

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

Степенной характер (где 0 < n < 1 — «график корня») зависимости остаётся идеальным для большинства систем. Он хуже, чем логарифмический, но при этом всё равно очень выгодный для бизнеса, т.к. на обслуживание каждой следующей единицы нагрузки (пользователей, запросов, объёмов данных) бизнес тратит всё меньше и меньше ресурсов. Хорошие архитекторы умеют создавать архитектуру с таким качеством.

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

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

Степенной характер (где n > 1 — «график параболы») зависимости — это самый худший вид масштабируемости (не считая принципиальной немасштабируемости — отказа системы при увеличении нагрузки за рамками плановой).

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

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

Пример такого требования:

* — под производительностью здесь понимается количество обрабатываемых запросов в единицу времени

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

Доступность (Д) — характеристика, показывающая, какое время может простаивать система, а также процент времени, который система должна быть доступна для работы.

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

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

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

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

Как посчитать допустимое время простоя? Проще всего это делать через расчёт допустимого ущерба. Например, заказчик разработки — интернет-магазин, который продаёт товаров на 1 миллион рублей в месяц.

Если считать грубо, не принимая во внимание распределение заказов во времени, один час простоя магазина может обернуться потерями в 1 млн / (30 дней * 24 часов) = 1 400 рублей в день или 33 тысячи рублей в месяц.

Допустимы ли такие потери? Тут решать заказчику, но чтобы у него было больше фактуры для принятия решения, команда разработки, если она уже известна, может посчитать свои расходы и ежемесячные затраты на снижение времени простоев, например, в 5 раз — с 1 часа в день до 12 минут.

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

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

Обратите внимание, что требование, которое охватывает более длительный интервал наблюдения — сутки, не является простой суммой допустимого времени простоя за час — 24 * 5 = 120 минут, а более жёстко по характеру, это обычная практика, следующая принципу, что допустимые отклонения от нормы не должны становиться нормой и накапливаться при суммировании.

Таким образом можно дополнить и более длительным по интервалу наблюдения требованием:

Все 3 требования совместимы и органично дополняют друг друга, задавая прагматичные нормы доступности.

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

Например, посчитаем для одного часа — 5 минут простоя в час = 55 / 60 = ~92% времени доступности.

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

Для тренировки можете попробовать самостоятельно рассчитать коэффициент доступности для требований Д-1 и Д-3 выше.

Надёжность (Н) — это способность системы работать с определённой долей сбоев, и обычно характеризуется 2-мя показателями: 1) вероятность сбоя, и временем восстановления после сбоя.

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

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

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

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

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

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

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

Этот показатель удобнее всего задавать через benchmarking — измерение аналогичного времени в продуктах-конкурентах и изучение опыта пользователя.

Например, в интернете многие пользователи привыкли, что в случае сбоя в показе страницы пользователь может её обновить принудительно и уже на этот раз страница покажется правильно, иначе это будет уже выглядеть не только как сбой, но и в целом недоступность системы (хоть и для одного пользователя, а не всех). Таким образом ожидаемое время восстановления после сбоя в отображении веб-страницы — 0,5-1 секунды.

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

Пример формулировки требования ко времени восстановления после сбоя:

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

Чтобы в любом, даже мелком проекте не изобретать велосипед и не придумывать, как оценить каждый из атрибутов качества, мы можем определить типовые уровни качества и затем посмотреть, что каждый из уровней значит применимо к конкретным атрибутам качества.

Можно условно выделить четыре уровня качества, на котором может находиться система по каждому из аспектов качества:

• 0 — низкий уровень, посредственное качество
• 1 — средний уровень, обычное, приемлемое качество
• 2 — высокий уровень, повышенное качество
• 3 — исключительный уровень, необычное, редкое качество

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

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

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

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

В старых советских стандартах на качество ПО была предложена классификация из 12 категорий систем — см. ГОСТ 28195-89.

Мы не каждый день разрабатываем новые СУБД или САПР, поэтому эта классификация порядком потеряла актуальность для массовой коммерческой разработки и так что давайте рассмотрим классификацию прикладного ПО и систем, соответствующую реалиям нашего времени:

1. Простые интернет-сайты:
1.1. Home Site — личный сайт
1.2. Business Site — сайт компании

2. Публичные мобильные приложения:
2.1. Consumer Mobile App — мобильное приложение для частных лиц
2.2. Enterprise Mobile App — мобильное приложение для компаний

3. Потребительские интернет-сервисы и настольные приложения:
3.1. Consumer Web Service — публичный интернет-сервис для частных лиц
3.2. Consumer Desktop App — настольная программа для частных лиц (требует установки)

4. Отдельные программные компоненты:
4.1. Custom Component — заказной, уникальный компонент
4.2. Serial Component — тиражируемый, распространяемый компонент

5. Заказное ПО для компаний:
5.1. Custom Enterprise Desktop/Web App — заказное клиентское приложение для бизнеса (требует установки)
5.2. Custom Enterprise Server App — заказное серверное приложение для бизнеса (требует установки)

6. Тиражируемое ПО для компаний:
6.1. Enterprise Desktop App — тиражируемая настольная программа для бизнеса (требует установки)
6.2. Enterprise Server App — тиражируемая серверная программа для бизнеса (требует установки)

7. Массовые облачные интернет-сервисы по подписке:
7.1. B2C SaaS — облачный интернет-сервис для частных лиц, распространяемый по модели подписки (похож на 3.1, но тут пользователь получает собственное пространство для работы, а не просто личный кабинет)
7.2. B2B SaaS — облачный интернет-сервис для компаний, распространяемый по модели подписки (не требует установки)

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

Как пользоваться этой таблицей? Необходимо найти класс, к которому относится ваша система (первый столбец) и посмотреть, какому уровню качества должны соответствовать её атрибуты (столбцы со 2 по 9).

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

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

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

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

Например, если ваша система является прототипом, понижать уровень качества на 3 пункта и т.д.

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

Можно ли подрядчику, исполнителю, команде подписывать требования к внешнему качеству ПО в таком виде (как показано выше)?

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

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

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

К таким ограничениям относятся:

• скорость и надежность сетевых соединений;
• совместимость с версиями оборудования, ОС и браузеров;
• ограничения, связанные со смежными системами, с которыми взаимодействует наша система (ограничения на протоколы взаимодействия, показатели доступности и производительности смежных систем и тд);
• другие ограничения в зависимости от контекста.

Как могут выглядеть типовые допущения об оборудовании, на которые может опираться команда разработки:

Как инженеру по требованиям в повседневной работе использовать материалы этой статьи? Вот примерный план действий.

1. Определить существующие ограничения (например, связанные со смежными системами или оборудованием);
2. Определить класс своей системы или понять, к какому классу она ближе и чем от него отличается (если не получается найти систему в приведенном выше списке классов);
3. Определить уровень качества: для этого посмотреть рекомендованный уровень качества разных атрибутов для систем выбранного класса. При необходимости учесть уровень зрелости системы и снизить уровень качества в соответствии с ним.

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

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

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

Потренироваться в формулировании требований к внешнему качеству ПО вы можете самостоятельно или на нашем курсе «Системный анализ и Разработка требований в ИТ-проектах».

Некоторые отраслевые стандарты, которые использовались при подготовке статьи:

Устаревшие советские стандарты:

1. ГОСТ 28195-89 Оценка качества программных средств. Общие положения
2. ГОСТ 28806-90 Качество программных средств. Термины и определения

Современные международные стандарты:

1. ГОСТ Р ИСО/МЭК 25010-2015. «Информационные технологии. Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Модели качества систем и программных продуктов»
2. ГОСТ Р ИСО/МЭК 25021-2014. «Информационные технологии (ИТ). Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Элементы показателя качества»
3. ГОСТ 27.002-2015. МЕЖГОСУДАРСТВЕННЫЙ СТАНДАРТ. НАДЕЖНОСТЬ В ТЕХНИКЕ. Термины и определения

Денис Бесков — основатель и руководитель школы системного анализа и проектирования Systems Education. Автор курсов, ИТ-предприниматель и методист.


• Более 20 лет в индустрии на позициях разработчика баз данных, архитектора, системного аналитика, руководителя отдела анализа (35 человек) и менеджера продуктов
• Основной автор федерального профстандарта «Системный аналитик»
• Вёл учебный курс по анализу требований в МФТИ
• Организатор Летнего Аналитического Фестиваля 2013 и онлайн-марафона «Проектные истории» 2016
• Более 20 выступлений на ИТ-конференциях
• Certified Professional for Requirements Engineering (IREB CPRE)