Document Management and Workflow System: Real Estate Administration Montenegro

Technical Requirement
Specification
Document Management
and Workflow System
Real Estate Administration

Montenegro
SK project no. LIN10001
Version 1.2.July 2012

Technical Requirement Specification, System, Version 1.2, Draft
Document History
Date Version Description By Approval
19/4/12 1.0 Initial Document Oskar

Henriksen
2/5/12 1.1 Corrections after Oskar

comments from Henriksen
Norwegian Mapping
Authority
4/7/12 1.2 Corrections after misc. Oskar

comments Henriksen
Content
1 Introduction................................................................................................5
1.1 Purpose of this Document...................................................................5
1.2 Scope of this Document......................................................................5
2 Background and Environment.....................................................................6
3 Terms and Definitions.................................................................................7
3.1 Definition of Terms.............................................................................7
3.1.1 Concept of Workflow Management Terms.................................9
3.2 Acronyms............................................................................................9
3.3 References........................................................................................10
4 Overall System Concept............................................................................11
4.1 The system Components...................................................................11
4.1.1 Workflow...................................................................................11
4.1.2 Document Management...........................................................12
5 Overall System Requirements...................................................................13
6 Document Management System...............................................................17
6.1 Overall Requirements.......................................................................17
6.2 Data Repository Requirements.........................................................17
3
Real Estate Administration, Montenegro
6.3 Document Administration Requirements.........................................19

6.4 Requirements to Metadata Editor....................................................20
6.5 Analogue-Digital Conversion and Raster Tools..................................22
6.6 Requirements to View, Search and Download..................................24
6.7 Import Export Requirements.............................................................25
6.8 Interoperability Requirements..........................................................25
7 Workflow Management System................................................................28
7.1 Overall Requirements.......................................................................28
7.2 Requirements to Workflow Data Repository....................................29
7.3 Requirements to Workflow Administration......................................30
7.4 Requirements to Workflow Control..................................................31
8 Non Functional Requirements..................................................................33
8.1 Performance Requirements..............................................................33
8.2 Reliability Requirements...................................................................34
8.3 Usability Requirements.....................................................................34
8.4 Error Handling Requirements............................................................34
8.5 Documentation Requirements..........................................................36
8.6 Licensing Requirements....................................................................37
8.7 System Administration Requirements...............................................38
8.8 System Security Requirements..........................................................39
8.9 Training Requirements......................................................................39
8.10 Installation, Testing and Warranty Requirements.............................41
8.11 Project Implementation Requirements.............................................45
8.12 Project Management Requirements.................................................47
8.13 Support Organisation Requirements.................................................48
8.14 Economic Requirements...................................................................48
Appendix 1: Overview of relevant existing technical infrastructure

Appendix 2: List of relevant existing scanners
Appendix 3: SOA, Service Oriented architecture
3
1 Introduction
This document is related to a project where Statens kartverk (The Norwegian
Mapping Authority) is supporting the Real Estate Administration of
Montenegro (REA) to strengthen the national information infrastructure.
One procurement under this project shall include two sub-projects:
1. Document Management and
Workflow System
2. Pilot Document Data Conversion
This document contains the specifications for sub-project 1. Document
Management and Workflow System
1.1 Purpose of this Document

The purpose of this document is to provide the necessary background
information, business requirements, system scope, and high-level technical
specifications for the out-sourcing of the detailed design, the development,
and the implementation of a computerized Document Management and
optional Workflow System for the Real Estate Administration of Montenegro.
The Document Management and Workflow System is planned to be the main
source for registering, managing and distributing digital documents in the Real
Estate Administration.
1.2 Scope of this Document

The scope of the document is to:
 Give an overall picture of the background and environment the
system is going to be implemented into.
 Describe the overall system concept.
 Specify the overall system requirements
 Specify the requirements for the system modules
 Specify the non-functional requirements of the project
3
2 Background and Environment

The system shall be implemented as a centralized system in REA headquarters
where all application software and databases are located under the
management of the Section for Information Systems. REA has 21 local offices
plus two sub-offices constituting 23 local nodes that shall be users of the
Document Management and optional Workflow System. The view, search and
download part of the system shall be made generally available through the
internet.
The system shall also offer services through service interfaces to other systems
within REA.
The implementation of this system is the start of an initiative to digitize all
documents related to Real Estate transactions in Montenegro, a project that
will take several years. The estimated volume of documents is about 10 mill,,
spanning a wide range of document types and formats.
It is assumed that REA has adequate hardware and communication
infrastructure to accommodate the system, a description of the relevant
infrastructure is included in Appendix 1 of this document.
The system implementation will run in parallel with a pilot project on
outsourcing of document conversion.
3
3 Terms and Definitions

3.1 Definition of Terms
Web Service Services applied between two systems without user

interaction. A request for service is sent by one system
as a message, and the response from the other system
is a message.
SOAP Web Service, WMS and WFS are examples of
Web Services.
See also Appendix 3: SOA, Service Oriented
architecture
Invocation services Invocation services are used when the service involves
user interaction directly to the system which provides
the service.
Architecture
Metadata for Data for the description of documents and their

documents management
Document Fixed and structured amount of information that can
be managed and interchanged as a unit between users
and systems.
Example: Application Letter, Memo, Sketch, Map
Document version Identified state of a document in its life cycle,
recorded so that it can be retrieved as a record or for
distribution purposes
Document Class A class assigned to a document according to a
classification scheme
Metadata Model Metadata elements grouped into sets designed for a
specific purpose, e.g. metadata collected for a
particular type of information resource.
Compound Document consisting of several embedded files in a
document specified file structure. (The embedded files have no
separate metadata.)
A document may result as being composed from more
than one type of document, for example a technical
specification document, made up of, for example text
files and/or pictorial representation files. Each file may
be produced by different software applications
Aggregated Document containing separately identified documents
Document (parts) that are logically dependent but can be
physically independently managed.
A document aggregation is an assembly of self-
contained documents; each associated with its own
metadata. The aggregating document has metadata,
but not necessarily a separate own document.
Note:
3
A document aggregation includes a “recipe” of what

