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

Признавая вышесказанное, этот раздел описывает требования, способные обеспечить гибкость и простоту пользования. Соответственно, большинство требований являются желательными, нежели обязательными. Эти требования могут быть реализованы в программном обеспечении по автоматизации рабочих процессов, интегрированном в СУЭОД э(32).

Некоторых из нижеприведенных требований направлены на способность выполнение определенных функций «… как интегрированных частей процесса». Во всех случаях это означает, что пользователь э(68), осуществляющий процесс, должен:

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

Это проиллюстрировано на диаграмме 11.1.

Диаграмма 11.1

Все следующие требования должны интерпретироваться как зависящие от прав доступа пользователя э(68).

№	Требование	Тест
СУЭОД э(32) должна разрешать пользователю э(68), которому позволено изменять гриф ограничения доступа э(63) для любого официального документа э(52), дела э(34) или класса э(11), проверять существующие категории и разрешения как составную часть процесса по изменению грифа.	Д
Если роль администратора э(1) предупреждена о понижении грифа ограничения доступа э(63) официального документа э(52) (смотри э10.13.28), роль администратора э(1) должна быть способна проверять официальный документ э(52) и / или его метаданные э(40) как составную часть процесса (по понижению грифа).	Д
Всегда, когда создается новое дело э(34), раздел э(66) или том э(74), и существует материальный контейнер для его хранения, СУЭОД э(32) должна разрешать пользователю э(68) печатать необходимую метку для материального контейнера, как составная часть процесса (по созданию агрегации э(3)).	Д
Это позволит создать метку, содержащую важные метаданные э(40), которая может быть прикреплена к материальному контейнеру. Метка может включать, но не только, такие метаданные э(40), как, Заголовок; Системный идентификатор; Код классификации э(13); Дату открытия э(43); Гриф ограничения доступа э(63) (если применяется); Обычное место хранения.
Всегда, когда пользователь э(63) удаляет любую информацию, как составную часть процесса (по удалению информации), он должен  получать предупреждение о существующих ссылках (смотри раздел 9.3) и иметь возможность изучать ссылки и ссылочную информацию и / или соответствующие метаданные э(40).	Д
СУЭОД э(32) должна разрешать пользователю э(68), который цензурирует э(54) официальный документ э(52), достигать следующих результатов единым интегрированным процессом: создать выписку из официального документа э(55); определить место в схеме классификации э(14), где выписка из официального документа э(55) должна быть размещена, и провозгласить ее в качестве официального документа э(52); связать выписку из официального документа э(55) с оригинальным официальным документом э(55); связать оригинальный официальный документ э(52) с выпиской из официального документа э(55).	Д
Когда пользователь э(68) провозглашает официальный документ э(52), СУЭОД э(32) должна разрешать ему проверять, был ли документ э(26) уже провозглашен в качестве официального документа э(52) единым интегрированным процессом.	Д
Это должно применяться к любому виду документа э(26).
СУЭОД э(32) должна предупреждать пользователя э(68), который захватывает э(8) документ э(26) в качестве официального документа э(52), был ли этот документ э(26) уже захвачен э(8), информируя пользователя э(68), где он расположен (класс э(11), дело э(34) и др.), и предоставляя пользователю э(68) выбор продолжать или отменить процесс захвата э(8).	Д
Когда пользователь э(68) захватывает э(68) официальный документ э(52), СУЭОД э(32) должна разрешать ему: просматривать схему классификации э(14) (для нахождения нужного класса э(11), дела э(34) и т. п.); просматривать метаданные э(40) (разрешения, ключевые слова э(39), описания и т. п.) для любого класса э(11) или дела э(34); до завершения захвата э(68) как интегрированной части процесса.	Д
Всегда, когда пользователь э(68) видит любой класс э(11), дело э(34), официальный документ э(34) и т. п. на экране в результате поиска при изучении схемы классификации э(14) или в любом ином контексте, пользователь э(68) должен иметь возможность выполнять любые разрешенные действия с ними напрямую, без необходимости переходить в другую часть СУЭОД э(32), включая как минимум: открытие э(43) его; определение его родителей в схеме классификации э(14); просматривание его метаданных э(40) или протокола аудита э(4); просматривание и прослеживание его ссылок; отправку его посредством электронной почты; изменение его грифа ограничения доступа э(63); просматривание пользователей э(63) и ролей э(62), имеющих доступ к нему; его печатание (или представление э(50)); его цензурирование э(54); его перемещение или удаление.	Д
СУЭОД э(32) должна разрешать уполномоченному пользователю э(6) изменять гриф ограничения доступа э(63) любого документа э(52), дела э(34) или класса э(11), включая обновление значений элементов всех затронутых  метаданных э(40), как один процесс.	Д
Если тезаурус, соответствующий ISO 2788 или ISO 5964, интегрирован в СУЭОД э(32), СУЭОД э(32) должна разрешать пользователю э(68), который вводит или обновляет значение ключевого слова э(39) (или другие значения элементов метаданных э(40), относящихся к тезаурусу), использовать все функции тезауруса, такие как расширение, сужение, родственные термины и синонимы, как интегрированную часть процесса.	Д
Заметим, что э8.1.18 содержит взаимосвязанные требование для поиска.

