Digital Archive IT system for the Republic administration for geodetic and property affairs of

Republic of Srpska (RSGA), Case no. 16/07231

Appendix 1

Development of Digital Archive IT System

Technical Requirements
Content
1 Introduction .................................................................................................................................. 3
1.1 Purpose .........................................................................................................................................3
1.2 RSGA Digital Archive overall content and functionality ...............................................................3
1.3 Scope of this document ................................................................................................................3
1.4 Business Needs .............................................................................................................................4
1.5 Key Stakeholders ..........................................................................................................................5
1.5.1 Responsibility ............................................................................................................................5
1.5.2 Business Needs .........................................................................................................................5
2 General Architecture Principles .................................................................................................... 6
3 Architecture Decisions and Rationale ........................................................................................... 8
4 Views and Models ......................................................................................................................... 9
4.1 Context view .................................................................................................................................9
4.1.1 Concerns ...................................................................................................................................9
4.1.2 Stakeholders .............................................................................................................................9
4.2 Context model ..............................................................................................................................9
4.3 Functional view...........................................................................................................................10
4.4 Functional model ........................................................................................................................11
4.5 Information view ........................................................................................................................11
4.6 Static information structure models ..........................................................................................12
4.6.1 Austrian Land Register and Land Cadaster .............................................................................13
4.6.2 Land Cadaster, Topographic Maps, Geodetic Points and Ortophoto .....................................14
4.6.3 Census Cadaster......................................................................................................................15
4.6.4 Revision...................................................................................................................................16
4.6.5 Property Affairs.......................................................................................................................16
4.6.6 Communal Devices Cadaster ..................................................................................................16
4.6.7 Book of Deposited Contracts buying ...................................................................................17
4.6.8 Book of Deposited Contracts selling ....................................................................................17
4.6.9 Office Management ................................................................................................................17
4.6.10 Books ..................................................................................................................................17
4.6.11 Land Registry ......................................................................................................................18
4.6.12 Other Documents ...............................................................................................................18
4.7 Deployment view ........................................................................................................................18
5 Requirements .............................................................................................................................. 20
5.1 General Technical Requirements ...............................................................................................20
5.2 Functional Requirements ...........................................................................................................22
5.3 Non-Functional Requirements ...................................................................................................29
6 Appendices .................................................................................................................................. 37

1
6.1 References ..................................................................................................................................37
6.2 Definitions...................................................................................................................................38
6.3 List of Acronyms .........................................................................................................................40

2
1 INTRODUCTION
This document is related to the project Maps for National Development and European Integration
where Statens kartverk1 (The Norwegian Mapping Authority) is supporting both Administration for
Geodetic and Real Property Affairs in Bosnia and Herzegovina: Republic Administration for Geodetic and
Real Property Affairs (RSGA)2 and Federal Administration for Geodetic and Real Property Affairs (RSGA)3
with developing digital archives.
The complementary project "Capacity Building for Improvement of Land Administration and Procedures
in Bosnia and Herzegovina" (CILAP)4, financed by Lantmteriet5, focuses on strengthening and
development of the land administration institutions and business processes, human resources, education
and training in using of modern survey technology, development of a legislation framework, property and
land valuation system, an work processes utilizing new, modern digital archives.

1.1 Purpose
The purpose of this document is to provide the necessary background information, business needs,
system scope, and high-level technical specifications for the outsourcing of the detailed design,
development and the implementation of a Digital Archive IT system, to be installed at RSGA.

1.2 RSGA Digital Archive overall content and functionality

RSGA digital archive (DA) is consisting of an DA IT system, and an organization of people that has accepted
the responsibility to preserve relevant RSGA data and make it available for an identified group of potential
consumers who should be able to understand a particular set of preserved data.
The DA IT system is a multitier web-based system that will be used at central level, as well as at cadaster
offices.
The DA will hold documents in various formats. The documents shall be searched by their metadata only,
except for documents having text in readable form, where free text search should be enabled. Search for
documents using spatial criteria is limited to location data contained in the related metadata.
The DA is a responsive multitier web-based application that enables the following key functionalities:
- Archive and store data in an organized way with versioning to be reflected in the metadata,
- Enables metadata management (metadata editor),
- Enables creating data templates and data groups,
- Enables a secure and controlled data access and modification,
- Enables data search and filters based on metadata and simple spatial criteria as far as such data
are contained in the metadata,
- Enables controlled and monitored import and export of data,
- Enables interaction with other systems using SOA and
- Enables backup and safe storage procedures.

1.3 Scope of this document

The scope of the document is to:
Give an overall picture of the background and environment of the system,

1 http://www.statkart.no
2 http://www.rgurs.org
3 http://www.fgu.com.ba
4 http://www.cilap-project.org
5 http://www.lantmateriet.se

3
 Describe the system architecture,
Specify the overall system requirements,
Specify the non-functional requirements.

The contractor has the obligation to implement the metadata for each of the classes of archive
documents listed and described in chapter 4.6. The contractor, will consider technical requirements
information contained in this document and all other information that the RSGA will provide during
implementation. If the contractor needs other information for the modifications of metadata, the RSGA
will provide clarifications upon request. In case there is a need for metadata modifications during the
project implementation the contractor can propose changes to the metadata specifications, which need
to be accepted by the RSGA.

1.4 Business Needs

The overall business needs to be covered by the DA (Digital Archive IT System) include:
1. Capture
The system needs to support capturing scanned as well as scanned and georeferenced documents
through a set of predefines business processes. The process of capturing metadata should be automatic
wherever possible (including reading a georeferenced raster location if available). A function to transfer
access rights and metadata from other documents or document sets should be implemented.
2. Dynamic content templates and user access groups
The system needs to enable creation of new content templates or change existing ones. This includes but
is not limited to creating templates with corresponding metadata and spatial references. The same apply
to templates for group of documents. The administrator needs to be able to create users and groups of
users and assign corresponding rights for the users for access to groups of documents or single
documents.
3. Store
The system needs to store all data/documents in an enterprise content repository with versioning
enabled. The system should also support storing original (lossless compression) and compressed (lossy
compression) files for easier distribution.
4. Manage
The system needs to provide content/document6 management and users management.
5. Preserve
The system needs to provide long-term, safe storage and backup of static, archive documents, as well
documents incoming from RSGA internal systems7. The backup procedures should be differential, should
run at times defined by RSGA (hourly, daily, weekly) and do not have to be a part of the software itself
but configured externally. Backup reporting should be implemented.
6. Dissemination
The system needs to provide application services, which can be used by internal systems to search for
and show archive data/documents.

