ГОСТ Р 57318—2016
Пункт 3.1.4 Структурная декошозиция системы (SBS).
В нем следует описывать то, каким образом будут
разработаны SBS-элементы, а также пояснить, какая взаимосвязь между древом спецификаций и древом черте
жей с SBS-элементами и как должны быть связаны системные продукты с их процессами жизненного цикла. Здесь
также следует описать каждый SBS-элемент, методы разработки и контроля рабочих пакетов, их обьем; использо
вание ресурсов, включая объединенную группу разработчиков данного проекта IPT; отслеживание изменений: от
чет о затратах и его интегрирование для оперативного управления и определения основного направления/порядка
разработки и конфигурационное управление.
Пункт 3.1.5 Обучение персонала.
В нем необходимо определять внутреннюю и внешнюю (кпиентов/постав-
щикое) потребность в обучении персонала. Включает анализ рабочих характеристик, недостатков поведения или
отклонений, необходимой подготовки для их исправления и графика достижения требуемых профессиональных
навыков.
Пункт 3.1.6 Стандарты и процедуры.
В нети необходимо описать основные стандарты и процедуры, кото
рым должен соответствовать данный проект. Задачи по стандартизации включают в соответствующие разделы
SEP-процесса.
Пункт 3.1.7 Распределениересурсов между работами.
В нем необходимо описывать способ распределения
ресурсов между различными техническими задачами. Включает идентификацию требований к ресурсам, процеду
ры управления и перераспределения ресурсов.
Пункт 3.1.8 Ограничения.
В нем необходимо описывать способ распределения ресурсов между различны
ми техническими задачами. Включает идентификацию требований к ресурсам, процедуры управления и перерас
пределения ресурсов, основные проектные ограничения. Включает те аспекты, которые нельзя или невозможно
применять в данном проекте, а также сведения о финансировании, персонале, средствах, производственных мощ-
ностях/возможностях. критических ресурсах, а также о других ограничениях.
Пункт 3.1.9 Авторизация работ.
В нем необходимо описать метод, с помощью которого будет разрешаться
выполнение работ по данному проекту, а также метод, с помощью которого будет разрешаться внесение измене
ний в работы по проекту.
Подраздел
3.2 Анализ
требований.
В нем необходимо задокументировать: используемые подход и методы
анализа системных продуктов; среду применения: присущие человеку ограничения возможностей; ожидаемые ре
зультаты; конструктивные ограничения и выявленные потребности, требования и ограничения, связанные с про
цессами жизненного цикла. Следует также задокументировать подходы и методы анализа аппаратных средств,
программного обеспечения и потребностей человека и системы (трудовые ресурсы, персонал и его обучение, ме
тоды инженерной психологии и обеспечения безопасности системы); подходы и методы, которые будут использо
ваться для определения функциональных и эксплуатационных требований к следующим показателям качества:
производительность, пригодность к испытаниям, возможность интегрированной диагностики, распределяемость
(включая упаковку, обработку, транспортабельность и легкость монтажа), удобство применения, возможность тех
нической поддержки, обучаемость персонала и утилизируемое!ь: подход и методы, используемые в некоторых
инженерных областях: надежность, ремонтопригодность, электромагнитная совместимость и защита от электро
статических зарядов; опасности для здоровья и влияние человека на окружающую среду, безопасность системы,
инфраструктурная поддержка, а также другие инженерные специальности, влияющие на определение функци
ональных и эксплуатационных требований к системе и соответствующие уровню разработки. Кроме того, здесь
должны быть описаны подход и методы для развивающейся системы продуктов.
П р и м е ч а н и е — На некоторые области анализ требований может влиять только после мероприятий в
части синтеза, определяющих альтернативные решения. Часть описательной информации может быть более эф
фективно охвачена другими SEP-меролриятиями.
Подраздел 3.3 Валидация базовой линии требований.
Включает в себя описание подходов и методов вали
дации того, что базовая линия требований, установленная в рамках анализа требований, является отслеживаемой в
восходящем и нисходящем направлениях в соответствии с ожиданиями заинтересованных сторон, проектными,
производственными и внешними ограничениями.
Подраздел 3.4
Функциональный
анализ.
Включает в себя описание подходов и методов, планируемых для
определения функций низкого уровня, распределения требований к результатам деятельности и к другим предель
ным требованиям, к функциям более низкого уровня для описания функциональных интерфейсов, а также для
определения функциональной архитектуры. Также здесь должны быть определены подходы и методы оценки по
казателей качества и технические области специализации (см. 3.2).
Подраздел 3.5 Функциональная верификация.
Этот подраздел должен включать описание запланированных
подходов и методов для верификации того, что функциональная архитектура, созданная по результатам функ
ционального анализа, является отслеживаемой в восходящем и нисходящем порядке вплоть до утвержденной
базовой линии требований.
Подраздел
3.6 С интез. Э
тот
подраздел должен содержать подход и методы для преобразования ф ункцио
нальной архитектуры в проектную архитектуру (аппаратное/программное обеспечение и персонал, необходи
мые для поддержания жизненного цикла системы), для определения альтернативных системных концепций,
ф изических интерф ейсов, а также выбора предпочтительных продуктов и технологических решений. В нем
68