ТРЕБОВАНИЯ К МЕТАДАННЫМ

Эта глава представляет функциональные требования для управления метаданными э(40). «Модель» метаданных MoReq2 представлена в приложении 9. Раздел 12.1 рассматривает принципы метаданных э(40), а раздел 12.2 перечисляет основные требовании к метаданным э(40).

Метаданные э(40) включают, в контексте данной спецификации, индексную информацию и другие данные, необходимые для эффективного управления официальными документами э(52), такие, как информацию об ограничении доступа. Формальное определение дано в глоссарии. Более детальное разъяснение роли метаданных э(40) в управлении официальными документами э(52) можно найти в ISO 23081 (смотри приложение 7).

Принципы

Обзор

Не представляется возможным определить здесь все требования к метаданным э(40) для всех возможных реализаций СУЭОД э(32). Различные типы организаций и приложений имеют различающиеся потребности и традиции, которые варьируются в значительной степени. Например, некоторым организациям нужно индексирование, которое сфокусировано на названиях клиентов и датах транзакций, в то время как другим нужна строгая иерархическая система нумерации; некоторым требуется деление на тома э(74) по финансовым годам, тогда как другим этого не требуется; некоторым нужно управление доступом из соображений безопасности, а другим в целях защиты интеллектуальной собственности и так далее.

Эта глава MoReq2 поэтому представляет минимальные требования, которые должны рассматривать как начальная точка определения потребностей и дальнейшего развития. Эти минимальные требования тесно связаны со списком специфических «элементов» метаданных э(40), которые СУЭОД э(32) обязательно должна быть способна захватывать э(8) и обрабатывать. Из этих элементов составлена «Модель метаданных MoReq2» в приложении 9.

Основные требования к метаданным