6 Archive documents, files, maps and documents from FGA internal systems.
7 RSGA internal systems are listed in 4.1.1.2.

4
7. Data/Document Search & Access
The system needs to provide advanced search capabilities based on the document itself (if the document
can be read), document metadata and spatial query (if the related metadata has a spatial component8),
all according to the UML metadata models. The access to documents should be controlled through
dynamic user rights that can be applied to a single document or a set of documents and are controlled by
the administrator. Document access should be provided as read only (access only through the
application), watermarked document download, compressed document downloads and original
document download. The system needs to track user activity in regards to system usage and provide the
administrator with reporting capabilities.

1.5 Key Stakeholders

The table below shows the main stakeholders related to the DA, and summarizes their responsibilities
and business needs.

Stakeholder 1.5.1 Responsibility 1.5.2 Business Needs

Tool for centralized archiving
RSGA Archiving
and content distribution
DA user management
System administration
IT infrastructure
System maintenance
Data replication
Access control
Capturing data
Managing data
Preserving data
QC tool
Managing Replication
Convert data from paper into
Internal ISs (via Data capture
an electronic format
services) File management
Search DA
Provide DA content
Retrieve DA data/documents
Consume DA content
Provide data/documents to
DA
Search DA
External systems - via Consume DA content
Retrieve DA data/documents
services (see 4.1.1.2)

Table 1.1: Stakeholders, their responsibilities and business needs

8
Term spatial component in this documents implies MBR (minimum bounding rectangle) of the space
covered by documents content.
5
2 GENERAL ARCHITECTURE PRINCIPLES
Architecture of a software-intensive system is the structure or structures of the system, which comprise
software elements, the externally visible properties of those elements, and the relationships among
them. The system architecture defines four different aspects of system:
1. Static structures
Specify the design-time form of a system, i.e. its internal design-time elements (modules, services,
classes, computers, routers) and their arrangement.
2. Dynamic structures
Specify how the system actually works and what the system does in response to external (or internal)
stimulus. Dynamic structures define run-time elements of system and their interactions.
3. Externally visible behavior
Specifies what a system does from the viewpoint of an external observer, i.e. defines the functional
interactions between the system and its environment.
4. Quality properties
An externally visible, nonfunctional properties of a system such as performance, security, or scalability.
System architecture is an abstraction - an architecture description captures architecture. The architecture
description is inherently multi-view. No single view is sufficient to capture architecture because
architecture is multi-disciplinary, with multiple stakeholders and multiple architecture-related concerns
that the architect must deal with. The viewpoints (perspectives on the architecture) are separated from
views (what is captured in the description of a specific architecture from the perspective of a viewpoint
for a system of interest). This distinction is motivated by the body of existing practice that defines
viewpoints for a number of architecture-related concerns. There should be a viewpoint for each view -
the viewpoint explains the conventions being used in that view.
According to [1] an architecture description contains the following:
Identification of the stakeholders for the architecture and the system of interest,
Identification of the architecture-related concerns of those stakeholders,
A set of architecture viewpoints defined so that all of the stakeholder concerns are covered by
that set of viewpoints,
A set of architecture views, such that there is one view for each viewpoint,
A set of architecture models from which the views are composed.
Figure 2.1 depicts concepts pertaining to the practice of architecture description when applying
ISO/IEC/IEEE 42010 Standard [1] to produce architecture description expressing architecture for the
system-of-interest.
A system is built to address the needs, concerns, goals and objectives of its stakeholders. Stakeholders of
a system have concerns with respect to the system-of-interest considered in relation to its environment.
A concern could be held by one or more stakeholders. Concerns arise throughout the life cycle from
system needs and requirements, from design choices and from implementation and operating
considerations. A concern could be manifest in many forms, such as in relation to one or more stakeholder
needs, goals, expectations, responsibilities, requirements, design constraints, assumptions,
dependencies, quality attributes, architecture decisions, risks or other issues pertaining to the system.
The system architecture is comprised of a number of architecture elements and their relationships, and
can be documented by an architecture description.
An architecture description documents architecture for its stakeholders and demonstrates to them that
it has met their needs. It includes one or more architecture views.

6
A viewpoint defines the aims, intended audience, and content of a class of views and defines the concerns
that views of this class will address.

Fig. 2.1. Conceptual model of an architecture description

A view conforms to ta viewpoint and so communicates the resolution of a number of concerns. An
architecture description comprises a number of views. It addresses one or more of the concerns held by
the systems stakeholders. The architecture view is composed of one or more architecture models.
An architecture model uses modelling conventions appropriate to the concerns to be addressed. These
conventions are specified by the model kind governing that model. Within an architecture description,
an architecture model can be a part of more than one architecture view.

7
3 ARCHITECTURE DECISIONS AND RATIONALE
The decision on global system architecture is influenced by a number of relevant factors and architectural
principles - all of them have been considered and excessively discussed with RSGA and a centralized
multitier system should be implemented. The two factors that have primarily influenced the global
system architecture are: organization of geodetic administration and telecommunication infrastructure.
RSGA is centralized institution, so the DA of RSGA will be implemented as a centralized system (Fig. 3.1).

Fig. 3.1 RSGA DA as centralized system

Hardware is not part of this procurement. It is obligation of RSGA to provide all hardware necessary for
the implementation of this project.

