2.4 Функциональные требования

 

R2.4.1 Система управления записями должна включать функциональность:

 

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

 

Каждая служба может быть внедрена отдельно или же несколько служб могут быть связаны вместе.

 

Функциональные требования к каждой из этих служб представлены в базовых службах MoReq2010. Система может также включать дополнительную функциональность, описанную в дополнительных модулях MoReq2010.

Система может иметь общие с другими системами службы, кроме службы записей. MoReq2010 не определяет, как организована работа общих служб между разными системами.

Система должна включать функциональность, описываемую этими службами. MoReq2010, однако, не содержит требования внедрять эти сервисы как отдельные службы.

R2.4.2 При установке, система должна задать  для каждой службы(Е14.2.14) или группы служб (R2.4.1) следующие метаданные:

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

 

Каждая служба или группа служб также включает:

 

  • типы объектов для каждого объекта, управляемого службой или группой служб;
  • объекты, управляемый службой или группой служб;
  • историю событий для службы или группы служб;
  • список доступа (или его эквивалент, см. главу 4. Типовая служба ролей);
  • контекстуальные метаданные (или эквивалент, см. главу 7. Типовая служба метаданных).

 

У каждой службы или группы служб имеются собственные метаданные, собственная история событий и собственные списки доступа. Значение идентификатора службы должно соответствовать одной из служб, указанных в спецификации MoReq 2010 (значение каждого идентификатора указано в разделе служебной информации в начале каждой главы, начиная с главы 3. Служба пользователей и групп). Каждый идентификатор модуля должен соответствовать модулю, указанному в спецификации MoReq2010. Каждый сертификационный номер должен соответствовать сертификату, выданному Форумом по управлению жизненным циклом документов системе, прошедшей тестирование на совместимость в аккредитованном центре и сертифицированной по результатам тестирования.

 

Информация о поставщике должна включать имя поставщика, наименование продукта и номер установленной версии продукта. Она также может включать любые полезные сведения о поставщике — такие, например, как контактные данные или адрес сайта технической поддержки.

 

В соответствии с подходом, принятым в главе 4. Типовая служба ролей, список доступа может отсутствовать при выполнении системной операции и может быть добавлен уже при экспорте.

 

В соответствии с подходом, принятым в главе 7. Типовая служба метаданных, механизм добавления контекстуальных метаданных к разным службам может различаться.

 

R2.4.3 Система должна давать авторизованному пользователю возможность навигации по всем службам или группам служб (R2.4.1) или просматривать все метаданные, перечисленные в R2.4.2.

 

Значения понятий «навигация» и «просмотр» рассмотрены в главе 13. Глоссарий.

Пользователь может осуществлять навигацию по каждой службе или группе служб. Если в системе вся функциональность объединена в единое целое, для просмотра будет открыт только один набор метаданных, приписанных системе в целом.

 

Подробнее см. F14.5.158

 

R2.4.4 Система должна давать пользователю возможность изменять метаданные для каждой службы или группы служб (R2.4.1), в частности:

 

  • название;
  • описание;
  • информацию о владельце;
  • контекстуальные метаданные (если таковые имеются).

 

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

 

Подробнее см. F14.5.162

 

 

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

 

В отчете должно быть указано, внедрены ли службы по отдельности или же объединены в группы.

 

Целью данного требования является дать пользователю возможность убедиться, что система, внедряемая в конкретном месте или в конкретной организации, соответствует спецификациям MoReq2010. Именно поэтому идентификатор службы, идентификатор модуля и сертификационный номер каждой службы должны точно соответствовать спефикациям.

 

В отчете должно быть не просто отражено, прошла ли система тестирование на соответствие спецификациям MoReq2010; в нем должно быть показано, что она корректно установлена и настроена, и что все ее службы и модули на момент генерации отчета точно соответствуют спецификациям. MoReq2010 не определяет, каким именно образом должна осуществляться проверка на соответствия. Однако требование соответствия является необходимым.

 

Подробнее см. F14.5.163

 