and how it is aggregated. The recipe could be part of
its metadata or its own document.
Example:
Interlinked Web pages, CAD drawing with model files
references
Document set Collection of documents that are managed together as
a unit for a specific purpose
Note:
The metadata of the document set describes which
documents it consists of. The set has its own
metadata, but not its own content.
A document set has its own metadata. The purpose of
the document set as well as the list of contained
documents is described by its metadata. Each
document contained in the document set has its own
metadata
Example:
A set of documents sent as a unit to the recipients
according to a distribution list, folder in a document
management system, set of documents for tender
Workflow A resource which performs the work represented by a

Participant workflow activity instance.
Role (Workflow) A group of participants exhibiting a specific set of
attributes, qualifications and/or skills.
A workflow participant assumes a role given that he or
she has the appropriate skill set
Process Definition The representation of a business process in a form
(Workflow) which supports automated manipulation, such as
modelling, or enactment by a workflow management
system. The process definition consists of a network of
activities and their relationships, criteria to indicate
the start and termination of the process, and
information about the individual activities, such as
participants, associated IT applications and data, etc.
Activity A description of a piece of work that forms one logical
(Workflow) step within a process. An activity may be a manual
activity, which does not support computer
automation, or a workflow (automated) activity. A
workflow activity requires human and/or machine
resources(s) to support process execution; where
human resource is required an activity is allocated to a
workflow participant.
Process or Activity The representation of a single enactment of a process,
Instance or activity within a process, including its associated
(Workflow) data. Each instance represents a separate thread of
execution of the process or activity, which may be
controlled independently and will have its own
internal state and externally visible identity, which
may be used as a handle, for example, to record or
3
retrieve audit data relating to the individual

enactment.
3.1.1 Concept of Workflow Management Terms

The figure below shows the concept of Workflow Management terms used
Business Process
i.e. what is intended to happen
is defined in a Is managed by a
Process Definition Workflow Management System

a representation of what is intended Controls automated aspects of the
to happen business process
Sub- Processes composed of Used to control and manage via
Process Instances
A representation of what is actually
Activity happening
which may be
include one or more
or
during
Manual Activities Automated Activities execution Activity Instances
Which is not managed as a part of represented by
the Workflow system which Include
and/or
Work Items Invoked Applications
Task allocated to a Computer tools/
workflow participant applications used to
support activity
3.2 Acronyms
CAD Computer Aided Design

COTS Commercial-Off-The-Shelf – acronym for licensed
standard software
DBMS Database Management System
FAT Factory Acceptance Test
GeoPortal Official web site in Montenegro for dissemination of
spatial data
GUI Graphical User Interface
IT Information Technology
OCR Optical Character Recognition
OSS Open Source Software
QA Quality Assurance
QC Quality Control
REA Real Estate Administration
SAN Storage Area Network
SAT Site Acceptance Test (synonymous with User
Acceptance Test )
SOA Service Oriented Architecture
3
Architecture
SOAP Simple Object Access Protocol
SQL Structured Query Language
UAT End-User Acceptance Test (synonymous with Site
Acceptance Test)
URL Uniform Resource Locator
WFMC Workflow Management Coalition WFMC
XML Extended Mark up Language
3.3 References
Some of the terms above are further explained in:
 ISO International Standard - CEI/IEC 82045-1:2001
 Workflow Management Coalition Glossary and Terminology, WFMC-
TC-1011
http://www.wfmc.org/standards/docs/TC-1011_term_glossary_v3.pdf
3
4 Overall System Concept

The figure below gives a functional overview of the required system:
Note: The figure shows workflow control only of some components that are
those to be initially put under the workflow control. The workflow control shall,
however, be used for control of all modules of the document management
system, as well as other applications as expressed in the requirements to
Workflow Management System.
4.1 The system Components

This grouping of functionality into modules is done for purpose of systematic
description, and it is realised that the bidder may configure the system
differently. This is fully acceptable as long as the functionality is totally
covered, and the principles of interoperability and modularity are respected.
4.1.1 Workflow
The workflow system shall be offered as an optional part and is shown in red in
the figure above.
The workflow administration module shall define processes, activities and
roles. The module shall also monitor the process and activity instances and
generate status reports, as well as perform other relevant workflow
administration tasks. Both definition data and instance data shall be stored in
the workflow data repository.
The Workflow Control Module (or Workflow Engine) shall execute the actual
control of process and activity instances and their flow. It shall invoke and
3
interact with the Metadata Editor, Analogue/Digital Conversion, and Raster

Tool Modules.
4.1.2 Document Management

The Document Administration Module shall provide an interactive tool for
defining different metadata models and link them to document classes. It shall
also provide other relevant administration tasks related to the document
management tool.
If the option for Workflow is decided implemented the use of the three sub-
modules Metadata Editor, Analogue/Digital Conversion, and Raster Tool shall
be accessed through the Workflow Control Module in seamless sessions.
The Metadata Editor Module shall provide a tool for entering and
manipulating metadata and linking metadata to document files.
The Digital Analogue Conversion shall consist of modules for supporting the
operation of conversion using different types of scanners and cameras.
The Raster Tools shall support raster manipulation, conversion and geo-
referencing of converted image data.
The View, Search and Download Module shall provide internal and external
users with a tool to search for documents based on metadata and to view,
print and download documents.
The Import and Export Module shall provide import and export functionality
for import and export of document metadata and files.
The Services and Portal Interaction shall consist of a set of services enabling
other systems to locate, store and retrieve documents. It shall also provide a
link with the GeoPortal of REA.
3
5 Overall System Requirements
ID Capability Feature Type Bidder’s comments

5.1.1 Modular System The system is defined as two main modules with six Mandatory
sub-modules
 Document Management
o Document Administration including
meta data definition tool
o Metadata editor
o Analogue, Digital Conversion
o Raster tools including geo-referencing
 Workflow management
o Workflow administration including
workflow definition and monitoring
o Workflow control
Note! This module-based architecture does not
prevent a possibility for practical system solution that
combines several modules/sub-modules into one, and
also for use of common database. But the solution
shall provide all services, which are required for each
and every module.
In case one or several module/sub-modules are being
changed, removed, upgraded, etc. in the future, this
shall not affect the remaining modules and they shall
3

