Эпизод 8.
Нефункциональные требования: пример для медицинской системы
В этом эпизоде подкаста GetAnalyst мы обсуждаем нефункциональные требования: не только в теории, но и на практике. Разбираются конкретные примеры, которые могут быть применены в реальных ИТ-проектах.
Этот выпуск поможет системным и бизнес-аналитикам при подготовке к собеседованиям или перед стартом работы над нефункциональными требованиями для ТЗ нового проекта.
1:08 - Когда мы встречаемся с нефункциональными требованиями и что важно знать о них перед началом работы. Знакомство с проектом TelMed (https://t.me/getanalysts/1646).
08:09 - Что такое нефункциональные требования (НФТ). О проверяемости нефункциональных требований.
12:28 - Определение нефункциональных требований по Вигерсу (книга “Разработка требований к программному обеспечению”), ГОСТ-34 (https://www.prj-exp.ru/gost/gost_34-602-89.php) и Software Requirements Specification, IEEE (https://github.com/rick4470/IEEE-SRS-Tempate или https://ieeexplore.ieee.org/document/278253).
23:21 - Источники нефункциональных требований.
29:54 - Виды нефункциональных требований на примере медицинского проекта TelMed. Этап сбора потребностей из источников - первичная аналитика.
45:04 - Работа с нефункциональными требованиями для ТЗ и рядовых постановок задач на разработчиков. Личный опыт. Связь с принципами дизайна UI и архитектурой.
51:06 - Доступность. SLA - service-level agreement.
56:10 - Удобство установки.
01:01:36 - Целостность данных. Совместимость.
01:04:23 - Производительность.
01:06:24 - Надежность. Устойчивость.
01:09:13 - Защита и безопасность.
1:13:00 - Удобство использования. О боли про “Интуитивно понятный интерфейс”.
1:16:10 - Эффективность использования ресурсов.
1:18:10 - Модификация. Переносимость. Возможность повторного использования.
1:21:41 - Масштабируемость.
1:24:03 - Проверяемость и тестируемость. Другие требования по ГОСТ-34.
1:27:28 - Порядок работы с нефункциональными требованиями.
1:34:54 - Заключение и рекомендации по нефункциональным требованиям и организации работы с ними на проекте.
Ведущая:
Екатерина Ананьева
Подкаст сообщества системных аналитиков GetAnalyst.
Заметки к эпизоду
Что такое нефункциональные требования?
Требования к ПО можно разделить на три основные категории:
1. Бизнес-требования определяют цели и задачи, которые система должна поддерживать для достижения успеха бизнеса. Они описывают, зачем создается система, какие бизнес-проблемы она должна решать, и какие преимущества или улучшения она должна принести организации. Эти требования ориентированы на бизнес-результаты и могут включать увеличение прибыли, улучшение обслуживания клиентов и другие.
2. Функциональные требования определяют конкретные функции и возможности, которые система должна предоставить пользователям для выполнения задач и достижения целей, описанных в бизнес-требованиях. Эти требования могут включать взаимодействие с пользователем, обработку данных, выполнение бизнес-логики и интеграцию с другими системами.
3. Нефункциональные требования (НФТ) определяют критерии, которым система должна соответствовать, чтобы быть полезной и эффективной, но они не связаны с конкретными функциями системы. Эти требования описывают качества и характеристики системы, такие как производительность, безопасность, масштабируемость, надежность, удобство использования и поддерживаемость. Они ориентированы на общее качество системы и могут включать требования к времени отклика, защите данных, способности системы справляться с увеличением нагрузки и другие аспекты, которые обеспечивают стабильную и эффективную работу системы в различных условиях. Нефункциональные требования - это про то, как хорошо работает система.
При разработке нефункциональных требований обязательно проверяйте, чтобы их можно было протестировать:
- в ручном или автоматическом режиме при тестировании функцональности,
- в рамках нагрузочного тестирования системы.
Если требование невозможно проверить, то стоит подумать над необходимостью упоминать его в техническом задании.
Нефункциональные требования в технических заданиях на разработку программного обеспечения
Основные источники, определяющие нефункциональные требования:
1. Книга Карла Вигерса
"Разработка требований к программному обеспечению"
В книге приводится как теория, так и практические примеры по НФТ.
2. Стандарт для разработки ТЗ - ГОСТ 34 серии
3. Международный стандарт для разработки требований от IEEE
Recommended Practice for Software Requirements Specification (template)
Перевод:
Другие нефункциональные требования
5.1 Требования к производительности
5.2 Требования защите
Укажите те требования, которые касаются возможных потерь, повреждений или вреда, которые могут возникнуть в результате использования продукта.
5.3 Требования безопасности (доступ к данным)
Укажите любые требования, касающиеся вопросов безопасности или конфиденциальности, связанных с использованием продукта или защитой данных, используемых или созданных продуктом
5.4 Атрибуты качества программного обеспечения
Укажите любые дополнительные качественные характеристики продукта, которые будут важны как для заказчиков, так и для разработчиков. Некоторые из них, которые следует учитывать: адаптивность, доступность, гибкость, совместимость, ремонтопригодность, переносимость, надежность, возможность повторного использования, тестируемость и удобство использования.
5.5 Бизнес-правила
Виды нефункциональных требований - чеклист с примерами
Этот раздел посвящен изучению видов нефункциональных требований, собранный на основе трех фундаментальных источников - Вигерс, ГОСТ-34, IEEE. Его можно использовать в качестве чеклиста для ваших проектов и отдельных задач, где важно детально проработать функциональные требования и архитектуру взаимодействия систем.
Чеклист поможет не пропустить важные технические детали в требованиях, которые не лежат на поверхности.
Доступность
Это характеристика системы, определяющая её способность быть доступной и готовой к использованию в любой момент времени. Это означает, что система должна работать надежно и быть доступной для пользователей в запланированные часы работы или даже круглосуточно.
Другими словами: насколько сервисы системы доступны, какой период времени, и где они используются.
Вигерс ✅
ГОСТ-34 ❌
SRS IEEE ✅ (5.4 Атрибуты качества программного обеспечения)
Примеры:
- Система TelMed должна быть доступна для пользователей круглосуточно, 7 дней в неделю. Время простоя не должно превышать 0.1% времени в год.
- Система должна иметь встроенные инструменты мониторинга, которые будут отслеживать доступность всех компонентов системы в реальном времени.
- Время восстановления после сбоя не должно превышать 15 минут.
Удобство установки
Это характеристика, определяющая, насколько легко и правильно можно установить программное обеспечение.
Включает:
- начальную установку,
- минимальные требования к системе: приложения должны иметь четко задокументированные минимальные системные требования, чтобы пользователи могли легко проверить совместимость.
- восстановление после неполной, некорректной или прерванной пользователем установки,
- переустановку,
- обновление,
- возврат к предыдущей версии,
- установка дополнительных компонентов и обновлений,
- удаление.
Вигерс ✅
ГОСТ-34 ❌
SRS IEEE ❌
Примеры:
- Процесс установки приложения на мобильных устройствах не должен занимать более 5 минут, включая загрузку, установку и начальную настройку.
- В процессе установки должны быть предусмотрены пошаговые инструкции и подсказки, чтобы пользователи могли легко следовать им.
Целостность
Предотвращение потери и искажения информации в системе.
Включает:
- Обработку ошибок при вводе данных: проверка правильности данных на клиенте и сервере.
- Синхронизацию данных между серверами в распределенной архитектуре систем.
- Логирование изменений и инцидентов: фиксация всех изменений с указанием времени, пользователя и описания, хранение логов не менее года.
- Регулярное резервное копирование: ежедневное создание и хранение резервных копий для восстановления данных.
- Валидация данных из внешних источников: проверка данных перед их сохранением в системе.
Вигерс ✅
ГОСТ-34 ✅ (2.6.1.10. Требования по сохранности информации при авариях)
SRS IEEE ✅ (5.4 Атрибуты качества программного обеспечения)
Примеры:
- Все данные, вводимые пациентами и врачами, должны проходить валидацию как на уровне клиентских приложений, так и на сервере. Это предотвращает ввод некорректных данных и гарантирует точность и полноту информации.
- Все данные системы должны резервироваться не реже одного раза в сутки. Резервные копии должны храниться в защищённом месте и быть доступны для восстановления в случае сбоя системы. Это обеспечивает сохранность данных и возможность восстановления в случае потери или повреждения данных.
- Обеспечить синхронизацию данных в БД системы
Разбирая конкретную ситуацию, это значит:
1. При регистрации пациента данные о нем должны повляться одновлеменно в БД ЛК Пациентов и в БД Медидинских карт. Общая часть в обеих БД- ФИО пациента.
2. При обновлении ФИО пациента должна быть синхронно обновлена в обеих БД.
Совместимость (Интеграции)
Способность системы обмениваться данными с другими программными системами и интегрироваться с внешними аппаратными устройствами.
Вигерс ✅
ГОСТ-34 ✅ (2.6.1.1.3. Требования к характеристикам взаимосвязей создаваемой системы сосмежными системами, требования к ее совместимости, в том числе указанияо способах обмена информацией)
SRS IEEE ✅ (5.4 Атрибуты качества программного обеспечения)
Примеры:
- Система должна поддерживать интеграцию с лабораторной системамой через GraphQL API. Все данные, получаемые из лабораторий (например, результаты анализов), должны автоматически валидироваться сохраняться в медицинской истории пациента.
- Система должна поддерживать интеграцию с тонометром для мониторинга показателей давления пациента в реальном времени. Данные с этого устройства должны автоматически передаваться в систему и отображаться в интерфейсе врача во время консультации. Интеграция должна быть реализована через передаваемый производителем определенного вида оборудования SDK.
Производительность
Это характеристика системы, определяющая её способность быстро и эффективно выполнять задачи и обрабатывать запросы.
Включает:
- Время отклика: как быстро система реагирует на запросы пользователя.
- Пропускная способность: количество операций или запросов, которые система может обработать за определённый промежуток времени.
- Использование ресурсов: эффективное использование вычислительных ресурсов, таких как процессор, память, дисковое пространство и сеть.
- Время выполнения задач: насколько быстро система завершает различные процессы и операции.
Эти аспекты помогают оценить, насколько система справляется с текущими и будущими требованиями к производительности, обеспечивая стабильную и быструю работу.
Вигерс ✅
ГОСТ-34 ❌
SRS IEEE ✅ (5.1 Требования к производительности)
Примеры:
- Время установления соединения для видеоконсультации не должно превышать 5 секунд, а задержка видео и аудио не должна превышать 200 мс.
- Система должна поддерживать одновременную работу не менее 10,000 активных пользователей без деградации производительности.
Надежность
Это характеристика системы, определяющая её способность функционировать без сбоев и ошибок в течение заданного времени. Надежность включает следующие аспекты:
- Безотказность: вероятность того, что система будет работать без сбоев в течение определённого периода.
- Восстанавливаемость: способность системы восстанавливаться после сбоев и возвращаться в рабочее состояние.
- Предотвращение ошибок: меры и механизмы для предотвращения возникновения ошибок в работе системы.
- Устойчивость к отказам (отказоустойчивость): способность системы продолжать работу при возникновении частичных сбоев или отказов отдельных компонентов.
- Длительность безотказной работы: время, в течение которого система работает без сбоев.
Эти аспекты помогают обеспечить стабильную и надежную работу системы, минимизируя риск сбоев и обеспечивая быстрое восстановление в случае возникновения проблем.
Вигерс ✅
ГОСТ-34 ✅ (2.6.1.4. Требования к надежности)
SRS IEEE ✅ (5.4 Атрибуты качества программного обеспечения)
Примеры:
- Время восстановления после сбоя не должно превышать 30 минут для основных компонентов системы.
- Система должна обеспечивать среднее время между отказами не менее 30 дней для критических компонентов.
Устойчивость
Это способность системы продолжать корректно выполнять свои функции, несмотря на неверный ввод данных, недостатки подключенных компонентов или неожиданные условия работы. Устойчивое ПО легко восстанавливается после проблем и игнорирует ошибки пользователей.
Обычно устойчивость включают в функциональные требования: в альтернативных сценариях и требованиях к обработке ошибок, и отдельно не описывают.
Вигерс ✅
ГОСТ-34 ❌
SRS IEEE ❌
Защита (safety)
Требования к защите (safety) подразумевают, что система должна стремиться предотвратить причинение вреда людям и имуществу.
Это включает:
- Идентификация опасных условий: система должна выявлять условия, при которых её использование может нанести вред человеку или имуществу.
- Предупреждение и реагирование: система должна предупреждать пользователей о потенциальных рисках и принимать меры для их предотвращения.
Основные вопросы для анализа требований к защите:
Опасные условия:
- При каких условиях использование этого продукта может нанести вред человеку?
- Как система может обнаружить эти условия?
- Как нужно реагировать на них?
Частота отказов:
- Какая максимально разрешенная частота отказов, способная вызывать повреждения?
Виды отказов:
- Какие виды отказов могут приносить вред людям или имуществу?
Действия оператора:
- Какие действия оператора могут непреднамеренно нанести вред людям или имуществу?
Режимы работы:
- Есть ли какие-то режимы работы, которые могут представлять риск для людей или имущества?
Эти аспекты помогают обеспечить безопасность системы, минимизируя риск причинения вреда людям и имуществу, и позволяют разработать соответствующие механизмы для предотвращения и реагирования на опасные ситуации.
Вигерс ✅
ГОСТ-34 ✅ (2.6.1.5. Требования безопасности, 2.6.1.11. Требования к защите от влияния внешних воздействий)
SRS IEEE ✅ (5.2 Требования к защите)
Пример (не про медицинскую систему TelMed):
У пользователя должна быть возможность увидеть список всех потенциально опасных операций системы, например, операций с высоким напряжением в электрических системах, с указанием конкретных шагов, которые необходимо предпринять для обеспечения безопасности.
Безопасность (security)
Это характеристика системы, определяющая её способность защищать данные и ресурсы от несанкционированного доступа, использования, раскрытия, изменения или уничтожения.
Безопасность включает следующие аспекты:
- Аутентификация: проверка подлинности пользователей, чтобы убедиться, что они являются теми, за кого себя выдают.
- Авторизация: контроль доступа, определяющий, какие действия пользователи могут выполнять в системе.
- Шифрование: защита данных путем преобразования их в форму, недоступную для неавторизованных лиц.
- Конфиденциальность: защита данных от несанкционированного доступа и раскрытия.
- Аудит и мониторинг: ведение журнала действий пользователей и событий в системе для выявления и предотвращения инцидентов безопасности.
- Управление уязвимостями: обнаружение, оценка и устранение уязвимостей в системе.
Вигерс ✅
ГОСТ-34 ✅ (2.6.1.9. Требования к защите информации от несанкционированного доступа*)
SRS IEEE ✅ (5.3 Требования безопасности)
*P.S. Защита и безопасность по ГОСТ-34 точно не перепутаны.
Примеры:
- Все пользователи (пациенты, врачи, менеджеры, администраторы) должны проходить многофакторную аутентификацию при входе в систему. Доступ к различной функциональности системы должен регулироваться с помощью ролей и прав доступа.
Удобство использования
Это характеристика системы, определяющая её способность быть понятной, легкой и эффективной в использовании для пользователей.
Вигерс ✅
ГОСТ-34 ✅ (2.6.1.6. Требования к эргономике и технической эстетике)
SRS IEEE ✅ (3.1 User Interfaces)
Прекрасные примеры из книги Вигерса:
Плохой пример:
- Система должна быть удобной и интуитивно-понятной для пользователей.
(Это как? За счет чего? Как это проверять?)
Эффективность
Это показатель того, насколько хорошо система использует производительность процессора, место на диске, память или полосу пропускания соединения. Если система тратит слишком много доступных ресурсов, пользователи заметят снижение производительности.
Эффективность включает следующие аспекты:
- Загрузка процессора: процентное использование процессорного времени системой.
- Использование памяти: объем оперативной памяти, используемый приложением.
- Место на диске: объем дискового пространства, занятого приложением.
- Полоса пропускания: объем данных, передаваемых и принимаемых системой через сеть.
- Время выполнения операций: время, затрачиваемое на выполнение различных операций и задач.
Вигерс ✅
ГОСТ-34 ❌
SRS IEEE ❌
Примеры требований к эффективности:
- Загрузка процессора не должна превышать 70% при нормальных условиях эксплуатации.
- Использование оперативной памяти не должно превышать 500 МБ.
- Приложение должно занимать не более 1 ГБ дискового пространства.
- Система должна передавать и получать не более 10 МБ данных в минуту при стандартной нагрузке.
- Время выполнения основных операций не должно превышать 2 секунд.
Возможность модификации
Это характеристика системы, показывающая, насколько просто разбираться в дизайне и коде программного обеспечения, изменять его и расширять.
Это означает, что система должна быть спроектирована таким образом, чтобы изменения могли вноситься легко и без существенных затрат времени и ресурсов любым программистом или другим профильным ИТ-специалистом.
Высокий уровень этого показателя достигается за счет:
- Читаемости и структурированности кода.
- Наличия документации к ПО.
- Выстроенных процессов в команде.
- Внедрения инструментов-помощников (Confluence, Jira, Gitlab и другие).
В условиях современной разработки это ожидается по умолчанию. В ТЗ и в требования обычно не вносят.
Вигерс ✅
ГОСТ-34 ❌
SRS IEEE ❌
Переносимость
Определяет усилия, необходимые для перемещения программного обеспечения из одной операционной системы в другую. Это означает, что программное обеспечение должно быть спроектировано так, чтобы его можно было легко адаптировать для работы в различных операционных системах и средах.
В условиях современной разработки на страте определяют какие ОС должны быть поддержаны. Если нужно, чтобы система была переносима, то подбирают специальные языки программирования для десктоп- и мобильных приложений, которые позволяют писать программный код один раз, и из него собирать одну и ту же программу под iOS + Android / Windows + Linux +MacOS.
Вигерс ✅
ГОСТ-34 ❌
SRS IEEE ✅ (5.4 Атрибуты качества программного обеспечения)
Возможность повторного использования
Это показатель того, насколько легко можно использовать программные компоненты в других приложениях. Такое ПО должно быть:
- Модульным: разделено на независимые части.
- Качественно задокументированным: с описанием функциональности и интерфейсов.
- Независимым от конкретных приложений и операционных систем.
- Универсальным: с возможностями конфигурации и адаптации.
Вигерс ✅
ГОСТ-34 ❌
SRS IEEE ✅ (5.4 Атрибуты качества программного обеспечения)
Примеры:
- Модуль авторизации: используется для входа пользователей в разные приложения.
- Модуль платежей: обрабатывает платежи и может быть интегрирован в различные коммерческие системы.
Масштабируемость
Это характеристика системы, показывающая её способность справляться с увеличением нагрузки. Это означает, что система должна эффективно работать при росте числа пользователей, объема данных, сложности операций и количества функций в ней.
Вигерс ✅
ГОСТ-34 ❌
SRS IEEE ❌
Примеры:
- Система должна быть способна обрабатывать увеличение объема данных с 1 ТБ до 10 ТБ, сохраняя время отклика до 2 сек на запрос.
- Система должна поддерживать горизонтальное масштабирование, позволяя добавлять новые серверы для обработки увеличивающейся нагрузки.
Проверяемость и тестируемость
Это характеристики системы, показывающие, насколько легко можно проверить её корректность и протестировать различные аспекты её работы.
Раздел может включать требования к разработке тест-кейов, покрытию ПО автотестами или требования к проведению ручного тестирования.
Вигерс ✅
ГОСТ-34 ✅ (6. Порядок контроля и приемки системы)
SRS IEEE ✅ (5.4 Атрибуты качества программного обеспечения)
Ремонтопригодность
Это способность системы или её компонентов быть легко обслуживаемыми, исправляемыми и адаптируемыми к новым требованиям.
Она включает в себя набор требований к эксплуатации, техническому обслуживанию, ремонту и хранению, которые обеспечивают долговременную и эффективную работу системы:
Условия и регламент эксплуатации:
- Обеспечение использования технических средств (ТС) системы с заданными техническими показателями.
- Виды и периодичность обслуживания ТС системы.
- Допустимость работы без обслуживания.
Предварительные требования:
- Допустимые площади для размещения персонала и ТС системы.
- Параметры сетей энергоснабжения и другие необходимые условия.
Требования к обслуживающему персоналу:
- Количество и квалификация обслуживающего персонала.
- Режимы работы персонала.
Требования к запасным изделиям и приборам:
- Состав, размещение и условия хранения комплекта запасных изделий и приборов.
Требования к регламенту обслуживания:
- Детализированные процедуры и графики обслуживания системы.
Эти аспекты обеспечивают, что система будет легко и эффективно поддерживаться, что минимизирует простои и затраты на обслуживание и ремонт, а также гарантирует длительный срок службы и стабильную работу системы.
Вигерс ❌
ГОСТ-34 ✅ (2.6.1.8. Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы)
SRS IEEE ✅ (5.4 Атрибуты качества программного обеспечения)
Условия эксплуатации
Это совокупность факторов и требований, определяющих, как должна использоваться система для обеспечения её надежной и эффективной работы.
Включают:
Режим эксплуатации:
- Виды и периодичность технического обслуживания.
- Допустимость и условия работы без обслуживания.
- Нормы и ограничения по времени непрерывной работы системы.
Окружающая среда:
- Температурные диапазоны, в которых система может работать.
- Допустимые уровни влажности, пыли и других факторов окружающей среды.
- Требования к защите от воздействия внешних факторов (например, вибрации, электромагнитных помех).
Энергоснабжение:
- Требования к параметрам сетей энергоснабжения (напряжение, частота, допустимые колебания).
- Наличие резервных источников питания и их параметры.
Местоположение и размещение:
- Площади и условия для размещения системы и обслуживающего персонала.
- Требования к вентиляции, освещению и другим условиям в помещениях.
Вигерс ❌
ГОСТ-34 ✅ (2.6.1.14.3 Требования к системе, связанные с особыми условиями эксплуатации)
SRS IEEE ❌
Пример (не для медицинской системы TelMed):
- При разработке программного интерфейса учитывать, что приложение будет использоваться "на ходу" - пользователь может бежать или идти (т.е. в пользовательском интерфейсе должно быть как можно меньше текста, он должен быть крупный, и должны быть большие кнопки).
Требования к транспортабельности для подвижных АС
Требования, обеспечивающие транспортабельность технических средств системы, а также требования к транспортным средствам.
Вигерс ❌
ГОСТ-34 ✅ (2.6.1.7)
SRS IEEE ❌
Требования по стандартизации и унификации
Включают:
- Использование стандартных методов и инструментов для выполнения функций системы.
- Применение типовых программ и математических моделей.
- Внедрение стандартных проектных решений и форм документов.
- Соблюдение установленных стандартов и классификаторов.
Вигерс ❌
ГОСТ-34 ✅ (2.6.1.13)
SRS IEEE ❌
Примеры:
- Шаблоны постановок задач для разработчиков.
- Использование международного справочника стран при заполнении персональных данных пациентов.
Есть предложения или вопросы по чек-листу?
Мы всегда готовы улучшать и совершенствовать нашу базу знаний!
Пишите ваши пожелания и предложения на info@getanalyst.ru или в Telegram-чат GetAnalyst.
Контакты
+7 (499) 686-15-46
Лицензия №Л035-01255-50/01366872 от 28.08.2024
*Instagram — запрещенная на территории РФ организация
Практический опыт здесь, 2021-2024
Мы используем файлы cookie, для персонализации сервисов и повышения удобства пользования сайтом. Если вы не согласны на их использование, поменяйте настройки браузера.