8
4 VIEWS AND MODELS
4.1 Context view
The Context view describes relationships, dependencies and interactions between DA system and its
environment - the people, systems and external entities with which it interacts. It defines what the system
does and does not do; where the boundaries are between it and the outside world; and how the DA
system interacts with other systems and organizations across these boundaries.
4.1.1 Concerns
4.1.1.1 System scope and responsibilities
This concern does not extend to a complete definition of the systems requirements. System scope
encompasses:
Capturing, storing, managing and distribution of archival data,
Preserving all archive information in a central repository and make them available for an
identified group of users and potential customers,
Data, metadata and spatial search capabilities for all data stored,
Supporting regular and ad hoc extracts to the publishing repository,
Support for integration and communication with other systems via SOA.
4.1.1.2 Identity of external entities and services
There are several existing and future systems that should be able to integrate with DA. This is why the
main business functionalities of the DA should be exposed to other systems. The bidder has no
responsibility for developing the service interfaces in the existing RSGA internal systems the
corresponding system providers will develop them.
4.1.1.3 Identity and responsibilities of external interfaces
RSGA internal systems mentioned in may have one or more of the following responsibilities:
Data provider the system that supplies data directly to DA.
Data consumer the system that receives data directly from DA.
Service consumer the system that request some action of DA.
4.1.2 Stakeholders
Stakeholder concerns for the Context viewpoint are listed in Table 4.1:

Stakeholder Class Concerns

System scope and responsibilities External systems and services

Acquires

Developers

System administrator

Users

Table 4.1. Stakeholders concerns for the Context viewpoint

4.2 Context model

This model presents an overall picture of DA in its environment in RSGA headquarters and relations to
other systems with which it might interact in the future. Application integration, i.e., interaction with
other systems at RSGA headquarter will be based on service oriented architecture (SOA).
9
 Fig. 4.1. RSGA DA Context diagram

4.3 Functional view

The Functional view defines the architecture elements that deliver the DAs functionality. It describes the
systems runtime functional components and their responsibilities, interfaces and primary interactions.
This view frames the following concerns of all stakeholders:
Functional capabilities define what the system is required to do, and implicitly, what is not
required to do.
External interfaces data and control flows between the system and external systems.
Internal structure defined by internal elements (components), i.e. what they do and how they
interact with each other.
Stakeholder concerns for the Functional viewpoint are listed in Table 4.2:

Stakeholder Class Concerns

Functional capabilities External interfaces Internal structure

Acquires

Developers

System administrator

Users

Table 4.2: Stakeholders concerns for the Functional viewpoint

10
4.4 Functional model
UML component diagram (Fig 4.2) describes OAIS-compliant functional model9.

Fig 4.2. Digital Archive - UML Component diagram

The Ingest component should provide the services and functions to accept Submission Information
Packages (SIPs) from Producers (or from internal elements under Administration control) and prepare the
contents for storage and management within DA. Ingest functions should include receiving SIPs,
performing quality assurance on SIPs, generating an Archival Information Package (AIP) which complies
with the DAs data formatting and documentation standards, extracting Descriptive Information from the
AIPs for inclusion in the DA database, and coordinating updates to Archival Storage and Data
Management.
The Archival Storage component should provide the services and functions for the storage, maintenance
and retrieval of AIPs. Archival Storage functions should include receiving AIPs from Ingest and adding
them to permanent storage, managing the storage hierarchy, refreshing the media on which DA holdings
are stored, and providing AIPs to Access to fulfill orders.
The Data Management component should provide the services and functions for populating, maintaining,
and accessing both Descriptive Information, which identifies and documents DA holdings and
administrative data used to manage DA. Data Management functions should include administering the
DA database functions, performing database updates (loading new descriptive information or DA
administrative data), performing queries on the data management data to generate query responses, and
producing reports from these query responses.
The Administration component should provide the services and functions for the overall operation of the
DA.
The Access component should provide the services and functions that support Consumers in determining
the existence, description location and availability of information stored in DA, and allowing Consumers
to request and receive information products. Access functions should include communicating with
Consumers to receive requests, applying controls to limit access to specially protected information,
coordinating the execution of requests to successful completion, generating responses (Dissemination
Information Packages, query responses, reports) and delivering the responses to Consumers.

4.5 Information view

This view describes the way that DA system stores information. The Information view frames the
following concerns of stakeholders:

9Potenital bidders are allowed to propose alternative UML model which provide equivalent functional
capabilities.
11
 Information structure and content the structure and content of the information that DA stores,
manages and distributes.
Information flow the way that information moves around system and is accessed, modified and
distributed by its components.
Stakeholder concerns for the Information viewpoint are listed in Table 4.3:

Stakeholder Class Concerns

Information structure and content Information flow

Acquires

Developers

System administrator

Users

Table 4.3: Stakeholders concerns for the Information viewpoint

4.6 Static information structure models

DA shall store the following classes of archive10 documents and data from:
Austrian Land Register and Land Cadaster
Land Cadaster, Topographic Maps, Geodetic Points and Ortophoto
Census Cadaster
Revision
Property Affairs
Communal Devices Cadaster
Book of Deposited Contracts buying
Book of Deposited Contracts selling
Office Management
Books
Land Registry
Other Documents
Real Estate Cadaster 1984
Real Estate Cadaster 1996
Real Estate Cadaster 2006
Real Estate Cadaster 2012
Topographic maps
Geodetic points
Ortophoto
Content of Archive of B&H
Vectorized geodetic maps
The list above represents the minimum set of document/content types to be implemented by the DA
System. However, the DA must support creation of new document/content types along with its metadata
through an administrative interface.

10Archive documents do not include documents from the exisitng internal systems listed in 4.1.1.2.
However, DA component shall be able to manage documents from these systems.
12
Static information structures models (i.e. metadata specification) for these document classes are
presented in sections 4.6.1 4.6.12. These are the foundation for specifying the structure of the
metadata. The final set of metadata will be defined during the implementation of the project.
4.6.1 Austrian Land Register and Land Cadaster
The most important metadata (describing all document types) are as follows:
level political municipalities mandatory, one of many predefined values,
cadastral municipality mandatory, one of many predefined values,
document type mandatory, one of many predefined values,
document name mandatory,
number of files number of images or pages in a document mandatory,
note not mandatory.
Depending on the document type, the following metadata can appear:
1. Plans and sketches (Planovi i skice)
contents mandatory, one of many predefined values,
nomenclature not mandatory.

2. Census lists (Popisni listovi)

census list number mandatory, one of many predefined values.

3. Possession lists and collection lists (Posjedovni listovi i Sabirni listovi)

possession/collection list number mandatory.

4. Collection of documents (Zbirka isprava)