continue to operate undisturbed and independently.
The implementation of some of the modules can be
divided into other separate modules/sub-modules. In
this case, interoperability between the components
that operates independently shall follow the
described principles.
5.1.2 Modular System Workflow Management and Document Management Mandatory
shall operate independently and essentially and shall
control the data, which it is responsible for
5.1.3 Standard system A standard workflow and document management Preferable
system shall be applied
5.1.4 User interface Montenegrin and English language shall be available Mandatory
language in the user interface
5.1.5 Centralized system The system shall be implemented as a centralized Mandatory
system where all application software and databases
are located at the central system
5.1.6 Intranet Internal users of the system (REA , local cadastre Mandatory
office, and other relevant users within the intranet)
shall have access to the system via the Montenegrin
official network
5.1.7 Internet Citizens and public users shall have access to the Mandatory
system via Internet
5.1.8 Web based user User functionality shall be provided directly to the Mandatory
interface central system via web technology or web based thin
clients.
Note: Exceptions may be made for specialized COTS
3

applications such as raster manipulation, geo-
referencing etc.
Minimum requirements are web interface for
metadata editing, metadata search, and document
view.
5.1.9 Security control For every function that is started by the user, the Mandatory
systems shall control whether the user has accepted
access to both function and data.
Note: In case the optional workflow management is
included, this shall play a central role in the access
control.
5.1.10 Help function The user shall be able to get access to instructions for Mandatory
use of the functions directly in the user interface
5.1.11 Interaction with The Document Management and Workflow System
other systems shall interact with other systems through defined
services, and shall have a specific interaction with the
web Geoportal of REA
5.1.12 SOA The modules Metadata Editor, View and Search and Mandatory
Export, Import and Download shall interact and
exchange date based on Service Oriented
Architecture (SOA) principles.
See also requirements in 6.8 and Appendix 3: SOA,
Service Oriented architecture
5.1.13 Other Module The sub-modules: Analogue-Digital Conversion and Mandatory
Interoperability Raster Tools shall be interoperable allowing the user
to perform the different operations on the
3

documents in uninterrupted sessions
5.1.14 Workflow The workflow definition tool shall interact with the Mandatory
Administration Workflow Control Module based on an open standard
Interoperability workflow definition language.
5.1.15 Workflow Control The Workflow Control Module shall interact with Mandatory
Interoperability modules involved in the workflow so that the user
can work in a seamless session
3
6 Document Management System
6.1 Overall Requirements

6.1.1 Design Principles The design of the Document Management System Mandatory
shall comply with the principles laid down in the ISO
international standard IEC 82045-1
6.1.2 Common storage The Document Management Module shall provide Mandatory
for all documents storage and management of all documents related
Real Estate transactions
6.1.3 User Interface Management of documents shall be possible from Mandatory
user functions
6.14 Web Services Management of documents shall be possible by using Mandatory
Web Services accessible from other system modules
6.2 Data Repository Requirements

6.2.1 Metadata The data repository shall hold metadata with multiple Mandatory
metadata models .Each document class may use a
specified data model. (One model)
6.2.2 Metadata Each document class may refer to several metadata Preferable
models.
6.2.3 Archive and It shall be possible to divide the data repository Mandatory
3

Working Part logically in a Working and Archive part for the
purpose of different routines for backup, security etc.
(This division is independent of document class etc.)
6.2.4 Document format Any common document format shall be supported for Preferable
storing documents
6.2.5 Document format Following document formats shall be supported for Mandatory
storing and viewing documents
 TIFF
 PDF (Including OCR Text Layer)
 DjVu (Including OCR Text Layer)
 PDF/A
 All Microsoft Office document formats
 All Open Office document formats
 JPG
 GIF
 GML
 XML
 MVI
 HTML
 Email
 RTF
6.2.6 Georeferencing Georeferencing data shall be included for formats
data that support georeferencing e.g. GeoTiff
6.2.7 Multiple formats The document management system shall provide Mandatory
possibilities to store the same document with
different formats and/or with different data
compressions
6.2.8 Versioning The data repository shall support versions of Mandatory
documents and version history
3

6.2.9 Versioning Version history and earlier document versions shall Preferable
be available for viewing
6.2.10 Compound See definition in 3.1 above. The system shall be able Mandatory
Documents to handle compound documents
6.2.11 Aggregated See definition in 3.1above. The system shall be able Preferable
Documents to handle aggregated documents
6.2.12 Document Set See definition in 3.1above. The system shall be able Preferable
to handle document sets
6.2.13 Data Compression The document management system shall provide a Mandatory
scalable functionality to compress raster documents
which reduces the size of the document file without
corrupting the readability of the document
6.2.14 Database The system should be compatible with at least one Mandatory
Technology open source database solution, and at least one of
the two: MS SQL, Oracle.
6.3 Document Administration Requirements

6.3.1 Document Class It shall be possible to define an unlimited number of Mandatory
document classes according to a classification scheme
6.3.2 Metadata The document administration shall provide an Mandatory
definition tool interactive tool for definition of different metadata
models (data structure, labels, and legal values)for
each Document Class
3

6.3.3 System It shall be provided standard user interface Mandatory
Configuration interactive tools for all Document Management
system configuration
6.4 Requirements to Metadata Editor

6.4.1 Multiple metadata The user shall be able to record metadata for a Mandatory
models document in a form (or forms) defined by metadata
models assigned to Document Class, and the
metadata editor shall offer the correct metadata form
given the document class.
6.4.2 Document Creation It shall be possible to create a document when Mandatory
during metadata entering metadata. Files related to the document
entry may be linked to metadata this time or in a different
Meta Data Editor session.
6.4.3 Barcode Printing The system shall support printing of barcode Mandatory
document identifiers that may be attached to
document parts for later identification
6.4.4 Find Document It shall be possible to locate a document by: Mandatory
 Searching Metadata and selecting document
 Browsing file storage and selecting a file
linked to the document .
 Reading a bar code
3

6.4.5 Link document files It shall be possible to link and assemble documents Mandatory
to metadata files to metadata by:
 Selecting the file(s) in the browser
 Load the file from Analogue/Digital
conversion unit (Scanner/Camera)
 Add files or pages of files from other
