Продолжая обучение начинающих системных и бизнес-аналитиков основам разработки ТЗ, сегодня рассмотрим, что такое нефункциональные требования к ПО и как их составить. Также разберем, чем доступность отличается от надежности, как измерить качество пользовательского интерфейса и других характеристик проектируемой системы с комментариями BABOK®Guide, а также рекомендациями российских ГОСТ’ов и зарубежных стандартов.
Что такое нефункциональные требования и какие они бывают: взгляд BABOK®Guide
Как логично следует из названия, функциональные требования описывают функции ПО, т.е. его поведение, а нефункциональные относятся к характеристикам и условиям работы. Руководство к профессиональному своду знаний по бизнес-анализу BABOK®Guide отмечает, что нефункциональные требования означают особенности эксплуатации: производительность, информационную безопасность, удобство использования и прочие свойства, выражаемые в измеримых показателях, которые являются своего рода ограничениями варианта реализации (дизайна) решения.
При этом BABOK уточняет, что нефункциональные требования относятся не только к непосредственно ПО, но и также связаны с процессами и людьми. В технике «Анализ нефункциональных требований» BABOK выделяет следующие их категории:
- доступность – степень работоспособности и доступности решения для использования, часто выражается в процентах времени;
- совместимость — степень успешности взаимодействия решения с другими окружающими компонентами (бизнес-процессами, информационными системами, аппаратным обеспечением и пр.);
- функциональность — степень соответствия функций решения потребностям пользователей, включая пригодность, точность, совместимость, т.е. корреляция с требованиями стейкхолдеров;
- ремонтопригодность — легкость изменения решения или его компонента, чтобы улучшить их, исправить ошибки или адаптировать к изменениям окружающей среды;
- эффективность работы — способность решения или его компонента выполнять свои целевые функции с минимальным потреблением ресурсов в контексте или временном периоде, например, в условиях пиковой нагрузки;
- надежность — способность решения или его компонента выполнять требуемые функции в определенных условиях в течение конкретного периода времени, например, наработка на отказ, измеряемая в часах и равная среднему времени работы устройства до сбоя;
- масштабируемость — способность решения расти или развиваться по мере роста объемов данных и количества пользователей;
- расширяемость – возможность добавления в решение новых функциональных возможностей. Это свойство тесно связано с архитектурой ПО, например, микросервисная архитектура проще поддается модификациям, чем «монолитная».
- переносимость — легкость переноса решения или его компонента из одной среды в другую, например, миграция на новую версию операционной системы или аппаратной платформы;
- безопасность – защита данных и компонентов решения от случайного или злонамеренного доступа, неправомерного использования, разрушения или раскрытия. Подробнее про процедуры аутентификации и авторизации в веб-приложениях читайте в моей новой статье. А про основы инфобеза для аналитиков я рассказываю здесь.
- удобство использования – легкость взаимодействия пользователя с решением, включая простоту ежедневной работы и обучения;
- сертификация — соответствие отдельным стандартам или отраслевым соглашениям;
- соответствие — нормативные, финансовые или правовые ограничения в зависимости от контекста и юрисдикции;
- локализация – адаптация текстовых и графических компонентов интерфейса, а также представления данных к языкам, законам, валютам и особенностям культуры пользователей в определенной местности или отрасли;
- соглашения об уровне обслуживания между поставщиком и пользователем решения. На практике это свойство тесно связано с доступностью, о чем мы поговорим далее.
Лучшее из BABOK®Guide: ТОП-10 задач и 20+ техник для аналитика
Код курса
EXBAB
Ближайшая дата курса
25 ноября, 2024
Продолжительность
24 ак.часов
Стоимость обучения
54 000 руб.
Рекомендации стандартов по разработке ТЗ и примеры измерения нефункциональных требований
Российские ГОСТ’ы по разработке технического задания (ТЗ), 34.602-89 и 19.201-78, которые мы разбирали здесь, также предлагают свой список нефункциональных требований, который частично пересекается с перечнем BABOK. Зарубежные стандарты по спецификации требований к ПО (SRS, Software Requirements Specification), ISO IEEE 29148-2018 и IEEE 830-1998, тоже приводят рекомендации по атрибутам качества ПО, которые можно использовать в качестве нефункциональных требований. Еще атрибуты качества ПО подробно разбираются в стандарте ISO/IEC 25010:2011 (ГОСТ Р ИСО/МЭК 25010-2015) «Требования и оценка качества систем и программного обеспечения. Модели качества систем и программных продуктов». Наконец, некоторые метрики оценки качества, которые относятся к ИТ-сервису, упомянуты в библиотеке ITIL. Разумеется, в каждом конкретном случае не все категории нефункциональных требований будут упомянуты в отдельно взятом ТЗ или SRS. Однако, поскольку нефункциональные требования являются именно требованиями, а не пожеланиями, они должны быть точно сформулированы и иметь четкие критерии проверки их достижимости, т.е. значения упомянутых характеристик.
Например, «система должна обладать высокой надежностью» и «система должна иметь дружественный пользовательский интерфейс» — это не качественно сформулированные нефункциональные требования, поскольку их выполнение невозможно проверить. Удобство – это весьма субъективное понятие, а надежность должна измеряться в часах безотказной работы или других численных единицах. При этом надежность тесно связана с доступностью — способностью системы функционировать в определенный момент или интервал времени.
Наиболее часто используемым показателем для измерения доступности является значение SLA (Service Level Agreement, соглашение об уровне предоставления услуг между поставщиком и потребителем). Этот показатель обычно измеряется в процентах и говорит о времени безотказной работы и простоя системы. Например, при SLA 99,99% максимальный период возможной недоступности системы в день соответствует 9 секундам, а время безотказной работы составляет 23 часа 59 минут и 51 секунду. Если брать годовой период измерения (365 дней или 8760 часов), то при этом уровне SLA система может быть недоступной 52 минуты и 36 секунд. Чем выше уровень SLA, тем дороже будет TCO (Total Cost Ownership, общая стоимость владения) системы. Для некоторых решений, связанных с жизненно важными сервисами, требуется действительно высокая доступность со SLA близким к 100%, например, уровень «5 девяток» — 99,999%. А для приложений внутреннего документооборота или других учетных систем в рамках одного предприятия такой SLA будет избыточным. Для расчета времени безотказной работы существует множество открытых сервисов, например, http://shootnick.ru/uptime/99. Чем доступность отличается от надежности, и как ее рассчитать, я рассказываю здесь.
Еще одной из частых ошибок начинающих системных и бизнес-аналитиков при разработке нефункциональных требований к ПО является субъективное описание удобства его использования в виде «дружественного интерфейса». Идея этого пожелания продиктована заботой о пользователе, однако реализовать и протестировать достижимость реализации весьма проблематично. Чтобы снизить степень неопределенности и облегчить процесс верификации требований, аналитик должен определить критерии их приемки. Например, требование к удобству пользовательского интерфейса может быть сформулировано как необходимость соответствия предписаниям ГОСТ Р 52872-2019 «Интернет-ресурсы и другая информация, представленная в электронно-цифровой форме. Приложения для стационарных и мобильных устройств, иные пользовательские интерфейсы. Требования доступности для людей с инвалидностью и других лиц с ограничениями жизнедеятельности». Для веб-приложений актуальны время первого отклика страницы и адаптация к мобильным устройствам, что можно выразить в численных значениях с помощью сервиса https://developers.google.com/speed/pagespeed/insights. Подробнее об этом сервисе и генерируемых им оценках я пишу здесь.
Разработка ТЗ на информационную систему по ГОСТ и SRS
Код курса
TTIS
Ближайшая дата курса
2 декабря, 2024
Продолжительность
16 ак.часов
Стоимость обучения
36 000 руб.
Удобство использования в контексте обучения можно выразить долей пользователей, которые освоят часть функциональных возможностей системы за конкретный период времени. Например, 95% пользователей должны быть способны использовать 80% функций системы не более чем через 8 часов обучения. Эффективность работы может выражаться в быстродействии или объеме обрабатываемых данных, например, система должна выполнять 90% запросов не более чем за 1 секунду в условиях средней загрузки (10 тысяч пользователей и объем трафика 1 Гб/сек).
Таким образом, разработка нефункциональных требований предполагает не только выявление характеристик проектируемой системы, но и определение критериев их измеримости и желаемых значений. Это коррелирует с концепцией определений (Definition of Done), которые бизнес-аналитик разрабатывает с учетом условий функционирования будущего решения, особенностей его поведения (т.е. функциональных требований), архитектурных ограничений, ограничений среды, а также рекомендаций экспертов предметной области и конечных пользователей продукта.
Основы архитектуры и интеграции информационных систем
Код курса
OAIS
Ближайшая дата курса
20 января, 2025
Продолжительность
16 ак.часов
Стоимость обучения
36 000 руб.
Подробнее про концепцию определений и их связь с критериями приемки и оценки читайте в нашей новой статье. А ошибки, которые совершают начинающие системные и бизнес-аналитики при разработке требований и ТЗ чаще всего, смотрите здесь.
Как научиться разрабатывать функциональные и нефункциональные требования к системе, специфицируя их в виде ТЗ и SRS, вы узнаете на курсах нашей Школы прикладного бизнес-анализа в лицензированном учебном центре обучения и повышения квалификации системных и бизнес-аналитиков в Москве:
- Основы архитектуры и интеграции информационных систем
- Разработка ТЗ на информационную систему по ГОСТ и SRS