year mandatory, one of many predefined values,
number of documents mandatory,
list of changes mandatory, one or many,
parcel number mandatory, one or many,
possession list mandatory, one or many,
party mandatory, one or many,
subject type mandatory, one or many.

5. List of changes nad Other documents (Lista promjena, Drugi dokumenti)

year.

Fig 4.3. Austrian Land Register and Land Cadaster UML class diagram

13
4.6.2 Land Cadaster, Topographic Maps, Geodetic Points and Ortophoto
The most important metadata (describing all document types) for Land Cadaster are as follows:
level political municipalities mandatory, one of many predefined values,
cadastral municipality mandatory, one of many predefined values,
document type mandatory, one of many predefined values,
content mandatory, one of many predefined values,
document name not mandatory for all document types,
number of files number of images or pages in a document mandatory,
note not mandatory,
year not mandatory for all document types, one of many predefined values,
land possession list mandatory only for land possession list document type, one or many,
census list mandatory only for census list document type,
document number mandatory,
list of changes not mandatory, one or many,
parcel number not mandatory, one or many,
party mandatory, one or many,
subject type mandatory, one or many,
PL number, one or many.

Fig 4.4. Land Cadaster, Topographic Maps and Ortophoto UML class diagram
The most important metadata for Topographic Maps are as follows:

14
 document type mandatory, one of many predefined values,
content mandatory, one of many predefined values,
document name mandatory,
number of files number of images or pages in a document mandatory,
note not mandatory,
year mandatory, one of many predefined values,
nomenclature mandatory.

4.6.3 Census Cadaster

The most important metadata are as follows:
level political municipalities mandatory, one of many predefined values,
cadastral municipality mandatory, one of many predefined values,
document type mandatory, one of many predefined values,
content mandatory, one of many predefined values,
document name mandatory,
year mandatory only for Collection of documents, one of many predefined values,
number of files number of images or pages in a document mandatory,
note not mandatory,
census list mandatory,
list of changes not mandatory, one or many,
document number mandatory,
land census list mandatory only for land census list document type, one or many,
parcel number not mandatory, one or many,
party not mandatory, one or many,
subject type mandatory, one or many,
PL number not mandatory, one or many.

Fig 4.5. Census cadaster UML class diagram

15
4.6.4 Revision
The most important metadata (describing all document types) for Revision are as follows:
level political municipalities mandatory, one of many predefined values,
cadastral municipality mandatory, one of many predefined values,
document type mandatory, one of many predefined values,
document name not mandatory for all document types,
number of files number of images or pages in a document mandatory,
note not mandatory.

4.6.5 Property Affairs

The most important metadata (describing all document types) for Property Affairs are as follows:
level political municipalities mandatory, one of many predefined values,
cadastral municipality mandatory, one or many of many predefined values,
document type mandatory, one of many predefined values,
classification mandatory, one of many predefined values,
subject type mandatory, one of many predefined values,
document name not mandatory for all document types,
year mandatory, one of many predefined values,
document number mandatory,
party mandatory, one or many,
cadastral parcel mandatory, one or many,
land-registry slip/sheet/parcel mandatory, one or many,
possession list mandatory 1/311, one or many,
cadastral-registry slip/sheet mandatory 1/312, one or many,
immobilities list mandatory 1/313, one or many,
number of files number of images or pages in a document mandatory,
note not mandatory.

4.6.6 Communal Devices Cadaster

The most important metadata (describing all document types) for Communal Devices Cadaster are as
follows:
level political municipalities mandatory, one of many predefined values,
cadastral municipality mandatory, one or many of many predefined values,
document type mandatory, one of many predefined values,
maintenance / establishment mandatory, one of many predefined values,
year mandatory, one of many predefined values,
document number mandatory 1/214,
registration number mandatory 1/215,
type of line mandatory, one or many of many predefined values,

11
one of the following is mandatory: possession list, cadastral-registry slip/sheet, immobilities list
12
one of the following is mandatory: possession list, cadastral-registry slip/sheet, immobilities list
13
one of the following is mandatory: possession list, cadastral-registry slip/sheet, immobilities list
14
one of the following is mandatory: document number, registration number
15
one of the following is mandatory: document number, registration number
16
 nomenclature mandatory,
number of files number of images or pages in a document mandatory,
note not mandatory.

4.6.7 Book of Deposited Contracts buying

The most important metadata (describing all document types) for Book of Deposited Contracts buying
are as follows:
level political municipalities mandatory, one of many predefined values,
cadastral municipality mandatory, one of many predefined values,
document type mandatory, one or many of many predefined values,
document name not mandatory for all document types,
year mandatory, one of many predefined values,
document number mandatory,
subject type mandatory, one or many of many predefined values,
entry number not mandatory, one or many,
parcel number not mandatory, one or many,
object number not mandatory, one or many,
number of files number of images or pages in a document mandatory,
note not mandatory.

4.6.8 Book of Deposited Contracts selling

The most important metadata (describing all document types) for Book of Deposited Contracts selling
are as follows:
level political municipalities mandatory, one of many predefined values,
cadastral municipality mandatory, one of many predefined values,
document type mandatory, one of many predefined values,
document name not mandatory for all document types,
year mandatory, one of many predefined values,
document number mandatory, one or many,
subject type mandatory, one or many,
entry number not mandatory, one or many,
parcel number not mandatory, one or many,
object number not mandatory, one or many,
number of files number of images or pages in a document mandatory,
note not mandatory.

4.6.9 Office Management

The most important metadata (describing all document types) for Office Management are as follows:
level political municipalities mandatory, one of many predefined values,
document type mandatory, one of many predefined values,
document name not mandatory for all document types,
year mandatory, one or many of many predefined values,
number of files number of images or pages in a document mandatory,
note not mandatory.

4.6.10 Books
The most important metadata (describing all document types) for Books are as follows:

17
 level political municipalities mandatory, one of many predefined values,
document type mandatory, one of many predefined values,
field mandatory, one of many predefined values,
document name not mandatory for all document types,
year mandatory,
number of files number of images or pages in a document mandatory,
note not mandatory.

4.6.11 Land Registry