R2.4.6 Каждая служба или группа служб в системе должна обладать интерфейсом, включающий один из модулей, описанных в 100. Типы интерфейсов.

 

Система может включать несколько интерфейсов из серии 100. При этом каждая служба или группа служб должна полностью соответствовать по крайней мере одному модулю из серии 100, а также быть протестирована на такое соответствие.

 

 

R2.4.7 В случае, если система не может выполнить заданную операцию, отчет об ошибках должен содержать следующую информацию:

 

  • дату и время совершения ошибки;
  • системный идентификатор функции, попытка выполнения которой предпринималась;
  • системный идентификатор авторизованного пользователя, инициировавшего выполнение функции;
  • системные идентификаторы всех задействованных объектов;
  • дополнительную информацию о совершенной ошибке.

 

 

Это требование касается отчета об ошибках, не поддерживаемого самой системой. Цель заключается в том, что отчет должен храниться отдельно от системы и быть доступным даже тогда, когда доступ к системе невозможен.

 

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

 

Обратите внимание на то, что все функции должны выполняться отдельно. MoReq2010 не допускает частичного выполнения функций, что является причиной неопределенного состояния системы. Если выполнение функции постоянно завершается неудачей,система должна откатить все изменения и вернуться к состоянию, в котором находилась до совершения ошибки. В настоящих спецификациях не описывается, каким образом должен осуществляться такой откат.

 

R2.4.8 При совершении ошибки, описанной в предыдущем пункте, система должна предоставлять пользователю возможность получить дополнительную информацию об ошибках, не обращаясь к внешнему отчету.

 

В MoReq2010 не сформулировано никаких требований к механизмам, за счет которых пользователь получает информацию об ошибках.

Способ сообщения пользователю информации об ошибках зависит от типа используемого интерфейса.

 

R2.4.9 Система должна позволять авторизованному пользователю просматривать объекты, ассоциированные с каждой службой или группой служб, а также их метаданные.

 

С каждой службой ассоциированы следующие типы объектов:

 

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

 

R2.4.10 Объекты каждого типа должны быть снабжены следующими метаданными:

 

  • системный идентификатор;
  • название;
  • описание.

 

Каждый объект также включает:

 

  • системные метаданные в соответствии с его типом;
  • определения функций;
  • историю событий;
  • список контроля доступа или его эквивалент (см. 4. Типовая служба ролей)

 

Системные идентификаторы для каждого типа объектов , а также их названия и описания содержатся в главе 14.2 Типы объектов.

 

Система должна использовать идентификаторы, включенные в настоящие спецификации, а не создавать собственные. В то же время название и описания могут быть заменены в системе в соответствии с локальными особенностями.

 

 

R2.4.11 Система должна позволять авторизованному пользователю просматривать определения функций для объектов объектами любого типа, а также их метаданные.

 

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

 

 

R2.14.12 Каждое определение функции должно обладать следующими метаданными:

 

  • системный идентификатор;
  • название;
  • описание;
  • флаг события;
  • индикатор сохранения после разрушения.

 

Каждое определение функции имеет также:

 

  • системные метаданные для добавления к событиям;
  • историю событий;
  • список доступа или его эквивалент (см. 4. Типовая служба ролей).

 

Системные идентификаторы для каждого определения функции в MoReq2010, равно как и названия по умолчанию, описания и типы объектов, к которым они применяются, приведены в 14.5 Определения функций.

 

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

 

R2.4.13 Для каждого определения функции система должна давать авторизованному пользователю возможность определять, будет ли при выполнении функции создаваться системное событие.

 

Значение хранится во флаге события.

 

Результатом выполнения функции и изменения требований всегда является генерация события, как это было описано в R2.14.2.

 

Кроме того, результатом выполнения функций, описанных в R2.4.21, R3.4.4 и R7.5.7 всегда будет генерация события, независимо от значения флага события.

R2.4.14 Генерация события должна осуществляться всегда при выполнении функции, описанной в R2.4.13.

 

Это требование является исключением в случае, описанном в R2.4.13, так как генерация событий

 