documents (compound documents)
 Reading a bar code and find file(s)
 Upload a set of files identified with barcodes
and automatically link to existing metadata
6.4.6 Metadata Search All metadata shall be searchable on single metadata Mandatory
elements or combinations or as free text search
6.4.7 Metadata Edit The user shall have access to change/update all Mandatory
metadata in an editor environment.
6.4.8 Versioning The system shall offer functionality for handling any Mandatory
number of versions of documents
6.4.9 Previous record It shall be possible to present the attributes entered Mandatory
default values for the last document as the default values in the
editor
6.4.10 Offline Metadata In case of lack of external network connectivity the
Entry system shall have functionality for offline registration
of metadata and subsequent upload
3
6.5 Analogue-Digital Conversion and Raster Tools

6.5.1 Analogue/Digital Assuming the availability of network accessible Mandatory
Data Conversion conversion devices (Scanners/Cameras), the system
shall include functionality to control the scanning of
documents to be included in the Document
Management database .
6.5.2 Scanners The system shall provide possibility to use of multiple Mandatory
scanners/cameras with different features
 Black/white, Grey tones and Colour
 A0, A1, A3, A4 sheet size
 Output format : Tiff, Pdf, Jpg
 Resolution
6.5.3 Scanners The system shall initially be installed with support for Mandatory
the scanners listed in Appendix 2, which are scanners
present in REA today.
6.5.4 Analogue/Digital The system shall be prepared for adding new Mandatory
Conversion Devices conversion devices using standardised drivers.
6.5.5 Inspection/Reject The system shall have functionality for inspecting Mandatory
of images converted images and approve/reject/re-convert.
6.5.6 Raster Tool, The raster tool shall offer possibility for converting Mandatory
Formats and the raster image to different raster formats, and
Compression different compression schemes.
6.5.7 Raster Tool, The raster tool shall have functionality to resize and Mandatory
Resizing, Re- resample the raster image
sampling
3

6.5.8 Raster Tool, Image The raster tool shall have functionality for image Mandatory
Enhancement enhancement, minimum brightness, contrast, hue
and saturation
6.5.9 Raster Tool Geo- The raster tool shall have features for geo- Mandatory
referencing referencing raster images and storing geo-referencing
data in different formats
6.5.10 Raster Tool Page It shall be possible to manipulate pages in a Mandatory
manipulation document by:
 Inserting selection of pages from document
files
 Extract Pages from document file and create
new document file
 Delete Pages from document file
 Rotate Pages
6.5.11 Raster Tool OCR The raster tool shall have functionality for Optical Mandatory
Character Recognition, and storage of searchable free
text documents.
6.6 Requirements to View, Search and Download

6.6.1 Search for The user shall be able to search for documents based Mandatory
documents on matching matches with single metadata elements,
or combinations of metadata elements
6.6.2 Search for It shall be possible to search and identify documents Mandatory
documents by free text search
3

6.6.3 Search results The user shall be able to choose a specific document Mandatory
from the search results, and read the metadata of
the document
6.6.4 Viewing documents The user shall be able to view a chosen document Mandatory
independent of file format
6.6.5 View geo The viewer shall offer functionality to view the extent Mandatory
referenced of georeferenced documents on a simple map
documents background
6.6.6 Print out When viewing a document, the user shall be able to Mandatory
print the document
6.6.7 Download When viewing a document, the user shall be able to Mandatory
document download the document file(s) and its metadata to
files
6.6.8 Send document When viewing a document, the user shall be able to Preferable
send the document as attachment to an email
6.6.9 Versioning Version history and earlier document versions shall Mandatory
be available for viewing
6.6.10 Creating Document The user shall be able to choose and mark several Preferable
Sets documents from the list of results from the search,
and create a Document Set from the selection. See
definition in 3.1above
3

6.6.10 Export/Print The user shall be able to: Preferable
Document sets  Print the content of a Document Set
 Mail the content of a document set to a
specified address
 Download the document set to local file(s),
optionally to a zipped folder
6.7 Import Export Requirements

6.7.1 Export metadata The document management system shall provide Mandatory
and documents functionality for export of both metadata as csv-files
and corresponding files to external storage
6.7.2 Import metadata The document management system shall provide Mandatory
and documents functionality for import of both metadata as csv-files
and corresponding files to the system. It shall be
possible to specify whether data represents new
documents or addition to existing documents.
Conflicts with existing data shall be flagged for
resolution.
6.8 Interoperability Requirements

6.8.1 Interoperability The Document management system shall provide Mandatory
with other modules interoperability functions accessible from other
systems.
3

6.8.2 Record / update The Document management system shall provide a Mandatory
metadata web service for recording/ updating of metadata of a
document, as
 Web Service, and
 Invocation Service
6.8.3 Upload a new The Document management system shall provide a Mandatory
document web service for upload of a new document and
connect it to already existing metadata as
6.8.4 Search for The Document management system shall provide a Mandatory
documents web service for search for documents based on
metadata values, as
6.8.5 Search list The result from a search shall contain a list of Mandatory
metadata for the documents which match the search
criteria, including the URL to the document
6.8.6 Download The Document management system shall provide a Mandatory
document file web service for downloading a document file to the
system that is asking, as
6.8.7 View document The Document management system shall provide a Mandatory
service that by request of a specified document, will
show the document in an appropriate viewer
3
3
7 Workflow Management System

7.1 Overall Requirements
7.1.1 Standard Work A standard work flow system (COTS or OSS) shall be Preferable
Flow system applied with necessary modifications due to
requirements in this document
7.1.2 Standard The workflow system shall be organised in Preferable
Architecture conformance with the architecture set forth by the
Workflow Management Coalition (WFMC)
7.1.3 General System The workflow system shall be of general character Mandatory
and interfaced to the Document Management System
in a standardized and documented way.
7.1.4 Interoperability The workflow system shall act as the umbrella system Mandatory
and able to invoke the other systems when they are
required for use during the workflow processes
7.1.5 Multiple Processes The system shall have the ability of defining, storing Mandatory
and managing any number of processes.
7.1.6 Multiple Activities Each process definition may contain any number of Mandatory
activities which have to be completed before the
workflow instance is completed
3