The most important metadata (describing all document types) for Land Registry are as follows:
level political municipalities mandatory, one of many predefined values,
cadastral municipality mandatory, one or many of many predefined values,
document type mandatory, one of many predefined values,
document name mandatory,
year not mandatory for all document types, one of many predefined values,
document number mandatory for all documents created after 2007, one or many,
DN number mandatory, one or many,
parcel not mandatory, one or many,
land-registry slip/sheet mandatory for land-registry document type, one or many,
party mandatory, one or many,
subject type mandatory, one or many,
number of files number of images or pages in a document mandatory,
note not mandatory.

4.6.12 Other Documents

The most important metadata (describing all document types) for Other Documents are as follows:
level political municipalities mandatory, one of many predefined values,
document name not mandatory for all document types, one of many predefined values,
content mandatory, one of many predefined values,
subject type mandatory, one of many predefined values,
number of files number of images or pages in a document mandatory,
note not mandatory.

4.7 Deployment view

This view describes the environment into which the system will be deployed; including the dependencies
the system has on its runtime environment.

Stakeholder Class Concerns

Runtime platform models Specification of hosting

Developers

System administrators

Testers

18
Fig 4.10. Deployment at RSGA

19
5 REQUIREMENTS
5.1 General Technical Requirements

Req. ID Requirement Description Type

GTR-1 Core functions Capturing, storing, managing, Mandatory

preservation and distribution of
DA content.

GTR-2 SOA Integration and interoperability Mandatory

with other systems shall be
based on SOA.

GTR-3 Data/Content The DA shall capture, store, Mandatory

manage, preserve and distribute
the following data/content:
Austrian Land Register
and Land Cadaster
Land Cadaster,
Topographic Maps,
Geodetic Points and
Ortophoto
Census Cadaster
Revision
Property Affairs
Communal Devices
Cadaster
Book of Deposited
Contracts buying
Book of Deposited
Contracts selling
Office Management
Books
Land Registry
Other Documents
Real Estate Cadaster
1984
Real Estate Cadaster
1996
Real Estate Cadaster
2006
Real Estate Cadaster
2012
Topographic maps
Geodetic points
Ortophoto
Content of Archive of
B&H
Vectorized geodetic
maps

20
 The DA must support
creation of new content
types through an
administrative interface.
GTR-4 OAIS The system shall be conforming Optional
to OAIS framework.

GTR-5 OSS-based solution The system shall be Optional

implemented by OSS and related
components (see NFR-SDL-2).

GTR-6 METS for SIP/DIP Integration and interoperability Optional

services shall use METS for SIP
and DIP.

GTR-7 Multi-tier architecture The system shall be based on Mandatory

multi-tier architecture, in which
presentation, application
processing, and data
management functions are
physically separated (Fig. 5.1 or
equivalent).

GTR-8 Web interface User interface shall be Web- Mandatory

based and
a) Operate efficiently
within the following
Web browsers all
versions released in the
last 365 days:
Internet Explorer
Edge
Mozilla Firefox
Safari
Chrome
b) Can handle the file
format that the system
generates
GTR-9 Open Source Software The system shall be developed Preferable
Compliance using Open Source software and
components, including
Operating systems
Web Servers
DBMS
Table 5.1: General requirements

21
 Database Application Web server Client
server server
DA storage / DA Web DA Web
Web browser
database services application

External
system
Client of DA
Web services

Fig 5.1. Multi-tier architecture

5.2 Functional Requirements

DA core functional requirements are depicted in the following UML Use Case Diagram:

Fig 5.2. Core DA functional requirements UML Use Case diagram

Before performing any actions on the DA, users should be authenticated.
Additional functional requirements are given in Table 5.2.

Req. ID Requirement Description Type

FR-1 General functionality The functionality of DA system Mandatory

shall cover all use cases

22
 described in 4.3 (Functional
view) and Fig. 5.2.

FR-2 Security The system shall support both Mandatory

Authentication
Authorization
What operations an
authenticated user is
allowed to perform
Secure access via TLS
FR-3 Granular user permissions The system shall allow granular Mandatory
user permissions to construct
content-specific roles with
privileges. The system must also
support the creation of new
roles with custom privileges.

FR-4 Capture/Scanning/Validation The system shall support Optional

converting information from
paper documents into an
electronic (at least: PDF/A-2,
TIFF, GIF, JPEG and PNG) format
through scanning.
The bidders shall specify
technical requirements for
scanners.

FR-5 Multiple formats The system shall support storing Mandatory

of content in multiple formats,
including (but not limited to) the
following:
PDF
TIFF
GIF
JPEG
PNG
MS Word
OpenOffice
FR-6 Image cleanup The system shall support Mandatory
rotation, straightening, color
adjustment, transposition,
zoom, aligning, page separation,
annotations and despeckling.

FR-7 Content repository Content repository shall Mandatory

implement the following
services:
Definition of content
structure (modeling)
Creation, modification,
and deletion of content,

23
 associated metadata,
and relationships
Query of content
Access control on
content (permissions)
Versioning of content
Content renditions
Locking
Events
Rules/Actions
FR-8 Content transformation The system shall be able to Mandatory
perform the following content
transformations:
Image to image (lossy
and lossless
compression)

FR-9 Delivery The system shall support Mandatory

delivery of simple document or
collection of documents,
including on-the-fly
compression.

FR-10 Metadata The system shall support Mandatory

Metadata entry
Storing metadata for
each document
Linking with
corresponding
document(s)
Batch metadata update
and insert
Documents that do not have all
mandatory metadata shall be
marked as non-validated. These
documents should be available
for search and retrieval only by
users with appropriate
privileges.

FR-11 Metadata extraction The system should support Mandatory

automatic extracts of metadata
information from inbound
and/or updated content,
including MBR.

FR-12 Indexing The system shall provide Mandatory

classification and indexing
through the documents'
metadata

24
FR-13 Searching and retrieval The system shall support Mandatory
searching and retrieval based
on:
General criteria
Targeted criteria
Metadata
QR Code
Bar Code
Enable spatial queries
involving region of
interest and documents
MBR
FR-14 Define spatial region of interest The system shall enable users to Mandatory
define simple spatial region of
interest by:
Importing CSV file
Importing GML file
Defining MBR by user
input
Defining circle
FR-15 Backup and restore The system shall support backing Mandatory
up and restoring DA content
repository