№	Требование	Тест
Приложение СУЭОД э(32) никогда не должно устанавливать никаких практических ограничений на число элементов метаданных э(40), относящихся к каждому информационному объекту (в том числе классу э(11), делу э(34), разделу э(66), тому э(74), официальному документу э(52)).	В
Определение «практическое ограничение» будет варьироваться в зависимости от приложения. Например, в небольших организациях с небольшой схемой классификации э(14) может не потребоваться столь много элементов метаданных э(40) как в крупной организации со сложной схемой классификации э(14).
Если, содержание элементов метаданных э(40) может быть связано с функциональным режимом работы СУЭОД э(32), то система обязательно должна использовать содержание этих элементов метаданных э(40) для определения функциональности.	В
Например, если СУЭОД э(32) хранит метаданные э(40) даты открытия э(43) дела э(34), она обязательно должна заполнять эти метаданные э(40) автоматически при открытии э(43) дела э(40), а не требовать от пользователя э(68) заполнять их. Следует заметить, что это есть общее требование, которое распространяется на многие элементы метаданных э(40). MoReq2 не пытается идентифицировать все возможные ситуации.
СУЭОД э(32) обязательно должна позволять определять различные наборы элементов метаданных э(40) для различных типов официальных документов э(53)  на этапе конфигурации э(20).	Д
Например: счета-фактуры требуют в качестве метаданных э(40) учетный номер; для писем требуется элементы метаданных э(40), содержащие множество значений о получателе; официальные документы э(52), которые являются сканированными изображениями, требуют метаданные э(40), относящихся к процессам сканирования и индексирования.
СУЭОД э(32) обязательно должна позволять роли администратора э(1) определять на этапе конфигурации э(20), является ли элемент метаданных э(40) обязательным или опциональным.	Д
	СУЭОД э(32) обязательно должна поддерживать, по крайней мере, следующие форматы элементов метаданных э(40): буквенный;  буквенно-цифровой; числовой;  дата;  логический (т. e. ДА / НЕТ, ИСТИНА / ЛОЖЬ).	Д