7.1.7 Parameter The system must have the ability to control flow of Mandatory
Controlled Flow of work such as branching to different activities in the
Work workflow based on parameters.
Example: Documents of one type may be branched to
scanning, while documents of another type shall be
branched to photography. These parameters may
either be obtained from the metadata, or input
directly to the workflow system.
7.1.8 Authentication The workflow system shall provide authentication of Mandatory
the user and management of users access rights
7.1.9 User access rights The Workflow system shall provide a service that Mandatory
gives information about the access rights of the user,
accessible from the other system components
7.1.10 Process Instances The Work Flow system shall provide a service that Preferable
Records records information about process instances,
accessible from the other system components
7.2 Requirements to Workflow Data Repository

7.1.1 Standard Storage The data repository shall be based on standard Mandatory
system database and/or file system, and shall offer standard
and documented interface for access to data
7.2.2 Information The workflow data repository shall hold information Mandatory
Content about process definitions, process instances,
roles,workflow participants and user rights.
3

7.2.3 Process definition The process definition shall be stored in a Mandatory
data documented and open format. Preferably XPDL
7.3 Requirements to Workflow Administration

7.3.1 Process Definition The workflow system shall provide functions for Mandatory
Tool definition, storage and change of any number of
processes.
7.3.2 Process Definition The process definition tool shall define data about Mandatory
Tool processes and activities such as:
 Processes attributes
 Activity relations
 Activity attributes and rules including flow
control.
 Role allocation
 Application Invocation
7.3.3 Process Definition An interactive graphic user interface shall be offered Mandatory
Tool for process definition
7.3.4 Process Definition The Work Flow system shall provide functions for Mandatory
Tool allocation roles (See definition in 3.1above) to
Role allocation processes and activities
7.3.5 Monitoring and The monitoring and resource management functions Mandatory
Resource shall include capability to assign workflow
Management participants to process Instances.
7.3.6 Monitoring and The system shall provide monitoring functions for Mandatory
Resource showing the state of one, more or all process
Management instances.
3

7.3.7 Monitoring and The Work Flow system shall provide report/statistical Mandatory
Resource functions showing
Management  Workload, throughput, and bottlenecks
Report/Statistics  Generate production statistics on processes
and activities over defined time periods.
The reports shall be generated using a report
generation tool, and it shall be possible to export
reports to Excel spreadsheets for further use.
7.3.8 Implementation of REA will define up to 10 actual workflows, these shall Mandatory
actual workflows be implemented in the system by the contractor at
installation/training time.
7.4 Requirements to Workflow Control

7.4.1 Workflow control The Work Flow system shall provide functionality for Mandatory
interpreting process definition, route and control of
the process instances.
7.4.2 User functions The workflow system shall provide following user Mandatory
functions such as:
 Authentication
 Show ”My work plan” – list of waiting
process instances
 Selecting a process instance
 Fill activity attributes
 Checking out activities
 Invoking other systems (raster tools,
metadata editor, conversion)
3

7.4.3 Application The Workflow control shall Invoke other applications Mandatory
Invocation and automatically interchange parameters with these
so that the user can work in a seamless session.
Note: In case of use of standardised tools for example
raster management, a certain user assistance in the
passing of parameters may be accepted.
7.4.4 Outside licensed There shall be possible to make restrictions on the Mandatory
users normal working system for registration according to
(Court, police, etc.) roles, where outside licensed authorities are allowed
to register certain applications on a case or certain
(limited data) in the Cadastre and Document Systems.
3
8 Non Functional Requirements

8.1 Performance Requirements
ID Feature Type Bidder’s comments
8.1.1 The Document Management and Workflow System l shall be available 24 Mandatory
hours a day, 7 days a week (24/7).
8.1.2 The Document Management and Workflow System shall be available at REA Mandatory
offices at the Local Offices via the Governmental network, and available for
public and private institutions, and citizens, via the Internet.
The system shall be able to manage more than 500 users connected at the
same time.
8.1.3 System response times for data entry will be  90% within 2 seconds
Mandatory
measured at REA as the delay between a key
 100% within 3 seconds
stroke action by the user and the completion of
the system operation, on a client desktop
workstation similar to Intel Core Duo processor.
8.1.4 System response times for data search will be  90% within 2 seconds
Mandatory
measured at REA as the delay between a key
 100% within 3 seconds
stroke action by the user and the time taken to
display the record required by the user, on a
client desktop workstation similar to Intel Core
Duo processor.
8.1.5 System response times for use of services provided by other systems shall Mandatory
not be included in the response time of the Document Management and
Workflow System, but the system shall provide a log for response times
when using services.
3
8.1.6 The system shall be scalable to handle up to twice the currently planned Mandatory
amount of users of the Document Management and Workflow System.
8.2 Reliability Requirements

8.2.1 The Document Management and Workflow System shall have an uptime of Mandatory
more than 99% of the announced 24/7 availability, measured over any 30
days period.
Note! Will be enforced in maintenance contract
8.3 Usability Requirements

8.3.1 The system shall provide the option on every page of the complete Mandatory
Document Management and Workflow System to view the headings, menus,
labels, tooltips, and any software control values in Montenegrin and English
language.
8.4 Error Handling Requirements

8.4.1 All written software shall be subject to a comprehensive error handling Mandatory
regime, which shall be described in the offer by the bidder.
8.4.2 Error and Warning messages shall be informative and identify the error as Mandatory
completely as possible (e.g. identifying the system, the procedure or
function, any variables passed to the procedure or function, the identifier of
the record being processed at the time of the error, the last SQL statement,
if relevant.)
3
8.4.3 All error and warning messages shall be written to the server’s Windows Mandatory
Event Log for the Document Management and Workflow System
8.4.4 Critical errors shall be emailed automatically to all relevant software support Mandatory
personnel.
8.4.5 It shall be possible to configure the language (Montenegrin and English) for Mandatory
Error Messages.
8.5 Documentation Requirements

ID Feature Content Type Bidder’s comments
8.5.1 Software The Document Management and Workflow System Mandatory
Description Software Description Guide shall be provided in the
Guide Montenegrin and English languages, and shall
describe the following:
 Software development environment (including
tools used),
 Software compilation details
 Implemented software architectural features
 Software coding standards
 And any other software details that will be of use
