5. Спецификации на этапе создания компьютеризированной системы
5. Спецификации на этапе создания
компьютеризированной системы 
170. В зависимости от категории и сложности компьютеризированной системы документация по спецификации может быть объединена в один документ.
Функциональная спецификация
171. Функциональные спецификации должны содержать точное и подробное описание того, каким образом система удовлетворяет основным требованиям, предъявляемым к компьютерной системе и внешним интерфейсам. Это включает в себя описания функций, представлений и, если применимо, ограничений и атрибутов. Документ определяет, что должна делать система и какие функции и средства разрешены системой, включая перечень проектных целей системы.
172. Документ должен содержать подробные функциональные описания требований компании к системе, диаграммы использования, технологические схемы, спецификации процессов, спецификации внешних интерфейсов, рабочие спецификации, спецификации безопасности и контроля, конфигурируемые элементы, детали логической модели данных, спецификации технологической инфраструктуры, спецификации доступности (ремонтопригодности).
173. Спецификации следует подготовить и сформировать таким образом, чтобы можно было отслеживать каждое требование пользовательской спецификации, соотнося его с соответствующими функциональными возможностями и соответствующей документацией по испытаниям, что обеспечивает прослеживаемость на протяжении всего жизненного цикла от индивидуальных требований пользователя до соответствующих испытаний. Описания "верхнего" уровня следует разделить на "подуровни", описывающие отдельные функции. Каждая функция должна иметь систему кодирования, с тем чтобы ее можно было идентифицировать и отслеживать.
174. Функциональные спецификации следует проверить на соответствие требованиям пользователя, что позволяет выполнять квалификацию эксплуатации (OQ) (то есть функциональное тестирование) и утверждение проектных спецификаций системы.
Конфигурационные спецификации
175. Конфигурационная спецификация создается для описания:
списка компонентов аппаратного и программного обеспечения, включенных в компьютеризированную систему;
параметров системы (например, длины пароля), которые могут повлиять на одну или несколько функций в системе GMP.
176. Конфигурационная спецификация определяет базовые показатели конфигурации системы, адресующиеся к компонентам и интерфейсам программного обеспечения, а также параметрам системы, преимущественно фокусируясь на элементах конфигурации, которые могут повлиять на GMP-функциональные возможности.
177. Для идентификации профилей пользователей, определенных в системе, и связанных с ними функций создается матрица безопасности (включенная в конфигурационную спецификацию или в виде отдельного документа). Соотнесение пользователей с каждым профилем выполняется в соответствии с процедурами безопасности.
178. Конфигурационная спецификация должна также описывать IT-ландшафт, на котором размещено программное обеспечение, и то, как оно должно быть подключено к любой существующей системе или оборудованию. Поэтому этот документ должен включать также (или давать ссылку на другой документ) описание системного ландшафта и спецификации всех элементов, показанных на ландшафте (например, операционной системы, промежуточного программного обеспечения, вспомогательные инструменты (программы просмотра PDF-файлов, системных сред, интерфейсов, соответствующих компонентов IT-инфраструктуры, например, серверов и т.д.).
Проектные спецификации
179. Проектные спецификации необходимы для пользовательских компонентов в целях обеспечения детального технического описания функциональной спецификации и объяснения, как система выполняет то, что определено в спецификации высшего уровня.
180. Программное обеспечение должно быть разработано в соответствии с признанными стандартами проектирования (если это применимо). Проектные спецификации, определяя проект программного обеспечения, необходимы для разработанных на заказ приложений. Этот тип документации, как правило, не требуется для конфигурируемых продуктов, для которых проект программного обеспечения в большинстве случаев рассматривается и оценивается в ходе оценки поставщика.
181. Проект программного обеспечения выполняется на двух уровнях. На более высоком уровне он определяет программные модули (подсистемы), которые формируют полную программную систему, интерфейсы между этими модулями, а также интерфейсы к другим внешним системам. На нижнем уровне проект описывает работу отдельных программных модулей. Для кастомизированных компонентов проектная спецификация должна документировать компоненты разработки программного обеспечения, единицы реализации, дизайн пользовательского интерфейса, дизайн интерфейса, процедуры обработки ошибок и модели физических данных.
Детальная оценка рисков
182. Подробная оценка рисков требуется на этапах разработки спецификации и создания системы посредством выполнения процессного и (или) функционального анализа рисков с целью идентификации тех из них, которые могут повлиять на правильное или надежное функционирование системы на уровне процессов и функций соответственно.
183. Оценка функциональных рисков определяет соответствие нормативным требованиям и степень серьезности бизнес-рисков в сравнении с существующими функциональными возможностями системы и поддерживаемыми бизнес-процессами.
184. Валидационные группы вместе с владельцем бизнес-процесса или его представителями и техническими группами готовят оценку риска на основе требований пользователя и (или) функциональных, конфигурационных, проектных спецификаций.
185. Результат оценки риска должен включать результаты процессного и (или) функционального анализа риска, выполненного в соответствии с заранее определенной методологией.
186. В отчете об оценке рисков должны быть определены действия по снижению риска, включая описание объема тестирования и ресурсов.
