+7 (499) 673 2500
ok@systems.education
Telegram
Как задавать требования к ПО
в цифрах. Внешнее качество

Кому и для чего нужны требования к качеству ИТ-системы?
При формировании требований к ИТ-системе часто требуется описать не только функциональные требования — что она должна делать или позволять делать, но и так называемые «нефункциональные» (неудачный, но устоявшийся термин) — насколько хорошо:
  • атрибуты качества — свойства, отражающие качество системы в целом или её отдельных функций;

  • ограничения — допустимые и недопустимые пространства решений.
Изначально стратегия определялась как общий план, без детализации, достижения долгосрочной цели. Она формализовывала как минимум три фактора:

  1. Где мы сейчас
  2. К чему/Куда мы должны прийти?
  3. Как нам это сделать?

Сегодня речь пойдёт только про атрибуты качества, а про ограничения поговорим в отдельной статье.
Начинающему ИТ-аналитику и проектировщику может быть достаточно работать на уровне описания функций и сценариев, но в какой-то момент проектируемая система становится достаточно сложной и возникает риск того, что конечный продукт будет работать не так, как хочет заказчик, система будет работать ненадежно или слишком медленно, пользователи будут допускать ошибки и т.д.
Если с описанием функций систем многие работать привыкли, то с описанием требований к качеству системы могут возникать трудности.
Эта статья поможет разрешить наиболее часто встречающиеся сложности, ответить на такие типичные вопросы, как:
  • как выбрать характеристики качества системы, к которым предъявляются требования?

  • как определить конкретные значения этих требований?
Вот несколько целей, для которых потребуется выявлять и оценивать атрибуты, характеризующие качество системы:
  1. Если вы работаете на стороне Заказчика — нужно обезопасить себя от того, что система формально выполняет все необходимые функции, но работает слишком медленно, слишком неудобна для пользователя, данные теряются или еще что-то (например, планировалась одновременная работа 1000 пользователей, а система «тянет» максимум 100).

  2. Если вы работаете на стороне Подрядчика — требуется аргументировано объяснить Заказчику, почему при выборе определенного решения (более безопасного или более отказоустойчивого) стоимость или сроки разработки увеличиваются и какие плюсы Заказчик получит в случае выбора этого решения, а также, нужно ли вообще для требуемой системы такое улучшение.

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

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

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

