Типовые требования к управлению электронными официальными документами (стр. 9 )

Классы э(11) и дела э(34) являются разными типами конструкции. Классы э(11) обеспечивают основу для классификации э(12), тогда как дела э(34) накапливают (агрегируют э(3)) официальные документы э(52); классы э(11) являются строительными блоками схемы классификации э(14) в отличие от дел э(34). Несмотря на эти главные различия, будет полезным перечислить некоторые требования вместе, т. к. они являются общими как обоих.

№	Требование	Тест
СУЭОД э(32) обязательно должна поддерживать захват э(8), ведение и представление э(50) метаданных э(40) для дел э(34) и классов э(11) в схеме классификации э(14), соответствующей «Модели метаданных MoReq2» (см. приложение 9).	Д
СУЭОД э(32) обязательно должна ограничивать возможность добавления метаданных э(40) в дело э(34) и класс э(11), как установлено «Моделью метаданных MoReq2» (см. приложение 9).	Н
СУЭОД э(32)  обязательно должна обеспечивать механизм автоматического размещения в иерархическом коде классификации э(13) (там, где такой код еще не существует – см. э3.1.15) в каждый класс э(11), дело э(34), раздел э(66) и том э(74) в схеме классификации э(14).	Д
См. Также  э7.1.1.
СУЭОД э(32) обязательно должна позволять ролям пользователей э(71) присваивать заголовок каждому электронному э(29) классу э(11), делу э(34), разделу э(66) и тому э(74).	Н
Это требование применимо к сфере неструктурированных дел э(42). Там, где требуется управление досье (структурированными делами) э(9), необходим альтернативный подход к наименованию. Это описано в разделе 10.5.
Обязательно должна быть возможность использования кода классификации э(13) и текстового заголовка дела э(34) как отдельно, так и вместе.	Д
СУЭОД э(32) обязательно должна позволять лицу исполняющему роль администратора э(1) настраивать код классификации э(13) как на этапе конфигурации э(20) так и после него.	Д
СУЭОД э(32) должна позволять настраивать классификационный код э(13), включая: формат идентификатора, ассоциированный с каждым уровнем иерархии, например, порядковый, алфавитный; первое число идентификатора в каждом классе э(11), например 1, 1000; интервал, который будет использоваться между последовательными классами э(11), например 1, 10; наличие или отсутствие ведущих нулей; любой глобальный префикс, например «корпоративный/»; любое глобальное расширение, например, суффикс страны; разделитель между каждым идентификатором, например “ / ”, “ - ”.	Д
СУЭОД э(32) обязательно должна сохранять дату открытия э(43) и дату закрытия э(16) класса э(11) или дела э(34) в их метаданных э(40).	Д
Дата открытия э(43) и дата закрытия э(16) класса э(11) или дела э(34) обеспечивает важный  контекст, относящийся к официальным документам э(52), содержащимся в них. См. также 3.3.9.
Когда класс э(11) или дело э(34) открыты э(43), в них возможно  захватывать э(8) официальные документы э(52). Когда класс э(11) или дело э(34) закрыты э(17), захватывать э(8) в них официальные документы э(52) невозможно.
СУЭОД э(32) обязательно должна сохранять дату создания нового класса э(11), дела э(34), раздела э(66) или тома э(74) в метаданных э(40) класса э(11) или дела э(34).	Д
В случае работы с материальными делами э(48) возможно, что дата открытия э(43) будет более ранней, чем дата создания, сохраненная в СУЭОД э(32). Это может произойти, если материальное дело э(48) создано и открыто э(43) только в материальной форме еще до того, как оно было создано в СУЭОД э(32) В случае применения электронных э(29) дел э(34), возможно, что дата открытия э(43) будет более ранней, чем дата создания, сохраненная в СУЭОД э(32)  Это может произойти, когда электронное э(29) дело э(34) импортировано э(38) в СУЭОД э(32) из другой системы.
Всякий раз, когда открывается новый класс э(11) или дело э(34), СУЭОД э(32) обязательно должна автоматически включать в их метаданные э(40) те атрибуты, которые наследуются в соответствии с их положением в схеме классификации э(14).	Д
Например, если дело э(34) озаглавленное «Встречи с общественностью» расположено в иерархическом пути названий: «План регионального развития: Консультации с общественностью: Встречи с общественностью» и лицо, выполняющее роль администратора э(1) добавляет новое дело э(34), озаглавленное «Письменные консультации», на том же уровне, что и дело э(34) «Встречи с общественностью», тогда новое дело э(34) автоматически наследует префикс «План регионального развития: Консультации с общественностью».
Примечание: унаследованные метаданные э(40) не обязательно должны  вноситься  явно; они могут быть переданы автоматически. Более подробно – см. в  Приложении 9.3
СУЭОД э(32) обязательно должна позволять лицу исполняющему роль администратора э(1) модифицировать  унаследованные значения метаданных э(40) до степени, разрешенной «Моделью метаданных MoReq2» (см. Приложение 9).	Д
Унаследованные значения часто являются значениями по умолчанию или начальными значениями. Они могут быть изменены, в случае если изменения совместимы с моделью метаданных э(40).
Любое добавление к унаследованным метаданным э(40) класса э(11) должно быть унаследовано по умолчанию всеми его дочерними классами э(11) и делами э(34).	Д
СУЭОД э(32) должна поддерживать назначение терминов из управляемого словаря, соответствующего ISO 2788, в качестве описательных метаданных э(40) класса э(11) или дела э(34) в  дополнение к другим требованиям данного раздела.	Д
СУЭОД э(32) должна поддерживать назначение терминов из управляемого словаря, соответствующего ISO 5964, в качестве описательных метаданных э(40) класса э(11) или дела э(34)  в дополнение к другим требованиям данного раздела.	Д
Требования  э3.2.13 и э3.2.14 идентичны, первый из них определяет одноязычный тезаурус, а последний – многоязычный тезаурус.
СУЭОД э(32) ни в коем случае не должна налагать практический лимит числа классов э(11) или дел э(34), которые могут быть определены.	В
СУЭОД э(32) должна быть способной экспортировать э(33) список или опись э(60) всех дел э(34) или дел э(34), отнесенных к определенному классу э(11) (и их дочерним классам э(11)), в формате э(36) XML и/или в человекочитаемом формате э(36).	В
СУЭОД э(32)  обязательно должна позволять лицу, исполняющему роль администратора э(1), конфигурировать класс э(11) таким образом, чтобы предоставлять или не предоставлять возможность сохранять официальные документы э(52) непосредственно в нем.	Д
Другими словами, система должна быть способной быть конфигурируемой таким образом, чтобы официальные документы э(52) могли не содержаться в делах э(34), разделах э(66) или томах э(74).