FR-16 Printing, mailing and exporting The system shall support Mandatory
printing, mailing and exporting:
Part of a document
Part of a image
Single document
Aggregate documents
Document sets
FR-17 Monitoring The system shall have a module Mandatory
for overall system monitoring

FR-18 Auditing The system should provide the Mandatory

ability to audit activity, i.e. to
generate, store, and retrieve
auditing information.

FR-19 Georeferencing The system shall manage geo- Optional

referencing of maps/imagery.

FR-20 Viewing Map display The system shall enable the Mandatory
viewing (map display) of geo-
referenced maps/imagery.

FR-21 Collaboration The system should allow Mandatory

documents to be retrieved and
worked on by an authorized
user:

25
 Access should be
blocked to other users
while work is being
performed on the
document.
Multiple users should be able to
view and modify (or markup) a
document at the same time in a
collaboration session.

FR-22 Versioning The system should support Mandatory

versioning and support tracking
content history. Old versions of
documents should not be
deleted.

FR-23 OCR The system shall support optical Preferable

character recognition

FR-24 QRCode and Barcode The system shall support Mandatory

document information capture
and retrieval using QRCode and
barcode.

FR-25 Aggregate documents, The system shall be able to Mandatory

composite documents and manage aggregate documents,
document sets composite documents and
document sets.

FR-26 Templates The system should allow for the Mandatory

creating and storing of content
templates, that users can then
use to quickly create content
based on a pre-determined
style.

FR-27 Multiple formats The system shall be able to store Optional

documents in multiple formats,
if possible. For example, the
system shall be able to combine
multiple images into PDF.

FR-28 Data compression The system shall enable both Mandatory

lossless and lossy data
compression.

FR-29 Bulk importing The system shall provide a Mandatory

mechanism for bulk importing of
already scanned documents and
corresponding metadata given
in Excel files, CSV files and XML
files.
During bulk import the system
shall compare number of

26
 documents for importing with
control number of documents
contained in metadata.
The system shall be able to
update madatada through bulk
import.
Examples of data prepared for
bulk import can be obtained on
request.

FR-30 Backup and restore The system shall be able to Mandatory

backup and restore
Relevant binaries
Configuration files
Repository
o Content
o Indexes
o Database
FR-31 Reporting and analytics The system shall provide Mandatory
reporting and analytics
capabilities on:
Users
Content
Errors
Content usage per user
Retreived documents
Non-validated
documents (see FR-32)
report about
charactersitics of a
documents (for
example, for images:
format, resolution,
number of colors, etc.)
etc.
FR-32 Double validation and The system shall enable double Mandatory
confirmation of documents and validation of documents (and
metadata corresponding metadata) that
are imported through Bulk
importing. All metadata shall be
entered twice by distinct users.
Only confirmed documents shall
be available for searching and
retrieving by regular users. Users
with appropriate privileges
should be able to search and
retrieve non-confirmed
documents as well.

FR-33 Metadata alphabet Metadata can be entered in Mandatory

Cyrillic or Latin alphabet, but
before insertion into database
27
 they should be converted into
Latin alphabet.

FR-34 Splitting documents The system shall be able to split Mandatory

the documents that are already
in the DA. This is an
administrative function.

FR-35 Access to documents There are users that are allowed Mandatory
to search the DA, but are not
allowed to see the document,
before their request for
accessing the document is not
approved. All requests to
documents should be logged. All
approvals/disapprovals should
also be logged.

FR-36 Exporting of metadata The system shall provide a Mandatory

mechanism for exporting
metadata in Excel files, CSV files
and XML files in the same
formats used for bulk import.

FR-37 Deactivation of a document Document can be deactivated in Mandatory

a case of exemption.
Deactivated documents should
not be available for search and
retrieval by standard users. Only
administrators should be able to
search and retrieve deactivated
documents.

FR-38 Quality Assurance It should not be possible to Mandatory

insert/import documents into
DA if required quality
charactersitics are not satisfied:
- for images: format,
resolution, number of
colors, etc.
Table 5.2. DA functional requirements
It is the obligation of the contractor to perform the bulk import (FR-29) of at least one set of documents
for each of the document types listed in GTR-3.

DA should expose at least the following three services listed in Table 5.3.

Service Functionality Parameters Result

authenticate Web service client Web service client TRUE and access
authentication credentials token or FALSE

28
 searchContent Search Part of Metadata/METS, Metadata/METS
content/document access token

getContent Returns the Metadata/METS, access Content/Document

content/document token or NULL

postContent Posts, i.e. stores the Metadata/METS, access TRUE

content/document token (content/document
is stored) or FALSE

recordUpdate Record content User, metadata/METS, Store metadata, user

update access token and time

Table 5.3. DA services

All inserts and updates shall be approved by administrator of the system (or by user with appropriate
role/privilege).

5.3 Non-Functional Requirements

Concurrent users and availability

NFR-CU-1 Concurrent users The system shall provide the Mandatory

following throughput, i.e.
minimal number of active
concurrent users is 200.

NFR-AV-2 Availability The system shall have 99.99% Mandatory

availability measured over any
30 day period.

NFR-RT-3 Search response time16 The system shall be able to Mandatory

response to interactive user
search requests as follows:
90% within 2 seconds
100% within 5 seconds
NFR-RT-4 Update response time The system shall be able to Mandatory
response to interactive user
update (create, update, delete)
requests as follows:
90% within 4 seconds
100% within 8 seconds
(large files excluded)
NFR-RT-5 Log for response time DA shall provide a log with Mandatory
response times.

16 Delay between a keystroke action by the user and the completion of the system operation measured
at RSGA HQ, on a standard client desktop workstation equivalent to Intel i3 processor.

29
NFR-SC-6 Scalability The system shall be scalable to Mandatory
handle up to twice the currently
planned number of users.

NFR-GL-7 GUI language The GUI shall be available in the Mandatory

official languages of B&H and
English.

NFR-CS-8 GUI character sets The GUI shall support Latin Mandatory
alphabet.

NFR-RE-9 Responsive design The system must be able to Mandatory

function on all devices and
display resolutions following
responsive design patterns.

NFR-RE-10 Case insensitive search The system must be able to Mandatory

perform case insensitive search

Errors handling

NFR-EH-1 Errors and warnings The error and warning messages Mandatory
shall be informative and identify
the errors completely as
possible.

