Введение

Цель статьи — провести классификацию и иерархическое деление требований на группы с конкретными примерами из лабораторной практики. Разделение требований на группы и подгруппы необходимо для правильного построения проектного решения, основанного на анализе требований, а не на "представлениях о хорошем". Особенно это актуально для систем, подчиняющихся строгим стандартам, таким как ГОСТ ISO/IEC 17025-2019, который устанавливает общие требования к компетентности, беспристрастности и стабильной работе лабораторий.

Я провожу обучения и консультации для лабораторий, которые хотят автоматизировать часть своей деятельности и внедрить ЛИМС или адаптировать имеющиеся системы под задачи лаборатории. Естественно, что в самом начале я делаю акцент на необходимости правильной постановки цели автоматизации и разработке технического задания. В это время всегда появляется необходимость разделения требований на группы с определенной иерархией. Проанализировав разные подходы и классификации, я пришел к тому, что проще начать с дихотомического деления на функциональные и нефункциональные требования.

Функциональные требования

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

Примеры из лабораторной практики:

-"Система должна позволять регистрировать образцы с автоматической генерацией уникальных идентификаторов и штрих-кодов"
-"Лаборант может назначить методику испытаний для конкретного образца и отслеживать статус выполнения"
-"Система должна автоматически рассчитывать неопределенность измерений при градуировке оборудования"
Функциональные требования отвечают на вопросы:
-"Что делает система?"
-"Зачем система это делает?"

Нефункциональные требования

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

Примеры из лабораторной практики:
-"Система должна обеспечивать целостность данных в соответствии с принципами ALCOA+ (Attributable, Legible, Contemporaneous, Original, Accurate)"
-"Время отклика системы при поиске результатов испытаний не должно превышать 3 секунды при нагрузке до 100 одновременных пользователей"
-"Все данные о калибровке оборудования должны соответствовать требованиям ГОСТ ISO/IEC 17025-2019 и храниться не менее 5 лет"
Нефункциональные требования отвечают на вопросы:
-"Как хорошо работает система?"
-"В каких условиях она должна функционировать?"

Иерархия функциональных требований

Бизнес-требования (Business Requirements)

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

Примеры из лабораторной практики:

"Внедрение ЛИМС должно сократить время обработки образцов на 30% и обеспечить соответствие требованиям аккредитации по ГОСТ ISO/IEC 17025-2019"
"Автоматизация процесса калибровки оборудования необходима для снижения количества ошибок и исключения человеческого фактора при расчетах неопределенности измерений"
Отвечают на вопрос: "Зачем мы создаём эту систему?"

Бизнес-правила (Business Rules)

Это правила, регулирующие логику работы бизнеса и накладывающие ограничения на поведение системы. Часто связаны с юридическими, финансовыми или организационными нормами.

Примеры из лабораторной практики:
-"Все изменения в результатах испытаний должны логироваться с указанием пользователя, времени и причины изменения в соответствии с требованиями п. 7.5.2. ГОСТ ISO/IEC 17025-2019"
-"Система должна учитывать наличие поверки средств измерений в соответствии с 102-ФЗ"
-"Система должна формировать протокол испытаний в соответствии с требованиями ГОСТ Р 58973-2020"
Отвечают на вопрос: "Какие нормативно-правовые требования должна выполнять система?"

Пользовательские требования (User Requirements)

Описывают, что система должна делать с точки зрения конечного пользователя. Часто формулируются в виде Use Cases или User Stories.

Примеры из лабораторной практики:
-"Я как лаборант хочу видеть на главной странице список моих невыполненных анализов с приоритетами, сроками и статусами готовности оборудования"
-"Я как руководитель лаборатории хочу получать ежедневный отчет по количеству обработанных образцов, времени выполнения анализов и проценту брака"
-"Я как метролог хочу настроить напоминания о предстоящей поверке оборудования с автоматической генерацией приказов и рассылкой уведомлений ответственным лицам"
Отвечают на вопросы: "Что нужно пользователю от системы?" "Как он хочет в ней работать?"

Иерархия нефункциональных требований

Ограничения (Constraints)

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

