ГОСТ Р 54360—2011
ществлены повторная валидация и требуемое документирование. В некоторых отраслях промышлен
ности ремонт должен следовать установленным организацией процедурам контроля изменения.
11.4.11 Использование ЛИМС
В данном пункте подчеркиваются уровни ответственности. Можно ссылаться на руководство(а)
(инструкции), если они существуют, но руководства или справочники пользователя не должны быть
прописаны в СОП. Следует учитывать, что те. кто использует эти СОП. должны быть обучены и знают,
как использовать ЛИМС. Необязательно переписыватьСОП. если проявляются системные изменения,
например, если вместо "log the samples by batch" появляется "log — <retum> <return> <down-arrow>
highlight "by batch" and <return>".
11.4.12 Обработка ошибок
В данном пункте проводится рассмотрение того, какобрабатываются ошибки вЛИМС. Могут быть
разработаны отдельные СОП. или СОП могут быть включены в «Эксплуатационные СОП» ЛИМС.
В любом случае ошибки ЛИМС должны быть документированы. СОП должны описать направление
действий, которые должны быть предприняты пользователями ЛИМС. когда они сталкиваются с некоей
проблемой.
11.4.13 Построение шаблонов статических данных
Данный пункт включает спецификации, которые используются в построении различных статичес
кихтаблиц. Например. СОП могутустановить, что все методы испытания будут кодироваться в ЛИМС с
использованием определенной системы нумерации метода или что во всех шаблонах результатов
испытания будут прослеживаться конкретные элементы данных (наименование испытания, серийный
номер лабораторного портативного компьютера испытателя и т. д.).
11.4.14 Установка интерфейсов инструментов
Должно быть описано, как новые инструменты соединяются с ЛИМС. как они испытываются, как
они валидируются. как они должны использоваться.
11.5 Документ, содержащий функциональные требования
11.5.1 Документ, содержащий функциональные требования, является ключевым документом в
процессе валидации ЛИМС. Этот документ используется для того, чтобы гарантировать, что ЛИМС
осуществляет то. что ей предписано делать, и продолжит эти действия, будучи валидированной. Этот
документ должен обрисовать в общих чертах бизнес-процессы и регулирующие требования и опреде
лить их политику. Поскольку разработка документа с функциональными требованиями является обя
занностью команды, работающей над проектом ЛИМС. существенно, чтобы команда по валидации
ЛИМС знала и понимала, что должно содержаться в этом документе.
11.5.2 Документ, содержащий функциональные требования, должендоступным языком предста
вить требуемые функциональности ЛИМС и проблемы эксплуатации ЛИМС. Этот документ является
тем «коммуникационным устройством», которое предназначено для передачи требований продавцу
ЛИМС. Кроме того, документ по функциональным требованиям помогает в разработке квалификацион
ных документов и связанных с ними протоколов испытаний. Когда протоколы испытаний будут выпол
нены. они будут сравниваться с требованиями, детально описанными в этом документе.
11.5.3 Данный документдолжен содержать подробную информацию, которая охватывает описа
ние системы, ограничения системы, требования, имеющие отношение к продавцу, детализированную
системную информацию, общие требования к работе систем, внедрение системы и другие
эксплуата ционные требования, а также другую документацию для сделанного на заказ
программного обеспечения.
11.5.3.1 Описание системы должно включать, но не ограничиваться ими. следующие пункты:
основная цель, необходимые характеристики окружающей среды системы и связанные интерфейсы,
критические для работы системы, а также спроектированный график завершения. Дополнительные
пункты также включают словарь терминов, акронимов и сокращений, специфических для ЛИМС, и
ссылки на другие корпоративные стандарты.
11.5.3.2 Ограничения системы должны включать, но неограничиваться ими. привилегированные
(предпочтительные) платформы для аппаратных средств и программного обеспечения, системные
интерфейсы для других систем [лабораторных приборов, локальной сети (Local Area Network, LAN),
глобальной сети (WideArea Network, WAN)) ит.д.. будущие требования к расширяемой системе, требо
вания к окружающей среде, среднюю продолжительность эксплуатации системы, планирование требо
ваний. доступность исходного кода и требования по обслуживанию.
11.5.3.3 Требования, относящиеся к продавцу, должны включать, но неограничиваться ими. тре
бования к аудиту продавца, компоненты системы продавца (аппаратные средства, исходный код и
23