NFR-EH-2 Log files All detailed error and warning Mandatory

messages (including stack
traces) shall be written to the
application log files.

Documentation and source code

NFR-DSC-1 Software description guide The software description guide Mandatory

shall contain the following:
Development
environment details
Tools
Third-party libraries
Details about
environment and tools
setup for development
NFR-DSC-2 User manual The User manual shall describe Mandatory
and illustrate all system
functionalities.

NFR-DSC-3 Help The help resource files used for Mandatory

the Online Help functions and
tutorials shall be available for
management and parallel
update in the official B&H
languages.

30
NFR-DSC-4 Source code Developed source code and all Mandatory
related customization for DA
shall be delivered to RSGA. All
software rights to the developed
source code will be transferred
to RSGA.

NFR-DSC-5 Data model Indexing metadata The final and implemented data Mandatory
model (metadata for indexing)
should be delivered as:
UML class diagram
XML schema(s)
Object catalogue
Project implementation

NFR-PI-1 Staged implementation The supplier shall propose a Mandatory

project plan with the following
stages:
Inception
Detailed system design
Development of pilot
system
Pilot installation and
test
Development of the
final version
Test of final version
Training
Roll-out
NFR-PI-2 Delivery plan The supplier shall provide a Mandatory
detailed specifications and time
schedule of deliverables, which
shall be approved by RSGA after
the Inception stage.

NFR-PI-3 Project organization The supplier shall provide a Mandatory

description of the project
organization with roles and
required competences of each
position.

NFR-PI-4 Personnel The supplier shall provide CVs Mandatory

for experts nominated for
positions for the project.

NFR-PI-5 Reporting The supplier shall provide for Mandatory

each implementation stage a
report with the findings and
recommendations for further
implementation.
The RSGA shall accept the
reports individually before the

31
 project proceeds to the next
stage.

Systems deliverance and licenses

NFR-SDL-1 Pilot and final versions The DA system shall be delivered Mandatory
in two versions
Pilot version
Final version
The specification of the Pilot
version shall be specified in
detail during the Inception stage
of the project, and accepted by
RSGA. Both versions shall be
tested and accepted (FAT and
UAT) prior to installation on the
production environment.

NFR-SDL-2 Software OSS Fees for all software Mandatory

subscription/maintenance subscriptions shall be included in
the bid offer of the supplier, and
shall cover a period of one year
(see GTR-5). These subscriptions
shall be paid to the software
vendor by the supplier in a once-
only payment to be made at the
time of the first implementation
of the system, and shall cover
the provision of all specified
system functionality.
RSGA shall reserve the right to
obtain software under a
separate procedure.
Software subscriptions
and customized solution should
not impose any constraints,
including number of users.

Installation and testing

NFR-IT-1 Installation The software shall be installed Mandatory

by the supplier at the premises
of the RSGA, under the
supervision of the RSGA staff.

NFR-IT-2 Testing There should be three stages of Mandatory

the software testing and
acceptance:
FAT
UT
UAT

32
NFR-IT-3 Test plan The supplier shall deliver a test Mandatory
plan of all tests to be included in
the FAT. This plan shall follow
IEEE 829-2008 guidelines. The
test plan shall contain
Test scenarios
Detailed test cases
NFR-IT-4 Test scenario The supplier shall prepare a list Mandatory
of test scenarios, which shall
contain a short description of
real use cases or workflows to be
tested.
The list of scenarios shall be
approved by RSGA.

NFR-IT-5 Test and training environment The supplier shall develop Mandatory
testing, training and
development environments,
separated from the production
system.

NFR-IT-6 FAT The supplier shall perform FAT Mandatory

on all test cases.
The FAT shall be documented
and accepted by the RSGA prior
to the installation at RSGA.

NFR-IT-7 User test After installation, an UT shall be Mandatory

performed at RSGA and at least
one office or Internet user
outside RSGA. UT and
acceptance shall be done after
the training is completed for the
relevant RSGA staff.

NFR-IT-8 Error corrections Based on the user testing the Mandatory

supplier shall correct the
software and install a new
version of the software. The user
tests shall continue until all
errors are removed.

NFR-IT-9 UAT When all errors are removed, Mandatory

the supplier shall participate in
the UAT. The UAT shall take
place no more than one week
after UT has been completed.
The UAT shall be executed at the
premises of RSGA.

Training

33
NFR-TR-1 Training materials The training shall include the Mandatory
preparation of all training
materials (including printed
materials) and handouts. All
training materials shall be
available in the official B&H
languages. Part of the system
documentation can be prepared
in English only.

NFR-TR-2 Involve RSGA staff The supplier shall involve RSGA Mandatory
staff when developing
administration and user
manuals.

NFR-TR-3 Language and content The training shall be delivered in Mandatory

any of B&H languages and
involve
Presentations
Practical exercise using
the system
Discussions
NFR-TR-4 Knowledge transfer package The supplier is obliged to deliver Mandatory
a knowledge transfer package
that includes training for
software development for
necessary customization.

Warranty and support

NFR-WS-1 Warranty and Maintenance The supplier shall provide a Mandatory

comprehensive warranty and
maintenance for one year. The
warranty and maintenance shall
cover all software and
customized applications that are
delivered as part of the software
solution.
The warranty and maintenance
period shall begin once UAT as
well as Training is completed and
approved by RSGA.

NFR-WS-2 Error handling During the installation, Mandatory

acceptance and warranty period
the supplier shall provide
corrective services.
The supplier shall present a
proposal for error reporting and
corrective services, including
response times. The maximum
response times are as follows:

34
 - 1st level support: 1h
- 2nd level support: 1 day
- 3rd level support: 7 days
NFR-WS-3 Support The support during the warranty Mandatory
shall be implemented via a
three-level support:
1st level support by a
super-user who can give
rapid help to the users
experiencing a problem
with the system.
2nd level support by an
analyst who can analyze
problems that cannot be
solved by the
experienced user, or
analyze the need for
improved functionality
in depth, and prepare
related specifications
for subsequent changes
to the source code.
3rd level support by a
developer who can
make changes to the
source code related to
removing errors,
including new
functionality.
NFR-WS-4 Maintenance The supplier is obliged - if Mandatory
requested by RSGA to enter
into a maintenance contract
after the warranty period has
expired.

