MINTAKÖVETELMÉNYEK AZ ELEKTRONIKUS IRATOK KEZELÉSÉHEZ JAVÍTOTT ÉS BŐVÍTETT KIADÁS, 2008
MoReq2 SPECIFIKÁCIÓ
Az eredeti, angol nyelvű változatot a Serco Consulting készítette az IDABC program finanszírozásával.
MINTAKÖVETELMÉNYEK AZ ELEKTRONIKUS IRATOK KEZELÉSÉHEZ JAVÍTOTT ÉS BŐVÍTETT KIADÁS, 2008
MoReq2 SPECIFIKÁCIÓ A Specifikáció és annak különböző nyelvi fordításai elektronikus formában az alábbi címeken érhetők el: http://www.moreq2.eu/moreq2 http://dlm-network.org/moreq2 http://ec.europa.eu/transparency/archival_policy Az angol nyelvű Specifikáció nyomtatásban is megjelent az Európai Közösség Hivatalos Kiadványainak Osztálya (Office for Official Publications of the European Communities) által az INSAR VIII. bővítményeként. Angolul megjelent Model Requirements for the Management of Electronic Records: Update and Extension 2008 — MoReq2 Specification címen az Európai Közösség Hivatalos Kiadványainak Osztálya gondozásában. © Európai Bizottság, 2008 Reproduction is authorised, except for commercial purposes, provided the source is acknowledged. A Specifikáció nem kereskedelmi célú sokszorosítása engedélyezett a forrás feltüntetése mellett. Jogi nyilatkozat: A kiadvány szerzői jogi tulajdonosa az Európai Közösségek Bizottsága. Az Európai Bizottság nem garantálja a Specifikációban található információk helyességét, továbbá nem vállal felelősséget az azok felhasználásából eredő károkért. Sem az Európai Bizottság, sem a nevében eljáró személyek vagy intézmények nem tehetők felelőssé a Specifikáció felhasználásából eredő esetleges károkért. Magyar fordítás © KOVEX-Computer Kft., 2010 Fordította: Korotij Ágnes Jelen fordítást, illetve annak részeit tilos reprodukálni, adatrögzítő rendszerben tárolni, bármilyen formában vagy eszközzel – elektronikus úton vagy más módon – közölni a szerzők engedélye nélkül. A fordítás és részeinek saját célú, ill. oktatási vagy kutatási célú reprodukálása engedélyezett a szerző nevének egyértelmű feltüntetése mellett, amennyiben nem fűződik hozzá kereskedelmi érdek. Jelen fordítást nem validálta a DLM Forum. A magyar fordítás helyességéért a felelősség kizárólag a KOVEX-Computer Kft-t terheli.
Tartalomjegyzék BEVEZETÉS.............................................................................................................. 7
1. 1.1.
Előzmények ........................................................................................................... 7
1.2.
A MoReq és a MoReq2 kapcsolata ........................................................................ 7
1.3.
A Specifikáció célja és hatásköre ........................................................................... 8
1.4.
Mi az EIKR? ........................................................................................................... 8
1.5.
A Specifikáció felhasználási területei ..................................................................... 9
1.6.
Szellemi tulajdonjogok ..........................................................................................10
1.7.
A Specifikáció hangsúlyos részei és korlátai .........................................................10
1.8.
Megfontolások a tagállamok számára ...................................................................11
1.9.
A Specifikáció testreszabása ................................................................................11
1.10.
A Specifikáció szerkezeti felépítése ......................................................................12
1.11.
Megfelelőségi tesztek............................................................................................13
1.12.
Kötelezően előírt és kívánatos követelmények ......................................................14
1.13.
A Specifikációval kapcsolatos megjegyzések ........................................................15 AZ EIKR KÖVETELMÉNYEK ÁTTEKINTÉSE ..........................................................16
2. 2.1.
Kulcsfontosságú szakkifejezések ..........................................................................16
2.2.
Alapfogalmak ........................................................................................................20
2.3.
Egyed-kapcsolat modell ........................................................................................26 BESOROLÁSI SÉMÁK ÉS AZ IRATOK RENDSZEREZÉSE ....................................29
3. 3.1.
A besorolási séma konfigurálása ..........................................................................30
3.2.
Osztályok és dossziék...........................................................................................35
3.3.
Kötetek és aldossziék ...........................................................................................38
3.4.
A besorolási séma karbantartása ..........................................................................41 ELLENŐRZÉS ÉS BIZTONSÁG ...............................................................................48
4. 4.1.
Hozzáférés-korlátozás ..........................................................................................48
4.2.
Eseménynapló ......................................................................................................53
4.3.
Biztonsági mentés és visszaállítás ........................................................................58
4.4.
Kiemelt iratok ........................................................................................................58 MEGŐRZÉS ÉS SELEJTEZÉS ................................................................................61
5.
6.
5.1.
Megőrzési és selejtezési ütemtervek .....................................................................61
5.2.
A selejtezési tevékenységek felülbírálása .............................................................70
5.3.
Áthelyezés, exportálás és megsemmisítés ............................................................72 IKTATÁS ÉS IRATTÁ NYILVÁNÍTÁS .......................................................................78
6.1.
Iktatás ...................................................................................................................78
6.2.
Tömeges importálás..............................................................................................89
6.3.
Az e-mailek (elektronikus levelek) kezeléséről ......................................................91
6.4.
Irattípusok .............................................................................................................97
6.5.
Szkennelés és képfeldolgozás ..............................................................................98 AZONOSÍTÓK ........................................................................................................104
7. 7.1.
Besorolási kódok.................................................................................................108
7.2.
Rendszerazonosítók ...........................................................................................110 KERESÉS, KINYERÉS ÉS MEGJELENÍTÉS .........................................................114
8. 8.1.
Keresés és lekérdezés ........................................................................................114
8.2.
Megjelenítés: az iratok megjelenítése képernyőn ................................................122
8.3.
Megjelenítés: nyomtatás .....................................................................................123
8.4.
Megjelenítés: egyéb ............................................................................................126 ADMINISZTRÁTORI FELADATOK .........................................................................128
9. 9.1.
Általános adminisztráció .....................................................................................128
9.2.
Jelentések készítése ...........................................................................................129
9.3.
Iratok módosítása, törlése és maszkolása...........................................................137
10.
OPCIONÁLIS MODULOK .......................................................................................143
10.1.
Fizikai (nem elektronikus) dossziék és iratok kezelése........................................144
10.2.
Fizikai iratok selejtezése .....................................................................................149
10.3.
Dokumentumkezelés és kollaboráció ..................................................................149
10.4.
Munkafolyamatok ................................................................................................156
10.5.
Ügyviteli környezetek ..........................................................................................162
10.6.
Tartalomkezelő rendszerek integrálása ...............................................................167
10.7.
Elektronikus aláírások .........................................................................................172
10.8.
Titkosítás ............................................................................................................175
10.9.
Digitális jogkezelés .............................................................................................176
10.10.
Elosztott rendszerek ........................................................................................179
10.11.
Offline és távoli munka ....................................................................................182
10.12.
Faxok integrálása ............................................................................................185
10.13.
Biztonsági kategóriák ......................................................................................187
11.
NEM FUNKCIONÁLIS KÖVETELMÉNYEK ............................................................196
11.1.
Használhatóság ..................................................................................................197
11.2.
Teljesítmény és skálázhatóság ...........................................................................202
11.3.
A rendszer rendelkezésre állása .........................................................................205
11.4.
Műszaki szabványok ...........................................................................................206
11.5.
Jogi és szabályozási követelmények ...................................................................208
11.6.
Kiszervezett adatkezelés ....................................................................................208
11.7.
Hosszú távú megőrzés és a technológiák elavulása ...........................................210
11.8.
Üzleti folyamatok.................................................................................................215
12.
METAADAT-KÖVETELMÉNYEK ............................................................................222
12.1.
Alapelvek ............................................................................................................222
12.2.
Általános metaadat-követelmények.....................................................................222
13.
HIVATKOZÁSI MODELL ........................................................................................228
13.1.
Szószedet ...........................................................................................................228
13.2.
Egyed-kapcsolat modell ......................................................................................241
13.3.
Az egyed-kapcsolat modell kifejtése ...................................................................244
13.4.
Hozzáférés-szabályozási modell .........................................................................246
1. FÜGGELÉK – HIVATKOZÁSOK ....................................................................................250 2. FÜGGELÉK – A SPECIFIKÁCIÓ FEJLESZTÉSÉNEK TÖRTÉNETE .............................252 3. FÜGGELÉK – A SPECIFIKÁCIÓ ELEKTRONIKUS FORMÁBAN TÖRTÉNŐ FELHASZNÁLÁSÁRÓL ......................................................................................................255 4. FÜGGELÉK – KÖSZÖNETNYILVÁNÍTÁS .....................................................................257 5. FÜGGELÉK – A MOREQ2 METAADAT-ELEMEK LEKÉPEZÉSE MÁS MODELLEKRE 261 6. FÜGGELÉK – DÁTUMFELDOLGOZÁS .........................................................................265 7. FÜGGELÉK – SZABVÁNYOK ÉS IRÁNYELVEK ...........................................................266 7.1
Szabványok ........................................................................................................266
7.2
További irányelvek ..............................................................................................268
7.3
A kisegítő technológiákra vonatkozó források és irányelvek ................................268
7.4
A digitális tartalommegőrzésre vonatkozó irányelvek ..........................................269
7.5
A MoReq2 kapcsolata a további irányelvekkel ....................................................270
8. FÜGGELÉK – KÜLÖNBSÉGEK A MOREQ2 ÉS A MOREQ KÖZÖTT ...........................276 8.1
Nem kompatibilis változások ...............................................................................276
8.2
A szakaszok megfeleltetése ................................................................................276
9. FÜGGELÉK – METAADATMODELL ..............................................................................280
ELŐSZÓ: MOREQ2 Előszó a Mintakövetelmények az elektronikus iratok kezeléséhez javított és bővített kiadásához 2001-es megjelenését követően a MoReq (Model Requirements for the management of electronic records – Mintakövetelmények az elektronikus iratok kezeléséhez) első, eredeti változatát széles körben vették használatba az európai kontinensen és azon túl. Az Európai Unióban hamar felismerték a MoReq-hez hasonló mintakövetelményekből származó előnyöket, melyek stabil alapot biztosítanak az Elektronikus Iratkezelő Rendszerek (EIKR) követelményeinek kidolgozásához. Megjelenése óta számos szoftverfejlesztő cégben a fejlesztési folyamat részévé vált a MoReq-ben foglalt követelmények feldolgozása. Egyre több iratkezelő termék hirdeti büszkén, hogy megfelel a MoReq előírásainak. A MoReq páratlan sikertörténet. Több kontinensről származó hivatkozások tömege jelzi a MoReq egyértelmű dominanciáját az elektronikus iratkezelés területén. Az információtechnológia azonban számos változáson ment keresztül 2001 óta. Radikális átalakuláson estek át az elektronikus iratok létrehozását, iktatását és kezelését érintő technológiák. A MoReq új kiadása, a MoReq2 a technológiai változások figyelembevételével készült. Kiemelt hangsúlyt kapnak az elmúlt néhány évben kiadott újabb szabványok és a bevált gyakorlatok. Ennek megfelelően jelen Specifikáció az eredeti MoReq radikális frissítéseként és kiegészítéseként íródott. Most először a MoReq2 támogatja a követelmények tesztelésének módszeres megtervezését és kivitelezését. A MoReq2 lehetővé teszi független megfelelőségi tesztek futtatását, a mintakövetelményekkel egyidejűleg pedig megfelelőségi tesztcsomagok is készültek. A követelmények egyértelmű tesztelhetősége érdekében több ponton át kellett írni a korábbi követelményeket, így a mostani változatot a szigorú, precíz megfogalmazás jellemzi. A hosszú évek során szerzett tapasztalatok rámutattak a nemzeti változatok szükségességére, melyek figyelembe veszik az eltérő nemzeti nyelveket, törvénykezést, szabályozást és az iratkezelési hagyományokat. Ebből kifolyólag a MoReq2 ezúttal lehetővé teszi a mintakövetelmények kiegészítését a tagállamok sajátos követelményeivel egy ún. „nulladik fejezetben”. A MoReq2 eredeti, angol nyelvű változatát a Serco Consulting készítette az Európai Bizottság részére az Európai Unió IDABC programjának finanszírozásában. A fejlesztési folyamatot az Európai Bizottság felügyelte a DLM Fórummal szoros együttműködésben, a tervezeteket a DLM szakértői nézték át a fejlesztés kulcsfontosságú szakaszaiban. A felülvizsgálatokon túl a felhasználók, tanácsadók, beszállítók, kutatók és jogi szervezetek tucatjainak a visszajelzései minden eddiginél nagyobb befolyást biztosítanak a MoReq2-nek. Mindezeket tekintve a MoReq2 érdemben segíti az elektronikus iratok kezelését Európában és világszerte.
1.
BEVEZETÉS
1.1.
Előzmények
Az elektronikus iratkezelésre vonatkozó követelmények átfogó előírásai összeállításának igényét először az 1996. évi DLM Fórumon1 fogalmazták meg 1996-ban, a megbeszélés során felmerült 10 intézkedési pont egyikeként. Ezt követően az Európai Bizottság IDA (Interchange of Data between Administrations – Kormányzatok közötti adatcsere) programja megbízást adott az elektronikus iratokat kezelő rendszerek (EIKR) mintaspecifikációjának kidolgozására. Ennek eredményeként 2001-re elkészült a MoReq2 (Model Requirements for the management of electronic records), az elektronikus iratok kezelésére vonatkozó mintakövetelmények leírása. A MoReq széles körben elterjedt az Európai Unió határain belül és kívül. Népszerűsége ellenére a MoReq-nek két jelentős problémával kellett szembenéznie: egyrészt nem volt egységes karbantartási rendszere, másrészt pedig nem biztosított lehetőséget a szoftverek MoReq-megfelelőségének a tesztelésére. A MoReq frissítése és a megfelelőségi tesztek sémája iránti igény egyre csak nőtt. A DLM Fórum megbeszéléseket kezdeményezett az Európai Bizottsággal. A megbeszélések eredményeképp a Bizottság Főtitkára (Directorate B e-Domec és a levéltárak közreműködésével) 2006-ban nyílt versenyt hirdetett a MoReq2 fejlesztésére. A fejlesztést a Serco Consulting (előzőleg Cornwell Management Consultants plc) szaktanácsadóinak kis csapata végezte 2007-ben, több ország szakértőinek, valamint a privát- és közszféra önkéntes bírálóinak támogatásával. A 2. számú függelék a fejlesztéshez használt módszertant ismerteti, a 4. számú függelék pedig a bírálóbizottság tagjainak közreműködését köszöni meg, akik idejükkel, tudásukkal és tapasztalatukkal járultak hozzá a MoReq továbbfejlesztéséhez.
1.2.
A MoReq és a MoReq2 kapcsolata
A MoReq2 a MoReq-et hivatott lecserélni. A MoReq2 leírását a „Hatáskör jelentés” tartalmazza. A jelentés az alábbiakban rögzíti a MoReq2 célkitűzéseit: „A MoReq2 kidolgozásával célunk, hogy összefoglaljuk az európai kontextusnak megfelelő, bővített funkcionális követelményeket, és támogassuk a megfelelőségi sémákat az alábbiak szerint: A MoReq időközben kulcsfontosságúvá emelkedett területeinek megerősítése és az újabb követelményterületek világos lefedése; A funkcionális követelmények tesztelhetőségének biztosítása és tesztanyagok fejlesztése a termékek megfelelőség-vizsgálatának segítéséhez;
1
2
A DLM a „Document Lifecycle management” (Dokumentum Életciklus Kezelés) rövidítése (eredetileg a francia “Données Lisibles par Machine” rövidítése volt, ami gép által olvasható adatot jelent). A DLM Fórum az Európa Tanács (94/C 235/03) 1994. június 17-én levont következtetéseire épült, amelyek a levéltárak közötti nagyobb együttműködést hangsúlyozták. A MoReq elérhető a http://www.DLM-Network.org weboldalon. Nyomtatásban is megjelent, azonosítószáma ISBN 92 894 1290 9.
A követelmények moduláris szervezése a különféle környezetekben történő felhasználás támogatására.” „A kompatibilitás érdekében a MoReq2 a MoReq továbbfejlesztése, nem egy radikálisan új termék.” A „továbbfejlesztés” fogalom kulcsfontosságú szerepet kap. Néhány apró ellentéttől eltekintve (melyeket egyértelműen jeleztünk), a MoReq2 teljesen kompatibilis a MoReq-kel: ugyanazokra a fogalmakra épül, és mint dokumentum, hasonló felépítésű.
1.3.
A Specifikáció célja és hatásköre
Jelen Specifikáció az elektronikus iratkezelő rendszerek mintakövetelményeinek második verziója (MoReq2). A fő hangsúly az elektronikus iratkezelő rendszerek (EIKR-ek) funkcionális követelményeinek leírására esik. Szándékunk szerint a Specifikáció a közszférában és a privát szektorban tevékenykedő szervezeteknél egyaránt felhasználható, ahol felmerül az igény egy EIKR bevezetésére, vagy a szervezet meglévő iratkezelő szoftverének a kiértékelésére. Bár a Specifikáció a funkcionális követelmények leírására összpontosít, felismeri, hogy a nem funkcionális jellemzők központi szerepet játszanak az EIKR sikerében. Mivel azonban a nem funkcionális jellemzők erősen függnek a rendszer környezetétől, a Specifikáció csak röviden vázolja a megfontolandó szempontokat. A Specifikáció kitér az iratkezeléshez szorosan kapcsolódó követelményekre is, mint a dokumentumkezelés és a fizikai iratok (pl. papíralapú dossziék, mikroformán tárolt iratok) elektronikus úton történő kezelése, de ezeket nem a lényeges iratkezelő funkciók leírásánál megszokott részletességgel tárgyalja. Az olyan területek, mint a digitalizálás és az elektronikus iratok létrehozásának módjai jelen Specifikáció hatáskörén kívül esnek. A MoReq2 az elektronikus iratkezelő rendszerek gyakorlati megvalósításának kérdéseire sem tér ki. A Specifikáció feltételezi, hogy az EIKR-t nemcsak adminisztrátorok, iratkezelők és levéltárosok szeretnék használni, hanem irodai alkalmazottak is, akik mindennapi munkájuk során iratokat hoznak létre, fogadnak és keresnek. Mivel jelen Specifikáció „minta”-követelményeket tartalmaz, tervezésekor az általánosságot tartottuk szem előtt. A Specifikáció nem foglalkozik platformfüggő vagy konkrét szektorra jellemző követelményekkel. Moduláris felépítésének köszönhetően a felhasználói közösségek üzleti követelményeiknek megfelelően bővíthetik a funkciók körét (lásd az 1.6. szakaszt és a 3. függeléket a Specifikáció felhasználásával és személyre szabásával kapcsolatban).
1.4.
Mi az EIKR?
Az EIKR egy olyan alkalmazás, amely elsősorban az elektronikus iratok kezelését szolgálja, bár fizikai iratok kezelésére is alkalmas lehet. Ez a szabvány döntő mértékben az elektronikus iratok kezelésével foglalkozik. Az elektronikus iratok kezelése összetett feladat, ami igen sok, az üzleti szükségletekhez igazodó funkcionalitás magas színvonalú megvalósítását követeli meg. Nyilvánvaló, hogy az ilyen igényeket kielégítő rendszer – azaz, egy EIKR – speciális szoftver használatát követeli meg, jóllehet a korszerű operációs rendszerek egyre nagyobb mértékben tartalmaznak iratkezelő funkciókat. Az iratkezelő szoftver állhat egyetlen csomagból, több integrált
csomagból, készülhet egy már meglévő rendszer testreszabásával, de ezek tetszőleges kombinációja is elfogadható. Valamennyi esetben nélkülözhetetlenek viszont a kiegészítő használati kézikönyvek és kezelési utasítások. Az EIKR jellege szervezetenként változhat. Jelen Specifikáció nem él feltételezésekkel az egyes EIKR megoldások jellegéről. A specifikáció felhasználóinak maguknak kell meghatározniuk, hogy miként igazítsák az EIKR funkcionalitását egyedi igényeikhez. Az elektronikus iratkezelő rendszerekre hosszú élettartam és egyre növekvő interaktivitás jellemző. Egy EIKR sokféleképpen kapcsolatba léphet más szoftveralkalmazásokkal, ennél fogva célszerű olyan interfészeket tervezni, amelyen keresztül más üzleti alkalmazások iratokat iktathatnak az EIKR-be (lásd 6.1. szakasz), vagy az EIKR-ben tárolt iratokhoz férhetnek hozzá (lásd 4.1. szakasz). Ez az igény különösen a CRM (Customer Relationship Management – Ügyfélkapcsolat kezelés) és az üzletági alkalmazások esetén jelentkezik. A 10. fejezet kitér a tartalomkezelő rendszerek (TKR [CMS]), a munkafolyamat-kezelő rendszerek és a faxok integrálásához szükséges interfészek leírására. A 6. fejezet az emailalkalmazások (6.3. szakasz), valamint a szkennelő és képfeldolgozó megoldások (6.5. szakasz) integrálását részletezi. A metaadatok validálásához felhasználható külső eszközöket a 6.1. szakasz, a jelentések generálását a 8.3. szakasz tartalmazza. A MoReq2 elsősorban a kifejezetten iratkezelésre tervezett alkalmazások követelményeit fedi le, ugyanakkor abban az esetben is érvényes, ha az iratkezelési funkciókat több alkalmazás vagy platform szolgáltatja együttesen. „Az EIKR-nek [lehetővé kell tennie]…” kezdetű állítások tehát olvashatók úgy is, hogy „A felhasználó szervezet alkalmazásrendszerének és/vagy a beszállító platformjának [lehetővé kell tennie]…”. A MoReq2 felhasználói maguk döntik el, mely követelmények vonatkoznak a környezetükre. A MoReq2 követelmények teljes tárháza integrált alkalmazásrendszerek készítését segíti. Adott esetben hasznosabb lehet a követelményeknek egy jól körülhatárolt részhalmazát megvalósítani, például amikor ügyviteli környezetek vagy üzletág-specifikus alkalmazások igényelnek iratkezelési funkciókat. Üzletág-specifikus alkalmazásra példa a MoReq2 10.4. szakaszában leírt munkafolyamat modul és a 10.5. szakaszban kifejtett ügyviteli modul. Ezeknek a megvalósításakor hasznos lehet megfontolni a MoReq2 többi részében leírt követelményeket.
1.5.
A Specifikáció felhasználási területei
A MoReq2 Specifikáció az alábbi célokra használható fel: potenciális EIKR felhasználók: pályázati felhívások elkészítésének alapjaként; EIKR felhasználók: EIKR rendszerek auditálásának és ellenőrzésének alapjaként; továbbképző szervezetek: referenciadokumentumként iratkezelés tréningeken és tananyagként; felsőoktatási intézmények: oktatási anyagként; EIKR beszállítók és fejlesztők: termékfejlesztési irányok meghatározásához a megkövetelt funkcionalitás(ok) kiemelésével; iratkezelési szolgáltatók: a nyújtandó szolgáltatások jellegének meghatározásához;
kiszervezett iratkezelési szolgáltatások potenciális felhasználói: a beszerzendő szolgáltatások körének meghatározásához segédanyagként. A teszt-keretrendszerrel kiegészítve további felhasználási területei: EIKR beszállítók tesztelése;
és
fejlesztők:
EIKR
megoldások
MoReq2-megfelelőségének
EIKR felhasználók: EIKR megvalósítások MoReq2-megfelelőségének tesztelése. A Specifikáció írásakor erős hangsúlyt fektettünk a könnyű használhatóságra. Célunk egy gyakorlatias és hasznos követelményspecifikáció összeállítása volt.
1.6.
Szellemi tulajdonjogok
A MoReq2 Specifikáció, beleértve a MoReq2 név használatát az Európai Bizottság szellemi tulajdonjogát képezi. Ennek megfelelően a MoReq2 és a nulladik fejezet bárminemű fordításának közzététele írásos engedélyhez kötött – lásd a szerzői jogi megjegyzést a borítón. Az engedélykérés részletei a DLM Forum weboldalán (http://www.DLM-Network.org) olvashatók.
1.7.
A Specifikáció hangsúlyos részei és korlátai
A MoReq2 Specifikációt a gyakorlatiasság és a használhatóság szellemében tervezték. Elsődleges célja, hogy gyakorlatias eszközt adjon a számítógépen tárolt és a papíralapú iratok kezelésében érdekelt szervezetek kezébe. A szabvány fejlesztésekor figyelembe vettük a levéltári és iratkezelő hagyományokat, és átértelmeztük azokat az elektronikus környezetek jellemzőinek megfelelően. A MoReq2 tehát az elektronikus és a fizikai iratok kezelésével szemben támasztott elvárásoknak is eleget tesz. A MoReq2 követelményeinek megvalósítása olyan rendszert eredményez, amely megfelelő szinten biztosítja az elektronikus iratok biztonságosságát és integritását az elektronikus és a klasszikus iratkezelési módszerek együttes figyelembevételének köszönhetően. A gyakorlatias megközelítés részeként a MoReq2 említést tesz a dokumentumkezelő rendszerek, a munkafolyamatok, a metaadat-technológiák stb. integrálásának lehetőségeiről. Bár a MoReq2 igen sok irattípus követelményeit lefedi, fontosnak tartjuk kiemelni, hogy az EIKR megoldások leginkább az ún. „strukturálatlan” iratok3 kezelését biztosítják. Strukturálatlan iraton olyan iratot értünk, melynek tartalmát elsősorban emberi felhasználók értelmezik. Strukturálatlan iratnak számítanak a levelek, emlékeztetők, e-mailek, képek, fénymásolatok, beszkennelt képek, továbbá a hang- és videofelvételek. Ezzel szemben a strukturált iratok tartalmát elsődlegesen számítógépes alkalmazások használják fel (pl. könyvelői rendszereknek szánt iratok, gyártás ütemezésének leírása, forgalomirányítórendszerek által kezelt iratok stb.). Az EIKR megoldások képesek ugyan strukturált iratokkal dolgozni, nem ez az elsődleges felhasználási területük. Az esetek túlnyomó többségében a strukturált iratok kezelését adatfeldolgozó alkalmazások végzik (a fenti példákat követve lehet szó általános főkönyvi rendszerekről, gyártásütemező alkalmazásokról, vagy akár forgalomirányító rendszerekről is). Az elektronikus iratkezelő rendszereket szinte kivétel nélkül strukturálatlan iratok kezelésére használják. Az ügyviteli környezetben használt EIKR-
3
A megfelelően kezelt elektronikus iratok bizonyos szempontból strukturáltak, mivel mindegyik rendelkezik metaadatokkal, eseménynapló bejegyzésekkel stb. Pontosabb lenne tehát a strukturálatlan iratokat „strukturálatlan tartalmú iratoknak” nevezni, ez a szóhasználat azonban nem elterjedt, így a MoReq2 sem követi.
ek azon kivételes alkalmazási területek közé tartoznak, amikor EIKR-ben strukturált iratokat is tárolnak (lásd 10.5. szakasz). A MoReq2 nem tér ki az iratkezelés gyakorlati vonatkozásaira. A Specifikáció szándékosan csak az iratkezelő szoftverektől elvárható funkciókat határozza meg, ennél fogva kerüli például a levéltári hagyományoknak, a döntéshozatalnak, vagy az iratkezelés elméletének tárgyalását – ezeknek a témáknak részletes szakirodalma van, néhányat megemlít az 1. függelék. Egy szemléletes példát kiragadva, a Specifikáció több helyen is úgy határoz, hogy bizonyos funkciókat kizárólag adminisztrátori szerepkörök érhetnek el. Ez nem azt jelenti, hogy az adminisztrátori szerepkörök felelős döntéseket hoznak, pusztán annyit jelent, hogy a szervezet felhasználóknak eme szűk körére korlátozza adott funkciók végrehajtásának jogát. Fontosnak tartjuk megjegyezni, hogy a szervezet iratkezelési elveit szorosan össze kell kapcsolni a szervezet üzleti és egyéb műszaki követelményeivel, továbbá az adminisztrátori szerepkörök – az iratkezelés és a rendszer szempontjából – csupán végrehajtói a felsőbb vezetés által hozott felelős döntéseknek. Végezetül megemlítjük, hogy jelen Specifikáció szándékosan felhasználó-központú: amennyire lehet, az elektronikus iratok kezelői által használt terminológiát követi. A Specifikáció például úgy fogalmaz, hogy az elektronikus dossziék iratokat „tartalmaznak”, jóllehet az elektronikus dossziék szigorú értelemben véve semmit sem tartalmaznak. További részletekért lásd a 2.2. szakaszt.
1.8.
Megfontolások a tagállamok számára
Amint arról a Specifikáció hatáskörét leíró 1.3. szakaszban szó esett, a MoReq2 a követelmények széles skáláját lefedi, hogy a különböző országok különböző iparágaira jellemző különböző irattípusokra is érvényes legyen. A szándékosan tág hatáskör jelentős hátránya ugyanakkor az, hogy lehetetlen a benne foglalt követelményeket változatlan formában átvenni. A különböző országok eltérő iratkezelési hagyományokat követnek, az iratkezelés jogi vonatkozásai és az arról alkotott nézetek is államonként változnak. Egyes esetekben, különösen egy új rendszer specifikációjának az elkészítésekor erősen ajánlott a Mintakövetelmények mellett a nemzeti különbségeket is figyelembe venni. Az iratkezelésben érintetteket segítendő a MoReq2 honosított változata egy „nemzeti fejezet”, a „nulladik fejezet” formájában a magyar iratkezelés követelményeit is tartalmazza, az alábbi pontok mentén: Szakkifejezések és kulcsfontosságú fogalmak fordítása; A magyar törvénykezés és szabályozás követelményei; A kisegítő technológiákra vonatkozó magyar szabványok és irányelvek; Szükség szerint további nemzeti követelmények; A felhasznált és javasolt magyar nyelvű források hivatkozásai.
1.9.
A Specifikáció testreszabása
A Specifikációban leírt követelmények mintaként szolgálnak. Nem minden EIKR implementáció valósítja meg az összes követelményt, tekintve, hogy bizonyos környezetekre adott követelmények nem érvényesek. Az érintett üzleti szektor, az implementáció mérete, a szervezet típusa és számos egyéb tényező további, sajátos követelmény bevezetését teheti indokolttá.
Ebből kifolyólag a Specifikációt a felhasználó szervezet igényeihez kell igazítani még az iratkezelő rendszer beszerzése vagy megvalósítása előtt. A testreszabás részeként: új követelményeket lehet felvenni, meglévőket pedig törölni a szervezet igényeinek megfelelően; a követelmények pontosíthatók, szűkíthetők. Például:
az egynél több lehetséges kimenetet előíró követelményeknél meg lehet határozni az egyetlen elvárt kimenetet;
a nem funkcionális követelményekben konkrét mennyiségi adatok szerepelhetnek.
leírhatók a szervezetre jellemző részletek, mint például a szoftverkörnyezet; egyértelműen jelezni kell az egyes követelményeknél, hogy melyeket:
vették át változatlanul a MoReq2-ből,
vették fel újként,
törölték,
pontosították.
A szabvány elektronikus és papíralapú felhasználásra egyaránt alkalmas. A szabvány a Microsoft Word 2003 szövegszerkesztővel készült, és a következő formátumokban érhető el: Microsoft Word 97-2003 Microsoft Word 2007 Adobe PDF. Az elektronikus változat használata számos előnnyel jár, bővebb részleteket a 3. függelék tartalmaz.
1.10.
A Specifikáció szerkezeti felépítése
A Specifikáció fejezetekre, azon belül szakaszokra tagolódik. A következő, 2. fejezet áttekintést ad néhány alapvető követelményről, kezdve a kulcsfontosságú szakkifejezések ismertetésével. A 3 – 9. fejezet tartalmazza az EIR követelmények részletes leírását. Mindegyik fejezet a funkcionális követelmények egy logikus csoportosítását adja. A szakterület jellegéből adódóan azonban elkerülhetetlen a fejezetek közötti bizonyos mértékű átfedés. A 10. fejezet több szakaszból áll, melyek mindegyike az EIKR egy opcionális moduljának a követelményeit részletezi. Az egyes szakaszok (pl. az elosztott rendszerekre vonatkozó követelmények) alapvető fontosságúak lesznek egyes szervezetek számára, míg feltehetően más szervezetek szükségtelennek találják ugyanazon követelményeket. A 11. fejezet a nem funkcionális követelményeket foglalja össze. A 12. fejezet a metaadatok kezelésére vonatkozó követelményeket írja le. A MoReq2 támogatásához szükséges metaadat elemek definíciói a 9. függelékben olvashatók.
A 13. fejezet az EIKR jelen Specifikáció értelmében vett formális hivatkozási modelljét tartalmazza. A modell felhasználható a Specifikáció kulcsfontosságú szempontjainak megértéséhez, beleértve a kifejezések (pl. kategória, aldosszié, kötet) és a közöttük fennálló kapcsolatok (pl. „Mi tárolható egy elektronikus dossziéban?”) formális meghatározását. A függelékek referencia dokumentumok részleteit, adminisztratív és egyéb jellegű információt tartalmaznak. A 9. függelék a MoReq2 metaadatmodelljét írja le. A kereszthivatkozások megkönnyítése végett, illetve terjedelmi okokból külön dokumentumban került kiadásra. A különféle forrásokból származó igényekre válaszolva, a követelményeket kiegészítő tesztanyagokat állítottunk össze. A tesztanyagokat a követelmények elektronikus példányai mellett adták ki. A MoReq2 felépítése támogatja a követelményekkel szembeni megfelelőségi tesztek készítését, a 10. fejezet különálló szakaszai például elkészíthetők önálló tesztmodulként. A MoReq2 tesztelésével kapcsolatos további részletekért lásd http://www.DLM-Network.org. A követelmények táblázatos formában szerepelnek, a táblázat minden egyes sora egy önálló követelménynek tekinthető. A táblázat oszlopait az 1.1. ábra illusztrálja.
1.1. ábra Mindegyik követelményhez tartozik egy sorszám. A követelmények megfogalmazása természetes nyelven történt.
1.11.
Megfelelőségi tesztek
Tesztelhetőség Az egyes követelményeket a „Teszt” nevű attribútum követi, ami azt mutatja, hogy ellenőrizhető-e a követelménynek való megfelelés. A „tesztelhetőségi” attribútum lehetséges értékei példákkal illusztrálva az alábbiak lehetnek: Igen: A követelmény formálisan tesztelhető. Példa követelmény: „Az EIKR-nek legalább háromszintes [besorolási] hierarchiát kell támogatnia.” Ezt úgy lehet tesztelni, hogy megpróbálunk felállítani egy háromszintes hierarchiát a rendszerben. Ha sikerül, a rendszer kielégíti a követelményt. Nem: A követelmény nem tesztelhető formálisan. Példa követelmény: „Az EIKRnek támogatnia kell a szervezet üzleti besorolási sémáját.” A legtöbb esetben nincs megfelelő eszköz ennek a követelménynek az ellenőrzésére. Részben: A követelmény tesztelhető ugyan, de a teszt lefedettsége csak részleges lehet. Pozitív kimenetű tesztet követően kiderülhet, hogy a rendszer mégsem felel meg a követelménynek. Példa követelmény: „Az EIKR nem korlátozhatja a besorolási séma hierarchiájában a szintek számát.” Formálisan nem lehet tesztelni egy határérték hiányát. A követelmény azonban bizonyos mértékig tesztelhető: megfelelően nagy számra megvizsgálható, hogy a rendszer engedi-e egy adott mélységű séma
létrehozását. A részleges tesztelés során kiderülhet, ha a rendszer nem felel meg a követelménynek. Az EIKR-en kívüli rendszerek A Specifikáció mellé teszt-keretrendszer is készült, amely az elektronikus iratkezelő rendszerek MoReq2-megfelelőségének tesztelését írja le. Néhány követelmény teljesítése az EIKR határain kívül eső hardver és szoftver jellemzőitől függ. Ide sorolhatók például az alábbi követelmények: az e-mailkezelő funkciók integrálása az e-mailkezelő alkalmazástól függ; a skálázhatóságra és integritásra vonatkozó követelmények teljesítését az adatbáziskezelő szoftver jellemzői befolyásolják; a szkennelési követelmények megvalósítása a szkennertől függ. Egyetlen EIKR sem tesztelhető az összes lehetséges külső hardver- és szoftverkomponens kipróbálásával, ezért az EIKR készítői maguk határozhatják meg, hogy a rendszert milyen hardver és szoftver felhasználásával szeretnének megfeleltetni a MoReq2 követelményeinek. A megfelelőségi tanúsítvány leírja, milyen hardverés szoftverkomponensek mellett tesztelték az EIKR-t; a megfelelőség csak a tanúsítványban leírt környezetre terjed ki. Amennyiben az EIKR potenciális felhasználói tudni szeretnék, hogy a rendszer más hardver- és szoftverkomponensekkel is megfelel-e a MoReq2 követelményeknek, az adott környezetet külön kell tesztelni.
1.12.
Kötelezően előírt és kívánatos követelmények
A MoReq2 kötelező és kívánatos követelményeket egyaránt tartalmaz. Azt, hogy egy követelmény kötelező-e, a követelmény mellett szereplő „Kötelező” attribútum jelöli, melynek értéke lehet: Igen: a követelmény kötelező jellegű; Nem: a követelmény opcionális. A kötelezőség minden esetben környezetfüggő. Egy opcionális modul kötelező követelménye csak a modulon belül kötelező, a teljes rendszer vonatkozásában nem az. Egyes esetekben egy követelmény csak akkor kötelező, ha a rendszer eleget tesz egy opcionális követelménynek. Ez mindig egyértelmű a környezetből, amint az a következő példából is kiderül: 3.1.17: Az EIKR-nek támogatnia kell egy teljes besorolási séma vagy a séma bizonyos részeinek az exportálását. (Opcionális) 3.1.18: Amennyiben az EIKR támogatja a besorolási sémák teljes vagy részleges exportálását, az exportálásnak tartalmaznia kell a kapcsolódó metaadatokat is. … (Kötelező) Ami azt jelenti, hogy a 3.1.18. pontban megkövetelt funkcionalitás akkor és csak akkor kötelező jellegű, ha a rendszer biztosítja a 3.1.17-ben foglalt opcionális funkcionalitást.
1.13.
A Specifikációval kapcsolatos megjegyzések
Észrevételeiket és megjegyzéseiket a http://www.DLM-Network.org címen, a DLM Fórum honlapján közzétett formában várjuk.
2.
AZ EIKR KÖVETELMÉNYEK ÁTTEKINTÉSE
Ez a fejezet néhány kulcsfontosságú szakkifejezés meghatározásával kezdődik (2.1. szakasz). Ezt követi az alapfogalmak ismertetése (2.2. szakasz). A fejezetet az adatmodell egyed-kapcsolat diagramja zárja (2.3. szakasz).
2.1.
Kulcsfontosságú szakkifejezések
A MoReq2 megköveteli, hogy bizonyos szakkifejezéseknek pontos jelentése legyen. Ahol lehetséges, a jelentések az általános szóhasználathoz, vagy az iratkezelő közösségen belül elfogadott szakmai nyelvhasználathoz igazodnak. Néhány kivételes esetben a szóhasználat a MoReq2 sajátja. Az összes szakkifejezés meghatározása a Szószedetben (13.1. szakasz) olvasható. Ezek közül a kulcsfontosságúakat – melyek a MoReq2 megértéséhez nélkülözhetetlenek – a könnyebb visszakereshetőség céljából itt megismételjük. A meghatározások teljes mértékben megegyeznek a Szószedetben olvasható definíciókkal. Azok a kifejezések, melyek a definíciókban dőlt betűkkel szerepelnek, megtalálhatók a Szószedetben (13.1. szakasz). aldosszié Egy dosszié logikai felosztása során keletkező kisebb egység. Megjegyzés: Az aldossziék használata nagyon gyakori az ügyiratkezelésben (kézi rendszerekben használják az ügyiratdarab kifejezést is). Az aldossziék általában névvel rendelkező egységek, és a dosszié iratainak meghatározott szempont szerint kiválasztott csoportját foglalják össze, például „számlák”, „értékelések”, „levelezés”. állomány Az iratot vagy dokumentumot alkotó elkülöníthető bitfolyam, vagy bitfolyamok egy csoportja. Szinonimája a fájl. Megjegyzés: „Elkülöníthető bitfolyamon” az információtechnológiában alapfogalomnak számító fájl, magyarul állomány értendő. Egy irat több állományból épülhet fel, melyek akár külön is kezelhetők. Megjegyzés: példa állományra: weboldalt alkotó HTML-dokumentum és a hozzá tartozó JPEG-képek; olyan, szövegszerkesztővel készített dokumentumból álló irat, mely (adott esetben) táblázat(ok)ra mutató, szövegbe ágyazott csatolóugrás(oka)t (hiperhivatkozás(oka)t) is tartalmaz. Megjegyzés: Az állományok pontosan elkülöníthetők egymástól. Amennyiben a szövegszerkesztővel készített dokumentum tartalmazza a beágyazott táblázatot (szemben azzal az esettel, amikor csak hivatkozik arra), a táblázat nem tekinthető önálló állománynak. Ilyenkor úgy vesszük, hogy az irat egyetlen állományból áll, mégpedig a beágyazott táblázatot tartalmazó, szövegszerkesztővel készített dokumentumból. Megjegyzés: Az e-mail és csatolmányai kezelhetők egyetlen állományként, állományként, vagy több iratként, attól függően, hogy milyen formátumban tárolják.
több
Ha az e-mail az üzenet törzsét a csatolmányokkal közös formátumban tárolja, akkor egyetlen állományból álló iratról beszélhetünk. Ha az e-mail a mellékleteket külön tárolja, azokat pedig az üzenet törzséből hivatkozza, akkor az irat az üzenet törzsét képviselő állományból és a mellékletekből mint külön állományokból áll. Ha az e-mail üzenetének törzsét és a csatolmányokat külön-külön állományokban tárolják, de ezek között nincs áthivatkozás, akkor az állományok különálló iratokként kezelendők. A bevált iratkezelési gyakorlatból az következik, hogy ilyen esetben manuálisan kapcsoljuk egymáshoz az iratokat. besorolás Az üzleti tevékenységek és az iratok, dossziék módszeres beazonosítása és elrendezése a besorolási séma egy kiválasztott osztályába a megállapodásoknak és eljárási szabályoknak megfelelően. Forrás: ISO 15489, 2006/24 (lásd 7. függelék). besorolási séma Az osztályok, dossziék, aldossziék, kötetek és iratok besorolását, osztályozását lehetővé tevő hierarchikus, egymástól függetlenül kialakítható kategória-struktúra. Forrás: 2006/24, a MoReq2-ben használt fogalmakhoz igazítva. dokumentum Egyedi egységként kezelhető rögzített információ vagy objektum. Forrás: ISO 15489, 2006/24 (lásd 7. függelék). Megjegyzés: A dokumentum lehet papíron, mikroformán, mágneses vagy egyéb elektronikus adathordozón rögzítve. Szövegek, adatok, ábrák, hangok, mozgóképek és egyéb formátumú információk tetszőleges kombinációit tartalmazhatja. A dokumentum egy vagy több állományból állhat. Megjegyzés: A dokumentumok számos lényeges szempontból különböznek az iratoktól. Dokumentumon olyan információt értünk, amely nem került iktatásra iratként, tehát nincs besorolva, rögzítve és tartalmát nem zárolták. A „rögzítés” fenti definícióban szereplő fogalma nem függ össze az iktatással, azaz nem iratra vonatkozik. Idővel természetesen előfordulhat, hogy egy dokumentumot irattá nyilvánítanak, miután átesik az iktatáson. dosszié Egyazon tárgyhoz, tevékenységhez vagy tranzakcióhoz kapcsolódó iratok szervezett egysége. Forrás: az ISAD(G) alapján (lásd 7. függelék). EIKR Elektronikus iratkezelő rendszer (Electronic Records Management System).
Megjegyzés: Az EIKR-ek és az EDKR-ek között lényegi eltérések vannak, ezeket a 10.3. szakasz foglalja össze. elektronikus irat Elektronikus formában tárolt irat. Megjegyzés: Elektronikus iratnak tekinthetők a szoftverekkel készített iratok, illetve a digitalizált, például beszkennelt – eredetileg papíralapú – iratok. iktatás (1) Digitális objektum konkrét példányának rögzítése vagy mentése. (Forrás: InterPARES 2 Project Terminology Database – az InterPARES 2 projekt terminológiai adatbázisa) (2) Információ mentése számítógépes rendszerben. Megjegyzés: A MoReq2 értelmezésében egy irat iktatása magában foglalja az irat rögzítését, azaz nyilvántartásba vételét az EIKR-ben, az irat besorolását, a hozzá tartozó metaadatok bevitelét, illetve a forrásdokumentum tartalmának befagyasztását. Az „iktatás” MoReq2-ben értelmezett fogalma („capture”) általánosabb, mint a hagyományosan iktatószámmal való nyilvántartásbavétel, azaz az irattá nyilvánítás teljes folyamatát reprezentálja; az angol „capture” általánosabb értelemben számítógépes adatrögzítést, mentést jelent (pl. metaadatok bevitelét). Adott szerv vagy személy üzletvitele vagy törvényi kötelezettségeinek teljesítése során keletkezett, fogadott, bizonyítékként vagy egyéb célból kezelt információ. Forrás: ISO 15489 (lásd 7. függelék). Megjegyzés: Iratnak tekinthető a szöveg, számadatsor, térkép, tervrajz vagy vázlat formájában rögzített információ. A megjelentetés szándékával készült könyv jellegű kézirat nem kezelhető iratként. Forrás: Levéltári törvény. Megjegyzés: Egy irat egy vagy több dokumentumot tartalmazhat (pl. egy dokumentum néhány csatolmánnyal), melyek formátumára és a tárolásához használt adathordozó típusára nincs megkötés. Ebből következik, hogy az irat több állományból is állhat. A forrásként használt dokumentum(ok) tartalmán kívül az irat mellé célszerű feljegyezni az irat környezetére, illetve, ha értelmezhető, a szerkezetére vonatkozó információkat (pl. szerkezeti információnak tekinthető, hogy hány állományból áll az irat). Az irat fő jellemzője, hogy nem lehet módosítani. Megjegyzés: az EIKR elektronikus iratokat és fizikai iratokat is kezelhet egyidejűleg. kötet Egy aldosszié felosztása során keletkező egység. Megjegyzés: Az aldossziék, ezáltal pedig a dossziék lebontása további egységekre a kezelhetőséget hivatott javítani olyan iratcsoportok létrehozásával, amelyek nem túl nagyok. A felosztás általában valamilyen formális, technikai, semmint logikai szempont szerint történik, például dátum vagy azonosító alapján.
metaadat (Az iratkezelés vonatkozásában) Az iratok környezetét, tartalmát és szerkezetét, illetve a kezelésükkel kapcsolatos információkat leíró adatok. Forrás: ISO 15489 (lásd 7. függelék). Megjegyzés: Más modellek a metaadatok eltérő felfogására épülnek. Egyesek például teljes mértékben metaadatként kezelik az eseménynaplóban rögzített információkat. Jóllehet az ehhez hasonló alternatív megközelítések az adott környezetre nézve érvényesek és értékesek, nem sokban segítik a rendszerek funkcionalitásának leírását, ennél fogva jelen Specifikáció figyelmen kívül hagyja azokat. osztály (Csak a MoReq2-ben) A besorolási séma hierarchiájának egy része, melyet a séma egy kiválasztott pontjától az alatta lévő dossziékig vezető folytonos vonal ábrázol. Megjegyzés: Klasszikus terminológiában az osztály szinonimái a besorolási séma tetszőleges szintjén előforduló „kategória”, „csoport”, „sorozat”, „tétel”, vagy ezek alosztályai („alkategória”, „alcsoport” stb.). Megjegyzés: MoReq2-ben az osztály az alá besorolt iratok összességét is jelentheti. ügyirat Konkrét folyamat vagy tevékenység eredményeként keletkező, egy vagy több tranzakcióhoz egészben vagy részben kapcsolódó, strukturált vagy részben strukturált dosszié. Megjegyzés: az ügyirat definíciója nem pontosan körülhatárolt, mint ahogy az ügyirat és a hagyományos dossziék közötti különbség sem éles. Az itt bemutatott definíció a MoReq2 megértését segíti, más kontextusban nem feltétlenül helytálló. Megjegyzés: Az ügyiratba tartozó iratok lehetnek strukturáltak vagy strukturálatlanok. Az ügyiratok megkülönböztető jellemvonása, hogy olyan folyamatok eredményeként keletkeznek, melyek legalább részben strukturáltak és megismételhetők. Ügyiratba gyűjthetők: az engedélykérelmek; a rutin szolgáltatások felőli érdeklődések; adott ügy kivizsgálásához kapcsolódó iratok; a felügyeleti ellenőrzések. Megjegyzés: Az ügyiratokra jellemző továbbá, hogy gyakran kikövetkeztethető a tartalmuk szerkezete; nagy számban fordulnak elő; részben vagy teljesen strukturáltak; jól ismert és előre meghatározott folyamat alapján használják és kezelik azokat;
megőrzésük előre meghatározott periódus idejére, törvényi előírás vagy egyéb szabályozás alapján kötelező; szakavatott személyek, végfelhasználók vagy adatfeldolgozó rendszerek a vezetőség jóváhagyása nélkül megnyithatják és lezárhatják.
2.2.
Alapfogalmak
A Specifikáció megértéséhez szükséges alapfogalmak a következők: irat és elektronikus irat; hiteles irat; elektronikus dosszié, aldosszié és kötet; besorolási séma; osztály; EIKR; iratok iktatása; felhasználói szerepkörök. Irat és elektronikus irat A DLM Fórum Irányelveinek (1. függelék) 2.4. szakaszában foglaltak értelmében az irat a következőkből áll: tartalom; szerkezet; környezet (kontextus); megjelenítési mód. A tartalom az irat által hordozott üzenetet közvetítő egy vagy több fizikai és/vagy elektronikus dokumentumban jelenik meg. A dokumentumok tárolási módja lehetővé teszi a jövőbeli felhasználók számára az iratban foglaltak és a kontextus megértését. Ebből következik, hogy egy jól kezelhető irat a dokumentum(ok) tartalmán túl fontos információkkal szolgál a szerkezetét és metaadatait illetően, melyek kitérnek az irat kontextusának és megjelenítésének a részleteire is. A MoReq2 értelmezésében azonban az irat csak a dokumentum(ok) információs tartalmát foglalja magában, a metaadatokat nem. Az irat megjelenítése az irat tartalmának, szerkezetének és (elektronikus iratok esetén) a megjelenítő szoftvernek a függvénye (lásd Szószedet.) A fizikai iratok világában a papíralapú iratok döntő többsége dossziékba rendezett egység, melyek fizikailag papírmappákban találhatók. Az ügyrendi szabályok biztosítják, hogy a felhasználók ne változtathassák meg az iratok tartalmát, sem az iratok dosszién belül elfoglalt helyét.
Hasonló elvek vonatkoznak az elektronikus iratokra is. Az irat egy vagy több elektronikus dokumentumból áll. Ezek a dokumentumok lehetnek szövegszerkesztett dokumentumok, email üzenetek, táblázatok, mozgó- és állóképek, audiofájlok, de tartozhatnak a digitális objektumok bármely más típusához is. A dokumentumok akkor válnak iratokká, amikor „iktatásra” kerülnek az elektronikus iratkezelő rendszerben. Iktatáskor az iratokat osztályozzák, azaz olyan kódokat rendelnek hozzájuk, amelyek kijelölik a besorolási sémában elfoglalt helyüket, lehetővé téve kezelésüket az elektronikus iratkezelő rendszer számára. Az iratokat legtöbbször közvetlenül dossziékba helyezik, de ez nem mindig igaz – lásd az alábbiakban. A megőrzés szempontjából nem szabad megfeledkezni arról, hogy az iratok gyakran több állományból állnak. Az egyes állományokat külön kezeli az operációs rendszer, azok formátuma sem feltétlenül egyforma, logikailag mégis egyetlen iratot alkotnak. Tipikus példa erre egy weboldal, amely a szöveget tartalmazó HTML-dokumentumból, JPEG-képek tucatjaiból és CSS stíluslapokból áll. Természetesen az egyetlen állományt tartalmazó iratok sem ritkák, ilyenek például a szövegszerkesztővel készített dokumentumok. Az iratok lényeges tulajdonsága, hogy információs tartalmuk rögzített. Ennek egyik következménye, hogy az elektronikus iratokon végrehajtott műveletek nem változtathatják meg az irat állományai között fennálló kapcsolatokat. Másként fogalmazva, az iratokon végrehajtott műveleteknek meg kell őrizniük az állományok közötti helyes kapcsolatokat. Ha például iratot helyezünk át vagy másolunk az EIKR-ben, áthelyezéskor vagy másoláskor az irat összes állományának egyszerre kell helyzetet változtatnia, hogy a kapcsolatok épek maradjanak. Hiteles iratok Az ISO 15489 szabvány értelmében egy irat akkor hiteles, ha az alábbi jellemzők érvényesek rá: hitelesség; megbízhatóság; integritás; használhatóság. Az ISO 15489 szabvány szerint az iratkezelő rendszerek célja, hogy a bennük tárolt iratok hitelesek legyenek. Összefoglalva, egy hiteles irat bizonyíthatóan az, amit állít magáról; bizonyíthatóan az a személy készítette vagy küldte, akiről az irat ezt állítja; bizonyíthatóan a feltűntetett időpontban készült vagy érkezett; megbízható, mert tartalma pontosan tükrözi azt a tranzakciót, tevékenységet vagy tényt, amelyet leírni hivatott; teljes és változatlan; visszakereshető, megjeleníthető, értelmezhető, helye beazonosítható.
A MoReq2 követelményeit úgy tervezték, hogy a MoReq2 előírásainak megfelelő iratkezelő rendszerek biztosítsák a bennük tárolt iratok hitelességét. A MoReq2 követelményeinek teljesítése önmagában azonban még nem elég; a vállalati irányelvek és azok betartása legalább ennyire fontos. Elektronikus dosszié, aldosszié és kötet A papíralapú iratokat dossziékban gyűjtik össze, és ezeket többnyire papíranyagú mappákban helyezik el. A papíralapú dossziékat a besorolási séma szerint rendezik. Az elektronikus iratkezelő rendszerben az elektronikus iratok úgy kezelhetők, mintha elektronikus mappákban tárolt elektronikus dossziékban lennének összegyűjtve. A valóságban azonban az elektronikus dossziék és mappák csupán virtuálisan léteznek: fizikailag nem „tartalmaznak” semmit a hozzájuk rendelt iratok metaadatain kívül. Sok esetben ténylegesen nem is szükséges valós különbséget tenni az elektronikus rendszerben a dossziék (ügyiratok) és a mappák között. Az ilyen jellegű technikai részleteket a rendszerek általában elrejtik a felhasználók elől, így az EIKR szoftver felhasználói úgy tekinthetik és kezelhetik a mappákat, mintha azok fizikailag tartalmaznák a dossziéhoz rendelt iratokat. A MoReq2 végig ebben a felhasználó-központú szellemben íródott. A Specifikáció további részében ezért úgy kezeljük a virtuális dossziékat, mintha azok valóban „tartalmaznák” az iratokat. Azt azonban ne feledjük, hogy ez a Specifikáció csak a dossziék kezelésére vonatkozó funkcionális követelményeket írja le, a dossziék implementációjának kérdéseivel nem foglalkozik. A magyar közhivatalok iratkezelési gyakorlatában az ügyiratok többnyire „szervesen”, az ügy egy-egy fázisában keletkező ügyiratdarabokból állnak össze. Kevésbé formális környezetekben ennek a dossziék és aldossziék kapcsolata feleltethető meg. Mindkét esetben igaz, hogy a részekre bontás „logikai” alapon történik, azaz általában emberi döntést igényel annak meghatározása, hogy egy adott irat melyik aldossziéba (ügyiratdarabba) kerüljön. Példaként említhető egy föld eladásával kapcsolatos dosszié (ügyirat), ami külön aldossziékat (ügyiratdarabokat) szentel az eladást kísérő különböző üzleti tevékenységeknek, mint a hirdetések, szerződések, ügyvédek által intézett papírok stb. Az aldossziékba tehát az iratokat tartalmuk típusa szerint rendszerezik. Ebből kifolyólag az egyes aldossziékra különböző megőrzési és selejtezési ütemtervek lehetnek érvényben. Függetlenül attól, hogy a dossziékat aldossziékra bontották-e vagy sem (illetve az ügyiratokat ügyiratdarabokra), a dossziék szükség esetén „mechanikusan” kötetekre oszthatók előre rögzített szabályok alapján. A „mechanikus” vagy formális ebben az összefüggésben azt jelenti, hogy a felosztás nem az iratok tartalmát veszi figyelembe, hanem olyan egyszerű szempontok szerint történik, mint a dosszié mérete, a benne tárolt iratok száma, vagy időintervallumok. Ez a gyakorlat a papíralapú dossziék idején alakult ki, célja a dossziék méretének és súlyának kezelhető nagyságúra korlátozása volt. A kötetekre bontás az elektronikus iratok esetében is követhető, segítségével a felülvizsgálat, átvitel és egyéb feladatok szempontjából kezelhető egységeket kapunk. Különösen azoknál a dossziéknál jelent nagy segítséget a kötetekre osztás, amelyekben hosszú időn keresztül nagy mennyiségű irat halmozódik fel. Bár a dossziék és a kötetek közötti különbség egyértelmű, a vele járó következmények már kevésbé. Az implementációs igények befolyásolják a kötetekre osztás szükségességét. Az eltérések abból adódnak, hogy: egyes dossziékat korlátozott időn belül le kell zárni, így a kezelés mértékegysége a dosszié, függetlenül attól, hogy kötetekre osztották-e. Példa erre egy kis összegű beszerzés vagy egy projekt iratanyaga.
egyes dossziék élettartama korlátlan (vagy közel korlátlan), így a kezelés mértékegysége a kötet. Példaként említhető egy földrajzi régió iratait tartalmazó dosszié, vagy az olyan, lezárási határidővel nem rendelkező dossziék, mint a jogszabálygyűjtemények, vagy egy szervezet működése során felhalmozott számlák, ahol minden évben új kötetet nyitnak. Kivételes esetben az iratot nem dossziéba iktatják, hanem közvetlenül a besorolási séma egy osztályához rendelik. Ezt a 3.2.17. pont részletezi. Besorolási séma Az iratkezelés strukturált módon rendszerezi a dossziékat, az így kialakított szerkezet célja, hogy a szervezet vagy személy üzleti tevékenységét tükrözze. A dossziék szervezésének módját írja le a „besorolási séma”. A besorolási séma leggyakrabban hierarchikus felépítésű. A továbbiakban a Specifikáció a hierarchikus elrendezéssel foglalkozik, az egyéb, például szótárjellegű besorolási sémák a MoReq2 hatáskörén kívül esnek. A MoReq2-megfelelőség egyik feltétele a hierarchikus besorolási sémák támogatása. Hasonlóan ahhoz, ahogy a dossziék valóságosnak tűnnek, holott pusztán a hozzájuk rendelt iratokat fogják össze, a besorolási séma hierarchiájának magasabb szintjei is valóságosnak tűnnek, pedig pusztán az alájuk rendelt dossziékat vagy az alacsonyabb szinteket fogják össze. Akárcsak a dossziék esetében, jelen Specifikáció csak a hierarchiával szemben támasztott követelményeket sorolja fel, azok implementációs kérdéseivel nem foglalkozik. A dossziék a hierarchia bármelyik szintjéhez besorolhatók. A 2.1. ábra egy képzeletbeli besorolási sémát illusztrál, amely osztályokból áll, melyekhez dossziékat rendeltek. Ez az ábra természetesen jóval primitívebb, mint a valós életben előforduló besorolási sémák bármelyike.
2.1. ábra Megjegyzendő, hogy a 2.1. ábra csak egy lehetséges elrendezése a szinteknek, dossziéknak és iratoknak. Az összes számba vehető szintet és elrendezést lehetetlen bemutatni.
Osztály MoReq2-ben az „osztály” a besorolási séma által képviselt hierarchia egy része, melyet a séma egy kiválasztott pontjától az alatta lévő dossziékig vezető folytonos vonal ábrázol. Ennek következtében felfogható az egyes leírásokban olvasható „kategória”, „csoport”, „sorozat”, esetleg „tétel” (illetve az alájuk sorolt „alkategória”, „alcsoport” stb.) kifejezés szinonimájának is. Vizuálisan elképzelve a hierarchia osztályai a faágakhoz hasonlítanak. Egy osztály szétágazhat további alosztályokra és al-alosztályokra, mint ahogy egy sorozat is alsorozatra, al-alsorozatra stb. bontható. A fenti példát folytatva, a 2.2. ábrán megfigyelhető sötét hátterű téglalapok és a vastagított vonalak egy osztályt szemléltetnek.
2.2. ábra A MoReq2 értelmezésében egy „osztály” a hozzá rendelt összes dossziét, iratot stb. is jelentheti. (Egy valós életből vett példához hasonlítva, az „üveg” kifejezés egyaránt jelenthet tárolóeszközt, például „teleöntöttem az üveget vízzel” és mértékegységet, mint a „kérek két üveggel” szófordulatban. Utóbbi esetben az üveg tartalmi egységet jelent.) A kétértelműség szándékos, a szövegkörnyezetből azonban mindig kiderül, hogy melyik értelmezés az odaillő. A Specifikáció a „gyerek” és „szülő” kifejezésekkel szemlélteti az egyedek közötti kapcsolatokat. Az egyed „gyereke” az a csomópont, amelyik a hierarchiában egy szinttel alatta található, és közvetlen kapcsolatban áll vele (más szóval az egyed közvetlen leszármazottja). Az egyed szülője ezzel szemben az az egyed, amelyik közvetlenül az egyed fölött szerepel a hierarchiában. Az itt bemutatott metaforákkal élve, az osztályok gyerekei további osztályok, dossziék és (elvétve) iratok lehetnek. Néhány kivételes esetben az iratokat közvetlenül egy osztályhoz lehet rendelni, anélkül, hogy az irat bármilyen dossziéhoz tartozna. Ennek a viszonylag ritka esetnek a pontos körülményeit a MoReq2 mintakövetelményei részletesen leírják. Elektronikus iratkezelő rendszerek Az elektronikus iratkezelő rendszerek elsősorban az elektronikus iratok kezelését szolgálják, bár megfelelő funkciókkal ellátva fizikai iratok kezelésére is alkalmassá tehetők. Az elektronikus iratkezelő rendszerek gyakran szoros együttműködésben állnak egy elektronikus dokumentumkezelő rendszerrel (EDKR) és a szervezetnél fontos szerepet
betöltő egyéb üzleti alkalmazásokkal. Az EIKR és az EDKR között az a lényegi különbség, hogy míg az EIKR iratok kezelésére való, az EDKR dokumentumokkal foglalkozik. A kétféle rendszer funkcionalitását nem mindig lehet élesen szétválasztani, különösen, ha az egyének mindennapi munkájának szerves részét képezik. A 10.3. szakasz az iratkezelő rendszerektől elvárható dokumentumkezelési funkciókat mutatja be. Iratok iktatása A rendszert használó szervezet vagy személy tevékenysége során keletkezett vagy érkezett dokumentumok az EIKR-be történő iktatásuk után válnak iratokká. Az iktatás részeként az iratokat „besorolják”, azaz hozzájuk rendelik a megfelelő osztályt azonosító kódot (az iktatószámot), a rendszer ez alapján tudja az iratot kezelni. A besorolás mellett, az iktatás részeként az iratok egyedi (elsődleges) azonosítót is kapnak. Sok esetben a megőrzött dokumentum azért tekinthető iratnak, mert (különösen a szigorú munkafolyamatokat követő szervezeteknél) egy üzleti folyamat részeként keletkezett. A számlakiállításnak például automatikusan egy irat iktatását kell maga után vonnia. Más esetekben szabályzat rögzítheti, hogy minden, adott üzleti ügyben keletkezett dokumentumot irattá kell nyilvánítani még akkor is, ha szigorú értelemben véve nem vesz részt az üzleti folyamatban. Olyan helyzet is előfordulhat, amikor az iktatást egy felhasználó kezdeményezi önkényesen. Azt, hogy mely dokumentumok kerüljenek iktatásra az iratkezelő rendszerbe, olyan tényezők elemzésére kell alapozni, mint a jogszabályi környezet, az üzleti és számonkérhetőségi követelmények, valamint az iratok rögzítésének elmulasztásával járó kockázat mértéke. Példaként említhető a vállalati elvekkel kapcsolatos jegyzetek sorsa a szervezeten belül. Ha a szervezet úgy dönt, hogy csak a fontos dokumentumokat őrzi meg, akkor a jelentéktelen emlékeztetőket, például a tárgyalások időpontjára és helyszínére vonatkozó felhívásokat törlik. A tárgyalások során készült jegyzetekről viszont a tartalmuk alapján dől el, hogy lényegesek-e a megőrzés céljából, vagy sem. A MoReq2 feladata, hogy az előbb említett helyzetek mindegyikét támogassa. Más szavakkal, a MoReq2 általános célú irodai rendszert ír le, és nem egy kizárólag a levéltárosok és közigazgatásbeli ügyintézők igényeit kielégítő, az alkalmazások szűk körét támogató iratkezelő rendszert. Felhasználói és adminisztrátori szerepkörök A MoReq2 terminológiájában „felhasználónak” tekinthető az a személy, aki érvényes engedéllyel használja munkája során az EIKR-t. Azok a személyek tehát, akik beléphetnek az EIKR-be, mind felhasználók, beleértve az adminisztrátorokat is. Mivel azonban nem mindig lehet pontosan megkülönböztetni az adminisztrátort és a többi felhasználót, lévén hogy feladataik részben átfedik egymást, a MoReq2 számos követelmény megfogalmazásakor az informatikában jól bevált „szerepkör” fogalomra épít. A különböző szervezetek különféleképpen valósítják meg elektronikus iratkezelő rendszereiket. Kis szervezet megelégszik egyetlen adminisztrátorral, a nagyvállalatok viszont több adminisztrátort foglalkoztatnak, különféle hozzáférési engedélyekkel. Nem célszerű tehát a Specifikációban konkrét hozzáférési profilokat rögzíteni; a szerepkörök rugalmasabb hozzáférés-kezelést tesznek lehetővé. A MoReq2 a szerepkörök két típusát határozza meg, ezek a „felhasználói szerepkörök” és az „adminisztrátori szerepkörök”. A gyakorlatban a szervezetek túlnyomó része több személyt is kijelöl a két szerepkör betöltésére, számos helyen pedig további szerepköröket definiálnak. A 13.4. szakaszban látható mátrix néhány példa szerepkört mutat be a hozzárendelhető lehetséges jogosultságokkal. Röviden összefoglalva, a MoReq2-ben bemutatott „szerepkör” nem más, mint egy felhasználói profil, és mint ilyen, felelősségek és jogosultságok (egynél több) felhasználóhoz
rendelhető csoportját jelöli ki. A „szerepkör” tehát nem összekeverendő a beosztással. A MoReq2 két-két példát említ az adminisztrátori és felhasználói szerepkörökre. Az adminisztrátori szerepkört betöltő személyek az iratok kezelésében érintettek, számukra az iratok tartalmának és üzleti környezetének nincs különösebb jelentősége. Másrészről gondoskodnak az elektronikus iratkezelő rendszer zavartalan működéséhez szükséges hardver, szoftver és tárolóhelyek karbantartásáról, rendszeres biztonsági mentéseket végeznek és az iratkezelő rendszer teljesítményét hangolják. Az adminisztrátorokkal ellentétben a felhasználói szerepkört betöltő személyek az irodai dolgozók és a kutatók által megszokott hagyományos szolgáltatásokat veszik igénybe, mint amilyen a dokumentumok hozzáadása, iratok keresése és megtekintése. A hangsúly az iratok tartalmára esik, más megfogalmazással élve a felhasználókat az iratokban nyomon követhető üzleti folyamatok érdeklik.
2.3.
Egyed-kapcsolat modell
A 2.5. ábrán bemutatjuk a MoReq2-ben használt fontosabb fogalmak egyed-kapcsolat modelljét, ami a Specifikáció megértését segíti. A leíró magyarázatot a 13.3. szakasz tartalmazza. A modell fontos vonása, hogy nem ábrázolja közvetlenül az iratkezelő rendszer megvalósításához használható struktúrákat. Az egyed-kapcsolat modell elméleti szemszögből mutatja be az iratokkal összefüggő egyedtípusokat. Az EIKR ezeket a kapcsolattípusokat használja fel a modellben bemutatott szerkezetek viselkedésének szimulálására. Lásd 2.2. szakasz. Az alábbi kulcsfontosságú fogalmak közötti kapcsolatokat szemlélteti az egyed-kapcsolat diagram: Osztály; Dosszié, Ügyirat; Aldosszié; Ügyiratdarab; Kötet; Irat; Állomány. Az egyed-kapcsolat diagram további egyedtípusokat is tartalmaz. A diagramon az egyedtípusokat (dossziékat, iratokat stb.) téglalapok jelölik. A téglalapokat összekötő vonalak felelnek meg az egyedtípusok között fennálló kapcsolatoknak. A vonal közepén lévő szöveg a kapcsolat leírását adja meg, a kapcsolatot a nyíl irányában kell értelmezni. A kapcsolatok egyes végpontjaiban feltüntetett számok a kapcsolatban résztvevő előfordulások számát (azaz a kapcsolat számosságát) jelentik, pontos értelmezésüket a jelmagyarázat tartalmazza. Ennek megfelelően a 2.3. ábrát úgy kell olvasni, hogy „egy irat egy vagy több állományból áll” (külön felhívjuk az Olvasó figyelmét a nyíl irányára).
2.3. ábra A két vagy több kapcsolaton áthaladó félkörív azt jelenti, hogy a kapcsolatok kölcsönösen kizárják egymást minden résztvevő egyed-előfordulás esetén. A 2.4. ábrán látható félkörív olvasata: „egy iratot vagy kötetben, vagy aldossziéban lehet tárolni, de egyszerre csak az egyikben”.
2.4. ábra Az osztály egyedtípus az „összetevője” kapcsolattal kapcsolódik saját magához (része lehet önmaga is). Informálisan ez azt jelenti, hogy egy hierarchikus besorolási sémában minden osztály egy vagy több osztályt tartalmazhat. Ha a diagramról eltávolítanánk ezt a (rekurzív) kapcsolatot, a modell a nem hierarchikus besorolási sémák leírásának is megfelelne. A MoReq2 további részében félkövérrel szedett kék szöveg jelzi a Szószedetben megadott kifejezés első előfordulását. A Specifikáció elektronikus változatában a kiemelt szöveg egyben hiperhivatkozás is a kifejezés meghatározására: a Ctrl+kattintás kombinációval a meghatározásra ugorhatunk, majd egy újabb Ctrl+kattintás a meghatározásról visszavisz az eredeti szövegbeli előforduláshoz.
2.5. ábra
3.
BESOROLÁSI SÉMÁK ÉS AZ IRATOK RENDSZEREZÉSE
Ez a fejezet a besorolási sémával és a dossziék rendszerezésével kapcsolatos követelményeket foglalja össze. A 3.1. szakasz tartalmazza a besorolási séma kialakításának követelményeit. Az osztályokra és dossziékra vonatkozó követelmények a 3.2., a kötetekkel és aldossziékkal szemben támasztott elvárások pedig a 3.3. szakaszban olvashatók. A 3.4. szakasz a besorolási séma karbantartásával kapcsolatos követelményeket részletezi. Minden EIKR alapja a besorolási séma: ez teszi lehetővé az elektronikus iratok tárolását a velük összefüggő más iratokkal, meghatározza, hogy milyen elvek szerint szervezzék az iratokat elektronikus dossziékba (ügyiratokba), és rögzíti a dossziék (ügyiratok) közötti kapcsolatokat. Lényeges különbség a MoReq2 és elődje között, hogy a MoReq2 megengedi az iratok közvetlen hozzárendelését egy osztályhoz. A MoReq első változatában csak dossziékhoz lehetett iratot rendelni, osztályokhoz nem. A MoReq2 szerint a következőkbe lehet közvetlenül iratot iktatni: osztály; dosszié; aldosszié; kötet. Az iratokat leggyakrabban kötetekbe iktatják; a 3.3.1, 3.3.2 és 3.3.3 pontokból kiderül, mikor érdemes dossziékban és aldossziékban elhelyezni az iratokat. A változtatással a MoReq2 a nagy mennyiségű iratokat kezelő ügyviteli rendszerek igényeihez alkalmazkodik. A kötetek népszerűsége azonban nem indokolja a hierarchikus besorolási sémák vagy a dossziék mellőzését. A helytelen kötethasználat megnehezíti az iratkezelést, ezért a MoReq2 felhasználóinak azt tanácsoljuk, hogy körültekintően járjanak el a kötetek alkalmazásakor. A legtöbb MoReq2 felhasználó valószínűleg nem veszi hasznát a köteteknek, ezért a Specifikáció egyik követelménye kimondja, hogy a funkció igény szerint kikapcsolható. A MoReq2-megfelelőség egyik előfeltétele a hierarchikus besorolási sémák támogatása. A hierarchikus sémák mellett szólnak az alábbi érvek: a hierarchikus sémák hatékony, megbízható és átlátható rendszerbe szervezik az iratokat; Európában a hierarchikus sémák a legelterjedtebbek. A hierarchikus sémák használatának előírása kompatibilis a MoReq első változatával. Számos követelmény épít az osztály fogalomra: ezek a követelmények olykor összeegyeztethetők a nem hierarchikus besorolási sémákkal, de ez nem minden esetben lehetséges.
Nagyon fontos, hogy a besorolási séma összhangban legyen a szervezet üzleti igényeivel. A gyakorlatban az vált be, hogy a szervezet előbb elkészíti az üzleti besorolási sémát, és csak azután alakítja ki az iratkezelésre vonatkozó besorolási sémát.
3.1. Hiv. 3.1.1.
A besorolási séma konfigurálása Követelmény
Köt. Teszt
Az EIKR-nek támogatnia kell a szervezet üzleti besorolási sémáját, és kompatibilisnek kell lennie azzal.
Igen
Nem
Igen
Rész ben
(a) Az EIKR-nek lehetővé kell tennie az adminisztrátori szerepkört betöltők számára, hogy Címet és Leírást kapcsolhassanak a besorolási sémához.
Nem
Igen
(b) Az EIKR-nek automatikusan Azonosítót kell rendelnie a besorolási sémákhoz.
Igen
Igen
Igen
Igen
Igen
Igen
Ez a követelmény rendszerint nem tesztelhető, pusztán emlékeztetőként szerepel a követelmények élén, hogy a MoReq2 felhasználói ne tévesszék szem elől: az EIKR által támogatott besorolási sémát össze kell hangolni a szervezet üzleti igényeivel. Az üzleti igényeket az EIKR-en kívül tárolt iratok elrendezése is tükrözi. 3.1.2.
Az EIKR-nek minden időben meg kell őriznie belső integritását az alábbi tényezőktől függetlenül: karbantartási tevékenységek; egyéb felhasználói tevékenységek; a rendszerösszetevők meghibásodása. Másképp fogalmazva: nem megengedhető, hogy az EIKR vagy a hozzá kapcsolódó adatbázisok inkonzisztens állapotba kerüljenek felhasználói tevékenység vagy szoftverhiba következtében.
3.1.3.
Ezek a metaadatok a besorolási sémák exportálását segítik. 3.1.4.
Az EIKR által támogatott besorolási sémának osztályok hierarchiájába szervezve kell ábrázolnia a dossziékat és az iratokat. A hierarchikus besorolási sémák támogatása a MoReq2-megfelelés egyik alapvető feltétele. A hierarchiák lehetővé teszik a megőrzési és selejtezési ütemtervek és egyéb metaadatok öröklődését, emellett pedig könnyítik a navigálást az osztályok mentén. Az EIKR-nek legalább háromszintű hierarchiát kell támogatnia, a legtöbb szervezetnek azonban ennél több szintre lesz szüksége.
3.1.5.
Az EIKR csak adminisztrátori szerepkörnek engedélyezheti a besorolási séma kezelését (vö. 3.1.6.). „Kezelésen” a 3.1. és 3.4. szakaszban meghatározott műveletek értendők.
Hiv. 3.1.6.
Követelmény
Köt. Teszt
Az EIKR-nek lehetővé kell tennie, hogy a hierarchia egyes osztályait meghatározott felhasználói szerepkörök és/vagy felhasználók egy meghatározott csoportja kezelhesse.
Nem
Igen
Nem
Rész ben
Igen
Igen
A „kezelés” kifejezés ennél a követelménynél követelményben használt értelmezéssel.
azonos
a
3.1.5.
A követelményt két esetben indokolt megvalósítani: olyan nagyméretű besorolási sémák esetén, amelyek terjedelmüknél fogva központilag nem karbantarthatók (ilyenkor a magasabb szinteket központilag, az alacsonyabb szinteket pedig helyileg kezelik); olyan besorolási sémák esetén, amelyek külön osztályokba szervezve ügyiratokat is tartalmaznak, ezek kezelése az ügyben illetékes üzleti részleg meghatalmazott felhasználójának kiváltsága. 3.1.7.
Az EIKR nem korlátozhatja a besorolási séma hierarchiájában a szintek számát. Ugyanakkor valószínűtlen, hogy tíznél több szintre lenne szüksége bármelyik felhasználónak is.
3.1.8.
Az EIKR-nek már a rendszer konfigurálásakor támogatnia kell a besorolási séma létrehozását, hogy mihamarabb készen álljon az elektronikus iratok iktatására és/vagy importálására. A követelmény célja, hogy azelőtt készüljön el egy besorolási séma, mielőtt még iratkezelésre kezdenék használni a rendszert.
3.1.9.
Az EIKR-nek lehetővé kell tennie, hogy egy adminisztrátori szerepkört betöltő személy már a rendszer konfigurálásakor meghatározhassa a címzési mechanizmus(oka)t.
Igen
Igen
3.1.10.
Az EIKR-nek engedélyeznie kell, hogy bármely osztályhoz, dossziéhoz, aldossziéhoz és kötethez szöveges hatásköri megjegyzést, más szóval leírást lehessen fűzni.
Nem
Igen
A hatásköri megjegyzések leíró jellegűek, céljuk, hogy tisztázzák az osztályok, dossziék, aldossziék és kötetek javasolt tartalmát és kivételeit, a felhasználók munkáját könnyítendő.
Követelmény
Köt. Teszt
3.1.11.
Ha megjelenik a hivatalos MoReq2 XML séma, az EIKR-nek képesnek kell lennie a sémának megfelelő formában iratokat importálni és exportálni.
Igen
Igen
3.1.12.
Az EIKR-nek támogatnia kell a teljes besorolási séma vagy a séma bizonyos részeinek az importálását mind a konfiguráció során, mind később.
Igen
Igen
Igen
Igen
Igen
Igen
Igen
Rész ben
Hiv.
A követelmény célja, hogy a besorolási sémát az EIKR konfigurálása során is ki lehessen alakítani, mielőtt még a rendszert iratkezelésre használnák. A nem teljes, azaz részben importált sémákat fel lehet használni a meglévő séma bővítésére, de akár új besorolási sémaként is kezelhetők, amennyiben a rendszerben korábban nem hoztak létre sémát. 3.1.13.
A besorolási sémák teljes vagy részleges importálásakor az EIKR-nek lehetővé kell tennie a besorolási sémához kapcsolódó metaadatok, a megőrzési és selejtezési ütemtervek, illetve az eseménynapló importálását is, amennyiben azok elérhetők. Ideális esetben az importált besorolási sémához megfelelő osztály-leíró metaadatok, valamint megőrzési és selejtezési ütemtervek tartoznak. Más esetben ezek teljes mértékben hiányoznak, vagy a rendelkezésre álló adatok nem teljesek.
3.1.14.
Ha az EIKR a besorolási séma metaadatait is importálja, vissza kell utasítania azokat az osztályokat, amelyeknek nincs címe. A rendszernek hibajelentést kell készítenie egy adminisztrátori szerepkör részére, a jelentésben fel kell sorolni a visszautasított osztályokat. A MoReq2-vel nem kompatibilis EIKR-eknél előfordulhat, hogy nem minden osztályt látnak el címmel (helyette a null érték szerepel). Ilyen eset teljességgel kizárt a MoReq2-kompatibilis iratkezelő rendszerekben.
3.1.15.
Ha az EIKR a besorolási séma metaadatait is importálja, kötelező minden egyes importált osztályhoz hozzárendelnie egy hierarchia-kódszámot az alábbi módok egyike szerint (a választást egy adminisztrátori szerepkör által módosítható beállítás határozza meg): a besorolási sémák manuális létrehozásakor követendő szabályok alapján; az eredeti kódokat teljes mértékben megtartva (csak egymással kompatibilis hierarchikus struktúrák esetén lehetséges); az eredeti kódokat a befogadó séma kódjainak végéhez fűzve. Az importált hierarchiában esetlegesen előforduló hierarchikus osztálykódok (pl. 4/6/4) nem minden esetben használhatók fel a befogadó sémában, mivel az EIKR nem tudja garantálni a kódok konzisztenciáját és egyediségét. A meglévő kódok importálása különféle forgatókönyvek szerint történhet, igen gyakori azonban a hierarchikus számozási módok jelentős eltérése. A MoReq2 nem írja elő, hogy mi a kimenete annak a logikailag helytelen választásnak, amikor a sémák nem kompatibilisek egymással.
Hiv.
Követelmény
Köt. Teszt
Amennyiben az importált sémakódok használhatatlanok, sorsuk az adott helyzettől függ, felvehetők például metaadatként „régi kód” néven. 3.1.16.
Ha az EIKR a besorolási séma metaadatain túl a megőrzési és selejtezési ütemterveket is importálja, ugyanazokkal a szabályokkal kell validálnia azokat, mint amelyek a besorolási sémák manuális létrehozására érvényesek (lásd 12. fejezet). Amennyiben a validálási folyamat hibát észlel (kötelező metaadatok hiányoznak, hibás a formátum stb.), figyelmeztetnie kell az importálásért felelős adminisztrátori szerepkört, az érintett metaadatokat azonosítva. Ideális esetben az importált besorolási séma metaadatai (pl. az osztályok metaadatai) teljes mértékben megfelelnek a MoReq2 metaadat-modelljének. Azokban az egyéb esetekben, amikor a metaadatok nem felelnek meg a modellnek, a MoReq2 nem ír elő egyetlen konkrét kimenetet, hanem az alábbi lehetőségeket javasolja: A teljes importálás meghiúsul, a rendszer tájékoztatja az adminisztrátori szerepkört a törlés okáról; A nem megfelelő metaadatokkal ellátott osztályok importálása meghiúsul, a rendszer tájékoztatja az adminisztrátori szerepkört a törlés okáról; Az adminisztrátori szerepkör feladata, hogy válasszon a hiba kijavítása és az érintett osztály importálásának törlése közül; Az importálás végbemegy a részben helytelen metaadatok ellenére is, a nem megfelelő metaadatokat a rendszer az érintett elemeknél előírt alapértelmezett értékekkel írja felül, azokról hibajelentést készít. Az adminisztrátori szerepkör értesítéséből nem következik, hogy az importálást egy előtérben vagy valós időben futó folyamat végzi; erre a feladatra egy háttér- vagy kötegelt folyamat is alkalmas.
Igen
Igen
Követelmény
Köt. Teszt
3.1.17.
Az EIKR-nek támogatnia kell egy teljes besorolási séma vagy a séma bizonyos részeinek az exportálását.
Nem
Igen
3.1.18.
Amennyiben az EIKR támogatja a besorolási sémák teljes vagy részleges exportálását, az exportálásnak tartalmaznia kell a kapcsolódó metaadatokat is. Az exportálásra kerülő metaadatok kiválasztása egy adminisztrátori szerepkör feladata.
Igen
Igen
3.1.19.
Amennyiben az EIKR támogatja a besorolási sémák teljes vagy részleges exportálását, az exportálásnak tartalmaznia kell az összes kapcsolódó megőrzési és selejtezési ütemtervet is egy adminisztrátori szerepkör döntésétől függően.
Igen
Igen
3.1.20.
Amennyiben az EIKR támogatja a besorolási sémák teljes vagy részleges exportálását, az exportálásnak tartalmaznia kell a kapcsolódó eseménynaplót is részben vagy egészben egy adminisztrátori szerepkör döntésétől függően.
Igen
Igen
3.1.21.
Amennyiben az EIKR támogatja az exportálást (a fenti követelmények bármelyikére), pontosan dokumentált módszer szerint kell összekapcsolnia az elemeket.
Igen
Igen
Hiv.
A módszer dokumentációjának ki kell térnie az iratok, dossziék, osztályok stb. és a közöttük lévő kapcsolatok jelöléseinek magyarázatára. Lásd még 3.1.22. 3.1.22.
Amennyiben az EIKR támogatja az exportálást (a fenti követelmények bármelyikére), az adatokat XML vagy egy azzal egyenértékű nyílt szabványos formátumba kell exportálnia.
Nem
Igen
3.1.23.
Amennyiben az EIKR támogatja a besorolási sémák teljes vagy részleges másolását, a másolásnak tartalmaznia kell a kapcsolódó metaadatokat.
Igen
Igen
3.1.24.
Amennyiben az EIKR támogatja a besorolási sémák teljes vagy részleges másolását, a másolásnak tartalmaznia kell az összes kapcsolódó megőrzési és selejtezési ütemtervet.
Igen
Igen
3.1.25.
Az EIKR-nek lehetővé kell tennie, hogy az adminisztrátori szerepkört betöltő személyek új osztályokkal bővíthessék a hierarchia tetszőleges osztályát, feltéve, hogy az üres, azaz nem tartalmaz dossziékat és iratokat.
Igen
Igen
A MoReq2 nem engedi, hogy egy osztály gyerekei között dossziék és osztályok keveredjenek (más szóval, dossziék és osztályok nem kapcsolódhatnak egyszerre ugyanahhoz a csomóponthoz a hierarchiában). Ez a bevált iratkezelési gyakorlat elveit tükrözi.
Hiv. 3.1.26.
Követelmény
Köt. Teszt
Az EIKR-nek több besorolási séma létrehozását és párhuzamos használatát kell támogatnia.
Nem
Igen
A legtöbb szervezet várhatóan egyetlen besorolási sémát fog használni az EIKR-ben rögzített iratok elsődleges rendszerezésére. Ez a követelmény azonban lehetőséget ad arra, hogy a dossziék egy részét az egyik besorolási sémába, másik részét pedig egy másik sémába lehessen elhelyezni. Erre például két szervezet egyesítése után lehet szükség, vagy olyan helyzetekben, amikor az egyes iratgyűjteményekre nagymértékben eltérő kezelési elvek vonatkoznak.
3.2.
Osztályok és dossziék
Ez a szakasz az osztályok követelményeket írja le.
és
dossziék
rendszerezésével
szemben
támasztott
Az osztályok és a dossziék eltérő célokat szolgálnak. Míg az osztályok a besorolás kereteit határozzák meg, a dossziék összefogják az iratokat; az osztályok a besorolási sémák építőkockái, a dossziék nem. Mindezen éles különbségek ellenére hasznosnak találtuk, hogy a két egyedtípusra vonatkozó közös követelményeket külön szakaszban emeljük ki. Követelmény
Köt.
Teszt
3.2.1.
Az EIKR-nek támogatnia kell a besorolási sémához tartozó osztályok és dossziék metaadatainak a rögzítését, karbantartását és megjelenítését a MoReq2 metaadat-modelljének megfelelően.
Igen
Igen
3.2.2.
Az EIKR-nek korlátoznia kell az osztályokhoz és dossziékhoz kapcsolódó metaadatok bővítésének lehetőségét a MoReq2 metaadatmodelljében foglaltak szerint.
Igen
Nem
3.2.3.
Az EIKR-nek biztosítania kell, hogy a besorolási sémához tartozó összes osztály, dosszié, aldosszié és kötet automatikusan hierarchikus besorolási kódot kapjon (amennyiben nem rendelkezik ilyennel, vö. 3.1.15).
Igen
Igen
Igen
Igen
Hiv.
Lásd még 7.1.1. 3.2.4.
Az EIKR-nek lehetővé kell tennie, hogy a felhasználói szerepkörök címeket rendelhessenek minden egyes elektronikus osztályhoz, dossziéhoz, aldossziéhoz és kötethez. Ez a követelmény a nem ügyirati környezetekre vonatkozik. Az ügyiratok kezelése más elnevezési megközelítést kíván, melyet a 10.5. szakasz részletez.
Követelmény
Köt.
Teszt
3.2.5.
Egyaránt lehessen besorolási kódot és szöveges címet használni, külön-külön vagy együtt.
Igen
Igen
3.2.6.
Az EIKR-nek lehetővé kell tennie, hogy egy adminisztrátori szerepkör a rendszer konfigurálásakor vagy később beállítsa a besorolási kódokat.
Igen
Igen
3.2.7.
Az EIKR-nek lehetővé kell tennie a besorolási kód konfigurálása során az alábbiak rögzítését:
Nem
Igen
Igen
Igen
Igen
Igen
Hiv.
a hierarchia egyes szintjeire vonatkozó azonosítók formátumát, például numerikus, alfanumerikus; minden osztály azonosítójának az első értékét, például 1, 1000; az egymást követő osztályok közötti intervallumokat, például 1, 10; a vezető 0-k jelenlétét vagy hiányát; tetszőleges általános előtagot, például „vállalati/”; tetszőleges általános azonosítókódját;
kiterjesztést,
például
az
ország
az azonosítók közötti elválasztójeleket, például „/”, „-”. 3.2.8.
Az EIKR-nek rögzítenie kell az osztályok és a dossziék megnyitásának és lezárásának a dátumát az osztály vagy a dosszié metaadatai között. Az osztály vagy dosszié megnyitásának és lezárásának a dátuma fontos meghatározója a benne tárolt iratoknak. Lásd 3.3.9. Amikor egy osztályt vagy dossziét megnyitnak, lehet bele iratot iktatni. Miután az osztályt vagy a dossziét lezárják, nem lehet bele iratot iktatni.
3.2.9.
Az EIKR-nek tárolnia kell az újonnan létrehozott osztályok, dossziék, aldossziék és kötetek létrehozási dátumát az osztály vagy a dosszié metaadatai között. Fizikai dossziéknál előfordulhat, hogy a megnyitás dátuma megelőzi az EIKR-ben tárolt létrehozás időpontját. Ez akkor lehetséges, ha a fizikai dossziét még azelőtt létrehozzák és megnyitják a valóságban, hogy az EIKR-ben jeleznék a létrehozását. Elektronikus dossziéknál előfordulhat, hogy a megnyitás dátuma megelőzi az EIKR-ben tárolt létrehozás időpontját. Ez akkor lehetséges, ha az elektronikus dossziét egy másik iratkezelő rendszerből importálták.
Hiv. 3.2.10.
Követelmény
Köt.
Teszt
Az EIKR köteles az újonnan létrehozott osztályok és dossziék metaadatai közé automatikusan felvenni a besorolási sémában elfoglalt helyzetükből származó jellemzőket.
Igen
Igen
Igen
Igen
Tegyük fel, hogy létezik egy „Nyilvános értekezletek” nevű dosszié az alábbi hierarchikus útvonal végén: Területi tervfejlesztés: Nyilvános konzultációk: Nyilvános értekezletek. Amennyiben egy adminisztrátori szerepkört betöltő személy felveszi az „Írásbeli konzultációk” nevű dossziét a „Nyilvános értekezletek”-kel azonos szinten, az új dosszié automatikusan örökli a Területi tervfejlesztés: Nyilvános konzultációk előtagot. Megjegyzendő, hogy magukat az örökölt metaadatokat nem szükséges ténylegesen tárolni, részletek a 9.3. függelékben. 3.2.11.
Az EIKR-nek lehetővé kell tennie, hogy egy adminisztrátori szerepkör megváltoztathassa az örökölt metaadatok értékét a MoReq2 metaadatmodelljében engedélyezett mértékig. Az örökölt értékek gyakran kiindulási pontként szolgálnak, ezért értékük felülírható, feltéve, hogy a változtatások kompatibilisek a MoReq2 metaadat-modelljével.
3.2.12.
Egy osztály örökölt metaadatainak a bővítését örökölnie kell a leszármazott osztályoknak és dossziéknak.
Nem
Igen
3.2.13.
Az EIKR-nek támogatnia kell az ISO 2788 (magyar tezaurusz esetén az MSZ 3418) szabványnak megfelelő kötött szótárak (tezauruszok) kifejezéseinek (deszkriptorainak) felvételét az osztályok és dossziék metaadatai közé tárgyszóként.
Nem
Igen
3.2.14.
Az EIKR-nek támogatnia kell az ISO 5964 szabványnak megfelelő kötött szótárak (tezauruszok) kifejezéseinek (deszkriptorainak) felvételét az osztályok és dossziék metaadatai közé tárgyszóként.
Nem
Igen
A 3.2.13 és 3.2.14 pontban megfogalmazott követelmények megegyeznek azzal a különbséggel, hogy míg előbbi egynyelvű, utóbbi kétnyelvű szótárak használatát írja elő.
Követelmény
Köt.
Teszt
3.2.15.
Az EIKR nem szabhat gyakorlati korlátot a rendszerben létrehozható osztályok és dossziék számát illetően.
Igen
Rész ben
3.2.16.
Az EIKR-nek tudnia kell felsorolást, avagy jegyzéket készíteni a rendszerben tárolt összes, vagy egy adott osztály (és annak leszármazottai) alá sorolt dossziéról XML és/vagy ember által értelmezhető formátumban.
Nem
Rész ben
3.2.17.
Az EIKR-nek lehetővé kell tennie, hogy egy adminisztrátori szerepkör konkrét osztályra vonatkozóan meghatározhassa, hogy az adott osztály tárolhat-e közvetlenül iratokat.
Igen
Igen
Hiv.
Más szóval a rendszernek rendelkeznie kell olyan beállítással, amely meghatározza, hogy az iratokat kötelező-e dossziékban, aldossziékban vagy kötetekben tárolni.
3.3.
Kötetek és aldossziék
Az olyan rendszerekben, ahol papíralapú iratokat tárolnak, a nagyméretű dossziék felosztása kisebb részekre ergonómiai szempontból és az iratlefűzők, mappák stb. élettartama szempontjából is létfontosságú. A papíralapú dossziék vastagsága a kötetekre bontásnak köszönhetően rendszerint nem haladja meg a 2 cm-t. Amikor a dosszié (valójában a dosszié első kötete, annak ellenére, hogy dossziénak hívják) eléri a méretbeli korlátot – példánkban a 2 cm-t –, lezárják az aktuális kötetet, és helyette újat nyitnak. Mindez nem érvényes az elektronikus dossziékra: egy elektronikus dosszié méretének növekedése nem okoz különösebb problémát. A gyakorlatban azonban úgy tűnik, az elektronikus dossziékat is érdemes kötetekre bontani. Többek közt az alábbi helyzetekben előnyös az elektronikus dossziék felosztása: amikor a felhasználók távmunkában dolgoznak (kis sávszélességű kapcsolat esetén gondot okoz a dossziéba foglalt összes irat letöltése; a dosszié kis tárolóképességű adathordozón nem fér el); amikor a dossziékat nem zárják le, mert (például) egy adott földrajzi terület időben folytonos iratainak tárolására használják. Az előbbiekhez hasonlóan gyakori a papíralapú dossziék felosztása aldossziékra (különösen az ügyviteli környezetekben, ahol az ügyiratokat ügyiratdarabokra szokás osztani). Az aldossziékat rendszerint a dokumentumtípusok mentén alakítják ki. Ennek megfelelően az elektronikus dossziékat is érdemes lehet aldossziékra bontani, mivel könnyítik az eligazodást a dosszién belül; lehetővé teszik, hogy a dossziéhoz tartozó iratokra eltérő megőrzési követelmények legyenek érvényben (a számlák megőrzését például törvényi előírás szabályozza). Ebben a szakaszban a kötetekre és aldossziékra vonatkozó követelményeket csoportosítottuk. A két egyedtípusban közös, hogy az egyébként kezelhetetlen nagyságú dossziék felosztását szolgálják. A MoReq2 nem írja elő a részekre bontás
implementációjának módját, pusztán annyit vár el, hogy a Specifikációval kompatibilis szoftverek a felhasználó igényei szerint képesek legyenek a felosztásokat kezelni. A MoReq előző verziója nem ismerte az aldosszié fogalmát. Röviden összefoglalva: Minden dosszié felosztható egy vagy több aldossziéra; Minden aldosszié felosztható egy vagy több kötetre; A különböző aldossziék kötetei egymástól függetlenek; Egy nyitott dossziéhoz tartozó aldossziék lehetnek nyitottak vagy zártak a felhasználók igényeinek megfelelően; Egy aldossziéban csak egy kötet lehet egyszerre megnyitva. Az aldossziék és kötetek további leírását lásd a 2.2. szakaszban. Követelmény
Köt.
Teszt
3.3.1.
Az EIKR-nek lehetővé kell tennie, hogy egy adminisztrátori szerepkör a rendszer konfigurálásakor vagy későbbi időpontban letilthassa a besorolási sémában lévő dossziék aldossziékra és/vagy kötetekre bontásának lehetőségét.
Igen
Igen
3.3.2.
Az EIKR-nek lehetővé kell tennie, hogy egy adminisztrátori szerepkör a rendszer konfigurálásakor vagy későbbi időpontban a besorolási séma meghatározott osztályaihoz tartozó meghatározott dossziéknak csak az aldossziékra bontását engedélyezze.
Igen
Igen
3.3.3.
Az EIKR-nek lehetővé kell tennie, hogy egy adminisztrátori szerepkör a rendszer konfigurálásakor vagy egy későbbi időpontban a besorolási séma meghatározott osztályaihoz tartozó meghatározott dossziéknak csak a kötetekre bontását engedélyezze.
Igen
Igen
Hiv.
Az előbbi három követelmény együttesen azt a célt szolgálja, hogy a szervezetek igényüknek megfelelően korlátozhassák a besorolási séma adott részeinek aldossziékra és kötetekre bontását. Az aldossziék és kötetek együttes használata nyújtja a legnagyobb fokú rugalmasságot, ezzel együtt viszont potenciálisan a legtöbb bonyodalmat és meg nem értést okozhatja a felhasználók körében. Amennyiben a besorolási séma adott részében engedélyezték az aldossziék használatát, az ott található dossziéknak kötelező legalább egy aldossziét tartalmazniuk. Amennyiben a besorolási séma adott részében engedélyezték a kötetek használatát, az ott található dossziéknak (vagy aldossziéknak, ha azokat engedélyezték) kötelező legalább egy kötetet tartalmazniuk.
Hiv.
Követelmény
Köt.
Teszt
Igen
Igen
A rendszer maradjon áttekinthető a végfelhasználó számára, azaz ha egy aldosszié egyetlen kötetből áll, a felhasználónak nem kell látnia a különbséget az aldosszié és a kötet között; ha egy dosszié egyetlen aldossziét tartalmaz, amely egyetlen kötetből áll, a felhasználónak nem kell látnia a különbséget a három szint között. Ennek az a célja, hogy az EIKR ne kényszerítse rá a felhasználóra fölöslegesen a „dosszié – aldosszié – kötet” szerkezetet. A rendszer tegye lehetővé az aldossziék és kötetek használatát, ugyanakkor hagyja, hogy a felhasználó a dossziék szintjén gondolkodjon, ha számára az a kényelmesebb. Fontos, hogy a felhasználó figyelmét ne tereljék el az üzleti folyamatok szempontjából lényeges elemekről az EIKR esetlegesen zavaró technikai részletei. 3.3.4.
Az EIKR-nek különbséget kell tennie nyitott és lezárt elektronikus kötetek között az alábbiak szerint: csak az aldosszié legfrissebb kötete lehet megnyitva; az aldosszié összes többi kötetének lezártnak kell lennie.
3.3.5.
Az EIKR nem engedheti meg, hogy a felhasználó lezárt kötetbe iktasson elektronikus iratot.
Igen
Igen
3.3.6.
Az EIKR-nek lehetővé kell tennie, hogy az adminisztrátori szerepkört betöltő személyek a nem lezárt elektronikus aldossziékba új elektronikus kötetet vehessenek fel.
Igen
Igen
Egy új kötet felvétele az aktuálisan nyitott kötet lezárásából és az új kötet megnyitásából áll. 3.3.7.
Az EIKR-nek lehetővé kell tennie, hogy az adminisztrátori szerepkört betöltő személyek a nem lezárt elektronikus dossziékba új elektronikus aldossziékat vehessenek fel.
Igen
Igen
3.3.8.
Az EIKR-nek lehetővé kell tennie, hogy a felhasználók bármikor lezárhassanak egy aldossziét.
Igen
Igen
3.3.9.
Az EIKR-nek rögzítenie kell az új kötet vagy aldosszié létrehozásának dátumát a kötet vagy aldosszié metaadatai között.
Igen
Igen
3.3.10.
Az EIKR-nek automatikusan be kell állítania az újonnan létrehozott kötet vagy aldosszié megnyitásakor azon metaadatok értékét, amelyek a szülő dosszié metaadataival közösek (a MoReq2 metaadatmodell előírásainak megfelelően).
Igen
Igen
A kötetben tárolt iratok hozzáférhetők függetlenül attól, hogy a kötet meg van nyitva vagy már lezárták.
Hiv. 3.3.11.
Követelmény
Köt.
Teszt
Az EIKR-nek minden újonnan létrehozott kötethez automatikusan azonosítót kell rendelnie, amely egyedi az őt tartalmazó aldosszién belül.
Igen
Rész ben
Az azonosító lehet a kötet sorszáma az aldosszién belül, amely minden egyes aldossziéban következetesen 1-gyel kezdődik. 3.3.12.
Az EIKR-nek rögzítenie kell az kötetek és aldossziék lezárásának dátumát azok metaadatai közt.
Igen
Igen
3.3.13.
Az iratok besorolásakor a rendszernek alapértelmezés szerint az aldosszié legújabb kötetét kell felkínálnia a felhasználó számára.
Igen
Igen
3.3.14.
Az EIKR-nek lehetővé kell tennie, hogy egy dosszién belül egyidejűleg több nyitott aldossziét is létre lehessen hozni.
Igen
Igen
3.3.15.
Az EIKR-nek lehetővé kell tennie egy adminisztrátori szerepkör számára, hogy üres kötetet törölhessen.
Igen
Igen
3.3.16.
Az EIKR-nek lehetővé kell tennie egy adminisztrátori szerepkör számára, hogy egyetlen lépésben törölhessen egy üres kötetet, és nyithassa meg az aldossziéban azt megelőző lezárt kötetet. Az esemény feljegyzésre kerül az eseménynaplóban.
Igen
Igen
Nem
Igen
Így könnyen orvosolható, ha a felhasználó véletlenül zárt le egy kötetet. 3.3.17.
Az EIKR-nek támogatnia kell „aldosszié-sablonok” létrehozását adott osztályhoz, amely meghatározza az osztályhoz ezután sorolt dossziék automatikusan kialakítandó szerkezetét. A sablonok létrehozása egy adminisztrátori szerepkör feladata. Ez a követelmény főként az ügyviteli környezetek igényeit veszi figyelembe. Egy biztosítótársaság előírhatja például, hogy az ügyfél-biztosítási szabályzatokkal foglalkozó osztályba sorolt dossziék a következő aldossziékra legyenek lebontva: szabályzatok és kiegészítések, belső levelezés, orvos szakértőkkel folytatott levelezés, számlák, ügyfelekkel folytatott levelezés. Ezt követően az osztályhoz újonnan sorolt dossziékban a rendszer automatikusan létrehozza az előbb felsorolt aldossziékat.
3.3.18.
Az EIKR-nek automatikusan le kell zárnia a nyitott aldossziékat a szülő dosszié lezárásakor.
Igen
Igen
3.3.19.
Az EIKR-nek lehetővé kell tennie a felhasználók számára a kötetek egyenkénti lezárását.
Igen
Igen
3.4.
A besorolási séma karbantartása
A szakasz először az osztályok áthelyezésére, egyesítésére, felosztására és másolására vonatkozó követelményeket ismerteti (3.4.1-3.4.4.). Ezek a követelmények az olyan kivételes eseteket fedik le, mint két szervezet egyesítése vagy átszervezése, irodai hibák javítása, vagy a besorolási séma átszerkesztése, ha az nincs összhangban a szervezet üzleti modelljével. Hétköznapi használatuk nem javasolt, mivel jól átgondolt és megtervezett besorolási sémák megléte mellett ezek a funkciók szükségtelenek. Az említett
követelményeket a 9.3.3. és 9.3.4. követelményekkel együtt kell értelmezni. A szakasz a besorolási séma karbantartásával szemben támasztott követelményekkel zárul (3.4.17-től kezdődően). Hiv. 3.4.1.
Követelmény Az EIKR-nek lehetővé kell tennie, hogy egy adminisztrátori szerepkör egyetlen művelettel áthelyezhessen egy osztályt a besorolási sémán belül.
Köv. Teszt Igen
Igen
Igen
Igen
Igen
Igen
Igen
Igen
Az „áthelyezés” ebben a szövegkörnyezetben az érintett osztály vagy dosszié átmozgatását jelenti a besorolási séma másik pontjára, amely a séma tetszőleges szintjén helyezkedhet el. Az áthelyezés számos következménnyel jár, ezeket a szakasz későbbi részében ismertetjük. 3.4.2.
Az EIKR-nek lehetővé kell tennie, hogy egy adminisztrátori szerepkör egyetlen művelettel egyesíthessen két osztályt. „Egyesítésen” az alábbi értendő: amennyiben egy osztályt egyesítenek egy másikkal, az előbbi osztály összes gyerekét és tartalmát áthelyezik a másik osztály gyerekei és tartalma közé; az előbbi osztályt lezárják.
3.4.3.
Az EIKR-nek lehetővé kell tennie, hogy egy adminisztrátori szerepkör egyetlen művelettel két osztályra oszthasson egy osztályt. „Felosztáson” az alábbi értendő: amennyiben egy osztályt felosztanak, egy új osztály jön létre a felosztandó osztály testvéreként, tehát vele azonos szinten, ugyanazon szülő közvetlen gyerekeként (az új osztály létrehozására vonatkozó követelmények, mint az örökölt metaadatok rögzítése itt is érvényesek); a felhasználó kijelöl egy pontot a felosztandó osztály tartalmán belül; a kijelölt ponton túl elhelyezkedő (nagyobb besorolási kóddal rendelkező) tartalmak áthelyezésre kerülnek az újonnan létrehozott osztályba. Az osztály tartalma magában foglalja az összes olyan egyedtípust, amely előfordulhat egy osztályban, tehát az osztályokat, dossziékat és az iratokat.
3.4.4.
Az EIKR-nek lehetővé kell tennie, hogy egy adminisztrátori szerepkör egyetlen művelettel másolhasson osztályt a besorolási sémán belül. „Másoláson” egy másolat készítését értjük az osztályról és annak tartalmáról a besorolási séma egy tetszőleges másik pontján úgy, hogy közben az eredeti osztály érintetlen marad. A másolás számos következménnyel jár, ezeket a szakasz későbbi részében ismertetjük.
Hiv.
Követelmény
Köv. Teszt
A funkció a besorolási séma ágainak replikálását (megkettőzését) támogatja. Erre a séma azon részeinek tervezésekor lehet szükség, amelyeket nem funkcionális alapokon alakítottak ki. Az egymást követő export és import műveletek megvalósítása nem könnyű ezeknek a funkcióknak az alkalmazása mellett. 3.4.5.
Osztályok áthelyezésekor vagy másolásakor az EIKR-nek biztosítania kell, hogy az újonnan áthelyezett vagy másolt dossziék és azok tartalma a besorolási sémán belüli új helynek megfelelő besorolási kódokat kapjon.
Igen
Igen
Igen
Igen
Ez annyit tesz, hogy minden áthelyezett vagy másolt osztálynak, dossziénak, aldossziénak, kötetnek, iratnak és állománynak új besorolási kódot és új teljesen minősített besorolási kódot kell kapnia. Az új kódok kiosztására ugyanazok a szabályok érvényesek, mint az újonnan létrehozott osztályok, dossziék, iratok stb. esetében. 3.4.6.
Az EIKR nem kötelezheti az osztályok áthelyezését, egyesítését, felosztását vagy másolását végző adminisztrátori szerepkört külön export és import feladatok végrehajtására. A követelmény a könnyű használhatóságot segíti; a felhasználóktól nem várható el, hogy egymástól logikailag független lépések sorozatán keresztül érjék el a kívánt eredményt.
Hiv. 3.4.7.
Követelmény Az EIKR nem engedélyezheti az olyan áthelyezési és másolási műveletek végrehajtását, amelynek következtében a MoReq2 adatmodellben (lásd 13.2. szakasz) implicit, vagy a mintakövetelményekben explicit módon meghatározott szabályok sérülnek. Nem engedélyezhető az áthelyezés, amennyiben:
Köv. Teszt Igen
Igen
a besorolási séma áthelyezési célként megjelölt részén letiltották az aldossziék vagy a kötetek használatát (lásd 3.3.1, 3.3.2, 3.3.3), az áthelyezendő osztály tartalma között azonban előfordulnak a korlátozás alá eső egyedtípusok; az áthelyezés következtében iratok kerülnének közvetlenül olyan osztály alá, amely dossziékat tartalmaz, vagy ennek fordítottja; az áthelyezés következtében dossziék kerülnének közvetlenül olyan osztály alá, amely osztályokat tartalmaz, vagy ennek fordítottja. 3.4.8.
Az EIKR-nek biztosítania kell, hogy az áthelyezés során az iratok megőrzik az osztályokon és/vagy dossziékon belül elfoglalt helyüket, illetve az aldossziék, kötetek és dossziék között fennálló kapcsolatok nem sérülnek.
Igen
Rész ben
3.4.9.
Az EIKR-nek biztosítania kell, hogy a másolás során az iratok megőrzik az osztályokon és/vagy dossziékon belül elfoglalt helyüket, illetve az aldossziék, kötetek és dossziék között fennálló kapcsolatok nem sérülnek.
Igen
Rész ben
3.4.10.
Az osztályok, dossziék, kötetek, aldossziék és iratok áthelyezésekor vagy átsorolásakor a korábban lezárt dossziéknak lezárt státuszban kell maradniuk, megőrizve a besorolási sémában előzőleg elfoglalt helyüknek megfelelő hivatkozásokat (besorolási kódokat).
Igen
Igen
3.4.11.
Az osztályok, dossziék, kötetek, aldossziék és iratok áthelyezésekor vagy átsorolásakor a nyitott dossziékat
Igen
Igen
Igen
Igen
le kell zárni, megőrizve a besorolási sémában előzőleg elfoglalt helyüknek megfelelő hivatkozásokat, a metaadatok közti utalással az új dossziéra a megváltozott besorolási sémában; vagy a megváltozott sémára kell hivatkoznia, megőrizve a metaadatok közt a besorolási sémára vonatkozó összes korábbi hivatkozást az áthelyezést végző adminisztrátori szerepkör döntésétől függően. 3.4.12.
Osztályok áthelyezésekor és másolásakor az EIKR-nek lehetővé kell tennie az osztályok és tartalmuk (vagy a megfelelő másolatok) metaadatainak átvételét az új szülő osztálytól. Az átvehető metaadatok közé tartoznak például a hozzáférési engedélyek és a biztonsági besorolás.
Hiv. 3.4.13.
Követelmény Osztályok áthelyezésekor és másolásakor az EIKR-nek lehetővé kell tennie, hogy az áthelyezett vagy átmásolt osztályok és tartalmuk átvehesse az új szülő osztályra érvényes megőrzési és selejtezési ütemterveket, a korábbi megőrzési és selejtezési ütemtervek mellett.
Köv. Teszt Igen
Igen
Igen
Igen
Ez a minimálisan elvárható funkcionalitás, az EIKR-ek ennél több lehetőséget is biztosíthatnak a megőrzési és selejtezési ütemtervek kezelésére vonatkozóan. Az új megőrzési és selejtezési ütemterv ütközhet a régivel, ilyen esetben az 5.1. szakaszban (azon belül is az 5.2.18. és 5.2.33. pontban) leírt módon kell eljárni. 3.4.14.
Osztályok áthelyezésekor és másolásakor az EIKR-nek köteleznie kell egy adminisztrátori szerepkört, hogy indokolja meg az áthelyezést vagy másolást. Az indoklás bekerül a metaadatok közé. Az indoklás azért kötelező, mert az áthelyezés és a másolás olyan kivételes műveletek, amelyek nagymértékben veszélyeztethetik az iratok integritását, ha szakszerűtlenül hajtják végre.
3.4.15.
Osztályok, dossziék és iratok áthelyezésekor és másolásakor az EIKR-nek naplóznia kell az egyedtípusok művelet előtti státuszát az eseménynaplóban.
Igen
Igen
3.4.16.
Osztályok áthelyezésekor az EIKR-nek naplóznia kell a metaadatok értékét az áthelyezést megelőzően.
Igen
Igen
Az előbbi két követelmény együttesen segít visszavezetni az áthelyezett iratok történetét. 3.4.17.
Az EIKR-nek lehetővé kell tennie, hogy egy adminisztrátori szerepkör inaktívnak jelölhessen meg osztályokat és dossziékat, aminek következtében az adott osztály vagy dosszié nem bővíthető új dossziékkal vagy iratokkal.
Nem
Igen
3.4.18.
Az EIKR-nek lehetővé kell tennie, hogy egy adminisztrátori szerepkör üres osztályt törölhessen.
Nem
Igen
3.4.19.
Az EIKR nem engedélyezheti az elektronikus dossziék vagy azok tartalmának teljes vagy részleges törlését.
Igen
Igen
Az alábbi két eset kivételével: a megőrzési és selejtezési ütemterv szerint előírt megsemmisítés során (lásd 5.2.25.); vagy dossziék és azok tartalmának törlése egy adminisztrátori szerepkör által egy felülvizsgálati folyamat keretein belül (lásd 9.3. szakasz).
Hiv. 3.4.20.
Követelmény Az EIKR-nek lehetővé kell tennie, hogy felhasználói szerepköröket betöltő személyek lezárhassanak elektronikus dossziékat.
Köv. Teszt Igen
Igen
Nem
Igen
Igen
Igen
A MoReq korábbi változata adminisztrátorokra korlátozta ezt a funkciót. 3.4.21.
Az EIKR zárja le automatikusan azokat az elektronikus köteteket, amelyekre teljesülnek a konfiguráció során beállított feltételek. Ily módon egy kötet automatikusan lezárható: éves fordulónapon (naptári, gazdasági vagy egyéb év zárásakor); egy meghatározott eseménytől számított adott idő elteltével (például a kötetbe legutóbb elhelyezett irat iktatásától számított 3 hónap elteltével); a kötetben tárolt iratok száma eléri a meghatározott korlátot. Bizonyos körülmények más feltételeket követelhetnek meg, például amikor a kötet mérete eléri egy cserélhető adathordozó tárolókapacitását.
3.4.22.
Az EIKR-nek ugyanolyan formában kell elérhetővé tennie a lezárt osztályok, dossziék, aldossziék és kötetek tartalmát, mint a nyitottakét. Más szóval, az információt kereső vagy böngésző felhasználó számára transzparens, hogy nyitott-e vagy lezárt-e az információt tartalmazó dosszié, kötet stb. A nyitott és lezárt dossziékra, aldossziékra stb. ugyanazok a keresési és hozzáférési szabályok vonatkoznak.
3.4.23.
Az EIKR-nek lehetővé kell tennie, hogy a felhasználók lásd még típusú kereszthivatkozásokat hozhassanak létre az egymáshoz kapcsolódó dossziék között.
Nem
Igen
3.4.24.
Az EIKR-nek lehetővé kell tennie, hogy egy elektronikus irat egyszerre több osztályhoz, dossziéhoz, aldossziéhoz vagy kötethez tartozhasson az irat vagy az alapjául szolgáló dokumentum megkettőzése nélkül.
Nem
Igen
Igen
Igen
A MoReq2 nem írja elő, hogy a követelményt miként kell megvalósítani. Kézenfekvő megoldás lehet a mutatók használata, amikor például egy adott dokumentumot többször is iktatnak. 3.4.25.
Az EIKR-nek jelentéskészítő eszközöket kell biztosítania, melyek a besorolási sémával kapcsolatos tevékenységekről készítenek statisztikát az illetékes adminisztrátori szerepkör által kiválasztott szempontok szerint, beleértve a megadott időintervallumon belül létrehozott, lezárt vagy törölt osztályok, dossziék, aldossziék, kötetek és iratok számát és méretét. A jelentést lehessen felhasználó és osztály szerint szűrni.
Követelmény
Köv. Teszt
3.4.26.
Az EIKR-nek lehetőséget kell biztosítania ad hoc jelentések készítésére a besorolási sémával kapcsolatos tevékenységek adott vonatkozásairól.
Nem
Rész ben
3.4.27.
Az osztályokkal, dossziékkal vagy iratokkal dolgozó felhasználók számára legyen megismerhető az érintett osztály, dosszié vagy irat környezete, azaz a hozzátartozó metaadatok és a szülő dosszié vagy osztály. A felhasználónak legyen lehetősége arra, hogy elérhesse az osztály, dosszié vagy irat szülőjét.
Igen
Igen
Hiv.
A felhasználónak ne kelljen kilépnie az adott osztályból vagy dossziéból a környezet megismeréséhez. A környezet megjelenítése ne zavarja a felhasználót a dosszién végzett munkájának folytatásában. 3.4.28.
Dossziét leíró tárgyszó módosítását csak egy adminisztrátori szerepkör indoklása mellett engedélyezheti az EIKR.
Igen
Igen
3.4.29.
Dossziét leíró tárgyszó módosításakor az EIKR-nek világosan rögzítenie kell a változtatás előtti státuszt, hogy a dosszié története könnyen visszavezethető legyen.
Igen
Igen
A tárgyszavak módosítására vonatkozó szabályok csökkentik a kockázatát annak, hogy iratokat lehessen elrejteni a tárgyszavak átírásával. Mivel a tárgyszavak alapvető szerepet játszanak az iratok kereséskor, változtatásaik nyomon követése elengedhetetlen, amennyiben meg szeretnénk akadályozni, hogy a felhasználó fontos iratot rejthessen el a tárgyszavak manipulálásával.
4.
ELLENŐRZÉS ÉS BIZTONSÁG
Ez a fejezet az iratok biztonsága szempontjából fontos ellenőrzésekre vonatkozó követelményeket tartalmazza. A követelmények az ISO 15489 szabvány 7.2. szakaszában megfogalmazott iratjellemzőket megvalósító funkciókat írják le. A szervezetek számára alapvető fontosságú, hogy szabályozzák, ki milyen iratokhoz férhet hozzá és milyen körülmények között, mivel az iratok személyes, pénzügyi vagy a szervezet működése szempontjából érzékeny adatokat tartalmazhatnak. A hozzáférési szabályokat gyakran a külső felhasználókra is ki kell terjeszteni. Egyes államokban például az információs szabadság jegyében az állampolgároknak joga van betekinteni a közérdekű iratokba. Az is előfordul, hogy a szervezetek megosztják az elektronikus irattáruk egy részét a partnerszervezetekkel. Az ilyen jellegű ellenőrzési eszközökre vonatkozó követelményeket a 4.1. szakasz foglalja össze. Az iratok hozzáférésének körülményeit és az iratokon, dokumentumokon és adatokon végzett összes tevékenységet rögzíteni kell az eseménynaplóban a jogi felelősség megállapítása és az adatok visszaállíthatósága érdekében. Az eseménynaplóból származó ellenőrzések követelményeit a 4.2. szakasz írja le. Gyakorlatilag ezek a követelmények biztosítják az iratok hitelességét és integritását az ISO 15489 szabvány 7.2. szakaszában foglaltaknak megfelelően. Az iratok biztonsága a rendszer hiba utáni helyreállási képességét is magában foglalja, melynek legfontosabb eszköze a biztonsági mentés. Az erre vonatkozó követelmények a 4.3. szakaszban találhatók. A követelmények biztosítják az iratok használhatóságát az ISO 15489 szabvány 7.2. szakaszában foglaltaknak megfelelően. A 4.4. szakasz a kiemelt iratok védelmének követelményeit részletezi. A kiemelt iratok olyan iratok, melyek helyreállítása az esetleges rendszerhiba után elsődleges.
4.1.
Hozzáférés-korlátozás
A szervezetek érdeke, hogy ellenőrzésük alatt tartsák az iratok hozzáférését, melynek leggyakoribb módja biztonsági előírások megfogalmazása és betartása. Biztonsági előírás például, ha egy alkalmazott csak a szervezetnél betöltött üzleti szerepe alapján engedélyezett iratokhoz férhet hozzá. A felhasználók jogosultságait rendszerint központilag szabályozzák, ezen belül egyszerre több vállalati rendszerhez kaphatnak különböző szintű hozzáférést, többek között az iratkezelő rendszerhez is. Az iratkezelő rendszerben nem célszerű az engedélyeket egyéni felhasználók és iratok kapcsolataként megfogalmazni. A hozzáférési jogokat általában szerepkörökhöz és/vagy felhasználócsoportokhoz kötik, melynek tagjai a séma meghatározott osztályaiba és dossziéiba tartozó iratokhoz kaphatnak hozzáférési és mentési jogokat. Azon túl, hogy a felhasználók korlátozott mértékben férhetnek hozzá a besorolási séma részeihez, az engedélyek a felhasználók, szerepkörök és felhasználócsoportok által az EIKR-ben tárolt egyedeken elvégezhető tevékenységeket is szabályozzák. Engedélyhez köthető például az EIKR-ben tárolt egyedek módosítása, törlése, tartalmának és metaadatainak megtekintése, vagy egy adott típusú egyed létrehozása és megjelenítése. Adott felhasználói szerepkörnek például joga van iratokat keresni és azokat elolvasni, de jogát csak a besorolási séma adott részében tárolt iratokon gyakorolhatja.
A felhasználócsoport engedélyeit a csoporttagok automatikusan megkapják. Az engedélyeket javasolt csoportokhoz kötni az egyéni felhasználók helyett, hosszútávon ugyanis egyszerűsíti a rendszer kezelhetőségét, valahányszor új felhasználók érkeznek, vagy korábbi felhasználók távoznak. A szerepköröknek köszönhetően a felhasználók és a felhasználócsoportok egyidejűleg több különböző engedéllyel is rendelkezhetnek az EIKR-ben. Később, ha a felhasználótól vagy a felhasználócsoporttól megvonnak egy szerepkört, az azzal járó engedélyeket is automatikusan elveszi a rendszer. Az EIKR-nek a hozzáférési jogok beállítását szerepkörhöz kell kötnie. A 13.4. táblázat értelmében ez a feladat az adminisztrátori szerepkörök hatáskörébe tartozik. Megjegyzendő azonban, hogy a rendszer szemszögéből nézve az adminisztrátori szerepkört betöltők csak megvalósítják a felső vezetés által rögzített biztonsági irányelveket, azokról nem döntenek. A biztonsági irányelvek és az engedélyek felhasználókhoz rendelése általában az iratok elérése iránti igénytől, a szervezet iratkezelési gyakorlatától, a vonatkozó jogszabályoktól és törvényi előírásoktól (pl. adatvédelmi törvény, levéltári törvény, ipari szabályozások stb.) függ, lásd 11.5. szakasz. Egyes környezetekben az iratkezelő rendszerre vonatkozó engedélyeket teljes egészében az EIKR-en belül kezelik, míg máshol az engedélyek felügyeletéért egy külön szoftver felel, például egy hálózati segédprogram. Az alábbiakban felsorolt követelményeknek mindkét megoldás eleget tesz. A most következő szerepkörök ismertetése csak irányadó. A valóságban a szervezet igényei határozzák meg a szerepkörök számát és összetételét, sőt, olyan eset is előfordulhat, hogy a szervezet nem igényli a szerepkörök használatát. Hiv. 4.1.1.
Követelmény
Köt. Teszt
Az EIKR semmilyen tevékenység végrehajtását nem engedélyezheti a felhasználó sikeres azonosítását és hitelesítését megelőzően.
Igen
A MoReq2 nem írja elő a hitelesítéshez használt módszert. A legtöbb szervezet igényeit kielégíti a felhasználónév és jelszó alapú hitelesítés. A szigorúan bizalmas adatokkal dolgozó szervezeteknek azonban érdemes megfontolniuk egy nagyobb védettségi szintet nyújtó hitelesítési mechanizmus bevezetését.
Igen
Követelmény
Köt. Teszt
4.1.2.
Az EIKR-nek lehetőséget kell biztosítania az adminisztrátori szerepkört betöltők számára, hogy az egyes iratok, aldossziék, dossziék, osztályok és metaadatok elérését felhasználók, felhasználói szerepkörök és felhasználócsoportok szerint korlátozhassák egy meghatározott időintervallumra vonatkozóan.
Igen
Igen
4.1.3.
Az EIKR nem korlátozhatja a rendszerben létrehozható szerepkörök és felhasználócsoportok számát.
Igen
Rész ben
4.1.4.
Az EIKR-nek lehetővé kell tennie, hogy az adminisztrátori szerepkörök kezelhessék az összes szerepkör és felhasználócsoport engedélyeit, beleértve a szerepkörök és felhasználócsoportok számára hozzáférhető funkciók, metaadat-elemek, iratok és dossziék körét és jellegét.
Igen
Igen
4.1.5.
Az EIKR-nek lehetővé kell tennie, hogy az adminisztrátori szerepkörök engedélyhez köthessék:
Igen
Rész ben
Hiv.
az egyes dossziék és iratok hozzáférhetőségét; a besorolási séma egyes osztályainak a hozzáférhetőségét; a felhasználó számára hozzáférhető egyedek körét a felhasználó megbízhatósági bizonyítványa alapján; a rendszer funkcióinak használatát (pl. metaadat-elemek olvasása, frissítése, törlése); a hozzáférést adott dátumot megelőzően; a hozzáférést adott dátumot követően. Az engedélyeket a szervezet biztonsági előírásaival összhangban kell kiosztani. Az engedélyek részletességével a 13.4. szakasz foglalkozik. 4.1.6.
Az EIKR-nek lehetővé kell tennie, hogy egy beállítástól függően a rendszert el lehessen érni integrált hálózati bejelentkezéssel.
Nem
Igen
4.1.7.
Az EIKR-nek lehetővé kell tennie az adminisztrátori szerepkörök számára, hogy a felhasználócsoportokhoz és szerepkörökhöz felhasználókat adhassanak, vagy onnan azokat eltávolítsák.
Igen
Igen
Igen
Igen
Az adminisztrátori szerepkörök használhatnak szoftvert a felhasználócsoportok kezeléséhez. 4.1.8.
külső
címtárkezelő
Az EIKR-nek lehetővé kell tennie, hogy a besorolási séma különböző részei fölött más-más adminisztrátori szerepkörök rendelkezhessenek az adminisztrátori jogokkal. Lásd például a 13.4. szakaszban bemutatott hozzáférés-szabályozási modellt.
Követelmény
Köt. Teszt
Az EIKR-nek lehetővé kell tennie, hogy adminisztrátori szerepkörök inaktívként jelölhessenek meg egy felhasználót anélkül, hogy azt törölnék a rendszerből.
Igen
Igen
Igen
Igen
Igen
Igen
Igen
Igen
Igen
Igen
4.1.14. Az EIKR-nek lehetővé kell tennie, hogy adminisztrátori szerepkörök ad hoc felhasználó-listákat állíthassanak össze a besorolási séma egyes részeihez vagy konkrét iratokhoz való hozzáférés szabályozása céljából.
Igen
Igen
4.1.15. Az EIKR-nek adminisztrátori szerepkörökre kell rendszerfeladatok és kapcsolódó események kezelését.
a
Igen
Igen
4.1.16. Az EIKR csak adminisztrátori szerepkörnek engedélyezheti felhasználói profil létrehozását, illetve a felhasználók szerepkörökhöz és csoportokhoz rendelését.
Igen
Igen
Hiv. 4.1.9.
Az adminisztrátori szerepkörök használhatnak szoftvert a felhasználók kezeléséhez.
külső
címtárkezelő
4.1.10. Az EIKR-nek lehetővé kell tennie, hogy adminisztrátori szerepkörök ugyanazokat a hozzáférési jogokat rendelhessék a felhasználói szerepkörökhöz, mint magukhoz a felhasználókhoz. Ezáltal az adminisztrátori szerepkörök a felhasználók egyenkénti kezelése helyett hozzáférési jogosultságok szűk, könnyen behatárolható gyűjteményeivel foglalkozhatnak. Szerepkörre példa a Menedzser, Kárigény ügyintéző, Biztonsági elemző, vagy az Adatbázis adminisztrátor. 4.1.11. Az EIKR-nek lehetővé kell tennie hozzáférési követelmények csoportjainak az alkalmazását a szerepkörökön keresztül. Példák a 13.4. szakaszban. 4.1.12. Az EIKR-nek lehetővé kell tennie egy adminisztrátori szerepkör számára felhasználócsoportok létrehozását és karbantartását. Példák felhasználócsoportokra: HR, Logisztika, Pénzügy. 4.1.13. Az EIKR-nek lehetővé kell tennie, hogy egy felhasználó tetszőleges számú felhasználócsoport tagja lehessen, beleértve azt az esetet is, amikor a felhasználó egyetlen csoportnak sem tagja. Valószínű, hogy lesznek a rendszernek olyan felhasználói, akik eltérő hozzáférési lehetőségekkel rendelkeznek a besorolási séma különböző részeire vonatkozóan. Minden esetben a szervezet üzleti igényei és elvei határozzák meg, hogy a felhasználók milyen csoport(ok)ba kerülnek.
korlátoznia
Ez a követelmény az elektronikus iratok hitelességét védi.
Lásd még a 13.4. szakaszt.
Hiv.
Követelmény
4.1.17. Az EIKR-nek lehetővé kell tennie, hogy az iratok tulajdonosi szerepköre korlátozhassa az iratok hozzáférésére jogosult felhasználók és csoportok körét.
Köt. Teszt Igen
Igen
Igen
Igen
Igen
Igen
Igen
Igen
4.1.21. Az EIKR-nek biztosítania kell egy alkalmazás programozói interfészt, amin keresztül külső alkalmazásrendszerek hozzáférhetnek az EIKR-ben tárolt iratokhoz.
Nem
Nem
4.1.22. Tartalomra kiterjedő kereséskor (pl. teljes keresés vagy szabad szöveges keresés esetén) az EIKR nem jeleníthet meg a találati listán olyan iratot, amelyhez a felhasználónak nincs hozzáférési engedélye.
Igen
Igen
A „tulajdonos” kifejezés értelmezését lásd a Szószedetben. Amennyiben a szervezeti politika lehetővé teszi, a tulajdonjog gyakorlása az adminisztrátori szerepkörök jogosultsága. 4.1.18. Az EIKR-nek adminisztrátori szerepkörökre kell korlátoznia a csoportok, szerepkörök és felhasználók profiljainak a változtatási jogát, beleértve a profilok kiegészítését, törlését, vagy új profil létrehozását. A változtatások az olyan jellemzőkre is vonatkoznak, mint a hozzáférési jogok, privilégiumok és jelszók kiosztása és kezelése. 4.1.19. Az EIKR-nek lehetővé kell tennie, hogy adminisztrátori szerepkörök szabályozhassák a felhasználók által elérhető EIKR funkciók körét úgy, hogy az egyes szerepkörök funkciók különböző kombinációhoz férhetnek hozzá. Az EIKR-nek a szabályok részletességét (azaz alábontását) legalább a 13.4. szakaszban bemutatott szinten kell biztosítania. Az egyes szervezetek eltérő funkcionális hozzáférés-szabályozási követelményeket állíthatnak fel, ezért nem lehet és nem is javasolt egy általános modellt kidolgozni. A MoReq2 a pontos követelmények megfogalmazása helyett csak a szabályozás részletességének fokát rögzíti. 4.1.20. Az EIKR-nek lehetővé kell tennie, hogy adminisztrátori szerepkörök a 13.4. szakaszban bemutatott szerepkörökön túl további szerepköröket hozhassanak létre. A szervezetek célzott hozzáférési jogokat rendelhetnek a szerepkörökhöz, például ügyintéző, menedzser stb.
Ez a követelmény megakadályozza, hogy a felhasználók szövegkeresés segítségével olyan dokumentumok tartalmát böngészhessék, amikhez egyébként nincs jogosultságuk.
Hiv.
Követelmény
4.1.23. Ha a felhasználó olyan objektumhoz (pl. irat, kötet, aldosszié, dosszié, vagy osztály) próbál hozzáférni, navigálni, vagy nem tartalomkeresés útján eljutni, amelyhez nincs hozzáférési jogosultsága, az EIKR az alábbi válaszok egyikével reagálhat (a válasz a konfiguráció során vagy egy későbbi időpontban megadható beállítástól függ):
Köt. Teszt Igen
Igen
Nem
Igen
nem szolgál információval az adott objektumról, így a felhasználó azt sem tudja meg, hogy az objektum létezik-e, vagy sem; a rendszer megerősíti az objektum létezését, és esetlegesen kiírja annak tulajdonosát (megjelenítheti az objektumot tartalmazó dosszié vagy irat azonosítóját), de nem fedi fel az objektum címét és egyéb metaadatait; megjeleníti az objektum címét, típusát (osztály, irat stb.), létrehozási dátumát és tulajdonosát; megjeleníti az objektum címét és egyéb metaadatait. A felsorolás első pontja ugyanazt a kimenetet írja elő, mint a tartalomkeresésre vonatkozó követelmény (lásd 4.1.22.). A másik három lehetőség biztonság szerint csökkenő sorrendben szerepel. Egyes szervezeteknél a felsorolás utolsó pontja, azaz a biztonságilag leggyengébb megoldás is elfogadható. A lehetőségek közül az adminisztrátori szerepkörök választhatnak. Ez a követelmény csak azokra a hozzáférési kísérletekre vonatkozik, melyek nem a tartalomkeresésre irányulnak. A tartalomkereséssel a 4.1.22. követelmény foglalkozik. 4.1.24. Az EIKR-nek lehetővé kell tennie, hogy a 4.1.23. pontban megfogalmazott válaszlehetőségek közül a besorolási séma egyes osztályaira igény szerint eltérő korlátozások vonatkozzanak, mint amelyek a teljes rendszerre érvényesek. A kivételeket a konfiguráció során vagy egy későbbi időpontban lehessen beállítani.
4.2.
Eseménynapló
Az eseménynapló az EIKR-ben végrehajtott tevékenységek jegyzéke. Tevékenységnek számít egy felhasználói vagy adminisztrátori szerepkör által kezdeményezett művelet és az EIKR-ben rendszerparaméterek hatására automatikusan végrehajtott feladat. A pontos megfogalmazást lásd a Szószedetben, 13.1. szakasz. Az eseménynaplóból kiderül, hogy a rendszer felhasználói betartják-e az üzleti szabályokat, a jogosulatlan tevékenységeket könnyű felismerni és visszavezetni. A felelősségre vonhatóság előfeltétele, hogy az EIKR minden olyan tevékenységet rögzítsen az eseménynaplóban, amelyet a rendszer valamilyen mértékben automatizált vagy számítógéppel támogatott folyamattal valósít meg. A 10.5. szakaszban bemutatott ügyviteli környezetek jól példázzák az ilyen interfészek használatának szükségességét.
Az eseménynapló kulcsfontosságú szerepet tölt be a számonkérhetőség mint követelmény megvalósításában azáltal, hogy az összes iraton végrehajtott összes tevékenységet számon tartja (a műszaki környezet biztonságosságától függően). Az eseménynapló mérete rohamosan nő, ha a rendszer minden tevékenységet feljegyez. Ebből kifolyólag egyes szervezeteknél döntést hozhatnak arról, hogy tevékenységeknek csak egy meghatározott körét kövessék nyomon (a döntéshozatal napját követően). Több ismert implementációban rendszeres időközönként offline tárolóhelyre mozgatják az eseménynaplót, azzal a feltétellel, hogy az offline másolatot törlik, amennyiben az érintett iratok kikerülnek az iratkezelő rendszerből, vagy az üzletpolitika lehetővé teszi. Az előbb felsorolt megvalósítási módszerekből is kitűnik, hogy az eseménynaplóra vonatkozó pontos szabályok meghatározása a szervezet vezetése illetve a jogi szabályozás hatáskörébe tartozik. A MoReq2 ennél fogva csak helyt ad a naplózási tevékenységekre vonatkozó követelményeknek, de nem írja elő, hogy azokat milyen mértékben kell követni.
Hiv. 4.2.1.
Követelmény
Köt. Teszt
Az EIKR-nek megváltoztathatatlan eseménynaplót kell vezetnie, melyben az alábbiakat rögzítik automatikusan:
Igen
az iratokon, iratcsoportokon és a besorolási sémán végrehajtott összes művelet; a tevékenységet végrehajtó felhasználó; az esemény napja és pontos időpontja. Pusztán az illusztráció céljából az alábbiakban felsorolunk néhány tipikus eseményt, melyet naplózni szokás (természetesen a lista nem kizárólagos): elektronikus iratok iktatása; az elektronikus dossziék átsorolása a besorolási sémán belül (lásd 3.4.1.); a megőrzési és selejtezési ütemtervek megváltoztatása; az adminisztrátori szerepkörök által végrehajtott selejtezés felülbírálati tevékenységek; selejtezési visszatartás elhelyezése vagy feloldása egy elektronikus dosszién; az elektronikus osztályokhoz, elektronikus dossziékhoz és elektronikus iratokhoz tartozó metaadatokon végzett változtatások; metaadatok törlése vagy módosítása felhasználók által; hozzáférési engedélyek módosítása; felhasználók és csoportok létrehozása, törlése vagy módosítása; exportálás és áthelyezés; bemutatók létrehozása; iratok törlése és megsemmisítése. A „megváltoztathatatlan” kifejezés arra vonatkozik, hogy se felhasználói, se adminisztrátori szerepkör nem módosíthatja és nem törölheti az eseménynapló egyetlen részét sem. Az eseménynapló részletességét a szervezet igényei határozzák meg. Az eseménynapló megbízhatósága az iratkezelő rendszer és az azt futtató operációs rendszer biztonságától is függ. Az eseménynapló átszervezése és offline tárolóra másolása viszont engedélyezett, amennyiben a műveletek végrehajtása közben nem sérül a napló integritása.
Igen
Követelmény
Köt. Teszt
4.2.2.
Amennyiben az EIKR támogatja az eseménynapló adatainak átvitelét offline tárolókra, az EIKR-nek gondoskodnia kell az offline adatok biztonságos kezeléséről és szükség esetén azok visszatöltéséről a rendszerbe. Az EIKRnek biztosítania kell, hogy az eseménynaplót ne lehessen a rendszert megkerülve elérni (pl. ne lehessen az adatokat egyszerűen a rendszeren kívülről átmásolni egy másik tárolóra, ott módosítani, majd visszamásolni).
Igen
Rész ben
4.2.3.
Az EIKR-nek lehetőséget kell biztosítania az iratokat vagy azok gyűjteményeit érintő hozzáférési kísérletek, illetve a hozzáférés céljának (olvasás, nyomtatás, egyéb megjelenítés) automatikus naplózására.
Igen
Igen
Hiv.
Ez általában csak a legszigorúbb biztonsági előírások mellett működő környezetben szükséges. 4.2.4.
Az EIKR-nek paramétereket kell biztosítania az eseménynaplóhoz, amelyeken keresztül az adminisztrátori szerepkörök beállíthatják, hogy milyen tevékenységeket kell automatikusan naplózni.
Igen
Igen
4.2.5.
Az eseménynapló paramétereinek a megváltoztatását rögzíteni kell az eseménynaplóban.
Igen
Igen
Az eseménynapló paraméterei közül az eseménynapló megváltoztatására vonatkozót ne lehessen kikapcsolni. Az EIKR-nek minden körülmény között rögzítenie kell, hogy ki és mikor változtatott az eseménynapló beállításain. 4.2.6.
Az eseménynapló paramétereinek változtatása azonnal életbelép, az EIKRnek a módosítást követően az új paramétereket figyelembe véve kell az egyes eseményeket rögzítenie.
Igen
Igen
4.2.7.
Az EIKR köteles megőrizni az eseménynaplót a szervezet iratkezelési szabályzatában meghatározott ideig.
Igen
Nem
Az eseménynapló megőrzésének ideje rendszerint lefedi a naplóban hivatkozott iratok élettartamát. Ez azonban felülbírálható, különösen olyan környezetekben, ahol az eseménynaplót adott időközönként alaposan átvizsgálják, és törlik az érdektelen adatokat. A megsemmisített adatok helyét egy vizsgálati tanúsítvány jelzi.
Követelmény
Köt. Teszt
4.2.8.
Az EIKR-nek rögzítenie kell az eseménynaplóban az iratokon, köteteken, aldossziékon, dossziékon, osztályokon és a megőrzési és selejtezési ütemterven végzett minden egyes tevékenységet függetlenül attól, hogy a tevékenység egy vagy több egyedet érint.
Igen
Rész ben
4.2.9.
Az EIKR-nek rögzítenie kell az eseménynaplóban a MoReq2 metaadatmodellben felsorolt metaadat-elemek értékeinek megváltoztatását.
Igen
Rész ben
4.2.10. Az iratok kiegészítését és a hozzá fűzött feljegyzéseket rögzíteni kell az irat eseménynaplójában.
Igen
Igen
4.2.11. Az EIKR-nek automatikusan rögzítenie kell az eseménynaplóban az adminisztrátori paramétereket érintő összes változtatást.
Igen
Igen
4.2.12. Az EIKR-nek felülvizsgálati kérésre elő kell adnia az eseménynaplót olyan formában, hogy az egyes eseményeket be lehessen azonosítani a hozzá tartozó adatokkal együtt.
Igen
Igen
4.2.13. Az EIKR-nek olyan eszközöket kell biztosítania a jogosult felhasználók számára, amellyel a rendszert kevésbé vagy egyáltalán nem ismerő felhasználók is képesek az eseménynapló adataiban keresni.
Igen
Rész ben
4.2.14. Az EIKR-nek lehetővé kell tennie, hogy a felhasználók konkrét eseményekre, objektumokra (osztályok, iratok stb.), felhasználókra, szerepkörökre, időpontokra vagy időintervallumokra kereshessenek az eseménynaplóban.
Igen
Igen
4.2.15. Az EIKR-nek lehetőséget kell biztosítania az eseménynapló adott iratra, kötetre, aldossziéra, dossziéra vagy osztályaira vonatkozó adatainak az exportálására anélkül, hogy az bármilyen formában érintené az eseménynaplót, leszámítva az exportálásra vonatkozó új naplóbejegyzést.
Igen
Igen
Igen
Igen
Hiv.
A rendszernek tehát naplóznia kell, ha egy adminisztrátori szerepkör megváltoztatja valamelyik felhasználó jogosultságait, vagy módosítja az eseménynapló beállításait.
Ez a követelmény a könnyű használhatóságra vonatkozik. A felhasználók lehetnek a szervezeten kívülről érkező személyek, például külső felülvizsgálók, ettől függetlenül azonban a rendszer őket is hagyományos felhasználónak tekinti.
Ez a funkció segít például a külső felülvizsgálóknak elemezni a rendszerben végrehajtott műveleteket. 4.2.16. Az EIKR-nek rögzítenie kell minden olyan eseményt, amely a hozzáférési szabályok kijátszására utalhat (vagyis amikor a felhasználó jogosultság híján próbál meg elérni egy iratot, kötetet, aldossziét vagy dossziét). A hozzáférési szabályok megkerülésének módjait a 4.1.23. követelmény foglalja össze. Jelen követelmény nem vonatkozik azokra az esetekre, amikor a rendszer elrejti a felhasználó elől a számára nem elérhető információkat.
4.3.
Biztonsági mentés és visszaállítás
Az üzleti és törvényi előírások megkövetelik, hogy az EIKR átfogó biztonsági mentést készítsen az iratokról és a metaadatokról. A rendszernek gondoskodnia kell a hiba (pl. rendszerhiba, véletlen baleset, biztonsági rés kijátszása) folytán elveszett vagy károsult iratok megfelelő visszaállításáról. A rendszeresen elvégzett automatikus biztonsági mentés megvalósítható az iratkezelő rendszeren belül, ugyanakkor igénybe vehetők a rendszerhez kapcsolódó elektronikus dokumentumkezelő rendszerek (EDKR) szolgáltatásai, végezheti az EIKR-t támogató adatbázis szoftver, de más, erre alkalmas szoftver is felhasználható. A szakaszban „az EIKR” kifejezés tehát ezek bármelyikét jelentheti a leendő megvalósítástól függően. A gyakorlatban a biztonsági mentés és visszaállítás a szervezet informatikai részlegének a hatáskörébe tartozik, csak ritkább esetben az adminisztrátori szerepkör feladata. Követelmény
Köt. Teszt
4.3.1.
Az EIKR-nek gondoskodnia kell automatikus biztonsági mentési és visszaállítási folyamatokról, amelyek lehetővé teszik, hogy a kiválasztott osztályokról, dossziékról, iratokról, metaadatokról, adminisztrátori paraméterekről és az eseménynaplóról rendszeres biztonsági másolat készüljön, ami alapján azok automatikusan visszaállíthatók.
Igen
Igen
4.3.2.
Az EIKR-nek lehetővé kell tennie, hogy adminisztrátori szerepkörök a biztonsági mentés ütemezésekor
Igen
Igen
Hiv.
meghatározhassák a mentés gyakoriságát; kiválaszthassák a mentésre kerülő osztályokat, dossziékat és iratokat; kijelölhessék a mentés helyéül szolgáló adathordozót vagy rendszert (pl. offline tárhely, külön rendszer, távoli tárhely). 4.3.3.
Az EIKR csak a jogosult adminisztrátori szerepkört betöltő személyeknek engedélyezheti az adatok visszaállítását a biztonsági mentésből.
Igen
Igen
4.3.4.
A biztonsági mentésből való visszaállítást követően az EIKR-nek biztosítania kell az adatok teljes körű integritását, az eseménynaplót is beleértve.
Igen
Rész ben
Igen
Rész ben
A szabályosan megsemmisített, de a korábbi biztonsági mentésben jelenlévő iratokat csak kivételes esetben szabad visszaállítani. 4.3.5.
4.4.
Amennyiben az EIKR ellenőrző pontokat tartalmaz és adatbázis-előregörgető (roll-forward) képességgel rendelkezik, az előregörgetést csak az arra jogosult adminisztrátori szerepkör kezdeményezheti.
Kiemelt iratok
Kiemeltnek azok az iratok tekinthetők, amelyek rövid vagy hosszú távon elengedhetetlenek a szervezet üzleti tevékenységeihez (a pontos meghatározást lásd a Szószedetben). A kiemelt iratok vészhelyzeti forgatókönyveket írnak le, vagy a szervezet pénzügyi és jogi érdekeit védik.
Az ilyen jellegű iratok azonosítása és védelme a szervezet kulcsfontosságú feladata. Egy esetleges katasztrófát követően elsőként a kiemelt iratokat kell visszaállítani. A kiemelt irat a szervezet egészére vagy részére nézve kiemelt. Hiv. 4.4.1.
Köt.
Tesz t
Igen
Igen
Igen
Igen
Igen
Rész ben
Követelmény Az EIKR-nek lehetővé kell tennie, hogy adminisztrátori szerepkörök megjelölhessék a „kiemelt iratként” kezelendő iratokat. A kiemelt iratot tároló dosszién is jelezni kell, hogy tartalma fontos. A kiemelt jelzést metaadatelem formájában kell rögzíteni.
4.4.2.
Az EIKR-nek két, egymástól független biztonsági mentési műveletet kell biztosítania: „teljes” biztonsági mentést, ami az összes (megjelölt) EIKR adatra kiterjed; „kiemelt” biztonsági mentést, ami csak az EIKR beállításait és a kiemelt iratokat és dossziékat menti el. A kétféle biztonsági mentés szétválasztása lehetővé teszi, hogy a „kiemelt” biztonsági mentéseket gyakrabban végezzék el, mint a „teljes” biztonsági mentést; a „kiemelt” biztonsági mentéseket más (lehetőség szerint biztonságosabb) adathordozó eszközre rögzítsék, mint a „teljes” biztonsági mentéseket. A szétválasztás az EIKR visszaállítását is megkönnyíti, mivel a „kiemelt” biztonsági mentésből történő helyreállítás a „teljes” visszaállítástól teljesen függetlenül, más időpontban is elvégezhető. A 4.3. szakasz értelmében a biztonsági mentést végezheti az EIKR vagy egy integrált szoftver.
4.4.3.
A „kiemelt” biztonsági mentésből történő visszaállítást követően az EIKR-nek teljesen működőképesnek kell lennie. A „kiemelt” biztonsági mentésből történő visszaállítás után feltehetően több dosszié és irat is hiányozni fog a rendszerből. Ettől eltekintve azonban a rendszer funkcionalitásában nem lehet korlátozott.
Hiv. 4.4.4.
Köt.
Tesz t
Nem
Igen
Igen
Igen
Követelmény Az EIKR-nek két módon kell a „teljes” biztonsági mentésből történő visszaállítást támogatnia: a „teljes” biztonsági mentésből kinyert adatok visszatöltése egy „tiszta” környezetbe; a visszanyert adatok felülírják a rendszerben tárolt adatokat; a „teljes” biztonsági mentésből kinyert adatok összefésülése egy meglévő környezet adataival. Az első módszer azoknál a szervezeteknél bevett gyakorlat, ahol nem készül biztonsági mentés a „kiemelt” adatokról. A második módszer a „kiemelt” biztonsági mentésből való helyreállítást követően használatos, nem sokkal azután, hogy a rendszer ismét működőképes állapotba kerül. Ilyenkor a „teljes” mentésből történő visszaállítás során figyelembe kell venni, hogy a korábban helyreállított kiemelt iratok és dossziék adatait, illetve az első helyreállítást követően létrehozott új egyedeket és az egyéb változtatásokat ne írják felül. Ha az EIKR a 4.4.4. pontban felsorolt mindkét helyreállítási módot támogatja, a „kiemelt” biztonsági mentésből (amennyiben készült ilyen) végzett helyreállításnak mindig a „teljes” visszaállítás előtt kell megtörténnie. A fordított visszaállításnak nincs értelme. A kétlépéses rendszer-visszaállítás során fellépő ellentmondásokat egy adminisztrátori szerepköröknek kell manuálisan feloldania. Előfordulhat például, hogy a két biztonsági mentés a besorolási séma más-más változatát rögzítette.
4.4.5.
Az EIKR-nek lehetővé kell tennie adminisztrátori szerepkörök számára, hogy indokolt esetben töröljék a kiemelt jelzést az érintett iratokról és dossziékról. A kiemelt státusz törlését rögzíteni kell az eseménynaplóban. Egy megállapodás-sablon például érvényét vesztheti törvénymódosítás következtében, így többé nem számít kiemelt iratnak.
5.
MEGŐRZÉS ÉS SELEJTEZÉS
Ez a fejezet az iratok megőrzését és selejtezését szabályozó megőrzési és selejtezési ütemtervek követelményeit tartalmazza. A megőrzési és selejtezési ütemtervek az iratok megtartásának időtartamát és a rendszerből való eltávolításuk módját határozzák meg, a formális definíciót lásd a Szószedetben. A megőrzési és selejtezési időkre vonatkozó követelményeket az 5.1. szakasz ismerteti. A további szakaszok a megőrzési idő lejártakor követendő eljárásokat részletezik: a lehetséges eljárásokat az 5.2. szakasz, az iratok áthelyezésének, exportálásának és megsemmisítésének követelményeit pedig az 5.3. szakasz foglalja össze. A 2.2. szakasz Elektronikus dossziék, aldossziék és kötetek című részében foglaltak szerint az iratok tárolhatók osztályokban, dossziékban, aldossziékban és kötetekben az üzleti követelményekkel összhangban. Környezettől függően a megőrzési és selejtezési ütemtervek osztályokra, dossziékra, aldossziékra és kötetekre vonatkozhatnak, ezzel egyidejűleg azonban irattípusokhoz is társíthatók. Az irattípusok lehetővé teszik eltérő megőrzési idő kijelölését, ami például a bizalmas személyes adatok gyors törlését, vagy a műszaki tervrajzok hosszú távú tárolását támogatja. A különféle ütemtervek közötti ellentmondások minden esetben feloldhatók. A MoReq2 bevezeti a „selejtezési visszatartás” fogalmat, ami újítás a MoReq korábbi változatához képest. A selejtezési visszatartás váratlan helyzetekben akadályozza meg az iratok ütemterv szerinti selejtezését. Elhúzódó bírósági eljárásoknál például garantálja, hogy a bizonyítékot nem semmisíti meg automatikusan a rendszer az eljárás vége előtt.
5.1.
Megőrzési és selejtezési ütemtervek Követelmény
Köt. Teszt
5.1.1.
Az EIKR-nek kizárólag adminisztrátori szerepkörök számára kell engedélyeznie megőrzési és selejtezési ütemtervek létrehozását és karbantartását.
Igen
Igen
5.1.2.
Az EIKR nem korlátozhatja a megőrzési és selejtezési ütemtervek számát.
Igen
Rész ben
5.1.3.
Az EIKR-nek lehetőséget kell biztosítania a megőrzési és selejtezési ütemtervek hierarchikus struktúrába rendezésére, ami a hatályos jogszabályok szellemében készült általános és a szervezetre jellemző megőrzési és selejtezési ütemtervek struktúráját tükrözi.
Ne m
Nem
Hiv.
A hierarchikus felépítés több megőrzési és selejtezési ütemterv együttes kezelését segíti.
Követelmény
Köt. Teszt
5.1.4.
Az EIKR-nek a létrehozás pillanatában egyedi azonosítót kell rendelnie minden újonnan létrehozott megőrzési és selejtezési ütemtervhez.
Igen
Igen
5.1.5.
Az EIKR-nek lehetővé kell tennie egyedi címek hozzárendelését a megőrzési és selejtezési ütemtervekhez azok létrehozásakor.
Igen
Igen
5.1.6.
Az EIKR-nek nyomon kell követnie a megváltoztathatatlan eseménynaplóban a megőrzési és selejtezési ütemterveket érintő összes módosítást és törlést a művelet időpontjával és az azt kezdeményező felhasználó adataival együtt.
Igen
Igen
5.1.7.
Az EIKR-nek biztosítania kell, hogy a megőrzési és selejtezési ütemterven végrehajtott módosítások azonnal érvénybe lépjenek azokon az egyedeken, amelyekre az ütemterv vonatkozik.
Igen
Igen
5.1.8.
Az EIKR-nek ki kell kényszerítenie, hogy a megőrzési és selejtezési ütemterv módosítását vagy törlését megindokolja a tevékenységet végző adminisztrátori szerepkör. Az indoklást rögzíteni kell az eseménynaplóban.
Igen
Igen
Az EIKR-nek képesnek kell lennie megőrzési és selejtezési ütemtervek importálására és exportálására.
Igen
Rész ben
5.1.10. Az EIKR-nek biztosítania kell, hogy minden egyes osztályra, dossziéra, aldossziéra és kötetre legalább egy megőrzési és selejtezési ütemterv vonatkozzon.
Igen
Igen
Ne m
Igen
Hiv.
A megőrzési és selejtezési ütemterv módosítása és törlése kockázatos művelet, mert az iratok idő előtti megsemmisítését vonhatja maga után. 5.1.9.
Ez a követelmény garantálja, hogy a rendszer nem tárolhat megőrzési és selejtezési ütemterv nélküli egyedeket, emellett pedig növeli a használhatóságot. 5.1.11. Az újonnan létrehozott osztályok, dossziék, aldossziék és kötetek alapértelmezésben a szülő megőrzési és selejtezési ütemtervét öröklik. Azokban az esetekben, amikor ez nem lehetséges (a besorolási séma legfelső szintű osztályai és a megőrzési és selejtezési ütemtervvel nem rendelkező szülők esetén, lásd 5.1.18.), alapértelmezett megőrzési és selejtezési ütemtervet kell rendelni az egyedhez.
Hiv.
Követelmény
Köt. Teszt
5.1.12. Az osztályokban közvetlenül tárolt iratokra legalább egy megőrzési és selejtezési ütemtervnek kell vonatkoznia.
Igen
Igen
5.1.13. Az osztályokban közvetlenül tárolt iratok (lásd 3.2. szakasz és 3.2.17. követelmény) alapértelmezésként kötelezően a szülő osztály megőrzési és selejtezési ütemtervét öröklik.
Igen
Igen
5.1.14. Az EIKR-nek engedélyeznie kell, hogy egy adminisztrátori szerepkör adott megőrzési és selejtezési ütemtervet tetszőleges osztályhoz, dossziéhoz, aldossziéhoz, kötethez vagy irattípushoz rendelhessen, időponttól függetlenül.
Igen
Igen
Ne m
Igen
Az „időponttól függetlenül” kifejezés arra vonatkozik, hogy adminisztrátori szerepkörök lecserélhetik a meglévő megőrzési és selejtezési ütemtervet, vagy (amennyiben a rendszer több ütemterv egyidejű használatát támogatja, lásd 5.1.16.) újabb megőrzési és selejtezési ütemtervet rendelhetnek bármelyik osztályhoz, dossziéhoz, aldossziéhoz, kötethez vagy irattípushoz. Gyakori példa, amikor az alapértelmezett ütemtervet megváltoztatják, vagy felülbírálat hatására további megőrzési és selejtezési ütemtervet adnak az adott egyedhez. Utóbbi esetben ellentmondás alakulhat ki a két vagy több ütemterv között, ezek feloldását lásd az 5.1.23. pontban. 5.1.15. Az EIKR tudjon alapértelmezett megőrzési és selejtezési ütemtervet rendelni az irattípusokhoz. Ebből következik, hogy nem minden irattípushoz tartozik megőrzési és selejtezési ütemterv. Ez teljesen elfogadható, tekintve hogy az iratokra legalább egy ütemterv vonatkozik, ami nem más, mint az iratot tartalmazó dosszié vagy kategória 5.1.10. követelmény értelmében kötelezően előírt ütemterve.
Hiv.
Követelmény
5.1.16. Az EIKR-nek egynél több megőrzési és selejtezési ütemtervet kell támogatnia az osztályok, dossziék, aldossziék és kötetek vonatkozásában.
Köt. Teszt Igen
Igen
Igen
Igen
Igen
Igen
Ez a követelmény valós életből vett igényt fogalmaz meg. Igen gyakori, hogy a különféle szabályozások és üzleti szükségletek eltérő megőrzési időket szabnak meg. Az alábbiakban példán keresztül mutatjuk be, hogyan lehet egyszerre több ütemtervet kezelni (a példát a sok lehetséges szituáció közül ragadtuk ki). Példánkban adott egy dosszié, amihez egyetlen megőrzési és selejtezési ütemterv tartozik, lévén hogy a dosszié olyan iratokat tartalmaz, amelyeknek nincsenek jogi vonatkozásai. A dosszié megőrzési és selejtezési ütemtervét más dossziékon is használják. Egy napon kiderül, hogy a dossziét az ütemtervben megadott időpontnál tovább kell megőrizni, mivel olyan iratokat tartalmaz, melyek fontos szerepet játszanak egy biztonsági ügy megoldásában. Az adott pillanatban ésszerűnek tűnik egy újabb megőrzési és selejtezési ütemterv formájában rögzíteni a hosszabb megőrzési időtartamot. Később bebizonyosodik, hogy a biztonsági kivizsgálás megalapozatlan volt, így a dossziéról törölhető a második megőrzési és selejtezési ütemterv. 5.1.17. Az iratok megőrzését és selejtezését az irathoz kapcsolódó osztály, dosszié, aldosszié, kötet és irattípus érvényes megőrzési és selejtezési ütemterve határozza meg az esetleges selejtezési visszatartások figyelembe vételével (lásd 5.1.34.) Az egyedre vonatkozó megőrzési és selejtezési ütemtervek az egyeddel kapcsolatban álló iratokra is érvényesek (amennyiben más megőrzési és selejtezési ütemtervvel nem ütköznek). 5.1.18. Az EIKR-nek lehetővé kell tennie a megőrzési és selejtezési ütemtervek és az azokon végzett módosítások átöröklését a besorolási séma hierarchiájának alsóbb szintjeire egy adminisztrátori szerepkör döntésétől függően. A megőrzési és selejtezési ütemterv öröklésének engedélyezését vagy tiltását az adminisztrátori szerepkör bárhogy elvégezheti, a MoReq2 nem kíván e kérdésben állást foglalni. Néhány lehetséges megoldás: a beállításról a megőrzési és selejtezési ütemterv létrehozásakor kell dönteni (ez esetben minden elemre érvényes, amelyre az adott megőrzési és selejtezési ütemtervet alkalmazzák); a beállításról a megőrzési és selejtezési ütemterv elemhez rendelésekor kell dönteni (ez esetben a leszármazott egyedekre vonatkozik); új egyed létrehozásakor döntik el, hogy örökölje-e a szülője megőrzési és selejtezési ütemtervét.
Hiv.
Követelmény
5.1.19. A megőrzési és selejtezési ütemtervnek kötelező rendelkeznie
Köt. Teszt Igen
Igen
Igen
Igen
Ne m
Igen
Igen
Igen
Igen
Igen
a megőrzés időtartamáról (5.1.25) és az időtartam lejártakor bekövetkező eseményről (5.1.25) vagy a selejtezési dátumról. 5.1.20. A megőrzési és selejtezési ütemtervnek tartalmaznia kell a selejtezési tevékenységet (5.1.24); annak indoklását. 5.1.21. A megőrzési és selejtezési ütemtervnek tartalmaznia kell egy leírást és egy rendelkezést. A rendelkezés igazolja a megőrzési és selejtezési ütemtervet. A rendelkezés általában törvényi előírásra, jogszabályra vagy vállalati elvre hivatkozik. 5.1.22. Az irat megőrzési és selejtezési ütemterv szerinti megőrzési idejének lejártakor az EIKR köteles intézkedést kezdeményezni az irat selejtezésének ügyében. Az intézkedés jelentheti a selejtezési döntés végrehajtását (az 5.2.4. követelmény figyelembe vételével), vagy egy adminisztrátori szerepkör hatáskörébe tartozó tevékenység végrehajtását (lásd 5.1.23.). Egyes szervezetek az utóbbi megoldást részesítik előnyben az automatikus végrehajtásból származó kockázatok elkerülése végett. 5.1.23. Ha a selejtezési döntés végrehajtásának kezdeményezésekor (az 5.1.22. követelménynek megfelelően) eltérő megőrzési időt vagy selejtezési döntést előíró megőrzési és selejtezési ütemterv is érvényes az elemre, ellentmondás keletkezik. Az EIKR-nek rendelkeznie kell olyan beállítással, amely megszabja, hogy az EIKR jelentést küldjön az ellentmondásokról egy adminisztrátori szerepkörnek, aki azt feloldja. A „rendelkeznie kell olyan beállítással” kifejezés arra utal, hogy az adminisztrátori szerepkörök nem kötelesek minden helyzetben beavatkozni. Az EIKR önmaga is feloldhatja az ellentmondást, de biztosítania kell olyan beállítást, amellyel megszabható, hogy az ellentmondás feloldásának módjáról egy adminisztrátori szerepkör döntsön.
Hiv.
Követelmény Ellentmondást eredményez, ha az egyedre érvényes megőrzési és selejtezési ütemtervek eltérő módon rendelkeznek a selejtezés megkezdésének idejéről; vagy az egyedre érvényes megőrzési és selejtezési ütemtervek eltérő selejtezési tevékenységet írnak elő. Az esetek túlnyomó részében az ütemtervek precedenciáját egyszerű megállapítani. Ellentmondások az alábbi két szituációban keletkezthetnek: az ellentmondásos ütemtervek egy teljes iratgyűjteményre (pl. egy dossziéra) vonatkoznak; az ütemtervek iratgyűjteményekre és azon belül néhány iratra vonatkoznak (utóbbi esetben feltehetően adott irattípushoz tartozó iratok érintettek). Az adminisztrátori közbelépés akkor kívánatos, amikor nem lehet automatikusan egyértelműen helyes döntést hozni. Például: két, jogi vonatkozású megőrzési és selejtezési ütemterv eltérő megőrzési időt írhat elő. Ilyen esetben általában a hosszabb időtartamot indokolt választani; előfordulhat, hogy az egyik (pl. az adatvédelmi előírásokat követő) megőrzési és selejtezési ütemterv selejtezési dátuma korábbi, mint a másiké. Döntésnél a két ütemterv rendelkezésének súlyát és az üzleti igényeket kell figyelembe venni. Ilyen helyzetek akkor fordulhatnak elő, amikor a dokumentum irattípusa alapján, az iratokat tartalmazó iratgyűjteményekre érvényes szabályokkal szemben, az irattípus selejtezési szabályait kell alkalmazni és örökíteni a típusba tartozó iratokra. Az adminisztrátori szerepkör az alábbi módokon oldhatja fel az ellentmondást: eltávolíthat egy vagy több ellentmondó ütemtervet az iratokról vagy iratgyűjteményekről; megváltoztathatja az ütemterveket az ellentmondás feloldása céljából; eltávolíthatja az összes ellentmondó ütemtervet, és helyettük újat vezethet be; igénybe veheti a 9.3. szakaszban leírt kivételes törlési lehetőségeket.
Köt. Teszt
Hiv.
Követelmény
Köt. Teszt
A felsorolt tevékenységek gondatlan alkalmazása az iratok helytelen kezelését vonhatja magával. Ennél fogva e tevékenységek mindegyike – a megőrzési és selejtezési ütemtervek módosítása, vagy az iratok törlése – előzetes írásbeli eljáráshoz kötött. Egyes környezetekben a könnyű ellenőrizhetőség érdekében a feladatok szétosztása javasolt. Ha az ellentmondás feloldása után olyan iratgyűjteményben (dosszié, osztály stb.) maradnak iratok, amelyet törölni kellett volna, a szervezet külön szabályokat hozhat az így fennmaradt iratok tárolásáról. Előírhatja például az iratgyűjtemények megtartását, vagy a megmaradt irat(ok) áthelyezését (lásd 3.4. szakasz). 5.1.24. Az EIKR legalább az alábbi selejtezési tevékenységeket (meghatározásukat lásd az 5.1.20. pontban) köteles biztosítani megőrzési és selejtezési ütemtervenként: tartós megőrzés; benyújtás felülbírálatra; automatikus megsemmisítés; megsemmisítés adminisztrátori szerepkör által adott meghatalmazás alapján; levéltárba adás vagy küldés más tárolóba (lásd Szószedetben). Az „automatikus megsemmisítés” számos kockázattal jár, amiről az előző követelményben is szó esett. A szervezeteknek mérlegelniük kell az automatizálás előnyeit és a kockázatokat.
Igen
Igen
Hiv.
Követelmény
5.1.25. Az EIKR a megőrzési idők és a lejártukkor bekövetkező események (lásd 5.1.19.) legalább következő kombinációinak a meghatározását köteles biztosítani:
Köt. Teszt Igen
Igen
Ne m
Rész ben
Igen
Rész ben
selejtezés az osztály, dosszié, aldosszié vagy kötet megnyitását követő meghatározott időtartam elteltével; selejtezés az osztály, dosszié, aldosszié vagy kötet lezárást követő meghatározott időtartam elteltével; selejtezés a legutolsó iratnak osztályba, dossziéba, aldossziéba vagy kötetbe való elhelyezését követő meghatározott időtartam elteltével; selejtezés az osztályba, dossziéba, aldossziéba vagy kötetbe tartozó irat legutolsó elérését követő meghatározott időtartam elteltével; selejtezés meghatározott külső esemény (azaz olyan, az ütemtervben rögzített esemény, amelynek bekövetkeztét egy adminisztrátori szerepkör jelzi a rendszer felé, mivel az nem képes automatikus észrevenni az eseményt, pl. szerződés aláírása) bekövetkezése utáni meghatározott időtartam elteltével; „tartósan”, az iratok hosszú távú megőrzését jelezve. Bár a felsorolt feltételek általában a legtöbb szervezet igényeit kielégítik, előfordulhat, hogy egyes helyeken további megőrzési időtartamokat és selejtezést kiváltó eseményeket határoznak meg. A megőrzési és selejtezési ütemtervek tetszőleges számú külső eseményre hivatkozhatnak. 5.1.26. Az EIKR nem korlátozhatja a megőrzési időtartam hosszát. 5.1.27. Az EIKR-nek legalább 100 év megőrzési időtartamot kell biztosítania az 5.1.24. követelmény alapján. A megőrzési időtartam e minimális felső határát a gyakorlati korlátozások elkerülése érdekében határoztuk meg. Jóllehet egyetlen EIKR-t sem használnak száz évig, ez a követelmény biztosítja, hogy az iratokat a megőrzési és selejtezési ütemtervek átírása nélkül lehessen átmozgatni egy másik, jövőbeli rendszerbe.
Hiv.
Követelmény
Köt. Teszt
5.1.28. Az EIKR-nek az adminisztrátori szerepkörökre kell korlátoznia a selejtezési folyamat kezelését.
Igen
Igen
5.1.29. Az EIKR-nek rögzítenie kell az eseménynaplóban az automatikus selejtezési tevékenységeket, azokról értesítenie kell egy adminisztrátori szerepkört.
Igen
Igen
5.1.30. Az EIKR-nek automatikusan értesítenie kell egy adminisztrátori szerepkört, ha esedékessé válik egy felülbírálati tevékenység.
Igen
Igen
5.1.31. Az EIKR-nek lehetővé kell tennie, hogy az adminisztrátori szerepkör az értesítésben szereplő felülbírálati tevékenységet továbbíthassa egy felülbírálói szerepkört betöltő személy felé.
Igen
Igen
5.1.32. Az EIKR-nek lehetővé kell tennie egy adminisztrátori szerepkör számára a megőrzési és selejtezési ütemtervek módosítását (az egyedi azonosító kivételével, lásd 5.1.6.).
Igen
Igen
5.1.33. Amikor egy adminisztrátori szerepkör elektronikus dossziékat vagy iratokat mozgat a besorolási séma osztályai között, az EIKR-nek az alábbi két lehetőséget kell felkínálnia:
Igen
Igen
5.1.34. Az EIKR-nek lehetővé kell tennie jogosultsággal rendelkező felhasználók számára selejtezési visszatartások elhelyezését osztályokon, dossziékon, aldossziékon és köteteken.
Igen
Igen
5.1.35. A selejtezési visszatartás nem akadályozhatja meg a megőrzési idők lejártát.
Igen
Rész ben
Igen
Igen
a célként megjelölt osztály megőrzési és selejtezési ütemterve írja felül a meglévő megőrzési és selejtezési ütemtervet; egy adminisztrátori szerepkör válassza ki a megfelelő megőrzési és selejtezési ütemterve(ke)t. Ez a követelmény az iratok 9.3.3. és 9.3.4. pontban megfogalmazott kivételes áthelyezésére vonatkozik. Azon ritka alkalmak során, amikor adminisztrátori szerepkörök iratokat mozgatnak, különös figyelmet kell fordítani a megőrzési és selejtezési ütemtervek kijelölésére és megváltoztatására, főleg a kiemelt iratok esetén.
Vö. Error! Reference source not found.. 5.1.36. Az EIKR-nek meg kell akadályoznia a selejtezési visszatartás alá eső egyedek és azok tartalmának (gyerekeinek) a törlését vagy bármilyen nemű selejtezési tevékenység végrehajtását. A törlést a 9.3. szakasz részletezi.
Hiv.
Követelmény
Köt. Teszt
5.1.37. Az EIKR-nek jogosult felhasználókra kell korlátoznia a selejtezési visszatartás eltávolítását.
Igen
Igen
5.1.38. Amikor egy jogosult felhasználó selejtezési visszatartást alkalmaz vagy távolít el, az EIKR-nek az alábbi információkat kell rögzítenie legalább az eseménynaplóban, de lehetőség szerint metaadatként is:
Igen
Igen
Ne m
Igen
5.1.40. Az EIKR-nek lehetővé kell tennie egy jogosult felhasználó számára, hogy egyetlen művelettel több, ugyanabból az okból elrendelt selejtezési visszatartást távolíthasson el.
Ne m
Igen
5.1.41. Az EIKR-nek lehetővé kell tennie, hogy egy osztályra, dossziéra, aldossziéra és kötetre egyidejűleg több selejtezési visszatartás lehessen érvényben vagy oly módon, hogy mindegyik közvetlenül az adott egyedre vonatkozik, vagy azért, mert az egyednél magasabb szinten lévő egyedhez rendelték. Ettől függetlenül a selejtezési visszatartással járó megőrzési kötelezettségek mindaddig érvényesek az egyedre, amíg az utolsó selejtezési visszatartást el nem távolítják.
Ne m
Igen
5.1.42. Az EIKR-nek lehetővé kell tennie egy jogosult felhasználó számára, hogy kereséseket végezzen és jelentést készíthessen adott selejtezési visszatartással ellátott egyedekről.
Ne m
Igen
5.1.43. Az EIKR-nek lehetővé kell tenni egy jogosult felhasználó számára, hogy „emlékeztetőt” állíthasson be, változtathasson meg és törölhessen, amely adott dátum elérkezésekor emlékezteti a felhasználót egy adott selejtezési visszatartás meglétéről.
Ne m
Igen
a visszatartás alkalmazásának vagy eltávolításának dátumát; a jogosult felhasználó azonosságát; a visszatartás okát. 5.1.39. Az EIKR-nek lehetővé kell tennie egy jogosult felhasználó számára, hogy azonos okból egyidejűleg több selejtezési visszatartást rendelhessen osztályok, dossziék, aldossziék és kötetek csoportjához egyetlen művelettel. A követelmény megengedi a jogosult felhasználónak, hogy ugyanabból az okból tartson vissza egyszerre több osztályt, dossziét stb.
5.2.
A selejtezési tevékenységek felülbírálása
Egyes környezetekben a megőrzési és selejtezési ütemterveket a selejtezés felülbírálata nélkül alkalmazzák. Más szervezeteknél a megőrzési és selejtezési ütemterv felülbírálathoz köti a selejtezési tevékenység végrehajtását. A felülbírálat az egyed metaadatainak és tartalmának figyelembe vételével dönt a selejtezési tevékenységről, mely jelentheti a megőrzési idő meghosszabbítását, az egyed áthelyezését egy másik rendszerbe, vagy annak teljes megsemmisítését.
Bizonyos iratok selejtezéséről törvényi előírások és egyéb szabályok rendelkeznek. A selejtezési tevékenységek felülbírálatának összhangban kell lennie ezekkel a szabályokkal. A felülbírálatnak a szervezet értékelési elveire és eljárásaira is ki kell térnie, amennyiben szükséges, a megfelelő levéltári szervek bevonásával, esetenként az ő kizárólagos döntésük alapján. Ezeknek a kérdéseknek a részletesebb tárgyalása azonban a MoReq2 hatáskörén kívül esik. Köt.
Teszt
5.2.1.
Az EIKR-nek automatikusan értesítenie kell egy adminisztrátori Nem szerepkört az előre meghatározott hosszúságú perióduson belül bekövetkező megőrzési és selejtezési ütemtervek eseményeiről.
Igen
5.2.2.
Az EIKR-nek a felülvizsgálandó osztályok, dossziék, aldossziék és kötetek, illetve a hozzájuk kapcsolódó metaadatok és megőrzési és selejtezési ütemtervek megjelenítésével kell támogatnia a felülbírálati folyamatot.
Igen
Igen
Hiv.
Követelmény
A gyakorlatban ez olyan eszközöket jelent, amelyek segítik az előrevissza navigációt a dossziék között és azokon belül, illetve a dossziék és iratok metaadatai között. 5.2.3.
Az EIKR-nek számon kell tartania az azonos iratok különféle megjelenítési formái közötti kapcsolatokat, és lehetővé kell tennie azok egyidejű és azonos módú selejtezését.
Igen
Igen
5.2.4.
Az EIKR-nek a felülbíráló számára az egyes osztályok, dossziék, aldossziék és kötetek felülbírálata során legalább az alábbi tevékenységek végrehajtását kell biztosítania:
Igen
Igen
kijelölés megsemmisítésre időpontban (lásd 5.3.);
azonnal
vagy
egy
későbbi
kijelölés áthelyezésre (lásd 5.3.) azonnal vagy egy későbbi időpontban; kijelölés további felülbírálatra azonnal vagy egy későbbi időpontban; kijelölés határozatlan idejű megőrzésre. A tevékenységek kijelölése történhet egy új megőrzési és selejtezési ütemterv elrendelésével, vagy más módon.
Követelmény
Köt.
Teszt
5.2.5.
Az EIKR köteles automatikusan rögzíteni a felülbírálat dátumát.
Igen
Igen
5.2.6.
Az EIKR-nek lehetővé kell tennie a felülbíráló számára, hogy megjegyzés formájában rögzíthesse az osztály, dosszié, aldosszié, kötet vagy irat metaadatai között a felülbírálati döntések indoklását.
Igen
Igen
5.2.7.
Az EIKR-nek megváltoztathatatlan módon számon kell tartania a felülbíráló által a felülbírálatok során hozott döntéseket, beleértve azok indoklását.
Igen
Igen
Az EIKR-nek figyelmeztetnie kell egy adminisztrátori szerepkört, ha Nem olyan iratot kellene megsemmisíteni, amelyre más irat hivatkozik. Ilyen esetben az EIKR köteles megakadályozni az irat megsemmisítését az alábbi javító tevékenységek felajánlásával:
Igen
Hiv.
A döntéseket célszerű metaadatként, és lehetőség szerint az eseménynaplóban is tárolni. 5.2.8.
adminisztrátori szerepkör általi jóváhagyás vagy visszavonás; jelentés készítése az érintett irat(ok)ról és a rá(juk) vonatkozó hivatkozásokról.
5.3.
Áthelyezés, exportálás és megsemmisítés
A szervezeteknek szükségük lehet az EIKR-ben tárolt iratok átküldésére más helyszínekre, vagy más rendszerekbe levéltárba adás vagy egyéb célokból. Ezt nevezzük összefoglalóan „áthelyezésnek”. Az áthelyezés lehetséges okai: az iratok tartós megőrzése jogi, adminisztrációs vagy kutatási megfontolásból; külső szolgáltatások igénybe vétele az iratok kezeléséhez közép- és hosszútávon. Ez a tevékenység gyakran az iratok áthelyezését eredményezi egy másik EIKR környezetbe. Az áthelyezés kezdetben nem teljes, először ugyanis az iratoknak csak a másolata kerül át a másik helyre vagy rendszerbe, az eredeti példányok érintetlenek maradnak mindaddig, amíg a másik rendszer vissza nem jelez az áthelyezés sikerességéről. Az exportálás ezzel szemben az iratok és nagyobb egységeik (pl. dossziék, kötetek) lemásolását jelenti egy másik rendszer részére, miközben az eredeti példányok érintetlenek maradnak. A folyamat végén az iratok nem törlődnek az eredeti rendszerből. Az áthelyezés valójában két folyamatból áll: először másolat készül exportálásra az iratokról és a kapcsolódó metaadatokról, illetve az eseménynaplóról, majd ezt követi az eredeti példányok megsemmisítése. Mindhárom esetben (áthelyezés, exportálás és megsemmisítés) általános elvárás a művelet szigorúan szabályozott végrehajtása. Az iratokon végzett műveletekkel egyidejűleg a hozzájuk kapcsolódó metaadatokról és eseménynaplóról is dönteni kell.
Jelen szövegkörnyezetben a „megsemmisítés” nem egyenértékű a „törléssel”. Az iratok törlésének körülményeiről a 9.3. szakaszban esik szó. Hiv. 5.3.1.
Követelmény
Köt.
Teszt
A hivatalos MoReq2 XML séma elkészülte után az EIKR-nek képesnek kell lennie iratok exportálására a sémának megfelelő formában.
Igen
Rész
Lásd még a 6.2.1. követelményt az iratok tömeges importálásával kapcsolatban. A két követelmény együtt a MoReq2 követelményeinek eleget tevő EIKR-ek együttműködését növeli. 5.3.2.
Az EIKR köteles az iratok áthelyezése vagy exportálása során a részüket képező összes állományt áthelyezni vagy exportálni, megőrizve a közöttük fennálló kapcsolatokat.
Igen
Rész
5.3.3.
Az EIKR-nek jól meghatározott folyamatot kell biztosítania az iratok, a hozzájuk kapcsolódó metaadatok és eseménynapló adatok áthelyezéséhez egy másik rendszerbe, vagy egy másik szervezethez.
Igen
Rész
5.3.4.
Az EIKR-nek képesnek kell lennie az iratok és kapcsolódó metaadataik exportálására az OASIS szabványban (lásd 7. függelék) meghatározott beszolgáltatói információcsomag (SIP, Submission Information Package) formájában.
Nem
Igen
Igen
Rész
Igen
Rész
Lásd a kibocsátott információs csomagok (DIP, Dissemination Information Package) küldéséről szóló hasonló 11.7.12. követelményt. 5.3.5.
Az EIKR az osztályok, dossziék, aldossziék és kötetek áthelyezésekor vagy exportálásakor köteles áthelyezni vagy exportálni: (osztályok esetén) az osztályba sorolt dossziékat és iratokat; (dossziék esetén) aldossziékat;
a
dossziéban
elhelyezett
köteteket
és
a kijelölt dossziékba, aldossziékba és kötetekbe tartozó iratokat; az imént felsorolt egyedekhez kapcsolódó összes vagy néhány kiválasztott metaadatot; az imént felsorolt egyedekhez kapcsolódó teljes vagy részleges eseménynaplót. Bár az EIKR-nek támogatnia kell a metaadatok és az eseménynapló exportálását, várhatóan nem minden célrendszer tart erre igényt. 5.3.6.
Amennyiben az EIKR metaadatokkal együtt exportálja vagy helyezi át az iratokat, az implicit metaadatokat explicit módon kell ábrázolni. Más szóval az osztályokhoz, dossziékhoz, aldossziékhoz, kötetekhez és iratokhoz kapcsolódó összes metaadat értékét explicit módon kell feltüntetni akkor is, ha azokat az EIKR implicit módon tárolta. Lásd a 9.3. függelékben a példákat.
Hiv. 5.3.7.
Követelmény
Köt.
Teszt
Iratok tetszőleges csoportjának exportálása vagy áthelyezése során az EIKR-nek az alábbi tevékenységek közül legalább egyet kell támogatnia:
Igen
Rész
Igen
Rész
Igen
Rész
Igen
Igen
az iratokhoz rendelt megőrzési és selejtezési ütemtervek exportálása vagy áthelyezése oly módon, hogy a célrendszer képes legyen újrahasznosítani az ütemterveket; az egyes iratcsoportokhoz rendelt megőrzési és selejtezési ütemtervekről és azok jellemzőiről készített egy vagy több jelentés nyomtatása. 5.3.8.
Iratok tetszőleges csoportjának exportálása vagy áthelyezése során az EIKR-nek az alábbi tevékenységek közül legalább egyet kell támogatnia: az iratokra vonatkozó hozzáférési szabályok exportálása vagy áthelyezése olyan formában, amely lehetővé teszi azok ismételt felhasználását az áthelyezett vagy exportált iratokon a célrendszerben; az egyes iratcsoportokra érvényes hozzáférési szabályokat és azok jellemzőit bemutató egy vagy több jelentés nyomtatása.
5.3.9.
Az EIKR-nek képesnek kell lennie egy dosszié vagy egy osztály tartalmának exportálására vagy áthelyezésére egyetlen műveletsorozatban az alábbiak figyelembevételével: az elektronikus iratok tartalma és szerkezete nem változik; az elektronikus iratot alkotó összes állomány (amennyiben az irat több állományt tartalmaz) egy egységként kerül exportálásra; a művelet végrehajtása során nem sérülhetnek az iratok és a kapcsolódó metaadatok és eseménynaplók között fennálló kapcsolatok; a fogadó EIKR-ben való újbóli összeállítás érdekében az osztályok, dossziék, aldossziék, kötetek és iratok közötti kapcsolatok nem sérülhetnek.
5.3.10. Amennyiben az exportálásra vagy áthelyezésre kerülő dossziék vagy aldossziék valamelyike más dossziéban tárolt iratra mutat (lásd 3.4.24.), az EIKR köteles a mutató helyett a teljes iratot áthelyezni vagy exportálni. A követelmény célja a küldő és a fogadó rendszer közötti mutatók feloldásából származó nehézségek elkerülése.
Köt.
Teszt
5.3.11. Az EIKR-nek képesnek kell lennie az iratokat az iktatásuk során használt formátumban áthelyezni vagy exportálni.
Igen
Igen
5.3.12. Az EIKR-nek képesnek kell lennie az iratokat azok bármelyik megjelenési formájában áthelyezni vagy exportálni.
Igen
Igen
5.3.13. Az EIKR-nek képesnek kell lennie az áthelyezésre vagy exportálásra szánt iratokat meghatározott formátumban mozgatni.
Igen
Rész ben
Igen
Igen
Igen
Igen
Hiv.
Követelmény
Elképzelhető például XML vagy más nyílt formátum alkalmazása. A követelmény a hosszú megőrzési idejű iratok időtálló formátumba történő automatikus átalakítását támogatja bizonyos idő elteltével, megőrizve az iratok hitelességét és integritását. 5.3.14. Az EIKR köteles megőrizni az áthelyezés alatt álló iratgyűjteményeket, iratokat és a kapcsolódó adatokat legalább addig, amíg visszajelzés nem érkezik a sikeres áthelyezésről. Ez a biztonsági intézkedés garantálja, hogy az iratok addig nem semmisülnek meg, amíg a fogadó fél vissza nem jelez azok sikeres beérkezéséről. Az áthelyezés során bekövetkező hibák jelentésével kapcsolatban lásd a 9.2.30. és a 9.2.31. követelményeket. 5.3.15. Az EIKR-nek törölnie kell az áthelyezés alatt álló iratgyűjteményeket, iratokat és a kapcsolódó adatokat a sikeres áthelyezésről érkező visszajelzés után, kivéve a csonkként megmaradó metaadatokat. Lásd 5.3.19.
Köt.
Teszt
Nem
Rész
5.3.17. Az EIKR-nek lehetővé kell tennie felhasználók által meghatározott metaadat-elemek felvételét az áthelyezésre kerülő elektronikus dossziékhoz levéltári kezelés céljából.
Nem
Igen
5.3.18. Az EIKR-nek biztosítania kell, hogy az iratok megsemmisítésekor az irat összes megjelenítési formája is megsemmisül.
Igen
Igen
Igen
Igen
Hiv.
Követelmény
5.3.16. Az EIKR-nek képesnek kell lennie a besorolási séma egy osztályának a teljes tartalmát exportálni egyetlen műveletsorozatban az alábbiak figyelembevételével: az exportálás megőrzi a dossziék egymáshoz viszonyított helyzetét a besorolási sémán belül a dossziék szerkezetének könnyű visszaállítása végett; az osztályok tartalma mellett a szülő ág helyreállításához elegendő metaadat kerül exportálásra.
Amennyiben egy irat több dossziéban is szerepel (lásd 3.4.24.), az iratot és annak minden megjelenítési formáját el kell távolítani a dossziéból, de véglegesen nem törölhető, amíg az irat összes előfordulását meg nem semmisítik. 5.3.19. Az EIKR-nek lehetővé kell tennie metaadatcsonk megőrzését a megsemmisített vagy áthelyezett osztályok, dossziék, aldossziék, kötetek és az osztályokban közvetlenül tárolt iratok esetén. Egyes környezetekben kívánatos megőrizni a megsemmisített iratok adatainak egy részét, köztük legalább az irat bekerülésének dátumát, illetve az iratot és besorolási sémához fűződő kapcsolatát egyértelműen azonosító metaadatokat. Lásd a MoReq2 metaadatmodellt. A követelmény célja, hogy a szervezet anélkül is számon tudja tartani, milyen iratok birtokában volt, azok mikor kerültek be és lettek megsemmisítve, hogy az iratokat és dossziékat egyébként jellemző összes metaadatot el kellene tárolnia.
Köt.
Teszt
Igen
Igen
5.3.21. Az EIKR-nek lehetővé kell tennie egy adminisztrátori szerepkör számára, hogy további metaadatokat válasszon ki megőrzésre a metaadat csonkban.
Igen
Igen
5.3.22. Az EIKR-nek lehetővé kell tennie a metaadat csonkok exportálását az iratok exportálásakor.
Igen
Igen
többszöri
Igen
Igen
5.3.24. Adatok exportálásakor vagy áthelyezésekor az EIKR-nek kérésre jelentést kell készítenie az exportált vagy áthelyezett iratokról azok biztonsági kategóriáinak figyelembevételével.
Nem
Igen
Hiv.
Követelmény
5.3.20. A metaadat csonk (lásd 5.4.19.) legalább az alábbi adatokat tartalmazza: a megsemmisítés vagy áthelyezés időpontja; teljesen minősített besorolási kód; cím; leírás; a megsemmisítésért vagy áthelyezésért felelős felhasználó; a megsemmisítés vagy áthelyezés oka (hivatkozás a megőrzési és selejtezési ütemtervre, vagy kézzel beírt indoklás); az áthelyezés célrendszere által kiadott hivatkozás az áthelyezett iratok visszakeresésének segítése érdekében.
A követelmény az EIKR-ek közötti átjárhatóságot növeli. 5.3.23. Az EIKR-nek exportálását.
lehetővé
kell
tennie
az
információk
6.
IKTATÁS ÉS IRATTÁ NYILVÁNÍTÁS
Áttekintés Ez a fejezet az iratok EIKR-be történő iktatásával foglalkozik. Az első szakasz (6.1.) a hagyományos iktatási folyamatot írja le. Az azt követő szakasz (6.2.) az iratok tömeges importálását részletezi, melyet a kiemelt témaként kezelt elektronikus levelezésről szóló szakasz (6.3.) követ. A 6.4. szakasz az irattípusokat részletezi, a 6.5. pedig a szkennelő és képfeldolgozó rendszerekkel foglalkozik. Szakkifejezések Az információ bevitelére a legáltalánosabb kifejezés a „rögzítés”, amely bizonyos szövegkörnyezetekben az információtechnológiában elterjedt „mentés” szinonimája. Ebben az értelemben az InterPARES 2 projekt terminológiai adatbázisában használt „iktatás” kifejezéssel egyenértékű („digitális objektum konkrét példányának rögzítése vagy mentése”). Rögzíteni többek között iratokat, metaadatokat, ritkább esetben dokumentumokat lehet. Mivel az EIKR-ek (elvétve) nemcsak iratok, hanem dokumentumok rögzítésére is alkalmasak lehetnek, a „rögzítés” kifejezés pontatlan. Iratok esetében iktatásról beszélünk, amely (a MoReq értelmében) magában foglalja az irat besorolásának, szűkebb értelemben vett nyilvántartásba vételének (egyedi azonosítóval való ellátásának, „regisztrálásának”) és lezárásának folyamatát. Az „iktatás” szinonimájának tekinthető az „irattá nyilvánítás”, amely egyaránt alkalmazható az EIKR-en kívül keletkezett és a korábban az EIKR-ben rögzített dokumentumokra is. A formális definíciók a 13.1. szakaszban olvashatók.
6.1.
Iktatás
Az üzleti folyamatok során keletkezett vagy fogadott elektronikus dokumentumok belső és külső forrásból egyaránt származhatnak, formátumuk és szerzőik eltérőek lehetnek, felépítésüket tekintve pedig egy vagy több állományból (lásd Szószedet) állhatnak. Az iratok egy része a szervezeten belül keletkezik valamely üzleti folyamat részeként. Az iratok másik része különféle kommunikációs csatornákon keresztül jut el a szervezethez, például elektronikus levél, facsimile, (beszkennelhető) hagyományos postai levél, vagy kézírás formájában. Az iratok beérkezésének gyakorisága és mennyisége eltérő. Egy jó kezelési gyakorlatot megvalósító, rugalmas iktatórendszertől elvárható, hogy megfeleljen az irattá nyilvánítás változatos követelményeinek.
Hiv. 6.1.1.
Követelmény
Köt.
Teszt
Az EIKR iktatási folyamatának biztosítania kell a megfelelő ellenőrzést és eszközöket ahhoz, hogy a felhasználók:
Igen
Rész ben
az állomány formátumától, a kódolástól és egyéb technológiai jellemzőktől függetlenül iktathassák az elektronikus iratokat; biztosíthassák, hogy minden irat a besorolási séma egy osztályához kapcsolódhasson; biztosíthassák, hogy minden irat legalább egy dossziéhoz vagy osztályhoz tartozik. Az állományformátum kifejezés meghatározása a Szószedetben található. Jelen követelmény annyit fogalmaz meg, hogy az EIKR képes legyen tetszőleges formátumú irat iktatására. A követelmény nem tesztelhető egyértelműen, ugyanakkor nem jelenti azt, hogy az EIKR-nek az összes formátumot meg kell tudnia jeleníteni (lásd Szószedet). Éppen ezért a MoReq2 nem sorolja fel az iktatásra szánt iratok lehetséges formátumait, mivel azok a szoftverek fejlődésével párhuzamosan időről időre változnak. A kétségek eloszlatása végett az alábbi (nem teljes) felsorolás az iratok formátumának változatosságát szemlélteti: asztali alkalmazások, például irodai szoftvercsomagok kimenete; e-mailek (elektronikus levelek) (lásd 6.3. szakasz); hang; adatbázis; hordozható dokumentumformátum; beszkennelt képek; videó; weblapok. Egyes esetekben az EIKR-be egészen szokatlan típusú iratokat iktathatnak, például:
Hiv.
Követelmény
Köt.
Teszt
Igen
Rész ben
blogokat; tömörített állományokat; elektronikus naptárakat; elektronikus űrlapokat; földrajzi információs rendszerből származó adatokat; más számítógépes alkalmazásból (pl. bérszámfejtő rendszer, számítógépes tervezőprogram) származó adatokat; azonnali üzenetküldő rendszerek naplóit; multimédiás dokumentumokat; web-alapú tranzakciók kivonatait; iratokra hivatkozó iratokat; szoftver-forráskódot és -dokumentációt; strukturális adatokat (pl. EDI tranzakciók); webes közvetítéseket; wiki oldalakat. A felsorolások nem teljesek. 6.1.2.
Az EIKR nem korlátozhatja sem az egyes osztályokba, dossziékba, aldossziékba és kötetekbe iktatható iratok, sem az EIKR-ben összesen tárolt iratok számát. Ha túl sok iratot tárolnak egy kötetben, aldossziéban stb., csökken a rendszer kezelhetősége, így ez nem javasolt. A követelmény célja, hogy lehetőséget biztosítson nagyszámú iratok együttes kezelésére, amikor az elkerülhetetlen (pl. tranzakciós környezetekben).
Követelmény
Köt.
Teszt
6.1.3.
Több állományból álló irat iktatásakor az EIKR az irat minden állományát köteles iktatni.
Igen
Rész ben
6.1.4.
Az egynél több állományból álló elektronikus irat iktatásakor az EIKRnek lehetővé kell tennie az irat egyetlen egységként történő kezelését, megőrizve az irat szerkezeti egységét és az iratot alkotó állományok közötti kapcsolatokat.
Igen
Rész ben
Nem
Rész ben
Hiv.
Több állományból álló irat például egy ábrákkal teli weboldal, egy külső táblázathoz kapcsolt szövegszerkesztővel készített dokumentum. Egyes esetekben az állományok olyan hivatkozásokat tartalmaznak, melyek egyszerű másolással nem vihetők át az EIKR tárhelyére. Egy weboldal például olyan grafikus és egyéb típusú objektumoknak a címére (URL-jére) hivatkozhat, amely a tárhelyen kívülre mutat; a kapcsolt táblázatok ugyancsak tartalmazhatnak tárhelyen kívüli címekre mutató hivatkozásokat (ezek rendszerint az operációs rendszerben használt állománynevek). Lásd a következő követelményt. 6.1.5.
Az egynél több állományból álló elektronikus irat iktatásakor az EIKR megváltoztathatja az iratot annak megjeleníthetősége érdekében. A gyakorlatban ez az iratot alkotó állományok belső hivatkozásainak módosítását jelenti. A követelmény csak az EIKR számára előírt formátumokra vonatkozik, ismeretlen állományformátumokra nem. A támogatott formátumok közé tartozhatnak: ábrákra és egyéb objektumokra hivatkozó HTML oldalak; más táblázatokra hivatkozó táblázatok. Az ilyen jellegű változtatások ellentmondanak az iratok megváltoztathatatlanságának, ugyanakkor elkerülhetetlenek, ha a rendszer meg szeretné őrizni a több állományból álló iratok funkcionalitását és hitelességét. A változtatásokat minden esetben rögzíteni kell az eseménynaplóban (lásd a következő követelményt). A hivatkozások módosításának alternatívája az irat átalakítása statikus megjelenést biztosító archiválási formátumra (pl. PDF/A), lásd a 11.7.8. követelményt. Utóbbi megközelítés hátránya, hogy elvesznek a hivatkozások.
Követelmény
Köt.
Teszt
6.1.6.
Amennyiben az EIKR módosítja az irat belső hivatkozásait az iktatás során, köteles naplózni a változtatások részleteit az eseménynaplóban.
Igen
Igen
6.1.7.
Az iratok állományainak iktatásakor az EIKR köteles automatikusan rögzíteni az állományok formátumát (lásd Szószedet), beleértve annak verzióját, az állomány metaadatai között.
Igen
Rész ben
Igen
Igen
Nem
Igen
Hiv.
Ez a követelmény az iratok hosszú távú digitális megőrzését és hozzáférhetőségét támogatja. Lásd 11.7. szakasz. Az állomány formátumára következtetni lehet az állomány nevének kiterjesztéséből, például „.htm”, vagy „.pdf”, egyes esetekben azonban nem egyértelmű a formátum. A „.doc” kiterjesztés például több, egymástól független formátum bármelyikére vonatkozhat. A kiterjesztés nem utal az állomány formátumának verziószámára, esetenként pedig magára a formátumra sem. Sok esetben ugyanakkor teljes mértékben elfogadható a kiterjesztés felhasználása, a hosszú távú megőrzést és pontosságot (pl. számít a színtér) igénylő környezetekben azonban ennyi nem elég. Az állományformátumok száma egyre csak nő, miközben a meglévő formátumok is gyakran változnak. Ennél fogva nem várható el az EIKRtől, hogy minden lehetséges formátumot feltüntessen. Az EIKR-től annyi várható el, hogy határozza meg a felismerhető állományformátumok listáját; általánosan elfogadott állományformátum-adatbázist használjon, lehetőleg olyat, amelyet kifejezetten a digitális tartalmak megőrzése céljából hoztak létre. Az EIKR-t használó szervezetnek mindkét esetben ellenőriznie kell, hogy a formátumok listája kielégíti-e a hosszú távú megőrzés által támasztott követelményeket. 6.1.8.
Az EIKR-nek ellenőriznie kell az iratok iktatásakor a megadott metaadat-elemek értékeit, legalább a MoReq2 metaadatmodell szabályai alapján. Lásd még a 6.1.34. követelményt ebben a szakaszban.
6.1.9.
Az EIKR-nek támogatnia kell a metaadat-elemek számellenőrző algoritmusok segítségével.
validálását
Egy dossziét azonosíthat egy tizenhat jegyű szám, melynek utolsó számjegye az első tizenöt értékétől függ (pl. összegük 10-zel való osztásának a maradéka). Megengedett, hogy a rendszer alkalmazás programozói interfészen keresztül biztosítsa a szervezeteknek saját ellenőrző algoritmus használatát.
Hiv. 6.1.10.
Követelmény
Köt.
Teszt
Az EIKR-nek olyan elektronikus iratok iktatását is lehetővé kell tennie, amelyeknél nem áll rendelkezésre a létrehozásukhoz használt szoftver.
Igen
Igen
Tegyük fel, hogy egy EIKR felhasználó e-mail csatolmányként egy projekttervet és CAD/CAM tervrajzot kap. Ha a felhasználó nem rendelkezik a projektterv megjelenítésére alkalmas vagy CAD/CAM alkalmazással, nem nézheti meg a csatolmányokat. Ennek ellenére a felhasználó iktathatja mindkét csatolmányt az EIKR-ben, ami elképzelhető, hogy meg tudja jeleníteni azokat, de ez nem elvárás. 6.1.11.
Az EIKR-nek képesnek kell lennie a MoReq2 metaadat-modellnek megfelelő metaadatok rögzítésére.
Igen
Igen
6.1.12.
Az EIKR-nek képesnek kell lennie arra, hogy meghatározott dokumentumtípusok adminisztrátori szerepkör által kijelölt mezőinek az értékeit felhasználva automatikusan hozzárendelje az irathoz a MoReq2 metaadat-modellben előírt metaadat-elemeket.
Nem
Igen
A követelményben megfogalmazott funkcionalitás csak néhány elektronikus objektumra vonatkozik, például adott sablon szerint, adott szövegszerkesztővel készített levelekre. Számos dokumentumtípus, köztük néhány népszerű irodai dokumentum és PDF állomány tartalmaz a felhasználók által beállítható metaadat-elemeket. Lehetővé kell tenni, hogy az EIKR segítségével lekérdezhessék e mezők értékét, és ezeket metaadatként az iratokhoz kapcsolhassák. 6.1.13.
Az EIKR-nek lehetővé kell tennie a konfigurálás során meghatározott metaadat-elemek értékének rögzítését, és köteles azokat megőrizni az irattal szoros kapcsolatban.
Igen
Igen
6.1.14.
Az EIKR-nek lehetővé kell tennie az olyan iratok átmeneti tárolását, amelyeket a felhasználók iktatni szeretnének, de nem áll rendelkezésükre az összes kötelezően kitöltendő metaadatelem értéke.
Nem
Igen
Más szóval, az EIKR-nek lehetőséget kell biztosítania a hiányos metaadatokkal ellátott (azaz az iktatás követelményeit nem kielégítő) iratok tárolására. Az ily módon tárolt iratokról a rendszernek jelentést kell készítenie, és nyomon kell követnie a metaadat-elemek állapotát. A követelményből nem következik azonban, hogy a hiányos iratokat a hagyományos iratokkal azonos módon kell kezelni, tehát nem szükséges azokat megjeleníteni, exportálni, áthelyezni stb. A MoReq2 nem írja elő a hiányos metaadatokkal rendelkező iratok kezelésének módját. Csak a szerkeszthető metaadat értékeket lehet később átírni, a rögzített metaadatok (pl. e-mail érkezésének adatai) megváltoztathatatlanok.
Követelmény
Köt.
Teszt
6.1.15.
Az EIKR-nek biztosítania kell, hogy az elektronikus irathoz tartozó bizonyos metaadat-elemek értékét csak adminisztrátori szerepkör módosíthassa a 12. fejezetben rögzített szabályokkal összhangban.
Igen
Igen
6.1.16.
Az EIKR-nek biztosítania kell, hogy iktatás után az irat legalább egy osztályhoz vagy dossziéhoz (esetleg aldossziéhoz) tartozzon.
Igen
Igen
6.1.17.
Az EIKR-nek az elektronikus dokumentumok rögzítésekor automatizált segítséget kell nyújtania azzal, hogy a rendszer a lehető legtöbb dokumentumtípus lehető legtöbb metaadatát rendelkezésre bocsátja.
Nem
Nem
Igen
Igen
Hiv.
A követelmény mögöttes szándéka: a felhasználók által begépelendő adatmennyiség csökkentése (a tapasztalat azt mutatja, hogy a felhasználók hajlamosak visszautasítani azt a rendszert, amelyikben sok metaadatot kell begépelniük); növeli a metaadatok pontosságát. A kiválasztott metaadatokat és dokumentumtípusokat a környezet határozza meg, némi útmutatót azonban a metaadatmodell is nyújt. 6.1.18.
Az EIKR-nek automatizált segítséget kell nyújtania a kimenő és belső dokumentumok (pl. emlékeztetők, szövegszerkesztővel készített, meghatározott elrendezésű és formátumú levelek) irattá nyilvánításában azáltal, hogy az alábbi metaadatokat automatikusan rendelkezésre bocsátja: dátum (a dokumentum törzsében); címzett(ek); másolatot kap(nak); címsor (tárgy); szerző(k); belső hivatkozás hivatkozás”);
(általános
megjelenési
formája
a
„saját
amennyiben ezek az adatok elérhetők. A MoReq2 nem írja elő az irodai dokumentumok és e-mailek formátumát, se a létrehozásukhoz használandó szoftvert. A metaadatok rendelkezésre bocsátása történhet a metaadatok megkeresésével az iraton belül, a metaadatok megkeresésével egy sablon alapján, vagy bármilyen más módon.
Hiv. 6.1.19.
Követelmény Az EIKR köteles rögzíteni az irat metaadatai eseménynaplóban az irat iktatásának időpontját.
között
és
az
Köt.
Teszt
Igen
Igen
Igen
Igen
Amennyiben az irat egyedi azonosítójának része az iktatás dátuma és időpontja, nem kötelező azokat ismételten eltárolnia, ha az azonosítóból egyértelműen kinyerhetők. A MoReq2 nem írja elő az időpont precizitását, a legtöbb rendszer ugyanakkor másodperces vagy ennél finomabb pontossággal dolgozik. Bizonyos helyeken jogszabály írja elő, hogy az iratokat kizárólag tanúsított hatóság vagy eszköz láthatja el időbélyeggel. 6.1.20.
Az EIKR-nek meg kell tudnia jeleníteni az iktatott iratok metaadatait a képernyőn, beleértve a konfiguráláskor kijelölt metaadatokat. A konfiguráláskor meghatározott metaadatok a 12. fejezet megfelelő szakaszának metaadatai közül kerülhetnek ki.
6.1.21.
Az EIKR-nek biztosítania kell, hogy minden iktatott irat rendelkezik a kötelező metaadatokkal.
Igen
Igen
6.1.22.
Iktatáskor az EIKR-nek fel kell szólítania a felhasználót automatikusan ki nem töltött metaadatok értékeinek beállítására.
az
Igen
Igen
6.1.23.
Az EIKR-nek támogatnia kell, hogy az osztályokhoz, dossziékhoz, aldossziékhoz és iratokhoz egyszerre több tárgyszót lehessen rendelni.
Igen
Igen
A MoReq2 nem teszi kötelezővé, hogy kötetekhez is lehessen tárgyszót fűzni.
Követelmény
Köt.
Teszt
6.1.24.
Az EIKR-nek lehetővé kell tennie egy adminisztrátori szerepkör számára, hogy a rendszer konfigurálásakor beállíthassa, kötelező-e tárgyszavakat fűzni az osztályokhoz, dossziékhoz és aldossziékhoz.
Nem
Igen
6.1.25.
Az EIKR-nek lehetővé kell tennie, hogy egynél több egyedhez (osztályhoz, dossziéhoz stb.) lehessen ugyanazt a tárgyszókombinációt rendelni.
Igen
Igen
6.1.26.
Az EIKR-nek lehetővé kell tennie, hogy egyed létrehozásakor a felhasználó az egyedhez tartozó tárgyszavakat másik egyed tárgyszavainak lemásolásával állíthassa be, egyetlen művelettel.
Nem
Igen
6.1.27.
Az EIKR-nek lehetővé kell tennie a felhasználó számára, hogy az iratok azonosítóit több nyelven is megadhassa.
Nem
Igen
6.1.28.
Az EIKR-nek lehetőséget kell biztosítania a tárgyszavak és egyéb metaadat-elemek értékeinek kötött szótárból (vagy megengedett kifejezések előre rögzített listájából) való kiválasztására vagy validálására.
Igen
Igen
Hiv.
A rendszer használhat követelményt.
tezauruszokat.
Lásd
még
a
11.8.11.
6.1.29.
Az EIKR-nek lehetővé kell tennie további leíró és egyéb jellegű metaadatok bevitelét iktatáskor, vagy a feldolgozás későbbi szakaszában.
Igen
Igen
6.1.30.
Az EIKR-nek figyelmeztetnie kell a felhasználót, ha az iktatott objektum címe már szerepel az azt tartalmazó egyeden belül, vagy át kell neveznie az azonos című objektumot.
Igen
Igen
Igen
Igen
Lásd még 11.8.6. 6.1.31.
Az EIKR-nek lehetőséget kell biztosítania egy adminisztrátori szerepkör vagy jogosult felhasználó számára, hogy kiegészíthesse az elektronikus irat címét. Az EIKR ezen szolgáltatása a szervezet igényétől függően használható.
Hiv. 6.1.32.
Követelmény
Köt.
Teszt
Amikor a felhasználó olyan dokumentumot szeretne irattá nyilvánítani, amelyik több verzióban létezik, az EIKR-nek az alábbi lehetőségek közül kell legalább egyet felkínálnia a felhasználó számára:
Igen
Igen
Nem
Rész ben
Nem
Igen
Nem
Igen
a dokumentum összes verziójának egyetlen irattá nyilvánítása; a dokumentum egy adott verziójának irattá nyilvánítása; a dokumentum minden egyes verziójának külön irattá nyilvánítása. 6.1.33.
Az EIKR-nek automatizált támogatást kell biztosítania az elektronikus iratok besorolásához legalább az alábbi módszerek egyikével: a besorolási séma egy részének felkínálása a felhasználó vagy szerepkör számára; a felhasználó által legutóbb használt osztályok és dossziék felkínálása; a felhasználó által leggyakrabban használt osztályok és dossziék felkínálása; az irat metaadat-elemeiből kikövetkeztetett osztályok és dossziék felkínálása (pl. a címben vagy az e-mail tárgyában előforduló fontosabb tárgyszavak alapján); az irat tartalmából felkínálása.
6.1.34.
kikövetkeztetett
osztályok
és
dossziék
Az EIKR-nek lehetővé kell tennie, hogy egy irat iktatási folyamatában több felhasználó vehessen részt. Az EIKR-nek biztosítania kell, hogy az iktatási folyamatot a felhasználók feloszthassák egymás között. Ez rendszerint azt jelenti, hogy az egyik felhasználó kitölt néhány metaadatot, majd továbbítja az iratot a következő felhasználónak, aki pótolja a hiányzó metaadatokat, és besorolja az iratot.
6.1.35.
Az EIKR-nek egyszerű munkafolyamat-vezérlő eszközöket kell biztosítania a dokumentum iktatás előtti vétózásának, a döntések naplózásának, a döntések és indoklásaik együttműködésének egyszerű irányításához. Mindez alapvető munkafolyamat-vezérlő képességeket igényel. A követelmény szándékosan mellőzi a 10. fejezetben részletezett munkafolyamat-szolgáltatásokat.
Hiv. 6.1.36.
Követelmény
Köt.
Teszt
Az EIKR-nek alkalmazás programozói interfészt kell biztosítania a más alkalmazásokból vagy rendszerekből érkező iratok és tranzakciók valós idejű iktatására.
Nem
Nem
Nem
Igen
Az 1.4. szakasz értelmében az elektronikus iratok kezelése gyakran egy nagyobb rendszer részét képezi. Ilyen helyzetekben elvárható, hogy az EIKR képes legyen más rendszerekből (pl. CRM [Customer Relationship Management – Ügyfélkapcsolat kezelés], vagy üzletághoz kapcsolódó rendszerek) iratokat fogadni és iktatni alkalmazásprogramozói interfészen (API-n) keresztül. 6.1.37.
Amennyiben lehetséges, az EIKR-nek figyelmeztetnie kell a felhasználót, ha olyan e-mailt szeretne iratként iktatni, amelyik már szerepel az iktatás céljaként megjelölt dossziéban vagy osztályban. A MoReq2 nem határozza meg, hogyan lehet az e-mailt azonosítani, az internetes üzenetazonosító (message-ID) azonban megfelelhet a legtöbb igénynek. Sok esetben ez logikailag lehetetlen, például amikor olyan dossziéba iktatták az e-mailt iratként, amelyikhez a felhasználónak nincs hozzáférése.
6.1.38.
Amennyiben lehetséges, az EIKR-nek figyelmeztetnie kell a felhasználót, ha olyan iratot szeretne iktatni (kivéve az e-maileket, melyekkel a 6.1.37. követelmény foglalkozik), amelyiknek a tartalma megegyezik az iktatás céljaként megjelölt dosszié vagy osztály egyik iratjának a tartalmával.
Nem
Igen
6.1.39.
Amennyiben lehetséges, az EIKR-nek figyelmeztetnie kell a felhasználót, ha olyan iratot szeretne iktatni (kivéve az e-maileket, melyekkel a 6.1.37. követelmény foglalkozik), amelyiknél az azonosító metaadatok értéke megegyezik az iktatás céljaként megjelölt dosszié vagy osztály egyik iratjának azonos metaadataival.
Nem
Igen
Nem
Nem
Az iratokat ebben a követelményben az alábbi metaadatok azonosítják: Cím (Title); Dátum (Date); Szerző (Author); Címzett (Addressee). 6.1.40.
Amennyiben lehetséges, az EIKR-nek figyelmeztetnie kell a felhasználót, ha olyan iratot szeretne iktatni, amelyik a jövőbeli megbízhatóság szempontjából hiányos vagy inkonzisztens. Ilyen például az elektronikus aláírás nélküli megrendelés, vagy az ismeretlen beszállító által kiállított számla.
Hiv. 6.1.41.
Követelmény
Köt.
Teszt
Az EIKR-nek lehetővé kell tennie egy adminisztrátori (nem felhasználói) szerepkör számára, hogy irattal bővíthessen korábban lezárt kötetet, feltéve, hogy az irat ideje megelőzi a kötet lezárásának időpontját. Ilyen esetben:
Igen
Igen
az EIKR-nek köteleznie kell az adminisztrátori szerepkört, hogy metaadat formájában indokolja meg a kivételes tevékenység okát mind a kötet, mind az irat metaadatai között; az EIKR-nek automatikusan naplóznia kell a műveletet az eseménynaplóban. A művelet hatására a kötet lezárásának időpontját leíró metaadat értéke nem változik. 6.1.42.
A követelmény célja az esetleges felhasználói hibák (ilyen pl. a kötetek véletlen lezárása) kijavítása. Ennél fogva fontos, hogy a kötet utólagos bővítését mindig megfelelő magyarázat kísérje.
6.1.43.
A MoReq2 nem írja elő a kötet utólagos bővítésének a pontos menetetét, elképzelhető például a kötet átmeneti megnyitása majd ismételt lezárása.
6.2.
Tömeges importálás
Az EIKR-be többféleképpen is érkezhetnek tömegesen iratok, például: iratok tömeges áthelyezése kompatibilis EDKR-ből; iratok tömeges áthelyezése kompatibilis EIKR-ből; több, azonos típusú iratot (pl. napi számlákat) tartalmazó kompatibilis adatállomány formájában; kompatibilis szkennelő vagy képfeldolgozó rendszerből; operációs rendszerbeli könyvtárak hierarchiájából. Az EIKR köteles fogadni ezeket az iratokat, és eszközöket kell biztosítania az importált iratok iktatási folyamatának támogatásához, valamint az iratok tartalmának és szerkezetének karbantartásához. Tömeges importáláskor az EIKR-nek ugyanazokat az adatokat kell rögzítenie, mint a hagyományos iktatás során, azaz az iratokat és azok metaadatait. Iktatáskor gondoskodni kell az iratok megfelelő besorolásáról (szükség esetén a besorolási séma kibővítéséről, lásd 3.1.12.), illetve igény szerint az eseménynapló adatainak rögzítéséről. Végezetül pedig a tömeges importálási műveletet fel kell készíteni a kivételek és hibák kezelésére. A Specifikáció írásának idejében folyamatban van a MoReq2 XML séma kidolgozásának tervezése. A séma várhatóan megvalósítja a MoReq2 metaadatmodellt, és a MoReq2-vel kompatibilis EIKR-ek közötti elektronikus iratok tömeges importálásának protokolljává válik.
Hiv. 6.2.1.
Követelmény
Köt.
Teszt
A hivatalos MoReq2 XML séma elkészülte után az EIKR-nek képesnek kell lennie a sémának megfelelő formában megadott iratok tömeges importálására.
Igen
Rész ben
Igen
Rész ben
Lásd még az 5.3.1. követelményt az iratok exportálásával kapcsolatban. A két követelmény együtt a MoReq2 követelményeinek eleget tevő EIKR-ek együttműködését növeli. 6.2.2.
Az EIKR-nek lehetővé kell tennie a más rendszerek által készített tranzakciós iratok iktatását, beleértve: az előre meghatározott kötegelt állományok tranzakcióinak importálását; szerkeszthető szabályok készítését az iratok automatikus iktatására; az adatok integritását biztosító validálást. A MoReq2 nem írja elő e képesség megvalósításának módját.
6.2.3.
Tömeges importáláskor az EIKR-nek lehetővé kell tennie az iratokhoz tartozó metaadatok automatikus rögzítését (megengedve a hiányzó vagy helytelen metaadatok kézi bevitelét).
Igen
Rész ben
6.2.4.
Az EIKR-nek ugyanazon szabályok szerint kell validálnia az iratok metaadatait azok automatikus rögzítésekor, mint a hagyományos, kézi bevitel során. Amennyiben a validálás hibát észlel (pl. kötelezően kitöltendő metaadatok értékei hiányoznak), a rendszer köteles a hibáról értesíteni az importálást végző felhasználót, minden esetben azonosítva az érintett metaadatokat. Az EIKR-nek rögzítenie kell az eseménynaplóban a hibát és a végrehajtott tevékenységeket.
Igen
Igen
Ideális esetben az importált iratok metaadatai teljes mértékben megfelelnek a metaadatmodellnek. Előfordulhat azonban olyan helyzet is, amikor a metaadatok nem megfelelőek. Ilyenkor többféle kimenet is elképzelhető, a MoReq2 nem írja elő, mit tegyen a rendszer. Az alábbi kimenetek lehetségesek (a felsorolás nem teljes): a teljes importálási folyamat megszakítása; a nem megfelelő metaadatokkal rendelkező irat importálásának megszakítása; a felhasználó választhat, hogy kijavítja a hibát, vagy megszakítja az érintett osztály importálását; az adatok átmenetileg hiányos iratként kerülnek be a rendszerbe (ez a választási lehetőség a 6.1.34. követelményre emlékeztet, amely az iktatási folyamat felosztását részletezi).
6.2.5.
Az EIKR-nek képesnek kell lennie az iratok előzményeit taglaló eseménynaplók importálására.
Igen
Igen
6.2.6.
Az EIKR nem egyesítheti az iratokhoz tartozó eseménynaplókat a saját eseménynaplójával, azokat külön köteles tárolni.
Igen
Igen
Igen
Igen
Igen
Igen
Az importált eseménynaplók megkülönböztetett kezelését az indokolja, hogy a rendszernek biztosítania kell az eseménynapló hitelességét, tehát ki kell zárnia, hogy adminisztrátori szerepkörök módosíthassák azt. A MoReq2 nem írja elő, hogy milyen formában lehet az importált eseménynaplókat tárolni, de elképzelhető az eseménynapló felvétele külön iratként az érintett iratok mellett, vagy megjelölhető más rendszerből származó eseménynaplóként. 6.2.7.
Az EIKR-nek gondoskodnia kell a bemeneti sorok kezeléséről. Ez az alábbi képességeket foglalja magában: a sorok megtekintése; az összes vagy néhány sor szüneteltetése; az összes vagy néhány sor újraindítása; sor törlése.
6.2.8.
Az EIKR-nek lehetővé kell tennie egy adminisztrátori szerepkör számára, hogy egy általa szabályozható beállítástól függően az EIKR automatikusan lezárja az osztályokat, dossziékat és köteteket importálásuk után. Két vállalat egyesítését követően például kívánatos lehet a szerkezet egyes ágait lezárni, hogy azokat ne lehessen többé bővíteni.
6.3.
Az e-mailek (elektronikus levelek) kezeléséről
Meghatározások Az elektronikus levelezés, más szóval e-mailezés az ágensek közötti üzenetátvitel egyik módja (az „ágens” kifejezés ebben a mondatban pontos szakmai jelentéssel rendelkezik, megértése azonban nem szükséges a MoReq2 értelmezéséhez). Az elektronikus levelezéshez használt szabványos protokollt az IETF (Internettechnológiai munkaszervezet) részeként működő Network Working Group (Hálózati Munkacsoport) definiálja az RFC 2821 és RFC 2822 dokumentumokban (lásd 7. függelék). A MoReq2 az RFC 2821/RFC 2822 dokumentumok alapján határozza meg az elektronikus levél („e-mail”) fogalmát. Főnévként az „e-mail” egy elektronikus levél átvitelének összes adatát tartalmazó dokumentum. Bár az RFC 2822 egyértelműen meghatározza az e-mailek átvitelének szintaktikáját, az e-mail adatformátumát egyetlen szabvány sem rögzíti. Másképp fogalmazva, függetlenül attól, hogy a különböző levelezőprogramok szabadon küldenek és fogadnak e-maileket (mivel az RFC 2821/ RFC 2822 protokollokat követik), ha
az egyik alkalmazásban iktatunk egy e-mailt, nem lehetünk benne biztosak, hogy egy másik e-mail kezelő alkalmazás meg tudja azt jeleníteni. A levelezőprogramok készítői saját fejlesztésű formátumokat használnak az e-mailek tárolására, ezért az ilyen üzenetek metaadatainak automatikus lekérdezése nem garantálható. Használat és kérdések Az elektronikus levelezés dokumentumok küldésére szolgál szervezetek között és a szervezeteken belül. A dokumentum lehet maga az üzenet, vagy egy csatolmány. Az emailkezelő szoftverek sajátosságait (különös tekintettel a szabványok hiányára) és a felhasználók elektronikus levelezési szokásait figyelembe véve igen nehéz az iratkezelési funkciókat kiterjeszteni az elektronikus levelekre. A szervezeteknek az alábbi műveleteket és ellenőrzésüket kell megoldaniuk: az összes kimenő és bejövő e-mail és csatolmány iktatása; az e-mailek és csatolmányok meghatározott szabályok szerinti iktatása; a felhasználók választhatják ki, mely e-maileket és csatolmányokat szeretnék iktatni. Néhány országban az elektronikus levelek tulajdonjoga nem tisztázott, így bizonyos helyzetekben nem elfogadható azok automatikus iktatása az EIKR-be. Ilyenkor az előbbi felsorolás utolsó két pontja alkalmazható. Számos szervezetben az e-mail az alapértelmezett kommunikációs forma, de sok más helyen szintén kiemelt szerepet kap. Néhány szervezetnél az elektronikus levelezés szerepe elenyésző. A szervezeteknek maguknak kell eldönteniük, hogy a fent említett három lehetőség közül melyik felel meg legjobban körülményeiknek: Az első lehetőség a jelentéktelen és a fontos e-maileket egyaránt iktatja; A második lehetőség a megfelelő szabályok és szűrők sikeres összeállításán múlik; A harmadik lehetőség elvárja a felhasználótól, hogy megállapítsa a levelek fontosságát és relevanciáját, így fennáll a téves megítélés veszélye. A MoReq2 mindhárom lehetőségnek teret enged, a megvalósításhoz használt eljárások és kezelési szabályozások azonban jelen Specifikáció hatáskörén kívül esnek.
Követelmény
Köt.
Teszt
6.3.1.
Az EIKR köteles az e-maileket olyan formátumban iktatni, amely tárolja a fejléc adatait.
Igen
Igen
6.3.2.
Az EIKR-nek integrált módon kell támogatnia az e-mailek iktatását, ami azt jelenti, hogy a felhasználónak ne kelljen váltania a levelezőprogram és az iktatórendszer között, amikor e-mailt szeretne iktatni.
Igen
Igen
Igen
Igen
Hiv.
A szoros integráció az EIKR hatékony használatának egyik előfeltétele. Integrált megoldásnak számít például az, ha a felhasználó „áthúzhatja” az elektronikus levelet a levelezőprogramból az EIKR-be, vagy rendelkezésére áll egy „Iktatás” gomb a levelezőprogramban, esetleg a levelezőprogram jelzi, hogy mely leveleket iktatták korábban. A követelmény célja, hogy a felhasználónak ne kelljen átváltania az EIKR-re egy e-mail iktatásához. A MoReq2 az elektronikus levelek iktatásánál más, kevésbé integrált módszerek használatát is engedélyezi, de nem írja elő. 6.3.3.
Az EIKR konfigurálása során lehetővé kell tenni egy olyan beállítást, amellyel kiválasztható, hogy mi történjen, amikor a felhasználó e-mailt küld: a rendszer automatikusan iktassa az e-mailt; a rendszer állapítsa meg, hogy az e-mailt szükséges-e iktatni az előre meghatározott szabályok értelmében; a rendszer kérdezze meg a felhasználótól, hogy kívánja-e az elküldött e-mailt iktatni; a rendszer ne tegyen semmit (a felhasználó akkor iktatja az emailt, amikor azt jónak látja). Választástól függetlenül az EIKR kérheti a felhasználót az elektronikus levél iratként történő besorolására és a hiányzó metaadatok pótlására.
Hiv. 6.3.4.
Követelmény
Köt.
Teszt
Az EIKR-nek rendelkeznie kell egy olyan beállítással, amellyel a rendszer konfigurációja során kiválasztható, hogy mi történjen, amikor a felhasználó e-mailt fogad:
Igen
Igen
Igen
Rész ben
a rendszer automatikusan iktassa az e-mailt, amennyiben azt korábban még nem iktatták; a rendszer állapítsa meg, hogy az e-mailt szükséges-e iktatni az előre meghatározott szabályok értelmében; amennyiben az e-mailt korábban nem iktatták, a rendszer kérdezze meg a felhasználótól, hogy kívánja-e a fogadott e-mailt iktatni; a rendszer ne tegyen semmit (a felhasználó akkor iktatja az emailt, amikor azt jónak látja). Választástól függetlenül az EIKR kérheti a felhasználót az elektronikus levél iratként történő besorolására és a hiányzó metaadatok pótlására. 6.3.5.
Az EIKR-nek automatizált támogatást kell nyújtania a kimenő és bejövő, csatolmánnyal rendelkező vagy anélküli e-mailek iktatásához az alábbi metaadatok automatikus lekérdezésével: e-mail küldésének dátuma (amennyiben szükséges, pontos ideje); címzett(ek); másolatot kap(nak); tárgy (cím); feladó; beágyazott elektronikus aláírás; tanúsítványt kiállító szolgáltató; amennyiben ezek jelen vannak. A követelmény az e-mail „feladójának” rögzítését írja elő, aki nem minden esetben egyezik meg az e-mail szerzőjével. Egy titkárnő például küldhet e-mailt az igazgató nevében. Mivel az elektronikus levél szerzőjét lehetetlen megbízhatóan megállapítani, a MoReq2 csak a „feladó” fél azonosítását kéri. A szervezetek igény szerint manuális eljárásokkal győződhetnek meg a szerző metaadat helyességéről. A 9. függelék értelmezéséhez.
eligazítást
ad
az
e-mailek
metaadatainak
Hiv. 6.3.6.
Követelmény
Köt.
Teszt
A rendszernek lehetővé kell tennie, hogy az e-mailek aldossziékba, dossziékba vagy osztályokba történő iktatásához a felhasználók a levelezőprogramból a kiválasztott egyed fölé vihessék az egérrel a leveleket.
Nem
Igen
Igen
Igen
Nem
Igen
Az aldosszié, dosszié vagy osztály levelezőprogramban, vagy egy külön ablakban. 6.3.7.
megjelenhet
a
Az EIKR-nek lehetővé kell tennie a felhasználó számára, hogy eldöntse, a csatolmányokkal rendelkező e-mail mely részét szeretné iktatni: az e-mail üzenet részét, a csatolmányokat nem; az e-mailt annak csatolmányaival együtt egyetlen iratként, amely több, összekapcsolt állományból áll; csak a csatolmányokat, mindegyiket külön iratként. Ezek a lehetőségek az elküldött és beérkező üzenetekre egyaránt vonatkoznak. Az utolsó lehetőség a csatolmányokat környezetükből kivéve iktatja.
6.3.8.
Amennyiben a rendszer az e-mailt és annak csatolmányait egyszerre iktatja, de külön iratokként, az új iratokat automatikusan össze kell kapcsolnia. Az EIKR-nek lehetővé kell tennie a felhasználó számára a kereszthivatkozások mentén történő navigálást, így a felhasználó bármelyik csatolmányt elérheti az e-mail üzenetből indulva, illetve fordítva.
6.3.9.
Amennyiben a csatolmányok külön iratként kerülnek iktatásra, az EIKR-nek gondoskodnia kell a szükséges metaadatok értékeinek beállításáról.
Igen
Igen
6.3.10.
Az e-mail iktatásakor az EIKR-nek alapértelmezés szerint az üzenet tárgyával kell kitöltenie a Cím (Title) metaadat értékét.
Igen
Igen
Igen
Igen
A 9. függelék értelmezéséhez. 6.3.11.
eligazítást
ad
az
e-mailek
metaadatainak
Az EIKR-nek lehetővé kell tennie az e-mail üzenetet iktató felhasználó számára az irat címének szerkesztését. Ezáltal a felhasználók pontosíthatják vagy helyesbíthetik elektronikus levélben nem megfelelően megadott tárgyakat.
az
Az e-mail esetleges első kiemelt sora, amennyiben az nem megszólítás, független az e-mail tárgyától. Utóbbi az üzenet részét képezi.
Hiv. 6.3.12.
Követelmény
Köt.
Teszt
Amennyiben a felhasználó egy korábban már iktatott e-mailről érkező kézbesítési jelentést iktat, az EIKR-nek automatikusan össze kell tudnia kötni a két iratot.
Nem
Igen
Kézbesítési jelentésre példa a sikertelen vagy a sikeres kézbesítésről kapott visszajelzés. A rendszernek lehetővé kell tennie a felhasználó számára, hogy az iktatott e-mail és az iktatott jelentés között mindkét irányban tudjon navigálni, azaz az e-mailről el tudja érni a hozzá kapcsolódó jelentést, a jelentésről pedig az érintett e-mailt. 6.3.13.
Az EIKR-nek lehetővé kell tennie az e-mailek és csatolmányaik metaadatainak automatikus lekérdezését a MoReq2 adatmodellben leírtaknak megfelelően.
Igen
Igen
6.3.14.
Az EIKR-nek lehetővé kell tennie a „küldés dátuma” és „érkezés dátuma” metaadatok kézi bevitelét.
Igen
Igen
Igen
Igen
Nem
Igen
Erre olyan helyzetekben lehet szükség, amikor az e-mail üzenetben megadott dátumok nem felelnek meg az üzleti elvárásoknak. A funkció kikapcsolható egy beállítás segítségével. 6.3.15.
Az EIKR-nek lehetővé kell tennie a felhasználó számára, hogy egyetlen művelettel több kiválasztott e-mailt iktathasson egyetlen iratként, vagy minden e-mailt külön iratként a felhasználó döntésének függvényében.
6.3.16.
Az EIKR-nek képesnek kell lennie arra, hogy automatikusan azonosítsa és iktassa a felhasználó által kijelölt e-mailhez kapcsolódó e-maileket egyetlen műveletben, egyetlen iratként, vagy minden e-mailt külön iratként a felhasználó döntésének függvényében. Az RFC 2822 szabvány 3.6.4., azonosító mezőkről szóló szakasza leírja, hogyan kell az SMTP „References:” és „In-Reply-To:” fejléc mezők értékét felhasználni a „Message-ID:” mezővel együtt az emailhez kapcsolódó üzenetek megállapításához. Az egymáshoz kapcsolódó e-maileket gyakran beszélgetési szálként (thread) emlegetik.
Hiv. 6.3.17.
Követelmény
Köt.
Teszt
Az EIKR-nek lehetővé kell tennie, hogy a saját fejlesztésű, zárt formátumban iktatott e-mailt más, többek között nyitott formátumban is el lehessen menteni.
Igen
Igen
Igen
Igen
Hasznos lehet, ha az EIKR a megőrzési és selejtezési ütemtervek figyelembevételével felülvizsgálja az elektronikus levelek formátumát. A rövid megőrzési idejű levelek tárolhatók zárt formátumban, a hosszú ideig megőrzött iratokat azonban indokolt nyílt formátumban menteni. 6.3.18.
Az e-mail fejlécében szereplő címek kinyerésekor az EIKR-nek biztosítania kell, hogy a rendszer a feladó vagy a címzett „megjelenítési nevét”, ne pedig az e-mail címét tárolja el (az „
[email protected]” helyett például a „Kovács János” szöveget szűrje ki).
6.4.
Irattípusok
Az irattípusok az iratok azon jellemzőit határozzák meg, amelyekről a besorolási séma nem rendelkezik. Ilyen jellemzők például: a metaadat attribútumok; a megőrzési követelmények; a hozzáférési szabályozások; a dokumentum fajtája (pl. szerződés, életrajz, jelentés). Az irat irattípusa rendszerint megegyezik az irat alapjául szolgáló dokumentum dokumentumtípusával.
Követelmény
Köt.
Teszt
6.4.1.
Az EIKR-nek lehetővé kell tennie különböző irattípusok létrehozását és karbantartását.
Igen
Igen
6.4.2.
Egy iratnak pontosan egy irattípusa lehet.
Igen
Igen
6.4.3.
Az EIKR-nek adminisztrátori szerepkörre kell korlátoznia az irattípusok létrehozását és karbantartását.
Igen
Igen
6.4.4.
Az EIKR-nek lehetővé kell tennie egy adminisztrátori szerepkör számára, hogy adott irattípushoz tartozó iratok létrehozását felhasználók egy szűk körére korlátozhassa az üzleti igényeknek megfelelően.
Igen
Igen
6.4.5.
Az EIKR-nek lehetővé kell tennie egy adminisztrátori szerepkör számára, hogy alapértelmezettnek kijelöljön egy meghatározott irattípust, melyet minden, iratok iktatására jogosult felhasználó használhat.
Igen
Igen
Hiv.
6.5.
Szkennelés és képfeldolgozás
Az elektronikus iratkezelő rendszerek implementációjának tervezésekor figyelembe kell venni a papíralapon vagy mikroformán tárolt ún. fizikai iratok kezelésének kérdéseit. A fizikai iratok kezelése két fő problémát vet fel: a papíralapon vagy mikroformán rögzített meglévő iratokat az elektronikus iratokkal együtt kell kezelni; a szervezet életében folyamatosan keletkező dokumentumokat a szervezet az EIKR-ben szeretné kezelni elektronikus iratként. Ez a szakasz a papíralapú vagy mikroformán tárolt dokumentumok szkennelésével (lapolvasásával, képfeldolgozásával) foglalkozik. A szakasz részletezi a fizikai iratok digitalizálásának követelményeit, emellett pedig számos elvárást fogalmaz meg a szkennelési folyamat részleteit illetően. A szkennelés történhet: központosított módon; helyi jelleggel, vagy munkacsoportok formájában; kiszervezett feladatként, vagy alvállalkozóval; illetve ezek tetszőleges kombinációjában. A lehetséges módokat az alábbiakban röviden kifejtjük. A központosított szkennelés nagymennyiségű iratok rögzítésére alkalmas. Ez rendszerint tömeges bevitelre szakosodott gyors szkenner berendezések használatát jelenti, melyek működését szakértők felügyelik.
A helyi, vagy munkacsoport formájában történő szkennelés az iratokat fogadó felhasználó közelében történik, jellemzően egyszerre kis mennyiségű bevitelt jelent. A szkennelést végző személy tisztában van az iratok üzleti jelentőségével, vagy a szervezet földrajzi elhelyezkedése kívánja meg a helyi szkennelést. Az iratok digitalizására használt szkennerek általában multifunkcionális, kis kapacitású és lassú eszközök. A kiszervezett, vagy alvállalkozók által végzett szkennelésnek több, költséghatékonyságot növelő oka lehet: nagy mennyiségű iratot kell egyszerre beszkennelni; a szervezetnek nem áll rendelkezésére elegendő humán erőforrás a feladat elvégzéséhez; a szervezetnek nem áll rendelkezésére elegendő tárhely és eszköz a feladat elvégzéséhez; a szkennelés és a tárolás helytől független. A szakasz hátralevő része az EIKR-be integrált szkennelő megoldások iránti követelményeket foglalja össze. A követelményeket csak akkor kell teljesíteni, ha az EIKRből szkennelnek is. A követelmények jelentős része a kiszervezett szkennelésre is érvényes. Hiv. 6.5.1.
Követelmény
Köt.
Teszt
Az EIKR-nek legalább egy szkennelő megoldással együtt kell működnie.
Igen
Igen
Nem
Igen
Igen
Igen
Igen
Igen
A szkennelő megoldás nem más, mint interfész a szkennelő eszköz és az operátor között, lehetővé téve az operátor számára különböző, szkenneléssel kapcsolatos feladatok (pl. elforgatás, zajcsökkentés) végrehajtását. 6.5.2.
Az EIKR szkennelő szolgáltatásának támogatnia kell a monokróm és a színes szkennelést egyaránt. Számos alkalmazás nem igényel színes szkennelést.
6.5.3.
Az EIKR szkennelő szolgáltatásának legalább az szabványos képformátumba kell tudnia képeket menteni:
alábbi
TIFF (lásd TIFF 6.0 szabvány); JPEG (lásd ISO 15444, de csak ha a szoftver támogatja a színes szkennelést); PDF/A (lásd ISO 19005). 6.5.4.
Az EIKR szkennelő szolgáltatásának képesnek kell lennie különböző felbontásban elmenteni a képeket. Ideális esetben a szkennelő szolgáltatás egy menüben kínálja fel a lehetőségeket, melyek különböző típusú dokumentumok bevitelére programozhatók.
Követelmény
Köt.
Teszt
6.5.5.
Az EIKR szkennelő szolgáltatásának képesnek kell lennie különböző felbontásban elmenteni a színes vagy szürkeskálás képeket.
Nem
Igen
6.5.6.
Az EIKR szkennelő szolgáltatásának képesnek kell lennie a hagyományos papírméretek kezelésére, beleértve, de nem kizárólagosan az alábbi méreteket:
Igen
Igen
Nem
Igen
Nem
Igen
Hiv.
A4; A3. Lásd az ISO 216 szabványt az A4 és A3 papírméretekről. 6.5.7.
Az EIKR szkennelő szolgáltatásának rendelkeznie kell optikai karakterfelismerő (OCR, Optical Character Recognition) funkcióval. Az optikai karakterfelismerés szöveggé alakítja a beszkennelt képet. A karakterfelismerők egy része intelligens karakterfelismerő, azaz ICR (az Intelligent Character Recognition rövidítése). Az egyszerűség kedvéért a MoReq2 mindkettőt OCR néven említi.
6.5.8.
Amennyiben az EIKR rendelkezik optikai karakterfelismerő funkcióval, az iratkezelő rendszernek egyetlen iratként kell kezelnie a beszkennelt képet és az abból kinyert szöveget. Másképp fogalmazva, az OCR által felismert szöveget az irat metaadataként kell kezelni, nem önálló iratként. A MoReq2 nem írja elő, hogy a rendszer megjelenítse az OCR által felismert szöveget, mivel az a teljes szövegben végzett keresést támogatja (lásd a következő követelményt).
6.5.9.
Amennyiben az EIKR rendelkezik optikai karakterfelismerő funkcióval, az iratkezelő rendszernek támogatnia kell a teljes szövegben végzett keresést.
Nem
Igen
6.5.10.
Az EIKR szkennelő szolgáltatásának képesnek kell lennie tömeges szkenneléskor a különálló dokumentumok felismerésére és rögzítésére.
Nem
Igen
Igen
Igen
A MoReq2 nem írja elő, hogyan kell ezt a funkciót megvalósítani. A mindennapi gyakorlatban legtöbbször a mezőkódokat, vonalkódokat vagy az üres oldalakat veszik alapul. 6.5.11.
Az EIKR szkennelő szolgáltatásának képesnek kell lennie sorba küldeni a beszkennelt képeket közvetlenül a szkennelést követően. Például indexelésre, minőségellenőrzésre stb.
Hiv. 6.5.12.
Követelmény
Köt.
Teszt
Az EIKR-nek lehetőséget kell biztosítania a képek szkennelés utáni felülvizsgálatára.
Nem
Igen
Beleértve a képek elfogadását vagy elutasítását, illetve az elutasítást követő újraszkennelés kérését. A felülvizsgálatot végezheti a szkennelő operátor, hivatott minőségellenőrző felhasználó, vagy bármely felhasználó, akinek munkája részét képezi a minőségellenőrzés. 6.5.13.
Az EIKR szkennelő szolgáltatásának lehetővé kell tennie egy adminisztrátori szerepkör számára, hogy küszöbértéket állítson be a beszkennelt képek tartalmát illetően: a küszöbértéket el nem érő képeket a rendszer üres oldalként kezeli és elutasítja.
Nem
Igen
6.5.14.
Az EIKR szkennelő szolgáltatásának el kell tárolnia a szkenner beállításait (pl. egyoldalas/kétoldalas, felbontás, kontraszt, fényerő) az egyes dokumentumtípusokhoz.
Nem
Igen
6.5.15.
Az EIKR-nek lehetővé kell tennie a felhasználók számára, hogy annotálhassák a képeket.
Nem
Igen
Igen
Igen
Igen
Igen
A felhasználó annotáció formájában rögzítheti, ha hibát észlelt a szkennelés során, vagy megjegyzéseket fűzhet a képhez (hasonlóan ahhoz, amikor kézzel írt széljegyzetekkel látják el a papír alapú dokumentumokat). 6.5.16.
Amennyiben az EIKR lehetővé teszi az iratként tárolt képek annotálását, nem engedélyezheti az annotációk módosítását vagy eltávolítását. Ez a követelmény csak az iratokra vonatkozik, a többi képre nem. Célja, hogy az iratokat ne lehessen időlegesen megmásítani.
6.5.17.
Amennyiben az EIKR lehetővé teszi az iratként tárolt képek annotálását, minden egyes annotáció esetében rögzítenie kell a felhasználó azonosságát és az annotáció készítésének időpontját megváltoztathatatlan formában. Ez a követelmény csak az iratokra vonatkozik, a többi képre nem. Célja, hogy az annotációk megfelelőek és nyomon követhetők legyenek.
Hiv. 6.5.18.
Követelmény Az EIKR szkennelési szolgáltatásának munkamenetek alábbi részleteit kell naplóznia:
a
szkennelési
Köt.
Teszt
Nem
Igen
Nem
Igen
Nem
Igen
Nem
Igen
felhasználó bejelentkezése; munkaállomás azonosító; időpont és időtartam; munkamenet azonosító; kötegazonosító(k); dokumentumok száma (amennyiben értelmezhető); beszkennelt képek száma; képek száma az üres oldalak eltávolítása után (amennyiben az üres oldalakat a rendszer automatikusan eltávolítja). 6.5.19.
Az EIKR szkennelő szolgáltatásának az aktív területek szkennelése során támogatnia kell a szükséges metaadatok kinyerését. Az aktív terület a lapnak az a része, amit a szkennelő szoftver szkennelésre megjelöl. A meghatározott területen kívülre eső rész nem lesz szkennelve, ezáltal csökken a kép mérete, aminek következtében a tárolási és sávszélességi követelmények is mérséklődnek.
6.5.20.
Amennyiben az EIKR szkennelő szolgáltatása támogatja a metaadatok automatikus rögzítését, az ily módon kinyert információt fel kell használnia az iratok automatikus besorolásához. Ez a funkció különösen az ügyviteli környezetekben nyer értelmet, ahol a papír alapú iratokon szereplő azonosítók gyakran elegendő információval szolgálnak az irat besorolásához – lásd 10.5. szakasz.
6.5.21.
Az EIKR-nek támogatnia kell a beszkennelt képek és azok metaadatainak a tömeges importálását. Lásd a 6.2. szakaszt a tömeges importálással kapcsolatos további követelményekről.
6.5.22.
Az EIKR-nek képesnek kell lennie a beszkennelt képek miniatűrjeit megjeleníteni a navigáció és keresés megkönnyítése céljából.
Nem
Igen
6.5.23.
Az EIKR-nek lehetővé kell tennie a felhasználók számára, hogy iratként iktathassák a beszkennelt képeket.
Igen
Igen
7.
AZONOSÍTÓK
Ebben a fejezetben a besorolási séma egyedeinek (osztályok, dossziék, aldossziék, kötetek és iratok) hivatkozásával kapcsolatos követelmények szerepelnek. A besorolási kódokkal a 7.1., a rendszerazonosítókkal a 7.2. szakasz foglalkozik. Az EIKR-ben tárolt összes egyedet (osztályt, dossziét, aldossziét, kötetet, iratot stb.) azonosítóval kell ellátni. Az azonosítók segítik a szoftvert az egyedek feldolgozásában, a felhasználókat használatában.
az
egyedek
lekérésében,
kinyerésében,
hivatkozásában
és
A MoReq2 az alábbi szakkifejezéseket különbözteti meg az azonosítók leírásakor: A szoftver által használt azonosítót a Specifikáció rendszerazonosítónak nevezi. A rendszerazonosítót a szoftver és a felhasználók is igénybe vehetik; Az egyedeket a hierarchikus besorolási sémán belül azonosító, a felhasználók számára készült hierarchikus azonosítót besorolási kódnak hívják; A további azonosítók neve önmagáért beszél, például „megőrzési és selejtezési ütemterv azonosító”. A rendszerazonosítók és besorolási kódok közötti különbséget az alábbi három ábra szemlélteti. Az ábrákat a fejezet későbbi részei is hivatkozzák. A 7.1. ábrán egy kitalált, de valósághű besorolási sémát láthatunk. Az ábra az osztályok egy részét mutatja, minden osztály rendelkezik címmel (a 3.2.4. követelmény értelmében).
7.1. ábra: Osztálycímek Az osztályok mindegyikének van rendszerazonosítója, amit a 7.2. ábra mutat.
7.2. ábra: Rendszerazonosítók Megjegyzés. Az ábrán látható rendszerazonosítók az illusztráció céljából rövidek és egyszerűek, a valóságban azonban jóval hosszabbak, szerkezetük pedig összetett. A GUID (Globally Unique ID) algoritmus alapján készült rendszerazonosító például a 0c7220e3-564644c4-82b0-67832c1efa1c karakterlánc. Minden osztályhoz tartozik egy besorolási kód. A további követelmények értelmében a besorolási kód többféle alakot ölthet, egyik formája például a 7.3. ábrán is látható számsorozat.
7.3. ábra: Besorolási kódok Akárcsak a korábbi példánál, a besorolási kódok az illusztráció céljából itt is viszonylag egyszerűek. Minden osztályhoz tartozik egy besorolási kód, melyet a szülő osztályok kódjaival összefűzve kapjuk a teljesen minősített besorolási kódot. A Katasztrófavédelem osztály teljesen minősített besorolási kódja például a 001-001-003 sorozat, ezt az alábbi lépésekkel állítottuk elő: megkeressük az adott osztály hierarchiában legmagasabban lévő szülőjének a besorolási kódját (001 lesz, mivel a Katasztrófavédelem legmagasabb szinten lévő szülője a Testületi irányvonal) hozzáfűzzük a hierarchiában egy szinttel lejjebb található szülő besorolási kódját (001, az Üzleti folytonosság besorolási kódja), így kapjuk a 001-001 sorozatot; ismételjük az előző lépést, amíg a kérdéses osztály közvetlen szülőjének a kódját fel nem írjuk (ebben az egyszerű példában ez a lépés fölösleges); hozzáfűzzük az osztály besorolási kódját (003, Katasztrófavédelem), így áll elő az osztály teljesen minősített besorolási kódja, jelen esetben a 001-001-003 sorozat. Az iratok és az állományok hivatkozhatóságukat segíti.
is
rendelkeznek
besorolási
kóddal,
ami
egyedi
A felhasználás módja határozza meg az egyediség mértékét. A rendszerazonosítók legalább az EIKR „példányon” vagy „hálózati csomóponton” belül egyediek, jó esetben azonban a teljes hálózat tekintetében azok. A teljesen minősített besorolási kódok egyediek az adott besorolási sémán belül, ugyanakkor az egyes besorolási kódok csak a hierarchia adott csomópontján (osztályon, dosszién stb.) belül egyediek.
Amennyiben fontos, hogy egyediek legyenek az azonosítók a teljes hálózaton belül, célszerű olyan elismert szabványra támaszkodni, amely globális (azaz minden időben, rendszerek közötti) egyediséget garantál. Az ilyen jellegű szabványok használata az önálló asztali, nem hálózati alkalmazások esetén is javasolt, ugyanis segíti a jövőbeli terjeszkedést, illetve az egyesüléseket, felvásárlásokat. A szakma több, egyediséget biztosító szabványt is elfogad, mivel azonban egyiknek sincs elsöprő elismertsége, a MoReq2 egyik használatát sem írja elő konkrétan.
7.1.
Besorolási kódok Köt.
Teszt
vagy
Igen
Igen
7.1.2.
Az EIKR-nek biztosítania kell, hogy a teljesen minősített besorolási kódok egyediek a besorolási séma hierarchián belül.
Igen
Rész ben
7.1.3.
Az EIKR-nek biztosítania kell, hogy a besorolási kódok és a teljesen minősített besorolási kódok megőrzik kívánt egyediségüket az esetleges áthelyezésektől függetlenül is (lásd 3.4.1.)
Igen
Igen
7.1.4.
Az EIKR-nek a hivatkozott egyed metaadatai között kell tárolnia a besorolási kódot.
Igen
Igen
7.1.5.
Az EIKR-nek lehetővé kell tenni egy adminisztrátori szerepkör számára, hogy a rendszer konfigurálásakor meghatározhassa a besorolási kódok és a teljesen minősített besorolási kódok formátumát. Az EIKR-nek az alábbi lehetőségek beállítását kell lehetővé tennie hierarchiaszintenként:
Nem
Igen
Igen
Igen
Hiv. 7.1.1.
Követelmény Az EIKR köteles az alábbi egyedeket iktatásukkor besorolási kóddal ellátni:
létrehozásukkor
osztály; dosszié; aldosszié; kötet; irat; állomány.
numerikus, alfabetikus vagy alfanumerikus; vezető nullák jelenléte vagy hiánya; minimum hossz (vezető nullák megléte esetén); kezdőérték; lépésköz. 7.1.6.
A teljesen minősített besorolási kódok a besorolási kódok elválasztó karakterrel összefűzött sorozatából állnak.
Hiv. 7.1.7.
Követelmény
Köt.
Teszt
Az EIKR legalább az alábbi karaktereket köteles a teljesen minősített besorolási kódok lehetséges elválasztójeleként felkínálni:
Nem
Igen
Igen
Rész ben
„ “ (szóköz); „-” (kötőjel); „/” (perjel); „.” (pont). A bevezetésben példaként említett 001-001-003 teljesen minősített besorolási kód az alábbi formátumok bármelyikében előfordulhat, a vezető nullák megléte és az elválasztó karakter függvényében: 1 001 003; 001-001-003; 1/1/3; 001.001.003.. Mivel a 3.2.7. követelmény lehetőséget ad globális előtagok és kiterjesztések használatára, az alábbi változatok is elfogadhatók: testületi/1/1/3; 001.001.3.pt. 7.1.8.
Új osztály létrehozásakor az EIKR-nek köteleznie kell egy adminisztrátori szerepkört annak eldöntésére, hogy az osztály leszármazottait automatikusan számozza a rendszer, vagy azok besorolási kódját a felhasználó vagy egy külső alkalmazás rögzíti. Az EIKR-nek: automatikusan generálnia kell a besorolási kódokat, melyet a felhasználók később nem módosíthatnak (ez lehet egy sorszám, mint a példában); vagy: lehetővé kell tennie egy jogosult felhasználó vagy külső alkalmazás számára a besorolási kód bevitelét, de nem engedélyezheti annak későbbi megváltoztatását. Amennyiben az adminisztrátor az első lehetőséget választja, az „Üzleti folytonosság” osztály alá bekerülő új „Eseménykezelés” osztály a rendszer által generált 004 besorolási kódot kapja a 7.4. ábrának megfelelően.
Hiv.
Követelmény
Köt.
Teszt
Igen
Igen
Igen
Igen
7.4. ábra A második lehetőség különösen az ügyiratkezelő környezetekre érvényes. 7.1.9.
Amennyiben az EIKR automatikusan generálja a besorolási kódot (a 7.1.8. követelmény első lehetősége szerint), a soron következő számot az alábbiak figyelembevételével kell előállítania: a besorolási séma adott pontján legutóbb kiosztott besorolási kód, vagy (első egyed esetén) a kezdőérték; a lépésköz, lásd 7.1.5. Példa a 7.4. ábrán látható.
7.1.10.
Amennyiben a besorolási kódot egy felhasználó vagy külső alkalmazás rögzíti, az EIKR-nek ellenőriznie kell a kód egyediségét a szülőn belül.
7.2.
Rendszerazonosítók
Hiv.
Követelmény
Köt.
Teszt
Hiv. 7.2.1.
Követelmény
Köt.
Teszt
létrehozásukkor
Igen
Igen
Az EIKR-nek biztosítania kell, hogy a rendszerazonosítók egyediek a besorolási séma hierarchián és az EIKR példányon belül.
Igen
Nem
Az EIKR köteles az rendszerazonosítóval ellátni:
alábbi
egyedeket
besorolási séma; osztály; dosszié; aldosszié; kötet; irat; maszkolt másolat; megőrzési és selejtezési ütemterv; dokumentum. 7.2.2.
Megjegyzés. Ez a követelmény a különböző földrajzi pontokon elosztott besorolási sémákra és a több besorolási sémával dolgozó EIKR-re is érvényes. 7.2.3.
Az EIKR-nek a hivatkozott egyed metaadatai között kell tárolnia a rendszerazonosítót.
Igen
Igen
7.2.4.
Az EIKR-nek globálisan egyedi rendszerazonosítók kiosztására kell törekednie.
Nem
Nem
Nem
Rész ben
Akkor nevezünk egy azonosítót globálisan egyedinek, ha az előállításához használt algoritmus garantálja, hogy nem létezik két egyforma értékű rendszerazonosító, függetlenül az előállítás időpontjától és az EIKR-től. A globálisan egyedi rendszerazonosítók megkönnyítik a rendszer átkonfigurálását, például az átszervezéssel, felvásárlással vagy egyesítéssel járó változtatásokat. Globálisan egyedi rendszerazonosítók híján nő az átkonfiguráláskor bekövetkező hibák kockázata. 7.2.5.
Az EIKR lehetőleg a UUID algoritmus (lásd ISO/IEC 9834-8 és ITU-T Rec. X.667) segítségével állítsa elő a globálisan egyedi rendszerazonosítókat. A gyakran GUID (Globally Unique ID, globálisan egyedi azonosító) néven is emlegetett algoritmus garantálja az egyediséget.
Hiv.
Követelmény
Köt.
Teszt
Igen
Rész ben
Egyediséget biztosítanak továbbá a következő megközelítések: a Digital Object Identifier System (DOI®), a Uniform Resource Name (URN) séma, vagy az Archival Resource Key (ARK). 7.2.6.
Az EIKR funkciók használata nem függhet a rendszerazonosítók ismeretétől. A követelmény védi a felhasználókat a barátságtalan és rendszerint hosszú rendszerazonosítók keresésétől és begépelésétől. Ugyanakkor a rendszernek engedélyeznie kell a rendszerazonosítók használatát, amennyiben a felhasználók igénylik.
8.
KERESÉS, KINYERÉS ÉS MEGJELENÍTÉS
A kereséssel és lekérdezéssel szemben támasztott követelményeket a 8.1. szakasz részletezi. A megjelenítéssel kapcsolatos elvárásokat három szakasz foglalja össze: a 8.2. szakasz a kijelzőn való megjelenítéssel, a 8.3. a nyomtatással, a 8.4. pedig a nem nyomtatható iratok megjelenítésével foglalkozik. Az elektronikus iratkezelő rendszerek egyik legfontosabb szolgáltatása a dossziék és iratok kinyerése, amely magában foglalja azok keresését (függetlenül attól, hogy a felhasználó mennyire részletes ismeretekkel rendelkezik az adott iratról vagy dossziéról) és megjelenítését. A megjelenítés két legelterjedtebb módja a képernyőn történő megjelenítés és a nyomtatás, de ide sorolható még a zenei és videó állományok lejátszása is (lásd Szószedet). A dossziék és iratok elérése és azt követő megjelenítése rugalmas, sokrétű kereső és megjelenítő funkciókat igényel, mivel a felhasználók elvárásai változatosak. Bár az összetett keresőszolgáltatások meghaladják a hagyományos értelemben vett EIKR-ek képességeit, az alábbiakban ismertetett követelmények azon a feltételezésen alapulnak, hogy a gyenge keresési lehetőségeket nyújtó EIKR-ek kevésbé értékesek. A fejezetben felsorolt szolgáltatások és funkciók a Specifikáció más részeiben kifejtett hozzáférési szabályozás, különösen biztonsági korlátozás alá esnek. Az EIKR nem szolgáltathat ki olyan információt a felhasználónak, amelyet a felhasználónak nincs jogosultsága megtekinteni. Az egyszerűbb megfogalmazás érdekében ez a feltételezés a fejezetben leírt összes követelményre vonatkozik.
8.1.
Keresés és lekérdezés
A keresés az iratok vagy dossziék azonosításának folyamata a felhasználó által megadott paraméterek alapján az iratok, osztályok, dossziék, aldossziék, kötetek vagy metaadatok helyének megállapítása, elérése és lekérdezése céljából.Az EIKR keresést és navigálást támogató eszközei alkalmasak a metaadatok, osztályok, dossziék, aldossziék, kötetek és iratok helyének megállapítására. A „kutató” felhasználók és a „hétköznapi”, kevés számítógépes ismerettel rendelkező felhasználók szélsőséges igényeinek kielégítéséhez változatos keresési technikákra van szükség.
Követelmény
Köt.
Teszt
8.1.1.
Az EIKR egyetlen kereső és megjelenítő szolgáltatása sem fedhet fel a felhasználó előtt olyan információt (metaadatot vagy irattartalmat), amelyet a felhasználó a hozzáférési és biztonsági szabályozások (lásd 4.1. és 10.3. szakasz) értelmében nem tekinthet meg.
Igen
Rész ben
8.1.2.
Az EIKR-nek az alábbi egyedek keresését és megjelenítését kell lehetővé tennie a besorolási séma tetszőleges szintjén:
Igen
Igen
Igen
Igen
Hiv.
iratok; az iratok különböző szintű gyűjteményei (osztályok, dossziék, aldossziék és kötetek); illetve a hozzájuk kapcsolódó metaadatok. 8.1.3.
Az EIKR-nek lehetővé kell tennie a felhasználók számára, hogy metaadatok tetszőleges kombinációjával kereshessenek. A keresőszolgáltatásnak tetszőleges metaadatelem (pl. Cím [Title]) alapján el kell tudnia végezni a keresést.
8.1.4.
Az EIKR-nek lehetővé kell tennie a felhasználók számára annak meghatározását, hogy iratot vagy iratok adott szintű gyűjteményét keresik.
Igen
Igen
8.1.5.
Az EIKR keresőszolgáltatásának minden, a 8.1.2. követelménynek eleget tevő keresésnél azonosnak kell tűnnie a felhasználók előtt.
Nem
Igen
Igen
Igen
Igen
Igen
Más szóval, a felhasználók ugyanazzal a felülettel, eszközökkel és beállításokkal találkoznak függetlenül attól, hogy osztályt, dossziét, aldossziét, kötetet vagy iratot keresnek (a találati eredmények megjelenése azonban eltérhet az egyed típusától függően). 8.1.6.
Az EIKR-nek lehetővé kell tennie a felhasználók számára, hogy az iratok tartalmában kereshessenek. Ide tartoznak az alapvetően szöveges jellegű iratok, például e-mail üzenetek és (amennyiben az EIKR rendelkezik ilyen szolgáltatással) az OCR-rel képekből kinyert szövegek (lásd 6.5.7.).
8.1.7.
Az EIKR-nek biztosítania kell a keresőszolgáltatást az iktatási folyamat során az iktatás helyének meghatározásához. Ez a követelmény a rendszer használhatóságát segíti. A követelmény értelmében az iktatást végző felhasználók számára elérhető a keresőszolgáltatás, így nem kell felfüggeszteniük az iktatást pusztán azért, hogy megkeressék, hová szeretnék az iratot iktatni.
Hiv. 8.1.8.
Követelmény
Köt.
Teszt
Az EIKR-nek lehetővé kell tennie a felhasználók számára, hogy a keresés során egyidejűleg metaadatokat és az irat tartalmából szövegrészleteket használhassanak.
Igen
Igen
Nem
Igen
Tipikus keresés például a szerző nevének (metaadat) és a keresett szöveg egy részletének bevitele keresőkifejezésként. 8.1.9.
Az EIKR keresőszolgáltatásának integrált és konzisztens módon kell kezelnie az iratok tartalmára és a metaadatokra kiterjedő kereséseket. Ez annyit tesz, hogy mindkét típusú keresésnél megegyezik a felhasználói felület és annak viselkedése.
8.1.10.
Az EIKR-nek a keresést követően meg kell jelenítenie a képernyőn a találatok számát és a találati listát (vagy lehetőséget kell biztosítania a felhasználónak az utóbbi megtekintésére).
Igen
Igen
8.1.11.
Az EIKR-nek lehetővé kell tennie a felhasználók számára, hogy a találatokat a keresőkifejezések újbóli bevitele nélkül szűkíthessék.
Nem
Igen
Igen
Igen
Például újabb keresést lehessen végrehajtani a találati listán. 8.1.12.
Az EIKR-nek lehetővé kell tennie az adminisztrátori szerepkörök számára, hogy beállíthassák és később megváltoztathassák az alapértelmezett keresésnél használt metaadat-elemeket, melyek lehetnek: tetszőleges irat, metaadat-elemei;
kötet,
aldosszié,
dosszié
vagy osztály
opcionálisan megadott szöveg. A követelmény a keresési művelet elkezdésekor megjelenő alapértelmezett képernyőre vonatkozik, amely általában a keresések során leggyakrabban használt metaadat-elemeket tartalmazza. A követelmény értelmében az adminisztrátorok állapíthatják meg, melyek legyenek a kezdetben megjelenő elemek.
Hiv. 8.1.13.
Követelmény
Köt.
Teszt
Az EIKR-nek biztosítania kell olyan keresőfunkciót, amely támogatja az alábbi logikai operátorok tetszőleges számú keresőkifejezésre alkalmazott érvényes kombinációját:
Igen
Rész ben
ÉS (AND); VAGY (OR); KIZÁRÓ VAGY (XOR); NEM (NOT). 8.1.14.
Az EIKR-nek lehetővé kell tennie a felhasználók számára, hogy objektumokat kulcsszó, ill. tárgyszó alapján kereshessenek, amennyiben az objektum rendelkezik kulcsszavakkal, ill. az objektumot tárgyszavakkal osztályozták (indexelték).
Igen
Igen
8.1.15.
Tárgyszó alapján végzett kereséskor az EIKR-nek lehetővé kell tennie a felhasználók számára, hogy a tárgyszavakat kötött szótárból (vagy megengedett kifejezések listájáról) választhassák ki.
Igen
Igen
A 8.1.7. követelménnyel összhangban ez akár az iktatási folyamat során is szükséges lehet, de tetszőleges kereséskor is alkalmazható. 8.1.16.
Az EIKR-nek integrálnia kell egy tezauruszt, hogy a felhasználók fogalmak alapján (szemantikai alapon) is kereshessenek.
Nem
Igen
8.1.17.
Amennyiben az EIKR tezaurusszal segíti a fogalomkeresést, a tezaurusznak az alábbi szabványok egyikével kompatibilisnek kell lennie:
Nem
Igen
ISO 27884 ISO 5964. Ezáltal a szűkebb, tágabb vagy rokonértelmű kifejezések alapján is lehet dokumentumokat keresni. A „szemészeti szolgáltatások” kifejezés alapján végzett keresés például az „egészségügyi szolgáltatások”, „szemészet” vagy „szemvizsgálat” kifejezésekre kapott találatokat is megjelenítheti. A felsorolásban az első ISO szabvány egynyelvű tezauruszokra vonatkozik, a második többnyelvűekre (lásd 3.2.13. és 3.2.14.).
4
(magyar tezaurusz esetén az MSZ 3418 szabványt)
Hiv. 8.1.18.
Követelmény
Köt.
Teszt
Amennyiben az EIKR tartalmaz ISO 2788 (MSZ 3418) vagy ISO 5964-kompatibilis tezauruszt, a rendszernek lehetővé kell tennie a tárgyszó alapján kereső felhasználó számára a tezaurusz szolgáltatásainak igénybevételét a folyamat integrált részeként, mint a szűkebb, tágabb, vagy rokonértelmű kifejezések keresését.
Nem
Igen
Igen
Igen
Igen
Igen
A követelmény szemléletesen a következőket jelenti. Tegyük fel, hogy a felhasználó olyan tárgyszó alapján szeretne keresni, amely nem szerepel a kötött szótárban, például a „büdzsé” kifejezést használja az elfogadottabb „költségvetés” helyett. Ebben az esetben a rendszer javasolhatja a felhasználónak a szótárban szereplő szó használatát. A túl általános értelmű kifejezés helyett a rendszer felajánlhatja a szűkebb értelmű kifejezéseket. A rendszer használatát könnyítendő a felhasználók a kereső felületen vehetik igénybe a tezaurusz szolgáltatásait. Lásd a 11.8. szakasz bevezető részében a „folyamat integrált részeként” kifejezés jelentését. 8.1.19.
Amennyiben az EIKR tartalmaz tezauruszt, a rendszernek lehetővé kell tennie egy adminisztrátori szerepkör számára a tezaurusz karbantartását. A karbantartás során a tezaurusz új fogalmakkal és az üzletvitelhez szorosan kapcsolódó fogalmakkal bővül.
8.1.20.
Az EIKR-nek jogosult felhasználókra kell korlátoznia a dossziékhoz kapcsolódó tárgyszavak megváltoztatását. A dossziékhoz fűzött tárgyszavakat csak kivételes körülmények között, például hibajavítás céljából szabad módosítani. A tárgyszavak megváltoztatása súlyosan befolyásolhatja a benne lévő iratok hozzáférhetőségét, még ha az eseménynapló rögzítette is a módosítást. Emiatt a tárgyszavak megváltoztatása kerülendő.
Hiv. 8.1.21.
Követelmény
Köt.
Teszt
Az EIKR-nek lehetővé kell tennie a részleges illesztést és a helyettesítő karakterek használatát a keresőkifejezések elején, végén és belsejében, legyen az metaadat vagy szövegrészlet.
Nem
Igen
Nem
Igen
Helyettesítő karakter a „*” (csillag) és a „?” (kérdőjel). A „*” tetszőleges számú karaktert helyettesít, beleértve a 0-t is, míg a „?” pontosan egy karakter helyettesítésére szolgál. Például: a „proj*” jobbról csonkolt keresőkifejezéssel megtalálhatók a „projekt”, „Projekt” és „projekció” kifejezéseket tartalmazó iratok; a „pszicho*s” kifejezéssel megtalálhatók a „pszichológus”, „pszichoanalatikus” és „pszichoszomatikus” kifejezéseket tartalmazó iratok; a „*bájt” balról csonkolt keresőkifejezéssel megtalálhatók a „gigabájt” és a „terabájt” kifejezéseket tartalmazó iratok; a „vide?” keresőkifejezéssel megtalálhatók a „video” és „videó” kifejezéseket tartalmazó iratok. 8.1.22.
Az EIKR-nek lehetővé kell tennie a felhasználók számára a keresőszavak közelségének meghatározását kereséskor. A keresőszavak közelségének meghatározásakor a rendszer csak az egymástól legfeljebb adott távolságra lévő kifejezéseket találja meg, például: a „Nemzetközi” és a „Szervezet” szavak között legfeljebb egy szó fordulhat elő.
8.1.23.
Az EIKR-nek lehetővé kell tennie, hogy a felhasználók adott iratgyűjteményre (dosszié, osztály stb.) szűkíthessék a keresést a keresés bármely szakaszában.
Igen
Igen
8.1.24.
Az EIKR-nek kérésre meg kell keresnie és meg kell jelenítenia a teljes elektronikus dossziét, aldossziét vagy kötetet annak tartalmával és metaadataival együtt, továbbá meg kell jelenítenie az adott iratgyűjtemény összes bejegyzésének a listáját egyetlen műveletben.
Igen
Igen
Erre akkor lehet szükség, ha a felhasználó egy egész dosszié tartalmát ki szeretné nyomtatni, hogy magával vihesse egy tárgyalásra, vagy az iratokra más okból átmenetileg szükség van.
Hiv. 8.1.25.
Követelmény
Köt.
Teszt
Az EIKR-nek kereséskor azonos módon kell viselkednie, függetlenül attól, hogy a keresett elektronikus objektumok online, nearline vagy offline találhatók. Az egyes objektumok elérésére használt módszerek és azok hatékonysága természetesen eltérő lehet.
Igen
Rész ben
Ez a követelmény csak azokra a környezetekre vonatkozik, ahol az online tárhely mellett offline vagy nearline tárolókat is alkalmaznak.
Követelmény
Köt.
Teszt
8.1.26.
Az EIKR-nek lehetővé kell tennie a felhasználók számára a keresőkifejezések mentését és újbóli felhasználását.
Nem
Igen
8.1.27.
Az EIKR-nek lehetővé kell tennie, hogy a felhasználók elérhetővé tegyék az elmentett keresőkifejezéseket más felhasználók számára.
Nem
Igen
8.1.28.
Az EIKR-nek lehetővé kell tennie a felhasználók számára időintervallumok használatát kereséskor, például napok számát.
Nem
Igen
8.1.29.
Az EIKR-nek lehetővé kell tennie, hogy az időintervallumokat dátumok (pl. 2008. dec. 24. – 2009. jan. 5.) formájában vagy természetes nyelven (pl. „tegnap”, „múlt héten”) lehessen megadni. A rendszernek legalább az alábbi kifejezéseket kell ismernie:
Nem
Igen
Nem
Igen
Nem
Igen
Hiv.
legutóbbi; ez; következő; hét; hónap; negyedév; év; hét napjainak nevei; hónapok nevei. 8.1.30.
Az EIKR-nek lehetővé kell tennie a felhasználók vagy adminisztrátori szerepkörök számára, hogy személyre szabhassák a találati lista megjelenítését, beleértve: a találatok megjelenítésének sorrendjét; az egyszerre megjelenített találatok számát; a keresésenkénti találatok számának korlátozását; a találati listában kiválasztását.
8.1.31.
megjelenítendő
metaadat-elemek
Az EIKR-nek implicit vagy explicit módon rangsorolnia kell a találatokat.
Követelmény
Köt.
Teszt
8.1.32.
Amennyiben a találati lista egy elektronikus irat maszkolt másolatát tartalmazza, vagy olyan iratot, amelynek létezik maszkolt másolata (lásd 9.3. szakasz), az EIKR-nek jeleznie kell a kettő között fennálló kapcsolatot olyan formában, hogy az egyiktől el lehessen érni a másikat és fordítva, ugyanakkor a metaadataikat különítse el a rendszer.
Nem
Igen
8.1.33.
Az EIKR-nek lehetővé kell tennie az alapértelmezett keresőmotor lecserélését másik keresőmotorra.
Nem
Nem
Hiv.
Egyes szervezetek saját keresőmotort szeretnének használni kompatibilitás vagy egyéb okokból kifolyólag.
8.2.
Megjelenítés: az iratok megjelenítése képernyőn
Az EIKR az iratokat különféle formátumban tárolhatja, a felhasználóknak azonban olyan általános megjelenítő képességre van szükségük, amely számos formátumot képes egységesen kezelni. Hiv. 8.2.1.
Követelmény
Köt.
Teszt
Amikor a felhasználó számára a képernyőn osztály, dosszié, aldosszié, kötet vagy irat jelenik meg (pl. látszik a neve), az EIKR-nek lehetővé kell tennie az adott egyed tartalmának és/vagy metaadatainak megjelenítését egyetlen kattintásra vagy billentyűleütésre.
Igen
Igen
A követelmény független attól, hogy a felhasználó milyen módon jutott el az adott képernyőre – pl. bejárta a besorolási sémát, rákeresett, egy hivatkozást követett stb. –, ugyanakkor feltételezi, hogy a felhasználó rendelkezik az egyed megtekintéséhez szükséges jogosultsággal. Például: a felhasználó végrehajtotta a keresést, melynek eredményeként több iratból álló találati listát kapott; a rendszernek lehetővé kell tennie, hogy a felhasználó a listában szereplő iratok tartalmát és metaadatait egyetlen kattintással vagy billentyűleütéssel megnézhesse; a felhasználó a besorolási séma bejárása során olyan osztályra talál, amely számára érdekes dossziékat tartalmazhat; az EIKR-nek lehetővé kell tennie, hogy a felhasználó az osztályban található dossziék nevét és az osztály metaadatait egyetlen kattintással vagy billentyűleütéssel megnézhesse. Amennyiben az EIKR zárt formátumban tárolja az iratokat, elfogadható, hogy az iratot külső alkalmazás jelenítse meg.
Hiv. 8.2.2.
Követelmény
Köt.
Teszt
Az EIKR-nek képesnek kell lennie arra, hogy a találati listában szereplő iratokat az irathoz társított szoftver elindítása nélkül megjelenítse.
Nem
Igen
Nem
Nem
Ez általában egy megjelenítő funkciókat tartalmazó szoftvercsomag integrálását jelenti. Az integrált megoldások gyakran növelik a megjelenítés sebességét. 8.2.3.
Az EIKR-nek olyan formában kell megjelenítenie a szervezet által előírt elektronikus irattípusokat, amely megőrzi az irat vizuális elemeit (pl. az irat készítéséhez használt alkalmazáscsomag által létrehozott vizuális hatásokat és elrendezést), és együtt kezeli az iratot alkotó állományokat. A szervezetnek meg kell határoznia a szükséges alkalmazáscsomagokat és formátumokat, adott esetben pedig a megjelenítés pontosságát. A megjelenítés pontossága sok esetben (pl. tipikus irodai környezetekben) elhanyagolható tényező, más környezetekben azonban fontos szerepet játszik (pl. az iratok nagyfelbontású röntgenfelvételek).
8.3.
Megjelenítés: nyomtatás
Ez a szakasz csak azokra az iratokra vonatkozik, amelyek tartalmát értelmes formában ki lehet nyomtatni. Az audio- és videoanyagok nyomtatása például értelmezhetetlen. Az EIKR-nek olyan képességekkel kell rendelkeznie, amely biztosítja a felhasználók számára a nyomtatásra alkalmas iratok, azok metaadatainak és egyéb adminisztratív információknak a nyomtatására. Az alább felsorolt követelményekben a „nyomtatás” kifejezés magában foglalja a jelentéskészítéseknél elfogadott jellemzőket, beleértve a többoldalas jelentések készítését, az oldalszámozást, fejlécek beállítását és a meghatározott nyomtató használatát. A képernyőkép egyszerű kinyomtatása nem tesz eleget a követelményeknek.
Követelmény
Köt.
Teszt
8.3.1.
Az EIKR-nek ki kell tudnia nyomtatni az iratok tartalmát és az irathoz kapcsolódó kiválasztott metaadat-elemeket.
Igen
Igen
8.3.2.
Az EIKR-nek lehetővé kell tennie tetszőleges osztály, dosszié, aldosszié, kötet vagy irat összes vagy néhány kiválasztott metaadatának a nyomtatását.
Igen
Igen
8.3.3.
Az EIKR-nek lehetővé kell tennie egy osztály, dosszié, aldosszié vagy kötet tartalmát képező összes irat kinyomtatását egyetlen műveletben.
Igen
Igen
8.3.4.
Az EIKR-nek lehetővé kell tennie a felhasználók számára az általuk kiválasztott iratgyűjteményekhez tartozó kiválasztott metaadatelemek (pl. Cím [Title], Szerző [Author], Létrehozás dátuma [Creation date]) összesített listájának a kinyomtatását.
Igen
Igen
8.3.5.
Az EIKR-nek lehetővé kell tennie egy adminisztrátori szerepkör számára, hogy a rendszer konfigurálásakor kijelöljön néhány metaadat-elemet (pl. cím, iktatás dátuma, biztonsági kategória stb.), amelyeket a rendszer minden nyomtatvány végéhez alapértelmezésben hozzáfűz.
Nem
Igen
Hiv.
Ezáltal biztosítható például, hogy minden kinyomtatott iraton szerepeljen az irat biztonsági kategóriája, ami egyfajta biztonsági óvintézkedésnek is tekinthető. 8.3.6.
Az EIKR-nek lehetővé kell tennie a felhasználók számára, hogy nyomtatáskor kibővítsék az alapértelmezetten megjelölt metaadatelemek körét.
Nem
Igen
8.3.7.
Az EIKR-nek lehetővé kell tennie a felhasználók számára a keresések találati listáinak (lásd 8.1. szakasz) kinyomtatását.
Igen
Igen
8.3.8.
Az EIKR-nek lehetővé kell tennie egy adminisztrátori szerepkör számára az összes vagy néhány kiválasztott adminisztratív paraméter értékének a kinyomtatását.
Igen
Igen
Az adminisztrátori szerepkör kérheti például adott biztonsági kategóriával megjelölt felhasználók listájának, vagy egy felhasználócsoport összes felhasználójának a nyomtatását.
Követelmény
Köt.
Teszt
8.3.9.
Az EIKR-nek lehetővé kell tennie egy adminisztrátori szerepkör számára a megőrzési és selejtezési ütemtervek nyomtatását.
Igen
Igen
8.3.10.
Amennyiben a rendszer tartalmaz tezauruszt (lásd 8.1.16.), az EIKRnek lehetővé kell tennie egy adminisztrátori szerepkör számára a tezaurusz kinyomtatását.
Nem
Igen
8.3.11.
Az EIKR-nek ki kell tudnia nyomtatni a rendszerben használt kötött szótárakat (vagy megengedett kifejezések listáját).
Igen
Igen
Hiv.
Amennyiben az EIKR-be integráltak tezauruszkezelő szoftvert, elfogadható, ha a tezauruszt/kötött szótárt az integrált szoftver nyomtatja ki. 8.3.12.
Az EIKR-nek képesnek kell lennie arra, hogy exportálja az egyes kötött szótárakat (vagy megengedett kifejezések listáját).
Nem
Igen
8.3.13.
Amennyiben a rendszer ISO 2788 (MSZ 3418) vagy ISO 5964 kompatibilis tezauruszt használ, az EIKR-nek ki kell tudnia nyomtatni a tezaurusz cikkeit, ezáltal áttekinthető az összes lexikai egység (kifejezés) a közöttük lévő kapcsolatokkal együtt.
Nem
Igen
Az ISO szabványok szerint készült tezauruszok nyomtatásának az ISO 2788 (MSZ 3418) és ISO 5964 előírásait kell követnie. Elfogadható, ha a szótárt az EIKR-be integrált tezauruszkezelő szoftver nyomtatja ki. 8.3.14.
Az EIKR-nek lehetővé kell tennie az arra feljogosított szerepkörök számára, hogy kinyomtathassák a teljes besorolási sémát, vagy annak néhány kiválasztott osztályát.
Igen
Igen
8.3.15.
A besorolási séma nyomtatását (8.3.14.) kérő felhasználónak meg kell tudnia határozni a nyomtatásra kerülő tartalmat és annak formátumát.
Nem
Rész ben
Lehetővé kell tenni például a felhasználó számára, hogy (lehetőleg egy listából) kiválaszthassa a nyomtatandó metaadat-elemeket, és beállíthassa az elemek elrendezését a lapon.
Követelmény
Köt.
Teszt
8.3.16.
Az EIKR-nek lehetővé kell tennie adminisztrátori szerepkörök számára, hogy kinyomtathassák az összes dosszié vagy egy osztályba (és annak gyerekeibe) sorolt összes dosszié listáját (más néven ezt leltárnak is nevezik.)
Igen
Igen
8.3.17.
A dossziék listáját (8.3.16.) nyomtató felhasználó számára lehetővé kell tenni, hogy meghatározhassa a lista sorrendjét, tartalmát és formátumát.
Nem
Igen
Hiv.
A felhasználó kérheti például, hogy a lista csökkenő vagy növekvő rendezettségű legyen, szerepeljen a nyomtatásban a címe vagy a kódja, esetleg más attribútuma, illetve meghatározhatja, hogy mely metaadat-elemeket nyomtassa ki a rendszer. 8.3.18.
Az EIKR-nek lehetővé kell tennie az adminisztrátori szerepkörök számára, hogy kinyomtathassák a teljes eseménynaplót vagy annak egy részét (lásd 4.2.1).
Igen
Igen
8.3.19.
Az EIKR-nek ki kell tudnia nyomtatni a szervezet által előírt formátumokat. A nyomtatásnak:
Igen
Igen
meg kell őriznie az irat létrehozásához használt alkalmazás által készített elrendezést; tartalmaznia kell az elektronikus iratot alkotó összes nyomtatható állományt. A szervezetnek meg kell határoznia a kívánt formátumokat.
8.4.
Megjelenítés: egyéb
Ez a szakasz csak az értelmes formában ki nem nyomtatható iratokra és egyéb információkra vonatkozik, ilyenek például a hang és videó állományok. Hiv. 8.4.1.
Követelmény
Köt.
Teszt
Az EIKR-nek eszközöket kell biztosítania a nem nyomtatható multimédiás iratok megjelenítésére.
Igen
Rész ben
Ide tartoznak például a hang és videó állományok, valamint néhány weboldal. A szervezetnek kell meghatároznia, hogy milyen formátumok megjelenítését szeretné támogatni.
9.
ADMINISZTRÁTORI FELADATOK
Ez a fejezet az elektronikus iratkezelő rendszerek karbantartásával és a rendszer támogatásával foglalkozik. A fejezet az alábbi témakörök követelményeit fedi le: általános adminisztráció (9.1. szakasz); jelentések készítése a rendszer állapotáról (9.2. szakasz); iratok módosítása, törlése és maszkolása (9.3. szakasz). Szorosan kapcsolódik a témához a 4. fejezet két szakasza, nevezetesen: hozzáférési engedélyek, 4.1. szakasz; biztonsági mentés és visszaállítás, 4.3. szakasz. Ezek az eszközök lehetővé teszik, hogy az adminisztrátori szerepkörök kézben tartsák a rendszer felhasználói körében bekövetkező változásokat és a rendszer viselkedését szabályozó paramétereket. Az EIKR-nek gondoskodnia kell arról, hogy az adminisztrátori szerepkörök elláthassák a felhasználói állomány karbantartását, azon belül pedig a szervezet igényeivel összhangban korlátozzák a felhasználók, csoportok és szerepkörök jogosultságait. Az EIKR-nek a rendszerhibák megfigyelését is biztosítania kell. Az alábbiakban felsorolt képességek egy részével az iratkezelő rendszerhez kapcsolt elektronikus dokumentumkezelő rendszer, adatbázis-kezelő rendszer, az operációs rendszer vagy egyéb tetszőleges alkalmazás is rendelkezhet.
9.1.
Általános adminisztráció
Ebben a szakaszban a rendszerparaméterek beállításáról, a rendszer általános kezeléséről és a felhasználók nyilvántartásáról esik szó. Nagyobb szervezetekben az alábbi tevékenységek külön részleg feladatai lehetnek, kisebb szervezetekben azonban elvégezheti mindezt az alkalmazás karbantartásáért felelős adminisztrátor. Hiv. 9.1.1.
Követelmény
Köt.
Teszt
Az EIKR-nek lehetővé kell tennie az adminisztrátori szerepkörök számára a rendszer konfigurálásakor beállított paraméterek lekérdezését, megjelenítését és módosítását.
Igen
Igen
Ilyen paraméter például a hozzáférési jogok kiosztása, vagy a besorolási kódok formátuma.
Hiv. 9.1.2.
Követelmény
Köt.
Teszt
Az EIKR-nek lehetővé kell tennie az adminisztrátori szerepkörök számára, hogy:
Igen
Igen
Igen
Rész ben
Nem
Nem
Nem
Igen
engedélyeket rendelhessenek felhasználókhoz és szerepkörökhöz; bármely szerepkörhöz egy vagy több felhasználót rendelhessenek. 9.1.3.
Az EIKR-nek figyelnie kell a tárhelyen rendelkezésre álló üres hely mennyiségét, és értesítenie kell az adminisztrátori szerepköröket, ha ez a mennyiség egy kritikus szint alá süllyed, vagy egyéb hiba lép fel. Az adminisztrátori szerepköröket egy külön rendszerkezelő szoftver is értesítheti.
9.1.4.
Amennyiben a tárhely támogatja a hibagyakoriság jelentését, az EIKRnek figyelnie kell a tárhelyen bekövetkező hibák gyakoriságát, és jelentenie kell az adminisztrátori szerepkörök számára azokat a tárolókat, amelyeken a hibagyakoriság meghaladja a konfiguráció során vagy később beállított küszöbértéket. A hibák figyelése leginkább az optikai lemezeknél lényeges. Az adminisztrátori szerepköröket egy külön rendszerkezelő szoftver is értesítheti.
9.1.5.
Az EIKR-nek támogatnia kell, hogy az adminisztrátori szerepkörök könnyen áthelyezhessék a felhasználókat különböző felhasználói csoportokba és szerepkörökbe. Különösen fontos, hogy ha egy adminisztrátori szerepkör át szeretne helyezni egy felhasználót, ne kelljen ahhoz törölnie a felhasználót a rendszerből, majd újból bevinni az adatait.
9.2.
Jelentések készítése
Az elektronikus iratkezelő rendszerek fontos részét képezik a jelentéskészítő eszközök. A jelentések segítik az adminisztrátori szerepköröket a rendszer működésének felügyeletében és a karbantartási feladatok kijelölésében. Az EIKR-nek különféle kezelési, statisztikai és ad hoc jelentéseket kell készítenie az adminisztrátori szerepkörök kérésére, melyek lehetővé teszik a rendszertevékenységek és a rendszer állapotának megfigyelését. A jelentéseknek az egész rendszerre ki kell terjedniük, beleértve: a besorolási sémát; a dossziékat és iratokat; a felhasználói tevékenységeket; a hozzáférési és biztonsági engedélyeket;
a selejtezési tevékenységeket. Az EIKR-nek testreszabható és rugalmas, ugyanakkor szabványos jelentések készítését kell támogatnia, hogy az adminisztrátori szerepkör kérésre könnyen és gyorsan előállíthassa a jelentéseket. Ideális esetben az EIKR rugalmas jelentéskészítő alrendszert tartalmaz. Egy ilyen szintű összetett és átfogó alrendszer követelményeit nem áll módunkban jelen Specifikációban kimerítően részletezni, ezért csak a legfontosabb pontokat foglaltuk össze. A jelentéskészítő alrendszer hatásköre és összetettsége olyan jellemzőktől függ, mint a szervezetnél használt besorolási séma mérete, bonyolultsága, a változtatások mértéke, az iratok mennyisége és természete és a felhasználók száma. Követelmény
Köt.
Teszt
9.2.1.
Az EIKR-nek lehetőséget kell biztosítania az adminisztrátori szerepkörök számára rendszeres (naponta, hetente, havonta, negyedévente) és ad hoc jelentések készítésére.
Igen
Igen
9.2.2.
Az EIKR-nek eszközöket kell biztosítania a jelentések kinyomtatására, képernyőn történő megjelenítésére és tárolására elektronikus formátumban.
Igen
Igen
Nem
Igen
Hiv.
A 8.3. szakaszban leírtakkal összhangban a nyomtatás magában foglalja az olyan szokásos funkciókat, mint a többoldalas jelentések nyomtatása, oldalszámozás, a fejlécek ellátása dátummal, a fejlécek és a láblécek tartalmának meghatározása és természetesen a nyomtató kiválasztása. A képernyőképek közvetlen kinyomtatása nem elégíti ki a követelményeknek. 9.2.3.
Az EIKR-ben készített jelentést megjelenítő felhasználó számára lehetővé kell tennie a rendszernek, hogy a jelentést iratként iktassa. Ezáltal a rendszer újabb bizonyítékot nyújt az iratok hitelességéről.
9.2.4.
Az EIKR-nek lehetővé kell tennie a jelentésben lefedett adatok időszakának meghatározását az intervallumhatárok kijelölésével (pl. 2009.09.16-2009.09.23.) vagy természetes nyelven (lásd 8.1.29.).
Nem
Igen
9.2.5.
Az EIKR-nek eszközöket kell biztosítania a jelentésben foglalt adatok kiválasztására és rendezésére.
Igen
Igen
Biztosítani kell például a felhasználó számára, hogy kijelölhesse egy táblázatos formájú jelentésben az adatok rendezésére használt oszlopot. 9.2.6.
Az EIKR-nek eszközöket kell biztosítania a jelentésben foglalt adatok összesítésére.
Nem
Igen
9.2.7.
Az EIKR-nek eszközöket kell biztosítania grafikus jelentések készítésére.
Nem
Igen
Például az adatok hisztogramok.
időszakos
változását
mutató
grafikonok,
Követelmény
Köt.
Teszt
9.2.8.
Az EIKR-nek lehetővé kell tennie a jelentéskérelmek elmentését későbbi újrafelhasználás céljából.
Igen
Igen
9.2.9.
Az EIKR-nek lehetővé kell tennie a jelentések exportálását más alkalmazások részére.
Igen
Igen
Hiv.
Elképzelhető például, hogy a felhasználók a jelentések tartalmát táblázatkezelőben szeretnék megjeleníteni. A MoReq2 nem írja elő az exportáláshoz kiválasztható formátumokat.
Hiv. 9.2.10.
Követelmény
Köt.
Teszt
Az EIKR-nek jelentésbe kell tudnia foglalni az alábbi egyedek számát és helyét a rendszerben:
Igen
Rész ben
Igen
Igen
Igen
Igen
Nem
Igen
Nem
Rész ben
dossziék, aldossziék és kötetek; iratok formátum és verziószám szerint rendezve; dossziék, aldossziék és kötetek hozzáférési szabályok és biztonsági megjelölések szerint rendezve (amennyiben értelmezhető); elektronikus dossziék, aldossziék és kötetek méret szerint rendezve; elektronikus dossziék, aldossziék és kötetek tárhelyen számított elérési út szerint rendezve; kiemelt iratok. 9.2.11.
Az EIKR-nek jelentést kell tudnia készíteni az alábbi adatokról: az iratok iktatásának üteme; az iratok kinyerésének üteme; az új osztályok és dossziék létrehozásának üteme.
9.2.12.
Amennyiben a rendszer támogatja a dokumentumkezelést a 10.3. szakaszban foglaltaknak megfelelően, az EIKR-nek jelentést kell tudnia készíteni az alábbi adatokról: a dokumentumok száma a rendszerben és elérési útjuk; a dokumentumok rögzítésének/létrehozásának üteme; a dokumentumok kinyerésének üteme.
9.2.13.
A 9.2.11. és 9.2.12. követelményekben megfogalmazott jelentések esetén a rendszernek lehetővé kell tennie az adatok szűrését az alábbi megszorítások tetszőleges kombinációjával: a teljes rendszerre vonatkozóan, vagy néhány kijelölt osztály kapcsán; meghatározott felhasználócsoportok vagy felhasználók szerint; meghatározott időintervallumon belül.
9.2.14.
Az EIKR-nek jelentést kell tudnia készíteni a dossziékon és iratokon végzett tevékenységekről felhasználó, munkaállomás és (amennyiben értelmezhető) hálózati cím szerinti rendezésben.
Hiv. 9.2.15.
Követelmény
Köt.
Teszt
Az EIKR-nek lehetővé kell tennie, hogy a 9.2.11. követelményben megfogalmazott jelentések hatáskörét néhány napos időintervallumra lehessen szűkíteni.
Nem
Igen
Az óránkénti összesítések alapján például megfigyelhetők rendszerben végzett tevékenységek csúcsidői és a holtpontok.
a
Követelmény
Köt.
Teszt
9.2.16.
Az EIKR-nek lehetővé kell tennie olyan jelentés készítését, amely egy listában felsorolja a teljes besorolási sémához vagy annak egy részéhez tartozó dossziékat, aldossziékat és köteteket olyan formában, amely a besorolási séma szerkezetét tükrözi.
Igen
Igen
9.2.17.
Az EIKR-nek jelentést kell tudnia készíteni a jelenleg használatban lévő és üres rendszer-tárterületről.
Igen
Igen
9.2.18.
Az EIKR-nek lehetővé kell tennie az adminisztrátori szerepkörök számára, hogy jelentéseket készíthessenek az eseménynaplóról. A jelentéseknek legalább az alábbiak közül kiválasztott egyedekre kell kiterjednie:
Igen
Igen
Nem
Igen
Hiv.
osztály; dosszié; aldosszié; kötet; irat; felhasználó; időszak. 9.2.19.
Az EIKR-nek lehetővé kell tennie az adminisztrátori szerepkörök számára, hogy lekérdezhessék és eseménynapló-jelentést készíthessenek az alábbiak alapján: biztonsági kategóriák; felhasználócsoportok; egyéb metaadatok.
9.2.20.
Az EIKR-nek jelentést kell tudnia készíteni a selejtezési folyamat kimenetéről, felsorolva a sikeresen kiselejtezett osztályokat, dossziékat, aldossziékat, köteteket és iratokat, valamint az esetleges hibákat.
Igen
Igen
9.2.21.
Az EIKR-nek jelentést kell tudnia készíteni a selejtezési folyamat kimenetéről, felsorolva a sikeresen exportált osztályokat, dossziékat, aldossziékat, köteteket és iratokat, valamint az esetleges hibákat.
Igen
Igen
9.2.22.
Az EIKR-nek lehetővé kell tennie az adminisztrátori szerepkörök számára, hogy jelentést készíthessenek a selejtezési tevékenységekről, beleértve az esedékes és késedelmes selejtezési tevékenységek jelentését.
Igen
Igen
Követelmény
Köt.
Teszt
9.2.23.
Az EIKR-nek lehetővé kell tennie az adminisztrátori szerepkörök számára, hogy korlátozhassák a felhasználók hozzáférését a jelentésekhez.
Nem
Igen
9.2.24.
Az EIKR-nek lehetővé kell tennie az adminisztrátori szerepkörök számára, hogy jelentést készíthessenek a hozzáférési szabályok és biztonsági előírások megsértésére irányuló kísérletekről.
Igen
Igen
Hiv.
Ez a követelmény csak abban az esetben értelmezhető, amikor az EIKR (és/vagy az operációs rendszer) beállítása megengedi, hogy a felhasználó értesülést szerezzen azoknak az objektumoknak a létezéséről, amelyeknek a megtekintéséhez nincs jogosultsága. Amennyiben a rendszer nem mutatja azokat az egyedeket, amelyekhez a felhasználó amúgy sem férhetne hozzá, a követelmény nem releváns.
Követelmény
Köt.
Teszt
9.2.25.
A rendszernek lehetővé kell tennie, hogy az adminisztrátori szerepkörök szabályozhassák a megőrzési és selejtezési ütemtervekről készített jelentések gyakoriságát, a jelentésbe foglalt adatokat és kiemelhessék a kivételeket, mint például a késedelmes selejtezést.
Nem
Igen
9.2.26.
Az EIKR-nek lehetővé kell tennie mennyiségi jelentések készítését a meghatározott időn belül felülvizsgálandó iratok típusairól.
Nem
Igen
9.2.27.
Az EIKR-nek jelentéskészítő és elemző eszközökkel kell támogatnia egy adminisztrátori szerepkört a megőrzési és selejtezési ütemtervek kezelésében. A rendszertől az alábbi funkciók várhatók el:
Nem
Igen
Hiv.
a megőrzési és selejtezési ütemtervek felsorolása, indoklás és dátum szerint rendezve; adott megőrzési és selejtezési ütemtervvel rendelkező összes egyed felsorolása; adott osztályba sorolt összes egyed megőrzési és selejtezési ütemtervének felsorolása; a besorolási sémát érintő összes megőrzési és selejtezési ütemterv (és tartalmának) azonosítása, összehasonlítása és felülvizsgálata; a besorolási sémát érintő megőrzési és selejtezési ütemtervek közötti formális ellentmondások azonosítása. 9.2.28.
Az EIKR-nek össze kell tudnia gyűjteni az adott időszakon belül hozott felülvizsgálati döntések adatait, azokat táblázatos és grafikus formában meg kell tudnia jeleníteni.
Nem
Igen
9.2.29.
Az EIKR-nek össze kell tudnia gyűjteni az adott időszakon belül elhelyezett vagy eltávolított selejtezési visszatartások adatait, azokat táblázatos és grafikus formában meg kell tudnia jeleníteni.
Nem
Rész ben
9.2.30.
Az EIKR-nek jelentést kell készítenie az áthelyezés, exportálás, megsemmisítés és törlés során bekövetkező hibákról. A jelentésnek azonosítania kell a feldolgozási hibát előidéző iratokat, azok nagyobb egységeit és a kapcsolódó metaadatokat, illetve minden egyéb egyedet, melynek az áthelyezése, exportálása, megsemmisítése vagy törlése meghiúsult.
Igen
Igen
9.2.31.
Az EIKR-nek jelentést kell készítenie az importálás során bekövetkező hibákról. A jelentésnek azonosítania kell a feldolgozási hibát előidéző iratokat, azok nagyobb egységeit és a kapcsolódó metaadatokat, illetve minden egyéb egyedet, melynek az importálása meghiúsult.
Igen
Igen
Követelmény
Köt.
Teszt
9.2.32.
Az EIKR-nek nyomon kell követnie és jelentéseket kell készítenie az importálási folyamat előrehaladásáról és státuszáról, beleértve az importált iratok számát és százalékos arányát.
Nem
Igen
9.2.33.
Az EIKR-nek lehetővé kell tennie az áthelyezésre kerülő elektronikus dossziék rendezését a felhasználó által kiválasztott metaadatok alapján.
Nem
Igen
9.2.34.
Az EIKR-nek lehetővé kell tennie a felhasználó által meghatározott jelentések készítését az exportálásra vagy áthelyezésre kerülő elektronikus dossziékról és iratokról.
Nem
Igen
9.3.
Iratok módosítása, törlése és maszkolása
Hiv.
Az iratkezelés általános alapelvei közé tartozik, hogy az iratokat nem lehet megváltoztatni, a dossziékat, aldossziékat, köteteket és iratokat pedig (kivéve az életciklusuk lejártát) nem lehet megsemmisíteni. Ez a szakasz azokat a kivételes helyzeteket mutatja be, amelyek az iktatott iratok kiegészítését, törlését vagy cseréjét kívánják meg. Bizonyos esetekben az adminisztrátori szerepkörök kénytelenek törölni az iratot valamilyen hiba kijavítása vagy egy törvényi előírás betartása érdekében. Az adatvédelmi törvény előírásai például megkövetelhetik az iratok megsemmisítését, de természetesen más helyzetek is elképzelhetők. Egy irat törlése az alábbi két lehetőség egyikét jelenti: megsemmisítés; megőrzés, azzal a feltétellel, hogy az irat metaadatai között jelöli a rendszer, hogy az iratra többé nem vonatkoznak az iratkezelési szabályok. A törlés mindkét esetben kivételes műveletnek számít, így arra szigorú szabályok érvényesek az iratok integritásának védelme érdekében. A törléseket minden esetben fel kell tüntetni az eseménynaplóban. Ha helyi törvények vagy szabályok például a személyes adatok törlésére vonatkozóan eltérő feltételeket szabnak (lásd ISO 12037), akkor erre a nemzeti változat nulladik fejezetében kell kitérni. Az adminisztrátori szerepkörök néha kénytelenek bizalmas információt tartalmazó iratokat közzétenni oly módon, hogy közben nem tehetik nyilvánossá a bizalmas részeket. A bizalmas adatok védelmét számos szempont teheti indokolttá, például az adatvédelmi törvény, biztonsági megfontolások, pénzügyi kockázat stb. Ennél fogva az adminisztrátori szerepkörök számára lehetőséget kell biztosítani a bizalmas adatok elfedésére az irat megváltoztatása nélkül. A MoReq2 ezt a folyamatot nevezi maszkolásnak. A maszkolás eredményeképp az eredeti irat érintetlen marad (nem változik), és létrejön egy másodpéldány, amely annyiban különbözik az eredeti irattól, hogy a bizalmas adatok felismerhetetlenek (ezt nevezzük
maszkolt másolatnak, vagy az eredeti irat maszkolásának). Az EIKR mind az eredeti iratot, mind annak maszkolt változatát tárolja. Elméletileg az összes iratforma maszkolható, beleértve a szöveges, képi, hang- és videoanyagokat. Megjegyzés. Az iratok törlését és módosítását az 5. fejezet is érinti. Hiv. 9.3.1.
Követelmény
Köt.
Teszt
Az EIKR-nek biztosítania kell olyan konfigurációs beállítást, amellyel megakadályozható, hogy az iktatott iratot adminisztrátori vagy felhasználói szerepkör törölhesse vagy mozgathassa; lásd még 9.3.3.
Igen
Igen
Igen
Igen
Igen
Igen
A követelmény nem vonatkozik az iratoknak a megőrzési és selejtezési ütemterv szerinti áthelyezésére és megsemmisítésére (ezzel kapcsolatban lásd 5.3. szakasz). Az iratok törlését olyan környezetekben ésszerű kikapcsolni, ahol a törlés fölösleges vagy tilos. A követelmény alternatívája a 9.3.2. pontban olvasható. 9.3.2.
Az EIKR-nek lehetővé kell tennie egy olyan konfigurációs beállítást a 9.3.1. alternatívájaként, amely a törlést az irat megsemmisítéseként, az áthelyezést pedig az irat fizikai mozgatásaként határozza meg. Lásd még 9.3.4. A követelményben megfogalmazott eljárás nem követendő példa. Azért szerepel a követelmények között, hogy lefedje azokat a helyzeteket, amikor ez elkerülhetetlen, egyébként a 9.3.1. követelmény részesítendő előnyben. A 9.3.1. és ez a lehetőség kölcsönösen kizárják egymást.
9.3.3.
Amennyiben az EIKR a 9.3.1. lehetőséget valósítja meg, a rendszernek a következőképpen kell viselkednie: Amikor egy adminisztrátori szerepkör iratot „töröl” (a 9.3.5. követelménynek megfelelően), a rendszer metaadattal jelöli, hogy az irat tartalma és metaadatai többé nem jeleníthetők meg a felhasználók előtt, kivéve a megfelelő jogosultsággal rendelkező adminisztrátori szerepköröket; a műveletet a rendszer az eseménynaplóban rögzíti. Amikor egy adminisztrátori szerepkör iratot „helyez át” (a 9.3.4. követelménynek megfelelően), az EIKR a törléshez hasonló műveletet hajt végre azzal a különbséggel, hogy másolatot hoz létre (vagy mutatót, a tárolás megvalósításától függően) az új helyen. A törölt iratok megjelenítését lehetőleg egyetlen adminisztrátori szerepkör számára sem szabad engedélyezni, vagy ha igen, csak egy nagyon szűk kör számára.
Hiv. 9.3.4.
Követelmény
Köt.
Teszt
Amennyiben az EIKR a 9.3.2. lehetőséget valósítja meg, a rendszernek a következőképpen kell viselkednie:
Igen
Igen
Igen
Igen
Igen
Igen
Igen
Igen
Amikor egy adminisztrátori szerepkör iratot töröl (a 9.3.5. követelménynek megfelelően), a rendszer törli az iratot annak metaadataival együtt, kivéve a metaadatcsonk számára előírt metaadatokat (lásd 5.3.19.); a műveletet a rendszer az eseménynaplóban rögzíti. Amikor egy adminisztrátori szerepkör iratot helyez át (a 9.4.1. követelménynek megfelelően), az EIKR a törléshez hasonló műveletet hajt végre azzal a különbséggel, hogy másolatot hoz létre (vagy mutatót, a tárolás megvalósításától függően) az új helyen. 9.3.5.
Az EIKR-nek lehetővé kell tennie adminisztrátori szerepkörök számára, hogy osztályokat, dossziékat, aldossziékat, köteteket és iratokat a hagyományos selejtezési folyamaton kívül is törölhessenek. Ez a lehetőség különös körültekintést igényel, amint azt a szakasz bevezetője is részletezi. A követelményt a 9.3.1. és 9.3.2. pontokkal együtt kell értelmezni.
9.3.6.
Az EIKR-nek lehetővé kell tennie felhasználói szerepkörök számára, hogy osztályokat, dossziékat, aldossziékat, köteteket és iratokat törlésre javasolhassanak. Az adminisztrátori szerepkör pedig eldöntheti, hogy elvégzi-e a kért törlést, vagy nem.
9.3.7.
Az előbbiekben leírt bármelyik törlés esetén az EIKR-nek: rögzítenie kell a törlést az eseménynaplóban; jelentést kell készítenie az adminisztrátori szerepkörök részére; osztály, dosszié, aldosszié vagy kötet törlésekor annak teljes tartalmát is törölnie kell; biztosítania kell, hogy egy dokumentum törlése nem változtat meg egy másik iratot (egy dokumentum például két irat részét is képezheti, és törlik az egyiket); jeleznie kell az adminisztrátori szerepkörök számára, ha a törlésre szánt dossziéra, aldossziéra vagy kötetre más dosszié vagy irat hivatkozik, ez esetben a törlés megerősítését kell kérnie; meg kell őriznie a metaadatok integritását minden időben. A „metaadatok integritásának megőrzése” ebben a szövegkörnyezetben azt jelenti, hogy egyetlen metaadat sem vonatkozhat nem létező egyedre.
Hiv. 9.3.8.
Követelmény
Köt.
Teszt
Az adminisztrátori szerepkörök módosíthatják a felhasználók által bevitt metaadat értékeket.
Igen
Igen
Ezáltal az adminisztrátori szerepkörök kijavíthatják a felhasználók hibáit, például a hibás adatbevitelt, félregépeléseket stb., illetve felügyelhetik a felhasználók és a csoportok hozzáféréseit. A jó iratkezelési gyakorlat szerint a felhasználók önállóan kijavítják saját hibáikat – jelen követelmény nem zárja ki ennek lehetőségét. 9.3.9.
A rendszer köteles rögzíteni a metaadat-elemeken módosítások részleteit az eseménynaplóban.
végzett
Igen
Igen
9.3.10.
Az EIKR-nek lehetővé kell tennie az adminisztrátori szerepkörök számára, hogy maszkolhassák az iratokat, miközben megőrzik az eredeti példányt.
Igen
Igen
Igen
Rész ben
Bizonyos esetekben szükséges lehet az iratot több maszkolt változatban közzétenni különböző felek részére. 9.3.11.
Az EIKR-nek lehetővé kell tennie a maszkolás keretein belül az irat bizalmas adatainak az eltávolítását vagy elrejtését a szervezet által előírt formátumokban. Amennyiben az EIKR maga nem képes maszkolásra, a rendszerbe integrálni kell egy arra alkalmas szoftvercsomagot. A maszkolás során az EIKR áthelyezheti más megjelenítési formába az irat másolatát, feltéve, hogy az így keletkezett irat kellően hű az eredetihez. Lényeges, hogy a maszkolással elrejtett adatokat ne lehessen semmilyen módszerrel sem kinyerni a maszkolt példányból, függetlenül attól, hogy azt képernyőn jelenítik meg, kinyomtatják, lejátsszák vagy egyéb más módon férnek hozzá. Az eredeti adatokat ne lehessen kinyerni elforgatással, nagyítással vagy egyéb módon, beleértve a maszkolt példány megnyitását másik szoftverrel.
Követelmény
Köt.
Teszt
9.3.12.
Az EIKR-nek automatikusan fel kell tüntetnie a maszkolt példány létrehozásának tényét a maszkolt példány és az irat metaadatai között, beleértve a létrehozás dátumát, pontos idejét és a létrehozót.
Igen
Igen
9.3.13.
Az EIKR-nek ki kell kényszerítenie, hogy a maszkolást kezdeményező felhasználó megindokolja a maszkolást; a rendszernek rögzítenie kell az indoklást az eredeti irat és a maszkolt példány metaadatai között.
Igen
Igen
9.3.14.
A maszkolt példányok létrehozásakor az EIKR-nek automatikusan irattá kell nyilvánítania a maszkolt másolatokat. A maszkolt változatokat ugyanabba az egységbe (dosszié, osztály stb.) sorolják be, mint az eredeti iratot. A rendszer az alábbi adatok bevitelét várja el a maszkolást elvégzőtől:
Nem
Rész ben
Hiv.
indoklás (lásd 9.3.13); biztonsági kategória (amennyiben értelmezhető); opcionálisan a maszkolás besorolása másik helyre. 9.3.15.
Maszkolt példány létrehozásakor az EIKR-nek lehetővé kell tennie az eredeti irat metaadatainak átvételét.
Nem
Igen
9.3.16.
Megfelelő hozzáférési jogok függvényében az EIKR-nek lehetővé kell tennie néhány kiválasztott metaadat (pl. cím) értékének kiegészítését.
Nem
Igen
9.3.17.
Az EIKR-nek a maszkolásra mutató kereszthivatkozást kell elhelyeznie az eredeti iratot tartalmazó osztályban, dossziéban, aldossziéban vagy kötetben, akkor is, ha az adott osztályt, dossziét, aldossziét vagy kötetet már lezárták.
Nem
Igen
Ez a követelmény a 9.3.14. pontban leírtakat egészíti ki: nem elég egyszerűen elhelyezni a besorolási sémában az eredeti irattal egy helyen a maszkolt példányt. Mivel a kettő között rengeteg irat helyezkedhet el, szükség van kereszthivatkozásra. 9.3.18.
Irat lekérdezésekor az EIKR-nek automatikusan vagy a felhasználó kérésére meg kell mutatnia a felhasználó számára az irat maszkolt példányainak létezését, és a hozzáférési és biztonsági szabályok figyelembevételével rendelkezésre kell bocsátania azokat.
Igen
Igen
9.3.19.
Maszkolt másolat lekérdezésekor az EIKR-nek magától vagy a felhasználó kérésére meg kell mutatnia a felhasználó számára az irat eredeti példányának létezését, és a hozzáférési és biztonsági szabályok figyelembevételével rendelkezésre kell bocsátania azt.
Igen
Igen
9.3.20.
Az EIKR-nek rögzítenie kell az eseménynaplóban az összes, ebben a szakaszban bemutatott követelmény szerint végrehajtott módosítást.
Igen
Rész ben
10.
OPCIONÁLIS MODULOK
Ez a fejezet az elektronikus iratok kezeléséhez szorosan kapcsolódó egyéb hasznos funkciók követelményeit foglalja össze. A fejezet kitér a fizikai (nem elektronikus) iratok kezelésére, a dokumentumok kezelésére, a munkafolyamatokra, az elektronikus aláírásokra és néhány további szolgáltatásra. A fejezet minden egyes szakasza a MoReq2 tesztelési keretrendszer egy-egy opcionális moduljának felel meg. A modulok opcionálisak abban az értelemben, hogy nem részei a MoReq2-vel kompatibilis iratkezelő rendszerek alapfunkcióinak. A szakaszok sorrendben az alábbi témákat fedik le: fizikai iratok kezelése (10.1. szakasz); fizikai iratok selejtezése (10.2. szakasz); dokumentumkezelés és kollaboráció (10.3. szakasz); munkafolyamatok (10.4. szakasz); ügyviteli környezetek (10.5. szakasz); tartalomkezelő rendszerek integrálása (10.6. szakasz); elektronikus aláírás (10.7. szakasz); titkosítás (10.8. szakasz); digitális jogkezelés (10.9. szakasz); elosztott rendszerek (10.10. szakasz); offline és távoli munka (10.11. szakasz); fax integrálása (10.12. szakasz); biztonsági kategóriák (10.13. szakasz). A fejezetben megfogalmazott követelmények olyan opcionális funkciókat írnak le, melyeket igény szerint integrálni lehet egy iratkezelő rendszerbe, tehát a MoReq2 által előírt alapkövetelményeket egészítik ki. Csak akkor tekinthetők irányadónak, ha a szervezet meg kívánja valósítani az opcionális szolgáltatásokat. A MoReq2-megfelelésnek nem előfeltétele az itt megfogalmazott követelmények teljesítése. A kötelezőként feltüntetett követelmények tehát csak az adott modulon belül kötelező érvényűek, a rendszer egészére nézve nem azok. A követelmények minden szolgáltatás esetén magas szintűek és nem teljesek. Mivel ezek az opcionális modulok nem tartoznak a rendszer alapfunkcióihoz, a MoReq2 csak érintőlegesen utal az egyes moduloktól elvárható funkciókra.
10.1.
Fizikai (nem elektronikus) dossziék és iratok kezelése
A legtöbb szervezet az elektronikus iratokon túl nem elektronikus, avagy fizikai iratokat is tárol. Ide tartoznak a papíralapú iratok, az analóg tárolóeszközökön, például mikrofilmen vagy kazettán őrzött iratok, de a hordozható tárolókra (CD, DVD, mágnesszalag) rögzített digitális iratok is megemlíthetők ebben a csoportban. A MoReq2 értelmében tehát fizikai iratnak tekinthető minden olyan irat, amelynek tárolása az elektronikus iratkezelő rendszeren kívüli hordozóközegen történik. Nemcsak az analóg tárolók tartoznak ebbe a csoportba, hanem azok a digitális közegek is, amelyek az EIKR kezelésén kívül nem eső iratokat tárolnak. Például: ha egy CD-ROM 10 000 képet tartalmaz, melyeket az EIKR nem ismer fel iratként, fizikai iratnak tekintendők; ha egy CD-ROM 10 000 képet tartalmaz, de a lemezt egy meghajtóba helyezik, melyet az EIKR lát, és a rendszer felismeri a képeket mint iratokat, nem fizikai, hanem elektronikus iratokról van szó (melyek hordozható tárolón helyezkednek el). A Specifikáció nem foglalkozik a fizikai iratok kezelésének és karbantartásának üzleti igényeivel, mert az adott jogszabályi és szabályozási környezettől függően lehet, hogy ilyen igények fel sem merülnek. Amennyiben mégis, a szervezet feladata, hogy előírásokat fogalmazzon meg az elektronikus és fizikai iratok egységes integritásának és hozzáférhetőségének megőrzéséhez. Az EIKR-t fel kell készíteni a fizikai iratok hivatkozásainak kezelésére az elektronikus iratokéhoz hasonló módon, továbbá képessé kell tenni elektronikus és fizikai iratokat vegyesen tartalmazó iratgyűjtemények kezelésére is. Az osztályok, dossziék, aldossziék és kötetek elektronikus és fizikai iratokat egyaránt tartalmazhatnak, tetszőleges kombinációban. Ez jelentős változás a MoReq korábbi változatához képest. A fizikai iratok többek között az alábbi helyzetekben keveredhetnek elektronikus iratokkal: Egy osztály, dosszié, aldosszié vagy kötet csak fizikai iratokat tartalmaz. Ebben az esetben az EIKR-ben használt gyűjtő egyed (osztály, dosszié stb.) a fizikai iratokat a valós életben összefogó tárolóeszköz, például gyűrűs mappa megfelelője; Egy osztály, dosszié, aldosszié vagy kötet fizikai és elektronikus iratokat egyaránt tartalmaz. A fizikai iratokat az iratkezelés szempontjából lényeges gyűjtőn kívül tárolják, például a műszaki rajzokat más, nem kapcsolódó rajzokkal egy fiókban. Az EIKR-nek eszközöket kell biztosítania a fizikai tárolók (lásd első pont) kezeléséhez. A fizikai iratok kezelésének első és legfontosabb része az iratok metaadatainak rögzítése és kezelése. Ezek a metaadatok lehetővé teszik, hogy a fizikai iratokat ugyanolyan hozzáférési szabályok szerint lehessen besorolni, visszakeresni, felülvizsgálni, nyomon követni és kiselejtezni, mint az elektronikus iratokat. Az EIKR-t képessé kell tenni a fizikai iratgyűjtők metaadatainak rögzítésére és kezelésére.
Követelmény
Köt.
Teszt
10.1.1.
Az EIKR-nek lehetővé kell tennie, hogy egy adminisztrátori szerepkör azonosíthassa a rendszer azon osztályait, dossziéit, aldossziéit és köteteit, amelyeknek léteznek valós fizikai megfelelői.
Igen
Igen
10.1.2.
Az EIKR-nek lehetővé kell tennie adminisztrátori és felhasználói szerepkörök számára, hogy a valós fizikai megfelelővel rendelkező osztályokhoz, dossziékhoz, aldossziékhoz és kötetekhez a MoReq2 metaadat-modellnek megfelelő metaadatokat fűzhessenek, és azokat karbantarthassák.
Igen
Igen
10.1.3.
Az EIKR-nek lehetővé kell tennie felhasználói szerepkörök számára, hogy az osztályokban, dossziékban, aldossziékban vagy kötetekben tárolt fizikai iratokhoz adatokat fűzhessenek, és azokat karbantarthassák az elektronikus iratok iktatására vonatkozó szabályoknak megfelelően.
Igen
Igen
10.1.4.
Az EIKR-nek lehetővé kell tennie az elektronikus és fizikai iratok tetszőleges kombinációjának tárolását az osztályokban, dossziékban, aldossziékban és kötetekben.
Igen
Igen
10.1.5.
Az EIKR-nek azonos módon kell kezelnie a fizikai és az elektronikus iratokat, beleértve a metaadatok öröklődését.
Igen
Rész ben
10.1.6.
Egy osztály, dosszié, aldosszié vagy kötet böngészése, megtekintése stb. során a rendszernek egyértelmű jelöléssel kell megkülönböztetnie a fizikai iratokat és tárolókat.
Nem
Igen
Hiv.
A felhasználónak látnia kell, hogy tartalmaz-e az iratgyűjtő fizikai egyedeket, így gondoskodhat az iratok egységes kezeléséről. A MoReq2 nem írja elő a megkülönböztető jelölések jellegét.
Hiv. 10.1.7.
Követelmény
Köt.
Teszt
Az EIKR-nek lehetővé kell tennie, hogy egy adminisztrátori szerepkör az elektronikus egyedekétől eltérő metaadat-elemek felvételét határozhassa meg a fizikai osztályok, dossziék, aldossziék, kötetek és iratok vonatkozásában. Egy fizikai dosszié metaadatai közé indokolt lehet például az alábbi metaadatokat felvenni:
Igen
Igen
a dosszié fizikai helye; a fizikai iratgyűjtő vagy irat formátumára vonatkozó információ. 10.1.8.
Az EIKR-nek biztosítania kell, hogy bármely osztály, dosszié, aldosszié vagy kötet lekérdezésekor az elektronikus és fizikai iratok metaadatait egyszerre, egy műveletben találja meg.
Igen
Igen
10.1.9.
Az EIKR-nek támogatnia kell a fizikai irattárolók és iratok nyomkövetését azáltal, hogy az iratok tárolási helyének, kölcsönzési és visszahozatali idejének, és a kölcsönző ügyintéző vagy tárfelügyelő nevének a rögzítését lehetővé teszi.
Nem
Igen
10.1.10. Az EIKR-nek lehetővé kell tennie a fizikai iratgyűjteményt vagy iratot kikérő felhasználó számára, hogy meghatározza az iratgyűjtemény vagy irat visszahozatalának dátumát.
Nem
Igen
10.1.11. Az EIKR-nek jelentenie kell a meghatározott felhasználó felé, ha egy fizikai iratgyűjtemény vagy irat visszahozatali idejének lejárta közeleg, vagy letelt.
Nem
Igen
10.1.12. Az EIKR-nek lehetővé kell tennie egy megfelelő jogosultsággal rendelkező felhasználó számára, hogy egyetlen műveletben megváltoztathassa egy vagy több fizikai iratgyűjtemény vagy irat visszahozatalának időpontját.
Nem
Igen
10.1.13. Az EIKR-nek biztosítania kell, hogy a fizikai iratgyűjtemények és iratok metaadat-aira ugyanazok a hozzáférési szabályozások vonatkozzanak, mint az elektronikus egyedekére.
Igen
Igen
10.1.14. Az EIKR-nek nyomkövető eszközt kell biztosítania, amellyel a felhasználók bevihetik a fizikai iratgyűjtemények és iratok helyváltoztatásának adatait.
Nem
Igen
10.1.15. Az EIKR nyomkövető eszközének lehetővé kell tennie, hogy a fizikai egyedek helyét ellenőrzött listából lehessen kiválasztani (pl. legördülő listából), vagy a rendszer ellenőrizze a bevitt helyadatok helyességét ilyen lista segítségével.
Nem
Igen
Amennyiben az EIKR nem tartja nyilván a helyeket, a nem validált egyszerű szöveges megfogalmazás is megfelel.
Köt.
Teszt
Igen
Igen
Igen
Igen
10.1.18. Az EIKR-nek lehetővé kell tennie, hogy a felhasználó megfelelő hozzáférési szabályok betartásával megtekinthesse a kikölcsönzött fizikai egyed jelenlegi helyét, a kölcsönzést végző ügyintéző vagy tárfelügyelő nevét, és a kölcsönzés időpontját.
Igen
Igen
10.1.19. Az EIKR-nek rögzítenie kell az eseménynaplóban minden egyes kölcsönzési és visszahozatali eseményt.
Igen
Igen
10.1.20. Az EIKR-nek rögzítenie kell az eseménynaplóban a fizikai egyedek metaadat-értékein végzett módosításokat.
Igen
Igen
Nem
Igen
Hiv.
Követelmény
10.1.16. Az EIKR nyomkövető eszközének lehetővé kell tennie, hogy a felhasználók rögzíthessék a fizikai egyedek kölcsönzését és visszahozatalát. Más szóval az EIKR-nek számon kell tartania, hogy egy adott fizikai egyed a megszokott helyén van-e, vagy kikölcsönözték. 10.1.17. Az EIKR nyomkövető eszközének az alábbi adatokat kell rögzítenie a fizikai egyedek mozgatásáról: egyedi azonosító; jelenlegi hely; adminisztrátori szerepkör által beállítandó) számú előző hely;
előírt
(konfiguráció
során
elvitel dátuma; érkezés dátuma; áthelyezésért felelős személy (amennyiben értelmezhető).
Különös tekintettel a „hely” metaadatelem értékére. 10.1.21. Az EIKR-nek támogatnia kell a dossziék, aldossziék és iratok vonalkódjainak nyomtatását és felismerését, vagy egyéb nyomkövető rendszerek, mint a Radio Frequency Identification (RFID) technológia használatát. Ez segíti a fizikai iratok helyének és áthelyezéseinek nyomon követését.
Hiv.
Követelmény
10.1.22. Az EIKR-nek támogatnia kell címkék nyomtatását a fizikai dossziék, aldossziék és kötetek azonosításához.
Köt.
Teszt
Nem
Igen
Igen
Igen
Nem
Igen
A címke foglalja össze a lényeges metaadatokat, többek között az alábbiakat: Cím (Title); Rendszerazonosító (Identifier – System); Besorolási kód (Classification Code); Megnyitás dátuma (Date of Opening); Biztonsági kategória (Security Category) (ha vonatkozik az egyedre); Megszokott helye. 10.1.23. Az EIKR-nek az alábbi két pont kivételével azonos módon kell kezelnie az elektronikus és a fizikai iratokat a keresések során: a fizikai iratok tartalmát nem lehet megjeleníteni (helyette a rendszer az irat helyére vonatkozó információt jeleníti meg, lásd alább); a fizikai és elektronikus iratok esetében a rendszer eltérő metaadatokat jeleníthet meg. 10.1.24. Az EIKR-nek értesítenie kell az adminisztrátori szerepköröket a nem elektronikus iratokkal és iratgyűjteményekkel összefüggő, a legutóbbi visszaállítás óta bekövetkezett megőrzési és selejtezési ütemtervben előírt eseményekről. A 4.3. szakasz (Biztonsági mentés és visszaállítás) foglalja össze az elektronikus iratkezelő rendszerek visszaállíthatóságának követelményeit. Rendszer-visszaállítás után előfordulhat, hogy a fizikai objektumokat selejtezték, de a rendszer ezt nem mutatja. A követelmény biztosítja az adminisztrátorok számára, hogy javíthassák az ellentmondásokat.
10.2.
Fizikai iratok selejtezése Követelmény
Köt.
Teszt
10.2.1.
Az EIKR-nek értesítenie kell egy adminisztrátori szerepkört, amikor egy fizikai egyedhez társított megőrzési és selejtezési ütemtervben előírt megőrzési idő lejár.
Igen
Igen
10.2.2.
Az EIKR-nek figyelmeztetnie kell egy adminisztrátori szerepkört, ha egy áthelyezésre, exportálásra vagy megsemmisítésre jelölt osztály, dosszié, aldosszié vagy kötet fizikai egyedet is tartalmaz.
Igen
Igen
Hiv.
Az eseményt kiválthatja a megőrzési és selejtezési ütemtervben előírt selejtezés bekövetkezte, más esetben egy áthelyezési vagy exportálási kérelem.
10.2.3.
A fizikai egyedek exportálása vagy áthelyezése során az EIKR-nek támogatnia kell azok metaadatainak exportálását vagy áthelyezését az elektronikus egyedekével azonos módon.
Igen
Igen
10.2.4.
A fizikai egyedek áthelyezése, exportálása vagy megsemmisítése során az EIKR-nek megerősítést kell kérnie egy adminisztrátori szerepkörtől, hogy az áthelyezés, exportálás vagy megsemmisítés a valós életben is megtörtént-e.
Igen
Igen
Ez általában annyit tesz, hogy egy adminisztrátori szerepkörnek manuálisan meg kell erősítenie, hogy a fizikai iratok áthelyezése vagy megsemmisítése megtörtént.
10.3.
Dokumentumkezelés és kollaboráció
Számos szervezet használ elektronikus dokumentumkezelő rendszert (EDKR-t) az elektronikus dokumentumok kezelésére és ellenőrzésére. Az EDKR funkciók jelentős átfedést mutatnak az iratkezelő rendszerek funkcióival. Az elektronikus dokumentumkezelő rendszerek elterjedt szolgáltatásai közé tartozik a dokumentumok indexelése, a tároláskezelés, a verziókövetés és az asztali alkalmazásokkal való szoros együttműködés a dokumentumok elérése céljából. Egyes EIKR-ek az EDKR-ek összes funkcióját megvalósítják, mások csak egy kis részhalmazát. Hasonlóképpen léteznek olyan dokumentumkezelők, amelyek alapvető iratkezelést is biztosítanak. Az elektronikus dokumentumkezelők gyakran egy nagyobb rendszer részei, ezesetben előfordul, hogy támogatják az együttműködésen alapuló munkavégzést, más szóval kollaborációt, amikor több felhasználó is részt vehet a dokumentumok szerkesztésében. A kollaboráció a tartalomkezelő rendszereknél is kiemelt szerepet kap. Lásd a 10.6. szakaszt a tartalomkezelőkkel kapcsolatos követelmények részletes leírásáért. Az alábbi táblázat az EDKR-ek és EIKR-ek közti alapvető különbségeket foglalja össze: Egy EDKR-ben…
Egy EIKR-ben…
a dokumentumok módosíthatók;
az iratok nem módosíthatók;
egy dokumentumnak egyidejűleg több változata is lehet;
egy iratnak egyetlen, végleges változata lehet;
a dokumentumokat törölhetik a dokumentum tulajdonosai;
iratot törölni szigorúan tilos, néhány kivételes helyzettől eltekintve;
esetenként alkalmaznak megőrzési
szigorú megőrzési szabályokat
Egy EDKR-ben…
Egy EIKR-ben…
szabályokat;
alkalmaznak;
lehet dokumentumtárolási szerkezetet használni, ez a felhasználók hatáskörébe tartozik;
szigorú irattári rendszert (a besorolási sémát) használnak, melynek karbantartása egy adminisztrátori szerepkör feladata;
az elsődleges cél az üzletvitel során keletkező dokumentumok mindennapi kezelése.
az elsődleges cél a szervezet fontos iratainak a biztonságos tárolása, a mindennapi feladatok támogatása mellékes.
A szakasz további része egy integrált EIKR-EDKR megoldással szemben támasztott követelményeket tárgyalja. A követelményeket csak abban az esetben kötelező megvalósítani, ha az iratkezelő rendszer részét képezi a dokumentumkezelés. A követelmények alapelve, hogy a dokumentumokat ugyanazokban az osztályokban és dossziékban lehet tárolni, mint az iratokat, bár ez a lehetőség opcionális. Ugyanakkor a dokumentumok és az iratok egy helyen történő tárolása lehetővé teszi, hogy az iratok kezdeti változatait ugyanabban az iratgyűjtőben lehessen elérni. Megjegyzés. A dokumentum kifejezés ebben a szövegkörnyezetben olyan információ vagy objektum leírását jelenti, amelyet nem iktattak iratként az EIKR-ben. Hiv. 10.3.1.
Követelmény
Köt.
Teszt
Az EIKR-nek az elektronikus dokumentumokat és iratokat egyazon besorolási sémán belül kell kezelnie, azonos hozzáférési szabályozások mellett.
Nem
Igen
Igen
Igen
A követelmény célja, hogy a felhasználók együtt tárolhassák a piszkozatokat a későbbi végleges iratokkal. A követelmény opcionális. 10.3.2.
Amennyiben az EIKR a dokumentumokat és az iratokat egyazon besorolási sémán belül kezeli, egyértelműen jeleznie kell az egyedekről, hogy azok dokumentumok vagy iratok. A MoReq2 nem írja elő a jelölés módját.
Hiv. 10.3.3.
Követelmény
Köt.
Teszt
Amennyiben az EIKR a dokumentumokat és az iratokat egyazon besorolási sémán belül kezeli, az alábbi feladatok elvégzését biztosítania kell minden felhasználói szerepkör számára az egyes osztályok és dossziék esetén:
Igen
Igen
Igen
Igen
Igen
Rész ben
Igen
Igen
Igen
Igen
az összes dokumentum irattá nyilvánítása; az összes dokumentum törlése az iratok megőrzésével; egy adott időpontnál régebben létrehozott dokumentumok törlése. 10.3.4.
Amennyiben az EIKR a dokumentumokat és az iratokat egyazon besorolási sémán belül kezeli, értesítenie kell egy adminisztrátori szerepkört, ha egy exportálandó osztály vagy dosszié dokumentumokat is tartalmaz. Az adminisztrátori szerepkör az alábbi lehetőségek közül választhat: a dokumentumok törlése; a dokumentumok irattá nyilvánítása; a dokumentumok exportálása az iratokkal együtt.
10.3.5.
Amennyiben az EDKR egy EIKR része, vagy ahhoz szorosan kapcsolódik, az EDKR-nek automatikusan iktatásra kell tudnia küldeni az EIKR-be az üzleti folyamatok során keletkező elektronikus dokumentumokat. Ez a követelmény különösen az ügyviteli környezetekben fontos, lásd 10.5. szakasz.
10.3.6.
Az EIKR-nek lehetővé kell tennie a felhasználók számára egy elektronikus dokumentum rögzítését és irattá nyilvánítását egy lépésben, vagy egy elektronikus dokumentum rögzítését, tárolását és későbbi irattá nyilvánítását.
10.3.7.
Az EIKR-nek lehetővé kell tennie egy elektronikus irat tartalmának másolását új, külön elektronikus dokumentum létrehozása céljából, új irat létrehozása nélkül és az eredeti irat változatlan formában történő megőrzése mellett. Egy felhasználó például másolatot kérhet egy iratról, hogy elküldhesse annak tartalmát olyan címzett részére, aki nem az EIKR felhasználója. Helyzettől függően a másolat irattá nyilvánítható.
Követelmény
Köt.
Teszt
10.3.8.
Az EIKR-nek lehetővé kell tennie, hogy a megfelelő jogosultsággal rendelkező felhasználói szerepkörök dokumentumokat vehessenek ki (check out). Lásd 10.3.11.
Igen
Igen
10.3.9.
Az EIKR-nek engedélyeznie kell a felhasználói szerepkörök számára, hogy visszatehessenek (check in) egy korábban kivett dokumentumot, lehetővé téve a felhasználó számára, hogy szükség esetén a dokumentumot újabb verzióként tehesse vissza (lásd 10.3.20.).
Igen
Igen
10.3.10. Az EIKR-nek lehetőséget kell biztosítania arra, hogy a dokumentumot visszatevő felhasználó opcionálisan szöveges magyarázat formájában rögzíthesse, milyen módosításokat végzett a dokumentumon a rendszeren kívül.
Nem
Igen
10.3.11. Ha egy felhasználó kivett egy dokumentumot, az EIKR-nek meg kell akadályoznia, hogy más felhasználó is kivehesse vagy megváltoztathassa a dokumentumot (a 10.3.13. figyelembe vételével).
Igen
Igen
Hiv.
A kivett dokumentumot csak az azt lekérő felhasználó módosíthatja. A követelmény csak és kizárólag dokumentumokra vonatkozik. Iratokat definíció szerint nem lehet sem kivenni, sem módosítani.
Köt.
Teszt
Igen
Igen
Igen
Igen
10.3.14. A felhasználó nem teheti vissza a dokumentumot, ha megegyező változatának kivételét megakadályozta egy adminisztrátori szerepkör (lásd 10.3.13.).
Igen
Igen
10.3.15. Amennyiben egy lezárni kívánt iratgyűjtemény kivett dokumentumot tartalmaz, az EIKR-nek jelentenie kell a rendhagyó esetet egy adminisztrátori szerepkör felé.
Igen
Igen
10.3.16. A felhasználók számára biztosítani kell, hogy a dokumentumokat az EDKR-ből is iktathassák.
Nem
Igen
10.3.17. A felhasználók számára egyszerű átjárhatóságot kell biztosítani az EIKR és az EDKR között a dokumentumok iktatása szempontjából.
Igen
Nem
Hiv.
Követelmény
10.3.12. Amennyiben a felhasználó olyan dokumentumot próbál kivenni, amelyet más felhasználó már korábban kivett, a rendszernek meg kell akadályoznia a dokumentum újbóli kivételét, értesítve a felhasználót az előző kivétel tényéről, továbbá fel kell fednie a dokumentumot korábban kivevő felhasználó azonosságát, vagy el kell rejtenie a dokumentumot korábban kivevő felhasználó azonosságát egy konfiguráció során beállítható paraméter értékétől függően. 10.3.13. Az EIKR-nek lehetőséget kell biztosítania egy adminisztrátori szerepkör számára, hogy megakadályozhassa egy dokumentum lekérését. Erre azokban a helyzetekben lehet szükség, amikor a dokumentumot kivevő felhasználónak nem áll módjában a dokumentumot visszatenni. Ennek több oka is lehet, például: a felhasználó számítógépe (amelyre a dokumentumot letöltötte) meghibásodott, vagy ellopták; a kivett dokumentum megsérült; a felhasználó elfelejtette visszatenni a dokumentumot, mielőtt elment szabadságra.
Ez a követelmény különösen akkor fontos, ha az EDKR/EIKR megoldást általános irodai környezetben használják.
Köt.
Teszt
Igen
Igen
10.3.19. Az EIKR-nek verziószámmal kell ellátnia az egyes dokumentumokat. A dokumentum verziószámát a rendszernek egyértelműen fel kell tüntetnie a dokumentum kinyerésekor.
Igen
Igen
10.3.20. Az EIKR-nek automatikusan növelnie kell a verziószámát, valahányszor új változatot töltenek fel.
dokumentum
Igen
Igen
10.3.21. Az EIKR-nek lehetővé kell tennie a verziószámozás formátumának a beállítását a rendszer konfigurálásakor. A verziószámozásnál a rendszer legalább az alábbi opciókat kínálja fel:
Nem
Igen
Hiv.
Követelmény
10.3.18. Amennyiben az EIKR egy dokumentumnak több verzióját is tárolja, az EIKR-nek az alábbi lehetőségeket kell felkínálnia a dokumentumok irattá nyilvánításakor (ezek közül az egyiket kötelező a rendszer konfigurációja során alapértelmezésként beállítani): a legfrissebb verzió iktatása; a felhasználó által kiválasztott verzió iktatása; az összes verzió iktatása egyetlen iratként; az összes verzió iktatása önálló, de kapcsolódó iratokként.
egyszerű, folytonos verziószámozás, azaz 1, 2, 3 stb. fő és alverziószám használata, azaz x.y alakú verziószámozás, ahol x a fő verziószám, y pedig az alverziószám; a felhasználó döntheti el, hogy a fő vagy az alverziószámot szeretné növelni; a fő verziószám növelésekor az alverziószám automatikusan 0-ra vált. Természetesen más számozási formák is elképzelhetők.
Köt.
Teszt
Igen
Igen
10.3.23. Az EIKR-nek lehetővé kell tennie a felhasználók számára, hogy az általuk készített dokumentumok esetében felülírhassák az eltárolandó verziók számát (melyet a 10.3.21. rögzít).
Nem
Igen
10.3.24. Az EIKR-nek lehetővé kell tennie a felhasználó számára, hogy metaadatot fűzhessen az irathoz annak iktatásakor.
Igen
Igen
10.3.26. Az EIKR-nek biztosítania kell, hogy a bevitt metaadatok megfelelnek a MoReq2 metaadatmodellnek.
Igen
Igen
10.3.27. Az EIKR-nek lehetővé kell tennie, hogy egy jogosult felhasználó leképezhesse az EDKR metaadat-elemeit a megfelelő EIKR metaadat mezőkre.
Nem
Nem
10.3.28. Az EIKR-nek figyelmeztetnie kell a felhasználót, ha ellentmondást észlel az EIKR-ben és a dokumentumkészítő rendszer által használt metaadatok között.
Igen
Igen
Hiv.
Követelmény
10.3.22. Az EIKR-nek lehetővé kell tennie, hogy a dokumentumverziók tárolásának módját egy adminisztrátori szerepkör határozhassa meg a rendszer konfigurálásakor, vagy egy későbbi időpontban a besorolási séma osztályainak vagy dossziéinak szintjén. Az adminisztrátori szerepkör legalább az alábbi, osztályonként és dossziénként változó beállítások közül választhasson az alapértelmezés kiválasztásakor: minden dokumentum minden verzióját eltárolják az osztályban vagy dossziéban; a dokumentumoknak csak a legújabb (amennyiben egy adminisztrátori szerepkör képes fő és alverziószámokat meghatározni) verzióját tárolják el az osztályban vagy dossziéban; a dokumentumoknak adott számú verzióját tárolják el az osztályban vagy dossziéban, a számot egy adminisztrátori szerepkör határozza meg. Ezáltal biztosítható a dokumentumok verziókövetése olyan környezetekben, ahol a dokumentumok fejlődésének előzményeit fontos számon tartani. Amennyiben ez nem fontos, a tárolt verziók száma – ezáltal pedig a lefoglalt tárhely – lecsökkenthető.
10.3.25. Például a dokumentum létrehozásának időpontját és szerzőjét, illetve amennyiben a dokumentum szabványos mezőkkel rendelkezik, azok értékét (pl. tárgy).
Ez abban az esetben fordulhat elő, ha az EIKR nincs befolyással a dokumentum metaadat-elemeire.
Köt.
Teszt
Nem
Nem
Igen
Igen
Nem
Igen
Nem
Igen
10.3.33. Amennyiben az EIKR támogatja a személyes munkaterületeket, lehetővé kell tennie egy adminisztrátori szerepkör számára, hogy korlátozhassa annak méretét felhasználónként.
Igen
Igen
10.3.34. Amennyiben az EIKR támogatja a személyes munkaterületeket, a munkaterülethez csak a tulajdonosa férhet hozzá.
Igen
Igen
Hiv.
Követelmény
10.3.29. Az EIKR-t képessé kell tenni a szervezetnél bevezetésre kerülő újabb EDKR rendszerek integrálására. A MoReq2 nem írja elő az integrálhatóság szervezeteknek ezt részletesen ki kell dolgozniuk.
részleteit,
a
10.3.30. Az EIKR-nek támogatnia kell a verziókövetést, azaz egyazon dokumentum különböző változatainak az egységes kezelését. A verziókövetés lehetővé teszi a dokumentumok folyamatos javítását és segíti a kollaborációt. 10.3.31. Az EIKR legyen képes arra, hogy a felhasználók betekintési lehetőségeit az alábbiak egyikére korlátozza: egy dokumentumnak csak a legutóbbi verziója; egy dokumentum csak a kiválasztott verziói; egy dokumentum összes verziója; az irattá nyilvánított dokumentumok. A felhasználó korlátozásának beállítását egy adminisztrátori szerepkör végzi a konfiguráció során vagy egy későbbi időpontban. 10.3.32. Az EIKR-nek lehetővé kell tennie a felhasználók számára, hogy saját „munkaterületet” használhassanak dokumentumaik kezelésére. A felhasználók itt tárolhatnák azokat a személyes dokumentumokat, amelyeket nem szeretnének irattá nyilvánítani, például egy leendő irat nagyon korai, vázlatos verzióját, de egyéb dokumentumok is szóba jöhetnek. A személyes munkaterület opcionális, azaz léteznie kell olyan beállításnak, amellyel használata kikapcsolható.
10.4.
Munkafolyamatok
A munkafolyamat-szabványok kidolgozásáért felelős nemzetközi szervezet (WfMC – Workflow Management Coalition) meghatározása értelmében a munkafolyamat nem más, mint „egy üzleti folyamat automatizálása részben vagy egészben, melynek során a résztvevők dokumentumokat, információt vagy feladatokat küldenek egymásnak valamilyen tevékenység elvégzése céljából, előre meghatározott eljárás szerint”. A definíció értelmében vett „résztvevőnek” tekinthetők a felhasználók, a munkacsoportok és a szoftveralkalmazások.
Ebben a szakaszban a követelmények az alapvető továbbítási funkciókra (a 6.1.35.-ben leírtaknak megfelelően) és az egyéb, kifinomultabb munkafolyamat szolgáltatásokra vonatkoznak, beleértve a nagy terheléssel járó kivételek kezelését, valamint a rendszer- és az egyéni teljesítmény jelentését. Utóbbi megvalósítására külső munkafolyamat-kezelő termék is alkalmas. A munkafolyamatok megvalósításához használt technológiák elektronikus objektumokat továbbítanak a résztvevők között a program automatizált felügyelete alatt. Egy elektronikus iratkezelő rendszerben a munkafolyamatok az elektronikus iratok és dokumentumok mozgását írják le a felhasználók, részlegek és alkalmazásprogramok között. A munkafolyamatok felhasználhatók: a kritikus folyamatok kezelésére, mint a dossziék és iratok iktatása vagy selejtezése; az iratok ellenőrzésére és jóváhagyására az iktatás előtt; az iratok és dossziék szabályozott formában történő továbbítására a felhasználók között adott tevékenység végrehajtása érdekében, mint egy dokumentum ellenőrzése vagy az új verzió elfogadása; a felhasználók értesítésére az iratok hozzáférhetőségéről; az iratok elosztására; az iratok kezelésére ügyviteli folyamatokban. Követelmény
Köt.
Teszt
10.4.1.
Az EIKR-nek támogatnia kell az olyan munkafolyamatokat, amelyek egyértelműen elkülöníthető lépésekből állnak; minden egyes lépés egy irat, dokumentum vagy dosszié továbbítását jelenti (például) egyik résztvevőtől a másikig valamilyen tevékenység végrehajtása vagy döntéshozatal céljából.
Igen
Igen
10.4.2.
Az EIKR „résztvevőként” felhasználókat és munkacsoportokat is tudjon kezelni.
Igen
Igen
10.4.3.
Munkacsoport résztvevő esetén az EIKR munkafolyamat szolgáltatása legyen képes arra, hogy a csoporthoz bejövő elemeket egyenletes elossza a tagok között (körkörös kiosztással vagy az éppen „üresjáratú” felhasználóknak) az egyenletes terhelés érdekében.
Nem
Igen
10.4.4.
Az EIKR-nek lehetővé kell tennie az adminisztrátori szerepkörök számára előreprogramozott munkafolyamatok meghatározását.
Igen
Igen
10.4.5.
Az EIKR-nek lehetővé kell tennie az adminisztrátori szerepkörök számára, hogy elmenthessék a munkafolyamatokat későbbi felhasználásra.
Igen
Igen
Hiv.
Ebből következik, hogy minden egyes elmentett munkafolyamatot egyedi azonosítóval kell ellátni.
Követelmény
Köt.
Teszt
10.4.6.
Az EIKR-nek lehetővé kell tennie a munkafolyamatot elmentő adminisztrátori szerepkör számára, hogy egyedi szöveges címmel láthassa el a munkafolyamatot.
Nem
Igen
10.4.7.
Az EIKR-nek adminisztrátori szerepkörökre vagy jogosult felhasználókra kell korlátoznia az előreprogramozott munkafolyamatok módosítását.
Igen
Igen
10.4.8.
Valahányszor egy adminisztrátori szerepkör megváltoztat és ment egy munkafolyamatot, az EIKR-nek el kell tárolnia a munkamenet módosítás előtti változatát iratként, új verziószámmal kell ellátnia és fel kell jegyeznie metaadatként az időintervallumot, amelyben érvényben volt.
Nem
Igen
10.4.9.
Az EIKR nem korlátozhatja a definiált és eltárolt munkafolyamatok számát.
Igen
Rész ben
10.4.10. Az EIKR-nek rögzítenie kell az előreprogramozott munkafolyamatok létrehozását és minden egyes módosítását az eseménynaplóban.
Igen
Igen
10.4.11. Az EIKR-nek lehetővé kell tennie a felhasználói szerepkörök számára, hogy (ad hoc) munkafolyamatokat definiálhassanak, és azokat azonnal felhasználhassák és elmenthessék.
Nem
Igen
10.4.12. Az EIKR-nek grafikus felületet kell biztosítania a munkafolyamatok meghatározásához, karbantartásához és szerkesztéséhez.
Nem
Igen
10.4.13. Az EIKR-nek támogatnia kell a selejtezési, felülbírási és exportálási/áthelyezési folyamatokat az alábbiak nyomon követésével és jelentésével:
Nem
Igen
10.4.14. Az EIKR-nek értesítenie kell egy adminisztrátori szerepkört, ha egy munkafolyamatban az egyik irat vagy dosszié felülvizsgálatra vagy selejtezésre vár.
Igen
Igen
10.4.15. Az EIKR-nek biztosítania kell, hogy a munkafolyamatokban részt vevő iratok és dossziék megőrzik kapcsolataikat.
Igen
Rész ben
10.4.16. Az EIKR-nek a dossziékat és iratokat sorokban kell kezelnie, melyeket az adminisztrátori szerepkörök megvizsgálhatnak és irányíthatnak.
Nem
Igen
10.4.17. Az EIKR-nek lehetővé kell tennie a felhasználói szerepkörök számára, hogy az adminisztrátori szerepkörök által definiált munkafolyamatokat használhassák.
Igen
Igen
Hiv.
a felülbírálás előrehaladása/státusza (pl. várakozás, folyamatban), a felülvizsgáló adatai, a felülvizsgálat időpontja; a felülvizsgálati döntés értelmében selejtezésre váró iratok; az áthelyezési folyamat előrehaladásának állapota.
Köt.
Teszt
10.4.18. Az EIKR-nek lehetővé kell tennie a felhasználói szerepkörök számára, hogy megfigyelhessék azon munkafolyamatok menetét, melyet ők indítottak, illetve amelynek résztvevői.
Igen
Igen
10.4.19. Az EIKR-nek lehetővé kell tennie egy dokumentum automatikus deklarációját egyetlen munkafolyamat-lépésben.
Nem
Igen
10.4.20. Az EIKR nem korlátozhatja az egyes munkafolyamatok lépéseinek számát.
Nem
Rész ben
10.4.21. Az EIKR-nek prioritás szerint sorokba kell tudnia rendezni az elemeket.
Nem
Igen
10.4.22. Az EIKR-nek lehetőséget „randevújára”.
Nem
Igen
Igen
Igen
Hiv.
Követelmény
kell
biztosítania
a
munkafolyamatok
A randevú azt jelenti, hogy a munkafolyamat bevárja a kapcsolódó elektronikus dokumentumot vagy iratot; ezalatt a munkafolyamat szünetel. A várt elem érkezése után a folyamat automatikusan folytatódik. 10.4.23. Az EIKR-nek támogatnia kell különböző munkafolyamat-szerepkörök létrehozását és felhasználókhoz rendelését. Példa munkafolyamat-szerepkörre: munkafolyamat-adminisztrátori szerepkör (joga van átszervezni a feladatokat és a tevékenységeket a felhasználók vagy munkacsoportok között); felügyelő szerepkör (joga van kivételkezelésre rendelni egy munkafolyamatot); hagyományos munkafolyamat-felhasználók vagy munkacsoportok. Ezek a munkafolyamat-szerepkörök eltérnek a 13.4. szakaszban ismertetett EIKR-szerepköröktől.
Köt.
Teszt
10.4.24. Az EIKR-nek lehetővé kell tennie egy adminisztrátori szerepkör számára, hogy a rendszer konfigurálásakor rögzíthesse egy munkafolyamat maximális lépésszámát.
Nem
Igen
10.4.25. Az EIKR-nek lehetővé kell tennie a munkafolyamatot létrehozó adminisztrátori szerepkör számára, hogy határidőt fűzhessen az egyes lépésekhez; a rendszernek jelentenie kell a késedelmes feladatokat egy kijelölt felhasználó vagy adminisztrátori szerepkör felé.
Nem
Igen
10.4.26. Az EIKR-nek lehetővé kell tennie a munkafolyamatot létrehozó adminisztrátori szerepkör számára, hogy előre meghatározott listából választhassa ki a résztvevők feladatait a munkafolyamatban.
Nem
Igen
10.4.27. Az EIKR-nek lehetővé kell tennie a munkafolyamatot létrehozó adminisztrátori szerepkör számára, hogy a résztvevőket az alábbi szempontok mentén választhassa ki:
Nem
Igen
Nem
Igen
Hiv.
Követelmény
név; szerepkör; szervezeti egység. 10.4.28. Az adminisztrátori szerepköröknek képesnek kell lenniük engedélyt adni az egyes felhasználók részére, hogy azok átruházhassák feladataikat/tevékenységeiket a munkafolyamat más felhasználóira vagy csoportjaira. Erre olyan esetekben lehet szükség, amikor például az eredetileg kijelölt felhasználó tovább szeretné küldeni a dossziét vagy iratot annak tartalma miatt, vagy épp szabadságon van.
Köt.
Teszt
Nem
Igen
Nem
Igen
10.4.31. Az EIKR-nek lehetővé kell tennie a felhasználói szerepkörök számára a munkafolyamat átmeneti felfüggesztését és későbbi folytatását másik tevékenység elvégzése céljából (a felhasználó eközben kijelentkezhet a rendszerből).
Nem
Igen
10.4.32. Az EIKR-nek értesítenie kell a felhasználó résztvevőt, ha irat vagy dosszié érkezett a postaládájába.
Igen
Igen
10.4.33. Az EIKR-nek támogatnia kell a dossziék és iratok nyomkövetését egy „előrehozás” (más néven „határidőnapló”) eszköz segítségével, amely lehetővé teszi a felhasználó számára, hogy emlékeztetőt kérjen egy dosszié vagy irat hozzáféréséhez.
Nem
Igen
10.4.34. Az EIKR-nek olyan mechanizmust kell biztosítania, amellyel a felhasználók felhívhatják egymás figyelmét bizonyos iratokra.
Igen
Igen
Nem
Igen
Hiv.
Követelmény
10.4.29. Az EIKR-nek lehetővé kell tennie a résztvevők számára, hogy megtekinthessék a hozzájuk rendelt feladatokat, illetve kiválaszthassanak egyet, amelyiket el szeretnének végezni, vagy csak időrendileg legyen lehetőségük végrehajtani azokat (tehát az korábban hozzájuk rendelt feladatokat először). Ezen beállítás értéke a munkafolyamat tervezésekor dől el. 10.4.30. Az EIKR-nek lehetővé kell tennie az elágazások használatát a munkafolyamatoknál, amikor a folytatás iránya egy felhasználói bemenet vagy rendszeradat értékétől függ. Más szóval, az irat vagy dosszié útját a munkafolyamatban egy résztvevő által meghatározott feltétel dönti el. Például, az értékesítési tanácsadó ajánlásától függően az irat vagy a hitelellenőrző résztvevőhöz, vagy a megrendelés-jóváhagyó résztvevőhöz kerül; hasonlóképpen a folyamat továbbhaladásának iránya valamilyen rendszerértéktől is függhet.
A MoReq2 nem írja elő, hogy ez a postaláda az e-mail fiókhoz tartozik, vagy különbözik attól.
Ehhez használható akár hagyományos levelezőrendszer, akár külön üzenetküldő rendszer. 10.4.35. Az EIKR-nek automatikusan el kell tudnia indítani egy meghatározott munkafolyamatot, amikor adott irattípushoz sorolható irat érkezik. „Hitelkérelem űrlap” érkezésekor például automatikusan elindulhat a hitelkérelmi munkafolyamat.
Köt.
Teszt
10.4.36. Az EIKR-nek lehetővé kell tennie a munkafolyamatokat automatikusan indító elektronikus dokumentumok vagy iratok fogadását külön erre a célra létrehozott mappákban (az elindítandó munkafolyamatot a dokumentum típusa vagy egy metaadat értéke dönti el).
Nem
Igen
10.4.37. Az EIKR-nek átfogó jelentéskészítő eszközöket kell biztosítania a jogosult felhasználók és adminisztrátori szerepkörök számára a mennyiségek, teljesítmény és kivételek megfigyelése céljából.
Igen
Igen
10.4.38. Az EIKR-nek támogatnia kell a munkafolyamatok iktatását iratként.
Nem
Igen
10.4.39. Az iratok és dossziék feldolgozásakor az EIKR-nek lehetővé kell tennie a felhasználói szerepkörök számára, hogy kiválaszthassák a használandó munkafolyamatok azonosítóját és verzióját.
Igen
Igen
10.4.40. Az EIKR-nek biztosítania kell, hogy a hozzáférési szabályozások minden időben érvényesülnek.
Igen
Rész ben
10.4.41. Az EIKR-nek kompatibilisnek kell lennie a Workflow Management Coalition (WfMC) hivatkozási modelljével.
Nem
Igen
10.4.42. Az EIKR-nek támogatnia kell a szabványos munkafolyamatok vagy azok tetszőleges részeinek exportálását szabványos XML sémába.
Nem
Nem
10.4.43. A munkafolyamatokról készült eseménynaplót integrálni kell az EIKR eseménynaplójával.
Nem
Igen
10.4.44. A munkafolyamatokról készült eseménynapló megváltoztathatatlan.
Igen
Igen
Hiv.
Követelmény
Más szóval, ne lehessen olyan munkafolyamatot összeállítani, amelyben a felhasználók olyan jogosultságot kaphatnának, amilyet egyébként nem.
10.5.
Ügyviteli környezetek
Ez a szakasz a MoReq2-vel kompatibilis iratkezelő rendszerek „ügyiratokra” vonatkozó követelményeit írja le. Az ügyiratok meghatározását és magyarázatát lásd a Szószedetben. A MoReq2 meghatározása szerint az „ügyirat” olyan dosszié, amely egy vagy több tranzakcióhoz részben vagy egészben kapcsolódó iratokat foglal össze strukturált módon. A „strukturált” azt jelenti, hogy a tranzakciók dokumentált (vagy dokumentálható) szabályokat követnek, konzisztens folyamatot alkotnak (a felhasználók nem találhatnak ki tetszésük szerint teljesen új folyamatrészeket), és hasonló tranzakciók példányai esetén rendszeresen megismétlődnek. Az ügyiratok strukturált (pl. online formanyomtatványok) és strukturálatlan (pl. e-mailek, beszkennelt iratok) tartalmú iratokat tartalmazhatnak tetszőleges kombinációban. Az ügyiratok megkülönböztető jellegét az adja, hogy legalább részben strukturált folyamatok eredményeként keletkeznek. Az ügyiratokra jellemző továbbá, hogy gyakran nagyszámban fordulnak elő;
részben vagy teljesen strukturáltak; jól ismert és előre meghatározott folyamat alapján használják és kezelik azokat; megőrzésük kötelező egy előre meghatározott periódus idejére, törvényi előírás vagy egyéb szabályozás miatt; tartalmuk és/vagy szerkezetük hasonló; ismert a megnyitásuk és lezárásuk időpontja; szakavatott személyek, végfelhasználók vagy adatfeldolgozó rendszerek a vezetőség jóváhagyása nélkül megnyithatják és lezárhatják. Mivel az ügyiratok rendszerint strukturáltak, sablon alapján kisebb egységekre, ún. ügyiratdarabokra bonthatók. (Az ügyiratdaraboknak az aldossziék felelnek meg.) Az ügyiratok és az ügyiratdarabok kötetekre bonthatók. Az ezzel kapcsolatos követelményeket illetően lásd a 3.3. szakaszt, ahol a dossziékra vonatkozó leírások az ügyiratokra is érvényesek. Ügyviteli környezetekben gyakran használnak további üzleti alkalmazásokat (pl. licenszkérelmeket feldolgozó rendszert, vagy ajánlatkérést figyelő rendszert). Ezen felül a munkafolyamatok használata is elterjedt (lásd 10.4. szakasz). Hiv. 10.5.1.
Követelmény
Köt.
Teszt
Az EIKR-nek lehetővé kell tennie egy adminisztrátori szerepkör számára, hogy legalább egy „ügyintéző” szerepkört létrehozhasson a rendszerben. Az ügyintéző szerepkör sajátossága, hogy eltérő hozzáférési jogosultságok kapcsolódnak hozzá az ügyiratokat tartalmazó osztályok, ill. a hagyományos dossziékat tároló osztályok kezelése esetén.
Igen
Igen
Sok esetben ez annyit tesz, hogy az ügyintéző bármikor képes ügyiratot létrehozni, megnyitni és lezárni, de nincs joga hagyományos dossziékat létrehozni, megnyitni vagy lezárni. Utóbbi tevékenységekre csak adminisztrátori szerepköröknek adható jogosultság.
Köt.
Teszt
10.5.2.
Az EIKR-nek támogatnia kell egy opcionális elnevezési Nem mechanizmust az ügyiratok névadására, amely egy névből (pl. személynév) és/vagy dátumból áll (pl. születési dátum), vagy egyedi ügyirat-azonosítót jelöl ki, melynek kiválasztása és automatikus validálása külső listákból történik. Az elnevezési mechanizmus beállításáért egy adminisztrátori szerepkör felel.
Igen
10.5.3.
Az ügyiratok elnevezéséhez (lásd 10.5.2.) csak kötelezően kitöltendő metaadatok használhatók, ennek hiányában a rendszernek gondoskodnia kell a metaadatok alapértelmezett értékéről. Amennyiben a címben használt metaadatok (pl. nevek, dátumok) megváltoznak, az EIKR-nek nem kell frissítenie az ügyirat címét.
Igen
Igen
10.5.4.
Az ügyiratok automatikus névadásához használt szabályok (lásd Nem 10.5.2.) beállítástól függően eltérhetnek az egyes osztályokban.
Igen
Hiv.
Követelmény
Az imént felsorolt három követelmény az ügyiratokra vonatkozik. A validálás során használt listák vagy az EIKR hatáskörébe tartoznak, vagy külső listák. Valahányszor az ügyirat címe olyan metaadatok értékéből áll össze, mint egy személy neve, születési dátuma stb., fennáll annak a lehetősége, hogy az eredeti metaadatok értéke megváltozik (pl. nevet változtat az illető, vagy elírták a születési dátumát). Ilyenkor a rendszernek nem kell automatikusan frissítenie a címet, hogy az a megváltozott metaadatokat tükrözze, ugyanis előfordulhat, hogy az ügyirat címét a rendszerben már hivatkozzák (pl. levelezésben megemlítették, exportálták stb.). Azon túl, hogy a MoReq2 nem javasolja a cím automatikus frissítését, nem részletezi bővebben a metaadatok módosításának következményeit. A címben felhasznált metaadatok módosításának az alábbi lehetséges következményei lehetnek (a felsorolás nem teljes): a rendszer figyelmen kívül hagyja a módosításokat, a cím nem változik; a rendszer értesít egy adminisztrátori szerepkört a metaadatok változásáról, a szerepkör belátása szerint frissíti az ügyirat címét; a rendszer figyelmezteti a felhasználót a metaadatok értékének megváltoztatásakor, hogy azok szerepelnek az ügyirat címében, és megerősítést kér a módosítások elvégzéséhez; a rendszer megakadályozza, hogy a felhasználó megváltoztathassa a metaadatokat, és javasolja, hogy a felhasználó továbbítsa kérelmét egy adminisztrátori szerepkör felé, akinek jogában áll megváltoztatni a metaadatokat.
Követelmény
Köt.
Teszt
10.5.5.
Az EIKR-nek lehetővé kell tennie az ügyintéző szerepkörrel rendelkező felhasználók számára, hogy ügyiratokat hozhassanak létre.
Igen
Igen
10.5.6.
Az EIKR-nek lehetővé kell tennie a felhasználói szerepkörök számára, hogy egy ügyirathoz annak ügyirat-specifikus azonosítója alapján férhessenek hozzá és nyithassák meg.
Igen
Igen
Igen
Rész ben
Hiv.
Az azonosítót (pl. cím, hivatkozási szám) az esetek többségében egy külső rendszer szolgáltatja. A rendszernek lehetővé kell tennie, hogy a felhasználó a felületen keresztül validálhassa a kézzel beírt azonosítót. Ez az azonosító nem egyezik meg a rendszerazonosítóval vagy a besorolási kóddal. 10.5.7.
Az EIKR-nek alkalmazás programozói interfészt (API, Application Programming Interface) vagy hasonló lehetőséget kell biztosítania, melyen keresztül a külső üzleti alkalmazások a rendszernek legalább az alábbi funkcióit elérhetik: ügyiratok létrehozása, megnyitása és lezárása az EIKR-ben; az EIKR-ben létrehozott ügyirat ellátása címmel; az újonnan létrehozott ügyirat besorolási kódjának lekérdezése; irat iktatása az EIKR-ben; megőrzési és selejtezési ütemterv alkalmazása egy lezárt ügyiratra; hibakezelés arra az esetre, ha a rendszer által végrehajtott tevékenységet az üzleti alkalmazás nem képes értelmezni. Az üzleti alkalmazást tehát úgy kell elképzelni, mintha hagyományos felhasználó lenne – az EIKR ne tegyen különbséget a kettő között. A MoReq2 nem írja elő az említett hibakezelés módját, az esetleges kimeneteket azonban a következő két követelmény tartalmazza.
Hiv. 10.5.8.
Követelmény
Köt.
Teszt
Amennyiben az EIKR egyértelműen hibás kérelmet kap egy külső üzleti alkalmazástól,
Igen
Igen
Amennyiben az EIKR egyértelműen hibás kérelmet kap egy külső Nem üzleti alkalmazástól, értesítenie kell egy megfelelő jogosultsággal rendelkező felhasználót a hiba kijavítása érdekében.
Igen
nem teljesítheti a kérést, és nem idézhet elő szoftverhibát sem az EIKR-ben, sem a külső alkalmazásban. 10.5.9.
10.5.10. Amennyiben az EIKR elérhetővé teszi külső üzleti alkalmazás számára a 10.5.7. követelményben leírt funkciókat, lehetővé kell tennie egy adminisztrátori szerepkör számára a másik alkalmazás tevékenységeinek korlátozását egy vagy több előre meghatározott osztályra az EIKR besorolási sémájában.
Igen
Igen
10.5.11. Amennyiben az EIKR elérhetővé teszi külső üzleti alkalmazás Nem számára a 10.5.7. követelményben leírt funkciókat, a felhasználó tudjon könnyen váltani a kapcsolódó ügyiratokra mindkét rendszerben.
Nem
Más szóval, a külső alkalmazás nem férhet hozzá olyan iratokhoz, dossziékhoz és osztályokhoz, amelyek az ügyiratokat tartalmazó osztályokon kívül esnek.
Más szóval, ha a felhasználó a külső üzleti alkalmazás szolgáltatásával kereste meg és azonosította a kívánt ügyet vagy ügyiratot (pl. az alkalmazás levelezési cím alapján kereső szolgáltatásával), az ügyiratot nem kell ismét kikeresnie az EIKR-ben az azonosító begépelésével. Hasonlóképpen, ha a felhasználó az EIKR-ben találta meg az ügyiratot (pl. a besorolási sémát böngészve), könnyen kell váltania a külső alkalmazásban az ügyirathoz kapcsolódó adatokra. 10.5.12. Amennyiben az EIKR lehetővé teszi külső üzleti alkalmazás számára új ügyirat létrehozását, a rendszernek képesnek kell lennie fogadni az üzleti alkalmazástól a szükséges metaadatokat.
Igen
Igen
10.5.13. Az EIKR-nek lehetővé kell tennie az ügyiratok esetében független, csak az ügyiratokra vonatkozó metaadat-elemek felvételét.
Igen
Igen
Ilyen lehet például a „státusz”, „előrehaladás” stb.
Köt.
Teszt
Igen
Rész ben
10.5.15. Ha az EIKR strukturált tartalmú iratot fogad másik üzleti Nem alkalmazástól, képesnek kell lennie kinyernie az iratokból azok metaadatait.
Igen
10.5.16. Ha az EIKR strukturált tartalmú iratot fogad másik üzleti Nem alkalmazástól, fel kell tudnia használni az iratokból kinyert metaadatokat az iratok besorolásához a megfelelő ügyiratba.
Igen
Hiv.
Követelmény
10.5.14. Az EIKR-nek lehetővé kell tennie a felhasználói szerepkörök számára, hogy az ügyiratokba a besorolási kód helyett az ügyirat azonosítója alapján iktathassanak iratokat, onnan előkereshessenek adatokat és egyéb tevékenységeket hajthassanak végre. A legtöbb ügyirat rendelkezik egyedi ügyazonosítóval, például számlaszám, panaszszám stb. A rendszernek lehetővé kell tennie a felhasználók számára, hogy pusztán erre az azonosítóra hagyatkozva dolgozhassanak az adott ügyirattal anélkül, hogy a besorolási kódot ismerniük kellene. (Természetesen a besorolási kód továbbra is használható.)
Ha például az EIKR egy kárigény-bejelentést kap a kárigénybejelentéseket kezelő rendszertől, ki kell tudnia nyerni a kárigényazonosítót és a nyomtatvány típusát, majd az azonosító alapján a megfelelő ügyiratban, a nyomtatványtípus alapján pedig a megfelelő ügyiratdarabban (aldossziéban) kell elhelyeznie azt. 10.5.17. Az EIKR-nek biztosítania kell az egyes osztályokon, dossziékon vagy iratokon végrehajtott tevékenységek (függetlenül attól, hogy egy arra jogosult felhasználó vagy egy külső üzleti alkalmazás kezdeményezte) rögzítését az eseménynaplóban.
Igen
Igen
10.5.18. Az EIKR-nek jelentéseket kell tudnia készíteni az egyes ügyiratokon végrehajtott tevékenységekről, függetlenül attól, hogy azokat egy jogosult felhasználó vagy külső üzleti alkalmazás kezdeményezte.
Igen
Igen
10.5.19. Az EIKR-nek jelentéseket kell tudnia készíteni az adminisztrátori szerepkörök számára. A jelentéseknek legalább az alábbiakat kell tartalmaznia:
Igen
Igen
a külső üzleti alkalmazások által adott időintervallum alatt automatikusan ügyiratokba sorolt iratok száma; adott időintervallum alatt manuálisan ügyiratokba sorolt iratok száma; a külső alkalmazások által adott időintervallum automatikusan megnyitott és lezárt ügyiratok száma;
alatt
adott időintervallum alatt manuálisan megnyitott és lezárt ügyiratok száma.
10.6.
Tartalomkezelő rendszerek integrálása
Ebben a szakaszban a tartalomkezelő rendszerek (TKR, angolul CMS – Content Management System) integrálásával szemben támasztott követelmények olvashatók. Napjaink tartalomkezelő rendszerei a dokumentumkezelő feladatok (lásd 10.3. szakasz) többségét ellátják. Ez a szakasz csak az iratkezelő rendszerek javasolt tartalomkezelő funkcióit foglalja össze, az EDKR-ektől és TKR-ektől elvárható szolgáltatásokra nem tér ki. Az alábbiakban felsorolt követelmények nem fedik le teljesen a tartalomkezelő rendszerek jellemző funkcióit. A tartalomkezelő rendszerek a dokumentumkezelők feladatkörét tartalmazzák és bővítik ki a különféle információkra (tartalomra) vonatkozó szolgáltatásokkal a dokumentumok kezelésén túl. A TKR-ek rendszerint más szempontból vizsgálják az információt, mint az EIKR-ek. A tartalomkezelő rendszerek általános jellemzői: információ közzététele különféle csatornákon, gyakran weboldalakon és portálokon, különféle megjelenítési formákban; több forrásból származó információ kezelése; információ formázása és átalakítása eltérő megjelenítési formá(k)ba; a dokumentumok különböző verzióinak, megjelenítési formáinak és fordításainak összekapcsolása; a dokumentum összetevőinek kezelése. A Specifikáció írásának idején a TKR kifejezés leggyakoribb használata és az EIKR-ekkel való integrálásának fő oka az információ közzététele a weben. Ez a szakasz a webes közzétételen kívül további lényeges tartalomkezelő feladatokat is leír. A tartalomkezelő funkciókat szolgáltathatja egy önálló, az EIKR-rel nem azonos TKR, de egy integrált csomag is elláthatja a tartalom- és iratkezelő feladatokat. Az egyszerűség kedvéért az alábbiakban úgy tekintjük, hogy a TKR és az EIKR különálló rendszerek, ez azonban nem követelmény. Az EIKR és a TKR közötti kapcsolatot a 10.1. ábra szemléleti leegyszerűsített formában.
10.1. ábra Az ábráról az alábbiakat lehet leolvasni: Az EIKR iratmásolatokat adhat át a TKR-nek feldolgozás céljából (feldolgozáson ebben a környezetben a szerkesztést, a megjelenítési forma átalakítását és a közzétételt értjük).
A TKR átküldhet iratokat az EIKR-be iktatásra az információ feldolgozása közben vagy annak közzétételét követően. Iktathatók (többek között) a weboldalak, a weblapok és a meglévő iratok más megjelenítési formái. A TKR más forrásból is fogadhat információt, így az EIKR-hez visszaküldött iratok kiegészülhetnek az EIKR-en kívülről származó információkkal. Megjegyzés. A „fogadhat” kifejezés több lehetőséget takar: az alkalmazások iratmásolatokat váltanak egymással; az iratokat központi tárolóhelyen tárolják, amelyet a TKR és az EIKR egyaránt lát, így az alkalmazások csak az iratokat egyértelműen azonosító üzeneteket váltanak; az iratokat központi tárolóhelyen tárolják, amelyet a TKR és az EIKR egyaránt lát, de a két rendszer információátvitel nélkül használja az iratokat. A továbbiakban az iratok/iratpéldányok/iratmásolatok átvitelén az előbbi három (és a hozzájuk hasonló) lehetőség bármelyikét értjük. A tartalomkezelő technológiák rohamosan fejlődnek, így a tartalomkezelés integrálására törekvő szervezeteknek fel kell állítaniuk saját követelményeiket, mivel pusztán ennek a szakasznak a megvalósítása valószínűleg nem elegendő. Az alábbiakban felsorolt követelmények jó kiindulópontot jelentenek, ugyanakkor további elemzés tárgyai.
Hiv. 10.6.1.
Követelmény
Köt.
Teszt
Az EIKR-nek képesnek kell lennie iratokat és azok metaadatait fogadni a TKR-ből, és
Igen
Igen
Igen
Igen
Igen
Igen
automatikusan iktatnia kell az iratokat a megfelelő dosszié(k)ba a metaadatok alapján, vagy lehetővé kell tennie egy felhasználó számára, hogy kijelölje a dosszié(ka)t az iktatáshoz. 10.6.2.
Az EIKR-nek képesnek kell lennie irattá nyilvánítani TKR-specifikus állományokat és fájltípusokat, beleértve: a tartalomkezelő naplóállományokat; stíluslapokat.
10.6.3.
Az EIKR-nek el kell tudnia helyezni a TKR által szolgáltatott metaadatokat a MoReq2 által előírt iratkezelésnél használatos metaadatok mellett. A TKR-ek a tartalomkezeléshez használatát írhatják elő, például:
szükséges
metaadat-elemek
IP-cím; státusz; nyelv; közzététel időpontja; érvénybelépés időpontja; változtatás oka. Az EIKR-nek el kell tudnia tárolni ezeket az elemeket, jóllehet az iratkezeléshez nem szükségesek. Az EIKR-nek nem kell tárolnia a TKR által használt és előállított összes metaadat-elemet, csak azokat, amelyeket a rendszer konfigurálásakor kiválasztanak. A kiválasztásnál a fő szempont az üzleti igények figyelembe vétele. Megjegyzés. Ez elég általános követelmény, így teret enged a TKRnek, hogy különféle feladatok elvégzése után a keletkező metaadatokat elküldhesse az EIKR-nek, amely eltárolja azokat.
Követelmény
Köt.
Teszt
10.6.4.
Ha a TKR-től az EIKR-be iktatásra küldött irat kapcsolódik egy EIKRben tárolt irathoz (pl. annak más megjelenítési formája, vagy fordítása), az EIKR nem törölheti vagy módosíthatja az eredeti iratot, hanem el kell tárolnia az újat is.
Igen
Rész ben
10.6.5.
Létező irathoz kapcsolódó (lásd 10.6.4.) irat fogadásakor a TKR-ből az EIKR-nek automatikusan össze kell kapcsolnia az új és a létező iratot (lásd 3.4.23).
Igen
Igen
10.6.6.
Létező irathoz kapcsolódó (lásd 10.6.4.) irat fogadásakor és iktatásakor Nem az EIKR-nek törekednie kell az új és a létező irat metaadatainak minél nagyobb fokú egyezésére kivéve azokat a metaadatokat, amelyekből visszakövetkeztethetők a TKR által végrehajtott műveletek.
Nem
10.6.7.
Amikor a TKR weboldal formájú iratot küld az EIKR-nek, a rendszernek Nem képesnek kell lennie a weboldalt vagy a weboldalak összességét egyetlen iratként iktatni.
Igen
Hiv.
Ez csak akkor lehetséges, ha a TKR az irattal együtt elküldi az eredeti irat azonosítóját metaadatként. Ha a TKR nem szolgáltatja ezt az azonosítót, az EIKR átmehet a MoReq2-megfelelőségi teszten.
A weboldalak iktatása egyetlen iratként számos esetben hasznos lehet, például amikor egy webhely „pillanatképeit” időszakosan el kell tárolni. A weboldalak iktatása feltehetően több ponton is a hivatkozások módosítását igényli (hivatkozások oldalakon belül, hivatkozások más weboldalara, hivatkozások grafikus komponensekre stb.) az oldal eredeti megjelenésének és funkcionalitásának megőrzése érdekében. Amennyiben lényeges a funkcionalitás és hű megjelenés megőrzése, a grafikus elemek, stíluslapok stb. eltárolása miatt a hivatkozások módosítása elkerülhetetlen. A weboldal információtartalma azonban semmilyen körülmények között nem változtatható meg. Lásd a 6.1.5 és 6.1.6 követelményeket. 10.6.8.
A TKR-től kapott iratok fogadását automatikusan rögzítenie kell az EIKR-nek az eseménynaplóban és az iratok metaadatai között.
Igen
Igen
10.6.9.
A TKR-be küldendő iratok kiválasztásakor az EIKR-nek lehetővé kell tennie a felhasználó számára, hogy felhasználhassa a rendelkezésére álló TKR metaadatok értékeit.
Igen
Igen
Igen
Igen
A 10.6.3. pontban megkezdett példát folytatva, a felhasználó kiválaszthatja az iratokat azok „státusza” és „érvénybe lépésük időpontja” alapján. 10.6.10. Az EIKR-nek lehetővé kell tennie a felhasználói szerepkörök számára, hogy meghatározott iratok másolatainak és a kiválasztott metaadatok küldését kezdeményezzék a TKR-be. A metaadatokat meg lehet határozni a rendszer konfigurációja során.
Hiv.
Követelmény
10.6.11. A TKR-be küldött iratokat automatikusan rögzítenie kell az EIKR-nek az eseménynaplóban és az iratok metaadatai között.
10.7.
Köt.
Teszt
Igen
Igen
Elektronikus aláírások
Az elektronikus aláírások (néhol a digitális aláírás kifejezés is elterjedt) olyan információt tartalmaznak, amelynek alapján egyértelműen megállapítható egy elektronikus objektum hitelessége. Az elektronikus aláírás rendszerint egy karaktersorozat. Egyéb biztonsági algoritmusokkal, eljárásokkal és kulcsokkal (jelszóhoz hasonló karaktersorozatok) kombinálva segít megőrizni az irat integritását és azonosítani az irat forrását vagy küldőjét. Az elektronikus aláírás nem összetévesztendő a küldő kézi aláírásának a beszkennelt képével vagy a bittérképpel, azok ugyanis nem megbízhatóak, így nem igazolják az irat hitelességét. A MoReq2 értelmezésében az elektronikus aláírás az „elektronikus aláírások közösségi keretrendszeréről” készült 1999/93/EC európai ajánlásban („Directive on a Community Framework for Electronic Signatures”) megfogalmazott magas szintű elektronikus aláírás, mely az alábbi feltételeknek tesz eleget: egyértelműen kapcsolódik az aláíróhoz; alkalmas az aláíró azonosítására; olyan eszközzel/módszerrel stb. készült, amely az aláíró kizárólagos ellenőrzése alá esik; oly módon kapcsolódik a védett adathoz (pl. irathoz), hogy annak az aláírást követő módosítása egyértelműen észrevehető. Az elektronikus aláírások másik elterjedt szabványa az X.509 (lásd 7. függelék). Az elektronikus aláírásokhoz használt algoritmusok közül említésre érdemes a FIPS 186-2ben (lásd 7. függelék) definiált DSA (Digital Signature Algorithm) és az RSA/SHA-1. Számos szervezet életében az e-mail a kommunikáció alapértelmezett formája, aminek következtében naponta dokumentumok és iratok tucatjai keringnek a postaládák között viszonylag szabályozatlan környezetben. Egyre több helyen használnak elektronikus aláírásokat a hitelesség és integritás megerősítésére, különösen ahol üzleti tranzakciókat tanúsító iratokat küldenek egymásnak a felek. Az elektronikus aláírások az üzenetek letagadhatatlanságát is garantálják (az üzenet letagadása azt jelenti, hogy a küldő nem vállal érte felelősséget). A letagadhatatlanság biztosítja, hogy az adat integritása és eredete bármikor leellenőrizhető harmadik fél által, így az egyén vagy entitás nem tagadhatja, hogy végrehajtott olyan tevékenységet az adatokon, mint azok jóváhagyása, elküldése, fogadása, elismerése (a fogadott üzenet tartalmának felismerése) és szállítása (fogadása és elismerése). A fejezetben összefoglalt követelményeket csak abban az esetben érdemes megvalósítani, ha az EIKR felhasználási környezete megkívánja az elektronikus aláírásokkal ellátott iratok kezelését. A Specifikáció írásának idején az elektronikus aláírások folyamatosan fejlődnek, köszönhetően az újabb infrastruktúrák és algoritmusok fejlesztésének, tesztelésének és bevezetésének. Mivel az elektronikus aláírások helyzete feltehetően nem mutat előrelépést a
közeljövőben, javasoljuk, hogy a MoReq2 felhasználói egyeztessék az egyes algoritmusokra vonatkozó követelményeket és azok következményeit a megfelelő hatóságokkal. Az alábbiakban felsorolt követelmények általános elvárásokat fogalmaznak meg, az egyes országok ettől eltérő rendelkezéseket is kiadhatnak. Törvényi szabályozás írhatja elő például a teljes elektronikus aláírás megőrzését, míg máshol elegendő az aláírás metaadatait eltárolni. Hiv. 10.7.1.
Követelmény
Köt.
Teszt
Az EIKR-nek képesnek kell lennie az irat iktatásával egyidejűleg iktatni, szükség szerint ellenőrizni és eltárolni az irathoz kapcsolódó elektronikus aláírásokat, elektronikus tanúsítványokat és az azokat kiadó tanúsító szolgáltatók adatait.
Igen
Igen
Igen
Igen
Az EIKR-nek szabványos interfészekkel kell támogatnia a legújabb Nem elektronikus aláírás technológiák bevezetését.
Nem
Azért fontos ezeket az adatokat az irat iktatásakor rögzíteni, mert utólag nem mindegyik állhat rendelkezésre. 10.7.2.
Az EIKR-nek lehetővé kell tennie az adminisztrátori szerepkörök számára, hogy a rendszer konfigurálása során vagy egy későbbi időpontban beállíthassák, mely metaadatokat tárolja el a rendszer az elektronikusan aláírt iratok iktatásakor a hitelesség ellenőrzéséhez használt metaadatok közül, beleértve a nyilvános kulcsokat. Az adminisztrátor az alábbi lehetőségek közül választhat: a hitelesség tényének rögzítése; a hitelesség-ellenőrzési folyamat bizonyos adatainak rögzítése; az ellenőrzéshez használt összes adat rögzítése. Azért fontos ezeket az adatokat az irat iktatásakor rögzíteni, mert utólag nem mindegyik állhat rendelkezésre.
10.7.3.
Megfelelő szabványra példa W3C által kidolgozott XML Kulcskezelés Fejlesztési Terület (XML Key Management Spec XKMS, lásd 7. függelék). Az elektronikus aláírások fejlődését illetően ez különösen fontos szabvány. 10.7.4.
Az EIKR-nek képesnek kell lennie arra, hogy ellenőrizze az Nem elektronikus aláírások hitelességét, beleértve az iratokhoz tartozó tanúsítványok ellenőrzését az irat iktatásakor a rendelkezésre álló megbízható elektronikus tanúsítványok listája alapján. Az EIKR-nek el kell tárolnia az ellenőrzés kimenetét az irat metaadatai között. Az EIKR köteles jelenteni egy meghatározott felhasználó vagy adminisztrátori szerepkör felé, ha egy tanúsítvány nem megy át az ellenőrzésen. Azért fontos az ellenőrzést az irat iktatásakor elvégezni, mert utólag nem minden adat állhat rendelkezésre.
Igen
Hiv. 10.7.5.
Követelmény
Köt.
Teszt
E-mailek iktatásakor az EIKR köteles automatikusan rögzíteni és tárolni a metaadatok között az e-mail elektronikus aláírásának hitelesítési folyamatára vonatkozó részleteket, többek között:
Igen
Igen
Az EIKR-nek képesnek kell lennie arra, hogy az elektronikus Nem aláírással ellátott iratok integritását bizonyítsa.
Nem
az aláírás ellenőrzésének tényét; az aláírás ellenőrzését kezdeményező illető adatait (amennyiben értelmezhető); a tanúsítvány kiállítóját; az aláírást hitelesítő elektronikus tanúsítvány sorozatszámát; az aláírást hitelesítő tanúsító hatóság adatait; az ellenőrzés pontos dátumát és időpontját. Azért fontos ezeket az adatokat az e-mail iktatásakor rögzíteni, mert utólag nem mindegyik állhat rendelkezésre. Mivel a szoftverek változhatnak, a tanúsítványok lejárhatnak, és a tanúsító hatóságok megszűnhetnek, idővel ellenőrizhetetlenné válnak az elektronikus aláírások. A hitelesség ellenőrzésének tényét tehát célszerű iktatáskor rögzíteni. 10.7.6.
Példaként említhető az elektronikus aláírások ellenőrzése. Az integritás igazolásának e formája akkor is fennáll, ha egy adminisztrátori szerepkör jogos változtatásokat végzett az irat metaadatain. A Specifikáció nem írja elő az integritás bizonyításának módját. 10.7.7.
Az EIKR-nek el kell tudnia tárolni az elektronikus irattal együtt:
Nem
Igen
Az EIKR adminisztrátorának be kell tudnia állítani, hogy a rendszer Nem tárolja el az elektronikus aláírás ellenőrzését végző rendszertől visszakapott digitális érvényességi jegyet (validation ticketet).
Igen
az irathoz kapcsolódó elektronikus aláírás(oka)t; az aláírást hitelesítő elektronikus tanúsítvány(oka)t. 10.7.8.
Az érvényességi jegy másik gyakori angol elnevezése a token.
Hiv. 10.7.9.
Követelmény
Köt.
Teszt
Az EIKR-nek lehetővé kell tennie egy adminisztrátori szerepkör Nem számára, hogy elektronikus aláírással lássa el az adatátvitelre szánt dossziékat, iratokat vagy átviteli üzeneteket a dossziék, iratok és adatátviteli üzenetek integritásának és forrásának későbbi ellenőrzése céljából.
Igen
Adatátviteli üzeneten olyan üzenetet értünk, amelyet két alkalmazásrendszer vált egymással a rendszerek közötti átvitelek kezeléséhez használt protokoll részeként. 10.7.10.
Az exportált vagy áthelyezett (lásd 10.7.9.) dossziék, iratok vagy Nem adatátviteli üzenetek elektronikus aláírására külső hitelesítést is lehessen alkalmazni a dossziék, iratok és adatátviteli üzenetek integritásának és forrásának későbbi ellenőrzése céljából. Ehhez az EIKR-nek a szervezet nyilvános tanúsítványt is exportálnia kell az irattal együtt.
10.8.
kulcsával
Igen
aláírt
Titkosítás
A titkosítás egy elektronikus objektumon végrehajtott összetett átalakítási folyamat, melynek eredményeként az objektum olvashatatlan vagy értelmezhetetlen formában jelenik meg a különféle alkalmazásokban megfelelő visszafejtés nélkül. A biztonságos elektronikus kulcs kódokkal végzett átalakítások garantálják az elektronikus objektumok biztonságát. A fejezetben összefoglalt követelményeket csak abban az esetben érdemes megvalósítani, ha az EIKR felhasználási környezete megkívánja az elektronikus aláírásokkal ellátott iratok kezelését.
Követelmény
Köt.
Teszt
10.8.1.
Az EIKR-hez kapcsolódó szoftveralkalmazástól kapott vagy számára küldött titkosított iratok hozzáférését a rendszernek azon felhasználókra kell korlátoznia, akik az irat hozzáférését szabályozó hagyományos jogosultságon túlmenően rendelkeznek az irat visszafejtéséhez szükséges kulccsal.
Igen
Igen
10.8.2.
Az EIKR köteles iktatni és tárolni az irat iktatásakor a titkosítással kapcsolatos adatokat és az érintett hitelesítő szervek adatait.
Igen
Igen
10.8.3.
Az EIKR-hez kapcsolódó szoftveralkalmazásoktól titkosított formában Nem érkező iratok fogadásakor az EIKR-nek el kell tudnia tárolni az irat mellett metaadatként az alábbi adatokat:
Igen
Hiv.
a titkosított átvitel tényét; az elektronikus értelmezhető);
tanúsítvány
sorozatszámát
(amennyiben
az algoritmus típusát; a titkosítás szintjét; a titkosítás, a visszafejtési folyamat (amennyiben értelmezhető), vagy mindkettő pontos dátumát és időpontját. 10.8.4.
Az EIKR-nek biztosítania kell a titkosítást szoftveralkalmazásból fogadott titkosított iratok iktatását.
használó Nem
Igen
10.8.5.
Az EIKR-nek lehetővé kell tennie a titkosítás eltávolítását az iratok Nem importálásakor vagy iktatásakor. A szolgáltatás használatáról egy adminisztrátori szerepkör dönthet a rendszer konfigurálásakor vagy egy későbbi időpontban.
Igen
A titkosítás eltávolítása főként a nagymennyiségű iratokat tároló levéltárak esetében lehet hasznos, ahol fontos a hosszú távú olvashatóság megőrzése (a titkosítás ugyanis csökkenti az iratok olvashatóságának esélyét az idő előrehaladtával). Ilyenkor az eseménynaplóból derül ki, hogy titkosított formában érkezett-e az irat, és ha igen, mikor fejtették vissza eredeti formájába. Más környezetekben törvénytelennek minősülhet a titkosítás eltávolítása. Részletekért lásd az 5.3. és 3.1. szakaszokat az iratok áthelyezésével és importálásával kapcsolatban. 10.8.6.
Az EIKR architektúráját fel kell készíteni új titkosítási technológiák bevezetésére.
10.9.
Digitális jogkezelés
Nem
Nem
Ez az opcionális modul olyan követelményeket tartalmaz, amelyek jelen formájukban nem tesztelhetők. Amint az alábbiakból is kitűnik, a tesztelhetőség csak konkrét technológiákra vetített követelményeknél nyer értelmet.
A digitális jogkezelés (DRM, Digital Rights Management) és a vállalati digitális jogkezelés (EDRM, Enterprise Digital Rights Management) olyan, jelenleg még nem szabványosított technológiák, melyek célja a szellemi tulajdon védelme és a terjesztés korlátozása. A DRM elsődleges célja a szellemi tulajdon védelme (főként a zene-, kiadó- és filmiparban), míg az E-DRM inkább a biztonsági vagy piaci szempontból érzékeny üzleti adatok terjesztését korlátozza. A két technológia között azonban nem ennyire éles a határvonal, egy EIKR-ben bármelyikkel találkozhatunk. Ennek megfelelően a szakasz további részeiben a két technológiára együttesen a DRM/E-DRM jelölést vezetjük be. Példák DRM/E-DRM technológiákra: Az elektronikus vízjelek (más néven digitális vízjelek) jól látható formában jelölik az elektronikus dokumentumok és iratok szellemi tulajdonosát. Az információt összetett kialakításából eredően nehéz eltávolítani. A szteganográfia a vízjelhez hasonlóan szintén a szellemi tulajdon feltüntetésére szolgál, azonban láthatatlan, vagy hangfájlok esetén hallhatatlan jelölés. A tulajdonjogra vonatkozó információ csak speciális szoftverrel olvasható el. A másolás elleni védelmet nyújtó eszközök különféle módszerekkel akadályozzák a jogtalan terjesztést. Egyes szolgáltatások csak a dokumentumok és iratok megjelenítését támogatják, nyomtatásukat nem. Lejárati idők beépítésével korlátozható a dokumentumok és iratok megjelenítése egy meghatározott időpont bekövetkeztétől számítva. A DRM/E-DRM technológiák még fejlődésük korai fázisában tartanak, emiatt valószínű, hogy jelentős változáson mennek keresztül a MoReq2 becsült élettartama alatt. Ezek a technológiák iratformátumok széles skáláján hasznosíthatók, beleértve a digitalizált hang- és mozgókép-felvételeket. Az iratkezelés szempontjából azonban egyedi problémának tekinthető az a tény, hogy ezek a technológiák az idő előrehaladtával csökkentik, szélsőséges esetekben pedig ellehetetlenítik az iratok megfelelő megjelenítését. Például: Egyes vízjelek csak bizonyos szoftverbővítményekkel megjelenítve látszanak a maguk teljességében. Jóllehet az irat a bővítmény nélkül is megtekinthető, a vízjel az információknak csupán a töredékét mutatja. Idővel nő a valószínűsége a bővítmény megszűnésének. Amennyiben egy e-mailt lejárati idővel láttak el, az üzenet nem olvasható a megadott dátum után. Ez alattomos problémát okozhat, az elektronikus levél iktatásakor ugyanis nem feltétlenül látszik, hogy lejárati időt használtak. A legáltalánosabb elvárás az EIKR felhasználói és adminisztrátori szerepköreivel szemben, hogy ismerjék a rendszerben használt DRM/E-DRM megoldásokat. Az iratkezelésre vonatkozó nehézségek hatása minimálisra csökkenthető, ha megengedett, hogy a rendszer eltávolíthassa a DRM/E-DRM jelöléseket az iratokról iktatáskor vagy nem sokkal később. A felhasználók tájékoztatása és a DRM/E-DRM technológiák eltávolítása azonban eljárásbeli kérdés, és mint ilyen a MoReq2 hatáskörén kívül esik.
Az alkalmazható technológiák köre meglehetősen sokrétű, hasonlóan az egyes megoldásoknak az iratokon kifejtett hatásához. Ebből kifolyólag lehetetlen olyan általános követelményeket megfogalmazni, amelyek mindegyik technológiára érvényesek. Ebben a szakaszban kizárólag magas szintű követelményeket gyűjtöttünk össze, melyeket a MoReq2 felhasználói kibővíthetnek és pontosíthatnak körülményeikhez mérten. Ha például a szervezet lejárati időket alkalmaz, a követelményeket úgy kell átfogalmazni, hogy azok a lejárati idők használatának részleteire térjenek ki. Követelmény
Köt.
Teszt
10.9.1.
Az EIKR-nek képesnek kell lennie DRM/E-DRM jelölésekkel ellátott iratokat iktatni és tárolni.
Igen
Nem
10.9.2.
Az EIKR-nek fel kell tudnia ismerni az iratok iktatásakor, ha az adott Nem iratot DRM/E-DRM jelöléssel látták el. DRM/E-DRM jelölés észlelésekor a rendszernek értesítenie kell a felhasználót, és az alábbi lehetőségeket kell felkínálnia:
Nem
Hiv.
a DRM/E-DRM jelölések megőrzése; a DRM/E-DRM jelölések eltávolítása, amennyiben lehetséges; az iktatási folyamat leállítása. 10.9.3.
Az EIKR-nek el kell tudnia távolítani a DRM/E-DRM jelöléseket az Nem iratokról iktatáskor.
Nem
Egyes környezetekben elvárás a DRM/E-DRM jelölések eltávolítása, ugyanakkor nem tehető általános érvényű követelménnyé, mivel más környezetekben a biztonsági eljárások megkerülésére adna lehetőséget. A DRM/E-DRM jelölések eltávolítását minden esetben rögzíteni kell az eseménynaplóban. 10.9.4.
Az EIKR-nek lehetőséget kell biztosítania az iratok szellemi Nem tulajdonjog alapján történő hozzáférésének a korlátozására, beleértve a hozzáférések kiszámlázását.
Nem
Ez a tömör állítás önmagában véve számos olyan további funkciót vet fel, amely a MoReq2 hatáskörén kívül esik. A követelménynek eleget tehet egy külső alkalmazás bevonása. 10.9.5.
Az EIKR-nek helyesen kell megjelenítenie a DRM/E-DRM jelöléssel ellátott iratokat, amennyire azt a DRM/E-DRM jelölések engedik.
Igen
Nem
10.9.6.
Az EIKR-nek képesnek kell lennie az iratok iktatásakor a DRM/E- Nem DRM jelölésekben foglalt információk kinyerésére és tárolására, amennyire azt a DRM/E-DRM jelölések engedik.
Nem
Célszerű lehet például a vízjelben feltüntetett szellemi tulajdonjogot vagy a lejárati időt eltárolni. Egyes környezetekben kötelező megvalósítani ezt a követelményt, de nem tehető általános érvényűvé, mivel olyan módszer használatát kívánná meg, amivel biztonsági eszközök válnának megkerülhetővé.
Köt.
Teszt
10.9.7.
Az EIKR-nek lehetővé kell tennie új DRM/E-DRM technológiák Nem bevezetését.
Nem
10.9.8.
Az EIKR-nek el kell tudnia látni DRM/E-DRM jelölésekkel az iratokat Nem exportáláskor.
Nem
Hiv.
Követelmény
Különösen abban az esetben, ha korábban az iratról eltávolították a DRM/E-DRM jelölést.
10.10. Elosztott rendszerek Ez a szakasz azokat a követelményeket foglalja össze, amelyekre az EIKR-t több helyszínen üzemeltető szervezetek tarthatnak igényt. Számos szervezet esetében zajlik a munkavégzés több helyszínen. Amennyiben ezek a helyszínek egymáshoz földrajzilag közel esnek, vagy jó minőségű hálózati kapcsolattal rendelkeznek (megfelelő a sávszélesség), elegendő lehet egyetlen EIKR „példányt” futtatni a különböző helyszínek kiszolgálására. Ilyenkor a szervezet működése azonos földrajzi elhelyezkedés benyomását kelti, ennél fogva fölösleges a szakaszban leírt követelményeket megvalósítani. Ha azonban erős földrajzi szórás vagy gyenge internetkapcsolat jellemzi a helyszíneket, ésszerű elosztott rendszerként megvalósítani az EIKR-t. Ez a szakasz az elosztott környezetekre vonatkozó követelményeket taglalja. Elosztott rendszerek tervezésekor több architektúra is szóba jöhet: egyetlen EIKR példány több tárhellyel; több, egymással kommunikáló EIKR példány saját tárhellyel, és ezekhez hasonló megoldások. A MoReq2 egyik architekturális megközelítést sem részesíti előnyben, ehelyett az elosztott rendszerekkel szemben támasztott kulcsfontosságú elvárásokat fogalmazza meg, ahol az „elosztott EIKR” tetszőleges architektúrát takar. Köt.
Teszt
10.10.1. Az EIKR konfigurációjának lehetőséget kell biztosítania egy adminisztrátori szerepkör számára a több helyszínen történő elosztott használat beállítására.
Igen
Nem
10.10.2. Az EIKR-nek támogatnia kell az elektronikus irattárak hálózatán elosztott besorolási sémák használatát.
Nem
Igen
10.10.3. Az EIKR-nek lehetővé kell tennie egy adminisztrátori szerepkör számára, hogy az osztályokon, dossziékon, aldossziékon, köteteken, iratokon, azok metaadatain és az eseménynaplón egyszer végrehajtott karbantartási műveleteket a teljes EIKR hatókörén belül érvényesíthesse.
Igen
Rész ben
Hiv.
Követelmény
Karbantartáson a 3. fejezetben, a 9.1. szakaszban és a Specifikáció egyéb részeiben kifejtett műveleteket értjük.
Köt.
Teszt
10.10.4. Amennyiben az EIKR több tárhely használatát támogatja, lehetővé Nem kell tennie egy adminisztrátori szerepkör számára, hogy kijelölhesse, mely tárhelyeken tárolja a rendszer az egyes osztályok (és az alá sorolt osztályok, iratok stb.) eredeti, „mester” példányait.
Igen
Hiv.
Követelmény
Elképzelhető, hogy a szervezet helyszínenként egy-egy tárhely mellett dönt, és az adott helyszínen tárolt iratokat a helyszínhez tartozó tárhely kezeli (feltéve, hogy a besorolási séma támogatja az ilyen típusú konfigurációt). 10.10.5. Amennyiben az EIKR több tárhely használatát támogatja, lehetővé Nem kell tennie egy adminisztrátori szerepkör számára, hogy kijelölhesse, mely tárhelyek tárolják automatikusan az egyes osztályok (és az alá sorolt osztályok, iratok stb.) másolatát.
Igen
A szervezetben dönthetnek úgy, hogy minden tárhely tartalmát fel kell másolni a központi iroda tárhelyére; egy adott régión belül minden tárhely tartalmát át kell másolni a többi tárhelyre. Közvetve ez azt jelenti, hogy gondoskodni kell a tárhelyek automatikus szinkronizálásáról. Szinkronizálni kell: az iratokat és a dokumentumokat; a metaadatokat. 10.10.6. Amennyiben az EIKR több tárhely használatát támogatja, lehetővé Nem kell tennie egy adminisztrátori szerepkör számára, hogy kijelölhesse, az egyes helyszíneken a felhasználók mely tárhelyekhez férhetnek hozzá. A szervezetben dönthetnek úgy, hogy a felhasználók csak a saját helyszínükhöz tartozó tárhelyhez férhetnek hozzá; a felhasználók a saját helyszínükhöz tartozó és a központi iroda tárhelyéhez férhetnek hozzá; a központi iroda felhasználói minden tárhelyet elérhetnek, míg a többi felhasználó csak a helyszínéhez tartozó tárhelyhez kap hozzáférést; a felhasználók a régió összes tárhelyéhez hozzáférhetnek (azaz tárhelyek meghatározott körét érhetik el; az EIKR-nek nem kell ismernie a „régió” fogalmát).
Igen
Köt.
Teszt
10.10.7. Amennyiben az EIKR több tárhely használatát támogatja, lehetővé Nem kell tennie egy adminisztrátori szerepkör számára, hogy előírhassa az eseménynaplók egy tárhelyre történő másolását.
Igen
10.10.8. Az EIKR-nek meg kell előznie vagy fel kell oldania a különböző helyszíneken végzett változtatásokból származó ellentmondásokat.
Igen
Rész ben
10.10.9. Az EIKR-nek lehetővé kell tennie egy adminisztrátori szerepkör számára, hogy az elosztott EIKR-t egyetlen entitásként és több tárhelyként is megfigyelhesse, a 9.2. szakaszban leírt eszközökkel.
Igen
Igen
10.10.10. Az EIKR-nek lehetővé kell tennie több tárhelyre kiterjedő jelentések készítését (a 9.2. szakaszban leírtaknak megfelelően).
Nem
Igen
10.10.11. Az EIKR-nek támogatnia kell a távoli tárhelyeket használó Nem helyszíneken a gyakran és a nemrégiben hozzáfért dossziék, aldossziék, kötetek és iratok gyorsítótárba másolását.
Igen
Hiv.
Követelmény
Ellentmondás léphet fel például, ha két, különböző helyszínen dolgozó adminisztrátori szerepkör különböző módosítást végez egy harmadik helyszínen tárolt osztály metaadatain.
Az alábbi két követelmény az elosztott EIKR-ek teljesítményére vonatkozik. A követelmények a változó mennyiségek kifejezésénél megszokott csúcsos zárójeleket (pl. <xx perc/óra>) alkalmazzák a 11. fejezet bevezetésében leírtaknak megfelelően. 10.10.12. Amennyiben az EIKR szinkronizálja a tárhelyeket, a szinkronizálást a változtatásokat követő legfeljebb <xx perc/óra> időtartamon belül el kell végeznie (a hálózati kapcsolatok rendelkezésre állásától függően).
Igen
Nem
10.10.13. Az EIKR-nek továbbítania kell az adminisztrátori változtatásokat legfeljebb <xx perc/óra> időtartamon belül a többi tárhely felé.
Igen
Nem
A 10.10.12. és a 10.10.13. követelmények csak mintául szolgálnak. A MoReq2 nem írja elő a válaszidők nagyságát, mivel azok rendszerfüggők. Részletes leírásért lásd a 11.2. szakaszt. Kiemelkedően fontos, hogy a rendszerarchitektúra elfogadható válaszidőt biztosítson az elérés helyétől függően. Javasoljuk a MoReq2 felhasználóinak, hogy gondolják át a 11.2. szakaszban leírt követelményekben foglalt tranzakciók válaszidejét távoli elérésű tárhelyek esetére is.
Köt.
Teszt
Igen
Igen
10.10.15. Amennyiben az EIKR több tárhely használatát támogatja, és a Nem „mester” példányokat meghatározott tárhelyeken tárolja (lásd 10.10.4.), lehetővé kell tennie egy adminisztrátori szerepkör számára, hogy az megváltoztathassa az egyes osztályok (és az alá sorolt osztályok, iratok stb.) törzspéldányainak tárolási helyét; ezzel egyidejűleg az EIKR köteles átmozgatni az osztály tartalmát a régi tárhelyről az újra.
Igen
Hiv.
Követelmény
10.10.14. Amennyiben az EIKR képes rendszerek között elosztott munkafolyamatokat kezelni, támogatnia kell az adatátvitelt a rendszerek között a munkafolyamatok irányítása céljából.
Ez a követelmény egyrészt a tárhelyek létesítését és megszűntetését segíti, másrészt az üzleti funkciók földrajzi áthelyezéséből származó iratköltöztetést támogatja. 10.10.16. Amennyiben az EIKR több tárhely használatát támogatja, lehetővé kell tennie egy adminisztrátori szerepkör számára új tárhely létesítését.
Igen
Igen
10.10.17. Amennyiben az EIKR több tárhely használatát támogatja, lehetővé kell tennie egy adminisztrátori szerepkör számára a tárhelyek megszüntetését.
Igen
Igen
10.11. Offline és távoli munka Ez a szakasz az EIKR mobil és offline használatával kapcsolatos követelményeket foglalja össze. A követelmények azokat az eseteket fedik le, amikor a felhasználók nem létesítenek stabil kapcsolatot az EIKR-rel (vagy az azt kiszolgáló hálózattal). Ide sorolhatóak az alábbi szituációk: a felhasználók hordozható eszközről (pl. mobil, notebook stb.) kapcsolódnak az EIKRhez, vagy asztali számítógépről csatlakoznak időszakosan az EIKR-hez; a felhasználók modemes vagy egyéb alacsony sávszélességű kapcsolaton keresztül csatlakoznak az EIKR-hez (pl. távoli munkavégzés során vagy átmeneti helyszínen); a felhasználók egyéb mobileszközről (pl. PDA, okostelefon) csatlakoznak az EIKR-hez. A hordozható számítógépek hagyományos munkaállomásként működnek az EIKR-hez történő csatlakozást követően. Ugyanakkor a felhasználók részéről felmerülhet az igény az iratok és adatok letöltésére és szinkronizálására, hogy offline módban is tudjanak dolgozni. Az offline üzemmód támogatásához az EIKR-nek nemcsak az iratokat és azok gyűjteményeit kell letöltenie, hanem a hozzájuk tartozó metaadatokat is. A rendszernek a megváltoztatott adatok szinkronizálásáról is gondoskodnia kell a felhasználók legközelebbi csatlakozásakor. Hasonlóképpen a felhasználók hordozható számítógépekről is csatlakozhatnak időszakosan a rendszerhez, legtöbbször távoli munkavégzés céljából. Kapcsolódáskor az EIKR-nek szinkronizálnia kell a hordozható számítógéppel, melynek részét képezi az iratok letöltése a
számítógépre és a letöltött adatok kezelése a hordozható számítógépen két szinkronizáció között. A PDA-k, okostelefonok és egyéb kézi eszközök alkalmasak lehetnek az iratok elérésére és megtekintésére egy böngésző felületen keresztül. Az eszközök méretükből adódó korlátaik miatt (pl. kisméretű kijelző, gyenge teljesítmény) azonban nem képesek az asztali vagy hordozható számítógépekről elérhető összes funkciót biztosítani. Ugyanakkor a felhasználók sűrűn használják kisméretű eszközeiket e-mailküldésre, jegyzetelésre és emlékeztetők írására, a központi rendszernek tehát ezeket a dokumentumtípusokat is figyelembe kell vennie a szinkronizáláskor. A MoReq2 nem követeli meg a besorolási séma és a dossziék karbantartását (pl. új osztályok létrehozása, dosszié lezárása stb.) mobileszközről vagy offline módban. Természetesen elképzelhető olyan rendszerek fejlesztésre, amelyek lehetővé teszik az ilyen jellegű feladatok elvégzését is, a MoReq2 nem korlátozza az offline módú szolgáltatások körét. Köt.
Teszt
10.11.1. Az EIKR-nek lehetővé kell tennie egy adminisztrátori szerepkör Nem számára, hogy megjelölhessen olyan iratgyűjteményeket, amelyek tartalmuk miatt nem tölthetők le a felhasználók gépére.
Igen
Hiv.
Követelmény
Ez a biztonsági követelmény az érzékeny adatok letöltését akadályozza meg, melyek ezáltal nem kerülhetnek az EIKR hatáskörén kívülre. 10.11.2. Az EIKR-nek lehetővé kell tennie a felhasználó számára, hogy tetszőleges iratgyűjteményt letölthessen a kapcsolódó metaadatokkal együtt hálózat nélküli munkavégzés céljából.
Igen
Igen
10.11.3. Az EIKR-nek rögzítenie kell az eseménynaplóban a letöltött iratgyűjteményeken, iratokon és dokumentumokon végzett műveleteket.
Igen
Igen
10.11.4. Az EIKR-nek jeleznie kell a letöltött iratgyűjtemény, irat vagy Nem dokumentum metaadatai között, hogy azt offline módban használják.
Rész ben
10.11.5. Az EIKR-nek gondoskodnia kell a letöltött iratgyűjtemények, iratok és dokumentumok szinkronizációjáról a rendszerhez történő újracsatlakozáskor.
Igen
Azaz frissítenie kell a metaadatokat és lehetőséget kell biztosítania az esetleges ellentmondások feloldására.
Igen
Köt.
Teszt
10.11.6. Az EIKR-nek frissítenie kell az eseménynapló tartalmát az offline módú munkavégzés részleteiről a rendszerhez történő újracsatlakozáskor.
Igen
Igen
10.11.7. Az EIKR-nek lehetővé kell tennie a felhasználó számára, hogy dokumentumot hozzon létre offline módban, majd újracsatlakozáskor iratként iktassa azt.
Igen
Igen
Igen
Rész ben
Hiv.
Követelmény
Amennyiben az irat újracsatlakozáskor
offline
módban
készült,
az EIKR-nek
fel kell ajánlania a felhasználónak a szinkronizációt egy párbeszédablakban, ahol lehetőséget kínál az iktatás helyének (a megfelelő osztálynak, dossziénak, aldossziénak vagy kötetnek) a kiválasztására; vagy automatikusan iktatnia kell abba az osztályba, dossziéba, aldossziéba vagy kötetbe, amelyet a felhasználó szétkapcsoláskor megjelölt (megerősítés mellett). 10.11.8. Az EIKR-nek az összes hozzáférési és biztonsági szabályozást érvényesítenie kell a távolról csatlakozó eszközökkel szemben. Az EIKR nem engedheti, hogy hordozható eszközökkel megkerülhessék a rendszer biztonsági szabályait. A felhasználók például nem tölthetnek le olyan adatot hordozható eszközükre, amelyhez egyébként nem lenne hozzáférésük. A MoReq2 azonban tisztában van azzal a problémával, hogy letöltés után elveszti az adatok fölött gyakorolt felügyeletét, és az ebből származó biztonsági szabálysértések ellen nem tehet semmit. Az alábbi négy követelmény csak abban az esetben mérvadó, ha az EIKR az elektronikus dokumentumkezelést is támogatja a 10.3. szakaszban leírtaknak megfelelően. Az alábbi követelmények terminológiája az említett szakasz szóhasználatát követi.
Köt.
Teszt
10.11.9. Az EIKR-nek lehetővé kell tennie a felhasználó számára, hogy letölthessen dokumentumokat az azokhoz kapcsolódó metaadatokkal együtt hálózat nélküli munkavégzés céljából.
Igen
Igen
10.11.10. Az EIKR-nek lehetővé kell tennie a felhasználók számára, hogy kivehessék (check out) a dokumentumokat letöltés közben.
Igen
Igen
10.11.11. Amennyiben a felhasználó kivesz egy dokumentumot, majd azon offline módban dolgozik, a rendszernek lehetővé kell tennie a dokumentumok verziószámozását.
Igen
Igen
10.11.12. Amennyiben a felhasználó kivesz egy dokumentumot, és megváltoztatja annak verziószámát kapcsolat nélküli (offline) módban, újracsatlakozáskor az EIKR-nek lehetővé kell tennie a felhasználó számára az átdolgozott dokumentum feltöltését, ezzel egyidejűleg pedig vissza kell tennie (check in) a dokumentumot, továbbá rögzítenie kell a változtatásokat és az új verziószámot.
Igen
Igen
Hiv.
Követelmény
10.12. Faxok integrálása Jóllehet az elektronikus levelezés a legtöbb szervezetnél átvette a vezető szerepet a gyors kommunikáció terén, bizonyos helyzetekben és helyeken továbbra is a faxok használatát részesítik előnyben. Faxot célszerű használni például akkor, ha egy nem elektronikus formátumú dokumentum másolatát át kell küldeni egy másik szervezetnek, vagy valamilyen jól látható jelölés, például aláírás meglétét kell igazolni. Amennyiben a fax szervereket e-mail szerverekkel integrálják, a bejövő és kimenő faxok email csatolmányként jelennek meg. Ez esetben a 6.3. szakaszban foglalt követelményeket kell figyelembe venni. Az alábbiakban felsorolt követelmények a szervezet EIKR megoldásába integrált faxszolgáltatásokra vonatkoznak. Köt.
Teszt
10.12.1.
Az EIKR-nek alkalmazás programozói interfészen (API-n) keresztül Nem kell biztosítania csatlakozási felületet a fax szerverek felé.
Nem
10.12.2.
Az EIKR-nek képesnek kell lennie szabványos formátumban (pl. TIFF v6 képformátum IV. csoportú faxtömörítéssel) eltárolni a faxokat.
Igen
Hiv.
Követelmény
Lásd az ISO 12033 szabványt a tömörítési módszerekről.
Igen
Követelmény
Köt.
Teszt
10.12.3.
Az EIKR-nek integrált módon kell támogatnia a faxok iktatását, azaz lehetővé kell tennie a felhasználó számára, hogy az iktatást a fax kezelőfelületéről (amennyiben létezik ilyen) is kezdeményezhesse anélkül, hogy az EIKR-re kellene váltania.
Igen
Igen
10.12.4.
Az EIKR-nek szoros integrációt kell biztosítania a fax kezelőfelületével annak érdekében, hogy a felhasználók elküldhessék faxon az aktuálisan megtekintett vagy használt elektronikus iratokat közvetlenül az iratkezelő rendszerből (feltéve, hogy az irat megjeleníthető kétdimenziós kép formájában).
Igen
Igen
10.12.5.
Az EIKR-nek lehetővé kell tennie egy adminisztrátori szerepkör számára, hogy kiválaszthassa a rendszer alapértelmezett viselkedését faxküldéskor. Az alábbi lehetőségek jöhetnek szóba:
Igen
Igen
Igen
Igen
Hiv.
a rendszer automatikusan iktassa iratként a faxot; a rendszer automatikusan kínálja fel a felhasználónak az iktatás lehetőségét; ne tegyen semmit a rendszer (a felhasználó kezdeményezi a fax iktatását belátása szerint). Függetlenül attól, hogy az adminisztrátor melyik lehetőséget állítja be, az EIKR megkérheti a felhasználót az irat kézi besorolására és a hiányzó metaadatok bevitelére. 10.12.6.
Az EIKR-nek lehetővé kell tennie egy adminisztrátori szerepkör számára, hogy kiválaszthassa a rendszer alapértelmezett viselkedését fax fogadásakor. Az alábbi lehetőségek jöhetnek szóba: a rendszer automatikusan kínálja fel a felhasználónak a fax iktatásának lehetőségét; ne tegyen semmit a rendszer (a felhasználó kezdeményezi a fax iktatását belátása szerint). Függetlenül attól, hogy az adminisztrátor melyik lehetőséget állítja be, az EIKR megkérheti a felhasználót az irat kézi besorolására és a hiányzó metaadatok bevitelére.
Hiv. 10.12.7.
Követelmény
Köt.
Teszt
Az EIKR-nek automatikusan ki kell tudnia nyerni a bejövő faxok Nem metaadat-elemeit a 12. fejezetben leírtak figyelembe vételével. Példák metaadatokra:
Igen
cím; feladó; pontos dátum és idő; címzett. A metaadatok kinyerését faxsablonok használata segítheti, de kizárólag megjósolható belső szerkezetű faxok esetén. 10.12.8.
Az EIKR-nek automatikusan ki kell tudnia nyerni a kimenő faxok Nem metaadat-elemeit a 12. fejezetben leírtak figyelembe vételével. Példák metaadatokra:
Igen
cím; feladó; pontos dátum és idő; címzett. A metaadatok kinyerését faxsablonok használata segítheti, de kizárólag megjósolható belső szerkezetű faxok esetén. 10.12.9.
Az EIKR-nek lehetőséget kell biztosítania a faxot iktató felhasználó számára a cím metaadat érték megváltoztatását, hogy az jobban tükrözze a fax tartalmát.
Igen
Igen
10.12.10. Az EIKR-nek egy-egy fax irattípussal kell támogatnia a beérkező és a Nem kimenő faxok metaadatainak bevitelét.
Igen
10.13. Biztonsági kategóriák A 4. fejezet részletezte az iratgyűjtemények és az iratok hozzáférhetőségének szabályozását szerepkör és felhasználócsoport alapján. Egyes környezetekben (pl. nemzetbiztonság, egészségügy) azonban további hozzáférés-korlátozás szükséges, amely figyelembe veszi a védett objektumok biztonsági kategóriáját és a felhasználók megbízhatósági bizonyítványát. A megbízhatósági bizonyítványok felülírják a 4. fejezet követelményeinek megfelelően kiosztott hozzáférési jogokat. Az alább felsorolt követelmények csak azokra a szervezetekre vonatkoznak, ahol szigorú biztonsági intézkedéseket igényel az iratok védelme. Az osztályok, dossziék, aldossziék, kötetek és iratok védelméről ún. „biztonsági kategóriák” hozzárendelésével gondoskodnak.
Jelen Specifikációban biztonsági kategórián „az irathoz rendelt egy vagy több kifejezést” értjük, melyek „meghatározzák az irat hozzáférésére vonatkozó szabályokat”. Megjegyzés. A „biztonsági kategória” a MoReq2 sajátos terminológiájának része, nem általánosan elterjedt kifejezés. A felhasználók adott esetben egyetlen megbízhatósági bizonyítványt kapnak, amely megakadályozza, hogy a magasabb biztonsági kategóriájú iratokhoz és iratgyűjteményekhez hozzáférhessenek. A biztonsági kategóriák további alkategóriákra bonthatók, melyek akár hierarchikus felépítésűek is lehetnek. Az alkategóriák természetesen a szervezetre vagy az adott szektorra jellemző egyedi szerkezetet is követhetnek. A MoReq2 csak a hierarchikus felépítésű alkategóriák követelményeit írja le. A követelményeket szemléltető példák nemzetbiztonsági jelöléseket használnak, de az elvek függetlenek a szektorok jelöléseitől. A nemzetbiztonsági besorolási követelmények országonként eltérhetnek, az eltéréseket a nulladik fejezet tartalmazza. Hiv. 10.13.1.
Követelmény
Köt.
Teszt
Az EIKR-nek lehetővé kell tennie, hogy a rendszer konfigurálásakor az alábbi lehetőségek közül lehessen választani:
Igen
Igen
Igen
Igen
Igen
Igen
biztonsági kategóriák osztályokhoz, dossziékhoz, aldossziékhoz és kötetekhez rendelhetők (iratokhoz nem); biztonsági kategóriák iratokhoz rendelhetők dossziékhoz, aldossziékhoz és kötetekhez nem);
(osztályokhoz,
biztonsági kategóriák iratokhoz és osztályokhoz, dossziékhoz, aldossziékhoz, kötetekhez egyaránt rendelhetők. Egyes szervezetekben az érzékeny adatokat tartalmazó iratokat külön védik, másokban a hozzáférést az osztályok, dossziék stb. szintjén határozzák meg. 10.13.2.
Az EIKR-nek lehetővé kell tennie egy adminisztrátori szerepkör számára, hogy a rendszer konfigurálásakor beállíthassa, mely szerepkörök felelősek az iratok és iratgyűjtemények biztonsági kategóriájának kijelöléséért és megváltoztatásáért. Egyes szervezeteknél a biztonsági kategória kijelölése az információ tulajdonosának a privilégiuma, más környezetekben azonban külön szerepkörhöz (pl. biztonsági felülvizsgáló, részlegvezető) köthető ez a feladat.
10.13.3.
Az EIKR-nek lehetővé kell tennie, ugyanakkor nem szabad előírnia a biztonsági kategóriák „alkategóriákra” bontását. A példa kedvéért a biztonsági kategóriákat az alábbi három fiktív alkategóriára bontjuk:
Hiv.
Követelmény
Köt.
Teszt
Igen
Igen
Az EIKR-nek lehetőséget kell biztosítania összetett és egyedi biztonsági Nem szabályok egyéni megvalósítására.
Nem
Biztonsági besorolás; Fenntartás; Leíró. Az egyes alkategóriák az információ biztonságának egy-egy dimenzióját határozzák meg. Példánkban a biztonsági besorolás, fenntartás és leíró alkategóriák tetszőleges érvényes kombinációja írja elő az irat biztonsági kategóriáját. 10.13.4.
Az EIKR-nek kötött szótárak használatát kell előírnia az egyes alkategóriák által felvehető értékek szabályozása céljából. A szótárak karbantartása egy adminisztrátori szerepkör feladata. A fiktív példánkban bemutatott alkategóriák az alábbi értékeket vehetik fel: Alkategória Megengedett értékek Besorolás
Szigorúan titkos Titkos Bizalmas Korlátozott Besoroláson kívüli
Fenntartás
Csak NATO részre Csak WEU részre
Leíró
Kereskedelmi Személyi állomány Vezetés Audit és beszámolók
Fiktív példánkban a „Biztonsági besorolás” alkategória hierarchikus felépítésű (lásd 10.13.6.) szemben a másik két alkategóriával. A hierarchikus alkategóriákkal kapcsolatos követelmények általánosan elterjedtek, leírásukat lásd alább. A nem hierarchikus szerkezetű alkategóriák gyakran összetettek és az adott szektorban elfogadott elveket tükrözik, ennél fogva a 10.13.5. és a 10.13.7. követelmények kivételével a MoReq2 nem tér ki további részletekre. 10.13.5.
A szabályok megvalósítását alkalmazásprogramozói interfészek támogathatják. A követelményt olyan helyzetek teszik indokolttá, amelyek a Specifikációban nem említett jelölési konvenciókat írnak elő (pl. IDO-jelölés), de az egészségügyi iratok is ide tartoznak.
Hiv. 10.13.6.
Követelmény
Köt.
Teszt
Az EIKR-nek legalább egy alkategória esetén öt szintű hierarchiát kell támogatnia, legmagasabb szinten a korlátlan hozzáféréssel, legalacsonyabb szinten pedig a legszigorúbb jelöléssel.
Igen
Igen
Igen
Igen
A 10.13.3. követelményben bemutatott „biztonsági besorolás” példa ilyen hierarchikus alkategóriára. 10.13.7.
Amennyiben egy alkategória és a neki megfelelő megbízhatósági bizonyítvány nem hierarchikus felépítésű, az EIKR-nek az alábbi két lehetőséget kell választásra felkínálnia a rendszer konfigurálásakor: az EIKR minden új felhasználó esetén érvényes bizonyítvány bevitelét kéri; az EIKR az alapértelmezett bizonyítványt használja új felhasználók hozzáadásakor. Az adminisztrátori szerepkör alapértelmezett bizonyítványt.
bármikor
megváltoztathatja
az
Más szóval, kötelező bizonyítványt társítani a felhasználókhoz. 10.13.8.
Amennyiben az EIKR az alapértelmezett hierarchikus bizonyítványt rendeli a felhasználóhoz (a 10.13.7. követelménynek megfelelően), a hierarchia legalacsonyabb szintjén lévő (azaz a legszigorúbb korlátozás alá eső) bizonyítványt kell választania.
Igen
Igen
10.13.9.
Az EIKR-nek azon felhasználókra kell korlátoznia az iratok (és/vagy osztályok, dossziék, aldossziék és kötetek – vö. 10.13.1.) hozzáférését, akik az irat (osztály, dosszié stb.) biztonsági kategóriájával legalább azonos szintű megbízhatósági bizonyítvánnyal rendelkeznek.
Igen
Igen
Önmagában a bizonyítvány nem feltétlenül elégséges. Az elektronikus iratok hozzáférését további, felhasználókra, felhasználócsoportokra és szerepkörökre kiterjedő szabályok korlátozzák a 4. fejezetben leírtaknak megfelelően.
Köt.
Teszt
Igen
Igen
Igen
Igen
Igen
Igen
10.13.13. Az EIKR-nek lehetővé kell tennie a megbízhatósági bizonyítványok Nem szerepkörökhöz rendelését, amelyet ezáltal az adott szerepkörrel rendelkező felhasználók örökölnek. A rendszernek lehetővé kell tennie a szerepkörtől örökölt megbízhatósági bizonyítványon kívül más megbízhatósági bizonyítványok hozzáadását egyénenként.
Igen
10.13.14. Amennyiben az EIKR a biztonsági kategóriákat az iratok és az Nem osztályok, dossziék stb. (lásd 10.13.1.) szintjén is támogatja, meg kell tudnia akadályozni, hogy az egyes osztályok, dossziék, aldossziék és kötetek alacsonyabb biztonsági kategóriába essenek, mint a hozzájuk tartozó iratok bármelyike.
Igen
Hiv.
Követelmény
10.13.10. Hierarchikus alkategóriák esetén az EIKR-nek az alábbi lehetőségek egyikét kell alkalmaznia új osztályok, iratok stb. biztonsági alkategóriájának meghatározásakor (az EIKR által választott lehetőséget egy adminisztrátori szerepkör állíthatja be a rendszer konfigurálása során, vagy tetszőleges későbbi időpontban): az EIKR az adminisztrátori szerepkör alapértelmezett értéket alkalmazza;
által
kiválasztott
az EIKR a szülő iratgyűjtő értékét használja alapértelmezésként; az EIKR egy adminisztrátori szerepkörtől várja el az érték bevitelét. 10.13.11. Nem hierarchikus alkategóriák esetén az EIKR-nek az alábbi lehetőségek egyikét kell alkalmaznia új osztályok, iratok stb. biztonsági alkategóriájának meghatározásakor (az EIKR által választott lehetőséget egy adminisztrátori szerepkör állíthatja be a rendszer konfigurálása során, vagy tetszőleges későbbi időpontban): az EIKR az adminisztrátori szerepkör alapértelmezett értéket alkalmazza;
által
kiválasztott
az EIKR a szülő iratgyűjtő értékét használja alapértelmezésként; az EIKR lehetővé teszi, de nem várja el egy adminisztrátori szerepkörtől az érték bevitelét. 10.13.12. Új hierarchikus biztonsági kategória vagy alkategória definiálásakor az EIKR-nek a hierarchia legalacsonyabb szintjén lévő értéket kell rendelnie alapértelmezésben az összes létező osztályhoz, irathoz stb. Más szóval, az alapértelmezett érték a hierarchia szintjei közül a legkevesebb hozzáférést engedélyezi.
Köt.
Teszt
Igen
Igen
Igen
Igen
Igen
Igen
10.13.18. Az EIKR-nek támogatnia kell a biztonsági kategóriák rutinjellegű, Nem rendszeres, előre ütemezett felülbírálását, ahol felülbírálás során:
Igen
Hiv.
Követelmény
10.13.15. Amennyiben a felhasználó olyan iratot kísérel meg iktatni, amelynek a biztonsági kategóriája magasabb az iktatás céljaként megjelölt gyűjteményénél, az EIKR-nek figyelmeztetnie kell a felhasználót, és legalább az alábbi tevékenységek egyikét fel kell kínálnia (a tevékenységek kínálatát a rendszer konfigurálásakor kell beállítani): a gyűjtemény biztonsági kategóriáját kategóriájának szintjére kell emelni; a rendszer nem gyűjteménybe;
engedélyezi
az
irat
az
irat
iktatását
biztonsági a
megjelölt
a rendszer automatikusan továbbítja az iratot egy meghatározott felhasználónak további intézkedésre; a rendszer felkínálja egy új gyűjtemény létrehozását a felhasználó számára, melynek metaadatait automatikusan kitölti az eredetileg megjelölt gyűjtemény megfelelő metaadataival, majd az új gyűjteménybe iktatja az iratot egyetlen integrált folyamat során. 10.13.16. Egy adminisztrátori szerepkörnek egyetlen lekérdezéssel meg kell tudnia állapítani bármely osztály, dosszié, aldosszié vagy kötet iratainak legmagasabb biztonsági besorolását. Egyes környezetekben ez a követelmény nagymértékben hozzájárul a rendszer kezelhetőségéhez. 10.13.17. A 10.13.1. követelmény teljesítésétől függően egy adminisztrátori szerepkörnek meg kell tudnia változtatni az osztályok, dossziék, aldossziék, kötetek és iratok biztonsági kategóriáját. Lásd még 10.13.27.
a felhasználó (megfelelő megbízhatósági bizonyítvány és engedélyek megléte mellett) megtekintheti a felülbírálás tárgyát képező iratokat és azok biztonsági kategóriáit; a felhasználó megváltoztathatja a biztonsági kategóriákat. A MoReq2 további részleteket nem ír elő a felülbírálással kapcsolatban.
Köt.
Teszt
10.13.19. Az EIKR-nek automatikusan tárolnia kell a biztonsági kategóriák értékeit visszamenőlegesen az érintett iratok, osztályok stb. metaadatai között.
Igen
Igen
10.13.20. A biztonsági kategória értékének módosításakor (a 10.13.18. pontban leírt felülbírálás keretein belül vagy más alkalommal) a rendszernek lehetővé kell tennie a felhasználó számára, hogy megindokolja a módosítást, és el kell tárolnia az indoklást a korábbi kategória értékével együtt (lásd 10.13.19.) metaadatként.
Igen
Igen
Igen
Igen
10.13.22. Az EIKR-nek támogatnia kell az osztályok, dossziék, aldossziék és Nem kötetek meghatározott időre történő biztonsági kategóriába sorolását, mely idő lejártával a rendszer automatikusan a legalacsonyabb szintre csökkenti az osztály, dosszié stb. biztonsági kategóriáját.
Igen
10.13.23. Az EIKR-nek támogatnia kell az osztályok, dossziék, aldossziék és Nem kötetek meghatározott időre történő biztonsági kategóriába sorolását, mely idő lejártával a rendszer automatikusan egy előre meghatározott, alacsonyabb szintre csökkenti az osztály, dosszié stb. biztonsági kategóriáját.
Igen
10.13.24. Az EIKR-nek értesítenie kell egy adminisztrátori szerepkört, ha az Nem osztályokhoz, dossziékhoz, aldossziékhoz, kötetekhez meghatározott időre rendelt biztonsági kategóriák periódusa a végéhez közeleg, lehetővé téve a biztonsági kategória átértékelését és módosítását.
Igen
Hiv.
Követelmény
Lásd a 10.13.2. követelményt a biztonsági kategóriák módosításával kapcsolatban. 10.13.21. Az EIKR-nek lehetővé kell tennie az irat megtekintéséhez szükséges megbízhatósági tanúsítvánnyal és engedélyekkel rendelkező felhasználók számára az irat aktuális és korábbi (lásd 10.13.19.) biztonsági kategóriáinak a megtekintését.
Az EIKR értesítést küldhet például „Születés dátuma + x év” leteltekor. Ez a forma az orvosi leletek adatvédelmével összhangban áll. 10.13.25. Az EIKR-nek automatikusan naplóznia kell a biztonsági kategóriák és alkategóriák értékeinek módosítását az eseménynaplóban.
Igen
Igen
10.13.26. Az EIKR nem engedélyezheti, hogy a felhasználó biztonsági kategóriát rendelhessen olyan osztályhoz, dossziéhoz, aldossziéhoz vagy kötethez, amelyhez nincs hozzáférése.
Igen
Igen
10.13.27. Az EIKR-nek lehetővé kell tennie egy adminisztrátori szerepkör számára, hogy egyetlen műveletben egy osztály, dosszié, aldosszié vagy kötet összes iratának és gyerekének (a 10.13.1. követelmény függvényében) a biztonsági kategóriáját megváltoztathassa.
Igen
Igen
Ez a rutin művelet az idővel csökkenő bizalmasságú iratok védelmét gyengíti.
Hiv.
Követelmény
10.13.28. Az EIKR-nek figyelmeztetnie kell egy adminisztrátori szerepkört, amikor egy irat biztonsági kategóriáját megpróbálják csökkenteni, és az adminisztrátor megerősítését kell kérnie a művelet végrehajtása előtt.
Köt.
Teszt
Igen
Igen
Igen
Igen
Különösen akkor, ha egy felhasználó alacsonyabb szintűre próbálja állítani a gyűjtemény biztonsági kategóriáját a gyűjteményben tárolt iratok biztonsági kategóriájának szintjénél. 10.13.29. Az EIKR-nek automatikusan rögzítenie kell a biztonsági kategóriákon végzett módosítások történetét, például a változtatások időpontját és részleteit, a megfelelő osztály, dosszié, aldosszié, kötet vagy irat metaadatai között. A történet része módosításonként a pontos dátum és idő, a változtatást kezdeményező felhasználó, a módosítás előtti és utáni értékek és az indoklás.
11.
NEM FUNKCIONÁLIS KÖVETELMÉNYEK
Egy EIKR implementáció sikere nem csak a rendszer funkcióitól függ. A gyakorlat azt mutatja, hogy a nem funkcionális követelmények lényegesen nagyobb mértékben járulnak hozzá a szoftver sikerességéhez, mint maguk a szolgáltatások. Ebben a fejezetben az EIKRek nem funkcionális követelményeit gyűjtöttük össze. A fejezetben bemutatott nem funkcionális követelmények az alábbi területeket fedik le: használhatóság (11.1. szakasz); teljesítmény és skálázhatóság (11.2. szakasz); a rendszer rendelkezésre állása (11.3. szakasz); műszaki szabványok (11.4. szakasz); jogi és szabályozási követelmények (11.5. szakasz); kiszervezett adatkezelés (11.6. szakasz); hosszú távú megőrzés és a technológiák elavulása (11.7. szakasz); üzleti folyamatok (11.8. szakasz). A funkcionális követelményekhez képest a nem funkcionális követelményeket nehéz pontosan megfogalmazni, még nehezebb objektíven mérni. Mindazonáltal érdemes kitérni az ilyen jellegű elvárásokra is, legalább magas szinten. Az alább felsorolt követelmények egy része az irat- és dokumentumkezelő rendszerekre jellemző, míg néhány követelmény teljesen általános, tetszőleges informatikai rendszerre értelmezhető. Javasoljuk a MoReq2 felhasználóknak a fejezetben leírtakon túl a szervezet igényeinek megfelelő korszerű műszaki és operatív szabványok figyelembe vételét. Az EIKR-beszállítók támogatásszolgáltatásainak (dokumentáció, testreszabás, betanítás és tanácsadás) körét és minőségét is érdemes megfontolni. Méretük, felépítésük, fizikai jellemzőik és műszaki adottságaik függvényében a szervezetek további követelményekkel bővíthetik a fejezet nem funkcionális követelményeit. Ez a szakasz pusztán támpontot ad ahhoz, hogy milyen szempontokat célszerű átgondolni. A konkrét követelményeket a korábbi fejezetekben leírt általános követelményekkel együtt kell kezelni. Néhány mintakövetelményben a csúcsos zárójelbe foglalt részeket a felhasználóknak alkalmazás-specifikus, konkrét mennyiségi értékekkel kell helyettesíteniük. Az <xx perc/óra> forma például azt jelenti, hogy a Specifikáció felhasználói igényüknek megfelelő konkrét időtartamot adhatnak meg, melynek mértékegysége perc vagy óra. Hasonlóan, a <4 mp>
arra utal, hogy a felhasználónak egy időközt kell meghatároznia, a 4 mp pusztán javaslat a konkrét érték eldöntéséhez. Más esetben a felhasználónak különböző kifejezések közül kell választania. A
kifejezés értelmezése tehát „naponta, vagy minden munkanapon, vagy évente meghatározott számú napon, vagy ehhez hasonló mennyiségben” a szervezet igényeinek megfelelően. Az „xx” minden esetben tetszőleges számot helyettesít, a szélsőértékekre nincsenek megkötések. A követelmények általános jellegéből és a szervezetek jelentős mértékben eltérő igényeiből adódóan a MoReq2 teszt-keretrendszer nem ellenőrzi a nem funkcionális követelmények betartását. Ennek megfelelően a táblázatok Teszt attribútuma is irányadó, nem előíró. A szervezetek és a MoReq2 felhasználók feladata, hogy elemezzék saját igényeiket, meghatározzák prioritásaikat, és elvégezzék az erre vonatkozó teszteket.
11.1.
Használhatóság
Egy EIKR követelményspecifikáció nem funkcionális követelményein belül mindenképpen ki kell térni a rendszer könnyű használatának feltételeire és azok pontos megfogalmazására. A használhatóság a leendő felhasználók típusától és a betanítási idő hosszától függ. Az alábbiakban a könnyű használatra vonatkozó mintakövetelmények olvashatók. Hiv. 11.1.1.
Mintakövetelmény
Köt.
Teszt
Az EIKR-nek lehetővé kell tennie egy adminisztrátori szerepkör számára, hogy meghatározhassa, a besorolási séma mekkora hányadához férhetnek hozzá az egyes felhasználócsoportok és szerepkörök.
Igen
Igen
Ezáltal szabályozható, hogy egyes felhasználók vagy csoportok (pl. ügyviteli környezetben dolgozók) a besorolási sémából csak egyetlen osztályhoz, vagy megadott dossziékhoz, aldossziékhoz férhessenek hozzá. 11.1.2.
Az EIKR-nek a teljes rendszerhez online súgót kell biztosítania.
Igen
Igen
11.1.3.
Az EIKR-nek hierarchikus formában kell megjelenítenie a besorolási sémát, lehetővé téve a felhasználók számára a fa bejárását a grafikus ábrázolás segítségével.
Igen
Igen
11.1.4.
Az EIKR-nek környezetérzékeny online súgót kell biztosítania.
Nem
Igen
11.1.5.
Az EIKR súgójának ki kell térnie a besorolási séma használatára, beleértve az osztályok, dossziék, aldossziék és kötetek leíró metaadatainak az elérését.
Nem
Rész ben
11.1.6.
Az EIKR-nek beépített tezaurusszal kell segítenie a felhasználókat a tárgyszavak, leírások stb. megfogalmazásában.
Nem
Igen
Lásd 11.4.1, 11.4.2 és 11.8.11.
Hiv. 11.1.7.
Mintakövetelmény
Köt.
Teszt
Az EIKR-nek olyan értelmes hibaüzeneteket kell előállítania, amelyek segítenek a felhasználónak kijavítani a hibát vagy félbeszakítani a hibát kiváltó folyamat.
Igen
Nem
Nem
Nem
Nem
Nem
Igen
Nem
Igen
Rész ben
Ideális esetben a hibaüzeneteket rövid magyarázat és a felhasználó számára javasolt tevékenységek leírása kíséri. 11.1.8.
Az EIKR felhasználói felületének figyelembe kell vennie a speciális igényű felhasználók szükségleteit, azaz a mindenkor érvényes kisegítő technológiákra vonatkozó szabványokat és útmutatókat, illetve kompatibilisnek kell lennie kisegítő szoftverekkel. A vonatkozó szabványokat és útmutatókat lásd a 7. függelékben.
11.1.9.
Az EIKR dokumentációját hasznos formátumban kell elkészíteni, azaz minél több felhasználó igényeihez és képességeihez kell igazítani. A vonatkozó szabványokat és útmutatókat lásd a 7. függelékben.
11.1.10. Az EIKR használata könnyű és intuitív legyen. A könnyű használatot tipikus csoportjával lehet felmérni.
felhasználók
egy
kiválasztott
11.1.11. Az EIKR felhasználói felületének és viselkedésének következetesnek kell lennie a rendszer különféle építőelemei (ablakok, menük és parancsok) tekintetében. A rendszer az EIKR-t futtató operációs rendszer környezetéhez is alkalmazkodjon. A szabályok kövessék alkalmazások logikáját.
a
rendszerbe
telepített
népszerű
Köt.
Teszt
11.1.12. Az EIKR-nek képesnek kell lennie egyidejűleg több iratot és iratgyűjteményt megjeleníteni.
Igen
Igen
11.1.13. Az EIKR-nek grafikus felhasználói felülettel kell rendelkeznie.
Igen
Igen
11.1.14. Az EIKR-nek lehetővé kell tennie a felhasználók számára, hogy áthelyezhessék és átméretezhessék az ablakokat, módosíthassák azok megjelenését, a változtatásokat pedig elmenthessék felhasználói profiljukba, amely minden bejelentkezésükkor automatikusan érvénybe lép.
Igen
Igen
11.1.15. Az EIKR-nek lehetővé kell tennie a felhasználók számára, hogy a grafikus felhasználói felület egyes elemeit személyre szabhassák. A személyre szabás többek között az alábbiakra vonatkozik:
Igen
Igen
11.1.16. Az EIKR-nek lehetővé kell tennie a felhasználók számára, hogy kiválaszthassák a figyelmeztető hangjelzések stílusát és hangerejét, valamint elmenthessék ezen módosításaikat felhasználói profiljukba.
Nem
Igen
11.1.17. Az EIKR-nek lehetőség szerint perzisztens (tartós) alapértelmezett értékek felkínálásával kell támogatnia az adatbevitelt. Alapértelmezés lehet:
Igen
Rész ben
Igen
Igen
Hiv.
Mintakövetelmény
a menü és az eszköztár tartalma; a képernyő elrendezése; funkcióbillentyűk használata; a képernyőn megjelenő színek, betűtípusok és betűméretek; figyelmeztető hangjelzések.
felhasználó által beállítható alapértelmezett érték; rögzített alapértelmezett érték; az előző elem értékével egyező érték; a környezetből kinyerhető érték, pl. állományhivatkozás, felhasználó azonosítója;
mai
dátum,
igény szerint egyéb kikövetkeztethető érték. 11.1.18. Az EIKR-nek személyre szabható legördülő listákkal támogatnia a metaadat-elemek értékeinek bevitelét. A legördülő listák határozhatja meg.
tartalmát
egy
adminisztrátori
kell
szerepkör
Köt.
Teszt
11.1.19. A gyakran használt EIKR tranzakciók végrehajtását a rendszernek pár lépéssel (néhány kattintással vagy billentyű-leütéssel) elérhetővé kell tennie a felhasználó számára.
Igen
Rész ben
11.1.20. Az EIKR-nek szorosan együtt kell működnie a szervezet elektronikus levelező rendszerével annak érdekében, hogy a felhasználók az EIKR-ből közvetlenül tudjanak e-mailben iratokat és iratgyűjteményeket küldeni.
Nem
Nem
Nem
Nem
Nem
Igen
Nem
Igen
Nem
Igen
Hiv.
Mintakövetelmény
A követelmény célja, hogy a felhasználónak ne kelljen az EIKR-ből kilépnie és a levelezőrendszerbe belépnie irat küldéséhez. 11.1.21. Amennyiben a rendszer eleget tesz a 11.1.20. követelménynek, az EIKR-nek iratok és iratgyűjtemények e-mailben való küldésekor lehetőleg az iratokra és iratgyűjteményekre mutató hivatkozásokat kell küldenie az objektumok helyett. Ez alól kivételt képezhet például az az eset, amikor távoli felhasználónak küldenek e-mailben iratot vagy iratgyűjteményt, aki nem rendelkezik hozzáféréssel a központi tárhelyhez. 11.1.22. Az EIKR-nek jeleznie kell, hogy rendelkezik-e csatolmánnyal egy email. Például ikon formájában. 11.1.23. Az EIKR-nek engedélyeznie kell felhasználók által programozható funkciók használatát. Például a felhasználók által írt makrókat. 11.1.24. Valahányszor a felhasználóknak nyomtatott dokumentumok képeinek (pl. beszkennelt iratok) metaadatait kell bevinniük, az EIKR-nek optikai karakterfelismerő (OCR) szolgáltatással kell támogatnia a metaadatok lehetséges értékeinek kinyerését a képből (zonális OCR). Lehetővé kell tenni például a felhasználó számára, hogy kijelölhessen egy téglalap alakú területet a képen, amely adott metaadat értékét (pl. dátum, cím) tartalmazza, majd átalakíttathassa azt a rendszerrel a megfelelő értékké és beillessze az adott mező tartalmaként egyetlen művelettel.
Köt.
Teszt
11.1.25. Az EIKR-nek lehetővé kell tennie a felhasználók számára, hogy kereszthivatkozásokkal összeköthessék a kapcsolódó iratokat akár egyazon iratgyűjteményen belül vagy különböző iratgyűjtemények között, segítve az iratok közötti könnyű navigációt.
Nem
Igen
11.1.26. Amikor a felhasználó iratokkal vagy iratgyűjteményekkel (osztályokkal, dossziékkal, aldossziékkal vagy kötetekkel) dolgozik, függetlenül attól, hogy keresés eredményeként tekinti meg azokat vagy sem, a rendszernek segítenie kell a felhasználót a hierarchiában következő magasabb szintű iratgyűjtemény adatainak megtekintésében anélkül, hogy a felhasználónak be kellene zárnia vagy ott kellene hagynia az iratot.
Nem
Igen
Nem
Igen
Nem
Igen
Hiv.
Mintakövetelmény
Irat olvasásakor például a felhasználónak könnyen meg kell találnia, hogy melyik osztályban, dossziéban, aldossziéban vagy kötetben található az irat; egy dosszié metaadatait böngészve a felhasználónak könnyen ki kell találnia, hogy melyik osztályba tartozik az adott dosszié. 11.1.27. Az EIKR-nek lehetővé kell tennie egy adott dossziéhoz vagy irathoz hozzáféréssel rendelkező felhasználó számára, hogy megállapíthassa, rendelkezik-e egy másik felhasználó, csoport vagy szerepkör hozzáféréssel ugyanahhoz az objektumhoz. Ehhez a felhasználónak explicite meg kell mondania, melyik felhasználó, csoport vagy szerepkör jogai érdeklik. Ezáltal adott iratra vagy dossziéra vonatkozóan kideríthetők egy felhasználó hozzáférési jogai a felhasználó csoportjának vagy szerepkörének ismerete nélkül. 11.1.28. Az EIKR-nek lehetővé kell tennie a felhasználók számára a téves besorolás kockázatának csökkentését ún. ideiglenes zár használatával, melyet a felhasználók egyetlen kattintással helyezhetnek el egy adott iraton vagy dosszién. Az ideiglenes zárral ellátott dossziéhoz vagy irathoz az adminisztrátori szerepkörökön kívül senki nem férhet hozzá. A rendszer automatikusan értesítést küld egy adminisztrátori szerepkörnek a zár elhelyezéséről, lehetővé téve az adminisztrátori szerepkör (és senki más) számára az ideiglenes zár feloldását. Ez a lehetőség a véletlen hibák javítását segíti, mint amikor például bizalmas iratot húznak nem megfelelően védett dossziéba. Mivel a felhasználók nem törölhetik, mozgathatják vagy módosíthatják az iratokat, egy adminisztrátori szerepkör közbeavatkozása szükséges. Az ideiglenes zár ártalmas használatának elkerülése végett a felhasználókat tájékoztatni kell azok ésszerű felhasználásáról, az adminisztrátori szerepkörök pedig rendszeresen kötelesek ellenőrizni, hogy nem élnek-e vissza a felhasználók ezen eszközzel.
Köt.
Teszt
Nem
Rész ben
Nem
Rész ben
11.1.31. Az EIKR-nek lehetővé kell tennie a felhasználók számára, hogy a súgórendszerben a „kedvenc” vagy gyakran látogatott részeket megjelölhessék, elősegítve azok gyorsabb megtalálását.
Nem
Igen
11.1.32. Egy adott dossziéval dolgozó felhasználónak könnyen és gyorsan meg kell találnia a dossziéhoz tartozó tárgyszavakat.
Igen
Igen
11.1.33. Az EIKR-nek lehetővé kell tennie a felhasználók számára, hogy osztályokat, dossziékat és iratokat „kedvencként” jelölhessenek meg, elősegítve azok gyorsabb megtalálását.
Nem
Igen
11.1.34. Az EIKR-nek lehetővé kell tennie, hogy a felhasználók elküldhessék egymásnak „kedvenceiket”.
Nem
Igen
Hiv.
Mintakövetelmény
11.1.29. Az EIKR-nek lehetővé kell tennie a felhasználók számára, hogy a rendszerből saját munkakörnyezetükbe (pl. asztali mappájukba) másolhassák az iratokat vonszolással. Eközben az irat és metaadatai változatlanok maradnak a rendszerben. Más környezetbe történő másoláskor az iratok elveszíthetik metaadataikat (figyelembe véve, hogy az EIKR-en kívüli környezet nem támogatja a MoReq2 metaadatmodellt). 11.1.30. Az EIKR súgójának vizuális útmutatással kell segítenie a felhasználókat. Például képernyőképekkel és animációkkal kell szemléltetnie a rendszer funkcióinak használatát.
A tárgyszavak kiderítéséhez a felhasználónak ne kelljen kilépnie a dossziéból, és ne kelljen megszakítania munkáját.
A kedvenceket e-mailben lehet elküldeni, vagy tetszőleges más mechanizmussal.
11.2.
Teljesítmény és skálázhatóság
Javasoljuk a MoReq2 felhasználóinak, hogy az EIKR válaszidőinek megállapításakor vegyék figyelembe a felhasználók elvárásait és a felhasználók várható számát. Az alábbiakban megadunk néhány mintaszempontot és –követelményt. A felhasználók által tapasztalt válaszidő számos, EIKR-en kívüli tényezőtől függ, beleértve az alábbiakat: hálózat sávszélessége; hálózat leterheltsége; hálózat késleltetése; a különböző szerver-erőforrások konfigurációja és kihasználtsága.
A külső körülmények részletezése a Specifikáció hatáskörén kívül esik, arra azonban felhívjuk a felhasználók figyelmét, hogy ezeket a tényezőket nem szabad figyelmen kívül hagyni. A teljesítményről általában az éles környezetben futtatott tesztek adnak megbízható képet. A fejezetben „válaszidőn” a szabványos értelemben vett fogalmat értjük, melynek pontos értelmezése környezetenként más és más az infrastruktúra állapotától függően. Adott infrastruktúrára telepített EIKR esetén célszerű lehet a válaszidőt a szerverhez beérkezett kérés és a válasz elküldése között eltelő időben meghatározni; más esetben a hálózati munkaállomásról küldött kérés és a visszaérkező válasz között eltelt idő a mérvadó. Az offline módú és távoli munkavégzésre vonatkozó követelményekkel a 10.11. szakasz foglalkozik, az alábbiakban felsorolt követelményeket megfelelőképpen kell módosítani ezen speciális esetek lefedésére. Az EIKR-nek feladatai végrehajtásában és működésében konzisztensen az üzleti és felhasználói igényekhez kell igazodnia az alábbiakban leírt mintakövetelményeknek megfelelően. Hiv.
Mintakövetelmény
11.2.1. Az EIKR-nek normál körülmények között az üzleti igényeknek megfelelő válaszidőt kell adnia szokványos feladatok esetén, például:
Köt.
Teszt
Igen
Nem
Igen
Nem
Igen
Nem
a várható felhasználók <100%-a> bejelentkezett és aktív; a rendszer a várható dokumentummennyiség <100%-át> kezeli; a felhasználók tranzakciótípusokat vegyesen végeznek különféle ütemben; a rendszer legalább teljesítményt nyújt.
tíz
tranzakción
keresztül
konzisztens
11.2.2. Az EIKR egyszerű keresések eredményét (a találati listát) legfeljebb <3 mp>, összetett (legalább négy kereső-kifejezéses) keresések eredményét legfeljebb <10 mp> alatt köteles megjeleníteni, függetlenül a tárhely kapacitásától és a rendszerben tárolt dossziék és iratok számától. Jelen esetben keresésen a találati lista visszaadását értjük (lásd 8.1.10.), az iratok kinyerése nem része a keresésnek. 11.2.3. Az EIKR-nek <4 mp>-en belül ki kell nyernie és meg kell jelenítenie azoknak az iratoknak az első oldalát, amelyekhez a legutóbbi <xx> hónapban hozzáfértek, függetlenül a tárhely kapacitásától és a rendszerben tárolt dossziék/iratok számától. Ez és a 11.2.4. követelmény csak azokra a dokumentumokra vonatkozik, amelyeket lapokra osztva lehet megjeleníteni. Szokatlanul nagyméretű dokumentumoknál eltérő válaszidő is elfogadható lehet.
Hiv.
Mintakövetelmény
Köt.
Teszt
Igen
Nem
Igen
Nem
Igen
Nem
A „legutóbbi <xx> hónapban” kifejezés szinthez kötött vagy „hierarchikus” fizikai tárolási mechanizmusra utal. Lásd még a következő követelményt. Ez a követelmény a gyakran használt iratok gyors elérését segíti, feltéve, hogy a hozzáférés gyakorisága kapcsolatba hozható a legutóbbi használattal. Az időskálát a szervezet határozza meg a gyakran használt iratok fontosságának csökkenését figyelembe véve. 11.2.4. Az EIKR-nek <20 mp>-en belül ki kell nyernie és meg kell jelenítenie azoknak az iratoknak az első oldalát, amelyekhez a legutóbbi <xx> hónapban nem fértek hozzá, függetlenül a tárhely kapacitásától és a rendszerben tárolt dossziék/iratok számától. Ez a követelmény a tárolás hierarchikus kezelését támogatja, amikor a ritkán használt iratokat az „aktív” iratokénál lassabb közegen vagy nearline tárolják. Az időskálát a szervezet határozza meg a gyakran használt iratok fontosságának csökkenését figyelembe véve. Amennyiben az elektronikus iratok tárolását egyetlen (nem szinthez kötött vagy hierarchikus) fizikai mechanizmussal oldják meg, a „legutóbbi <xx> hónapban” kifejezés ebben és az előző követelményben értelmét veszti, és törlése javasolt. 11.2.5. Az EIKR egyetlen implementációjához tartozó elektronikus irattárnak legalább <xx gigabájt/terabájt/petabájt> vagy <xx ezer/millió/milliárd> irat tárolását kell biztosítania, ezzel egyidejűleg pedig a rendszer legalább <xx száz/ezer> felhasználót köteles egyidejűleg kiszolgálni az ebben a szakaszban meghatározott teljesítményszinteknek megfelelően. A tárolás pontos követelményeit, az iratok és a felhasználók számát a szervezet határozza meg. Nagyobb szervezeteknél idővel rengeteg irat halmozódik fel, melynek mennyisége akár a milliárdos nagyságrendet is eléri. 11.2.6. Az EIKR az ebben a szakaszban ismertetett teljesítményszinteket legalább az alábbi mennyiségek esetén köteles garantálni: <xx> osztály; <xx> dosszié osztályonként; <xx> aldosszié dossziénként; <xx> kötet aldossziénként; <xx> irat kötetenként. Ezek a mérőszámok csak jelzésértékűek. A szervezeteknek kell eldönteniük, alkalmaznak-e a felsorolt metrikákon túl további mérőszámokat.
Hiv.
Mintakövetelmény
11.2.7. Az EIKR-nek szabályozott módon kiterjeszthetőnek kell lennie a szervezet növekedésének megfelelően legalább <xx száz/ezer> felhasználóig a szolgáltatások folytonosságának biztosítása mellett.
Köt.
Teszt
Igen
Nem
Igen
Nem
Igen
Nem
A követelmény célja, hogy a rendszert „rutinszerű” frissítésekkel lehessen újabb felhasználók számára elérhetővé tenni jelentősebb szolgáltatás-kiesés nélkül. 11.2.8. Az EIKR-nek támogatnia kell a fenti teljesítményszintet, beleértve a szerepkörök, felhasználók és felhasználói csoportok, biztonsági kategóriák, hozzáférési profilok, besorolási sémák, adatbázisok, megőrzési és selejtezési ütemtervek és selejtezési visszatartások karbantartását a várható szervezeti átalakulások figyelembevételével, jelentősebb rendszerleállások és adminisztrációs nehézségek nélkül (lásd még 9. fejezet). Amennyiben a teljesítményre vonatkozó követelmények szigorú szabályozás alá esnek, a szervezeti változásokat célszerű konkrét mennyiségben kifejezni. 11.2.9. Az EIKR-nek skálázhatónak kell lennie, a rendszernek ki kell tudnia szolgálni a különböző méretű szervezeti egységekből felépülő, földrajzi helyszíneken elosztott kis és nagy szervezetek igényeit egyaránt.
11.3.
A rendszer rendelkezésre állása
Számos szervezetnél az EIKR és az EDKR együttes bevezetése olyan mértékben megnöveli a felhasználók függőségét az informatikai infrastruktúrától, hogy azok rendszerleállás esetén nem tudják munkájukat folytatni. Ennél fogva javasoljuk az ilyen rendszert beszerző szervezetek számára, hogy határozzák meg előre a rendelkezésre állás felhasználói követelményeit, majd érvényesítsék azokat a beszerzés során. Az alábbiakban néhány mintakövetelményt mutatunk be.
Köt.
Teszt
11.3.1. Az EIKR-nek elérhetőnek kell lennie a felhasználók számára <xx:00> és <xx:00> között <minden nap/minden hétköznap/évente xx napon>.
Igen
Nem
11.3.2. Az EIKR tervezett rendszerleállásainak időtartama nem haladhatja meg a(z) <xx> órát .
Igen
Nem
Igen
Nem
Igen
Nem
Igen
Nem
Hiv.
Mintakövetelmény
A „rendszerleállás” meghatározása az infrastruktúrától és az architektúrától függ. Egyes környezetekben például a szerver hardverének meghibásodását az EIKR meghibásodásának tekintik, míg máshol ez az EIKR-től független hibának számít. A szervezeteknek legelőször is meg kell határozniuk a rendszerleállás pontos jelentését, melyhez kiindulásképp a következőt javasoljuk: „Az elektronikus iratkezelő rendszer leállásának tekintjük azt a helyzetet, amikor a felhasználók több mint <xx%>-a nem tudja elérni az EIKR lényeges funkcióit, továbbá a meghibásodás az EIKR valamelyik komponensének tudható be (a felhasználó munkaállomása nem számít EIKR komponensnek)”. 11.3.3. A váratlan rendszerleállások időtartama nem haladhatja meg a(z) <xx percet/órát> . Beszerzéskor érdemes meghibásodások közötti pontosítása végett.
mennyiségi bizonyítékot kérni a átlagos időtartamról a követelmény
11.3.4. A váratlan rendszerleállások száma nem haladhatja meg a(z) <xx>-et . Beszerzéskor érdemes meghibásodások közötti pontosítása végett.
mennyiségi bizonyítékot kérni a átlagos időtartamról a követelmény
11.3.5. Bármilyen szoftveres vagy hardveres meghibásodás esetén az EIKR-t vissza lehessen állítani egy ismert (az <előző napi biztonsági mentésnél> nem régebbi) állapotba a működőképes hardver rendelkezésre állásától számított <xx> órán belül.
11.4.
Műszaki szabványok
Az EIKR-nek meg kell felelnie napjaink tényleges és jogos szabványainak. Lehetőség szerint az EIKR-ben a nyílt interfészeket kell előnyben részesíteni a zártakkal szemben. Jelen Specifikáció felhasználói számára az alábbi területek szabványainak megismerése javasolt:
hardverkörnyezetek (szerverek és munkaállomások esetén egyaránt); operációs rendszer környezetek (szerverek és munkaállomások esetén egyaránt); munkaállomás (kliens) szoftverarchitektúra; felhasználói felület; relációs adatbázisok és interfészek; hálózati protokollok és hálózati operációs rendszerek; adatátviteli szabványok; alkalmazásprogramozói interfészek és fejlesztőkészletek. Amennyiben jelen Specifikációt szoftverbeszerzési szempontok meghatározásához használják, célszerű a szervezet műszaki környezetére vonatkozó részleteket rögzíteni, beleértve az EIKR interfészeinek (pl. milyen rendszerekkel kell együttműködnie, a meglévő irodai szoftverek felsorolása) és a tervezett változtatásoknak a leírását. A Specifikáció felhasználói igényeik szerint további szabványok teljesítését is elvárhatják. A Specifikációban említett szabványok felsorolását lásd a 7. függelékben. Köt.
Teszt
11.4.1. Amennyiben az EIKR egynyelvű tezauruszt használ, a tezaurusznak az ISO 2788 szabványt (magyar tezaurusz esetén az MSZ 3418 szabványt) kell követnie, amely az egynyelvű tezauruszok készítésének irányelveit foglalja össze.
Nem
Igen
11.4.2. Amennyiben az EIKR többnyelvű tezauruszt használ, a tezaurusznak az ISO 5964 szabványt kell követnie, amely a többnyelvű tezauruszok készítésének irányelveit foglalja össze.
Nem
Igen
11.4.3. Az EIKR csak általánosan elfogadott vagy teljesen dokumentált szabványnak megfelelő állományformátumot és kódolást használhat az iratok tárolásához.
Igen
Rész ben
Hiv.
Mintakövetelmény
A felhasználók pontosíthatják a szervezet elvárásait az állományok formátumával és kódolásával kapcsolatban.
11.4.4. Az EIKR-nek az MSZ ISO 8601 szabványnak (Adatelemek és adatcsere-formátumok. Információcsere. A dátumok és az időpontok ábrázolása) megfelelő formátumban kell tárolnia a dátumokat.
Nem
Igen
11.4.5. Az EIKR-nek az MSZ EN ISO 639 szabványnak (A nyelvek nevének kódjai) megfelelő formátumban kell tárolnia a nyelvek neveit.
Nem
Igen
11.4.6. Amennyiben az EIKR több nyelven vagy nem angol karakterekkel írt iratokat is kezel, támogatnia kell az ISO 10646 (Unicode) kódolást.
Igen
Igen
11.5.
Jogi és szabályozási követelmények
Az EIKR-nek meg kell felelnie a különféle jogi és szabályozási követelményeknek, melyek jellemzően régiónként és iparáganként eltérőek. A MoReq2 nem írja elő az EIKR számára a fizikai iratok kezelését, mivel arra nem minden környezetben jelentkezik igény. Amennyiben a fizikai iratok kezelésére jogi vagy egyéb szabályozási előírás vonatkozik, biztosítani kell az elektronikus és fizikai iratok integritásának és használhatóságának egységes megőrzését. Ezekkel a kérdésekkel a megfelelő szervezeti irányelvek foglalkoznak. Az alábbi követelmények nemzetenként változóak, ezért a nulladik fejezetben szerepel részletes leírásuk. A jogszabályi előírásokon túl a MoReq2 felhasználói vegyék figyelembe az adott iparág, piaci szektor stb. követelményeit is. Követelmény
Köt.
Teszt
11.5.1.
Az EIKR-nek meg kell felelnie az iratok jogi megengedhetőségére és bizonyító súlyára vonatkozó helyileg érvényes előírásoknak.
Igen
Nem
11.5.2.
Az EIKR-nek meg kell felelnie a helyileg érvényes iratkezelésre vonatkozó jogszabályoknak.
Igen
Nem
11.5.3.
Az EIKR nem tartalmazhat olyan szolgáltatást vagy funkciót, amely ellentmond a helyileg érvényes adatvédelmi törvénynek, az információs szabadság elvének és egyéb szabályoknak.
Igen
Nem
11.5.4.
Az EIKR-nek meg kell felelnie az adott iparágat, üzleti szolgáltatást vagy szektort érintő helyileg érvényes európai, nemzeti és helyi előírásoknak, irányelveknek és gyakorlatnak.
Igen
Nem
11.6.
Kiszervezett adatkezelés
Hiv.
Több szervezetnél bízzák az iratok tárolását és kezelését külső szolgáltatóra. Sok esetben az iratok már nem aktívak (vagy előhívásuk igénye elhanyagolható), ugyanakkor törvényi vagy ipari előírások hosszú távú megőrzésüket kívánják meg. Máshol alkalmazás-szolgáltatók (ASP, Application Service Provider) kezelik az aktív és archivált iratokat egyaránt. Ilyenkor a szervezetek elküldik dokumentumaikat és irataikat – számlákat, levelezést, nyomtatványokat stb. – az ASP-hez, ahol indexelik és tárolják azokat. A dokumentumok ezután interneten vagy nagy kiterjedésű hálózaton keresztül érhetők el és jeleníthetők meg.
Az elektronikus iratkezelés kiszervezésének feltétele, hogy a szolgáltató szerződésben rögzítse a jogszabályi előírásoknak, az elektronikus iratok jogi megengedhetőségének és az ügyfél által támasztott hozzáférési és rendelkezésre állási igényeknek megfelelő eljárásokat és eszközöket. A szerződésnek az alábbi kitételeket kell tartalmaznia: a szolgáltató iratkezelési gyakorlatának legalább az ügyfél számára biztosított iratkezelési színvonalat el kell érnie; az ügyfél a jövőben elérheti a szolgáltatónál tárolt iratait, miközben iratkezelése továbbra is megfelel a szervezet előírásainak és a jogi megengedhetőség követelményeinek. Az alábbi szakasz az ISO 15801 szabványból merít (lásd 7. függelék). Hiv. 11.6.1.
Követelmény
Köt.
Teszt
A szolgáltatóval szerződésben vagy szolgáltatás-szintű egyezményben (SLA, Service Level Agreement) kell rögzíteni a szolgáltatások körét.
Igen
Nem
Igen
Nem
A szolgáltatás-szintű egyezmény az ügyfél és a szolgáltató között fennálló hivatalos egyezmény, amely a szolgáltatásokat, prioritásokat, felelősségeket stb. határozza meg. 11.6.2.
Az iratok átvitelének részleteit az ügyfél és a szolgáltató között mindkét irányban pontosan dokumentálni kell. Az iratok átviteléhez kommunikációs csatorna építhető ki, amelyen naponta vagy egyéb rendszeres időközönként automatikusan továbbítják az iratokat és a dossziékat. Az ügyfél számára garantálni kell a kommunikációs csatorna biztonságosságát, az iratok érkezését nyugtázó protokollt és az esetleges ellentmondások jelentését.
11.6.3.
A szolgáltatónak az ügyfél rendelkezésére kell bocsátania az iratok és dossziék tárolását rögzítő eseménynapló másolatát.
Igen
Nem
11.6.4.
A szolgáltatónak tanúsítania kell, hogy a nála tárolt dossziékat, iratokat és a kapcsolódó metaadatokat szerkezeti, metaadatbeli és tartalmi veszteségek nélkül képes visszaküldeni az ügyfél EIKR-ébe.
Igen
Nem
11.6.5.
A szolgáltatónak lehetőséget kell biztosítania az ügyfél számára különálló iratok és dossziék átvitelére.
Igen
Nem
11.6.6.
A szolgáltatónak azonnali hozzáférést kell biztosítania a kezelt iratokhoz az ügyfél számára. A szolgáltató köteles megjeleníteni az iratot vagy elküldeni azt az ügyfélhez a szerződésben foglalt időn belül előre rögzített áron.
Igen
Nem
11.6.7.
A szolgáltatónak lehetőséget kell biztosítania az ügyfél számára, hogy az saját irodájából kikérhesse, megtekinthesse és kinyomtathassa az iratokat és a dossziékat.
Nem
Nem
Ez hálózati kapcsolat segítségével megvalósítható.
Követelmény
Köt.
Teszt
11.6.8.
A szolgáltatónak lehetőséget kell biztosítania az ügyfél számára, hogy online kérhesse az iratok és dossziék letöltését vagy átvitelét az ügyfél iratkezelő rendszere és a szolgáltató tárhelye között.
Nem
Nem
11.6.9.
Az ügyfél jelentést kérhet a szolgáltatónál tárolt iratokról, a megőrzési és selejtezési ütemtervekről stb. A szolgáltatást online formában kell az ügyfél számára biztosítani, hogy az saját irodájából kérhessen jelentéseket.
Nem
Nem
Nem
Nem
11.6.11. Az ügyfélnek ellenőriznie kell, hogy a szolgáltató által felkínált hely elfogadható és megfelel az ügyfél biztonsági elvárásainak.
Nem
Nem
11.6.12. Az ügyfélnek ellenőriznie kell, hogy a szolgáltató által használt eljárások és tárhely-kezelési folyamatok nem jelentenek nagyobb veszélyt az iratokra, mint az ügyfél saját eljárásai.
Nem
Nem
Nem
Nem
11.6.14. Az ügyfél és a szolgáltató között végbemenő minden egyes iratszállítást egy ellenőrző dokumentumnak kell kísérnie, amely az iratok és dossziék azonosítóját és számát írja le.
Nem
Nem
11.6.15. A szállításhoz igénybe vett szervezetek szolgáltatásainak meg kell felelnie az ügyfél által támasztott minőségi és megbízhatósági feltételeinek.
Nem
Nem
Hiv.
11.6.10. A 11.6.7, 11.6.8 és 11.6.9 követelmények esetén: szerződésben kell rendelkezni az átfutási vagy válaszidőről; biztonságos környezetben kell üzemeltetni a szolgáltatásokat.
A szolgáltatónak be kell mutatnia, hogy az ügyfél iratairól biztonsági másolatot készít, amelyből a rendszer meghibásodása esetén képes visszaállítani az iratokat a szerződésben rögzített időn belül. 11.6.13. Az ügyfélnek ellenőriznie kell, hogy fokozott biztonságot igénylő iratok esetén a szolgáltató alkalmazottai megbízhatóak. Előnyös, ha a szolgáltató alkalmazottai titoktartási szerződést írnak alá munkavállalásuk idejére.
11.7.
Hosszú távú megőrzés és a technológiák elavulása
Háttér Az elektronikus iratok hosszú távon háromféle technológiai kockázattal néznek szembe: az adathordozók elavulása; a hardver elavulása; a formátum elavulása.
Az alábbi szakaszok röviden kifejtik az egyes pontokat. További részletek az ISO 18492 és a kulturális hagyatékot őrző intézetek kiadványaiban olvashatók. Az adathordozók elavulása Az adathordozók elavulásának oka az adathordozók korlátozott élettartama. Ez az élettartam az adathordozó típusától és a tárolási körülményektől egyaránt függ. Az alábbi óvintézkedésekkel információvesztés kockázata:
csökkenthető
az
adathordozók
elavulásával
járó
az adathordozók tárolásának, használatának és kezelésének megfelelő környezeti feltételek biztosítása; az adathordozók rutinszerű cseréje (az adatok másolásával egy új adathordozóra) a várható élettartam lejárta előtt; egy irat több másolatának tárolása és azok rendszeres összehasonlítása. Ezt a módszert használják a hosszú távú archiválásra szakosodott iratmegőrzők; megvalósítása automatizált rendszerekkel történik, melyek részletes leírása meghaladja jelen Specifikáció kereteit. A hardver elavulása A tárolási perifériák – mágnesszalag-meghajtók, optikai lemez meghajtók – várható élettartama korlátozott. Élettartamuk végéhez közeledve vagy azt elérve egyre több karbantartást igényelnek, aminek következtében üzemeltetésük költségesebbé válik, míg végül javíthatatlanul elromlanak. Az elavult eszközökön tárolt adatok véglegesen elvesznek, ha biztonsági mentésükről nem gondoskodnak időben. A formátum elavulása A formátumok elavulása a több év után jelentkező problémák közül a legnehezebben orvosolható. A probléma oka az adathordozó és a megjelenített információ közötti „feldolgozási láncot” alkotó protokollok és szoftverkomponensek folyamatos fejlődése. Ide sorolható a kódolási szabványok, az állományformátumok és a szoftverek rohamos fejlődése is. Az új verziók nem minden esetben kompatibilisek a korábbival, különösen több éves intervallumokat tekintve. Jelenleg az alábbi technikákat alkalmazzák a formátumok elavulásának kiküszöbölésére: migráció (az adatok konvertálása újabb formátumra, amely korszerű hardverek és szoftverek segítségével hozzáférhető); emulálás (az adat másolása új hardverre egy kiegészítő szoftverkomponens kíséretében, amely a régi hardvert emulálja, ezáltal a régi alkalmazásszoftver is futtatható); a technológia megőrzése (az eredeti hardver folyamatos karbantartása; hosszú távon nem kifizetődő megoldás); az adat és a szoftver egységbe zárása (elméleti megoldás, melynek lényege, hogy az iratokat, a metaadatokat és az EIKR-t egyetlen szabványos szoftverbe „csomagoljuk”).
Jelen Specifikáció írásakor nincs egyetlen egyszerű, általános módszer, amely az elektronikus iratok hosszú távú elérhetőségét garantálná. Az alábbi pontokban azonban egyetértés született: az adatok megőrzésének legmegfelelőbb módja a széles körben elfogadott, stabil, nyílt formátumok (azaz olyan formátumok, amelyeket nyilvánosan elérhető specifikációkban teljes körűen dokumentáltak) használata, melyeket hosszú várható élettartam jellemez, például XML, PDF/A; a legbiztonságosabb megoldás a migráció, az emulálás, vagy a kettő együttes használata; a gyakorlatban azonban mindkettőnél figyelni kell a metaadatok helyes megőrzésére – lásd alább. Az alábbi követelmények az imént említett megközelítési módokat részletezik. További információforrások a 7. függelékben találhatók. Konkrét követelmények Követelmény
Köt.
Teszt
11.7.1.
Az EIKR-ben használt adathordozót a kívánt/várható élettartam eléréséhez és a gyártó előírásának megfelelő körülmények között kell használni és tárolni.
Igen
Nem
11.7.2.
Az EIKR-nek támogatnia kell az adathordozók ellenőrzését és cseréjét az adathordozók elavulásával járó problémák elkerülése végett.
Igen
Igen
Hiv.
Ennek feltétele, hogy az EIKR vagy annak a tárolással foglalkozó alrendszere rendszeres jelentéseket készítsen az adathordozón előforduló hibák arányáról, és lehetővé tegye a hibás vagy élettartamuk végéhez közeledő adathordozók cseréjét a rajtuk tárolt iratok sérülése nélkül.
Követelmény
Köt.
Teszt
11.7.3.
Az EIKR-nek képesnek kell lennie arra, hogy biztosítsa az adatmásolatok automatizált, rendszeres összehasonlítását és a hibásnak talált példányok cseréjét az adathordozók elavulásával járó problémák elkerülése végett.
Nem
Rész ben
11.7.4.
Az EIKR-nek lehetővé kell tennie az iratok (és a kapcsolódó metaadatok, illetve eseménynapló adatok) tömeges migrálását (esetleg megjelenítési formájának átalakítását) új adathordozóra és/vagy rendszerbe a formátumokra vonatkozó előírások betartása mellett.
Igen
Igen
11.7.5.
Az EIKR-beszállítónak rendszerfrissítő program segítségével kell biztosítania a meglévő adatok folyamatos elérhetőségét a tartalom megváltoztatása nélkül.
Igen
Nem
11.7.6.
A rendszer frissítése nem befolyásolhatja az EIKR-ben a szervezeti követelményeknek való megfelelés céljából végrehajtott rendszerváltoztatásokat.
Igen
Nem
11.7.7.
Az EIKR-nek jelentést kell tudnia készíteni az állományok formátumáról és a komponensek verziószámáról.
Nem
Igen
Nem
Rész ben
Nem
Rész ben
Hiv.
Az EIKR-nek például ki kell tudnia listázni az adott állományformátumban tárolt komponenseket. Ezt a szolgáltatást egy szoftver- vagy megőrzésfigyelő funkcióval együtt érdemes használni, melynek célja az elavulás-közeli formátumok azonosítása. 11.7.8.
Az EIKR-nek át kell tudnia alakítani (lásd Szószedet) az iratokat eredeti formátumaikból egy meghatározott, hosszú távú megőrzést támogató állományformátumba az irat iktatásakor, exportálásakor, vagy egy későbbi időpontban. A megjelenítési forma átalakítása egy EIKR-en kívüli programmal is elvégezhető, feltéve, hogy az megőrzi az iratok környezetét és a közöttük lévő kapcsolatokat.
11.7.9.
Amennyiben az irat integritását nem sérti, az EIKR-nek át kell tudnia alakítani (lásd Szószedet) az iratokat eredeti formátumaikból egy meghatározott, hosszú távú megőrzést támogató állományformátumba az irat iktatásakor, exportálásakor, vagy egy későbbi időpontban. A megjelenítési forma átalakítása egy EIKR-en kívüli programmal is elvégezhető, feltéve, hogy az megőrzi az iratok környezetét és a közöttük lévő kapcsolatokat.
Köt.
Teszt
11.7.10. Iratok és állományok megjelenítési formájának átalakításakor az EIKR-nek lehetővé kell tennie az átalakítást végző adminisztrátor számára, hogy megindokolja az átalakítást.
Igen
Igen
11.7.11. Miután az iratot átalakították egy hosszú távú megőrzést támogató formátumba, az EIKR-nek lehetőséget kell biztosítania az irat eredeti formátumban vagy az átalakított megjelenítési formában való megjelenítésére, értelemszerűen.
Igen
Rész ben
Hiv.
Követelmény Amennyiben az irat több állományból tevődik össze, fontos, hogy az irat integritása fennmaradjon. Ennek megvalósíthatósága egyaránt függ az átalakítási folyamat és az irat megjelenítéséhez használt alkalmazás képességeitől. Ha például az irat egy GIF-képeket is tartalmazó weboldal, a GIF-képek megjelenítési formája csak akkor alakítható át, ha az alábbi feltételek mindegyike teljesül: a GIF-állományokat olyan állományformátumba alakítják át, amelyet a weboldal eléréséhez használt alkalmazás meg tud jeleníteni; ebben a példában a JPEG-formátum elképzelhető; a GIF-képekre történő hivatkozásokat a weboldalban átírják az új JPEG-képekre való hivatkozásokra a migráció részeként;
az eredeti állományokat (a módosítatlan weboldalakat és a nem átalakított GIF-állományokat) is megőrzik az új állományok mellett. Az EIKR-nek mindhárom tevékenységet támogatnia kell, lehetőleg automatikusan. A példa csak az illusztrációt szolgálja; jelen Specifikáció írásakor a GIF-képek migrációját semmi nem indokolja.
Lásd még 5.2.3.
Köt.
Teszt
11.7.12. Az EIKR-nek tudnia kell exportálni az iratokat metaadataikkal együtt kibocsátott információs csomag (Dissemination Information Package) formájában, meghatározását lásd az ISO 14721 OAIS szabvány 7. függelékében.
Nem
Igen
11.7.13. Az EIKR-nek legalább az alábbi metaadat-elemeket kell eltárolnia az átalakított megjelenítési formájú állományok esetén:
Nem
Igen
Nem
Rész ben
Igen
Igen
Nem
Rész ben
Nem
Nem
Hiv.
Követelmény
az állomány eredeti formátuma és verziószáma; az átalakítás időpontja. 11.7.14. Az EIKR-nek ki kell tudnia nyerni és metaadatként eltárolni az állományok technikai metaadatait. Ezek a metaadatok nem szerepelnek a MoReq2 metaadatmodellben. Ide tartoznak például képek esetén az olyan technikai paraméterek, mint a kép formátuma (pl. TIFF v6), hossza, szélessége stb. 11.7.15. Az EIKR kizárólag olyan zárt kódolást, tárolást vagy adatbázisstruktúrát használhat, melynek teljes körű dokumentációja elérhető az adminisztrátori szerepkörök számára. Ebből következik, hogy a beszállító nem tarthatja vissza a dokumentációt, mivel a megőrzési idők hosszát tekintve a beszállító elérhetősége nem garantált. Ajánlatos tehát, hogy a beszállító a felhasználó szervezet vagy egy semleges fél részére elérhetővé tegye a dokumentáció egy példányát. 11.7.16. Az EIKR-nek tudnia kell különféle, hosszú távú megőrzésre vonatkozó metaadat-elemeket kezelni az iratokhoz és az állományokhoz kapcsolódóan. Lásd 9. függelék. 11.7.17. Az EIKR-nek vagy nyílt forráskódúnak kell lennie, vagy a forráskódot letétbe kell helyezni egy semleges harmadik félnél.
11.8.
Üzleti folyamatok
Tapasztalatok szerint az elektronikus iratkezelő rendszerek sikere nagymértékben függ attól, hogy a rendszer mennyire tükrözi az emberek hétköznapi munkavégzési szokásait. Egy iratés dokumentumkezelő szolgáltatások teljes körével felszerelt rendszer csak akkor lehet sikeres, ha a felhasználók könnyűnek találják a használatát. A felhasználók el fogják utasítani a nehezen kezelhető, ámbár jó szolgáltatásokat nyújtó EIKR-t. Ennek tudatában ez a szakasz a rugalmasságot és könnyű használatot támogató követelményeket részletezi. A követelmények jellegéből adódóan többségük javasolt, de nem kötelező. A követelmények teljesíthetők egy munkafolyamat-kezelő szoftver integrálásával is.
Néhány követelmény szövege a „folyamat integrált részeként” kifejezést tartalmazza. Ez annyit tesz, hogy egy adott folyamatot végző felhasználó számára biztosítani kell a lehetőséget, hogy végrehajtsa a folyamatot vagy félbeszakítsa azt; lehetővé kell tenni, hogy a funkciót könnyen, lehetőség szerint egyetlen kattintással elérhesse, a korábban megadott adatok ismételt bevitele nélkül; a funkció befejezése előtt választási lehetőséget kell adni, hogy megszakíthassa az eredeti folyamatot, vagy visszatérhessen ahhoz a ponthoz és állapothoz, ahol a funkciót meghívta (a korábban megadott adatok ismételt bevitele nélkül). Ezt szemlélteti a 11.1. ábra. Felhasználó folyamatot indít Folyamat 1. lépése Folyamat 2. lépése
stb.
Felh. funkciót választ
IGEN
NEM
IGEN
Funkció
Felhasználó folytatja
Folyamat n. lépése Folyamat n+1. lépése stb.
NEM
Folyamat megszakítva
Folyamat kész
11.1. ábra Az alábbiakban felsorolt követelmények függetlenek a felhasználók jogosultságaitól.
Követelmény
Köt.
Teszt
11.8.1.
Az EIKR-nek lehetővé kell tennie az iratok, dossziék vagy osztályok biztonsági kategóriájának megváltoztatására jogosult felhasználó számára az irat, dosszié vagy osztály aktuális kategóriájának és a rá vonatkozó engedélyeknek a megtekintését a módosítási folyamat integrált részeként.
Nem
Igen
11.8.2.
Amikor egy adminisztrátori szerepkör értesül egy irat biztonsági kategória-szintjének a csökkentéséről (lásd 10.13.28), az adminisztrátori szerepkörnek meg kell tudnia vizsgálni az iratot és annak metaadatait a folyamat integrált részeként.
Nem
Igen
11.8.3.
Valahányszor a felhasználó olyan dossziét, aldossziét vagy kötetet hoz létre, amelynek létezik fizikai megfelelője a valóságban, a rendszernek lehetőséget kell biztosítania megfelelő címke nyomtatására a fizikai tárolóra a folyamat integrált részeként.
Nem
Igen
Hiv.
Ezáltal könnyen készíthető a tároló lényeges metaadatait tartalmazó címke. A címkén az alábbi metaadatok értéke szerepelhet: Cím (Title); Rendszerazonosító (System Identifier); Besorolási kód (Classification Code); Megnyitás napja (Date of Opening); Biztonsági érvényes;
kategória
(Security
Category),
Tárolás helye (Normal storage location).
amennyiben
Követelmény
Köt.
Teszt
11.8.4.
Valahányszor a rendszer adattörléskor hivatkozási kapcsolatokra figyelmezteti a felhasználót (lásd 9.3. szakasz), a felhasználónak meg kell tudnia vizsgálni a hivatkozásokat és a hivatkozott adatokat vagy azok metaadatait a folyamat integrált részeként.
Nem
Igen
11.8.5.
Az EIKR-nek lehetővé kell tennie az iratot maszkoló felhasználó számára az alábbi tevékenységek végrehajtását egyetlen integrált folyamatban:
Nem
Igen
Nem
Igen
Hiv.
maszkolás készítése; a maszkolás helyének meghatározása a besorolási sémában, és a maszkolt másolat irattá nyilvánítása; kereszthivatkozás készítése a maszkolt másolat és az eredeti irat között. kereszthivatkozás készítése az eredeti irat és a maszkolt másolat között. 11.8.6.
Irattá nyilvánításkor az EIKR-nek lehetővé kell tennie a felhasználó számára, hogy a folyamat integrált részeként ellenőrizhesse, nem nyilvánították-e korábban irattá az adott dokumentumot. Ez tetszőleges típusú dokumentumra vonatkozik.
Követelmény
Köt.
Teszt
11.8.7.
Az EIKR-nek figyelmeztetnie kell a dokumentumot irattá nyilvánító felhasználót, ha az adott dokumentumot korábban már irattá nyilvánították; a rendszernek tájékoztatnia kell a felhasználót az irat helyéről (melyik osztályba, dossziéba stb. sorolták), és fel kell kínálnia a felhasználó számára a lehetőséget, hogy folytassa az iktatást, vagy félbeszakítsa a folyamatot.
Nem
Igen
11.8.8.
Az EIKR-nek lehetővé kell tennie iktatáskor a felhasználó számára, hogy:
Nem
Igen
Nem
Igen
Nem
Igen
Hiv.
böngészhesse a besorolási meghatározásához);
sémát
(az
irat
helyének
megnézhesse tetszőleges osztály és dosszié metaadatait (engedélyek, tárgyszavak, leírások stb.); az iktatás befejezése előtt a folyamat integrált részeként. 11.8.9.
Valahányszor egy osztály, dosszié, irat stb. jelenik meg a képernyőn egy keresés eredményeként, a besorolási séma böngészése közben, vagy bármilyen más kontextusban, az EIKRnek lehetővé kell tennie bármilyen érvényes tevékenység végrehajtását azon az aktuális képernyő elhagyása nélkül, beleértve legalább az alábbi tevékenységeket: megnyitás; a szülők meghatározása a besorolási sémában; a metaadatok vagy az eseménynapló megtekintése; a kapcsolódó hivatkozások megtekintése és követése; küldés e-mailben; a biztonsági kategória módosítása; a hozzáféréssel rendelkező felhasználók és szerepkörök megtekintése; nyomtatás (vagy megjelenítés); maszkolás; áthelyezés vagy törlés.
11.8.10. Az EIKR-nek lehetővé kell tennie egy jogosult felhasználó számára az iratok, dossziék és osztályok biztonsági kategóriájának módosítását az érintett metaadatelem értékek frissítésével egyetlen folyamatban.
Hiv.
Követelmény
11.8.11. Amennyiben a rendszer integráltan tartalmaz ISO 2788 (MSZ 3428) vagy ISO 5964 kompatibilis tezauruszt, az EIKR-nek lehetővé kell tennie a felhasználó számára, hogy tárgyszavak (vagy egyéb metaadat-elemek értékének) bevitelekor kihasználhassa a tezaurusz összes szolgáltatását (pl. tágabb, szűkebb értelmű, kapcsolódó kifejezések, szinonimák keresése) a folyamat integrált részeként. Megjegyzés. A 8.1.18. követelmény hasonló elvárásokat támaszt a kereséssel szemben.
Köt.
Teszt
Nem
Igen
12.
METAADAT-KÖVETELMÉNYEK
Ez a fejezet a metaadatok kezelésére vonatkozó funkcionális követelményeket tartalmazza. A MoReq2 metaadatok „modelljét” a 9. függelék mutatja be. A 12.1. szakasz a metaadatok kezelésének alapelveit, a 12.2. szakasz pedig az általános követelményeket ismerteti. Jelen Specifikáció metaadatnak tekinti az indexelési adatokat és egyéb, a hatékony iratkezeléshez szükséges adatokat, valamint a hozzáférési jogok és korlátozások információit. A metaadatok formális leírását lásd a Szószedetben. Az ISO 23081 (lásd 7. függelék) szabvány részletesen foglalkozik a metaadatok szerepével az iratkezelésben.
12.1.
Alapelvek
Hatáskör Képtelenség pontosan meghatározni az összes lehetséges EIKR-implementációban használt összes lehetséges metaadat kezelésére vonatkozó követelményeket. Az egyes szervezetek és alkalmazások sajátos igényei és hagyományai jelentős eltérést mutatnak. Van olyan szervezet, ahol az indexelés főként a felhasználói fiókokra és a tranzakciók időpontjára irányul, másutt szigorúan hierarchikus számozást használnak; lesznek, akik köteteket nyitnak minden új gazdasági évben; sokan meg biztonsági okokból vagy a szellemi tulajdonjog szempontjából korlátozzák a felhasználók jogosultságait, és így tovább. Ezért a MoReq2 csak a legalapvetőbb követelményeket írja le, melyek a felhasználói igények kielégítésének és a bővítésnek szilárd kiindulási alapot adnak. A követelmények szoros kapcsolatban állnak az EIKR által kezelt metaadat-elemekkel, melyek összefoglalását a 9. függelék tartalmazza.
12.2. Hiv. 12.2.1.
Általános metaadat-követelmények Követelmény
Köt.
Teszt
Az EIKR nem szabhat gyakorlati korlátot a különféle egyedekhez (pl. osztály, dosszié, aldosszié, kötet, irat) kapcsolódó metaadatelemek számának.
Igen
Rész ben
Igen
Rész ben
A „gyakorlati korlát” meghatározása alkalmazásonként változik. Azokban a szervezetekben például, amelyek egyszerű besorolási sémát használnak, kevesebb metaadatelem szükséges, mint az összetett besorolási sémát használó szervezetekben. 12.2.2.
Amennyiben a metaadat-elemek tartalma kapcsolatba hozható az EIKR valamelyik műveletével, az EIKR-nek fel kell használnia az adott elem tartalmát a művelet meghatározásához. Ha például az EIKR eltárolja a dossziék megnyitásának dátumát, az arra vonatkozó metaadat-elemet automatikusan ki kell töltenie a dosszié megnyitásakor ahelyett, hogy a felhasználótól várná a hiányzó érték bevitelét. Megjegyzés. Ez az általános követelmény számos metaadat-elemre érvényes, a MoReq2 nem kíséreli meg az összes lehetséges eset felsorolását.
Hiv. 12.2.3.
Követelmény
Köt.
Teszt
Az EIKR-nek a rendszer konfigurálásakor lehetővé kell tennie a metaadat-elemek irattípusonként változó csoportjainak kijelölését.
Igen
Igen
Például: számláknál metaadat lehet a számlaszám; a levelezések tárolásához elemekre van szükség;
többértékű
címzett
metaadat-
beszkennelt iratok esetén a metaadatok leírják a szkennelési és indexelési folyamat részleteit. 12.2.4.
Az EIKR-nek lehetővé kell tennie a rendszer konfigurálásakor egy adminisztrátori szerepkör számára, hogy az egyes metaadatelemeket kötelező vagy opcionális jellegűnek nyilváníthassa.
Igen
Igen
12.2.5.
Az EIKR-nek legalább az alábbi metaadatelem formátumokat kell támogatnia:
Igen
Igen
Nem
Igen
alfabetikus; alfanumerikus; szám; dátum; logikai (azaz IGEN/NEM, IGAZ/HAMIS). 12.2.6.
Az EIKR-nek támogatnia kell a metaadat-elemek 12.2.5. pontban felsorolt formátumok kombinációjából előállítható formátumait, melyeket adminisztrátori szerepkörök hozhatnak létre. Hivatkozási számot megadhatunk például nnnnn/aa-n formában.
12.2.7.
Az EIKR-nek dátumkezelés esetén támogatnia kell az ISO 8601 szabványban meghatározott dátumformátumokat.
Igen
Igen
12.2.8.
Az EIKR-nek a rendszer konfigurálásakor lehetővé kell tennie az egyes metaadat-elemek forrásának meghatározását.
Nem
Igen
A lehetséges forrásokat a 12.2.9, 12.2.10, 12.2.11 és 12.2.13 követelmények írják le.
Követelmény
Köt.
Teszt
12.2.9.
Az EIKR-nek lehetővé kell tennie egy adminisztrátori szerepkör számára, hogy meghatározhassa, mely metaadat-elemek értékét kell manuálisan vagy kötött szótár felhasználásával bevinni és karbantartani.
Igen
Igen
12.2.10.
Az EIKR-nek engedélyeznie kell a metaadat-elemek értékének automatikus öröklését alapértelmezés szerint a besorolási sémában következő magasabb szinttől.
Nem
Igen
Nem
Igen
Hiv.
Egy kötet metaadatainak jelentős része a szülő aldosszié metaadatainak értékét örökli, az iratok metaadatainak értéke pedig az iratot tároló kötet metaadataiból vezethető le. 12.2.11.
Az EIKR-nek lehetőséget kell biztosítania a metaadatok értékének kinyerésére egy keresőtáblából vagy egy másik szoftveralkalmazásból. Az EIKR elküldheti például a felhasználó nevét és irányítószámát a rendszerbe integrált címkezelő alkalmazásnak, amely metaadatként felhasználható utcanevet küld vissza.
Követelmény
Köt.
Teszt
12.2.12.
Amennyiben a metaadat-elemek értéke keresőtáblákból származik, ha az első érték kiválasztása leszűkíti a többi elem lehetséges értékeinek kiválasztását a további táblákból, a rendszernek egyértelművé kell tennie a korlátozást a felhasználó előtt a további táblák megjelenítésekor.
Nem
Igen
12.2.13.
Az EIKR-nek az alábbiakból kell tudnia metaadatokat kinyerni:
Nem
Igen
Igen
Igen
Hiv.
dokumentumkészítésre alkalmas szoftver (lásd 6.1.12); operációs rendszer; hálózati szoftver; az iktatást végző felhasználó; az EIKR által iktatáskor automatikusan előállított metaadatok generálását leíró, a rendszer konfigurálásakor meghatározott szabályok. 12.2.14.
Az EIKR-nek képesnek kell lennie a metaadatok validálására azok bevitele vagy importálása során. Validáláskor legalább az alábbi szempontokat kell figyelembe venni: az elemek tartalmának formátuma; értékhatárok; validálás egy adminisztrátori szerepkör által karbantartott lista felhasználásával. A formátum validálásakor azt kell ellenőrizni, hogy a tartalmat a megfelelő szám, dátum stb. formában adták-e meg (a 12.2.5. követelménnyel összhangban). Az értékhatárok ellenőrzésekor például megvizsgálható, hogy a tartalom 1999. január 1. és 2001. december 31. közé esik. Listával történő validálásra példa, ha exportáláskor a rendszer ellenőrzi, hogy szerepel-e egy adott listán az exportálás helye.
12.2.15.
Az EIKR-nek képesnek kell lennie a metaadatok validálására más alkalmazások (az EIKR ellenőrizheti például, hogy kiosztottak-e egy sorszámot a személyzeti nyilvántartó rendszerben, vagy ellenőrizheti az irányítószámot egy erre a célra használható adatbázisban) vagy belső keresőtáblák igénybevételével.
Igen
Igen
12.2.16.
Az EIKR-nek lehetővé kell tennie egy adminisztrátori szerepkör számára, hogy minden egyes metaadat-elemre külön validálást (a 12.2.14. és 12.2.15. pontoknak megfelelően) írhasson elő.
Igen
Igen
A különböző metaadat-elemekre különböző validálási szabályok vonatkoznak. Dátumok esetén például tipikusan a formátumot és az értékhatárokat kell ellenőrizni; a leírásokat nem szokás validálni.
Hiv. 12.2.17.
Követelmény
Köt.
Teszt
Manuális bevitt metaadat-elemek értékei esetén az EIKR-nek lehetővé kell tennie egy adminisztrátori szerepkör számára, hogy az elem konfigurálásakor az alábbi adatbeviteli módokat lehessen kiválasztani:
Nem
Igen
perzisztens, felhasználó által meghatározott tartós értékek; rögzített alapértelmezett érték; aktuális dátum (csak dátum elemeknél); üres elem. A fenti listában felsorolt beviteli módokon kívül a rendszer további módokat is támogathat. Adatbevitelnél alapértelmezésként a rögzített alapértelmezett érték jelenik meg egy adott elem mezőjében, amíg az alapértelmezést a felhasználó meg nem változtatja. A módosítást követően az új érték marad tartósan, azaz perzisztenssé válik. A perzisztencia időtartama legalább a felhasználói munkamenet időtartama, ideális esetben a rendszer két munkamenet között is megőrzi az értéket. Ez minden olyan egyedre vonatkozik, amelyhez metaadat-értéket rendelhetnek a felhasználók. 12.2.18.
Az EIKR-nek lehetővé kell tennie, hogy a konfiguráció során tetszőleges metaadatelem értékét fel lehessen tüntetni keresőmezőként szabadszavas keresésnél.
Nem
Igen
12.2.19.
Dátum formátumban tárolt metaadat-elemek esetén az EIKR-nek lehetővé kell tennie olyan keresések végrehajtását, amelyek figyelembe veszik a dátum értékét.
Nem
Igen
Az EIKR-nek támogatnia kell például az időintervallumokban történő keresést. A dátum tárolása szövegként nem megfelelő. 12.2.20.
Számformátumban tárolt metaadat-elemek esetén az EIKR-nek lehetővé kell tennie olyan keresések végrehajtását, amelyek figyelembe veszik a szám értékét.
Nem
Igen
12.2.21.
Az EIKR-nek lehetővé kell tennie adminisztrátori szerepkörök számára, hogy a hozzáférés-szabályozó modellel (13.4. szakasz) összhangban korlátozhassák a metaadatok értékének módosíthatóságát.
Igen
Igen
12.2.22.
Az EIKR-nek lehetővé kell tennie egy adminisztrátori szerepkör számára az EIKR metaadat-modelljének átkonfigurálását, és jeleznie kell azt az eseménynaplóban.
Igen
Rész ben
Elképzelhető például, hogy vállalti átszervezés után bizonyos dokumentumtípusoknál felmerül az igény egy részlegazonosító metaadat felvételére.
Követelmény
Köt.
Teszt
12.2.23.
Az EIKR-nek biztosítania kell olyan konfigurációs beállítást, amellyel megakadályozható, hogy a felhasználók a külső alkalmazáscsomagokból, az operációs rendszerből vagy az EIKRből származó értékeket (pl. e-mail átvitelének adatait) iktatás után módosíthassák.
Igen
Igen
12.2.24.
Az EIKR-nek biztosítania kell olyan konfigurációs beállítást, amellyel megakadályozható, hogy a felhasználók a metaadat-elemek értékeit (pl. elektronikus levél átviteli adatait) iktatás után módosíthassák.
Igen
Igen
Hiv.
13.
HIVATKOZÁSI MODELL
Ez a fejezet a MoReq2 más részein felsorolt követelmények hivatkozási modelljét ismerteti. A fejezet az alábbi szakaszokból áll: Szószedet (13.1. szakasz); egyed-kapcsolat modell (13.2. szakasz); az egyed-kapcsolat modell kifejtése (13.3. szakasz); hozzáférés-szabályozási modell (13.4. szakasz).
13.1.
Szószedet
A szószedet a MoReq2 kulcsfontosságú kifejezéseinek gyűjteménye. Néhány fontos meghatározást az 1. függelékben ismertetett publikációk szószedeteiből vettünk át, esetenként némi módosítással. A forrásokat minden esetben feltüntettük. A szószedetben definiált kifejezéseket dőlt betűk mutatják. adminisztrátor A szervezeti iratkezelési szabályok mindennapi működtetéséért felelős szerepkör. Megjegyzés: a kifejezés kényelmi egyszerűsítés. A MoReq2-ben adminisztrátori feladatként feltüntetett tevékenységek többsége nagyobb szervezeteknél több szerepkör (Iratkezelő, Levéltáros stb.) között oszlik meg. adminisztrátori szerepkör Adminisztratív tevékenységek elvégzésére jogosult felhasználókhoz rendelt funkcionális engedélyek. Megjegyzés: a MoReq2-ben ugyanez a kifejezés jelöli az adminisztrátori szerepkörrel rendelkező személyeket is. aldosszié Egy dosszié logikai felosztása során keletkező kisebb egység. Megjegyzés: Az aldossziék használata nagyon gyakori az ügyiratkezelésben (kézi rendszerekben használják az ügyiratdarab kifejezést is). Az aldossziék általában névvel rendelkező egységek, és a dosszié iratainak meghatározott szempont szerint kiválasztott csoportját foglalják össze, például „számlák”, „értékelések”, „levelezés”. állomány Az iratot vagy dokumentumot alkotó elkülöníthető bitfolyam, vagy bitfolyamok egy csoportja. Szinonimája a fájl.
Megjegyzés: „Elkülöníthető bitfolyamon” az információtechnológiában alapfogalomnak számító fájl, magyarul állomány értendő. Egy irat több állományból épülhet fel, melyek akár külön is kezelhetők. Megjegyzés: példa állományra: weboldalt alkotó HTML-dokumentum és a hozzá tartozó JPEG-képek; olyan szövegszerkesztővel készített dokumentumból álló irat, mely (adott esetben) táblázat(ok)ra mutató, szövegbe ágyazott csatolóugrásokat (hiperhivatkozásokat) is tartalmaz. Megjegyzés: Az állományok pontosan elkülöníthetők egymástól. Amennyiben a szövegszerkesztővel készített dokumentum tartalmazza a beágyazott táblázatot (szemben azzal az esettel, amikor csak hivatkozik arra), a táblázat nem tekinthető önálló állománynak. Ilyenkor úgy vesszük, hogy az irat egyetlen állományból áll, mégpedig a beágyazott táblázatot tartalmazó, szövegszerkesztővel készített dokumentumból. Megjegyzés: Az e-mail és csatolmányai kezelhetők egyetlen állományként, állományként, vagy több iratként, attól függően, hogy milyen formátumban tárolják.
több
Ha az e-mail az üzenet törzsét a csatolmányokkal közös formátumban tárolja, akkor egyetlen állományból álló iratról beszélhetünk. Ha az e-mail a mellékleteket külön tárolja, azokat pedig az üzenet törzséből hivatkozza, akkor az irat az üzenet törzsét képviselő állományból és a mellékletekből mint külön állományokból áll. Ha az e-mail üzenetének törzsét és a csatolmányokat külön-külön állományokban tárolják, de ezek között nincs áthivatkozás, akkor az állományok különálló iratokként kezelendők. A bevált iratkezelési gyakorlatból az következik, hogy ilyen esetben manuálisan kapcsoljuk egymáshoz az iratokat. állományformátum Az iratok vagy állományok belső szerkezete és/vagy kódolása, amely lehetővé teszi az irat vagy állomány megjelenítését emberek számára értelmezhető formában. Megjegyzés: példák állományformátumra: HTML v3.2 (weboldalak formátuma); PDF/A v1 (hordozható dokumentumok archív formátuma); TXT (egyszerű, ASCII-kódolású szöveges állomány formátuma); XML v1.0 (a kiterjeszthető leíró nyelv formátuma, az ASCII szöveges formátumot veszi alapul); az asztali alkalmazások jelentős része (pl. irodai alkalmazások) zárt állományformátumot használ. áthelyezés Teljes elektronikus dossziék és az azokhoz tartozó metaadatok átvitele másik rendszerbe.
Forrás: A PRO Funkcionális specifikáció (Functional Specification) alapján (lásd 1. függelék). Megjegyzés: egyes dossziék áthelyezése gyakran a besorolási séma adott osztályában lévő összes többi dosszié áthelyezésével együtt történik, amennyiben az áthelyezés a tartós megőrzést szolgálja. Megjegyzés: lásd még exportálás. besorolás Az üzleti tevékenységek és az iratok, dossziék módszeres beazonosítása és elrendezése a besorolási séma egy kiválasztott osztályába a megállapodásoknak és eljárási szabályoknak megfelelően. Forrás: ISO 15489, 2006/24 (lásd 7. függelék). besorolási kód A besorolási séma minden osztályához tartozik egy azonosító, amely egyedi (elsődleges) a szülőosztályba tartozó osztályokon belül. besorolási séma Az osztályok, dossziék, aldossziék, kötetek és iratok besorolását, osztályozását lehetővé tevő hierarchikus, egymástól függetlenül kialakítható kategória-struktúra. biztonsági kategória Az irathoz vagy iratgyűjteményhez rendelt egy vagy több kifejezés, amely meghatározza az érintett iratra vagy iratgyűjteményre érvényes hozzáférési szabályokat. Megjegyzés: a biztonsági kategóriákat általában szervezeti vagy nemzeti szinten jelölik ki. Az európai szervezeteknél elterjedt biztonsági kategóriák például a „Szigorúan titkos”, „Titkos”, „Bizalmas”, „Besoroláson kívüli”. Ezeket néha még olyasféle kategóriákkal egészítik ki, mint „Csak WEU részre” vagy „Személyi állomány”. Megjegyzés: ez a kifejezés nem általánosan elterjedt. A biztonsági kérdésekkel foglalkozó szakmai közösségekben a „biztonsági besorolás” kifejezést használják, a MoReq2 azonban külön kifejezést vezet be, hogy ne lehessen összetéveszteni a besorolási séma osztályfogalmával, és ezáltal az iratkezelési értelemben vett tartalmi osztályozással, a besorolással. csonk Lásd metaadat csonk. csoport Felhasználók egy halmaza. Megjegyzés: a csoport azonos vagy eltérő szerepkörrel rendelkező felhasználókból állhat. Csoportok segítségével kijelölhető, hogy a felhasználók melyik szervezeti egységhez, például részleghez tartoznak (ebben az esetben a csoportba különböző szerepkörökkel rendelkező felhasználók kerülnek); a csoportok virtuális csapatokba (munkacsoportokba) foghatják az azonos tevékenységeket végző, de különböző egységekhez, esetleg szervezetekhez tartozó felhasználókat (ebben az esetben a felhasználók ugyanazzal a
szerepkörrel rendelkeznek); természetesen a csoportok számos egyéb felhasználása is elképzelhető. digitális Elkülöníthető számjegyekből vagy numerikus értékekből felépülő adat. Megjegyzés: A MoReq2 az iratokat illeti ezzel a jelzővel. Bár a „digitális irat” kifejezés pontosabb, mint az „elektronikus irat” kifejezés, előbbit ritkán használják a gyakorlatban. Lásd még elektronikus. dokumentum Egyedi egységként kezelhető rögzített információ vagy objektum. Forrás: ISO 15489, 2006/24 (lásd 7. függelék). Megjegyzés: A dokumentum lehet papíron, mikroformán, mágneses vagy egyéb elektronikus adathordozón rögzítve. Szövegek, adatok, ábrák, hangok, mozgóképek és egyéb formátumú információk tetszőleges kombinációit tartalmazhatja. A dokumentum egy vagy több állományból állhat. Megjegyzés: A dokumentumok számos lényeges szempontból különböznek az iratoktól. Dokumentumon olyan információt értünk, amely nem került iktatásra iratként, tehát nincs besorolva, rögzítve és tartalmát nem zárolták. A „rögzítés” fenti definícióban szereplő fogalma nem függ össze az iktatással, azaz nem iratra vonatkozik. Idővel természetesen előfordulhat, hogy egy dokumentumot irattá nyilvánítanak, miután átesik az iktatáson. dokumentumtípus Hasonló tulajdonságú dokumentumok. Megjegyzés: a dokumentumok tulajdonságai közül az elrendezés, a tartalom, a megőrzési és selejtezési követelmények, valamint a metaadatok hasonlósága számít. Példák dokumentumtípusra: űrlapok; levelezés (levelek, faxok, emlékeztetők); szakmai önéletrajz; e-mail; számla; lelet; weboldal. Megjegyzés: példánkban azért különítjük el az elektronikus leveleket a levelezés többi formájától, mert más metaadat-követelmények vonatkoznak rájuk; ez azonban nem minden szervezetnél teljesül.
Megjegyzés: a szervezeteknek meg kell határozniuk dokumentumtípusaikat üzleti igényeik alapján; a fenti felsorolás pusztán tájékoztató jellegű. dosszié Egyazon tárgyhoz, tevékenységhez vagy tranzakcióhoz kapcsolódó iratok szervezett egysége. Forrás: az ISAD(G) alapján (lásd 7. függelék). EDKR Elektronikus dokumentumkezelő rendszer. Az elektronikus dokumentumok teljes életciklusát támogató számítógépes alkalmazás. Forrás: IEC 82045-1 Document Management (a Nemzetközi Elektrotechnikai Bizottságnak az ISO-val közösen kiadott szabványa az elektronikus dokumentumkezelésről). Megjegyzés: ez a Specifikáció nem részletezi az elektronikus dokumentumkezelő rendszerekkel szemben támasztott követelményeket. EDKR-eket gyakran integrálnak EIKR megoldásokba. Részletekért lásd a 10.3. szakaszt. EIKR Elektronikus iratkezelő rendszer. Megjegyzés: Az EIKR-ek és az EDKR-ek között lényegi eltérések vannak, ezeket a 10.3. szakasz foglalja össze. elektronikus Jelen Specifikáció igényeihez mérten az „elektronikus” kifejezés jelentése megegyezik a „digitális” jelentésével. Megjegyzés: a MoReq2 keretein belül nem tekintjük elektronikusnak az analóg felvételeket, mert nem tárolhatók számítógépes rendszerben, digitális formában. Jelen Specifikáció értelmében tehát az analóg iratok nem elektronikus, hanem fizikai iratok. elektronikus dokumentum Elektronikus formában tárolt dokumentum. Megjegyzés: nem csak a szövegszerkesztővel készített szöveges dokumentumok tekinthetők elektronikus dokumentumnak, hanem az e-mailek, táblázatok, képek, HTML/XML dokumentumok, multimédiás dokumentumok és egyéb, irodai dokumentumok is. elektronikus irat Elektronikus formában tárolt irat. Megjegyzés: Elektronikus iratnak tekinthetők a szoftverekkel készített iratok, illetve a digitalizált, például beszkennelt – eredetileg papíralapú – iratok.
eseménynapló Egyedek (pl. metaadat-elemek) változtatásával járó tranzakciókról és egyéb tevékenységekről a korábbi események rekonstruálására alkalmas részletességben nyilvántartott adatok. Megjegyzés: az eseménynapló rendszerint egy vagy több listát jelent, vagy olyan adatbázist, amely megtekinthető lista formájában. A listákat számítógépes rendszerekkel (számítógépes rendszerek közötti tranzakciók esetén) vagy manuálisan állítják elő, jelen Specifikáció előbbire fekteti a hangsúlyt. exportálás Másolat készítése az elektronikus iratokról és azok metaadatairól másik rendszer számára. Megjegyzés: az áthelyezéssel ellentétben az exportálás nem érinti az eredeti iratok helyét az EIKR-ben. felhasználó Az EIKR-t igénybe vevő tetszőleges személy. Megjegyzés: ide sorolhatók (többek közt) az adminisztrátorok, az irodai alkalmazottak, külső személyek, például felülvizsgálók stb. Megjegyzés: egy felhasználó egyidejűleg több szerepkör és csoport tagja lehet. felhasználócsoport Lásd csoport. felhasználói profil A felhasználó profilja. felhasználói szerepkör Iratkezelési feladatok elvégzésére engedélyek gyűjteménye.
feljogosító,
felhasználókhoz
rendelt
funkcionális
Egy felhasználóhoz több felhasználói szerepkör tartozhat, de csak egyetlen felhasználói profilja lehet. Megjegyzés: a MoReq2-ben ugyanez a kifejezés jelöli a felhasználói szerepkörrel rendelkező személyeket is. fizikai dosszié Fizikai dokumentumok és fizikai iratok tárolását szolgáló eszköz. Forrás: A PRO Fukcionális specifikáció (Functional Specificaton) alapján (lásd 1. függelék). fizikai irat Az EIKR hatókörén kívül eső adathordozón tárolt irat, melynek kezeléséért az EIKR közvetlenül nem felel.
Megjegyzés: ide sorolhatók a papíralapú iratok, a mikroformán tárolt iratok és azok a cserélhető adathordozón tárolt elektronikus iratok, amelyek nem esnek külön az EIKR kezelése alá. formátum Lásd állományformátum. gyűjtemény Lásd iratgyűjtemény. hitelesség (Csak az iratkezelés vonatkozásában) Az eredetiséget jelző tulajdonság. Forrás: a UBC-MAS szótárában leírt „irathitelesség” definíciója alapján (1. függelék). Megjegyzés: a hiteles iratra igaz, hogy bizonyíthatóan „a) az, amit állít magáról, b) az a személy készítette vagy küldte, akiről az irat ezt állítja, továbbá c) a feltüntetett időpontban készült vagy érkezett.” Forrás: ISO 15489. Megjegyzés: egy irat hitelessége arra utal, hogy az irat az, amit állít magáról; a hitelesség önmagában nem mond semmit az irat tartalmának megbízhatóságáról. iktatás (1) Digitális objektum konkrét példányának rögzítése vagy mentése. (Forrás: InterPARES 2 Project Terminology Database – az InterPARES 2 projekt terminológiai adatbázisa) (2) Információ mentése számítógépes rendszerben. Megjegyzés: A MoReq2 értelmezésében egy irat iktatása magában foglalja az irat rögzítését, azaz nyilvántartásba vételét az EIKR-ben, az irat besorolását, a hozzá tartozó metaadatok bevitelét, illetve a forrásdokumentum tartalmának befagyasztását. Az „iktatás” MoReq2-ben értelmezett fogalma („capture”) általánosabb, mint a hagyományosan iktatószámmal való nyilvántartásbavétel, azaz az irattá nyilvánítás teljes folyamatát reprezentálja; az angol „capture” általánosabb értelemben számítógépes adatrögzítést, mentést jelent (pl. metaadatok bevitelét). importálás Lásd tömeges importálás. irat Adott szerv vagy személy üzletvitele vagy törvényi kötelezettségeinek teljesítése során keletkezett, fogadott, bizonyítékként vagy egyéb célból kezelt információ. Forrás: ISO 15489 (lásd 7. függelék).
Megjegyzés: Iratnak tekinthető a szöveg, számadatsor, térkép, tervrajz vagy vázlat formájában rögzített információ. A megjelentetés szándékával készült könyv jellegű kézirat nem kezelhető iratként. Forrás: Levéltári törvény. Megjegyzés: Egy irat egy vagy több dokumentumot tartalmazhat (pl. egy dokumentum néhány csatolmánnyal), melyek formátumára és a tárolásához használt adathordozó típusára nincs megkötés. Ebből következik, hogy az irat több állományból is állhat. A forrásként használt dokumentum(ok) tartalmán kívül az irat mellé célszerű feljegyezni az irat környezetére, illetve, ha értelmezhető, a szerkezetére vonatkozó információkat (pl. szerkezeti információnak tekinthető, hogy hány állományból áll az irat). Az irat fő jellemzője, hogy nem lehet módosítani. Megjegyzés: az EIKR elektronikus iratokat és fizikai iratokat is kezelhet egyidejűleg. iratgyűjtemény (Csak a MoReq2-ben) Osztály, dosszié, aldosszié vagy kötet. irattípus Adott dokumentumtípusú dokumentumból készített irat jellemzője. jegyzék A besorolási séma legalsó szintjeihez sorolt létező dossziénevek listája. jogosult felhasználó Olyan felhasználó, akinek engedélye van arra, hogy adott tevékenységet elvégezzen. Megjegyzés: a fogalom pontosabb meghatározása környezetfüggő. A különböző felhasználók különböző engedélyekkel rendelkeznek. Jelen Specifikáció szempontjából lényegtelen, hogy az egyes felhasználói szerepkörökhöz milyen engedélyek kapcsolódhatnak. A tevékenységek végrehajtására feljogosító engedélyeket a szervezet osztja ki irányelveinek és üzleti követelményeinek figyelembevételével. kiemelt irat A szervezet működése vagy túlélése szempontjából vészhelyzet esetén nélkülözhetetlen irat. konfiguráció Az EIKR életciklusának az a szakasza, amikor a rendszert telepítik és beállítják kezdeti paramétereit. kölcsönzési ügyintéző Lásd tárfelügyelő. kötet Egy aldosszié felosztása során keletkező egység.
Megjegyzés: Az aldossziék, ezáltal pedig a dossziék lebontása további egységekre a kezelhetőséget hivatott javítani olyan iratcsoportok létrehozásával, amelyek nem túl nagyok. A felosztás általában valamilyen formális, technikai, semmint logikai szempont szerint történik, például dátum vagy azonosító alapján. kulcsszó (tárgyszó) A kulcsszó osztályok, dossziék, aldossziék és iratok hozzáférési pontjaiként szereplő, bennük meglévő, opcionális metaadat. (Kötetekre nem vonatkozik.) A tárgyszó a fentiek hozzáférési pontjaként megadható, opcionális metaadat. A kulcsszó tehát abban különbözik a tárgyszótól, hogy az iratoktól függetlenül nem létezik, csak azokban van ott, a tárgyszó ezzel szemben létezhet az iratokról függetlenül, és ha iratokhoz kapcsolják, a kulcsszó szerepét tölti be. Megjegyzés: a tárgyszavakat célszerű előre megszerkesztett, ún. kötött szótárból választani, vagy az EIKR automatikus kulcsszavas keresésére támaszkodni, de ezek egyike sem kötelező. lezárás A dosszié, aldosszié vagy kötet attribútumainak olyan jellegű módosítása, amely megakadályozza újabb iratok hozzáadását. lezárt Olyan dosszié, aldosszié vagy kötet, amely nincs megnyitva, azaz nem bővíthető újabb iratokkal. megnyitás Új dosszié, aldosszié vagy kötet létrehozása iratok felvétele céljából. metaadat (Az iratkezelés vonatkozásában) Az iratok környezetét, tartalmát és szerkezetét, illetve a kezelésükkel kapcsolatos információkat leíró adatok. Forrás: ISO 15489 (lásd 7. függelék). Megjegyzés: Más modellek a metaadatok eltérő felfogására épülnek. Egyesek például teljes mértékben metaadatként kezelik az eseménynaplóban rögzített információkat. Jóllehet az ehhez hasonló alternatív megközelítések az adott környezetre nézve érvényesek és értékesek, nem sokban segítik a rendszerek funkcionalitásának leírását, ennél fogva jelen Specifikáció figyelmen kívül hagyja azokat. maszkolás Egy irat bizalmas adatainak elrejtése. Megjegyzés: maszkolásnak számít, ha telt téglalapokkal kitakarják az iratban szereplő neveket, telefonszámokat stb. (a tintával kihúzás elektronikus megfelelője), más, ennél biztonságosabb módszert alkalmaznak, vagy kivágnak az iratból néhány oldalt. Megjegyzés: a maszkolással nem sérül az elektronikus irat, mivel a műveletet az eredeti irat egy másolatán hajtják végre. Ezt a példányt nevezik maszkolt másolatnak vagy maszkolt példánynak.
maszkolt másolat Egy irat olyan másolata, melynek tartalmát törlés vagy elfedés, de nem bővítés vagy érdemi jelentésbeli kiegészítés céljából módosították. Forrás: A PRO Fukcionális specifikáció (Functional Specificaton) „példány” (instance) meghatározása alapján (lásd 1. függelék). Megjegyzés: a változtatások rendszerint a bizalmas adatok védelmét szolgálják. Előírás szabályozhatja például, hogy egy iratot csak a benne lévő nevek kitakarása vagy törlése után lehet közzétenni; ebben az esetben a maszkolt másolat az iratnak az a változata lesz, amelyben olvashatatlanok a nevek. Megjegyzés: a MoReq korábbi változata a maszkolt példány fogalmára a kivonat (extract)” kifejezést használta. metaadatcsonk Egy objektum selejtezése után megőrzött metaadatok, amelyek bizonyítják, hogy az adott objektum létezett a rendszerben és megfelelően megsemmisítették. megbízhatósági bizonyítvány A felhasználóhoz rendelt egy vagy több kifejezés, amely a felhasználó számára hozzáférhető biztonsági kategóriákat határozza meg. megjelenítés Az elektronikus irat EIKR általi megtestesülése, amelyre a felhasználó hivatkozhat. Megjegyzés: ide tartozik a képernyőn történő megjelenítés, valamint a nyomtatott, hang- és multimédiás megjelenítések is. Megjegyzés: a megjelenítés részleteit befolyásolja a szoftver- és hardverkörnyezet. Egyazon irat különböző megjelenítéseire más betűtípus, sorvégjel, oldaltörés, képfelbontás, színmélység stb. jellemző. Bizonyos esetekben azonban az egyes tulajdonságokra külön figyelmet kell fordítani, ennek leírása azonban meghaladja jelen Specifikáció hatókörét. Megjegyzés: a MoReq korábbi verziója a megjelenítési forma kifejezést használta ebben az értelemben. megjelenítés-átformálás Megjelenítési forma készítése. megjelenítési forma Egy irat vagy állomány megtestesülése az irat natív állományformátumától eltérő állományformátumban vagy annak segítségével. Megjegyzés: a megjelenítési formák rendszerint az elektronikus iratok tartós megőrzését támogatják, céljuk csökkenteni az irattartalmak elérhetetlenné válásának kockázatát. Zárt formátumú iratok esetén elképzelhető azok átalakítása PDF/A vagy XML formátumú megjelenítési formákba.
A több állományból álló iratok átalakítása más megjelenítési formába az iratot alkotó néhány vagy összes állományt érinti. Átalakítás után az irat vagy ugyanannyi, vagy eltérő számú állományt foglal magában. Például, egy 30 állományból, köztük 10 GIF formátumú képobjektumból álló irat az alábbi megjelenítési formákra alakítható át: Az irat átformálása PDF/A formátumra: az eredeti irat 30, az új megjelenítési forma egyetlen állományból áll; A GIF-állományok átalakítása JPEG formátumra: az eredeti irat és az új megjelenítési forma egyaránt 30 állományt tartalmaz, utóbbi néhány objektumát azonban módosítani kell, hogy az újonnan létrehozott JPEG-képeket hivatkozzák a GIF-képek helyett. Megjegyzés: a MoReq korábbi verziójában a megjelenítési forma kifejezés mást jelentett. megőrzési és selejtezési ütemterv Az iratok megőrzésének hosszát és a megőrzési idő lejártakor esedékes selejtezési tevékenységeket ütemtervben rögzítő formális eszköz. Forrás: az Ausztrál Nemzeti Levéltár irattári szószedete alapján. Megjegyzés: A MoReq korábbi verziója a megőrzési ütemterv kifejezést használja. megsemmisítés Az iratok helyreállíthatatlan eltávolításának folyamata. Forrás: ISO 15489 (lásd 7. függelék). Megjegyzés: A rendszer konfigurációjától függően a megsemmisítés jelenthet törlést, vagy más eljárást. Megjegyzés: Az irat helyreállíthatatlanságából nem következik, hogy az eltávolított iratot felül kell írni, vagy egyéb biztonsági intézkedéseket kell foganatosítani. Ugyan a MoReq2 nem zárja ki az ilyen jellegű biztonsági intézkedéseket, de nem is várja el azokat. nem ügyirat Olyan dosszié, amely nem ügyirat. nyitott Olyan dosszié, aldosszié vagy kötet, amit még nem zártak le, ezért iratokkal bővíthető. osztály (Csak a MoReq2-ben) A besorolási séma hierarchiájának egy része, melyet a séma egy kiválasztott pontjától az alatta lévő dossziékig vezető folytonos vonal ábrázol. Megjegyzés: Klasszikus terminológiában az osztály szinonimái a besorolási séma tetszőleges szintjén előforduló „kategória”, „csoport”, „sorozat”, „tétel”, vagy ezek alosztályai („alkategória”, „alcsoport” stb.). Megjegyzés: MoReq2-ben az osztály az alá besorolt iratok összességét is jelentheti.
papíralapú dosszié A fizikai dossziék egy fajtája. Megjegyzés: papíralapú dossziénak számít a boríték, az iratrendező és a gyűrűs mappa. PDF Portable Document Format (hordozható dokumentumformátum), kétdimenziós adatok megjelenítésének népszerű állományformátuma. Megjegyzés: Jelen Specifikáció írásának idején a PDF formátum az Adobe Inc. tulajdonát képezi, de a formátum egy nem régi verziójából (v1.7.) elképzelhető, hogy nemzetközi szabvány (ISO/DIS 32000) készül. A PDF kifejezés szószedetbe foglalása nem jelent semminemű elköteleződést. A formátum kiterjesztése háromdimenziós adatok ábrázolására fejlesztés alatt áll. PDF/A A PDF állományformátumnak archiválás szabványcsaládban foglalt részhalmaza.
céljára
kifejlesztett,
az
ISO
19005
profil Egy felhasználó, csoport vagy szerepkör engedélyeinek összessége. randevú A munkafolyamat olyan pontja, ahol két, addig párhuzamosan futó tevékenység egyetlen közös szálban egyesül. Forrás: A munkafolyamat-kezelés szabványosításával foglalkozó „Workflow Management Coalition” terminológiai szótára (Terminology & Glossary, issue 3.0). regisztrálás Egyedi azonosító rendelése a rendszerbe bekerülő irathoz (a szűkebb értelemben vett iktatás, nyilvántartásba vétel). Forrás: ISO 15489 (lásd 7. függelék). Megjegyzés: MoReq2-ben a regisztrálás az iktatási folyamat része. selejtezés Az iratok megőrzéséről, megsemmisítéséről és áthelyezéséről hozott döntéseket támogató folyamatok, melyeket a megőrzési és selejtezési ütemterv vagy más szabályozás ír le. Forrás: ISO 15489 (lásd 7. függelék). selejtezési visszatartás Az iratok megsemmisítését és áthelyezését megakadályozó szabály.
szerepkör Felhasználók meghatározott köréhez rendelt funkcionális engedélyek gyűjteménye. Forrás: a PRO Fukcionális specifikáció (Functional Specificaton) alapján (lásd 1. függelék). tárfelügyelő (Irat vagy iratgyűjtemény esetén) Az a személy vagy szervezeti egység, aki vagy amely a tárolt állománnyal vagy állományokkal rendelkezik, azt kezeli. TKR Tartalomkezelő rendszer (CMS, Content Management System). tömeges importálás Rendszerint más alkalmazásból származó elektronikus iratok egy csoportjának iktatása a metaadatok részleges vagy teljes körű megőrzése mellett. tulajdonos Egy iratért vagy dossziéért felelős személy vagy szerepkör. Megjegyzés: a MoReq2 ebben az értelemben használja a tulajdonos fogalmat; az irat jogi értelemben vett tulajdonosa az a szervezet, amelyiknek a birtokában van az irat. Megjegyzés: lásd még tárfelügyelő. ügyintéző Ügyiratokkal foglalkozó felhasználó. ügyirat Konkrét folyamat vagy tevékenység eredményeként keletkező, egy vagy több tranzakcióhoz egészben vagy részben kapcsolódó, strukturált vagy részben strukturált dosszié. Megjegyzés: az ügyirat definíciója nem pontosan körülhatárolt, mint ahogy az ügyirat és a hagyományos dossziék közötti különbség sem éles. Az itt bemutatott definíció a MoReq2 megértését segíti, más kontextusban nem feltétlenül helytálló. Megjegyzés: Az ügyiratba tartozó iratok lehetnek strukturáltak vagy struktúra nélküliek. Az ügyiratok megkülönböztető jellemvonása, hogy olyan folyamatokból erednek, melyek legalább részben strukturáltak és megismételhetők. Ügyiratba gyűjthetők: az engedélykérelmek; a rutin szolgáltatások felőli érdeklődések; adott ügy kivizsgálásához kapcsolódó iratok; a felügyeleti ellenőrzések. Megjegyzés: Az ügyiratokra jellemző továbbá, hogy gyakran
kikövetkeztethető a tartalmuk szerkezete; nagy számban fordulnak elő; részben vagy teljesen strukturáltak; jól ismert és előre meghatározott folyamat alapján használják és kezelik azokat; megőrzésük előre meghatározott periódus idejére, törvényi előírás vagy egyéb szabályozás alapján kötelező; szakavatott személyek, végfelhasználók vagy adatfeldolgozó rendszerek a vezetőség jóváhagyása nélkül megnyithatják és lezárhatják. verzió (dokumentumé) A dokumentum állapota fejlődésének egy adott időpontjában. Forrás: a PRO Fukcionális specifikáció (Functional Specificaton) alapján (lásd 1. függelék). Megjegyzés: a verzió rendszerint a dokumentum piszkozatainak egyikét, vagy a végleges dokumentumot jelenti. Előfordulhat, hogy a kész dokumentum több verzióban is elérhető, példa erre a felhasználói kézikönyvek különböző kiadásai; más esetben a verzió az eredeti dokumentum valamelyik fordítására vonatkozhat. A dokumentumokkal ellentétben az iratok nem létezhetnek egynél több verzióban; lásd még maszkolás.
13.2.
Egyed-kapcsolat modell
Ez a szakasz a könnyebb érthetőség kedvéért részben megismétli a 2.3. szakaszban leírtakat. Az alábbiakban bemutatott egyed-kapcsolat modell a Specifikáció megértését segíti, ennek leíró magyarázatát tartalmazza a 13.3. szakasz. Az egyed-kapcsolat modellt a 13.3. ábra mutatja. A modell fontos vonása, hogy nem ábrázolja közvetlenül az iratkezelő rendszer megvalósításához használható struktúrákat. Az egyed-kapcsolat modell elméleti szemszögből mutatja be az iratokkal összefüggő egyedtípusokat. Az EIKR ezeket a kapcsolattípusokat használja fel a modellben bemutatott szerkezetek viselkedésének szimulálására. Lásd 2.2. szakasz. Az egyed-kapcsolat diagram a dossziék, kötetek, iratok és egyéb fontos egyedek között fennálló kapcsolatokat szemlélteti. Ebben a tekintetben a diagram az EIKR viselkedését leíró formális struktúra. A diagramon az egyedtípusokat (dossziékat, iratokat stb.) téglalapok jelölik. A téglalapokat összekötő vonalak felelnek meg az egyedtípusok között fennálló kapcsolatoknak. A vonal közepén lévő szöveg a kapcsolat leírását adja meg, a kapcsolatot a nyíl irányában kell értelmezni. A kapcsolatok egyes végpontjaiban feltüntetett számok a kapcsolatban résztvevő előfordulások számát (azaz a kapcsolat számosságát) jelentik, pontos értelmezésüket a jelmagyarázat tartalmazza. Ennek megfelelően a 2.3. ábrát úgy kell olvasni, hogy „egy irat egy vagy több állományból áll” (külön felhívjuk az Olvasó figyelmét a nyíl irányára).
13.1. ábra A két vagy több kapcsolaton áthaladó félkörív azt jelenti, hogy a kapcsolatok kölcsönösen kizárják egymást minden résztvevő egyed-előfordulás esetén. A 13.2. ábrán látható félkörív olvasata: „egy iratot vagy kötetben, vagy aldossziéban lehet tárolni, de egyszerre csak az egyikben”.
13.2. ábra Az osztály egyedtípus az „összetevője” kapcsolattal kapcsolódik saját magához (része lehet önmaga is). Informálisan ez azt jelenti, hogy egy hierarchikus besorolási sémában minden osztály egy vagy több osztályt tartalmazhat. Ha a diagramról eltávolítanánk ezt a (rekurzív) kapcsolatot, a modell a nem hierarchikus besorolási sémák leírásának is megfelelne.
13.3. ábra
13.3.
Az egyed-kapcsolat modell kifejtése
A 13.3. ábrán láthatóegyszerűsített modell nem tartalmazza az összes lehetséges egyedtípust és kapcsolatot. A modell csak az alkalmazás szempontjából lényeges egyedtípusokat foglalja össze, ezért a felhasználók, a szerepkörök stb. kimaradtak a modellből. A szakasz további részében a diagramon bemutatott egyedtípusok és a közöttük lévő kapcsolatok leírása olvasható. Besorolási séma Az iratkezelési elvek megvalósításának egyik legfontosabb előfeltétele, hogy a szervezet legalább egy besorolási sémát meghatározzon, amely adott szervezeti egység (rendszerint hierarchikus) osztályozási rendszerét írja le. Egy besorolási séma több osztályból áll. Osztály Egy hierarchikus besorolási séma osztályok hierarchiájából áll, hasonlóan ahhoz, ahogy a fák kisebb ágakból állnak. Az osztályok a hierarchia adott szintjéhez kapcsolódnak, ugyanakkor több szinten átnyúlhatnak, és további kisebb osztályokra bonthatók. A hierarchia adott szintjéhez egyidejűleg több osztály is kapcsolódhat, de egy osztály csak egy szinten kezdődhet. A „kizáró vagy” kapcsolat értelmében minden egyes osztály: felosztható további osztályokra; vagy tartalmazhat dossziékat; vagy tárolhat iratokat; de ezek együttes előfordulása nem megengedett. Dosszié A dossziékat osztályokhoz kapcsolva („osztályokban”) tárolják a hierarchia tetszőleges szintjén. Dossziét csak olyan osztályhoz lehet rendelni, amelyik nem tartalmaz más osztályt. A „kizáró vagy” kapcsolat értelmében minden egyes dosszié: felosztható aldossziékra; vagy felosztható kötetekre; vagy tárolhat iratokat; de ezek együttes előfordulása nem megengedett. Aldosszié A dossziék aldossziékra oszthatók (adott konfigurációs beállítás értékétől függ, hogy a rendszer képes-e aldossziékat kezelni), a gyakorlatban azonban csak néhány dossziét bontanak szét ily módon. Amennyiben egy dosszié egyetlen aldossziéra oszlik, a rendszer elrejti az aldossziét a felhasználó elől gyakorlati megfontolásból. Ügyviteli környezetekben különösen elterjedt az aldossziék (ügyiratdarabok) használata. A „kizáró vagy” kapcsolat értelmében minden egyes aldosszié:
felosztható kötetekre; vagy tárolhat iratokat; de ezek együttes előfordulása nem megengedett. Kötet Az aldossziék kötetekre oszthatók előre rögzített szabályok szerint (adott konfigurációs beállítás értékétől függ, hogy a rendszer képes-e köteteket kezelni), a gyakorlatban azonban csak néhány aldossziét bontanak szét ily módon. Amennyiben egy aldosszié egyetlen kötetből áll, a rendszer elrejti a kötetet a felhasználó elől gyakorlati megfontolásból. A kötetre bontás szabályai figyelembe vehetik az iratok méretét és számát, az időszakokat vagy bizonyos tranzakciók végrehajtását. A kötetek használatát a nagyméretű, súlyos fizikai dossziék kezelhetősége iránti igény tette népszerűvé. Ezt a gyakorlatot vitték tovább az elektronikus iratkezelés világába, ahol az elektronikus dossziék kötetekre bontása a felülvizsgálati, áthelyezési stb. folyamatokat segíti. Amennyiben a dosszié egyetlen aldossziét tartalmaz, az aldosszié köteteit a rendszer a dossziéhoz tartozónak mutathatja a felhasználók előtt. A dosszié, aldosszié és kötet kifejezéseket a hétköznapi életben gyakran felcserélik egymással a fent említett átláthatósági követelmény miatt. Egy felhasználó jellemzően „dosszié” és nem (az egyébként helyes) „kötet” iránt fog érdeklődni, különösen ha olyan dossziét keres, amely egyetlen egykötetes aldossziét tartalmaz. Jóllehet a dosszié egy aldossziét tartalmaz, amely egy kötetből áll, az aldosszié és a kötet megnevezéseket rendszerint hanyagolják (vagy csak akkor alkalmazzák, ha a dossziéban megnyitják a második aldossziét vagy kötetet). Megőrzési és selejtezési ütemterv A megőrzési és selejtezési ütemterv rögzíti az iratok megőrzésének és selejtezésének szabályait. Az EIKR egynél több megőrzési és selejtezési ütemtervet használhat, melyek osztályokra, dossziékra, aldossziékra és kötetekre, esetenként iratokra vonatkozhatnak. Irattípusonként egy megőrzési és selejtezési ütemterv érvényes. Irat A rendszer legalapvetőbb elemei az iratok. Az iratkezelési infrastruktúra létjogosultságát az adja, hogy az iratok számot adnak a szervezet tevékenységeiről. Az iratok dokumentumok alapján készülnek. Egy irat egy vagy több dokumentumot foglalhat magában, és egy dokumentum is több irat alapjául szolgálhat. Az iratokat rendszerint kötetekben tárolják, de közvetlenül osztályokba sorolva is előfordulhatnak (ezt a kivételes esetet a szabvány más részei írják le). A MoReq2 konfigurációs beállítással teszi lehetővé az aldossziék és a kötetek letiltását, mely esetben az iratok tárolása dossziékban történik. Egy irat egyidejűleg csak egy kötetben, aldossziéban, dossziéban vagy osztályban tárolható. Irattípus Az iratok irattípussal rendelkeznek, ami az irat kezelésére vonatkozó jellemzőket foglalja össze. Irattípus például a „számla”, „weboldal” stb.
Állomány Minden irat és dokumentum legalább egy állományból tevődik össze, de a több állományból felépülő iratok és dokumentumok sem ritkák. Míg a legegyszerűbb weboldal – informatikai kifejezéssel élve: HTML-állomány – egyetlen állományból áll, az összetettebb weboldalak nem ritkán többtucat állományból épülnek fel – egy HTML-állományból és további GIF, JPEG stb. állományokból.
13.4.
Hozzáférés-szabályozási modell
A szakasz néhány egyszerű példaszerepkörön keresztül mutatja be az EIKR hozzáférésszabályozási modelljét. A modellt egy mátrix szemléleti, ahol két fő szerepkör látható, melyek maguk is további szerepkörökre oszlanak. A két fő szerepkör a felhasználói és az adminisztrátori szerepkör. Az egyes szerepköröket az EIKR-ben elvégezhető feladatok elérésére kapott engedélyek határolják el. A szerepkörök száma illusztratív: sem megvalósításuk, sem a felosztás követése nem kötelező a szervezetek számára. Minden szervezet magának határozza meg a szükséges szerepköröket, melyek idővel rendszerint változnak. Az alábbiakban bemutatott szerepkörök a felhasználók felelősségeit figyelembe vevő, a rendszer funkcionalitására vonatkozó hozzáférési szabályokat szemléltetik. A példamátrix négy szerepkört tartalmaz: Központi adminisztrátor – ez a szerepkör felel az EIKR konfigurálásáért valamint az iratgyűjtemények és az iratok kezeléséért. Helyi adminisztrátor – adminisztrátori jogokkal rendelkezik az EIKR és a besorolási séma egyes részei fölött. A helyi adminisztrátornak mint szerepkörnek általában csak a földrajzilag elosztott szervezetek esetén van értelme. Bíráló – ez az erősen szakosodott szerepkör elsősorban a megőrzési és selejtezési ütemtervekben leírt selejtezési tevékenységek alkalmazásával foglalkozik. Végfelhasználó – a végfelhasználói szerepkör az EIKR szabványos hozzáférési szintjét jelöli ki; azok tartoznak a szerepkörhöz, akik hétköznapi munkájuk során iratokat mentenek és keresnek az EIKR-ben. Az adminisztrátori szerepköröket csak a példa kedvéért osztottuk két részre, a felelősségeket más módon is fel lehet osztani. Kis szervezetekben az ilyenfajta felosztás szükségtelenül bonyolult, mivel egyetlen személy is elegendő az összes adminisztrátori tevékenység elvégzéséhez. Nagyobb szervezetekben viszont valószínűleg nem elég két adminisztrátori szerepkör (olyan további szakosodott szerepkörökre lehet szükség, mint az Iratkezelő, Levéltáros, Adatkezelő, IT adminisztrátor stb.). A MoReq2 ennél fogva nem kívánja előírni a valós szervezeteknél elképzelhető adminisztrátori szerepkörök számát. A Helyi adminisztrátor szerepkör az adminisztrátori szerepkörök egyik lehetséges felosztását szemlélteti, a szerepkör pontos megnevezése szervezettől függően lehet Helyi iratkezelőbiztos, Szuperfelhasználó stb. Felosztástól függetlenül érvényes az a megállapítás, hogy az adminisztrátori szerepkörök a rendszer szemszögéből tekintve a felső vezetés által hozott döntéseket valósítják meg.
Ezeket a döntéseket túlnyomórészt a szervezet üzleti követelményei és iratkezelési elvei befolyásolják, ugyanakkor figyelembe kell venniük az információs szabadság, az adatvédelmi törvény, a levéltári törvény és az ipar előírásait is (ezek részletesebb leírását a 11.5. szakasz tartalmazza). A mátrixból nem következik, hogy az adminisztrátori szerepkörök kötelesek vezetői döntéseket hozni, jóllehet néhány környezetben ez a helyzet. Az adminisztrátori szerepkörök az iratok kezelésével kapcsolatos tevékenységeket végeznek, érdeklődésük az iratokra mint egyedekre irányul, nem pedig azok tartalmára vagy üzleti vonatkozásaira. Az adminisztrátori szerepkörök olykor az EIKR hardver- és működési környezetének üzemeltetéséért, a tárolóhelyek karbantartásáért, biztonsági mentések készítéséért és az EIKR teljesítményének hangolásáért is felelnek. Több szervezetre jellemző, hogy az iratkezelést összekapcsolják az üzleti folyamatok kezelésével. Ebben az esetben az üzleti vezetők külön-külön kaphatnak bizonyos adminisztrátori engedélyeket, például adott felhasználócsoport vagy a besorolási séma egy részének a felügyelete és kezelése fölötti jogot. Bár a MoReq2 csak egy szigorú értelemben vett felhasználói szerepkört ismertet, a legtöbb szervezet számos felhasználói szerepkört fog megkülönböztetni. Az EIKR nem szabhat korlátot a szerepkörök számának. Tipikus felhasználói szerepkör például az Ügyintéző (lásd az ügyviteli környezetek követelményeiről szóló 10.5. szakaszt). Ez a szerepkör a besorolási séma egy konkrét ágát érintő engedélyekkel rendelkezik. Az adminisztrátori szerepkörökkel ellentétben a felhasználói szerepkörök olyan eszközökhöz kapnak hozzáférést, amelyek az irodai alkalmazottak és kutatók iratkezelési igényeinek felelnek meg. Ide tartoznak többek közt a dokumentumok hozzáadását, az iratok keresését, kinyerését támogató szolgáltatások. A felhasználói szerepköröket az iratok tartalma, tulajdonságai és üzleti vonatkozása foglalkoztatja, nem pedig kezelésük. Más szóval, a felhasználói szerepköröket az iratokkal tanúsított üzleti folyamatok érdeklik. Amint az a mátrixból látható, a végfelhasználói szerepkörhöz rendelt jogok lefedik a felhasználók többségének a munkavégzéssel kapcsolatos igényeit. A példában bemutatott másik szerepkör a bíráló, aki az iratok bírálásához szükséges hozzáférési engedélyekkel rendelkezik. A mátrix leginkább a jogosultságok kiosztásának kiindulási pontjának tekinthető. A Specifikáció felhasználói számára javasolt a környezetüknek megfelelő további követelmények meghatározása. A táblázattal kapcsolatos követelményeket a 4.1. szakasz részletezi, megerősítve azt, hogy az elektronikus iratkezelő rendszereknek nem kell megvalósítaniuk az alább bemutatott példamátrixot, lehetőséget kell biztosítaniuk azonban arra, hogy a hozzáférési jogokat a szervezet által összeállított hozzáférési mátrixnak megfelelő szintű részletességben konfigurálják. A szervezet által meghatározott mátrix korlátlan számú szerepkört és funkciót tartalmazhat. A mátrix cellái az „Igen” vagy „Nem” értékek egyikét vehetik fel, az oszlopok száma azonban nincs korlátozva. További lehetséges szerepkörök: asszisztens;
felülvizsgáló; információs szabadság-biztos; vezető; iratkészítő; iratkezelő; felügyelő. A mátrix szakaszokba csoportosítva sorolja fel a funkciókat, ezek rendre osztályokhoz és dossziékhoz, iratokhoz, az iratkezeléshez és az adminisztrációhoz kapcsolódnak. Szerepkörök
Igen
Igen
Új dosszié létrehozása
Igen
Nem
Igen
Igen
Dosszié metaadatainak módosítása
Nem
Igen
Igen
Igen
A besorolási séma és a dossziék karbantartása
Nem
Nem
Igen
Igen
Dossziék törlése
Nem
Nem
Igen
Igen
Iratok iktatása
Igen
Nem
Igen
Igen
Irat átmozgatása másik dossziéba
Igen
Nem
Igen
Igen
Iratok keresése és olvasása
Igen
Igen
Igen
Igen
Iratok tartalmának módosítása
Nem
Nem
Nem
Nem
Irat metaadatainak módosítása
Nem
Igen
Igen
Igen
Iratok törlése
Nem
Nem
Igen
Igen
Selejtezési visszatartás elhelyezése és feloldása
Nem
Igen
Igen
Igen
Megőrzési és selejtezési ütemterv és selejtezési tranzakciók
Nem
Igen
Igen
Igen
Iratok és dossziék exportálása és importálása
Nem
Igen
Igen
Igen
Az eseménynapló megtekintése
Nem
Igen
Igen
Igen
Az eseménynapló konfigurálása és karbantartása
Nem
Nem
Nem
Igen
Az eseménynaplóban tárolt adatok módosítása
Nem
Nem
Nem
Nem
Az eseménynapló másolása offline adathordozóra
Nem
Nem
Igen
Igen
Felhasználókhoz és hozzáférési engedélyeikhez kapcsolódó tranzakciók végrehajtása
Nem
Nem
Igen
Igen
A helyi adminisztrátorok hozzáférési engedélyeinek kiosztása
Nem
Nem
Nem
Igen
Saját hozzáférési engedélyek kiosztása más felhasználóknak
Igen
Igen
Igen
Igen
Ügyintézői szerepkörök létrehozása és kezelése
Nem
Nem
Nem
Igen
Az adatbázisok és tárhelyek karbantartása
Nem
Nem
Igen
Igen
adminisztrátor
Nem
Központi
Nem
adminisztrátor
Új osztály felvétele
Funkció
Helyi
Bíráló
Adminisztrátori szerepkörök
Végfelhasználó
Felhasználói szerepkörök
Szerepkörök
Nem
Igen
Nem
Igen
Igen
Igen
adminisztrátor
Nem
Központi
Nem
Egyéb rendszerjelentések meghatározása és megtekintése
adminisztrátor
Egyéb rendszerparaméterek karbantartása
Funkció
Helyi
Bíráló
Adminisztrátori szerepkörök
Végfelhasználó
Felhasználói szerepkörök
1. FÜGGELÉK – HIVATKOZÁSOK Jelen Specifikáció az alábbi létező szabványok és publikációk felhasználásával készült:
Hiv. Forrás megnevezése és tulajdonosa
URL vagy a publikáció adatai
[1]
Dublin Core Metadata Element Set, Version 1.1: Reference Description
http://dublincore.org/documents/dces/
[2]
Functional Requirements for Electronic Records Management Systems (The National Archives of the UK)
http://www.nationalarchives.gov.uk/electronicrecords/reqs2002/default.htm
[3]
Code of Practice for legal admissibility and evidential weight of information stored electronically (British Standards Institution)
Published by British Standards Institution (www.bsi-global.com) as BSI BIP 0008
[4]
The Preservation of the Integrity of Electronic Records (UBC-MAS Project)(University of British Columbia)
http://www.interpares.org
[5]
Standard 5015.2 “Design Criteria Standard For Electronic Records Management Software Applications” (US Department of Defense)
http://jitc.fhu.disa.mil/recmgt/
[6]
National Archives of Australia – Functional Specifications for Electronic Records Management Systems Software- Exposure Draft
The exposure draft is no longer available. A similar document is available from http://www.naa.gov.au/Images/ERMSspecifications_tcm2-1007.pdf
[7]
Riksarkivet – The National Archives of Norway – NOARK-4 Norwegian recordkeeping system Version 4 – Part 1 Functional description and specification of requirements
http://www.arkivverket.no/arkivverket/lover/elarkiv/noark-4/english.html
Hiv. Forrás megnevezése és tulajdonosa
URL vagy a publikáció adatai
[8]
Functional Requirements for the Sustainability of Electronic Records
http://www.nationalarchives.gov.uk/documents/functional_requirements.pdf
[9]
InterPARES 2 Project Terminology Database
http://www.interpares.org/ip2/ip2_terminology_db.cfm
[10]
DLM Forum Guidelines
http://dlmforum.typepad.com/gdlines.pdf
2. FÜGGELÉK – A SPECIFIKÁCIÓ FEJLESZTÉSÉNEK TÖRTÉNETE Áttekintés A MoReq2 Specifikációt az egyesült királysági székhelyű Serco Consultancy (korábban Cornwell Management Consultants Bt.) csapata készítette az Európai Bizottság részére. A MoReq2 alapjául a DLM Forum által készített részletes hatásköri jelentést használták fel. A Serco csapat a Specifikáció megírásáért felelős szaktanácsadókból, néhány projektvezetőből, adminisztrátorból és egy Szerkesztőbizottságból állt, a fejlesztésben európai és észak-amerikai iratkezelési szakértők vettek részt. A Specifikáció közel végleges változatát egy félig független bíráló nézte át. A teszt-keretrendszer dokumentációját az Imbus AG készítette. A követelmények több szintű ellenőrzésen mentek keresztül. Először a Szerző csapat tagjai nézték át egymás munkáit. Ezt követően továbbították a követelményvázlatokat a különböző iratkezelési érdekeket képviselő bizottságokhoz. Az átláthatóság kedvéért a bírálókat az alábbi négy bizottságba sorolták: Levéltárosok bizottsága; Szakértői bizottság; Felhasználói bizottság; Beszállítók bizottsága. A MoReq2 Szerkesztőbizottsága megadott időpontokban értékelte a vázlatokat. A Bizottság kétszer vette fel a kapcsolatot személyesen a Szerzőkkel, és mindkét alkalommal felbecsülhetetlen útmutatást adott; a harmadik bírálat e-mailben történt. Nem sokkal később a Serco elküldte a MoReq2 újabb változatát az Európai Bizottságnak jóváhagyásra. A követelményeket a DLM Forum bírálói nézték át az Európai Bizottság nevében. A bírálók az EU tagállamok vezető szakértői közül kerültek ki. A projektcsapat felépítése az A2.1. ábrán látható, a tagokat a 4. függelék sorolja fel.
Projektfelelős
Adminisztrációs csapat
Teszt-keretrendszer fejlesztői csapata
Szakértői bizottsága
Európai Bizottság
DLM Forum
Vezetők
Szerkesztőbizottság
Félig független bíráló
Szerzők
Levéltárosok Felhasználói bizottsága bizottság Bírálóbizottságok
Beszállítói bizottság
A2.1. ábra A londoni projektindító ülésen a Szerző csapat és a Szerkesztőbizottság részvételével megállapodás történt a projekt során használandó protokollokról és irányelvekről a legfontosabb hivatkozási munkák figyelembevételével. Ezt követte az 1. függelékben összefoglalt irányadó munkák felkutatása és azonosítása. A kijelölt szakirodalom alapos áttanulmányozása biztosította, hogy az átdolgozott specifikáció a témába vágó összes lehetséges követelményt lefedi. Az eredeti MoReq szövegét importálták egy követelményelemző és változáskezelő szoftverbe (Telelogic DOORS), ami a többszerzős átírási folyamatot és a bírálóktól kapott visszajelzések nyomon követését segítette. A MoReq2 átszerkesztést követő formája megfelel a hatáskörjelentésben előírt alaki követelményeknek, a szerkezeti hasonlóság a MoReq eredeti és átdolgozott változata között egyértelmű. Amint elkészült a MoReq2 egy fejezetének legújabb változata, felkerült a MoReq2 weboldalára, amiről értesítést kaptak a bíráló bizottságok. A bírálók a DOORS szoftvernek megfelelő speciális formátumban fejezhették ki megjegyzéseiket. Miután a fejezetek többsége elérte a félkész állapotot, összeállították a teljes dokumentumot, amit elküldtek a Szerkesztőbizottságnak. A Szerkesztőbizottság előkészítette a második ülésen megvitatandó kérdéseket. A második, szintén Londonban tartott ülésen a kérdések többségében konszenzus született a tagok között. Ezután átdolgozták a dokumentumot a megegyezések fényében. A MoReq2 átdolgozott változatát elküldték az EB projektfelelősének és a DLM Forum tagjainak bírálatra. Az elküldött változat hivatalos értékelését továbbították a Serco csapata felé, és megvitatták a Brüsszelben tartott projekt-előrehaladási ülésen.
A szerzők értékelték a hivatalos bírálatban foglalt és az egyéni bírálóktól kapott visszajelzéseket, melyeket belátásuk szerint megfogadtak vagy elutasítottak. A szerzők megfeszített munkát végeztek az egymást kölcsönösen kizáró követelmények közötti ellentétek feloldásában és a MoReq2 hatáskörén kívül eső követelmények szűrésében. Általánosságban azonban színvonalas visszajelzések érkeztek a bírálóktól, ami a korábbi változat továbbfinomítását jelentette. Ezt követően a bírálóbizottságok kifejthették véleményüket a második, lényegében teljes piszkozattal kapcsolatban. A szerzők az előzőekhez hasonlóan vagy elfogadták, vagy elutasították a bírálók megjegyzéseit. Az újabb változatot 2007 októberében továbbították az EB projektfelelőse és a DLM Forum felé felülbírálásra. Az EB megjegyzéseinek figyelembevételével elkészült a MoReq2 végleges piszkozata, mely 2008. januárban lett közzétéve egy félig független bírálói értékelés után.
3. FÜGGELÉK – A SPECIFIKÁCIÓ ELEKTRONIKUS FORMÁBAN TÖRTÉNŐ FELHASZNÁLÁSÁRÓL A Specifikációt elektronikusan felhasználható formában is közzéteszik. A Specifikáció Microsoft® Word 2003 szövegszerkesztővel készült. A Specifikáció elektronikus formában történő felhasználásának legnagyobb előnye a könnyű testreszabhatóság. A követelményeket (3-12. fejezet) táblázatokba szervezték, a táblázat egy sora egy követelménynek felel meg. A táblázat felépítését az A3.1. ábra mutatja.
A3.1. ábra A táblázat az alábbi négy oszlopból áll: Hiv.: a követelmény hivatkozási száma. A sorszámot a Microsoft Word generálja automatikusan címsor-jellegű stílus segítségével. A címsorok használatának köszönhetően valahányszor új követelményt vesznek fel, vagy meglévőt törölnek (akár teljes szakaszt), a sorszámozás automatikusan változik; Követelmény:
a követelmény szövege;
indoklás. A követelmény szövegét néha dőlt betűs indoklás követi, ami tovább pontosítja a követelményben foglaltakat, vagy példával segíti annak megértését;
Kötelező5: a követelmény szövegét követő oszlop határozza meg, hogy a követelmény kötelező jellegű vagy opcionális. A MoReq2-megfelelőség feltétele a kötelezően előírt követelmények megvalósítása. A „kötelező” attribútum lehetséges értékei, példákkal:
Igen – A követelmény kötelező, megvalósítása a MoReq2-megfelelés feltétele. Példa: „Az EIKR-nek támogatnia kell a szervezet üzleti besorolási sémáját, és kompatibilisnek kell lennie azzal.”
Nem – A követelményben leírt funkció megvalósítása ajánlott, de a szervezet igényeitől függ, szükséges-e. Példa: „Az EIKR nem korlátozhatja a besorolási séma hierarchiájában a szintek számát.”
Teszt: az egyes követelményeket a „tesztelhető”, röviden „teszt” attribútum követi, ami azt mutatja, hogy ellenőrizhető-e a követelménynek való megfelelés. A „kötelező” attribútum lehetséges értékei, példákkal: 5
A magyar változat ezen a ponton eltér az eredeti, angol nyelvű leírás formátumától. Angolban a kötelező követelményeket a MUST, a kívánatosakat a SHOULD módbeli segédige jelöli a követelmény szövegén belül. Magyar nyelvben a KELL és KELLENE szavak feleltethetők meg, használatuk azonban erőltetett. A „kötelező” attribútum külön szerepeltetése a kötelező és opcionális követelmények gyors szétválasztását is segíti.
Igen – A követelmény formálisan tesztelhető. Példa követelmény: „Az EIKR-nek legalább háromszintes [besorolási] hierarchiát kell támogatnia.” Ezt úgy lehet tesztelni, hogy megpróbálunk felállítani egy háromszintes hierarchiát a rendszerben. Ha sikerül, a rendszer kielégíti a követelményt.
Nem – A követelmény nem tesztelhető formálisan. Példa követelmény: „Az EIKR-nek támogatnia kell a szervezet üzleti besorolási sémáját.” A legtöbb esetben nincs megfelelő eszköz ennek a követelménynek az ellenőrzésére.
Részben – A követelmény tesztelhető ugyan, de a teszt lefedettsége csak részleges lehet. Pozitív kimenetű tesztet követően kiderülhet, hogy a rendszer mégsem felel meg a követelménynek. Példa követelmény: „Az EIKR nem korlátozhatja a besorolási séma hierarchiájában a szintek számát.” Formálisan nem lehet tesztelni egy határérték hiányát. A követelmény azonban bizonyos mértékig tesztelhető: megfelelően nagy számra megvizsgálható, hogy a rendszer engedi-e egy adott mélységű séma létrehozását. A részleges tesztelés során kiderülhet, ha a rendszer nem felel meg a követelménynek.
Fejezetek, szakaszok vagy követelmények törlésekor a Microsoft Word hibaüzenettel helyettesíti a törölt pontokra mutató hivatkozásokat. Ezek könnyen kiszűrhetők, ha rákeresünk a „Hiba!” szövegre. A táblázat szegélyei alapértelmezésben nem látszanak. A szegélyek a „Show Gridlines” paranccsal jeleníthetők meg.
4. FÜGGELÉK – KÖSZÖNETNYILVÁNÍTÁS A projekt tagjai Frank Brady
Európai Bizottság (ügyfél)
Tim Burrows
Serco Consulting
Peter Campbell-Burns
Serco Consulting
Keith Cornwell
Serco Consulting
Alayne Crozier
Serco Consulting
Steve Davies
Serco Consulting
John Deverill
Serco Consulting
Marc Fresko
Serco Consulting
Michael Haimerl
Imbus AG (tesztelő partner)
Tilo Linz
Imbus AG (tesztelő partner)
Wasif Mehdi
Serco Consulting
Thomas Rumi
Imbus AG (tesztelő partner)
Josephus Schram
Európai Bizottság (Projektfelelős)
John Seeley
Serco Consulting
Caroline Senior
Serco Consulting
Michael Sill
Imbus AG (tesztelő partner)
Natasha Smith
Serco Consulting
A projekt tagjai köszönetüket fejezik ki Mr John Worsfold (Royal National Institute of Blind People, UK) felé a kisegítő technológiákra vonatkozó követelmények összeállításáért.
Szerkesztőbizottság A projekttagok munkáját a nemzetközi szakértőket összefogó Szerkesztőbizottság segítette. Miguel Camacho
Sadiel S.A, Spanyolország
Marie-Anne Chabin
Archive 17, Franciaország
Anne Mette Dørum
Norvég Nemzeti Levéltár, Iratkezelési Osztály, Norvégia
Professor Luciana Duranti
School of Library, Archival and Information Studies, University of British Columbia, Kanada
Professor Mariella Guercio
University of Urbino, Olaszország
Peter Horsman
Archiefschool (Netherlands Institute for Archival Education and Research), Hollandia
Dr Ulrich Kampffmeyer
PROJECT CONSULT Unternehmensberatung GmbH, Németország
Paul Murphy
Pénzügyminisztérium, Írország
DLM Forum A DLM Forum kijelölt csoportja értékelte a piszkozatokat az Európai Bizottság nevében. Richard Blake
Egyesült Királyság
Dolores Carnicer Arribas
Spanyolország
Olivier de Solan
Franciaország
Dr Andrea Hänger
Németország
Paivi Happonen
Finnország
Toivo Jullinen
Észtország
Göran Kristiansson
Svédország
Ian MacFarlane
Egyesült Királyság
Atle Skjekkeland
Titkárság
Jože Škofljanec
Szlovénia
Malcolm Todd (elnök)
Egyesült Királyság
Martin Waldron
Egyesült Királyság
Bírálóbizottságok A projekt tagjai köszönettel tartoznak az alábbi önkéntes személyeknek és vállalatoknak, akik idejük jelentős részét áldozták a különböző változatok átolvasására és megjegyzések írására. Értékes visszajelzéseik biztosították, hogy a MoReq2 a legkülönfélébb felhasználói igényeknek is megfelelhessen. Francisco Barbedo
Levéltárosok bizottsága
Instituto dos Arquivos Nacionais/Torre do Tombo, Portugália
Jan Dalsten Sørensen
Levéltárosok bizottsága
Dán Nemzeti Levéltár
Inta Feldmane
Levéltárosok bizottsága
Maltai Nemzeti Levéltár
Håkan Lövblad
Levéltárosok bizottsága
Riksarkivet/Nemzeti Levéltár, Svédország
Michal Wanner
Levéltárosok bizottsága
Levéltári Adminisztrációs és Részleg, Cseh Köztársaság
Sergey Afanasiev
Szakértői bizottság
Iratkezelők Egyesülete, Oroszország
Phédra Clouner
Szakértői bizottság
document@work, Belgium
Michiel Gen
Szakértői bizottság
ARMA International, Belgium
Kimberley Barata
Felhasználói bizottság
Parlamenti Levéltár, Egyesült Királyság
Kathy Bashaar
Felhasználói bizottság
PNC Bank, USA
Daniel J Beard
Felhasználói bizottság
Xerox Corp, USA
Alissa Burger
Felhasználói bizottság
Rail Corp, Information Management, Ausztrália
Barry Cahill
Felhasználói bizottság
Nova Scotia Archives Management Department Culture & Heritage, Kanada
Lluís-Esteve Casellas Serra
Felhasználói bizottság
Ajuntament de Spanyolország
Alejandro Delgado Gómez
Felhasználói bizottság
Servicio de Archivo y Bibliotecas del Ayuntamiento de Cartagena Archivo Municipal parque de Artilleria, Spanyolország
Paul Dodgson
Felhasználói bizottság
Leicestershire County Council, Egyesült Királyság
Susan Em
Felhasználói bizottság
Royal Pharmaceutical Society of GB
Iratkezelő
and
Records
& of
Records Tourism
Girona.
SGDAP,
Trish Fallen
Felhasználói bizottság
Information Ausztrália
Lucia Filimon Stefan
Felhasználói bizottság
Joint Research Centre of the European Commission, Olaszország
Fiorella Foscarini
Felhasználói bizottság
European Central Bank, Németország
Alison Gibney
Felhasználói bizottság
Cimtech, Egyesült Királyság
Stefan Gradmann
Felhasználói bizottság
Universität Hamburg, Németország
Frances Grey
Felhasználói bizottság
Parlamenti Levéltár, Egyesült Királyság
Harold C Heard Jr.
Felhasználói bizottság
Citigroup, USA
Sarah Higgins
Felhasználói bizottság
Digital Curation Centre, University Edinburgh, Egyesült Királyság
Caroline Ives
Felhasználói bizottság
Salford City Council, Egyesült Királyság
Philip Jones
Felhasználói bizottság
Staffordshire County Council, Királyság
Ben Kettell
Felhasználói bizottság
Cactus Tecnologia, Spanyolország
Natasha Khramtsovsky
Felhasználói bizottság
Electronic Office Systems, Oroszország
Stewart Kirkup
Felhasználói bizottság
Derbyshire Királyság
Päivi Laakso
Felhasználói bizottság
National Agency for Medicines, Finnország
Jessica Lila
Felhasználói bizottság
USA
Stephen Macintosh
Felhasználói bizottság
Ausztrál Szövetségi Bíróság
Sònia Oliveras Artau
Felhasználói bizottság
Ajuntament de Spanyolország
Matt O’Mara
Felhasználói bizottság
Adam Pope
Felhasználói bizottság
Information Handy Man, Egyesült Királyság
Barbara Reed
Felhasználói bizottság
Recordkeeping Innovation, Ausztrália
David Reeve
Felhasználói bizottság
Dorset County Council, Egyesült Királyság
Maria Reixach Urcola
Felhasználói bizottság
Ajuntament de Spanyolorság
Jordi Serra Serra
Felhasználói bizottság
Generalitat de Catalunya, Spanyolország
Deirdre Sharp
Felhasználói bizottság
Norfolk County Council, Egyesült Királyság
Alan Shipman
Felhasználói bizottság
Group 5 Training, Egyesült Királyság
Marija Šimunović
Felhasználói bizottság
Supreme Court of the Republic of Croatia
Sundeep Vaid
Felhasználói bizottság
International Fund for Development, Olaszország
Peter Van Garderen
Felhasználói bizottság
Artefactual Systems, Kanada
Willem Vannester
Felhasználói bizottság
Stadsarchief Antwerpen, Belgium
Gérard Weisz
Felhasználói bizottság
Sirius Systems, Franciaország
Martin Bartonitz
Beszállítók bizottsága
SAPERION, Németország
Solomon Barron
Beszállítók bizottsága
IBM, Egyesült Királyság
Martin Bould
Beszállítók bizottsága
ErgoGroup AS, Norvégia
Reynolds Cahoon
Beszállítók bizottsága
Lockheed Martin, USA
Management
County
Practitioner,
of
Egyesült
Egyesült
Council,
Girona.
SGDAP,
Girona.
SGDAP,
Agricultural
Ian Capon
Beszállítók bizottsága
Open Text Corporation, Egyesült Királyság
Simon Cole
Beszállítók bizottsága
Meridio, Egyesült Királyság
Jon Garde
Beszállítók bizottsága
Objective Corporation, Egyesült Királyság
Graham Hadingham
Beszállítók bizottsága
FileNet, Egyesült Királyság
Joachim Haessler
Beszállítók bizottsága
Haessler Information, Németország
Tamara Hoagland
Beszállítók bizottsága
EDRM Solutions, USA
Mike Huberty
Beszállítók bizottsága
Lockheed Martin, Egyesült Királyság
Chris Hughes
Beszállítók bizottsága
Tower Software, Egyesült Királyság
Gregor Joeris
Beszállítók bizottsága
SER Solutions Deutschland, Németország
Volker John
Beszállítók bizottsága
SAPERION, Németország
Dr Annegret Kampe
Beszállítók bizottsága
Docuware, Németország
Mary Kelly
Beszállítók bizottsága
IBM, Egyesült Királyság
Andy King
Beszállítók bizottsága
Getronics, Egyesült Királyság
Karen McKenzie
Beszállítók bizottsága
UK Software
Chris Palmer
Beszállítók bizottsága
CA, Egyesült Királyság
Shaheen Ramdiane
Beszállítók bizottsága
Open Text Corporation
Miroslav Širl
Beszállítók bizottsága
ICZ, Cseh Köztársaság
Andrew Snowden
Beszállítók bizottsága
Fujitsu, Egyesült Királyság
Dan Taillefer
Beszállítók bizottsága
EMC, Kanada
Nigel Wood
Beszállítók bizottsága
Fabasoft, Egyesült Királyság
Védjegyek A Specifikációban előforduló védjegyeket a rájuk vonatkozó szellemi tulajdonjogok tiszteletben tartásával kezeltük. A kereskedelmi forgalomban kapható termékek említése csak az illusztrációt szolgálja, nem jelent semmiféle elköteleződést. Hasonlóképpen, más termékek figyelmen hívül hagyásával nem kívánunk bárminemű kritikát kifejezni.
5. FÜGGELÉK – A MOREQ2 METAADAT-ELEMEK LEKÉPEZÉSE MÁS MODELLEKRE Ez a függelék bemutatja, hogy a 9. függelékben leírt metaadatmodell hogyan kapcsolódik: az ISO 23081 – Iratok metaadatai; az ISO 15836 – A Dublin Core metaadat elemkészlete szabványokhoz.
ISO 23081– Iratok metaadatai A MoReq2-ben tárgyalt egyedek hozzávetőlegesen az alábbi módon feleltethetők meg az ISO 23081 szabványban leírt egyedeknek6:
MoReq2 egyed
ISO 23081 egyed alosztály
Állomány
Item (Tétel)
Irat
Transaction sequence (Tranzakciósorozat)
Kötet Aldosszié
File/folder (Dosszié/mappa)
Dosszié Osztály
Series (***Sorozat***)
Besorolási séma
Archive (***Irattár***)
-
Archives (***Levéltár***)
A megfeleltetések természetüknél fogva csak megközelítőek. A MoReq2 modelljében a metaadatok neve két vagy három részből áll (lásd 9. függelék 6. szakasz). Ahol tehettük, a név második felét az ISO 23081-2-ből vettük át, sok végződés azonban a MoReq2 részére lett kidolgozva. A nevek forrását az alábbi táblázat foglalja össze:
ISO 23081 Metaadatcsoport MoReq2 elemnevek 2. része Identity (Azonosítás)
6
Név forrása
system_identifier (rendszerazonosító)
MoReq2
system_identifier_rendition (rendszerazonosító_átdolgozás)
MoReq2
A függelékben a hivatkozhatóság kedvéért a metaadat elemek nevét nem fordítottuk, a nevek jelentését tájékoztatás céljából zárójelben feltüntettük.
Név forrása
ISO 23081 Metaadatcsoport MoReq2 elemnevek 2. része
Description (Leírás)
Event plan (Eseményterv)
Event history (Eseménytörténet)
abstract (absztrakt)
ISO 23081
author (szerző)
MoReq2
classification (besorolás)
ISO 23081
copy_recipient (másolatot kap)
MoReq2
counter_signature (ellenjegyzés)
MoReq2
date (dátum)
MoReq2
external_identifier (külső azonosító)
MoReq2
place (hely)
ISO 23081
recipient (címzett)
MoReq2
sender (feladó)
MoReq2
title (cím)
ISO 23081
abstract (absztrakt)
MoReq2
agent (ágens)
ISO 23081
date (dátum)
ISO 23081
event_description (eseményleírás)
ISO 23081
event_trigger (eseménykiváltó)
ISO 23081
period (időszak)
MoReq2
reminder (emlékeztető)
MoReq2
status (státusz)
MoReq2
volume (kötet)
MoReq2
abstract (absztrakt)
MoReq2
date (dátum)
ISO 23081
disposal_hold (selejtezési visszatartás)
MoReq2
transfer_or_destroy megsemmisítés)
Use (Használat)
(áthelyezés
vagy ISO 23081
transferred_to (áthelyezés célja)
MoReq2
administrator (adminisztrátor)
MoReq2
inactive (inaktív)
MoReq2
language (nyelv)
ISO 23081
status (státusz)
MoReq2
technical_environment (műszaki környezet)
ISO 23081
ISO 23081 Metaadatcsoport MoReq2 elemnevek 2. része
Relation (Kapcsolat)
Név forrása
agent (ágens)
MoReq2
applies_to_agent (ágensre vonatkozik)
MoReq2
applies_to_class (osztályra vonatkozik)
MoReq2
cross_referenced_to (kereszthivatkozik)
MoReq2
disposal_hold (selejtezési visszatartás)
MoReq2
entity_agent (entitás ágens)
MoReq2
has_redaction (van maszkolt másolata)
MoReq2
has_role (van szerepköre)
MoReq2
has_user (van felhasználója)
MoReq2
is_child_of (gyereke)
MoReq2
is_member_of (tagja)
MoReq2
is_redaction_of (maszkolt másolata)
MoReq2
is_parent_of (szülője)
MoReq2
previous_fully_qualified_classification_code (korábbi teljesen minősített besorolási kód)
MoReq2
r&d_schedule (k&f ütemterv)
MoReq2
record_type (irattípus)
MoReq2
A MoReq2 és az ISO 23081 szabvány közötti további megfeleléseket a 9. függelék részletezi.
ISO 15836 – A Dublin Core metaadat-elemkészlete A Dublin Core szabványban leírt metaadat-elemek a következőképpen feleltethetők meg a MoReq2 modelljének. A nem teljes MoReq2 elemnév az összes, adott résszel kezdődő elemre utal. A “Description.abstract” például az alábbiakat mindegyikére vonatkozik: Description.abstract; Description.abstract.keywords; Description.abstract.reason_for_rendition.
Dublin Core elem
MoReq2 elem
contributor (közreműködő)
Description.sender
coverage (tér-idő vonatkozás)
-
creator (létrehozó)
Description.author
date (dátum)
Description.date
description (leírás)
Description.abstract.description Description.external_identifier.internal_reference
Dublin Core elem
MoReq2 elem
format (formátum)
Use.technical_environment.format Use.technical_environment.file_format
identifier (forrásazonosító)
Identity
language (nyelv)
Use.language
publisher (kiadó)
-
relation (kapcsolat)
Relation
rights (jogok)
-
source (eredeti információforrás)
-
subject (tárgy- és kulcsszavak, jelzetek)
Description.abstract.keyword
title (cím)
Description.title
type (típus)
Description.record_type
-
Description.abstract.mandate Description.abstract.reason_for_rendition Description.copy_recipient Description.place.current_location Description.place.home_location Description.recipient Event_history Event_plan Use.status Use.technical_environment (save as above)
A megfeleltetések természetüknél fogva csak megközelítőek. A MoReq2 és az ISO 23081 szabvány közötti további megfeleléseket a 9. függelék részletezi.
6. FÜGGELÉK – DÁTUMFELDOLGOZÁS Az EIKR köteles helyesen értelmezni a dátumokat, függetlenül attól, hogy az adott dátum ezredfordulót, századfordulót vagy egyéb, ábrázolás szempontjából kivételes napot jelképez. Jelen függelék a 2000. év feldolgozásával kapcsolatban fogalmaz meg elvárásokat, a követelmények szükség esetén más speciális dátumokra is kiterjeszthetők. A dátumok helyes feldolgozására különösen a múlt évszázadbeli iratok metaadatainál kell odafigyelni. A következő rész a BSI DISC PD2000-1:1998 A Definition of Year 2000 Conformity Requirements (A 2000. évi megfelelés követelményei) leírtak szó szerinti átvétele (a szerzői jog tulajdonosának engedélyével). A 2000. évi megfelelés értelmében a rendszer teljesítményét és funkcionalitását nem befolyásolhatja az, hogy a rendszer által kezelt dátumok a 2000. év előtti vagy utáni időpontot jelölnek. Pontosabban: 1. szabály
Az aktuális dátum nem okozhat fennakadást a rendszer működésében.
2. szabály
A dátumok kezelésével kapcsolatos funkcióknak konzisztensen viselkedniük a 2000. év előtti, közbeni és utáni dátumok esetében.
3. szabály
Minden interfész és adattár esetén a dátumokban az évszázadot explicite jelölni kell, vagy egyértelmű feloldó algoritmust vagy szabályt kell biztosítani annak kikövetkeztetésére.
4. szabály
A 2000. év szökőév.
kell
7. FÜGGELÉK – SZABVÁNYOK ÉS IRÁNYELVEK 7.1
Szabványok
Jelen függelék a Specifikációban hivatkozott, iratkezeléssel kapcsolatos szabványokat és egyéb forrásokat sorolja fel. A szabványok az EIKR-ek szempontjából kiemelt területeket fedik le; a tárolást kezelő hardverrel és az adatbázis-kezelő nyelvekkel kapcsolatos szabványokra nem térünk ki. A listán nemzetközi de jure és de facto szabványok szerepelnek. A nemzeti szabványok áttekintése kívül esik a MoReq2 hatáskörén, a tagállamok szükség esetén a nulladik fejezetben tárgyalhatják a számukra jelentőséggel bíró előírásokat. Kizárólag olyan szabványokat soroltunk fel, amelyek a rendszer tervezésére vannak közvetlen hatással; szervezetirányítási és menedzsmentbeli kérdésekkel nem foglalkozunk. A szabványok felsorolásakor legtöbbször (a teljesen minősített név helyett) a szabvány rövid neve szerepel a hivatkozás megkönnyítése végett. Amennyiben a szabvány magyar nyelven is elérhető, az eredeti változat mellett a magyar címet is feltüntettük.
FIPS 186-2
NIST Digital Signature Standard (http://csrc.nist.gov/publications/PubsFIPS.html) A szabvány nem érhető el magyar nyelven.
ISAAR(CPF)
International Standard Archival Authority Record for Corporate Bodies, Persons, and Families (International Council on Archives) (http://www.ica.org/en/node/30230) A szabvány magyar nyelven is elérhető: Szervezetek/testületek, személyek és családok levéltári azonosító leírásának nemzetközi szabványa. http://www.archivportal.hu/data/files/153021363.pdf
ISAD(G)
International Standard for Archival Description (General). (http://www.icacds.org.uk/icacds.htm) A szabvány magyar nyelven is elérhető: Az Általános Levéltári Leírás Nemzetközi Szabványa http://mlp.archivportal.hu/id-599-isad_g.html
IETF RFC 2821
Simple Mail Transfer Protocol. http://www.ietf.org/rfc/rfc2821.txt) A szabvány nem érhető el magyar nyelven.
IETF RFC 2822
Internet Message Format. (http://www.ietf.org/rfc/rfc2822.txt) A szabvány nem érhető el magyar nyelven.
ISO 216
Writing paper and certain classes of printed matter – Trimmed sizes – A and B series A szabvány nem érhető el magyar nyelven.
ISO 639
Codes for the representation of names of languages. A szabvány nem érhető el magyar nyelven.
ISO 2788
Guidelines for the establishment and development of monolingual thesauri. A szabvány nem érhető el magyar nyelven.
ISO 5964
Guidelines for the establishment and development of multilingual thesauri. A szabvány nem érhető el magyar nyelven.
ISO 8601
Representation of dates and times. A szabvány magyar nyelven is elérhető: A dátumok és az időpontok ábrázolása.
ISO 9834-8
Procedures for the operation of OSI Registration Authorities: Generation and registration of Universally Unique Identifiers (UUIDs) and their use as ASN.1 Object Identifier components (lásd még ITU X.667). A szabvány nem érhető el magyar nyelven.
ISO/TS 12033
Guidance for selection of document image compression methods. A szabvány nem érhető el magyar nyelven.
ISO/TR 12037
Recommendations for the expungement of information recorded on write-once optical media. A szabvány nem érhető el magyar nyelven.
ISO 12142
Media error monitoring and reporting techniques for verification of stored data on optical digital data disks. A szabvány nem érhető el magyar nyelven.
ISO/TR 12654
Recommendations for the management of electronic recording systems for the recording of documents that may be required as evidence, on WORM optical disk. A szabvány nem érhető el magyar nyelven.
ISO 14721
Open archival information system – Reference model (OAIS). A szabvány nem érhető el magyar nyelven.
ISO/IEC 15444
JPEG 2000 image coding system: Core coding system. A szabvány nem érhető el magyar nyelven.
ISO 15489
Records Management. A szabvány nem érhető el magyar nyelven.
ISO/TR 15801
Information stored electronically – Recommendations for trustworthiness and reliability. A szabvány nem érhető el magyar nyelven.
ISO 15836
The Dublin Core metadata element set. A szabvány magyar nyelven is elérhető: A Dublin Core metaadat elemkészlete. http://www.mszt.hu/dokumentumok/134715.pdf
ISO 18492/TR
Long-term preservation of electronic document-based information. A szabvány nem érhető el magyar nyelven.
ISO 19005-1
Electronic document file format for long-term preservation – Part 1: Use of PDF 1.4 (PDF/A-1). A szabvány nem érhető el magyar nyelven.
ISO 23081
Metadata for records. A szabvány nem érhető el magyar nyelven.
ITU X.667
Generation and registration of Universally Unique Identifiers (UUIDs) and their use as ASN.1 object identifier components. (http://www.itu.int/ITU-T/studygroups/com17/oid/X.667-E.pdf). A szabvány nem érhető el magyar nyelven.
TIFF
Tagged Image File Format. (http://partners.adobe.com/public/developer/tiff/index.html) A szabvány nem érhető el magyar nyelven. ITU-T Recommendation X.509: Open systems interconnection – The Directory: Publickey and attribute certificate frameworks. (http://www.itu.int/rec/T-REC-X.509-200003-I/en).
X.509
A szabvány nem érhető el magyar nyelven. XKMS
XML Key Management Spec. (http://www.w3.org/TR/xkms/). A szabvány nem érhető el magyar nyelven.
XML
W3C Extensible Markup Language (XML) (http://www.w3.org/TR/REC-xml/) A szabvány nem érhető el magyar nyelven.
7.2
További irányelvek
ISO/DIS 9241171
Ergonomics of human-system interaction – Part 171: Guidance on software accessibility A szabvány nem érhető el magyar nyelven.
ISO/TS 16071
Guidance on accessibility for human-computer interfaces (hamarosan érvényteleníti az ISO 9241-171). A szabvány nem érhető el magyar nyelven.
WfMC
Workflow Management Coalition Terminology & Glossary. (http://www.wfmc.org/standards/referencemodel.htm) A glosszárium nem érhető el magyar nyelven.
1999/93/EC
Directive on a Community Framework for Electronic Signatures. (http://europa.eu/scadplus/leg/en/lvb/124118.htm) Az irányelv nem érhető el magyar nyelven.
DLM Forum Guidelines
Guidelines on best practices for using electronic information. INSAR (European Archives News) Supplement III (1997). ISBN: 92-828-2285-0. (http://dlmforum.typepad.com/gdlines.pdf) Az irányelv nem érhető el magyar nyelven.
7.3
A kisegítő technológiákra vonatkozó források és irányelvek
Ez a szakasz a fejlesztők és az EIKR-beszerzők számára hasznos irányelveket és forrásokat tartalmazza. Szemben a függelék többi részével, melyek nyílt és nemzetközi publikációkat említenek, ez a szakasz olyan forrásokat sorol fel, amelyek a beszállítói közösségtől erednek. Ennek az az oka, hogy a kisegítő technológiákról eddig még egyetlen, nemzetközileg elfogadott dokumentum sem készült; elképzelhető, hogy a MoReq későbbi változatai részletesebben kitérnek erre a kérdéskörre.
Fejlesztőknek
W3C Web Content Accessibility Guidelines (for websites and web applications) (http://www.w3.org/WAI/) A leírás nem érhető el magyar nyelven. RNIB Web Access Centre (http://www.rnib.org.uk/webaccesscentre) A leírás nem érhető el magyar nyelven. RNIB Software Access Centre (http://www.rnib.org.uk/softwareaccesscentre) A leírás nem érhető el magyar nyelven. IBM Human Ability and Accessibility Centre (http://www-03.ibm.com/able/guidelines/) A leírás nem érhető el magyar nyelven. ISO/IEC 18019 Guidelines for the design and preparation of user documentation for application software (lásd kiváltképp a 4.2.6. pontot). (Hamarosan felváltja az ISO/IEC 26514 szabvány.) A szabvány nem érhető el magyar nyelven. ISO/IEC 26514 User documentation requirements for documentation designers and developers. (Fejlesztése folyamatban). A szabvány nem érhető el magyar nyelven. Beszerzéshez ACCENT – Accessibility in ICT Procurement: EU project (http://www.verva.se/english/international-network/the-accent-project/) A leírás nem érhető el magyar nyelven. PAS 78:2006 A guide to good practice in commissioning accessible websites (http://www.equalityhumanrights.com/en/publicationsandresources/Disability/Pages/Websiteaccessibi lityguidance.aspx) A leírás nem érhető el magyar nyelven. RNIB Software Access Centre (http://www.rnib.org.uk/softwareaccesscentre) A leírás nem érhető el magyar nyelven.
7.4
A digitális tartalommegőrzésre vonatkozó irányelvek
InterPARES project (http://www.interpares.org) Preserving Access to Digital Information (PADI) project National Library of Australia (http://www.nla.gov.au/padi/) A projekt leírása nem érhető el magyar nyelven. The National Archives Functional Requirements for the Sustainability of Electronic Records (http://www.nationalarchives.gov.uk/documents/functional_requirements.pdf) A követelményspecifikáció nem érhető el magyar nyelven.
7.5
A MoReq2 kapcsolata a további irányelvekkel
Az alábbiakban bemutatott grafikus modell azt ábrázolja, hogy miként kapcsolódnak a kulcsfontosságú szabványok az elektronikus iratkezeléshez. Az iratkezelés A7.1. ábrán látható új megközelítésű modelljét kifejezetten erre a célra készítették.
A7.1. ábra A modell az elektronikus iratok életciklusát képező főbb folyamatokat mutatja be. Az iratokat a középen elhelyezkedő szürke kör szemlélteti. A folyamatoknak (pl. „létrehozás”, „iktatás” stb.) a színes cikkek felelnek meg. A folyamatok száma (pontosabban a folyamatokra bontás mélysége, a modell részletgazdagsága) némileg önkényes. Számos más, az eltérő igényeket kielégítő ábrázolás is elképzelhető, az A7.1. ábrán bemutatott modell a szabványokkal való kapcsolatot szemlélteti. A folyamatokat az alábbi értelmezésben használjuk: Létrehozás. Nemcsak a szervezet belső iratainak létrehozására, hanem a szervezeten kívülről érkező iratok fogadására is vonatkozik. Iktatás. Iktatáson az iratok nyilvántartásba vétele, besorolása és a hozzá kapcsolódó metaadatok bevitele értendő. Használat. A használat magában foglalja a keresést, elérést, böngészést, megjelenítést, karbantartást, felülbírálatot stb. Megőrzés. A megőrzés az iratok hosszú távú hozzáférhetőségét biztosító folyamat. Kezelés. A kezelés része a hozzáférési szabályok és a selejtezési rendelkezések karbantartása.
A folyamatok sorrendje lényegtelen, mert a különböző környezetek eltérő sorrendet igényelhetnek. Erősen leegyszerűsítve, az elektronikus iratkezelésre vonatkozó legfontosabb szabványok az A7.2. ábrán látható módon kapcsolódnak az egyes folyamatokhoz.
A7.2. ábra Az ábrán látható kapcsolatokat a szakasz végén megismételjük nyomtatóbarát formában (színek nélkül). A modell színes félkörívekkel ábrázolja a szabványok (hozzávetőleges) relevanciáját az egyes folyamatok esetében. A színes vonalak egy vagy több szabványt jelképeznek. Ahol lehetett, a szabványokat közismert rövidítésükkel jeleztük (pl. PDF/A, OAIS) a kevésbé kifejező szabványazonosító helyett (pl. ISO 19005, ISO 14721). Az egyes szabványok azonosító sorszámát és hivatalos nevét lásd az 1. függelékben. Fontos megjegyeznünk, hogy az ehhez hasonló modellek csak hozzávetőleges képet adnak, a szabványok és folyamatok összes lehetséges kapcsolódási pontját nem célszerű szemléltetni. Bizonyos értelemben a bemutatott kapcsolatok és a kihagyott részek a készítők szubjektív nézőpontját tükrözik. A diagram csak a legfontosabbnak ítélt szabványokat ábrázolja, ezek kiválasztása önkényes volt. A modellt az alábbiakban értelmezzük. Előbb a fontosabb szabványokat, majd a folyamatokat írjuk le. ISO 15489 és MoReq2 Az ISO 15489 és a MoReq2 az elektronikus iratok teljes életciklusát lefedik, ezért az ábrán egy kör formájában átfogják az összes folyamatot.
XML Az XML – a tárolás és a megsemmisítés kivételével – a folyamatok többségénél fontos szerepet tölt be, jelentősége felhasználási környezetenként változó. Elméletileg az XML létrehozáskor befolyásolhatja az iratok formátumát, iktatáskor és a későbbi használat során pedig kihathat a metaadatok tárolásának és kifejezésének módjára; kiemelt jelentőséget nyer a metaadatok és a tartalom értelmezésében a hosszú távú megőrzés során; meghatározhatja a rendszerek közötti átvitel sémáját; felhasználható a hozzáférési szabályok, a sémák, valamint a selejtezési tevékenységek leírásához. Metaadatok A metaadatokra vonatkozó szabványok az iktatási, használati, megőrzési, áthelyezési és kezelési folyamatokban játszanak szerepet. Ide sorolhatók a következő szabványok: ISO 23081 (az iratkezeléshez kapcsolódó metaadatok kezelésének összes lehetséges nézőpontját lefedi), a Dublin Core (szabványos metaadat-halmazt ír elő), az ISO 639 (nyelvi kódok kötött szótára), az ISAD és az ISAAR (a metaadatok felhasználásáról irattárolási és levéltári környezetekben), valamint az ISO 2788 és az ISO 5984 (a tezauruszokról). Létrehozás Az iratok létrehozására vonatkozó szabványok legfőbbképpen az iratok formátumával foglalkoznak. A formátum-szabványok közül említést érdemel az RFC 2821/2822 (e-mailek formátuma), az ISO 216, a TIFF és a JPEG (szkennelt képekhez), illetve a PDF/A. Iktatás Az iktatási folyamatra egyaránt vonatkoznak a különböző metaadat-szabványok, a formátumszabványok (a metaadatok automatikus kinyerése szempontjából) és az iktatás jogi kérdéseit taglaló szabványok, mint az ISO 15801 és az ISO 12654. Használat A globálisan egyedi azonosítók (GUID-ok), az X.667, valamint a jogi szempontokat figyelembe vevő ISO 15801 és ISO 12654 szabványok befolyásolják az iratok használatát. Megőrzés A digitális megőrzés legfontosabb szabványa az OAIS, ami a megőrzési tevékenységek tervezésének és kezelésének kereteit rögzíti. Az ISO 18492 általános útmutatást ad. A megőrzési tevékenységek zöme a metaadat-szabványokra épül; a megőrzési formátumok közül népszerű a PDF/A. A digitális aláírások szabványai, az X.509 és az XKMS szintén hatással lehetnek egyes megőrzési kérdésekre. Áthelyezés A metaadat-szabványok nélkülözhetetlenek a szervezetek vagy rendszerek közötti átvitelek során. Kezelés A hozzáférés kezelését és a megőrzést támogatják a metaadat-szabványok, de figyelemre méltóak a jogi kérdéseket leíró ISO 15801 és 12654 szabványok is.
Tárolás Az ISO 12142 a tárolással kapcsolatos kérdések egy egészen kis részét érinti, az optikai lemezeken történő tárolást írja le. Megsemmisítés Az ISO 12037 a megsemmisítés egyik módjával foglalkozik, amire kevés környezetben jelentkezik igény.
Létrehozás
Iktatás
Használat
Megőrzés
Áthelyezés
Kezelés
Tárolás
Megsemmisíté s
A szabványok és a folyamatok közötti kapcsolatokat az alábbi (színektől mentes) táblázatban is összefoglaltuk. A folyamatoknak az oszlopok, a szabványoknak a sorok felelnek meg. Pipával () jelöltük egy szabvány és egy folyamat közötti kapcsolat meglétét.
ISAAR(CPF)
International Standard Archival Authority Record for Corporate Bodies, Persons, and Families (International Council on Archives).
IETF RFC 2821
Simple Mail Transfer Protocol.
IETF RFC 2822
Internet Message Format.
ISO 216
Writing paper and certain classes of printed matter – Trimmed sizes – A and B series
ISO 639
Codes for the representation of names of languages.
ISO 2788
Guidelines for the establishment and development of monolingual thesauri.
ISO 5964
Guidelines for the establishment and development of multilingual thesauri.
ISO 8601
Representation of dates and times.
ISO 9834-8
Generation and registration of Universally Unique Identifiers (UUIDs) and their use as ASN.1 Object Identifier components (see also ITU X.667).
ISO 12033
Guidance for selection of document image compression methods.
Szabvány
Létrehozás
Iktatás
Használat
Megőrzés
Áthelyezés
Kezelés
Tárolás
Megsemmisíté s
ISO 12037
Recommendations for the expungement of information recorded on write-once optical media.
ISO 12142
Media error monitoring and reporting techniques for verification of stored data on optical digital data disks.
ISO 12654
Recommendations for the management of electronic recording systems for the recording of documents that may be required as evidence, on WORM optical disk.
ISO 14721
Open archival information system – Reference model (OAIS).
ISO 15444
JPEG 2000 image coding system: Core coding system.
ISO 15489
Records Management.
ISO 15801
Information stored electronically – Recommendations for trustworthiness and reliability.
ISO 15836
The Dublin Core metadata element set.
ISO 18492
Long-term preservation of electronic document-based information.
ISO 19005-1
Electronic document file format for long-term preservation.
ISO 23081
Metadata for records.
ITU X.667
Generation and registration of Universally Unique Identifiers (UUIDs) and their use as ASN.1 object identifier components.
MoReq2
Update and extension of the Model Requirements for the management of electronic records
TIFF
Tagged Image File Format.
X.509
ITU-T Recommendation X.509: Open systems interconnection – The Directory: Public-key and attribute certificate frameworks.
XKMS
XML Key Management Specification.
Szabvány
XML Iktatás Használat Megőrzés Áthelyezés Kezelés Tárolás Megsemmisíté s
W3C Extensible Markup Language. Létrehozás
Szabvány
8. FÜGGELÉK – KÜLÖNBSÉGEK A MOREQ2 ÉS A MOREQ KÖZÖTT 8.1
Nem kompatibilis változások
A MoReq2 fejlesztői arra törekedtek, hogy a szabvány kompatibilis maradjon az eredeti MoReq változattal. A legfontosabb módosítás a korábbi változathoz képest az, hogy a szabvány megengedi az iratoknak közvetlenül az osztályokban való elhelyezését a dossziék megkerülésével. További részletekért lásd a 3.2. szakaszt. Az EIKR-nek rendelkeznie kell olyan beállítással, amellyel letiltható az iratok osztályokhoz rendelése. További újdonság a MoReq2-ben, hogy a dossziék aldossziékra és kötetekre is feloszthatók (lásd 3.3.). Ez a módosítás kompatibilis a MoReq korábbi változatával, de jelentős súllyal bír az új követelmények között. Változott emellett a megjelenítés és a megjelenítési forma kifejezések értelmezése a korábbi változathoz képest7. Az említett kifejezések pontos definícióját lásd a Szószedetben.
8.2
A szakaszok megfeleltetése
A MoReq2 felépítése a MoReq szerkezetét tükrözi, néhány apróbb változtatással és kiegészítéssel. Az alábbi táblázatban összefoglaltuk a MoReq és a MoReq2 szakaszai közötti megfeleléseket.
MoReq Fejezet
MoReq2 Cím
Fejezet
Előszó
Cím Előszó: MoReq2
1.
Bevezetés
1.
Bevezetés
1.1.
Előzmények
1.1.
Előzmények
1.2.
A Specifikáció célja és hatásköre
1.3.
A Specifikáció célja és hatásköre
1.3.
Mi az EIKR?
1.4.
Mi az EIKR?
1.4.
A Specifikáció felhasználási területei
1.5.
A Specifikáció felhasználási területei
1.5.
A Specifikáció hangsúlyos részei és korlátai
1.7.
A Specifikáció hangsúlyos részei és korlátai
1.6.
A Specifikáció felhasználása
1.9.
A Specifikáció testreszabása
1.7.
A Specifikáció szerkezeti felépítése
1.10.
A Specifikáció szerkezeti felépítése
1.8.
Kötelezően előírt és kívánatos követelmények
1.12.
Kötelezően előírt és kívánatos követelmények
1.9.
Szellemi tulajdonjogok
1.6.
Szellemi tulajdonjogok
2.
Az EIKR követelmények áttekintése
2.
Az EIKR követelmények áttekintése
2.1.
Kulcsfontosságú szakkifejezések
2.1.
Kulcsfontosságú szakkifejezések
2.2.
Alapfogalmak
2.2.
Alapfogalmak
2.3.
Egyed-kapcsolat modell
2.3.
Egyed-kapcsolat modell
7
Mivel a presentation és a rendering kifejezéseknek magyarul egyformán a megjelenítés felel meg – a megjelenítési forma a MoReq2 kedvéért alkotott műszó –, a két kifejezés értelmezésének felcserélése a MoReq2-ben fordítás után elvész. Ezért a táblázatban a MoReq2-nek megfelelő kifejezések szerepelnek mindkét oszlopban.
MoReq
MoReq2
Fejezet
Cím
Fejezet
Cím
3.
Besorolási sémák
3.
Besorolási sémák és az iratok rendszerezése
3.1.
A besorolási séma konfigurálása
3.1.
A besorolási séma konfigurálása
3.2.
Osztályok és dossziék
3.2.
Osztályok és dossziék
3.3.
Kötetek és aldossziék
3.3.
Kötetek és aldossziék
3.4.
A besorolási séma karbantartása
3.4.
A besorolási séma karbantartása
4.
Ellenőrzés és biztonság
4.
Ellenőrzés és biztonság
4.1.
Hozzáféréskorlátozás
4.1.
Hozzáféréskorlátozás
4.2.
Eseménynapló
4.2.
Eseménynapló
4.3.
Biztonsági mentés és visszaállítás
4.3.
Biztonsági mentés és visszaállítás
4.4.
Az iratok áthelyezéseinek nyomonkövetése
Törölve (áthelyezve a 10.1. szakaszba)
4.5.
Hitelesség
Törölve (áthelyezve a 2. fejezetbe)
4.6.
Biztonsági kategóriák
10.15.
Biztonsági kategóriák
5.
Megőrzés és selejtezés
5.
Megőrzés és selejtezés
5.1.
Megőrzési ütemtervek
5.1.
Megőrzés és selejtezési ütemtervek
5.2.
Felülbírálat
5.2.
A selejtezési tevékenységek felülbírálata
5.3.
Áthelyezés, exportálás és megsemmisítés
5.3.
Áthelyezés, exportálás és megsemmisítés
6.
Iratok iktatása
6.
Iktatás és irattá nyilvánítás
6.1.
Iktatás
6.1.
Iktatás
6.2.
Tömeges importálás
6.2.
Tömeges importálás
6.3.
Dokumentumtípusok
6.4.
Az e-mailek (elektronikus levelek) kezeléséről
6.3.
Az e-mailek (elektronikus levelek) kezeléséről
7.
Azonosítók
7.
Azonosítók
8.
Keresés, kinyerés és megjelenítés
8.
Keresés, kinyerés és megjelenítés
8.1.
Keresés és kinyerés
8.1.
Keresés és kinyerés
8.2.
Megjelenítés: az iratok megjelenítése képernyőn
8.2.
Megjelenítés: az iratok megjelenítése képernyőn
8.3.
Megjelenítés: nyomtatás
8.3.
Megjelenítés: nyomtatás
8.4.
Megjelenítés: egyéb
8.4.
Megjelenítés: egyéb
9.
Adminisztrátori feladatok
9.
Adminisztrátori feladatok
9.1.
Általános adminisztráció
9.1.
Általános adminisztráció
9.2.
Jelentések készítése
9.2.
Jelentések készítése
9.3.
Iratok módosítása, törlése és maszkolása
9.3.
Iratok módosítása, törlése és maszkolása
10.
További funkciók
10.
Opcionális modulok
Törölve (áthelyezve a 6.1. szakaszba)
MoReq
MoReq2
Fejezet
Cím
Fejezet
Cím
10.1.
A nem elektronikus iratok kezeléséről
10.1.
Fizikai (nem elektronikus) dossziék és iratok kezelése
10.2.
Hibrid dossziék megőrzése és selejtezése
10.2.
Fizikai iratok selejtezése
10.3.
Dokumentumkezelése
10.3.
Dokumentumkezelés és kollaboráció
10.4.
Munkafolyamatok
10.4.
Munkafolyamatok
10.5.
Digitális aláírások
10.7.
Elektronikus aláírások
10.6.
Titkosítás
10.8.
Titkosítás
10.7.
Elektronikus vízjelek stb.
10.9.
Digitális jogkezelés
10.8.
Interoperabilitás és nyíltság
11.
Nem funkcionális követelmények
11.
Nem funkcionális követelmények
11.1.
Használhatóság
11.1.
Használhatóság
11.2.
Teljesítmény és skálázhatóság
11.2.
Teljesítmény és skálázhatóság
11.3.
A rendszer rendelkezésre állása
11.3.
A rendszer rendelkezésre állása
11.4.
Műszaki szabványok
11.4.
Műszaki szabványok
11.5.
Jogi és szabályozási követelmények
11.5.
Jogi és szabályozási követelmények
11.6.
Kiszervezett adatkezelés
11.6.
Kiszervezett adatkezelés
11.7.
Hosszú távú megőrzés és a technológiák elavulása
11.7.
Hosszú távú megőrzés és a technológiák elavulása
12.
Metaadat-követelmények
12.
Metaadat-követelmények
12.1.
Alapelvek
12.1.
Alapelvek
12.2.
A fejezet további részeinek felépítése
9.1. függ.
Bevezetés
12.3.
Besorolási séma és metaadat-elemek
9.7.1. függ.
Besorolási sémák
12.4.
Osztályok és elektronikus dossziék metaadat-elemei
9.7.2. függ.
12.5.
Elektronikus dossziék és dossziékötetek metaadat-elemei
9.7.2. függ.
Osztályok, dossziék, aldossziék, kötetek Osztályok, dossziék, aldossziék, kötetek
12.6.
Elektronikus kötetek metaadat-elemei
9.7.2. függ.
12.7.
Iratok metaadat-elemei
9.7.2. függ.
12.8.
Iratkivonatok metaadat elemei
9.7.3. függ.
Maszkolt másolatok
12.9.
Felhasználók metaadat-elemei
9.7.8. függ.
Ágensek (felhasználók, felhasználói csoportok és szerepkörök)
12.10.
Szerepkörök metaadat-elemei
9.7.8. függ.
Ágensek (felhasználók, felhasználói csoportok és szerepkörök)
12.11.
A metaadat-követelmények személyre szabása
9.9. függ.
A metaadat-követelmények személyre szabása
13.
Hivatkozási modell
13.
Hivatkozási modell
13.1.
Szószedet
13.1.
Szószedet
Törölve (áthelyezve az 5 és 6. fejezetbe, ill. 10.6. szakaszba)
Osztályok, dossziék, aldossziék, kötetek Osztályok, dossziék, aldossziék, kötetek
MoReq
MoReq2
Fejezet
Cím
Fejezet
Cím
13.2.
Egyed-kapcsolat modell
13.2.
Egyed-kapcsolat modell
13.3.
Az egyed-kapcsolat modell kifejtése
13.3.
Az egyed-kapcsolat modell kifejtése
13.4.
Hozzáférés-szabályozási modell
13.4.
Hozzáférés-szabályozási modell
JEGYZÉKEK
FÜGGELÉKEK
1. jegyz.
Hivatkozások
1. függ.
Hivatkozások
2. jegyz.
A Specifikáció fejlesztésének története
2. függ.
A Specifikáció fejlesztésének története
3. jegyz.
A Specifikáció elektronikus formában történő felhasználásáról
3. függ.
A Specifikáció elektronikus formában történő felhasználásáról
4. jegyz.
Köszönetnyilvánítás
4. függ.
Köszönetnyilvánítás
1.
A projekt tagjai
4.1. függ.
A projekt tagjai
4.2. függ.
Szerkesztőbizottság
4.3. függ.
DLM Forum
4.4. függ.
Bírálóbizottságok
2.
Validáló szervezetek
3.
Védjegyek
4.5. függ.
Védjegyek
5. jegyz.
A MoReq2 metaadat-elemek leképezése más modellekre
5. függ.
A MoReq2 metaadat-elemek leképezése más modellekre
1.
Összehasonlítás a Dublin Core metaadat-elemkészletével
5.2. függ.
ISO15836 – A Dublin Core metaadatelemkészlete
2.
Összehasonlítás a Pittsburgh metaadat-elemkészletével
-
-
6. jegyz.
Dátumfeldolgozás
6. függ.
Dátumfeldolgozás
7. jegyz.
Szabványok és irányelvek
7. függ.
Szabványok és irányelvek
1.
Szabványok
7.1. függ.
Szabványok
2.
További irányelvek
7.2. függ.
További irányelvek
3.
Kisegítő technológiákra vonatkozó irányelvek
7.3. függ.
A kisegítő technológiákra vonatkozó források és irányelvek
4.
A digitális tartalommegőrzésre vonatkozó irányelvek
7.4. függ.
A digitális tartalommegőrzésre vonatkozó irányelvek
9. FÜGGELÉK – METAADATMODELL A 9. függelék írja le a MoReq2 metaadat-modelljét. Terjedelmi és hivatkozási okokból az angol nyelvű 9. függelék csak elektronikus formában érhető el a www.dlmnetwork.org/moreq2 címen. Magyar fordítás a 9. függelékről nem készült.
