6.3.1.1 Содержание
Спецификация требований к системе должна быть полной, содержать всю информацию, необходимую для последующей деятельности в течение жизненного цикла безопасности системы и квалификации системы.
6.3.1.2 Характерные черты
Характерные черты документа, содержащего спецификацию требований к системе:
a) требования должны быть верифицируемыми.
Примечание 1 - Подраздел 4.3 IEEE 830 [2] содержит правила по проверке верифицируемости требований;
b) требования должны быть ясными и точными с тем, чтобы они были недвусмысленно понятны всем заинтересованным лицам, включая рецензентов и лиц, отвечающих за спецификацию системы и функциональную валидацию.
Примечание 2 - Например, в противоположность документу, приводящему обширные объяснения и дополнительную информацию, документ с точным и исчерпывающим изложением требований способствует ограничению риска неправильной интерпретации. Наиболее подходящим путем достижения этих целей является написание требований в соответствии с руководящими документами, такими как IEEE 830 [2] и EWICS N 6 [5];
c) требования к прикладным функциям следует излагать в терминах, связанных с функционированием, а не с компьютерной технологией, чтобы сделать доступной работу по верификации для инженеров-технологов и оперативного персонала, занимающихся контролем и управлением, которые могут иметь ограниченные познания в области компьютерной технологии;
d) требования должны разрабатываться с использованием документированных инжиниринговых методов, инструментальных средств и руководств системы.
Примечание 3 - Детальные требования к программным инструментам для систем класса 1 приведены в 4.2 МЭК 60880-2;
e) для того, чтобы облегчить выполнение оценки соответствия спецификации на систему и обеспечить связь с планом квалификации системы, требования рекомендуется излагать в письменном структурированном виде.
6.3.1.3 Верификация
Должны быть верифицированы следующие пункты спецификации требований:
a) требования должны быть прослеживаемыми и должны соответствовать требованиям к системе, установленным при разработке проекта архитектуры и распределении функций (см. 5.5);
b) требования к интерфейсам должны согласовываться с требованиями на взаимосвязанные системы и оборудование;
c) необходимо выявить требования, которые необоснованно увеличивают сложность системы (сложность может привести к увеличению риска ошибок в требованиях на систему и/или в самой системе).
6.3.2 Документация по спецификации системы
6.3.2.1 Содержание
a) Документация по спецификации системы должна быть полной и представлять всю информацию, необходимую для последующей деятельности в течение безопасного жизненного цикла системы, особенно в фазах проектирования и валидации системы.
b) Документация по спецификации системы должна определять, будет ли использоваться покупное оборудование или должно разрабатываться новое. Следует подтвердить, что выбранное оборудование пригодно для создания системы.
c) Документация по спецификации системы должна описывать следующую архитектуру системы:
- декомпозицию системы на подсистемы и/или на компоненты оборудования и программного обеспечения;
- внутреннее поведение системы (см. 6.1.1.2.2), включая описание основных внутренних для системы событий и ее защиту от этих событий (см. 6.1.2.2.3);
- границы, условия окружающей среды, ожидаемую надежность оборудования, поведение, функции, характеристики и интерфейсы каждой подсистемы;
- классификацию каждой подсистемы; следует представить обоснование, если подсистема окажется более низкого класса, чем система или подсистема, в которую она входит;
- условия эксплуатации и связь подсистем с системой.
Примечание - Описание подсистем может выполняться в соответствии с иерархией так, чтобы облегчить восприятие от общей схемы вниз до элементарных подсистем (т.е. подсистем, которые не могут далее дробиться в проектной документации). Может быть также полезна информация, показывающая "горизонтальные" связи.
d) Документация по спецификации системы должна включать в себя спецификацию программного обеспечения (см. 6.1.2.3).
e) В системах классов 1 и 2 должно быть определено распределение функций по подсистемам, т.е. спецификация системы должна определять, какие подсистемы участвуют и/или являются необходимыми для выполнения конкретной функции.
6.3.2.2 Характерные черты
Характерные черты документации по спецификации системы:
a) документация должна быть ясной и четкой, чтобы ее недвусмысленно могли понять все заинтересованные читатели, особенно рецензенты, а также изготовители системы и лица, выполняющие работы по интеграции и валидации;
b) спецификация прикладных функций должна быть выполнена так, чтобы облегчить верификацию и понимание со стороны инженерного и оперативного персонала АС, связанного с системами контроля и управления;
c) спецификация системы должна разрабатываться с использованием документированных инженерных методов, инструментальных средств и руководств системы. Эти методы, средства и руководства должны минимально отличаться от методов, средств и руководств, используемых при спецификации требований к системе.
Примечание - Методы и средства разработки программного обеспечения могут улучшить качество проектной спецификации на систему даже в сравнении с проектной спецификацией на систему с жесткой логикой;
d) спецификация на систему должна быть написана и упорядочена с тем, чтобы облегчить выполнение оценки соответствия требованиям к системе и обеспечить основу для проведения проверки системы, т.е. она должна облегчить полную идентификацию спецификаций (вместо объяснений и привлечения дополнительной информации).
6.3.2.3 Верификация
a) Верификацию спецификации системы на соответствие спецификации требованиям к системе следует проводить до завершения разработки детального проекта. Должна быть возможность для внесения поправок до установки на месте и сборки системы.
b) Должна быть установлена эффективная связь между ответственными за спецификацию системы и поставщиками оборудования для определения порядка верификации.
c) Верификация должна документально подтвердить соответствие и зарегистрировать любое несоответствие спецификации системы спецификации требований к системе.
d) Необходимо верифицировать правильность передачи из спецификации требований к прикладным функциям в спецификацию прикладного программного обеспечения.
e) Для систем классов 1 и 2 любое несоответствие должно быть устранено или обосновано с точки зрения безопасности за счет введения возможных компенсирующих мер.
f) Для систем классов 1 и 2 компоненты, увеличивающие сложность системы, но не обусловленные требованиями к ней, должны быть выявлены, а их наличие обосновано с точки зрения безопасности.
Примечание - Наличие особенностей, не предусмотренных спецификацией требований к системе, может значительно увеличить сложность системы, что ведет к снижению уверенности в ее правильной работе.
6.3.3 Документация детального проекта системы
Проект может осуществляться в несколько стадий. Требования настоящего пункта относятся к окончательному варианту документации на систему, которая должна быть в наличии после завершения проектных работ, интеграции и валидации, когда система готова к поставке и внедрению на АС.
Документация детального проекта системы обычно может быть разделена на четыре группы:
- документация проекта системы;
- необходимый анализ (см. 6.1.3.1);