Примеры из лабораторной практики:
-Временные: "Этап внедрения базовой версии ЛИМС должен быть завершен в течение 6 месяцев с момента старта проекта, чтобы успеть к очередной аккредитации"
-Архитектурные: "Система должна функционировать исключительно в локальной сети лаборатории без доступа к интернету из соображений информационной безопасности"
-Бюджетные: "Стоимость внедрения системы не должна превышать утвержденный бюджет с учетом стоимости лицензий, обучения и технической поддержки"
-Лицензионные: "Все программное обеспечение, используемое в составе ЛИМС, должно иметь лицензии, разрешающие использование в государственных учреждениях"
-Эксплуатационные: "Система должна поддерживать работу на существующем серверном оборудовании лаборатории (покупка нового оборудования не предусмотрена бюджетом)"
-Безопасность: "Все персональные данные клиентов и конфиденциальная информация об испытаниях должны шифроваться в соответствии с требованиями законодательства"

Отвечают на вопрос: "Какие условия НЕЛЬЗЯ нарушать при разработке и эксплуатации системы?"

Внешние интерфейсы (External Interfaces / Интеграции)

Требования к взаимодействию системы с внешними компонентами: другими системами, API, устройствами, пользователями. Для современных ЛИМС интеграция с оборудованием является критически важной функцией.

Примеры из практики ЛИМС:
-Интеграция с оборудованием: "Система должна автоматически принимать результаты измерений с аналитических весов, pH-метров и спектрофотометров через стандартные протоколы"
-Интеграция с CRM: "Необходима интеграция с системой управления отношениями с клиентами для автоматической передачи заказов и результатов испытаний"
-Форматы данных: "Система должна поддерживать импорт/экспорт данных в форматах CSV, XML, JSON для обмена с внешними системами и аккредитационными органами"
-Совместимость: "ЛИМС должна быть совместима с мобильными устройствами для работы в полевых условиях и на производственных площадках"
Отвечают на вопрос: "С чем и как должна взаимодействовать система?"

Атрибуты качества (Quality Attributes)

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

Примеры из практики ЛИМС:
-Производительность: "Система должна обрабатывать одновременную загрузку данных с 5 аналитических приборов без потери производительности"
-Надёжность: "Система должна обеспечивать 99.95% доступности для критически важных операций по обработке образцов"
-Масштабируемость: "Система должна поддерживать расширение до 10 дополнительных рабочих мест и интеграцию с новыми типами лабораторного оборудования"
-Удобство использования: "Обучение новому пользователю должно занимать не более 2 часов благодаря интуитивному интерфейсу и встроенным подсказкам"
Отвечают на вопрос: "Насколько хорошо работает система?"

Системные требования (System Requirements / Внутренние интеграции)

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

Примеры из практики ЛИМС:
-Серверная инфраструктура: "Серверная часть должна развертываться на серверах Linux"
-База данных: "Для хранения результатов испытаний должна использоваться PostgreSQL 16.6."
-Архитектура: "Система должна быть построена по модульному принципу с возможностью отключения ненужных функциональных блоков для небольших лабораторий"
-Резервное копирование: "Ежедневное резервное копирование данных с возможностью восстановления на любой момент времени за последние 30 дней"
Отвечают на вопрос: "На какой платформе и как должна быть реализована система?"

Иерархия нефункциональных требований при разработке и внедрении ПО сложна, поскольку зависит от бизнес-требований, бизнес-правил и других ограничений. В лабораторной среде ГОСТ ISO/IEC 17025-2019 выходит на первый план при определении приоритетов, часто ставя ограничения выше атрибутов качества и системных требований. Во многом подходы к интеграциям, выбору системной архитектуры и так далее зависят от функциональных требований и имеющихся ограничений, в том числе по бюджету. В то же время атрибуты качества во многом сходны у всех информационных систем, а для реализации системные требований существует огромное количество инструментов, выбор которых определяется в первую очередь бюджетом проекта. Поэтому очень важно сначала определиться с ограничениями, потом с интеграциями и далее уже переходить к атрибутам качества и системным требованиям.

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

Классификация требований к ПО в виде иерархии