Economic requirements

NFR-ER-1 Price offer The price offer shall be Mandatory

submitted in the BoQ and signed
by an authorized representative
of the bidder.

NFR-ER-2 Support and maintenance Yearly cost for software Mandatory

subscriptions, support and
maintenance shall be specified
by the supplier in the BoQ.

Table 5.4. Non-functional requirements

35
36
6 APPENDICES

6.1 References
[1] ISO/IEC/IEEE 42010:2011, Systems and software engineering Architecture description
[2] Rozansky, N. and Woods E., Software Systems Architecture: Working With Stakeholders
Using Viewpoints and Perspectives, Addison-Wesley, 2011
[3] Object Management Group, UML, http://www.uml.org
[4] Oskar Henriksen AS, Federal Administration for Geodetic and Real Property Affairs - ICT Strategy,
2014
[5] Oskar Henriksen AS, Republic Administration for Geodetic and Real Property Affairs of Republic
Srpska - ICT Strategy, 2014
[6] Republic Authority for Geodetic and Real Property Affairs: Digital Archive Strategy, 2014
[7] The Consultative Committee for Space Data Systems, Reference Model for an Archival
Information System (OAIS), 2012
[8] The Open Group Architecture Framework (TOGAF), http://www.opengroup.org/togaf/
[9] The Open Group, TOGAF Version 9.1, Van Haren Publishing, 2013
[10] Weske, M. Business Process Management: Concepts, Langauges and Architectures,
Springer, 2012

37
6.2 Definitions
Abstraction
The technique of providing summarized or generalized descriptions of detailed and complex content.
Abstraction, as in "level of abstraction", can also mean providing a focus for analysis that is concerned
with a consistent and common level of detail or abstraction. Abstraction in this sense is typically used in
architecture to allow a consistent level of definition and understanding to be achieved in each area of the
architecture in order to support effective communication and decision-making. It is especially useful
when dealing with large and complex architectures as it allows relevant issues to be identified before
further detail is attempted.
Actor
A person, organization, or system that has a role that initiates or interacts with activities. Actors may be
internal or external to an organization.
Application
A deployed and operational IT system that supports business functions and services; for example, a
payroll. Applications use data and are supported by multiple technology components but are distinct
from the technology components that support the application.
Architecture
A formal description of a system, or a detailed plan of the system at component level, to guide its
implementation. Architecture is created solely to meet stakeholders needs.
Architecture element
Fundamental piece from which a system will be constructed.
Concerns
The key interests that are crucially important to the stakeholders in a system, and determine the
acceptability of the system. Concerns may pertain to any aspect of the system's functioning,
development, or operation, including considerations such as performance, reliability, security,
distribution, and evolvability.
Dynamic structure
Defines run-time elements of software system and their interactions.
Stakeholder
An individual, team, or organization (or classes thereof) with interests in, or concerns relative to, the
outcome of the architecture. Different stakeholders with different roles will have different concerns.
Static structure
Defines internal design-time elements of software system and their arrangement.
System
A collection of components organized to accomplish a specific function or set of functions.
System stakeholder
An individual, team, or organization (or classes thereof) with interests in, or concerns relative to, a system.
UML Class Diagram
Static structure diagram that describes the structure of a system systems classes, their metadata,
operations and the relationships among objects.
UML Use Case Diagram
Representation of a user's interaction with the system.

38
User
Any person, organization, or functional unit that uses the services of an information processing system.
View
The representation of a related set of concerns. A view is what is seen from a viewpoint. An architecture
view may be represented by a model to demonstrate to stakeholders their areas of interest in the
architecture.
Viewpoint
A definition of the perspective from which a view is taken. It is a specification of the conventions for
constructing and using a view (often by means of an appropriate schema or template).
Workflow
Automation of business process, in whole or part, during which documents, information, or tasks are
passed from one participant to another for action, according to a set of procedural rules.
System workflow
A system workflow consists of activities that are implemented by software systems without any user
involvement.
Human interaction workflow
A human interaction workflow is a workflow in which humans are actively involved and interacts with
information systems.
Workflow management system
A software system that defines, creates, and manages the execution of workflows through the use of
software, running on one or more workflow engines, which is able to interpret the process definition,
interact with workflow participants, and, where required, invoke the use of IT tools and applications.

39
6.3 List of Acronyms

AIP Archival Information Package

API Application Programming Interface
ATA Advanced Technology Attachment
BoQ Bill of Quantity
BPMN Business Process Model Notation
COTS Commercial Off-The-Shelf
CPU Central Processing Unit
CSV Comma Separated Values
DA Digital Archive
DBMS Database Management System
DIP Dissemination Information Package
DMZ Demilitarized Zone
EA Enterprise Architecture
ECM Enterprise Content Management
ESB Enterprise Service Bus
FAT Factory Acceptance Test
RS Republic of Srpska
RSGA Republic of Srpska Republic Administration for Geodetic and Property Affairs
FTP File Transfer Protocol
GA Geodetic Administration
GB Gigabyte
GML Geography Markup Language
GUI Graphical User Interface
HDD Hard Disk Drive
HQ Headquarter
HW Hardware
JICA Japan International Coopertion Agency
JCR Content Repository API for Java
ICT Information and Communication Technology
IT Information Technology
IS Information System
LARIS Land Registry Information System
LDAP Lightweight Directory Access Protocol
LGPL (GNU) Lesser General Public License
MBR Minimum Bouding Rectangle
METS Metadata Encoding and Transmision Standard
40
MS Microsoft Corporation
OCR Optical Character Recognition
OIAS Open Archival Information System
OSS Open Source Software
PDF Portable Document Format
QA Quality Assurance
QC Quality Control
RAM Random Access Memory
RPM Revolution Per Minute
RINEX Receiver Independent Exchange Format
SATA Serial ATA
SIP Submission Information Package
SOA Service Oriented Architecture
SSD Solid-State Drive
SSO Single Sign-On
TB Terabyte
TIFF Tagged Image File Format
UAT User Acceptance Test
UML Unified Modeling Language
URS User Requirements Specifications
Wf Workflow
XML Extensible Markup Language

41