Смысл данного требования заключается том, что в истории должны сохраняться записи обо всех изменениях настроек, вне зависимости от того, трактуются ли они как события и были ли они внесены авторизованными пользователями.

 

R2.4.15 При выполнении в системе любой функции, описанной в MoReq2010 и при изменении значения флага события в соответствии с R2.4.13 система должна автоматически создавать новое событие, описывающее выполненную функцию и включаемое в историю событий всех задействованных объектов.

 

Система должна поддерживать историю событий как часть метаданных для каждого объекта.

 

R2.4.16 Для каждого события (E14.2.8), создаваемого при выполнении функции (R2.4.15), система должна создавать следующие метаданные:

 

  • системный идентификатор (M14.4.100);
  • метку времени (M14.4.9);
  • метку времени для произошедшего события (M14.4.27);
  • идентификатор функции (M14.4.26).

 

Если функция выполнена пользователем, а не системой, то метаданные также должны включать:

  • идентификатор пользователя (M14.4.83)

 

Они также могут включать (R2.4.18):

 

  • комментарий к событию (M14.4.25).

 

В случае, если событие дублируется (R6.5.16),метаданные также будут включать:

 

  • идентификатор дубликата.

 

Если в результате события происходит изменение метаданных объекта, метаданные также будут включать:

 

 

  • запись об изменении метаданных (R2.4.16).

 

События могут также включать дополнительные системные метаданные в зависимости от представляемой ими функции, в соответствии с описанием каждой функции в 14.5 Определения функций:

 

  • импортируемый идентификатор шаблона (M14.4.2);
  • идентификатор функции для удаленного события (M14.4.14);
  • идентификатор функции для удаленных метаданных (M14.4.15);
  • временную метку начала экспорта (M14.4.28);
  • временную метку завершения экспорта (M14.4.29);
  • идентификатор экспорта (M14.4.30);
  • полный флаг завершения экспорта (M14.4.31);
  • идентификатор предоставленной роли (M14.4.35);
  • исторические дата/время (M14.4.36);
  • код простроченного удаления (M14.4.58);
  • код просроченного подтверждения удаления (M14.4.60);
  • идентификатор задействованной агрегации (M14.4.64);
  • идентификатор задействованного класса (M14.4.65);
  • идентификатор задействованного компонента (M14.4.66);
  • идентификатор используемого указания о запрете на уничтожение (M14.4.67);
  • идентификатор используемого графика удаления (M14.4.68);
  • идентификатор используемого дубликата (M14.4. 69);
  • идентификатор задействованного типа объектов (M14.4.70);
  • идентификатор задействованного события (M14.4.71);
  • идентификатор используемого определения функции (M14.4.72);
  • идентификатор задействованной группы (M14.4.73);
  • идентификатор задействованного элемента определения метаданных (M14.4.74);
  • идентификатор нового родительского объекта (M14.4.75);
  • идентификатор предыдущего родительского объекта (M14.4.76);
  • идентификатор задействованной записи (M14.4.77);
  • идентификатор задействованной роли (M14.4.78);
  • идентификатор задействованной службы (M14.4.79);
  • идентификатор задействованного шаблона (M14.4.80);
  • идентификатор задействованного пользователя (M14.4.81);
  • идентификатор задействованного пользователя или группы пользователей (M14.4.82);
  • идентификатор аннулированной роли (M14.4.87);
  • поисковый запрос (M14.4.98);
  • общее число объектов (M14.4.105).

 

Идентификатор функции события должен быть ссылкой на определение функции, выполненной пользователем и снабженной идентификатором пользователя. Временная метка события показывает, когда была выполнена функция; она ставится системой и обычно совпадает с временной меткой создания объекта, за исключением случаев, когда событие было импортировано из другой системы.

 

Дополнительные элементы метаданных, добавляемые к объекту, зависят от выполненной функции и записываются как часть определения функции; их полный список приведен в 14.5 Определения функций. В зависимости от выполненной функции событие может потребовать дополнительных метаданных. Например, если выполненная функция представляла собой экспорт объекта, система должна включить в событие идентификатор экспорта и флаг завершения экспорта (R11.4.8).

 