for software support or for further development of
the Document Management and Workflow
System.
3
ID Feature Content Type Bidder’s comments

8.5.2 Deployment The Document Management and Workflow System Mandatory
Guide Deployment Guide shall be supplied in the
Montenegrin and English languages, and shall
describe the technical aspects of
 installing,
 calibrating, and
 fine-tuning
the Document Management and Workflow System
software, application performance and database. This
guide shall be oriented towards the technical
specialist (e.g. system integrator, DBMS
administrator).
8.5.3 User Manual The Document Management and Workflow System Mandatory
User Manual shall be supplied in the Montenegrin
and English languages, and shall describe and
illustrate all system functions.
8.5.4 User Manual The text files containing the original text of the User Mandatory
Updates Manuals shall be organized in such a way that parallel
updates in all the languages will be managed easily
and consistently. The update method shall be
described by the bidder in the offer.
8.5.5 Help files Text files used for the Online Help functions and Mandatory
tutorials shall be available for management and
parallel update in all the languages. The update
method shall be described by the bidder in the offer.
3
8.6 Licensing Requirements

8,6,1 All modules of the Document Management and Workflow System shall be Mandatory
able to be scaled-up to the double the amount of users as currently
specified, without the need to pay for additional software license fees.
8,6,2 REA shall supply the following software licenses: Mandatory

Server operating systems:
 MS Server 2008 R2 x64
 MS Server 2003 x64
Client operating systems are:
 MS Windows XP,
 MS Windows Vista,
 MS Windows 7 Professional x86/x64
DBMS licenses:
 Oracle
 MS SQL Server
Fees for all additional software licenses needed for the Document
Management and Workflow System shall be included in the bid offer of the
supplier, and shall cover a period of one year. These fees shall be paid to the
software supplier 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.
Licence fees for subsequent years shall be indicated.
The contracting authority (REA) shall reserve the right to obtain software
licenses under a separate procedure.
8,6,3 The supplier shall, at the stage of detailed system design, identify all Mandatory
software packages (whether Commercial or Open Source) that are required
3

as part of the comprehensive solution for the Document Management and
Workflow System, along with any costs associated with the ongoing use of
these software packages.
The contracting authority shall reserve the right to obtain software licenses
under a separate contract.
8.7 System Administration Requirements

8.7.1 The system shall keep a log of all changes to the databases, including: Mandatory
 Database transactions made by the Document Management and
Workflow System
 Database changes made by Database Administrator
8.7.2 The system shall keep the log of changes for at least 6 months, and then Mandatory
archive it.
8.8 System Security Requirements

8.8.1 The system shall provide System Administration tools for the definition of Mandatory
user roles of
 Read-only
 Edit
and
 Editor of the Document Management and Workflow System
 Database Administrator
8.8.2 Changes to the databases shall only be made by use of the Document Mandatory
Management and Workflow System functionality, or by SQL-operations
3

performed by Database Administrator
8.8.3 The Document Management and Workflow System shall be able to prevent Mandatory
the receipt of trivial messages from users as well as other kinds of spam
8.8.4 The Document Management and Workflow System shall take into account Mandatory
the existing comprehensive firewall protection for connections outside of
REA
8.9 Training Requirements

8.9.1 The supplier shall deliver a plan for training of the staff at REA as part of the Mandatory
inception report.
8.9.2 It is required that the supplier works in partnership with the REA and other Mandatory
stakeholders identified by the REA to ensure knowledge transfer and further
build local capacity for maintenance of the system.
8.9.3 The supplier shall involve REA staff when developing administration and Mandatory
users manuals.
8.9.4 As part of the final handover the supplier shall provide the REA management Mandatory
with a written assessment confirming that the responsible REA staff is
competent to assume full responsibility for the system and make
appropriate recommendations about further training or support.
8.9.5 The supplier shall prepare and execute a formal training programme which Mandatory
shall identify timing, structure and content of the following training
programmes for the Document Management and Workflow System:
 Training of Editor(s). The Editor(s) will be staff designated by the REA.
 Training of Superuser
 Training of REA web site programmer (if relevant)
 Training of REA IT staff for system operation
3

 Training of REA database manager
8.9.6 The training shall include the preparation of all training materials (including Mandatory
printed materials) and handouts. All training materials shall be available in
the Montenegrin language; however, part of the system documentation
shall be prepared in English only, approved by REA.
8.9.7 The number of participants of a training session shall be no more than 5 Mandatory
(five)
8.9.8 The training shall cover: Mandatory

 System use (introduction and functionality to all modules, data entry,
searches, reporting etc.);
 System functionality for the editor for content management and design of
the Document Management and Workflow System user interface
 Information management procedures (how and when information is
captured, used and shared as part of the business processes)
 Information security and handling (protective markings, risk assessments,
physical control etc.)
8.9.9 The training shall be delivered in the Montenegrin language and involve: Mandatory
 Presentations
 Discussions
 Practical exercises using the system
8.9.10 The supplier is obliged to deliver a knowledge transfer package which Mandatory
includes training for software development for necessary customization (e.g.
plug-in). The description of the knowledge transfer procedure shall be
described in the offer
8.10 Installation, Testing and Warranty Requirements

8.10.1 Installation The software shall be installed by the supplier at the Mandatory
premises of the REA under the supervision of the REA
3

staff.
8.10.2 Testing There shall be three stages of the software testing Mandatory
and acceptance:
o Factory Acceptance Testing (FAT)
o User Test (UT)
o End User Acceptance Test (UAT)
8.10.3 Test plan The supplier shall deliver a test plan of all tests to be Mandatory
included in the FAT. This plan shall follow IEEE 829-
2008 guidelines. The test plan shall contain
 A list of test scenarios (test cases)
 Detail test cases associated to the scenarios
8.10.4 Test scenario The supplier shall prepare a list of test scenarios Mandatory
which shall contain a short description of real use
cases or workflows to be tested. The list of scenarios
shall be approved by REA
8.10.5 Test cases The supplier shall prepare test case specifications and Mandatory
provide them to the REA for approval. The REA shall
have the right to request modifications to the test
case documentation. The REA shall have the right to
use amended and expanded test cases for the User
Test and End User Acceptance Test (UAT).
8.10.6 Test cases The supplier shall prepare test case descriptions for Mandatory
 Functional tests
 Test of practical and actual workflows / use cases
