И еще о точных терминах.
Должностные инструкции не являются частью системы и не относятся к системе.
Это документы организации, в которых указываются обязанности СОТРУДНИКА. Не надо пытаться использовать  для них 34 серию ГОСТ.
В лучшем случае в них может быть ссылка на инструкции к тому ПО, которым сотрудник должен пользоваться при выполнении своих должностных обязанностей. А можно ограничиться формулировкой, избегая указывать наименования (коды) документов-инструкций, ограничившись наименованием ПО. Под этим ПО может быть как обычное офисное, так и то, что является одной из компонент конкретной АС.
Для системы должны предусматриваться инструкция ПОЛЬЗОВАТЕЛЯ, администратора, системного программиста.
Разницу понимаете? Пользователь - это роль. Разные сотрудники могут авторизоваться в системе с одной и той же ролью пользователя, при этом они могут быть сотрудниками с разными окладами, из разных подразделений и у них, соответственно, будут разные должностные обязанности.

При том подходе, методология которого предлагается 34 ГОСТом, и который Сергей() проявил желание соблюсти, вполне можно подготовить необходимый набор документов/материалов (которые великолепно описывают все необходимые аспекты). Важно их грамотно "вплести" в деятельность предприятия (в составе приказов, пользователских инструкций и др. организационно-распорядительный и методических документов), чтобы обеспечить эффективное использование системы.

34.602 Можно писать чтобы тендеры выигрывать, а можно, чтобы работало.
Если, чтоб работало, то в ТЗ я бы записал требование к должностным инструкциям. Что они должны быть созданы в рамках проекта. Перечислить какие инструкции должны быть и т.д. (желательно).

Деление по видам обеспечения, по подсистемам и компонентам не следует смешивать.

Да, я это понимаю, что это разные вещи. Поэтому-то и поднял этот вопрос.

Кстати, термина "подсистема" в ГОСТ 34.003-90 не определено ))
Зато есть понятие "Функциональная подсистема АСУ "(ФП АСУ) по ГОСТ 24.701-86

Значит, скорее всего когда упоминается «подсистема», имеется ввиду именно «функциональная подсистема».

То есть получается так.
Обеспечение – это все, из чего состоит система, конкретные элементы системы.
Подсистема (функциональная подсистема) – это совокупность элементов АСУ (конкретных элементов обеспечения), которые выполняют конкретную функцию системы, то есть выделенных по функциональному признаку.
Компонент – это совокупность элементов АСУ (конкретных элементов обеспечения), объединенных по любому другому не-функциональному признаку.

Согласны?

Должностные инструкции не являются частью системы и не относятся к системе. Это документы организации, в которых указываются обязанности СОТРУДНИКА. Не надо пытаться использовать  для них 34 серию ГОСТ.
В лучшем случае в них может быть ссылка на инструкции к тому ПО, которым сотрудник должен пользоваться при выполнении своих должностных обязанностей…

Мы в них пропишем ссылку на «Порядок выполнения бизнес-процесса ХХХ».
Вот этот порядок наверно будет частью системы?

Разницу понимаете? Пользователь - это роль. Разные сотрудники могут авторизоваться в системе с одной и той же ролью пользователя, при этом они могут быть сотрудниками с разными…

Да, это понятно.

При том подходе, методология которого предлагается 34 ГОСТом, и который Сергей() проявил желание соблюсти, вполне можно подготовить необходимый набор документов/материалов (которые великолепно описывают все необходимые аспекты).

Вы меня правильно поняли.
Поэтому мы и решили использовать стандарт, потому что вряд ли бы мы сами придумали другой метод описать все важные моменты.

Если, чтоб работало, то в ТЗ я бы записал требование к должностным инструкциям. Что они должны быть созданы в рамках проекта. Перечислить какие инструкции должны быть и т.д. (желательно).

Да, так мы и задумывали.
Чтобы наша АС работала, эти инструкции должны быть.

Вернее, сами инструкции уже есть.
Мы впишем в ТЗ требование, что в них нужно внести изменения, необходимые для работы нашей АС.
Как я писал выше, мы в инструкции вставим ссылку на "Порядок выполнения бизнес-процесса ХХХ".

После изменения должностных инструкций, придется повторно ознакомить с ними сотрудников.

Обеспечение – это все, из чего состоит система, конкретные элементы системы.

Не так. АС не состоит из видов обеспечения. Каждый из  видов обеспечения отражает, как систему можно описать с перечисленных  позиций: какая математика там должна быть реализована вообще, какая информация и в каком виде должна обрабатываться  (храниться, передаваться, отображаться), какие правоотношения и как следует отрегулировать в связи с функционированием, и т.д. по всем другим видам обеспечения.
Предложу такую аналогию. Вы строите систему, разрабатываете ТЗ. Вы в общем знаете ее назначение и функционал и приблизительно как она будет работать. У вас в команде есть спец по каждому виду обеспечения - математик, юрист, спец по базам данных, программист, руководитель подразделения, которое будет ее использовать,  дизайнер-"эргономист",  и т.д. Каждый   из них, допустим, сперва для ТЗ разрабатывает требования в своей части. Ну а потом, допустим, формирует соответствующие решения.
Ещё раз: виды обеспечения - это не структура, это точки зрения.

Не так. АС не состоит из видов обеспечения.

А я не говорил про "виды обеспечения".
Раз есть виды, значит есть конкретные элементы, которые можно по определенному признаку разделить на эти виды.
Вот про эти конкретные элементы АС я и говорил в определении "обеспечения".
То есть я имел ввиду, что (повторю свое определение):
обеспечение - это конкретные элементы системы, их совокупность.

Каждый из  видов обеспечения отражает, как систему можно описать с перечисленных  позиций: какая математика ... какая информация ...
Ещё раз: виды обеспечения - это не структура, это точки зрения.

Согласен.
Виды обеспечения - это "группировка" конкретных элементов системы с определенной точки зрения.


Так будет правильно?

Не уверен, что следует подходить через "группировку" элементов по видам.
Главное, что следует учитывать  (и, надеюсь, удалось довести) - что описание по каждому их видов обеспечения и описание структуры системы (по функциональным подсистемам) - это разные подходы, формирующие вместе несколько моделей системы. Совокупность всех этих моделей наиболее полно описывает необходимую систему.
Как в будущей работе по созданию (развитию) вы сможете использовать эти модели (или создавать дополнительные) - это уже воля автора и самая интересная часть работы.
Практика дальше вам поможет 

Вот ещё статья Михаила Острогорского, простым языком о компонентах, подсистемах и видах обеспечения.
http://philosoft-services.com/gost34asconcept.zhtml