Каждый объект, снабженный идентификатором вида «Идентификатор задействованного….» является объектом, задействованном в событии. Событие должно войти в историю событий каждого из задействованных объектов.

R2.4.17 При любом изменении метаданных, происходящем при выполнении функции и событии, генерируемом для этой функции (R2.4.15), система должна создавать записи об изменении метаданных (D14.3.3) для события, в результате которого изменяются метаданные. Запись должна включать:

 

  • идентификатор элемента определения метаданных;
  • предыдущее значение (M14.4.85);
  • новое значение (M14.4.57).

 

Запись об изменении метаданных представляет собой структуру данных, описанную в D14.3.3, в которой хранятся предыдущее и нынешнее значение элемента метаданных объекта.

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

 

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

 

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

 

R2.4.18 При выполнении по запросу пользователя функции, ведущей к изменению метаданных, система должна предоставлять авторизованному пользователю возможность оставлять комментарий, разъясняющий, почему эта функция была выполнена. В таком случае комментарий должен быть включен в историю событий как комментарий к событию (R2.4.16).

 

От системы не требуется, чтобы она обеспечивала важность комментирования для событий, не ведущих к изменению метаданных — например, для таких, как просмотр объектов и их метаданных. Обратите внимание на то, что изменение метаданных объекта приводит к созданию одной или нескольких записей об изменение метаданных.

 

Комментирование в большинстве случаев является необязательным. В то же время для некоторых функций пользовательский комментарий необходим (например, R2.4.21, R2.4.26, R8.4.17, R8.4.18, R7.5.7 и 11.4.10).

 

От системы не требуется давать комментарий к функциям, выполняемым ею самой, но она может быть настроена так, что при выполнении каждой такой функции комментарий генерируется и добавляется к событию автоматически.

 

R2.4.19 Система должна давать авторизованному пользователю возможность просматривать историю событий в порядке, соответствующем меткам времени их наступления, а также просматривать метаданные каждого события.

 

R2.4.20 Для каждого определения функции система должна предоставлять авторизованному пользователю возможность определять, должно ли событие, генерируемое системой при выполнении функции, сохраняться при удалении соответствующего объекта.

 

Событие сохранится, если установлен флажок Сохранять после уничтожения (R2.4.12).

 

События функций, для которых данный флажок не установлен, будут удалены из истории событий при удалении объекта. Они не будут включены в историю остаточного объекта.

 

Автоматическое удаление остаточных объектов может осуществляться по разным причинам, в частности, по следующим:

 

  • чтобы убедиться в окончательном удалении записи — удаляются все события, содержащие метаданные для предотвращения полного или частичного восстановления объекта;
  • чтобы обеспечить защиту персональных данных — удаляются события, которые могут содержать частную информацию;
  • чтобы уменьшить количество следов остаточного объекта.

 

Обратите внимание на то, что остаточный объект уже не может быть восстановлен после удаления.

 

События автоматически удаляются только для объектов, по отношению к котором было инициировано выполнение функции (см. R2.4.21). Данное положение имеет силу лишь для событий, в которых задействовано более одного объекта (см. 14.5 Определения функций).

 

R2.4.21 Система должна позволять авторизованному пользователю удалить событие из истории событий остаточного объекта при условии, что у пользователя и имеются основания для удаления и что будет создано событие.

 

В этом требовании описываются особые обстоятельства, когда бывает необходимым удалить метаданные или события объектов, для которых это предписано, например, решением суда. Совершенно не обязательно применять это требование по отношению к повседневным процессам управления записями.

 

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

 

Обратите внимание на то, что при выполнении данной функции всегда должно генерироваться событие, а требование R2.4.13 не имеет силы. Авторизованный пользователь должен разъяснить, почему он удаляет оставшееся после удаления событие, в комментарии к новому событию.

 