Вера Писаревская:
    Приведу пару примеров того, как недостаточное внимание в качеству системы может привести к не очень хорошим последствиям.
    Первый пример: крупной компании требовалось сделать систему, представляющую собой интеграционный слой с несколькими сервисами для обмена данными между двумя другими системами. Были сформированы требования к работе сервисов, а разработка была отдана команде подрядчика. После окончания разработки система была тщательно протестирована и отдана в промышленную эксплуатацию и обе стороны были довольны, по крайней мере, какое-то время. Примерно через год возникла необходимость переиспользовать разработанные сервисы, немного доработав их уже силами компании — Заказчика. Однако выяснилось, что требования к масштабируемости не были зафиксированы, не обсуждались и, соответственно, не тестировались. Чтобы переиспользовать сервисы, пришлось практически полностью переписать систему, что заняло почти столько же времени, сколько первоначальная разработка.
    Еще один пример, с которым, может столкнуться подрядчик или команда разработки. При проектировании системы отсутствуют требования к скорости обучения пользователей, система содержит сложный функционал и разрабатывается исходя их предположения, что заказчик возьмет на себя работы по обучению пользователей, к тому же разработчикам, которые погружены в работу над системой кажется, что она проста и интуитивно понятна. Однако в процессе сдачи выясняется, что функционал системы работает полностью корректно, но разобраться в нем самостоятельно практически невозможно, требуются длинные инструкции или даже обучение. Это приводит к увеличению порога вхождения для пользователей системы, росту количества пользовательских ошибок и другим неприятным последствиям, заказчик недоволен и просит переделать систему, а на финальном этапе это крайне дорого.
    Как выявлять требования к качеству?
    Итак, вы понимаете, что сформировать требования к качеству разрабатываемого продукта — очень важно и что это поможет достигнуть сразу нескольких целей. Но как это сделать? Обычно в голову приходит несколько стандартных вариантов:
    • Вариант первый — напрямую спросить заказчика, какую систему он хочет получить. Но, скорее всего, заказчик честно скажет, что хочет быстрое, надежное и удобное ПО, а при попытке уточнить, требования будут либо размытыми (например требование к безопасности, звучащее как «должна быть обеспечена безопасность передаваемых данных»), либо завышенными, озвученными без понимания того, нужны ли такие требования для конкретной системы и к каким временным и материальным затратам приведет их выполнение (например требование к доступности, звучащее как «система должна быть доступна 24 X 7»). Требования, полученные таким образом, и не проработанные дополнительно аналитиком будет либо невозможно протестировать при сдаче ПО заказчику, либо очень сложно реализовать, что в любом случае приведет к дополнительным конфликтам с заказчикам, то есть даст эффект, ровно обратный тому, к которому вы стремитесь, формируя требования к качеству системы. Конечно, требования нужно обсуждать и согласовывать с Заказчиком, но перекладывать на него работу по формулированию требований — не очень хорошая идея.
    • Вариант второй — изучить имеющиеся стандарты и основываясь на них сформировать требования к качеству своей системы. Однако предлагаемые в различных стандартах (например в семействе стандартов ISO/IEC 250XO) и литературе (например в The Quest for Software Requirements, Roxanne E. Miller) списки критериев качества часто оказываются слишком громоздкими или их тяжело использовать на практике. Приводимая в них классификация систем может быть устаревшей или не актуальной для вашей области, приводимые характеристики качества часто тяжело «переводить» на язык заказчика для обсуждения. В итоге требуется либо потратить много усилий на адаптацию такого стандарта под свою ситуацию, либо полученные требования получаются нежизнеспособными. Опять же, заглядывать в специальную литературу полезно, но брать решения as is получается не всегда.
    • Вариант третий — привлечь отдельных специалистов (например эксперта в области информационной безопасности), но будем честны, далеко не всегда есть такая возможность. Еще иногда формирование требований к качеству системы сваливают на Архитектора, ссылаясь на то, что у него широкая техническая экспертиза. Но такой подход тоже имеет свои минусы, потому что Архитектор — это зачастую исполнитель и формируя требования к качеству он по сути пишет требования сам для себя и может быть не объективен, причем может оказаться как то, что архитектор решил схалтурить, так и то, что архитектор в погоне за действительно крутой системой написал требования, реализация которых слишком сильно увеличит стоимость и сроки разработки.
    • Вариант четвертый — проанализировать показатели качества в аналогичных системах (такой подход называется benchmarking - сопоставительный анализ на основе эталонных показателей) и опереться на полученные значения, чтобы сделать свою систему лучше, или, хотя бы, не хуже систем конкурентов. У этого подхода есть существенные минусы: не всегда системы-аналоги есть в свободном доступе и возможно их изучение, а если система в свободном доступе - часто чтобы измерить такие ее характеристики как безопасность и производительность потребуется нанять отдельных специалистов, что не всегда возможно. Это делает такой подход для большинства случаев очень дорогостоящим или невозможным.
    В каждом из описанных вариантов есть здравое зерно, однако в чистом виде применять их сложно. В этой статье будет предложен подход, который позволит формировать четкие и тестируемые требования к качеству в терминах, понятных Заказчику. Подход может быть использован в качестве готового инструмента для оценки уровня качества системы или взят за основу и видоизменен в зависимости от целей и контекста.
    Что же такое качество?
    После того, как вы поняли, что требования к качеству системы придется фиксировать, причем часто именно самостоятельно, у аналитика и команды в целом возникает ряд вопросов: что вообще считать качеством? какие характеристики качества нужно учитывать? как задавать требования к качеству и к каким показателям нужно стремиться?
    В стандартах встречаются такие определения того, что такое качество:
    • Качество — совокупность свойств и характеристик продукции или услуги, которые придают им способность удовлетворять обусловленные или предполагаемые потребности потребителя (ИСО 8402—94).
    • Качество — степень соответствия совокупности присущих характеристик объекта требованиям (ГОСТ Р ИСО 9000-2015).
    Иными словами, качество — это соответствие продукта ожиданиям. Однако ожидания заказчика бывает трудно выявить из-за нескольких стейкхолдеров, отсутствия у самого заказчика четкой картины, неспособности внятно сформулировать. Поэтому полезно иметь список параметров, по которым оценивается качество продукта.
    Если обратиться к стандартам, то можно выделить два семейства стандартов качества, которые развивались параллельно, независимо друг от друга.
    Классификация требований к качеству в отраслевых стандартах
    Один из них (ISO/IEC 25010:2011) описывает требования к качеству программного обеспечения, а второй (ГОСТ Р ИСО/МЭК 25010-2015) описывает требования к качеству взаимодействия ПО и пользователя.
    В первом рассматриваемом стандарте выделяется внутреннее и внешнее качество ПО.
    • Внутреннее качество — то, с чем чаще всего сталкиваются в своей работе разработчики и что влияет на стоимость и сложность доработки и поддержки системы, но не обязательно сразу влияет на качество ее работы (например спагетти код, слабая связанность и др). В статье не будем подробно останавливаться на этом виде качества, т.к. обычно это больше ответственность архитектора или разработчика, а не аналитика.
    • Внешнее качество — то, что видно пользователю и влияет на функционирование системы. В него входят атрибуты качества продукта (product quality attributes) - это характеристики, которые могут быть измерены автоматизированно или людьми (например, информационная безопасность, надежность и др) и отражают нефункциональные требования к системе.
    Во втором стандарте описываются атрибуты качества использования (quality in use) — характеристики, которые выявляются только при взаимодействии пользователя с системой и показывают, насколько пользователь удовлетворен системой (количество ошибок, скорость обучения и тд). Это стремление сформулировать требования к эргономике, т.к. в более ранних стандартах подобные требования звучать расплывчато (например «интерфейс должен быть интуитивно понятным») и их трудно тестировать.
    Безусловно, все категории качества связаны между собой, внутреннее качество влияет на внешнее, а качество продукта влияют на качество использования и удовлетворенность пользователя, однако в такой классификации, разделив на категории, атрибуты качества удобнее всего оценивать.
    Наиболее полно закрыть вопрос с требованиями к качеству позволяет выбор полезных для конкретной задачи требований из обоих стандартов и использование их. В этой статье мы более подробно остановимся на атрибутах качества продукта (внешнем качестве ПО), а потом отдельно, во второй части, рассмотрим атрибуты качества использования.
    Основные атрибуты качества продукта
    Можно выделить несколько наиболее часто используемых атрибутов внешнего качества (качества продукта), для удобства будем рассматривать шесть основных атрибутов, которые являются типовыми и полезными для большинства. Однако в зависимости от особенностей проекта и потребностей могут выделяться и другие атрибуты.
    Атрибуты качества продукта (product quality attributes) с кратким описанием:
    1. Производительность (возможное количество одновременных операций в системе)

    2. Эффективность (использование доступных вычислительных мощностей)

    3. Надёжность (вероятность отказа системы)

    4. Доступность (режим работы системы без простоев)

    5. Информационная безопасность (вероятность сбоя, в результате которого могут быть убытки)

    6. Масштабируемость (способность системы к увеличению нагрузки)
    Ожидания от уровня качества продукта не меняются кардинально от проекта к проекту, а обусловлены категорией системы и другими, вполне конкретными факторами. Чтобы в любом, даже мелком проекте не изобретать велосипед и не придумывать, как оценить каждый из атрибутов качества — можно определить типовые уровни качества и затем посмотреть, что каждый из уровней значит применимо к конкретным атрибутам качества.
    Можно условно выделить четыре уровня качества продукта:
    Не обязательно при разработке каждой системы стремиться к достижению исключительного или даже высокого уровня, все зависит от целей, которых нужно достичь. Например в системе для внутреннего заказчика может больше цениться надежность, а в системе для внешних пользователей может быть важнее быстродействие.
    Важность учёта допущений и ограничений
    Перед тем, как перейти к описанию атрибутов качества и того, как измерить их уровень, нужно отметить, что и заказчику, и команде разработки важно помнить, что помимо качества системы есть еще некоторые допущения и ограничения, которые важно обсудить (и зафиксировать!) до начала разработки, иначе может оказаться, что требования и сама разработка не имела смысла. К таким ограничениям относятся:
    • скорость и надежность сетевых соединений,

    • совместимость с версиями оборудования, ОС и браузеров,

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

    • другие ограничения в зависимости от контекста.
    Как определить правильный уровень качества продукта?
    Какие же конкретные значения должны принимать атрибуты качества, чтобы соответствовать тому или иному уровню? Ниже в таблицах представлены диапазоны значений для каждого атрибута.
    Производительность (П) — характеристика, которая отвечает за то, какое количество, каких операций и как быстро может выполняться в системе, насколько система подходит для одновременной работы нескольких пользователей (или взаимодействия с несколькими системами).
    При проектировании системы есть большая разница, будет ли ее использовать десять пользователей или сотни тысяч пользователей, также важно, предполагается ли пиковая нагрузка или распределение запросов от пользователей будет равномерным.
    Например, если вы проектируете портал, на котором будут доступны результаты экзамена, вы должны учесть не только общее количество пользователей, но и тут факт, что почти все они одновременно зайдут на портал, чтобы посмотреть свои результаты и он должен выдержать такой пик нагрузки.
    В таблице приведены значения атрибутов для определенного процента случаев, а не средние величины. Это сделано, потому что иногда встречается ситуация или сценарий, сильно выделяющийся на фоне других (например первоначальная загрузка данных в систему или первый день работы, когда все пользователи получают доступ к системе и увеличивается нагрузка) и данный подход к изменению качества позволяет не учитывать его в общей статистике, а считать исключением.
    Эффективность (Э) — характеристика, показывающая условно насколько хорошо ПО использует доступные вычислительные мощности. По сути, без определения требований к эффективности, все остальные требования не имеют смысла, т.к. их можно переложить на сколь угодно дорогое оборудование. Например, если вы заказали разработку мобильного приложения для сотрудников, а получили приложение, отвечающее всем требованиям, но для работы которого требуется последняя версия айфона - приложение либо будет бесполезным, либо вы должны добавить к стоимости разработки стоимость покупки айфонов для всех сотрудников. В некоторых случая требования к эффективности можно заменить указанием конкретных видов и характеристик оборудования. Вкупе с требованиям к производительности требования будут достигать той же цели.
    Надежность (Н) — отказоустойчивость системы (вероятность сбоя), а также время восстановления после сбоя. При определении этой характеристики важно понимать, что обойдется заказчику дороже: сбой работы системы и понесенные в связи с этим репутационные и иные убытки или затраты на проектирование и поддержание более надежного решения. Например если проектируется платежная система и сбой может повлечь потерю денежных средств клиента — надежность становится принципиальной характеристикой, а если проектируется информационный портал, то серьёзные затраты на повышение надежности могут быть неоправданными.
    Доступность (Д) — характеристика, показывающая, какое время может простаивать система, а также процент времени, который система должна быть доступна для работы. Тут можно например отметить, что если вы делаете систему для использования сотрудниками компании и все они работают в Москве — может быть допустимо большое время простоя — по сути, все нерабочее время и выходные, а если сотрудники распределены по всей стране — возможность для простоя системы резко сокращается, т.к. все работают в разных часовых поясах.
    Информационная безопасность (ИБ) — характеристика, которая касается риска сбоя\утечки данных, в результате которой будут понесены убытки. Будем рассматривать эту характеристику с точки зрения вероятности материального ущерба и иметь в виду, что обычно стоимость защиты должна быть не больше, чем стоимость ущерба, который может быть нанесен в системе. Речь идет конечно об утечке одной записи, а не всех базы данных.
    Масштабируемость (М) — характеризует возможности программной системы по увеличению нагрузки, с которой она будет успешно справляться, а также то, насколько можно увеличить мощность системы и сколько это будет стоить (чем больше придется вкладывать дополнительно, тем менее система масштабируемая). Коварство этого атрибута качества в том, что сразу после сдачи системы он может быть незаметен и поэтому казаться неважным, однако при попытке доработать систему и увеличить ее мощность становится критичным и отсутствия изначальных требований к масштабируемости может привести к необходимости полностью или частично переписать систему. Если нужно увеличить мощность системы в десять раз, придется нам заплатить в десять раз больше за оборудование или в сто раз больше или всего в два раза больше за оборудование? Ответ на этот вопрос показывает, насколько хорошо масштабируется система.
    Бизнес-заказчику не всегда важны точные величины, однако важно иметь возможность оценить выполнение требований к качеству системы. Величины в таблицах приведены примерные, их можно адаптировать под текущий контекст.
    Как понять, к какому значению атрибутов качества следует стремиться в конкретном случае?
    Знать, из каких атрибутов складывается качество системы в глазах пользователей полезно само по себе. Но может возникнуть вопрос, как понять, на каком уровне должны быть характеристики качества системы именно в вашем случае. Предложенная в ГОСТ 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 WebApp

    3.2. Consumer Desktop App

    4. Компоненты:

    4.1. Заказной компонент

    4.2. Тиражируемый компонент

    5. Заказное ПО:

    5.1. Custom Enterprise Desktop App

    5.2. Custom Enterprise Service

    6. ПО для компаний:

    6.1. Enterprise Desktop App

    6.2. Enterprise Server App

    7. Интернет-сервисы:

    7.1. B2C SaaS

    7.2. B2B SaaS
    Если проектируется клиент-серверное приложение, то скорее всего требования по качеству будут разные к серверной части и клиентской части. Поэтому более правильно будет сказать, что это классификация не систем, а компонентов программных систем. Нужно помнить, что требования пишутся не только к системе в целом, но и к ее компонентам.
    Далее приведена достаточно объемная таблица, в которой сведены атрибуты качества и желательных для них уровень в зависимости от категории системы.
    В таблице можно найти класс, к которому относится ваша система (первый столбец) и посмотреть, какому уровню качества должны соответствовать ее атрибуты (каждый атрибут это отдельный столбец со 2 по 13). Разумеется, в вашей работе могут быть какие-то нюансы, влияющие на требования к качеству, но в таблице приведена некоторая "пристрелка", которую можно брать за основу. Все характеристики можно вычислить уникальным образом, основываясь на вашем знании о том, какой проект, какой заказчик, какие есть ограничения по срокам, стоимости и чему-то еще.
    Также нужно отметить, что если разрабатывается прототип — уровень качества для большинства атрибутов может (и должен!) быть ниже, т.к. разработка преследует немного другие цели (например, показать заказчику бета версию).
    Как использовать в работе знания об атрибутах качества и их уровне?
    Как аналитику в повседневной работе использовать материалы этой статьи? Вот примерный план действий:
    1. Определить существующие ограничения (например связанные со смежными системами или оборудованием);

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

    3. Определить уровень качества: для этого посмотреть рекомендованный уровень качества разных атрибутов для систем выбранного класса;

    4. При необходимости - учесть уровень зрелости системы и снизить уровень качества в соответствии с ним;

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

    Также можно видоизменять конкретные значения под свою ситуацию и вести их в аналогичной таблице, что поможет систематизировать требования
    В качестве примера оформления можно посмотреть пример документа с требованиями к качеству системы: (ссылка)
    Выявление отдельных атрибутов и конкретные числовые значения для характеристик помогут вести более конструктивный диалог с архитекторами, заказчиками и другими участниками проекта. А понимание того, что и как влияет на качество системы делает вашу работу как аналитика более ценной.
    В следующей части мы расскажем про то, почему важно выставлять требования к качеству взаимодействия пользователя с системой и как это делать.
    Приложения:
    Некоторые стандарты качества ПО, которые использовались при подготовке материалов статьи.
    ГОСТ 28195-89 Оценка качества программных средств. Общие положения

    ГОСТ 28806-90 Качество программных средств. Термины и определения

    ISO/IEC 25010:2011, Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — System and software quality models

    ISO/IEC 25030:2007, Software engineering — Software product Quality Requirements and Evaluation (SQuaRE) — Quality requirements