ГОСТ Р МЭК 61513— 2011
6.3.1.2 Характерные черты
Характерные черты документа, содержащего спецификацию требований к системе:
a) требования должны быть верифицируемыми.
П р и м е ч а н и е 1 — Подраздел 4.3 IEEE 830 [2] содержит правила по проверке верифицируемое! и
требований:
b
) требования должны быть ясными и точными с тем. чтобы они были недвусмысленно понятны всем
заинтересованным лицам, включая рецензентов и лиц. отвечающих заспецификацию системы и функцио
нальную валидацию.
П р и м е ч а н и е 2 — Например, в противоположность документу, приводящему обширные объяснения
и дополнительную информацию, документ с точным и исчерпывающим изложением требований способствует
ограничению риска неправильной интерпретации. Наиболее подходящим путем достижения этих целей являет
ся написание требований в соответствии с руководящими документами, такими как IEEE 830 [2] и EWICS N96
[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);
- границы, условия окружающей среды, ожидаемую надежностьоборудования, поведение, функции,
характеристики и интерфейсы каждой подсистемы:
- классификацию каждой подсистемы; следует представить обоснование, если подсистема окажется
более низкого класса, чем система или подсистема, в которую она входит;
- условия эксплуатации и связь подсистем с системой.
П р и м е ч а н и е — Описание подсистем гложет выполняться в соответствии с иерархией так. чтобы
облегчить восприятие от общей схемы вниз до элементарных подсистем (т.е. подсистем, которые не могут далее
дробиться в проектной документации). Может быть также полезна информация, показывающая «горизонталь
ные» связи.
46