8.10.7 Test case content The test cases shall cover all test scenarios. The Mandatory
description shall be formatted as a step-by-step
procedure (check-list), where each step is described
3

by following information
 User function
 Detail input test data
 Detailed expected results from the function
Note! Test cases can also be used as training material
8.10.8 Web Service Tests If relevant, the supplier shall use the following SOAP- Mandatory
UI software for the testing of web services:
http://www.soapui.org/
8.10.9 Test and training The supplier shall develop testing, training and Mandatory
environment development environments, separated from the
production system.
8.10.10 FAT The supplier shall perform FAT on all test cases. The Mandatory
FAT shall be documented and accepted by the REA
prior to the installation at REA.
8.10.11 External test During the development period, the supplier shall Mandatory
possibilities establish a test environment which is accessible from
REA and others as decided be REA
8.10.12 User Test After installation, a user test shall be performed at Mandatory
REA and at least one office or Internet user outside
REA. User test and acceptance shall be done after the
training is completed for the relevant REA staff.
8.10.13 Error corrections Based on the user testing the supplier shall correct Mandatory
the software and install a new version of the
software. The user tests shall continue until all errors
are removed.
8.10.14 UAT When all errors are removed, the supplier shall Mandatory
participate in the UAT. The UAT shall take place no
3

more than one week after UT has been completed.
The UAT shall be executed at the premises of REA and
in at least one external office.
8.10.15 Warranty The supplier shall provide a comprehensive warranty Mandatory

for one year. The warranty shall cover all software
and customized applications that are delivered as
part of the software solution and database for the
Document Management and Workflow System.
The warranty period shall begin once End User
Acceptance Test as well as Training is complete and
approved by REA.
8.10.16 Error handling During the installation, acceptance and warranty Mandatory
period the supplier shall provide corrective services.
The supplier shall in the offer present a proposal for
error reporting and corrective services, including
response times.
8.10.17 Support The support during the warranty shall be Mandatory

implemented via a three-level support regime
 1st level support, by a super-user who can
give rapid help to users at REA who
experience a problem with the system. This
requires a person who has very good
knowledge of the system, who can
understand the problem and give advice on
what to do. Many problems can be solved at
this level, without making any changes to the
SW.
 2nd level support by an analyst who can
3

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 as well as for new
functionality
8.10.18 Locally-based The support during the warranty shall be Mandatory
support implemented via locally-based first-level and second-
level support, while third level support may be
provided from outside Kosovo.
8.10.19 Maintenance The supplier is obliged - if requested by REA– to enter Mandatory

into a maintenance contract after the warranty
period has expired
8.11Project Implementation Requirements

ID Capability Feature Type Bidders comments
8.11.1 Staged The supplier shall propose a project plan with the Mandatory
implementation following stages for the two separate systems
(Document Management and Workflow System and
Metadata)
1. Inception
2. System Design
3. Development of pilot system
4. Test, installing and operation of pilot system
5. System development of the final system
6. Test of final system
7. Staff training
3
8. System roll-out
8.11.2 Project schedule The project plan shall include the overall time Mandatory
schedule for the project with milestones. The project
plan shall be integrated with the Pilot Data Conversion
project into one common project plan.
8.11.3 Delivery plan The supplier shall provide a delivery plan that step-by- Mandatory
step specifies the deliveries which shall be approved
by REA after the Inception stage. This plan shall
include:
 Detailed specification of the deliverables
 Timetable of deliveries
8.11.4 Reporting For each of the initial stages: Inception, System Design Mandatory
and Pilot Project, the supplier shall provide a report
with the findings and recommendations for further
implementation. The REA shall accept the reports
individually before the project proceeds to the next
stage.
8.11.5 Project The supplier shall provide a description of the project Mandatory
organisation organisation with roles and required competences of
each position.
8.11.6 Personnel The supplier shall provide CVs for persons nominated Mandatory
for positions for project development and
implementation
8.11.7 Design stage The deliverables from the design stage of the project Mandatory
shall include documentation of
 System architecture document with reference to
required principles
 Data models
 Service specifications
3
 User interface design

 Use Case descriptions / Test scenarios / Test cases
8.12 Project Management Requirements

8.12.1 Communication The supplier and the REA shall communicate via a Mandatory
single point of contact, even though both the
supplier and contracting authority have a project
team
8.12.2 Management roles The supplier shall provide clear role description Mandatory
for the project management covering:
 Authority for technical decisions including
modifications and change orders
 Interface between the REA and the Supplier’s
organization
 Financial administration and authorization
 Quality assurance
 Contract management authority over sub-
contractors.
8.12.3 Project meetings The supplier shall prepare and run project Mandatory
meetings during the implementation of the
project at REA, at least once every 3 weeks.
8.12.4 Task list The supplier shall be responsible for preparing Mandatory
detailed task lists for next period during the
implementation of the project, which shall also
include tasks both for the supplier and the
contracting authority. Essential information in the
task list shall comprise
 Task description
3
 Responsible body and person

 Time for completion of the task
 Status
 Comments
8.12.5 Project reports The supplier shall provide monthly reports on the Mandatory
progress of the deliverables, which shall
comprise:
 Status on the project

 Detailed plan for the following month
 Revised plan for the whole project
 List of actions (task list) and responsibilities
for special tasks to be provided both by
supplier and REA
8.13Support Organisation Requirements

8.13.1 Organisation The supplier shall describe the organization of Mandatory
support
8.13.2 Support procedures The supplier shall specify the support Mandatory
procedures both at locally-based first-level
support and at higher support levels
8.13.3 Local support Local support shall be available from the start Mandatory
of the roll-out of the Document Management
and Workflow System
3
8.14 Economic Requirements

8.14.1 Price offer The price offer shall be submitted in the Bill of Mandatory
Quantity (BoQ) and signed by an authorized
representative of the bidder
8.14.2 Payment The payment plan will be discussed with the Mandatory
winning bidder during the contract
preparations. The principles are:
 Payment per component

 Payment by acceptance
 Payment according the B&Q
