ГОСТ IEC 62304—2022
В.5.2 Анализ требований к ПО
Данная деятельность требует от ИЗГОТОВИТЕЛЯ установить и верифицировать требования к программно
му обеспечению для ПО МЕДИЦИНСКОГО ИЗДЕЛИЯ. Установление верифицируемых требований крайне важно
для определения того, что должно быть создано, для определения, что ПО МЕДИЦИНСКОГО ИЗДЕЛИЯ
функцио нирует должным образом, а также для демонстрации, что завершенное ПО МЕДИЦИНСКОГО ИЗДЕЛИЯ
готово к использованию. С цельюдемонстрации имплементации требований согласно замыслу, каждое требование
должно быть установлено таким образом, чтобы можно было установить объективные критерии для проверки
правильной имплементации. Если ПРОЦЕСС МЕНЕДЖМЕНТА РИСКА изделия предъявляет требования к ПО
для управле ния выявленными РИСКАМИ, эти требования должны быть идентифицированы в требованиях к
программному обеспечению таким образом, чтобы сделать возможным прослеживание мер по УПРАВЛЕНИЮ
РИСКОМ до тре бований к программному обеспечению. Все требования к программному обеспечению следует
определять таким образом, чтобы сделать возможной демонстрацию ПРОСЛЕЖИВАЕМОСТИ между требованием
и тестированием ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ СИСТЕМЫ. Если регулирующие требования некоторых стран
требуют соответ ствия специальным нормам или международным стандартам, данное требование должно быть
документировано в требованиях к программному обеспечению. Поскольку требования к программному
обеспечению устанавливают, что должно быть имплементировано в программное обеспечение, оценка
требований требуется до завершения ДЕЯТЕЛЬНОСТИ по анализу требований.
Областью частых недоразумений является различие между потребностями потребителя, входными данными
проектирования, требованиями к программному обеспечению, функциональными спецификациями программного
обеспечения и спецификациями проекта (дизайна) программного обеспечения. Входные данные проектирования
являются преобразованием потребностей потребителя в официально документированные требования к МЕДИ
ЦИНСКОМУ ИЗДЕЛИЮ. Требования к программному обеспечению — это официально документированные специ
фикации того, что программное обеспечение отвечает потребностям потребителя и входным данным проектиро
вания. Функциональные спецификации программного обеспечения часто включены в требования к программному
обеспечению и определяют в деталях, что программное обеспечение делает, чтобы соответствовать этим тре
бованиям, даже если много других альтернативных вариантов может так же соответствовать этим требованиям.
Спецификации проекта программного обеспечения определяют, как ПО будет проектироваться и раскладываться
на составные части, чтобы имплементировать эти требования и функциональные спецификации.
Традиционно требования к программному обеспечению, функциональные спецификации и спецификации
проекта оформляются как набор из одного и более документов. В настоящее время возможно оформление этой
информации как элементы данных внутри общей базы данных. Каждый элемент может иметь один или более
признаков, которые определяют его цель и его соединение с другими элементами в базе данных. Этот подход
допускает представление и печать различных видов информации, которая лучше всего подходит для каждой
группы предполагаемых пользователей (например, продавцов, ИЗГОТОВИТЕЛЕЙ, тестировщиков, аудиторов) и
поддерживает ПРОСЛЕЖИВАЕМОСТЬ, чтобы демонстрировать соответствие имплементации и степени, до ко
торой тестовые задания проверяют требования. Инструменты, поддерживающие этот подход, могут быть такими
же простыми, как гипертекстовый документ, использующий гиперссылки HTML, или столь же сложными, как CASE
(computer aided software engineering — разработка компьютерного программного обеспечения) и инструменты
анализа требований.
ПРОЦЕСС определения требований к СИСТЕМЕ лежит вне области применения настоящего стандарта. Од
нако решение об имплементации функционала МЕДИЦИНСКИХ ИЗДЕЛИЙ с программным обеспечением обычно
осуществляется по время проектирования СИСТЕМЫ. Некоторые или все требования к СИСТЕМЕ выделяются
с целью имплементации в программное обеспечение. ДЕЯТЕЛЬНОСТЬ по анализу требований к программному
обеспечению заключается в анализе требований предъявляемых к программному обеспечению ПРОЦЕССОМ
определения требований к СИСТЕМЕ, и в получении полного набора требований к программному обеспечению,
отражающих выделенные требования.
Чтобы обеспечить целостность СИСТЕМЫ, ИЗГОТОВИТЕЛЬ должен предусмотреть механизм согласования
внесения изменений и уточнения СИСТЕМНЫХ требований для исправления непрактичности, несоответствий или
двусмысленностей либо в исходных СИСТЕМНЫХ требованиях, либо в требованиях к программному обеспече
нию.
ПРОЦЕСС сбора и анализа СИСТЕМНЫХ и программных требований может быть итеративным.
Настоящий стандарт не предполагает жесткого разделения ПРОЦЕССОВ на два уровня. На практике АРХИ
ТЕКТУРА СИСТЕМЫ и АРХИТЕКТУРА программного обеспечения часто описываются одновременно, а требова
ния к СИСТЕМЕ и программному обеспечению впоследствии документируются в многоуровневой форме.
В.5.3 АРХИТЕКТУРА программного обеспечения
Эта деятельность требует, чтобы ИЗГОТОВИТЕЛЬ определил главные структурные компоненты программ
ного обеспечения и определил их основную зону ответственности, а также их внешне видимые свойства и взаи
мосвязь между ними. Если функционирование компонента может влиять на другие компоненты, то оно должно
быть описано в АРХИТЕКТУРЕ программного обеспечения. Это описание особенно важно для аспектов функци
онирования, которые могут повлиять на компоненты МЕДИЦИНСКОГО ИЗДЕЛИЯ, находящиеся вне программ
ного обеспечения (см. 5.3.5 и ВАЗ). АРХИТЕКТУРНЫЕ решения чрезвычайно важны для осуществления мер по
34