Тома и разделы

В системе, которая содержит бумажные официальные документы э(52), разбивка больших дел э(34) существенно важна с по причине эргономики и физическому сохранению папок, переплетов, обложек и т. д. Обычно из бумажных дел э(45) толщиной более 2 см создаются тома э(74). Когда дело э(34) (на самом деле первый том э(74) дела э(34), несмотря на название «дело э(34)») достигает лимита – например 2 см толщины – он считается закрытым томом э(74) и открывается э(43) новый том э(74). С электронными э(29) делами э(34) все обстоит иначе – электронное э(29) дело э(34) обычно может расти практически до любого размера без подобных проблем.

Однако на практике могут быть определенные преимущества в разбивке больших электронных э(29) дел э(34) на тома э(74).  Например, в следующих случаях:

когда пользователи э(68) вынуждены работать в отдалении (например, при низкой пропускной способности сети;  или после загрузки официальных документов э(52) в портативный компьютер или на запоминающее устройство с ограниченной емкостью); когда дела э(34) никогда не закрываются э(17), потому что они (например) связаны географически.

Подобным образом, бумажные дела э(45) часто разбиваются на разделы э(66), особенно в сфере управления досье (структурированными делами). Разделы э(66) используются для организации содержания дела э(34), как правило, в соответствии с типами документов э(27).

Соответственно в некоторых случаях существуют и преимущества разбивки  электронных э(29) дел э(34) на разделы э(66), например:

для облегчения навигации внутри дела э(34); для обеспечения возможности управлять официальными документами э(52), требования к хранению которых отличаются от остальных в деле э(34), например, содержащих закрытую в соответствии с  законодательством информацию.

Данный раздел включает требования, относящиеся к использованию томов э(74) и разделов э(66), которые обычно используются для подразделения дел э(34), которые в противном случае были бы неуправляемо большими. Однако Moreq2 не обязывает непременно осуществлять подразделение дел э(34), но требует, чтобы соответствующее Moreq2 программное обеспечение было способным обеспечить это в случае необходимости.

Разделы э(66) не рассматривались в предыдущей версии MoReq.

Краткая информация:

Каждое дело э(34) может содержать один или несколько разделов э(66); Каждый раздел э(66) может содержать один или несколько томов э(74); Тома э(74) отличаются от разделов э(66) и создаются независимо; Все разделы э(66) из открытого э(43) дела э(34) могут открываться э(43) или закрываться э(17) пользователями э(68) в соответствии с необходимостью; Только один том э(74) может быть открыт э(43) в каждом разделе э(66).

Для более детальной информации о разделах э(66) и томах э(74) см. раздел 2.2.