8.14.3 Price offer for support Yearly cost for support, software licences and Mandatory
and maintenance maintenance of IT Infrastructure shall be
specified by the supplier as a part of the B&Q
3
Appendix 1
Overview of relevant existing technical infrastructure
1. System Spec SW licenses:

Server installation should be compatible with following server operating systems:
 MS Server 2008 R2 x64
 MS Server 2003 x64
Client operating systems are:
 MS Windows XP,
 MS Windows Vista,
 MS Windows 7 Professional x86/x64
DBMS licenses:
 Oracle
 MS SQL Server
2. Hardware Configuration:
Server allocated for project (in central office in Podgorica):
HP rackmount server with following components:
 Intel Xeon quad core 2.4 GHz 12 MB Cache,
 16 GB RAM
 2 x 146GB 10K SAS, 2.5” Hot Swap HDD in RAID1
 and with following attached storage:
 iSCSI attached 24 TB raw (~14 TB in RAID6) storage system (12 x 2TB MDL SAS drives) ,
 Comment: This storage capacity can be eventually upgraded in future, depending on
software system requirements.
The client workstations satisfy the minimum requirements:
 Intel Core Processor, 1.8GHz
 1GB RAM
 Integrated VGA Card, 1024 x 768 resolution
3. Network:
REA computer network is WAN organized with local networks in each organizational unit.
REA has 23 local offices.
Connection between offices are made through Telekom Montenegro infrastructure,
and are based on optical links with bandwidth 1 - 2 Mbps.
For now only Central office in Podgorica has direct Internet access.
REA network is based on Microsoft windows (server and client) operating system
4. Other
Barcode equipment will be purchased separately.
3
Appendix 2
List of relevant existing scanners
 SMA 10 flatbed scanner

 HP DesignJet 820 mfp roll scanner
 HP ScanJet N9120
 HP ScanJet 8270
 HP ScanJet 6310
 HP ScanJet 5590
 HP ScanJet 5550
3
Appendix 3
SOA – Service Oriented Architecture
The Document Management system will be based on the principles of Service Oriented Architecture
(SOA), namely:
1. Each system module operates independently of other system modules.

2. Each system module completely controls the data for which it is responsible.
3. The system modules communicate with each other and with various other clients via
interoperability services.
Over the last 10 years, SOA has become a well known and accepted method used for
integration of software modules within a software system. In the context of this document,
the SOA principles are also applied to the integration of independent systems.
Interoperability Principles
The integration and communication between actual systems will be implemented by use of services.
The Document Management will deal with two types of interoperability services, namely
 invocation services
 web services
Web Services are services applied between two systems without user interaction. A request for
service is sent by one system as a message, and the response from the other system is a message.
SOAP Web Service, WMS and WFS are examples of Web Services.
Invocation services are used when the service involves user interaction directly to the system which
provides the service. The diagram below shows the principal functionality and data flow of an
invocation service:
1. The user interacts initially in a session with a Client System

2. During the session, the Client needs to ask a Service Provider for data, which must be
selected under user control.
3. The Service Provider will open a user session in parallel to the initial session (two
windows on the screen), where the user has access to functionality to query, select
and/or produce data.
4. The results from the user session at the Service Provider will be stored by the Service
Provider.
5. The Client System will retrieve the result from the Service Provider via a Web Service.
An invocation service implies that a unique (session) key is defined by the Client. The key will be
associated with results which will be stored at the Service Provider. The Client will therefore be able
to request the stored data using the key via a final Web Service.
3
Invocation Service communication
3

Document Management and Workflow System: Real Estate Administration Montenegro

Uploaded by

Copyright:

Available Formats

Document Management and Workflow System: Real Estate Administration Montenegro

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Document Management and Workflow System: Real Estate Administration Montenegro

Uploaded by

Copyright:

Available Formats

Technical Requirement

Real Estate Administration

Version 1.2.July 2012

19/4/12 1.0 Initial Document Oskar

2/5/12 1.1 Corrections after Oskar

4/7/12 1.2 Corrections after misc. Oskar

6.3 Document Administration Requirements.........................................19

Appendix 1: Overview of relevant existing technical infrastructure

1.1 Purpose of this Document

1.2 Scope of this Document

2 Background and Environment

3 Terms and Definitions

Web Service Services applied between two systems without user

Metadata for Data for the description of documents and their

A document aggregation includes a “recipe” of what

Workflow A resource which performs the work represented by a

retrieve audit data relating to the individual

3.1.1 Concept of Workflow Management Terms

Process Definition Workflow Management System

Sub- Processes composed of Used to control and manage via

CAD Computer Aided Design

4 Overall System Concept

4.1 The system Components

interact with the Metadata Editor, Analogue/Digital Conversion, and Raster

4.1.2 Document Management

5 Overall System Requirements

ID Capability Feature Type Bidder’s comments

ID Capability Feature Type Bidder’s comments

ID Capability Feature Type Bidder’s comments

ID Capability Feature Type Bidder’s comments

6 Document Management System

6.1 Overall Requirements

6.2 Data Repository Requirements

ID Capability Feature Type Bidder’s comments

ID Capability Feature Type Bidder’s comments

6.3 Document Administration Requirements

ID Capability Feature Type Bidder’s comments

6.4 Requirements to Metadata Editor

ID Capability Feature Type Bidder’s comments

6.5 Analogue-Digital Conversion and Raster Tools

ID Capability Feature Type Bidder’s comments

6.6 Requirements to View, Search and Download

ID Capability Feature Type Bidder’s comments

ID Capability Feature Type Bidder’s comments

6.7 Import Export Requirements

6.8 Interoperability Requirements

ID Capability Feature Type Bidder’s comments

7 Workflow Management System

ID Capability Feature Type Bidder’s comments

7.2 Requirements to Workflow Data Repository

ID Capability Feature Type Bidder’s comments

7.3 Requirements to Workflow Administration

ID Capability Feature Type Bidder’s comments

7.4 Requirements to Workflow Control

ID Capability Feature Type Bidder’s comments

8 Non Functional Requirements

ID Feature Type Bidder’s comments

8.2 Reliability Requirements

8.3 Usability Requirements