СУЭОД э(32) должна поддерживать форматы элементов метаданных э(40), определяемые ролью администратора э(1), которые состоят из комбинаций форматов в э12.2.5.	Д
Например, досье может иметь справочный номер в формате nnnnn / aa-n.
СУЭОД э(32) обязательно должна поддерживать формат дат, определенный в ISO 8601 для всех дат.	Д
На этапе конфигурации э(20), СУЭОД э(32) должна допускать определение источников данных для каждого элемента метаданных э(40).	Д
Возможные источники описаны в требованиях э12.2.9, э12.2.10, э12.2.11 и э12.2.13.
СУЭОД э(32) обязательно должна позволять роли администратора э(1) указывать, какие значения элементов метаданных э(40) должны вводиться и редактироваться с клавиатуры, а какие из управляемого словаря.	Д
СУЭОД э(32) должна разрешать значениям элементов метаданных э(40) автоматически по умолчанию наследовать от более высокого уровня в иерархии схемы классификации э(14).	Д
Например, для тома э(74) значения некоторых элементов метаданных э(40) обязательно должны наследоваться от его родительского раздела э(66); а для официального документа э(52) значения некоторых метаданных э(40) могут наследоваться из тома э(74), в котором он хранится.
СУЭОД э(32) должна позволять получать значения метаданных э(40) из справочных таблиц или посредством обращений к другим программным приложениям.	Д
Например, СУЭОД э(32) может обеспечивать название улицы и почтовый индекс специализированным адресным программным приложением, которое возвращает название улицы, чтобы использовать его в качестве метаданных э(40).
Когда элементы метаданных э(40) заполняются из справочных таблиц, если выбор значения исключает другие значения в последующих справочных таблицах, это должно отражаться в значениях, показываемых пользователям э(68) в этих последующих таблицах.	Д
СУЭОД э(32) должна быть способна принимать значения метаданных э(40) от: программного приложения создания документов э(26) (смотри э6.1.12); операционной системы; сетевого программного обеспечения; пользователя э(68) во время захвата э(8) или провозглашения; правил, определенных на этапе конфигурации э(20), для автоматической генерации метаданных э(40) самой СУЭОД э(32) во время провозглашения (официального документа э(52)).	Д
СУЭОД э(32) обязательно должна быть способна подтверждать допустимость метаданных э(40), когда они вводятся пользователями э(68) и когда они импортируются э(38). При проверке на допустимость значений должны использоваться как минимум следующие механизмы: формат содержимого элементов; диапазон значений; проверку на наличие значений в списке, поддерживаемом ролью администратора э(1).	Д
Примером проверки по формату могут быть все числовые поля или формат даты (см. также э12.2.5). Примером проверки формата по диапазону значений может быть требование попадания даты в интервал между 1 января 1999 и 31 декабря 2001. Примером проверки по списку значений может быть условие, чтобы пункт назначения экспорта э(33) был представлен в списке.
СУЭОД э(32) обязательно должна быть способна поддерживать проверку достоверности метаданных э(40), используя вызовы к другим приложениям (например, к системам управления кадрами, чтобы проверить, назначен ли персональный номер, или проверить почтовый индекс по базе данных, или используя внутренние справочные таблицы).	Д
СУЭОД э(32) обязательно должна разрешать роли администратора э(1) конфигурировать проверку достоверности (как указано в э12.2.14 и э12.2.15) для применения к каждому элементу метаданных э(40).	Д
Разные элементы метаданных э(40) потребуют разной проверки достоверности. Так, например, даты потребуют проверки формата и диапазона, в то время как описания не потребуют никакой проверки достоверности.
Для значений элементов метаданных э(40), вводимых вручную, СУЭОД э(32) должна разрешать роли администратора э(1) конфигурировать элементы так, чтобы они поддерживали один из следующих режимов ввода информации: постоянные значения по умолчанию, определяемые пользователем э(68); фиксированные значения по умолчанию; сегодняшняя дата (только для элементов даты); пустой элемент. Могут поддерживаться также дополнительные режимы для ввода информации, не указанные выше.	Д
Постоянное значение по умолчанию выглядит как подразумеваемое значение в поле ввода данных последовательно для каждого элемента, пока оно не будет изменено пользователем э(68). Будучи однажды измененным, новое значение остается, т. е., становится постоянным. Оно должно оставаться постоянным, по крайней мере, до конца сессии, а в идеале и между сессиями. Это относится ко всем сущностям, к которым пользователи э(68) могут вводить значения метаданных э(40).
СУЭОД э(32) должна позволять такую конфигурацию, при которой любой элемент метаданных э(40) мог бы использоваться как поисковое поле при свободном текстовом поиске.	Д
Если элемент метаданных э(40) хранится в формате даты, СУЭОД э(32) должна допускать поисковые запросы, которые распознают значение даты.	Д
Например, СУЭОД э(32) должна поддерживать поиск по интервалу дат. Недостаточно хранить дату только в виде текстового поля.
Если элемент метаданных э(40) хранится в числовом формате, СУЭОД э(32) должна допускать поисковые запросы, которые распознают значение числа.	Д
СУЭОД э(32) обязательно должна разрешать роли администратора э(1) ограничивать возможность внесения изменений в значения метаданных э(40) как определено в матрице контроля доступа в разделе 13.4	Д
СУЭОД э(32) обязательно должна позволять роли администратора э(1) осуществлять перенастройку модели метаданных э(40) СУЭОД э(32) и обязательно должна регистрировать такие изменения в протоколе аудита э(4).	В
Например, может быть необходимо добавить новый элемент данных, такой как «Идентификатор подразделения» к некоторым типам документов э(27) вследствие организационных изменений.
СУЭОД э(32) обязательно должна позволять конфигурировать элементы метаданных э(40) на этапе конфигурации э(20), таким образом чтобы значения которые автоматически сгенерированы другими прикладными пакетами, операционной системой или СУЭОД э(32) (например, о пересылке данных по электронной почте) не могли быть изменены пользователями э(68) после их захвата э(8).	Д
СУЭОД э(32) обязательно должна разрешать на этапе конфигурации э(20) настраивать элементы метаданных э(40) таким образом, чтобы их значения не могли быть изменены пользователями э(68) после захвата э(8).	Д

СПРАВОЧНАЯ ИНФОРМАЦИЯ

Эта глава предоставляет справочную информацию о требованиях, упоминаемых в тексте MoReq2.