Новое событие должно также содержать идентификатор функции для удаленного события. Он содержит информацию о типе удаленного события без сохранения каких-либо связанных с этим событием метаданных.

 

Когда в удаляемом событии задействовано более одного объекта, оно должно всего быть удалено из истории объекта, по отношению к которому была выполнена функция. Этот объект является также задействованным в удалении. Например, при удалении события перемещения записи из одной агрегации в другую, она должна быть удалена из истории новой родительской агрегации, так как событие удаления совершалось по отношению к ней, и было создано соответствующее событие.

См. также R7.5.7

R2.4.22 Когда авторизованный пользователь просматривает некоторый набор объектов, система по умолчанию должна ограничить этот набор только активными объектами за исключением случаев, когда пользователь по собственному выбору настраивает возможность просмотра как активных, так и остаточных объектов.

 

Значение термина «просматривать» разъяснено в 13. Глоссарий. Удаленные объекты по умолчанию недоступны для просмотра .

 

R2.4.23 Система должна использовать идентификаторы содержащиеся в настоящих спецификациях, везде,где это необходимо.

 

В MoReq2010 содержатся системные идентификаторы для:

  • служб и модулей (см. 2.1. Информация о службах);
  • типов объектов (см. R2.4.10 и 14.5 Типы объектов);
  • определения элементов системных метаданных (см.R7.5.1 и 14.4 Определения системных элементов метаданных);

 

Системные идентификаторы, содержащиеся в MoReq2010, должны использоваться с целью обеспечения интероперабельности между различными системами управления записями.

 

R2.4.24 Система должна генерировать для новых объектов универсальные уникальные идентификаторы и не должна допускать возможности их изменения.

 

MoReq2010 не определяет, каким именно образом должны генерироваться идентификаторы для новых объектов. Рекомендуется использовать подходы, описанные в RFC41222.

 

R2.4.25 Система должна автоматически создавать метки времени, а также сохранять время создания для всех новых объектов.

 

По умолчанию метка времени и время создания сохраняют время и дату создания нового объекта.

 

R2.4.26 Система должна позволять авторизованному пользователю изменять метку времени и дату/время создания при условии, что он разъяснит причину, по которой осуществляется такое изменение.

 

По умолчанию дата и время создания соответствуют дате и времени создания объекта. Авторизованный пользователь может заменить дату и время на более ранние, но никогда — на более поздние. Каждое изменение даты и времени должно сопровождать комментарием, сохраняемым в событии, сгенерированном данной функцией.

 

Обратите внимание на то, что дата и время являются сигналом к сохранению, и их изменение применительно к агрегации может повлиять на расчет дат начала хранения.

 

R2.4.27 Система должна создавать метки времени, совместимые с форматами даты и времениW3C XML. В метках времени должна присутствовать информация о часовом поясе.

 

Требуемый формат описан в спецификациях XML Schema, в разделе 1.1 Часть 2: Типы данных. Формат даты для временной метки является вариантом формата даты/времени XML, который, в свою очередь, представляет собой разновидность стандарта ISO 8601, не допускающей сокращенных вариантов (ISO 8601:2004 Элементы данных и форматы обмена — Обмен информацией — Представление даты и времени). Информация о часовом поясе необходима для определения времени происхождения события по отношению к другим событиям, а также для обеспечения интероперабельности между системами, работающими в разных часовых поясах.

 

R2.4.28 Система должна хранить все текстуальные метаданные в формате Юникод с идентификатором языка в соответствии с RFC5646 и регистром языков Администрации адресного пространства Интернета.

 

Метаданные считаются текстуальными, если в определении их элементов установлен соответствующий флажок.

 

MoReq2010 не указывает, каким именно образом должен определяться язык для текстуальных метаданных. Возможные варианты могут включать:

 

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

 

 

Использование кодировки Юникод гарантирует корректное отображение; оно также необходимо для обеспечения интероперабельности. Последней версией стандарта Юникод является версия 6.0.

Оставить комментарий

Вы должны войти, чтобы оставить комментарий.