...

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

функциональные требования ТЗ SRS примеры, нефункциональные требования ТЗ SRS примеры, как измерить нефункциональные требования. критерии приемки требований, обучение бизнес-анализу, курсы бизнес-аналитик, бизнес-аналитик обучение курс, разработка ТЗ курсы обучение, что такое НФТ ФТ ТЗ SRS, как написать ТЗ курс обучение, спецификация требований в ТЗ и SRS пример курсы, курсы BABOK, обучение BABOK®Guide, BABOK на русском, авторизованные курсы IIBA россия, Школа прикладного бизнес-анализа

Продолжая обучение начинающих системных и бизнес-аналитиков основам разработки ТЗ, сегодня рассмотрим, что такое нефункциональные требования к ПО и как их составить. Также разберем, чем доступность отличается от надежности, как измерить качество пользовательского интерфейса и других характеристик проектируемой системы с комментариями 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
Ближайшая дата курса
5 ноября, 2024
Продолжительность
16 ак.часов
Стоимость обучения
36 000 руб.

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

Как научиться разрабатывать функциональные и нефункциональные требования к системе, специфицируя их в виде ТЗ и SRS, вы узнаете на курсах нашей Школы прикладного бизнес-анализа в лицензированном учебном центре обучения и повышения квалификации системных и бизнес-аналитиков в Москве:

Я даю свое согласие на обработку персональных данных и соглашаюсь с политикой конфиденциальности.

Добавить комментарий