ict software applications · soa service-oriented architecture soap simple object access protocol...

Institutional and Sector Modernisation Facility

ICT Standards

Project Funded by the European Union

ICT Software Applications Document number: ISMF-ICT/3.06 Version: 3.0

1 Document control

1.1 List of Abbreviations Abbreviation DescriptionANSI American National Standards Institute API Application Programming Interface BPEL Business Process Execution Language COM Common Object Model CORBA Common Object Request Broker Architecture CRM Customer Relationship Management D3 Design-Driven Development DBMS Database Management System DCOM Distributed Common Object Model DOM Document Object Model DSDM Dynamic Systems Development Method e-GIF electronic Government Interoperability Framework e-GMS e-Government Metadata Standard ebXML Electronic Business using Extensible Markup Language EDI Electronic Data Interchange EIF European Interoperability Framework ERP Enterprise Resource Planning EU European Union FTP File Transfer Protocol FTR Full Text Retrieval GCL Government Category List GDSC Government Data Standards Catalogue GUI Graphical User Interface HTTP HyperText Transfer Protocol ICT Information and Communication Technology IDABC Interoperable Delivery of European eGovernment Services to Public

Administrations, Businesses and Citizens IEEE Institute of Electrical and Electronic Engineering IMAP Internet Message Access Protocol ISMF Institutional and Sector Modernisation Facility ISO International Standards Organisation LAN Local Area Network OASIS Organisation for the Advancement of Structured Information Standards OCR Optical Character Recognition OLTP On-Line Transaction Processing OMG Object Management Group OOUI Object Oriented User Interface ORB Object Request Broker PICU Project Implementation and Coordination Unit (from ISMF) PKI Public Key Infrastructure POP3 Post Office Protocol version 3 RFID Radio Frequency Identification RPC Remote Procedure Call RUP Rational Unified Process

SAGA Standards and Architecture for e-Government Applications SAX Simple API for XML SGML Standard Generalised Markup Language SMTP Simple Mail Transport Protocol SoA Service-oriented Architecture SOAP Simple Object Access Protocol TP Transaction Processing TPC Transaction Processing Council TSC Technical Standards Catalogue UBL Universal Business Language UDDI Universal Description, Definition and Integration UML Unified Modelling Language UN/CEFACT United Nations Centre for Trade Facilitation and Electronic Business VAT Value Added Tax W3C World Wide Web Consortium WAN Wide Area Network WSDL Web Services Description Language WSFL Web Services Flow Language XML Extended Markup Language

1.2 Purpose of this Document This document constitutes Deliverable 3.06 “ICT Software Applications” of Phase 1 – Development of Reference Documents, Sub-Phase 1.2 – Elaboration of Technical Standards (TS). This deliverable aims at the definition in sufficient detail of the software applications required to implement a specific business need, covering both custom development of software applications and off-the-shelf software systems where applicable. The proposed standards will mostly serve as reference material for the feasibility study and tender documents, as well as for the acceptance procedure of the suppliers’ deliverables.

2 Introduction This document describes the main aspects of the Application Software, providing an overview of: � The related organizational issues, � The Software Architecture issues, � The Interoperability issues, � Non-Functional and Functional requirements. The issues above are discussed in greater detail in the document’s annexes. These annexes provide an explanatory description of the subject as well as specific requirements (usually in form of a compliance matrix) to be included (after consideration and revision) in Tender, Contract and/or Requirements Specification documents.

2.1 Audience The audience consists of the Syrian Public Sector staff involved in Requirements Specification Analysis for Software Application / Integrated Systems development.

2.2 In scope – out of scope It is in the scope of the document to cover all significant aspects of Software Applications Requirements Specification and to provide some sample specifications for the most commonly used software modules. It is out of the scope to provide methodologies, sample tools etc for Application Software development.

3 Application Software Issues

3.1 Definitions Application software is a defined subclass of computer software that employs the capabilities of a computer directly to a task that the user wishes to perform. This should be contrasted with System Software which is involved in integrating a computer's various capabilities, but typically does not directly apply them in the performance of tasks that benefit the user. Examples of Application Software are Word Processors, Spreadsheets, Accounting systems, Human Resource Management systems etc. Multiple applications bundled together as a package are sometimes referred to as an application suite. The separate applications in a suite usually have a user interface that has some commonality making it easier for the user to learn and use each application. And often they may have some capability to interact with each other in ways beneficial to the user. For example a spreadsheet might be able to be embedded in a word processor document even though it had been created in the separate spreadsheet application. Typical simple example is Microsoft Office suite, bundle together a word processor, a spreadsheet, and several other discrete applications. Furthermore, regarding more complex needs, Enterprise Resource Planning (ERP) systems integrate Accounting Systems, Production Management, Client management, Human resource management etc in a homogeneous environment. So do Hospital Information Systems (HIS), integrating back office hospital applications (accounting, financial, purchasing, etc) with front office ones (Admission – Discharge – Transfer of patients – ADT), as well as services provision (medical and nursery operations, health records etc).

3.2 Overview of the related business needs In Syria, the public administration in general is faced with the same business needs and requirements related to software applications, as in the rest of the world. These needs in general can be categorised in two major classes: � Business needs arising from business processes that have significant common

approaches throughout the public sector (e.g. financial services such as accounting, cash management, accounts payable etc., human resources management and project administration).

� Specific business needs pertaining to business processes that are unique, in the sense that they cover the work process of a single organisational unit.

The first class of the above refers to business processes that can be supported by specific ready-made software applications such as Enterprise Resource Planning (ERP) systems, which, with the proper customisations, cover the complete functionality required by organisational units burdened with these specific tasks. The second class refers to business processes for which there are no specific software applications in off-the-shelf or ready-made form and they must be covered by custom-made software applications which will be tailor-made to meet the specific business needs. These needs and requirements incorporate a diversity of issues and aspects, both technical and organisational, including:

� The organisational entities involved, the business processes they perform that require the support of an application software system and the interrelations and interconnection between them.

� The technical architecture of a software application system that has to match and support the business needs of the organisation in the most effective way.

� The interoperability requirements of a software application system so as to be able to exchange information electronically with other related systems to simplify and speed up business operations.

� The non-functional requirements of a software application which are necessary to ensure that it does not only perform what it is intended to but it performs in the most efficient and performant way.

� The functional requirements of a software application which ensure that the specific business needs of the beneficiary organisation are covered and fulfilled by the system and that the system will enhance the method of operation for the day-to-day business.

3.3 Organisational Issues In the case of a software application implemented to cover a specific business need, there is at least one organisational unit (the beneficiary) and in some cases more, which is directly or indirectly involved in its implementation. Following the above mentioned categorisation of the business needs, these organisational units generally include: � Specific Directorates / Departments that are responsible for the financial management and

administration of the organisation. These organisational units, which in many cases are more than one having split responsibilities or form a hierarchical structure by themselves (e.g. a main Directorate having multiple Departments), are responsible for the day-to-day operations related to accounting, budgeting, cash management, fixed assets management, financial monitoring of suppliers and procurement, management and administration of warehouses etc.)

� Specific Directorates / Departments that are responsible for the management of human resources, i.e. the keeping and updating of employee personal details, salary classification, leaves and absences, travels, trainings etc. as well as the issue of payroll for the organisation’s employees in total.

For the above mentioned organisational units, the business processes they are responsible for can be generally standardised (at least as far as the general requirements are concerned). All other business needs (including the administration pf projects) involve for every specific case the specific organisational unit they apply or relate to and possibly other organisational units which are directly or indirectly related. The requirements for these business needs cannot be standardised in any way with the exception of project administration which, although it involves different organisational units per specific instance, relies on the same principles and work processes. A more detailed description of the organisational issues related to software application implementation is provided in Annex 1 of the present document.

3.4 Architectural Issues

Application software, whether ready-made or custom developed, follows an architecture style of the many developed during the evolution of information technology. The most common architecture styles include, but are not limited to: � Client-server � Distributed computing � Peer-to-peer � Blackboard � Implicit invocation � Pipes and filters � Plugin � Monolithic system � Three-tier model � Structured � Software componentry � Service-oriented architecture The above architecture styles pertain to both custom-made and ready-made application software, the most common being the traditional client-server model and the three-tier model. It is obvious that custom-made application software can cover any business need of any organisation whether it is common or unique. In the last years however, it is common practice to utilise a specific kind of ready-made software, namely the ERP systems, to cover specific common business needs that are common in the government work environment, such as the ones presented in the previous section of the present document. A more detailed description of the architectural issues related to software application implementation as well as of the two most common architecture styles (client-server and three-tier model) is provided in Annex 2 of the present document.

3.5 Interoperability Issues Interoperability is the notion of information systems working together in an integral manner by exchanging information in a format that is understandable and usable by the systems involved. Although this is common sense at present, in the past it was one of the most difficult things to accomplish since there was enormous diversity in computer systems, operating systems, programming languages, data storage organisations, even in character encoding. Focusing on the need for information systems to be interoperable so as to facilitate and enhance business operations, recent developments have provided frameworks and standards which ensure that information systems can exchange information in a useful way. The European Union as well as specific member states (such as Germany and the UK) have developed a set of frameworks which, if followed by a public administration, guarantee that information systems can interoperate and exchange data. Furthermore, international organisations have proposed or adopted standards pertaining to process modelling (e.g. UML, BPEL), data modelling (e.g. XML, UBL) and application-to-application interoperability and communication (e.g. Service-oriented Architecture – SoA, Web Services).

A more detailed description of the interoperability issues related to software application implementation is provided in Annex 3 of the present document.

3.6 Non-Functional Requirements Application software, irrespective if it is custom-made or a ready-made system customised to fit business needs, must conform to specific requirements and fulfil specific needs, which are not directly related to the functionality of the system itself. These requirements affect the quality and the usability of the system and have a direct effect to user satisfaction and full coverage of the system’s goals, and consequently, to the success of the system. The general categories of non-functional requirements and specifications a system must cover are: � Security, which is related to the provisions of the system that ensure confidentiality,

integrity, availability of information, access control and non-repudiation. � Performance, which is related to the metrics a system must abide by, in order to perform

efficiently within predefined time limits. � User friendliness, which is related to the characteristics a system must provide in order for

its users to perform their tasks with ease and efficiency. � Documentation, which is related to the principles the system textual description must abide

by, in order to provide its users with the information and reference material required for efficient operation.

� Data migration, which is related to the methodology and steps required in order to effectively transfer data from existing legacy systems to new systems.

� Data entry, which is related to the methodology and organisation of the task of manually entering massive data into the system both at the initial stage before system operation and as a continuous task during system operation.

� Quality, which is related to the intangible characteristics a system must possess so as to be complete, useful, usable and eventually successful.

A more detailed description of the non-functional requirements related to software application implementation is provided in Annex 4 of the present document.

3.7 Functional Requirements Specifying in detail the functional requirements a system must cover is a very difficult task, but unavoidable in the case of public procurement, which is the most common situation for public administrations. In order to arrive at the detailed design of the functional requirements of a system, some preparatory steps must be performed: � The analysis of the business needs and environment that will provide the context that the

system must perform in. � The specification of the system which will set the boundaries of the system and the

expectations the users have from it. In the case of custom-made application software, specifying the system’s functional requirements can be a very demanding task. The process involves detailed interactions with the users in order for them to specify the functionality the system is expected to provide as well

as elaboration of a high-level technical design of the system so as to provide useful input to the tendering process. It has to be noted that this task is one-off, in the sense that its outputs cannot be reused due to its unique nature. In the case of ready-made software, such as ERP systems, there is a common set of functional requirements derived from best practices, covering the more standard business processes presented above. These requirements cover application software systems that pertain to public administration line of work, such as: � Financial systems

� Budgeting � General Ledger � Cash Management � Accounts Payable � Accounts Receivable � Fixed Assets � Warehouse Management

� Project Administration � Costing � Time and Expense � Activity Management

� Human Resources � Human Resources � Payroll � Training � Time & Attendance

� Vehicle Management In addition, basic standard requirements can be provided covering the area of workflow and document management, which is a horizontal discipline, pertaining to every public administration line of business and providing a uniform method of operation for the management of documents and the standardization of the day-to-day business operations. A more detailed description of the functional requirements related to ready-made software applications (ERP systems) is provided in Annex 5 of the present document.

AANNNNEEXXEESS

1 Annex 1: Organisational Issues This annex presents the basic problems addressed in the preparation for the implementation of a software application system especially for systems that are categorised as having common functionality across the public administration, the organisational structure and issues pertaining to the implementation of such systems as well as the summary business processes these systems cover.

1.1 Problems to be addressed All over the world public administration organisations are performing a huge diversity of business processes which are impossible to standardise due to both legislative issues and their nature which differs dramatically from one organisation to another. However, there is a set of business areas which is common in concept throughout public organisations, although with several minor diversities in their details. These business areas relate to: � Financial services and accounting, including general ledger, budgeting, accounts payable,

accounts receivable, cash management, fixed assets and warehouse management � Human resources management and payroll of personnel � Project administration and monitoring � Vehicle management � Maintenance By being common in concept, the business areas presented above provide a good basis for the standardisation of a minimum set of specifications for software applications supporting them. Modern technology caters not just for the automation of the above mentioned services but also for their integration and for the standardisation of the work processes of the employees related to the information systems of an organisation. This goal can be accomplished by the design, implementation and deployment of a workflow system providing the users with a formal and standard way of performing their tasks through the automation of a series of steps for the execution of a business process and through clearing any ambiguities related to approval authorisations and setting the limits and boundaries each user has in performing his tasks. It has to be noted that a workflow system operates us an “umbrella” on top of the specific business systems in the sense that it provides the framework in which activities and tasks can be sequenced, prioritised and put on scale. The workflow system also provides a platform for the automatic allocation of work to employees by automatically routing requests for task execution to specific users who have the authority and competence to perform them. The computerisation of a business area is a task that should be performed after specific preparatory activities have been executed so as to maximize the added value of the information system that will be built and get the best possible results from its implementation. These preparatory activities include: � Business needs analysis � Information process reengineering � High-level system specification

Business needs analysis In order for the implementation of an application software system to be performed, an initial activity that has to be carried out is the definition of the specific business needs driving the implementation. This analysis is the cornerstone for the elaboration of the feasibility study for the system since it sets the grounds for the justification of the need for the investment. This analysis covers the following areas: � The description of the business problem the application software has to solve. � The specific business processes that will benefit from the implementation of the application

software. � The anticipated results from the system implementation and how this will affect and

enhance the day-to-day business of the specific beneficiary organisation. � The available resources (or lack of them) required for the successful implementation of the

system. � The cost expectations and timescales for implementation to meet the business critical

expectations.

Information process reengineering The activity of Information Process Reengineering is very important before the implementation of an application software system that covers specific business needs and it is related to evaluating and modifying an information development, delivery, or distribution process, or some combination thereof. The reason this activity is important is because business processes related to information handling and delivery in non-computerised environments are adapted to and make effective use of the manual method of operation. Seeking to computerise the manual method of operation without first performing an information process reengineering usually leads to disastrous situations since the business processes usually take longer to complete and become more complex when supported by a software application. The activity of information process reengineering enhances the business processes by adapting them to the information support environment thus reducing complexity and enhancing efficiency. A solid example of information process reengineering is a process which, in its manual form involves the issue of a roundabout form which the customer has to present to many offices to get approvals, signatures or specific information on it in order to complete his business. In a computerised system, however, the same process does not need a roundabout form, but rather the customer can complete his business in just one office (i.e. the one-stop-shop principle), while the form, in its electronic format, gets electronic approvals from all other offices involved. The information process reengineering activity involves the following steps: � Understanding a current process and assessing its effectiveness

The current processes in their manual form have to be analysed and understood thoroughly in terms of tasks required to accomplish, inputs required for the execution of each task, processing of these inputs per task, outputs generated by each task and task hierarchy and interconnections.

� Envisioning and designing an improved process supported by the application software that meets business objectives After a process has been thoroughly analysed, it is possible to restructure and redesign it in terms of inputs, processing and outputs so as to exploit the possibilities offered by information technology. The new redesigned process steps will form the requirements for the design and implementation of the application software supporting the specific process.

� Implementing a more effective process Since the new redesigned processes may have significant differences than the manual ones, their implementation has to be made in parallel with the deployment of the application software supporting them.

High-level system specification In the project lifecycle, the implementation of an application software system has to go through many steps, including definition, design, procurement and implementation. During design of the application software a high level description of its specifications has to be made so as to set the expectations of key stakeholders from its implementation. This high level description should incorporate the definition of the business processes the application software will support and its major interconnections with other related systems for the exchange of information. During procurement of the application software, the tender documents should include a more detailed definition of its functionality encompassing the “Functional Requirements” the application software is supposed to deliver as well as the “Non-Functional Requirements” that are mandatory for its effective use and exploitation. Both these functional and non-functional requirements are the output of a high-level system design (as opposed to the detailed system design that will be performed by the contractor who will undertake the implementation).

1.2 Organizational Units Involved In Syria, as it is the case worldwide, all public administration organisations have discrete organisational units (Directorates, Departments etc.) that are assigned the day-to-day execution of specific business processes. These business processes in general have a great diversity both in scope and in their operating principles and method of work. Nevertheless, as already stated above, there is a set of business processes which are generally common within most of the public administration organisations (i.e. financial services, human resource management and project administration). These processes can be categorised as back-office in the sense that there is limited (if any) interaction with “customers” outside of the organisation itself. In principle, the Syrian public administration organisations (e.g. ministries, public sector enterprises etc.) have dedicated organisational units responsible for the specific business areas presented above. More specifically, each organisation has in its organisational structure a specific directorate that is responsible for the complete set of processes related to financial management and administration. This directorate performs all the day-to-day work related to: � Purchase Ledger (Accounts Payable) � Sales Ledger (Accounts Receivable) � Cash management � Fixed assets management � Budgeting � Issuing pf payroll Additionally there is a specific department having the main responsibility for General ledger entries and control. Apart from the above, in organisations that buy, keep or distribute goods, there is also a department responsible for warehouse management and bookkeeping.

Additionally, every public sector organisation has a directorate responsible for the administration of its personnel. This directorate can be either centralised or decentralised according to the nature of the organisation and the needs for regional and local administration of resources. This directorate is responsible for keeping the updated employee records, recording leaves and absences and keeping all information related to the payroll of employees. As far as the monitoring of projects is concerned, responsibility is split between multiple organisational units within the organisation. Project financials (e.g. payments, expenses etc.) are monitored by the financial administration directorate while the planning department has the general responsibility for all projects. The monitoring of project execution lies with the directorate or department which has the responsibility for the business process the project relates to. The above mentioned pertain only to systems that can be standardised in a way due to their common nature across all public sector organisations. Other software application system which relate to business processes that are specific to one organisation or organisational unit, involve this organisational unit (and possibly other).

1.3 Business Processes The organisational units discussed above execute a set of business processes that can be supported by software application systems. These processes can be summarised as follows:

Accounting Units � The entering of financial transactions into the system and the execution of the complete set

of daily and periodic functions of a public administration accounting department such as maintaining and updating chart accounts, journals and balances, keeping tax and VAT collection and reimbursement information, control of supplier invoices etc.

Financial Administration Units � The management and administration of the fixed assets registry of the organisation, the

calculation of periodic depreciation of assets etc. � The preparation, adjustment, execution and control of the yearly budget of the organisation

and of the investment budget, should they exist. � The preparation, execution and control of the organisation’s cash flow programme as well

as the execution of all payments to suppliers or other beneficiaries. � The administration and management of supplier information (i.e. basic data, financial

information, price lists, discounts etc.) and of order processing. � The administration and management of warehouses and goods stored and distributed. � The issuance of monthly or periodic payroll for the total of the organisation’s employees or

for an individual employee.

Human Resource Management Units � The keeping and updating of human resources personal details. � The keeping and updating of employee skills and qualifications information.

� The evaluation and assessment of personnel based on performance appraisals. � The allocation and assignment of personnel to organisational units based on their skills

and qualifications. � The evaluation of staffing requirements of the organisation taking into account the existing

staff allocation and their qualifications and skills. � The keeping and updating of employee training information related to courses attended. � The monitoring and control of employee absences and leaves. � The administration of employee travels. � The classification of employees to specific salary grades and the monitoring and keeping

of all changes affecting an employee’s monthly salary.

Project Administration � The planning and design of projects as related to the activities to be executed, their

interrelations and the project milestones. � The budgeting of projects. � The management of project costs versus their budget. � The schedule of activities related to project execution. � The monitoring of project execution and the related reporting requirements.

2 Annex 2: Software Architecture Issues This annex presents the concept of architecture styles for software applications, provides a general overview of the Enterprise Resource Planning (ERP) software application paradigm, and makes a quick reference to Software Engineering methodologies and techniques.

2.1 Architecture The software architecture discipline is centered on the idea of reducing complexity through abstraction and separation of concerns. As a maturing discipline with no clear rules on the right way to architect a system the action of architecting is still a composition of art and science. The “art” aspect of software architecture is due to the fact that a commercial software system supports some aspects of a business or a mission. How a system supports key business drivers is described via scenarios as non-functional requirements of a system, also known as quality attributes, determine how a system will behave. To bring a software architecture user's perspective into the software architecture, it can be said that software architecture gives the direction to take steps and do the tasks involved in each such user's specialty area and interest e.g. the stakeholders of software systems, the software developers, the software system operational support group, the software maintenance specialists and also the business end user. In this sense, software architecture is really the amalgamation of the multiple perspectives a system always embodies. The fact that those several different perspectives can be put together into a software architecture stands as the vindication of the need and justification of creation of software architecture before the software development in a project attains maturity. ANSI/IEEE 1471-2000: Recommended Practice for Architecture Description of Software-Intensive Systems is the first formal standard in the area of software architecture, and was recently adopted by ISO as ISO/IEC DIS 25961. Its contributions lie in the following: � It provides definitions and a meta-model for the description of architecture � It states that an architecture exists to respond to specific stakeholder concerns about the

software/system being described � It asserts that architecture descriptions are inherently multi-view, no single view captures

all stakeholder concerns about an architecture � It separates the notion of view from viewpoint, where a viewpoint identifies the set of

concerns and the representations/modeling techniques, etc used to describe the architecture to address those concerns.

� It establishes that a conforming architecture description has a 1-to-1 correspondence between its viewpoints and its views.

� It provides for capturing rationale and inconsistencies/unresolved issues between the views within a single architecture description

Within the ontology established by ANSI/IEEE 1471-2000, views are instances of viewpoints, where a viewpoint exists to describe the architecture in question from the perspective of a given set of stakeholders and their concerns. Some possible views defined in the ANSI/IEEE 1471-2000 ontology are: � Functional/logic view � Code view � Development/structural view � Concurrency/process/thread view

� Physical/deployment view � User action/feedback view There are many common ways of designing computer software modules and their communications. An indicative list of software architecture styles includes: � Client-server, which separates the client (often an application that uses a graphical user

interface) from the server. Each instance of the client software can send requests to a server which in turn processes the request and returns the results to the client.

� Distributed computing, which is decentralised and parallel computing, using two or more applications communicating over a network to accomplish a common objective or task.

� Peer-to-peer, which implements only peering protocols that do not recognize the concepts of "server" and "client".

� Blackboard, which is composed of an area of shared memory that contains a problem to be solved and a collection of software agents or processes that can access and modify the blackboard.

� Implicit invocation, in which a system is structured around event handling, using a form of callback.

� Pipes and filters, which consist of a chain of processes or other data processing entities, arranged so that the output of each element of the chain is the input of the next.

� Plugin, in which computer programs interact with a main application to provide a certain, usually very specific function.

� Monolithic system, in which processing, data and the user interface all reside on the same system.

� Three-tier model, in which the user interface, functional process logic (business rules), data storage and data access are developed and maintained as independent modules, most often on separate platforms.

� Structured, which is a waterfall method by which an Information System design can be arrived at.

� Software componentry (strictly module-based, usually object-oriented programming within modules), in which a software component is a system element offering a predefined service and able to communicate with other components.

� Service-oriented architecture, which defines the use of loosely coupled software services to support the requirements of the business processes and software users. In an SoA environment, resources on a network are made available as independent services that can be accessed without knowledge of their underlying platform implementation.

It is obvious that, whichever architecture a software application uses, it has to be integrated with the architecture of the information system as a whole, taking into account and exploiting the facilities and architectural components offered by the hardware and system software architecture. It must be noted however that, in the case of a workflow system being implemented together with the systems covering specific business needs, the software application architecture must cater for their interconnection and interoperability so that the systems can work together seamlessly. This can be achieved by utilising the most flexible software application architectures (e.g. distributed computing, Service-oriented architecture etc.) as opposed to strict architectures (e.g. monolithic or client-server).

2.2 Most Common Architectural Styles

2.2.1 Client-server two tier model

Overview Client/server model was the preferred architectural style throughout the late 1980s and early 1990s, as applications were migrated from centralized minicomputers and mainframes to networks of desktop computers. The client is a process (program) that sends a message to a server process (program), requesting that the server perform a task (service). The connection between them is established via a local area network (LAN) or wide area network (WAN). Typically, client process:

o runs on the user’s PC, o Manages the user-interface portion of the application, validates data entered by the

user, dispatches requests to server programs, and sometimes executes business logic. o Constitutes the front- end of the application that the user sees and interacts with. o Contains solution-specific logic and provides the interface between the user and the

rest of the application system. While server process:

o Runs on a more powerful (usually multiprocessor) computer, o Manages the application data (usually an RDBMS), assuring the availability and

integrity of them providing stored procedures and triggers. o Constitutes the back-end of the application.

Client / server model must not be confused with file server model, since in the later case the server is a “passive” equipment providing just extended storage capabilities to the user’s PC. File servers, which range in size from PCs to mainframes, store data and programs and share those files with the clients. In this case, the server functions as a remote disk drive to the clients. To be a true client/server environment, both client and server must share in the business processing. For example, a database server processes requests from the client to look up data or update data in its database. In this case, the server is performing a search at its end to respond to the query received from a client. It is not acting as a remote disk drive; it is fully participating in the transaction. The basic characteristics of client/server architectures are: � Combination of a client or front-end portion that interacts with the user, and a server or

back-end portion that interacts with the shared resource. The client process contains solution-specific logic and provides the interface between the user and the rest of the application system. The server process acts as a software engine that manages shared resources such as databases, printers, modems, or high powered processors.

� The front-end task and back-end task have fundamentally different requirements for computing resources such as processor speeds, memory, disk speeds and capacities, and input/output devices.

� The environment is typically heterogeneous and multivendor. The hardware platform and operating system of client and server are not usually the same. Client and server processes communicate through a well-defined set of standard application program interfaces (API's) and Remote Procedure Calls (RPCs).

� An important characteristic of client-server systems is scalability. They can be scaled horizontally or vertically. Horizontal scaling means adding or removing client workstations

with only a slight performance impact. Vertical scaling means migrating to a larger and faster server machine or multiple machines.

Generic client/server architecture has two types of nodes: clients and servers. As a result, these generic architectures are sometimes referred to as "two-tier" architectures.

Limitations The two tier client/server architecture is a good solution for distributed computing when work groups are defined as a limited number (not more than 100 people) interacting on a LAN simultaneously. It does have a number of limitations. When the number of users exceeds certain limits, performance begins to deteriorate. This limitation is a result of the server maintaining a connection via "keep-alive" messages with each client, even when no work is being done. A second limitation of the two tier architecture is that implementation of processing management services using vendor proprietary database procedures restricts flexibility and choice of DBMS for applications. Finally, current implementations of the two tier architecture provide limited flexibility in moving (repartitioning) program functionality from one server to another without manually regenerating procedural code.

2.2.2 Client server three-tier model

The three-tier architecture (also referred to as the multi-tier architecture) emerged to overcome the limitations of the two tier architecture. In the three-tier architecture, a middle tier was added between the user system interface client environment and the database management server environment. There are a variety of ways of implementing this middle tier, such as transaction processing monitors, message servers, or application servers. The middle tier can perform queuing, application execution, and database staging. For example, if the middle tier provides queuing, the client can deliver its request to the middle layer and disengage because the middle tier will access the data and return the answer to the client. In addition the middle layer adds scheduling and prioritization for work in progress. The middle tier may be multi-tiered itself (in which case the overall architecture is called an "n-tier architecture"). The three-tier client/server architecture has been shown to improve performance for groups with a large number of users (in the thousands) and improves flexibility when compared to the two-tier approach.

2.2.3 The Web-based Client/Server model

Because of the Internet, terms such as "Web based" and "Web enabled" replaced the 1990s client/server buzzword, with "client/server" insinuating the old pre-Web way of doing things. However, most client/server systems were modified to include Web access, and the Web "is" naturally a true client/server architecture. On the server side, the Web uses a multi-tier architecture with interlinked Web servers, application servers, database servers and caching servers. On the client side, user machines commonly execute scripts embedded in countless Web pages. They also execute Java applets, Java programs and rich client applications, all of which means that both client and server are cooperating in tandem. A limitation with the n-tier web-based architectures is that the development environment is reportedly more difficult to use than the visually-oriented development of traditional client/server applications. Furthermore, the web-based applications relate with the use of “thin” clients, i.e. minimal clients which use as few resources on the host computer (user’s PC) as

possible, prohibiting the combined usage of any local files or applications (e.g. word processors or spreadsheets).

2.2.4 Conclusion

Traditional client-server applications take advantage of the client’s (i.e. user’s PC) processing power and other resources. Development tools provide great flexibility and address most complex interface needs. On the other hand, they provide medium performance scalability and implementation flexibility. Web-base applications provide excellent performance scalability and implementation flexibility. One the other hand the user interface may be rigid and the applications development more difficult than in the traditional client-server model.

2.3 Off-the-shelf and Custom Application Software Overview The business needs, as far as application software support is concerned, can be addressed in multiple ways. Until several years ago the only way to provide information systems support for specific business functions was to implement a software system from scratch. These custom-implemented systems usually worked as standalone “islands-of-information”, that is interoperability and exchange of information between two such systems was either very difficult or nearly impossible. In the recent years the concept of Enterprise Resource Planning (ERP) systems has emerged and gained wide acceptance. Enterprise Resource Planning systems (ERP) integrate (or attempt to integrate) all data and processes of an organization into a single unified system. A typical ERP system will use multiple components of computer software and hardware to achieve the integration. A key ingredient of most ERP systems is the use of a single, unified database to store data for the various system modules. The term ERP originally implied systems designed to plan the utilization of enterprise-wide resources. Although the acronym ERP originated in the manufacturing environment, today's use of the term ERP systems has much broader scope. ERP systems typically attempt to cover all basic functions of an organization, regardless of the organization's business or charter. Business, non-profit organizations, non governmental organizations, governments, and other large entities utilize ERP systems. Additionally, it may be noted that to be considered an ERP system, a software package generally would only need to provide functionality in a single package that would normally be covered by two or more systems. Technically, a software package that provides both Payroll and Accounting functions would be considered an ERP software package. However, the term is typically reserved for larger, more broadly based applications. The introduction of an ERP system to replace two or more independent applications eliminates the need for external interfaces previously required between systems, and provides additional benefits that range from standardization and lower maintenance (one system instead of two or more) to easier and/or greater reporting capabilities (as all data is typically kept in one database). Examples of modules in an ERP which formerly would have been stand-alone applications include: Manufacturing, Supply Chain, Financials, CRM, Human Resources, and Warehouse Management.

The tight integration between the modules of an ERP system provides the basis for supporting the back-office processes of an organisation. Nevertheless, it is generally wrong to consider ERP systems as pure back-office systems since they support also front-office activities through modules such as Customer Relationship Management (CRM) etc. Apart from the above common business functions that can be covered by ready-made but customisable ERP systems, there are also needs of information support for specific and specialised business functions within a public-sector organisation. Since these needs cannot be covered by ready-made off-the-shelf software, the solution is custom software development based on specific methodologies, principles and standard tools. The latter can be collectively called Software Engineering.

Software Engineering incorporates many different software development processes (philosophies), each one having its pros and cons, the most common of which are: � Agile software development � Best practice � Design-driven development (D3) � Dynamic Systems Development Method (DSDM) � Iterative and incremental development � Quick-and-dirty � Rational Unified Process (RUP) � Scrum (management) � Spiral model � Waterfall model The detailing of each philosophy will not be covered here as it is outside the scope of the present document. What must be noted though is that all the software engineering processes are composed of many activities which are considered sequential steps in the Waterfall process, but other processes may rearrange or combine them in different ways.

3 Annex 3: Interoperability and Interconnections This Annex describes the basic notions of Software Interoperability, the related standards and the major initiatives to achieve it, as well as the related software quality attributes in the form of a compliance matrix.

3.1 General A very important aspect of software applications is their ability to interconnect and interoperate exchanging information and providing the grounds for updating data only at one point (usually where data are created). With respect to software, the term interoperability is used to describe the capability of different programs to exchange data via a common set of business procedures, and to read and write the same file formats and use the same protocols. According to ISO/IEC 2382-01, Information Technology Vocabulary, Fundamental Terms, interoperability is defined as follows: "The capability to communicate, execute programs, or transfer data among various functional units in a manner that requires the user to have little or no knowledge of the unique characteristics of those units". As far as off-the-shelf ERP systems are concerned, interconnectivity and interoperability are ensured by the design and architecture of the systems themselves. ERP systems, especially the market leading packages, are built around a single database which ensures data exchange between the ERP’s software modules. Furthermore, the software modules implementing the different business functions are built using having common user interfaces and similar or even identical look-and-feel and are based on a common application platform thus ensuring their interconnection.

3.2 Interoperability Frameworks Most problems related to interconnectivity and interoperability arise from custom-made software applications, which need to exchange information with other applications potentially built on totally different platforms and with totally different architecture. These is especially true in relation to public administration information systems, where there is a mixture of beneficiaries each one implementing systems with a different strategy, resources, timing and contractors. To overcome these problems, several organisations such as the European Union and the governments of developed states have created policies, launched initiatives and built frameworks providing rules, regulations and guidelines to ensure interoperability between their software applications, such as: � The i2010 initiative

The European Commission has proposed a new strategic framework, i2010 – European Information Society 2010, which defines the general policy and orientation on the subject. It promotes the open and competitive market economy and highlights the Information and Communication Technologies (ICT) as the “engines” for social equity and quality of life. As a key element of the updated Lisbon strategy for employment, the i2010 strategy is based on an integrated approach of the EU policies on Information Society.

� The eEurope initiative

In the framework of the eEurope 2005 initiative, several measures are applied which focus on both sides of the equation: on the demand side, actions for electronic governance, electronic health, electronic learning and electronic commerce are foreseen leading to the enhancement of innovative services development. On the request side, actions related to broadband technology and security, are expected to promote the spreading of infrastructure.

� The IDABC programme

The objective of the IDABC programme (Interoperable Delivery of European eGovernment Services to Public Administrations, Businesses and citizens) is to define, support and promote the implementation of pan-European electronic governance services and the development of the related interoperable telematic networks, by supporting the member states and the European Union to apply in their fields of responsibility the European Community policies and activities so as to harvest significant benefits for the public administrations, the businesses and the citizens. This programme aims also at: � Enabling the effective, productive and secure exchange of information between public

administrations in all appropriate levels, as well as between public administrations and the EU or other institutions respectively.

� Expanding the benefits of information exchange, as this is defined above so as to enable the delivery of services to businesses and citizens taking into account their respective needs.

� Supporting the European Union decision making processes and enabling communication between community institutions by developing the relevant strategic plan in pan-European level.

� Achieving interoperability both within and between different policy sectors and, where appropriate, with businesses and citizens, based mainly on the European Interoperability Framework.

� The United Kingdom e-Government Interoperability Framework (UK e-GIF)

The electronic Government Interoperability Framework (e-GIF) provides policies and specifications so as to achieve interoperability and compatibility between information systems and communication systems of the United Kingdom public sector. The architecture which e-GIF complies with includes: � The e-Government Interoperability Framework. The specifications and policies of the

framework comprise the following: � Technical policies: general directives and standards to be adopted are provided for

the technical implementation of interconnection, networks, data integration, content management metadata, access and service provision channels, and standardisation of business areas.

� Implementation support: directives are provided for the development and maintenance of the framework and the tools required for its development. General descriptions and directions are provided for the implementation of XML schemas, the standard for metadata used by the public sector (e-Government Metadata Standard – e-GMS), the central website (http://www.govtalk.gov.uk/) and the members of working teams.

� Administration procedures: directions are provided for the roles and responsibilities of the government, the public institutions and the businesses so as to ensure the

successful implementation of the framework. Additionally the responsibilities of the working teams are described.

� Change management: directions and restrictions for the changes that will take place in the existing framework are provided.

� Conformance to the framework: the critical conformance points to the framework directives are stressed out.

� The e-GIF Interoperability Registry which covers the e-GMS metadata standard and the Government Category List (GCL), the Government Data Standards Catalogue (GDSC), the XML schemas and the Technical Standards Catalogue (TSC).

� The German Standards and Architecture for e-Government Applications – SAGA

The Standards and Architectures for e-Government Applications Framework was issued by the Federal Ministry of Interior of Germany with the utter objective to identify the required standards, formats and specifications and create rules and regulations which will ensure e-Governance and interoperability. The main principle of SAGA is simplicity and clarity of standards and specifications so as to satisfy the requirement for modern e-Governance with Information and Communication Systems which ideally collaborate and cooperate unobstructed. The SAGA framework aims at the following: � Continuous flow of information between citizens, businesses and administrations. � Similar approaches to services and data models through the notion of reusability. � Reduction of costs and potential risks. SAGA action directives include: � Specifications of technical standards, regulations and architectures � Process modelling � Data modelling � Development of the indispensable basic components

� The European Interoperability Framework – EIF IDABC

The European Union, in the framework of Interoperable Delivery of European e-Government Services to Public Administrations, Businesses and Citizens (IDABC), has issued the European Interoperability Framework (EIF) for e-Governance. The aim of this framework is: � The definition of main directions and principles for the delivery of e-Governance

services in pan-European level and for the interoperability between different member states’ e-Governance systems.

� The provision of directives and recommendations to the member states of the European Union for the adoption of EIF when designing national frameworks, so as to ensure interoperability in pan-European level.

3.3 Interoperability Standards Apart from the general initiatives and frameworks presented previously, which provide the general rules and guidelines for software applications interoperability, this can be achieved by the application of de facto or de jure standards related to process modelling, data modelling and application interconnection. An indicative list of these standards is:

� Process Modelling Standards� Unified Modelling Language – UML

The Unified Modelling Language (UML) is a visual modelling language with descriptive capabilities for the visualisation, specification, documentation and construction of the system implementation products. It is an international standard according to ISO/IEC 19501:2005 Information technology -- Open Distributed Processing -- Unified Modelling Language (UML) Version 1.4.2. In general, UML proposes a model which is not just a simple collection of diagrams providing graphical representations but includes a semantic dimension as well, providing descriptive documentation such as Use Cases which drive the elements and diagrams of the model.

� Business Process Execution Language – BPELThe Business Process Execution Language (BPEL) is an XML process modelling language which aims at the representation of interactions and state transitions of a process in a high level. It originates from a common IBM – Microsoft initiative to combine the Web Services Flow Language (WSFL) and the XLANG, that they had developed respectively, into a common language the Business Process Execution Language for Web Services (BPEL4WS). The BPEL specifications are XML documents which define the following components of a process: � The distinct roles that participate in message exchange for the process. � The interfaces which must be supported by the distinct roles and the process itself. � The data and access to data models, the service selection models, the transaction

models and the error handling models that constitute the definition of a process. � The correlation information which define how messages are routed in the right

composition instances. � Electronic Business using Extensible Markup Language – ebXML

The ebXML appeared as an initiative of the international organisations OASIS (Organisation for the Advancement of Structured Information Standards) and UN/CEFACT (United Nations Centre for Trade Facilitation and Electronic Business). It aims at the provision of an open XML based infrastructure which will enable businesses, independently of their size and geographic location, to make transactions over the Internet. Using ebXML businesses communicate through standard methods for the exchange of business messages defining the respective business processes. The ebXML architecture aims at both large and medium and small size businesses who in the near past had limited participation in e-business due to the high cost for the implementation of Electronic Data Interchange (EDI) systems.

� Data Modelling Standards

� Extensible Markup Language – XMLXML (eXtensible Markup Language) is a mark-up language proposed by World Wide Web Consortium (W3C) for document processing. Actually it is a simplified form of SGML (Standard Generalised Markup Language), an international document standard existing since the 80s (SGML - ISO 8879:1986). XML is a standard representation of structured data in the sense that data having some kind of structure can be represented by XML and take the form of a document. A subtle point in XML documents is that they describe their own self, i.e. besides the text they contain there is also a set of declarations defining the semantics of the content.

XML is the de facto standard for storing data exchanged between applications because of the following characteristics: � It supports data independence and separates the contents from their presentation

and handling, thus facilitating parsing. � There are ready-made tools for the processing of XML documents by the modern

programming environments, such as the Document Object Model (DOM) and the Simple API for XML (SAX).

� It is extensible and platform independent, which makes it invulnerable to changes in technology.

� The XML documents are readable by both humans and machines, and although they are not meant to be read by humans they offer this opportunity whenever required.

� It is fully compatible with Unicode, so it can handle information written in any human language. Additionally it supports international and local adaptations.

� Using XML the creators of documents can represent complex data structures and describe any data type.

� Universal Business Language – UBL

UBL (Universal Business Language) was designed by the Technical Committee of OASIS (Organisation for the Advancement of Structured Information Standards) with the participation of many industrial data standardisation organisations and is an international initiative for the definition of an open, publicly accessible library of standard electronic business documents.

� Application-to-Application Interoperability and Communication Standards

� Service-oriented Architecture (SoA)The Service-oriented Architecture is based on a service-centred design of applications, the latter being representations of real programs, databases, or business processes which are defined according to what they do, are specified in the frame of messages exchanged and are accessible through a network. There are four principles by which services following the Service-oriented Architecture must abide: � Formal and explicit definition of the service boundaries. � Autonomy between services. � Sharing of schemas and contracts but not of classes between services. � Ensuring of compatibility between services through policies.

SoA’s main characteristics are the following: � Support of loose coupling between components which allows changes in the way

services are implemented without effect on other parts of the application. The only interaction between the application and the services is through the published interfaces.

� Location transparency, meaning that the user of a service does not know where the implementation of the service lies.

� Reusability of code and components.

� Web ServicesWeb Services are a new generation of internet applications which offer a standardised way of interaction between different software applications independent of their implementation platform and framework and without demanding any change

whatsoever in the system mechanism. Web Services are today the next step in object-oriented programming: instead of developing applications from a limited set of class libraries provided in one location, programmers can access countless libraries through a computer network, e.g. the internet, an intranet or any other kind of network. A Web Service consists of a stack of related technologies placed on different layers, as depicted in the following figure. Starting from top to bottom there are: � A protocol for data transfer through the internet such as HTTP (HyperText Transfer

Protocol), SMTP (Simple Mail Transport Protocol) or FTP (File Transfer Protocol). � A communication protocol for the exchange of XML messages, i.e. SOAP (Simple

Object Access Protocol). � The WSDL (Web Services Description Language) for the definition of interfaces

and mechanisms for the interaction between services. � The issue of service finding for which three approaches exist: the existence of a

catalog documenting and publishing the services in the form of a registry such as UDDI (Universal Description, Definition and Integration) and DISCO (Microsoft Discovery), which is the most widely used solution, the existence of service reference web pages such as amazon (http://www.amazon.com) and google (http://www.google.com), and the peer-to-peer service discovery where services discover each other dynamically in an network of equivalent services.

� The service flow layer which describes the communication, the synergies and the flow of information between services, using WSFL (Web Services Flow Language).

3.4 Basic Interoperability Requirements In the case of custom-made application software, the system must conform to specific requirements so as to ensure interoperability with other systems. More specifically, these requirements include: � A well defined format for the information (standards for the structuring of data and

metadata) � A well defined method for information exchange (communication technologies and

protocols used to transfer information in the predefined format) � A well defined method for access to information and data � A well defined method for querying information and data (metadata technologies, Web

Services or any other technologies used for information retrieval in interoperable services) These requirements of a specific system can be expressed as follows:

# REQUIREMENT MANDATORY (Y/N)

1. The system must provide APIs for building interfaces with other systems Y

2. The system must support Web Services standards such as WSDL, SOAP, UDDL, WS-I N

3. The system must support XML technology Y

4. The XML implementation must conform to the directives and standards of the World Wide Web Consortium (W3C). Y

5. It is desirable that the system supports Semantic Standards such as EDI for the exchange of information between systems and applications N

4 Annex 4: Application Software Non-functional Requirements This annex presents software application requirements that are non-functional but mandatory for the successful implementation and operation of an information system. These requirements fall into the general categories related to security, performance, user friendliness, documentation, data migration and data entry and quality.

4.1 Security Requirements The modern perception for information systems security suggests that this specific topic has a broader field of application nowadays than it used in the past. It encompasses both technical issues such as application security, systems security etc. and organisational and business issues of the beneficiary of the information system. Furthermore, information systems security is significantly affected by the underlying laws and regulations of the state. It is obvious therefore that application security cannot be separated from the overall system security, but rather it has to be viewed within the total security perspective.

Security levels and General Principles An integrated information system must have an integrated security solution covering the general security principles which must be taken into account. The basic information systems security levels are: � Application Level Security: It refers to the available functionality of the software

subsystems and applications which the end users are able to execute depending on their predefined roles.

� Database Security: It refers to the application of a predefined information security policy regarding the accessibility and processing of the database stored information.

� Network Security: It refers to the protection of the information during their transmission through wire, wireless and satellite networks.

� Physical Security and Computer Security: It refers to the protection of the computing equipment from dangers related either to human intervention (e.g. unauthorised access, theft, malicious actions etc.) or to natural causes (e.g. fire, flood, earthquake etc.).

The general principles applying to all the above levels and thus must be part of the security requirements for a system, are: � Confidentiality: In all information systems there is a significant amount of information that

is classified as confidential and must be accessible only by users possessing the proper authorisations. The certification of user authority must be based on a role system. Furthermore all appropriate measures must be taken so as to avoid any data theft attacks.

� Integrity: The data must not be tampered with. To ensure data integrity a significant factor is the use of database management systems offering the appropriate mechanisms for data integrity and consistency as well as preventing attacks to sabotage the data.

� Availability of Information: The data must be available whenever they are required. This can be accomplished by the use of mechanisms that prevent denial-of-service attacks.

� Access Control: Every user must have the authorisation to access the system based on specific and well defined rights.

� Non-Repudiation: A user must not have the ability to deny that he participated in a transaction. This can be accomplished by the existence of a proper mechanism for tracking and recording the users’ actions (e.g. auditing, logging etc.) and the modifications of data (traceability).

Security Study In order to cover all the security issues of an information system, a Security Study must be elaborated very early in the project and its provisions must be taken into account when developing the software application. The Security Study must be elaborated taking into account the security levels and the general principles presented earlier in this chapter. It is mandatory for the identification of potential weaknesses and the design and implementation of specific security measures for the information system. A Security Study must cover at least the following issues: � Risk management framework and security policy � Conformance with the relevant laws and regulations � Technical security measures � Disaster Recovery Plan (if applicable and/or desired) � Authorisation Plan Risk management framework and security policyRisk management is one of the most important parts of the security study incorporating the study of risks for the information system and the elaboration of the organisation’s security policy which must be followed by the entire personnel, thus contributing to the efficient management of the identified risks. The risk management framework includes the identification, documentation, classification and scaling of the risks associated with the transmission, management and storage of information as well as the elaboration of risk management strategy for the identified risks using the appropriate countermeasures. The elaboration of a consistent and uniform security policy for the beneficiary of the information system includes all the principles, rules and practices that must be followed by the organisation’s personnel so as to achieve the best results regarding the protection of transmitted and stored information and the security of the system. Conformance with the relevant laws and regulationsThe information systems processing sensitive personal data must operate in respect of the prevailing legal and regulatory framework. Furthermore, due to the general sensitivity of the Syrian state and the scientific community in security matters, it is important that the appropriate de facto or de jure standards related to information systems security be used (e.g. ISO 17799). Technical security measuresThe security study of an information system provides the description of the technical, organisational and administrative measures that must be taken for the satisfactory protection of the information system. The contractor implementing the system must define in detail and implement the technical security measures. Furthermore it is desirable that he defines the organisational and administrative measures that will enable the implementation of the technical measures. It is imperative that the contractor must work closely with the organisation in order to effectively implement both the technical and the organisational/administrative measures with the minimum disruption in the organisation’s work environment. The technical security measures relate to all four security levels presented above and include indicatively the following: � Access through multiple control levels � Access to both applications and physical locations using smart card technology

� Secure storage and encryption of access codes (passwords) � Creation of a list of authorised physical persons which have access rights and

establishment of a process for identity checking � Single sign-on with a unique access code for all the subsystems of the information system � Central system for user management and control � Implementation of security measures at all levels of the system (operating systems,

database management systems, application software) � System for data integrity checking � The application software must provide support for Public Key Infrastructure (PKI) and

digital signatures (either directly or as a future extension depending on the availability of the required infrastructure)

� Encryption of data for transmission over insecure networks (e.g. Internet) � Keeping of log files � Keeping of audit trail information related to user actions � Protection from network intrusions � Protection from viruses, worms trojans etc. Disaster Recovery PlanThe Disaster Recovery Plan includes all the required procedures to recover the system and the data in the case of natural or other kind of disaster. It refers to the continuation of system operation and not of the organisation as a whole, after a disaster caused by either natural causes (e.g. earthquake, fire etc.) or human intervention (e.g. theft, sabotage etc.) which are presumed to have a major impact on system operation. This plan must provide for the procedures for transferring the computer centre to a different location until all damages are remedied. Furthermore, the plan must cater for the segregation of users to groups, which, depending on each ones role, will restore the system into operation as far as equipment, system software, application software and data are concerned. Additionally, the plan must cater for the transition to manual procedures for the period until the system is sufficiently operational and for the potential changes in business operations due to the fact that the system may not be fully operational. Finally, the plan must provide detailed description of the procedures for restore and recovery of data from backup copies. Authorisation PlanThe creation of the Authorisation Plan requires the definition of a sufficient number of roles which will be used to provide user access to system functionalities. For every role there must be well defined access rights for the creation, presentation, modification, deletion and archiving of master data, transactional data, reports, executables and other objects. This plan will form the basis for the authorised access of users to the system since each user can be assigned to one or more roles. The above requirements are presented below in a tabular format together with their classification as mandatory or desirable.


SECURITY LEVELS

1Security issues must be clearly defined at the following levels:

� Application level � Database level

Y


� Network level� Physical level GENERAL SECURITY PRINCIPLES

2 The system must cover the following general security principles:

2a Authorisation: Every user must be given access to the system based on specific predefined rights Y

2b Availability of data: Data must be available whenever required Y

2c Non-repudiation: A user must not be capable of denying that he participated in a specific transaction. This can be achieved by the existence of a suitable auditing and logging mechanism and traceability mechanism.

Y

2d

Integrity: Data must not be tampered with. To ensure integrity a significant factor is the use of database management systems offering the appropriate mechanisms for data integrity and consistency as well as preventing attacks to sabotage the data.

Y

2e Confidentiality: The certification of user authority must be based on a role system. Furthermore all appropriate measures must be taken so as to avoid any data theft attacks.

Y

SECURITY STUDY

3A risk management framework and security policy must be elaborated and utilised throughout the design, implementation and operation of the system Y

4The system must be conformant with the relevant laws and regulations related to security Y

5 The system must cover at least the following technical security measures:

5a Access through multiple control levels Y

5b Access to both applications and physical locations using smart card technology N

5c Secure storage and encryption of access codes (passwords) Y

5d Creation of a list of authorised physical persons which have access rights and establishment of a process for identity checking Y

5e Single sign-on with a unique access code for all the subsystems of the information system Y

5f Central system for user management and control N

5g Implementation of security measures at all levels of the system (operating systems, database management systems, application software) Y

5h System for data integrity checking Y

5i The application software must provide support for Public Key Infrastructure (PKI) and digital signatures (either directly or as a future extension depending on the availability of the required infrastructure)

N

5j Encryption of data for transmission over insecure networks (e.g. Internet) Y

5k Keeping of log files Y

5l Keeping of audit trail information related to user actions Y

5m Protection from network intrusions Y

5n Protection from viruses, worms trojans etc. YDISASTER RECOVERY PLAN

6 A full-scale Disaster Recovery Plan must be elaborated NAUTHORISATION PLAN

7 A full-scale Authorisation Plan must be elaborated Y

4.2 Performance Considerations

An integrated information system is not a single dimension system, but rather it consists of application software, system software and computing equipment. Its satisfactory total performance depends on the satisfactory performance of all its constituents. The contractor implementing an integrated information system must ensure that all the constituent parts of the system cooperate satisfactorily and perform adequately so as to maximize the performance of the complete system. In case of a contractor implementing the application software for an integrated information system, he must ensure that the application software is designed, developed, configured and deployed in such a way that the satisfactory cooperation with the other constituent parts of the system is ensured. He must therefore both design and develop the application software efficiently and test the system extensively so as to ensure the satisfactory performance of the system for the given infrastructure. Measuring performance for application software alone is not an easy task, since it is affected by multiple factors both within the application software and externally (e.g. the computing equipment, the network etc.) In the case of application software that is categorized as an On-Line Transaction Processing (OLTP) system in client-server architecture, meaning that its main functionality is to support transactions, a common approach to performance measurement can be based on a modified version of the provisions of the TPC-C benchmark designed by the Transaction Processing Council. Although this benchmark has been designed in order to measure the performance of computer systems and Relational Database Management Systems, it is still based on the repeated execution of a typical transaction. By adapting the provisions of the TPC-C benchmark, we can establish a performance measurement for an OLTP application. Using the above notions, we can define a measurement for application software to be the following: Response time - no longer than 3 seconds for a transaction of “medium complexity” at any time at any location, with the system operating at full load. A transaction of “medium complexity” is defined as one which accesses between five (5) and eight (8) entities, creates up to four (4) instances, changes/deletes up to four (4) instances and reads up to nine (9) instances. The provisions of this performance measurement can be modified to suit the needs of a specific software application. For example, the network delays can be excluded from the measurement in case the application operates over a WAN or can be part of the measurement in case the application operates only over a LAN. In the case of application software that is built using thin client technology and operating over the Internet or over a corporate Intranet, an approach to performance measurement can be based on the response times of a typical web application as defined by the universally accepted web application benchmark TPC-W. The average response times of such an application could be: � Access to static information web pages ≤ 3 sec � Access to pages issuing standard parametric requests ≤ 3 sec � Confirmation of request processing ≤ 5 sec � Access to information search pages ≤ 3 sec � Sending of search results ≤ 10 sec

� Access to application administration pages ≤ 5 sec � Conformation of application administration actions ≤ 20 sec The above response times are measured from the moment a request is a sent from a browser connected to the network serving the application until the moment the information is totally received from the browser. The maximum deviation from the above mentioned response times must be under 50% at any point in time.

4.3 User Interface The user interface is the aggregate of means by which people interact with a particular machine, device, computer program or other complex tool. The user interface provides means of: � Input, allowing the users to manipulate the system � Output, allowing the system to produce the effects of the users' manipulation. The term user interface is often used in the context of computer systems and electronic devices. The system may expose several user interfaces to serve different kinds of users. For example, a computerized library database might provide two user interfaces, one for library patrons (limited set of functions, optimized for ease of use) and the other for library personnel (wide set of functions, optimized for efficiency).

Usability The design of a user interface affects the amount of effort the user must expend to provide input for the system and to interpret the output of the system, and how much effort it takes to learn how to do this. Usability is the degree to which the design of a particular user interface takes into account the human psychology and physiology of the users, and makes the process of using the system effective, efficient and satisfying. Usability is mainly a characteristic of the user interface, but is also associated with the functionalities of the software application. It describes how well a software application can be used for its intended purpose by its users with efficiency, effectiveness, and satisfaction, also taking into account the requirements from its context of use.

Types Currently the following types of user interface are the most common: � Graphical user interfaces (GUI) accept input via devices such as computer keyboard and

mouse and provide articulated graphical output on the computer monitor. There are at least two different principles widely used in GUI design: object-oriented interfaces (OOUI) and application oriented interfaces.

� Web-based user interfaces accept input and provide output by generating web pages which are transported via the Internet and viewed by the user using a web browser program.

Other types of user interfaces include: � Command-line interfaces, where the user provides the input by typing a command string

with the computer keyboard and the system provides output by printing text on the computer monitor.

� Batch interfaces are non-interactive user interfaces, where the user specifies all the details of the batch job in advance to batch processing, and receives the output when all

the processing is done. The computer does not prompt for further input after the processing has started.

� Touch interfaces are graphical user interfaces using a touchscreen display as a combined input and output device.

� Attentive user interfaces manage the user attention deciding when to interrupt the user, the kind of warnings, and the level of detail of the messages presented to the user.

� Crossing-based interfaces are graphical user interfaces in which the primary task consists in crossing boundaries instead of pointing.

� Gesture interfaces are graphical user interfaces which accept input in a form of hand gestures, or mouse gestures sketched with a computer mouse or a stylus.

� Noncommand user interfaces, which observe the user to infer his / her needs and intentions, without requiring that he / she formulate explicit commands.

� Reflexive user interfaces where the users control and redefine the entire system via the user interface alone, for instance to change its command verbs.

� Tangible user interfaces, which place a greater emphasis on touch and physical environment or its element.

� Telephone user interfaces, which accept input and provide output by generating telephone voice which is transported via the telephone network and heard by the user using a telephone. The user input is made by pressing telephone keys.

� Text user interfaces are user interfaces which output text, but accept other form of input in addition to or in place of typed command strings.

� Zero-Input interfaces grab inputs from a set of sensors instead of querying the user with input dialogs.

� Zooming user interfaces are graphical user interfaces in which information objects are represented at different levels of scale and detail, and where the user can change the scale of the viewed area in order to show more detail.

Modalities and modes A modality is a path of communication employed by the user interface to carry input and output. Examples of modalities: � Input — computer keyboard allows the user to enter typed text, digitizing tablet allows the

user to create free-form drawing � Output — computer monitor allows the system to display text and graphics (vision

modality), loudspeaker allows the system to produce sound (auditory modality) The user interface may employ several redundant input modalities and output modalities, allowing the user to choose which ones to use for interaction. A mode is a distinct method of operation within a computer program, in which the same input can produce different perceived results depending of the state of the computer program. Heavy use of modes often reduces the usability of a user interface, as the user must expend effort to remember current mode states, and switch between mode states as necessary.

Application requirements related to user interface and user friendliness The user friendliness of the application software is a very important factor for the acceptance and successful operation of an IT system. Especially in the case where a software application does not substitute older application software but on the contrary it introduces IT support in an organization, the significance and

importance of user friendliness is augmented. In this case it has to be assumed that the users will not be familiar with the use of IT systems. An indicative list of requirements related to user friendliness of application software is: � The application software must possess a Graphical User Interface with common look and

feel in all its subsystems and modules. The use of a windows based graphical work environment is mandatory so as to speed up the familiarisation of users with the IT system.

� The application must be built around a menu system which includes all the processes a user has access to depending on his rights. These menu options can be grouped in different levels so as to facilitate the users in locating and accessing them.

� The application must support the use of function keys and / or other keys so as to facilitate the navigation through shortcuts.

� The work environment offered by the application must be in the Arabic language except in special occasions (highly specialized systems) when it might be in the English language. Indicatively the main menu, the submenus, the selection fields (drop-down lists, radio buttons, check boxes etc.) and the entry fields, the messages of all kinds and the help facilities must be in Arabic. Whenever these are not offered by the application software (in case of an off-the-shelf system) the contractor supplying the system must be responsible for the software’s localization.

� The system must facilitate the user in entering data with all possible means, so as to ensure the correct and quick entry of data and to reduce significantly the possibility of errors. Indicatively these facilities must be provided by: � Proposing default values for specific fields where applicable, so as to reduce data

entry time. � Checking the values entered by the user and providing warnings for invalid entry. � Providing lookup tables from codified lists so that the user can simply select the proper

value. � Issuing the appropriate help messages, warnings and error messages which will

facilitate the user to enter the proper data and in the proper format. This provides also direct and effective support to user questions.

� The system must provide automatic checking of data validity and issue the corresponding error messages during data entry so as to ensure that data are entered in the appropriate format, sequence, range of values etc.

� The application must offer the possibility to launch multiple active sessions from the same terminal.

� The application must provide the users with online help services and instructions per process, menu item, form etc.

The above requirements are presented below in a tabular format together with their classification as mandatory or desirable.


1. The system must provide a graphical window-based operating environment Y

2. The look & feel of the application software must be common between its subsystems Y

3. The menu system must include all options a user has access to depending on his rights. These options should be grouped in different levels so as to facilitate the users in locating and accessing them

Y

4. The application software should support an easy adaptation of the graphical user interface based on the rights and needs of the users (accessible menus, N


toolbars, access levels etc.)

5. The system must support the use of function keys and / or other keys so as to facilitate the navigation through shortcuts N

6.

The system must support fully the Arabic language. All menus, field labels, window labels, form titles and messages must be in the Arabic language. Whenever these are not offered by the application software (in case of an off-the-shelf system) the contractor supplying the system must be responsible for the software’s localization

Y

7.

The system must facilitate the user in entering data with all possible means, so as to ensure the correct and quick entry of data and to reduce significantly the possibility of errors. Indicatively these facilities must be provided by:

� Proposing default values for specific fields where applicable, so as to reduce data entry time.

� Checking the values entered by the user and providing warnings for invalid entry.

� Providing lookup tables from codified lists so that the user can simply select the proper value.

� Issuing the appropriate help messages, warnings and error messages which will facilitate the user to enter the proper data and in the proper format. This provides also direct and effective support to user questions.

Y

8. The system must provide automatic checking of data validity and issue the corresponding error messages during data entry so as to ensure that data are entered in the appropriate format, sequence, range of values etc.

Y

9. The application must offer the possibility to launch multiple active sessions from the same terminal Y

10. The online help provided by the application must be exhaustive, must be offered in all levels of the application (process, menu item, form, entry field etc.) and must be easily accessible by the users

Y

4.4 Documentation and Help Documentation is an important part of software engineering that is often overlooked. Types of documentation include: � Architecture/Design - Overview of software. Includes relations to an environment and

construction principles to be used in design of software components. � Technical - Documentation of code, algorithms, interfaces, and APIs. � End User - Manuals for the end-user, system administrators and support staff. Design documents tend to take a broad view. Rather than describe how things are used, this type of documentation focuses more on the why. For example, in a design document, a programmer would explain the rationale behind organizing a data structure in a particular way, or would list the member functions of a particular object and how to add new ones to the code. Architecture documentation is a special type of design documents. In a way, architecture documents are third derivative from the code (design documents being second derivative, and code documents being first). Very little in the architecture documents is specific to the code itself. These documents lay out the general requirements that would motivate the existence of specific software modules. A good architecture document is short on details but thick on explanation.

Technical Documentation is what most people mean when using the term “software documentation”. It is very well known that in application software, code alone is insufficient, but instead, there must be specific documents along with it to describe various aspects of its intended operation. This documentation is usually embedded within the source code itself so it is readily accessible to anyone who may be traversing it. This writing can be highly technical and is mainly used to define and explain the programming interfaces, data structures and algorithms. It is important for the code documents to be thorough, but not so verbose that it becomes difficult to maintain them. There is a significant number of tools which offer specific functionality for automating the generation of the code documents — that is, they extract the comments from the source code and create reference manuals in such forms as text or HTML files. Code documents are often organized into a reference guide style, allowing a programmer to quickly look up an arbitrary software element. The advantage of using this kind of tools is that the documentation is extracted from the source code itself (for example, through comments). This means that the developer can write it while referring to the code, and can use the same tools used to create the source code, to make the documentation. This makes it much easier to keep the documentation up-to-date. The disadvantage of using this kind of tools is that only specialised people (e.g. programmers) can edit this kind of documentation. Some would characterize this as a pro rather than a con (Donald Knuth has insisted on the fact that Software documentation can be a very difficult afterthought process and has been advocating “Literate programming” where documentation is written in the same time as the source code and extracted by automatic means. User documentation is usually not directly related to the source code, and instead simply describes how it is used. Typically, the user documentation describes each feature of the program, and the various steps required to invoke it. A good user document can also go so far as to provide thorough troubleshooting assistance. User documents need not be organized in any particular way. Consistency and simplicity are also very valuable. User documentation is considered to constitute a contract specifying what the software will do and should be free from undocumented features. There are three broad ways in which user documentation can be organized. A tutorial approach is considered the most useful for a new user, in which the user is guided through each step of accomplishing particular tasks. A thematic approach, where chapters or sections concentrate on one particular area of interest, is of more general use to an intermediate user. The final type of organizing principle is one in which commands or tasks are simply listed alphabetically, often via cross-referenced indices. This latter approach is of the greatest use to advanced users who know exactly what sort of information they are looking for. The best approach to software documentation is a combination of the three approaches, in the sense that the documentation should be provided in all three different organisation approaches so as to fit the needs of the different levels of users. In most software applications the user documentation is used as-is or with minor modifications mainly in structure for the on-line help of the system. The on-line help system is usually providing specific help on the usage of software application components such as commands, forms or menu items. A good on-line help system should also provide for indexed search of its contents and for context help that will enable the user to get assistance directly on the specific feature of the application software he is using instead of trying to locate it through the index.

4.5 Data Migration Requirements When a new software application is being implemented either by custom development or by customising off-the-shelf software in order to replace an existing system which no longer covers the needs of the business functions or is outdated in terms of technology, an important and critical task is the migration of data from the old system to the new one. Data to be migrated include electronic records storing information in the present system such as database files, MS Excel files, MS Access files, MS Project files etc. The technical results anticipated from data migration include: � Cleansing of all inactive data from the master files that overload the system without any

potential usefulness. � All the data required for the successful operation of the new system must be migrated to

the new system in time so that the new system can enter full operation on the scheduled time.

The functional results anticipated from data migration are: � The faster and easier management of processed data by the users. � The increase in user productivity. It has to be noted that in many cases the quality of the existing data may not be acceptable due to deficiencies (e.g. fields that are never filled in by the users), multiple entries of the same data which result in duplications, existence of different codes describing the same data element etc. Additionally there may be inconsistencies in other data such as dates, addresses, and measurement units which need to be catered for. Data migration is a complex task that must be very carefully planned, designed and executed in order to get the best results. The actual process of data migration can be split in three phases: � Data Migration Plan � Preparation of migration � Execution of migration Data Migration PlanThe Data Migration Plan must be elaborated in the Analysis and Design stage of the project and must include: � The identification of the data to be migrated and the location of the sources where these

data will be collected from (e.g. application files, database tables etc.) � The classification of data as per their category (master data, transactional data) as well as

per the point in time before the live operation of the system when these data must be migrated (1 month before, 1 day before etc.)

� The definition and specification of all programs, scripts etc. that will be required to perform the migration.

� The methodology for testing the migration process before actually executing it. � The methodology for evaluating the quality and correctness of the migration process and

its results. � The process for deleting, migrating of a new data sample and rechecking in the case of

errors in the migration of a data set. � The design of the mechanism for data cleansing and improvement (e.g. elimination of

duplications).

� The definition and specification of special programs which will perform the mappings of existing fields to the ones of the new system.

Preparation of migrationBefore the actual execution of the data migration, some preparatory activities need to take place. These activities include: � The implementation of all the programs, scripts etc. that will be required to perform the

migration. � The execution of test migrations for the entirety of the data to be migrated. � The control of quality, integrity and completeness of the data and of the migration

programs. � The development of special migration programs which will perform the mappings of

existing fields to the ones of the new system. Execution of migrationDuring this stage the actual data migration activities are carried out in accordance with the Data Migration Plan, resulting in the new system be populated with the data required for it to assume operation. This stage is usually carried out during the Implementation Phase of the system finishing off just before the system enters into production so as to have the latest data available. There are cases however when the new system enters into production without the entire data migration activities been carried out. Quality criteria for successful data migrationIn order for an evaluation committee to evaluate the quality of the process, several quality criteria can be set out covering the full scale of the data migration activity. An indicative list of such quality criteria is presented below: � Migration processes, procedures, programs etc are clearly understood and have been

agreed between users and technical staff � Expectations have been set between users and technical staff on when migration of data

should be performed i.e. one-off or on-going process � All data in the existing system(s) have been addressed and cover the needs described in

the migration plan � There is no duplication of rows/records � All columns are clear and match the columns in the new system in terms of names or

sequence � All new columns not present in the old system contain ZERO, NULL, SPACE or any other

default data previously agreed between the users and technical staff � All data has been prepared in the format required by the new system or temporary

database � All fields/attributes maps have a one to one correlation between old systems and new

system (Cross Reference Map) � Conversion of data types from old to new are handled and verified to ensure correct data

transfer and consistency � Random data in existing systems have been checked against other systems such as

manual records for correctness and completeness � Data model relationships are maintained or programs have been made available to handle

relationships or integrity of data

� Indexes, primary and secondary keys are clearly defined to support the needs of the migration

� All programs, processes and procedures have been identified for the preparation, cleaning, uploading and for populating the tables

� All security relating to data in old and new system has been maintained or enhanced � The migration program provides reporting/auditing information and differentiates between

warnings and major error relating to data inconsistencies � Migration of data provides a fast and efficient process for populating or migrating data to

the new system and not a hindrance or major list of problems to users and technical staff The above criteria should be adjusted to the specific needs of the system under implementation (e.g. there may be no need to define data conversion rules when migrating from an older to a newer version of the same database make). They can also serve as requirements to be set forth during the tendering procedure for new system procurement.

4.6 Data Entry Requirements In many cases when a new information system is implemented it is required that a significant amount of information be entered into the system by means of typing the data that exist in paper format. Apart from this situation which can be categorised as initial data entry in order for the system to be put into production, there are cases when there is also the need for continuous data entry services for a long period of time when the system is already in operation. Initial Data EntryInitial Data Entry is very similar to the process of data migration described earlier. It comprises of three stages, namely: � Data Entry Plan � Preparation of data entry � Execution of data entry The process for the execution of each stage is very similar to the corresponding stage of data migration, apart from the steps involving the automated execution of tasks by means of computer programs. Continuous Data EntryContinuous Data Entry is an ongoing activity of a project and as such it must be very carefully planned, designed, executed and controlled. Apart from the technical dimension of the continuous data entry process which is similar to the one of initial data entry, there are two other very important aspects that must be carefully designed: � The organisation of data entry � The quality control of the data entry activity results As far as the organisation is concerned, the contractor must elaborate a concise organisational structure that will both enable him to perform his tasks effectively and enable the beneficiary to communicate with the contractor and control the process efficiently.

To accomplish the above the contractor must define the roles, responsibilities and lines of communication for the organisational structure implementing the process. To this extent, the definition must cater for at least: � The management team of the data entry process (e.g. a task manager and one team

manager for each team of data entry personnel) � The number and qualifications of data entry team members � The communication process and responsibilities, taking onto account the organisational

structure of the beneficiary for the monitoring of the specific task. � The organisation and method of work for the execution of the data entry process (e.g.

receiving of document batches, assigning and dispatching of batches to data entry teams, entry of document data into the system, quality control of data entry per document batch, filing and archiving of document batches, management of unreadable or ruined documents etc.)

In relation to the quality control of the data entry activity results, it has to be noted that performing exhaustive checking on the correctness and completeness of data entered is neither efficient nor possible. For this reason, the quality control process must employ sampling techniques so as to ensure, within a statistically acceptable range, the quality of the process results. An approach to this quality control is: � At the end of a reporting period, the committee responsible for monitoring the data entry

process performs summary checks on the number of document batches and individual documents delivered to the contractor for entering the data into the system against the size and volume of actual data that have been entered. These checks can be easily performed by using standard tools provided by the database management system used for storing the data.

� If there is a deviation of the data entered versus the documents delivered then the committee must define the cause of the deviation. If the deviation is the contractor’s responsibility and exceeds a predefined percentage of the documents delivered (e.g. 3%) then the contractor is instructed to remedy the defects and the committee applies to the contractor any potential penalties that have been set out for defective delivery.

� If the deviation is lower than the predefined percentage of documents delivered, then the committee proceeds with the selection and exhaustive checking of a sample of the documents delivered. The sample selected must be of adequate size to allow for the extraction of statistically sound results. The sample is then checked against the corresponding data entered into the system by means of specially designed data presentation screens.

� Finally the committee calculates the percentage of erroneously entered characters, which is considered to apply to the whole quantity of documents processed during the reporting period. If this percentage exceeds a predefined value (e.g. 1%) then the total quantity of documents is returned to the contractor for re-processing. Otherwise the task is considered complete for the reporting period under consideration.

The above approach of quality control can be amended and adapted to fit the specific needs and special conditions of each project.

4.7 Quality Requirements

Application Software Quality is defined as conformance to specified requirements and is of paramount importance for the success of an ICT project involving a software system. Several quality factors are relevant to application software and can be evaluated in order to provide a measurement of the software quality. Apart from the acceptance tests of the software system which provide a quantitative evaluation of its quality (when a software system passes its acceptance testing scenarios then it fulfils the functional requirements, provided of course that the acceptance test scenarios are concise with the requirements), there are also non-functional criteria that characterize the quality of the application software. Some of them include: � Understandability: if the purpose of the product is clear. � Completeness: all of its parts are present and each of its parts is fully developed. � Conciseness: no excessive information is present. � Portability: it can be operated easily and well on multiple computer configurations. � Consistency: it contains uniform notation, symbology and terminology within itself. � Maintainability: it facilitates updating to satisfy new requirements. � Testability: it facilitates the establishment of acceptance criteria and supports evaluation

of its performance. � Usability: it is convenient and practicable to use. � Reliability: it can be expected to perform its intended functions satisfactorily. � Structuredness: it possesses a definite pattern of organization in its constituent parts. � Efficiency: it fulfils its purpose without waste of resources. � Security: it is able to protect data against unauthorized access and to withstand malicious

interference with its operations. The above software quality criteria cannot be measured easily because of their vague description. A scheme which could be used for evaluating the above is given below as an example. For every characteristic, there are a set of questions which are relevant to that characteristic. Some type of scoring formula could be developed based on the answers to these questions, from which a measure of the characteristic may be obtained. It has to be noted however that the exact questions providing the metric for each characteristic are very much dependent, among others, on the development approach and architecture chosen for a specific software system. � Understandability: Are variable names descriptive of the physical or functional property

represented? Do uniquely recognisable functions contain adequate comments so that their purpose is clear? Are deviations from forward logical flow adequately commented? Are all elements of an array functionally related?

� Completeness: Does the program contain all referenced subprograms not available in the usual systems library? Are all parameters required by the program available? Are all inputs required by the program available?

� Conciseness: Is all code reachable? Is any code redundant? How many statements within loops could be placed outside the loop, thus reducing computation time? Are branch decisions too complex?

� Portability: Is the program developed in an environment-independent development framework? Does the program depend upon system or library routines unique to a particular installation? Have machine-dependent statements been flagged and

commented? Has dependency on internal bit representation of alphanumeric or special characters been avoided?

� Consistency: Is one variable name used to represent difficult physical entities in the program? Does the program contain only one representation for physical or mathematical constants? Are functionally similar arithmetic expressions similarly constructed? Is a consistent scheme for indentation used?

� Maintainability: Has some computing capacity been reserved for future expansion? Is the design cohesive, i.e., each module has recognisable functionality? Does the software allow for a change in data structures? Is a change likely to require restructuring the main program, or just a module?

� Testability: Are complex structures employed in the code? Does the detailed design contain clear pseudo-code? Is the pseudo-code at a higher level of abstraction than the code? If tasking is used in concurrent designs, are schemes available for providing adequate test cases?

� Usability: Is a GUI used? Is there adequate on-line help? Is a user manual provided? Are meaningful error messages provided?

� Reliability: Are loop indexes range tested? Is input data checked for range errors? Is divide-by-zero avoided? Is exception handling provided?

� Structuredeness: Is a block-structured programming language used? Are modules limited in size? Have the rules for transfer of control between modules been established and followed?

� Efficiency: Have functions been optimized for speed? Have repeatedly used blocks of code been formed into sub-routines?

� Security: Does the software protect itself and its data against unauthorized access and use? Does it allow its operator to enforce security policies? Are appropriate security mechanisms in place? Are those security mechanisms implemented correctly? Can the software withstand attacks that must be expected in its intended environment? Is the software free of errors that would make it possible to circumvent its security mechanisms? Does the architecture limit the impact of yet unknown errors?

Apart from the above system for measuring functional and non-functional characteristics, the quality of application software has also been the objective of an ISO international standard set forth to provide the framework for software evaluation. This standard is ISO 9126 and its enhancement ISO 25000:2005, which follows the same general concepts. The standard is divided into four parts which addresses, respectively, the following subjects: quality model; external metrics; internal metrics; and quality in use metrics. The quality model established in the first part of the standard, ISO 9126-1, classifies software quality in a structured set of characteristics and sub-characteristics as follows: � Functionality - A set of attributes that bear on the existence of a set of functions and their

specified properties. The functions are those that satisfy stated or implied needs. � Suitability � Accuracy � Interoperability � Compliance � Security

� Reliability - A set of attributes that bear on the capability of software to maintain its level of performance under stated conditions for a stated period of time. � Maturity � Recoverability � Fault Tolerance

� Usability - A set of attributes that bear on the effort needed for use, and on the individual

assessment of such use, by a stated or implied set of users. � Learnability � Understandability � Operability

� Efficiency - A set of attributes that bear on the relationship between the level of

performance of the software and the amount of resources used, under stated conditions. � Time Behaviour � Resource Behaviour

� Maintainability - A set of attributes that bear on the effort needed to make specified

modifications. � Stability � Analysability � Changeability � Testability

� Portability - A set of attributes that bear on the ability of software to be transferred from

one environment to another. � Installability � Replaceability � Adaptability

The sub-characteristic Conformance is not listed above and applies to all characteristics. Examples are conformance to legislation concerning Usability or Reliability. Each quality sub-characteristic (as adaptability) is further divided into attributes. An attribute is an entity which can be verified or measured in the software product. Attributes are not defined in the standard, as they vary between different software products. The standard provides a framework for organizations to define a quality model for a software product. On doing so, however, it leaves up to each organization the task of specifying precisely its own model. This may be done, for example, by specifying target values for quality metrics which evaluates the degree of presence of quality attributes. There are a number of different tools and techniques that can be used when making qualitative analysis of software applications, such as Ishikawa diagrams, Root-cause analysis, Pareto analysis, Six-sigma analysis, Monte Carlo simulation etc. The details on these tools and techniques are outside the scope of the present document. It has to be noted that the above pertain mostly (but not only) to custom developed application software. Off-the-shelf software and especially the business-centric systems presented in the following annex of the present document are produced by companies that usually employ Total Quality Management principles. The relevant software systems pass through exhaustive

testing both internally in the producing company and externally by independent evaluators before hitting the market. Any defects or malfunctions identified after the release of the product in the market is usually remedied by issuing new releases of the software application.

5 Annex 5: Application Software Specifications This annex lists the basic specifications of the most common software subsystems in public administrations. It aims to act as a guideline for authorities preparing tender documents for the procurement of such subsystems. The specifications presented here are the most common and basic ones, so they may need to be complemented with additional specifications pertaining to a specific system. Furthermore, these specifications are valid at the time the current document is produced. In order to be kept current they must be updated on a regular basis in order to reflect the technological developments. The tables presented below include a column specifying whether the requirement is mandatory (i.e. every system should conform to it) or desirable (i.e. it is nice to have but not mandatory). It must be noted that the specifications presented hereunder do not include non-functional requirements (e.g. security, user interface etc.) as these are covered in the next chapter of the present document.

5.1 General requirements of ERP systems


1.

The system must be based on either a single comprehensive international software package or several more specialized single vendor packages, integrated as required to operate as a single system so far as the users are concerned.

Y

2. The selected package(s) will have sufficient flexibility in operating parameters that the necessary adaptations could be effected without the need for bespoke (“one-off”) software development.

N

3. The software solution shall be developed using a recognised methodology and system design tools, e.g. UML, and employing an industry-standard software technology platform.

Y

4. As a general guideline each processing system function should interact with any other system function in a seamlessly integrated fashion with minimal user intervention.

Y

5. Data will be entered once and once only and validated and verified at the source point in the business process. Y

6. The application software should be built on WEB/Intranet technology. N

7. The application interface must employ consistent screen design for ease of learning, graphical icons, data entry assistance and validation, multi-level help screens, etc.

Y

8. The application will have the capability to integrate information from a variety of sources such as other corporate applications. Y

9.

All user interface texts including error messages shall be in Arabic language (ISO-8859-6). All user on-line help-guide texts shall be in Arabic language (ISO-8859-6). All upgrades and patches that may be provided during or after the end of the project have to respect and comply with these requirements.

Y

10. The application(s) must support Syrian Pounds as well as the major international currencies. It is advised that all amounts are entered, displayed, stored and printed with 2 decimal points.

Y

11. Where applicable all reports must be produced on a time period basis and per organisational unit. N

12. Where applicable, reports must be available either as aggregated summary reports or as detailed with aggregated summaries per level. N


13.

The system must be completely flexible and allow the generation of reports based on any combination of the data stored. The system therefore shall enable the production of ad hoc reports without the need for modification to the system software.

Y

14. A report generation tool with formatting and statistical capabilities such as averaging, multi-level sub-totalling, percent change comparisons, and standard mathematical operations is required.

Y

15. There must be a utility implemented for query creation. The utility must allow users to choose which data is to be selected from the database and which criteria, for every field, must be applied in the selection process.

Y

16. Every ready-made report or result of a user made query, shall have the option of being previewed on the screen and/or printed on paper according to the users' desire and security constraints.

Y

17. The application should allow for users working in groups. N

18.

The system will be flexible in search capabilities, ranging from simple facilities, to more complex in-depth searches. Long duration searches should indicate their continued progress or may be deferred to speed up system response and reduce network traffic.

Y

19. The system must support the ability to exchange information (e.g. using the XML standard) with other organisations. Data exporting/importing must also support data exchange in XML encoding.

Y

20.

The system has to be designed to have backup and restore functions available. The system must incorporate comprehensive procedures for regular (daily, weekly and monthly) back-up and restoration of all system files and data to guarantee recovery in the event of hardware failure. Back-up procedures must be implemented that do not affect the operational availability of the system.

Y

21.

The documentation of the system will include at least: � A general system overview � Business relationship description between departments � Function by function process description � Function by function data flow diagrams � A description of all user interfaces � A general description of data structures � Data dictionary � Modelling Language definitions � A description of standard reports

Y

22.

The system should provide single sign-on. Users must be authenticated to the system by username and password and then they must have access to all system and network resources without entering username and password again.

Y

5.2 Financial systems

Budgeting


1.

The system must support the following: � Multiple budgets � Budget creation and revision processing � Budget entry at detail level � Budget entry at summary levels � Budget freeze � Budget transfers

Y


� Budget reporting and tracking

2.

Budget data should be entered on-line with on-line validation and real-time update. Budget maintenance can be performed through: � Budget Journals to provide audit trail � Direct amount maintenance � User defined Formulas � Allocation (e.g. from a Directorate to sub-Directorates) � Spreadsheet / external system interface with suitable validation

facilities

Y

3.

The system must provide the option to create budgets quickly based on user-defined rules which include: � percent increase / decrease from current or previous year’s actuals� percent increase / decrease from current or previous year’s budget

with option choose which budget or version to use � spread evenly across user specified range of periods � statistical data � copied from other budgets � repeat amount across user specified range of periods

Y

4. The system should support both decentralized budgeting and centralized budgeting. N

5.

The system must provide a spreadsheet-based (e.g. MS-Excel) budgeting module, so that users can capitalize on the familiar spreadsheet environment and yet be able to have the full capability of the above mentioned budget rules as well as the ease of uploading the budget data directly to the system.

N

6. In a decentralized budgeting environment, there are adequate controls to ensure that a budget organisation or department has access to their own accounts only.

N

7. The system should provide a facility to process Budget Transfers from one entity, cost centre, account, sub-account, etc. to another with online approval from the responsible organisation and the heads of each organisational unit.

N

8. The system should aggregate sub-allocations received at each level. Y

9. The system must calculate balances remaining from allocation to sub-allocation. Y

10. The system should prevent excess sub-allocations over the allocated amounts. Y

11. The system should provide a full commitment model where the system can keep track of the total budgeted amount, the amount already reserved for purchases, and the amount already expended as actual payments.

Y

12. The system should provide an on-line view of funds movement of the budgeted amount, committed amount, actual payment amount and the funds available.

Y

13.

The system must provide facility to set budgetary ceilings for specific budgetary units, with the option of allowing for an ‘advisory’ mode whereby users will be issued with a warning when expenditures exceed the ceiling or an ‘absolute’ mode whereby users would not be allowed to proceed if the funds available are not sufficient to cover the expenditure.

Y

14. The system should support the design and execution of what-if scenarios on budgets. N

15. The system should support the revision / amendment of an existing budget. Y

16. The system should provide concise reports related to budgetary data. Y

17. The system should be able to prepare budget books by major organisational unit for submission to higher authorities and be able to store up to 10 years worth of budgets (Planned/Actuals)

Y

General Ledger


1.

The system should provide a convenient way of moving balances from one account to another, or merge balances from multiple accounts into a single account, while maintaining financial integrity between General Ledger and its sub-ledgers.

Y

2. The System should be easy to operate by end users and should provide an intuitive graphical interface. The user interface should be consistent across all modules.

Y

3. The system must enable unique data entry. Y

4. The System should provide the feature to export data to spreadsheets or text files for incorporation into desktop reports or for further analysis. Y

5. The chart of accounts structure should support up to 30 segments and 25 characters per segment with the flexible structure, defined at implementation. Y

6. The system must support the search of an account by part of its code or part of its name. Y

7.

The system should provide easy to use facilities to maintain multiple organizations and hierarchies e.g. business units, cost centre hierarchies, account rollups, summary accounts etc. There should be also an option to view and edit the hierarchies and structures graphically e.g. organisation chart or tree-like style. Multiple or alternate hierarchies could be set up to view summary information in different ways. The organisation hierarchies should be easy to maintain in the event of a re-organisation and do not require any programming assistance.

N

8. Consolidation of the information from these entries is possible at both a transaction or at a balance level regardless of the differences in the structures mentioned above.

Y

9. Summarization of different entities where these features are the same shall be possible without the need to perform consolidation. Y

10.

The system must allow the accounting structure to be shared across all organisation units or to set up specific account code structures for each organisation unit. In the latter case, suitable facilities must be available to map the different structures for consolidation without the need for programming assistance.

Y

11. The structure must be consistent across budget execution and actual reporting. Y

12. The system should have the architecture necessary to support both cash and accrual basis of accounting concurrently. Y

13. Business transaction (e.g. payment) only needs to be entered once. The system shall generate accounting entries to both cash and accrual books. Y

14.

The system must support the entry of general ledger entries by: � Key-in of data � Use of templates � Copying and updating of any already submitted entry

Y

15.

Facilities for users to define summarization or “roll-up” levels of financial information for any segment (dimension) of the accounting structure without programming assistance should also be included. Users should be able to combine different “roll-up” levels for different segments (dimensions) to produce multiple business views of information.

Y

16. The system must automatically summarize all detail transactions on-line based on the summarization definitions so that up-date-date summary balances are always available.

Y

17. On-line inquiries must be available for summary balances and drill down to detail balance information. Y


18.

The system should provide facilities to define the accounting calendar and control which periods are open for posting: � There should be no limit to the number of periods open at one time for the

posting of journals. � Future period journal entry creation with suitable controls is an option. � Prior period posting with suitable controls is an option. � The system should provide overlapping period dates and shall support

audit periods.

Y

19.

The system must provide support for multiple currencies and exchange rate types including: � Daily rate � Spot rate � Multiple user defined rates

Y

20.

The system must provide support for the entry of daily conversion rates for any two currencies, regardless of the functional currency. Exchange rates should be entered online or via open interface file. The system must provide manually entered and system calculated average exchange rates.

Y

21. Journals should support amounts up to 9,999,999,999,999,999.99. Y

22. The system should provide functionality for: � On-line entry of journals � Batch import

Y

23. Both automatic and batch posting of journals must be supported with automatic validation. The option to defer journal posting for review should be available.

Y

24. Each journal must have the ability for multiple journal lines. Each journal line should provide for long text description. In addition, it should provide at least five other user-definable data fields for additional information.

Y

25. The system should have the option to automatically route manual journal entries to the appropriate user for approval before posting. The approval hierarchy and authorization limits for each user are user-defined.

Y

26.

Journals must support the following balance types: � Actuals - base currency � Actuals - foreign currency � Budget amounts � Statistical amounts

Y

27. Automatic currency conversion should be provided when foreign currency journal entries are created. Y

28. The system also must have a spreadsheet integration to enable users to create journals and journal batches within a spreadsheet (e.g. MS Excel). N

29. The system should be able to interface and exchange information with other systems. Journal import must have comprehensive validation facilities. Y

30. The system must have the ability to freeze journals that were imported from sub-ledgers. Y

31. The General Ledger must be tightly integrated to Accounts Payable, Fixed Assets and Cash Management. Y

32. The system must provide on-line on-screen and/or in printed format all books mentioned above for every level of the organisation. Y

33.

The General Ledger should maintain the following actual, budget, encumbrance, variance, and statistical balances at detail or summary levels and are available for on-line inquiry or reporting purposes: � Period-to-date � Year-to-date � Quarter-to-date � Project-to-date � Full year (budget) � Balance brought forward

Y


34. The system should support drill down from an account balance to the associated journal lines to the complete journal entry. Y

35. The system must include an easy to learn, user oriented report writer. All facilities should be available without the need for technical support or programming.

Y

36. The system must have a spreadsheet-based report writer (e.g. MS-Excel), where users can define, build and run financial reports without exiting from the desktop and having to logon to the system.

N

37. Inquiry facilities should provide drill-down to sub-ledgers e.g. Accounts Payable. Y

38.

The report writer should provide the following: � ability to report all budget, statistical, and actual detail for current and all

past periods � ability to define sophisticated multi-line formulas to derive report figures � ability to create summarized reports by division or organisation unit � ability to mask columns or rows in the report for distribution to certain

users

Y

39. Al reports produced by the system should support the graphical representation of their contents. N

Accounts Payable


1. The vendor number should be up to 30 characters length and support alphanumeric codes. Y

2. The system must have the ability to set up multiple vendor sites for each vendor to represent payment and/or purchasing sites. Y

3.

Vendor site information maintained should include but not limited to: � vendor name, address, telephone, fax details � multiple contact persons and their contact numbers � default liability account, which may be different for each site if required � payment terms � invoice amount limit for this vendor or vendor site, over which an invoice

will require special authorization � invoice currency � invoice payment currency � default account distribution � default payment method � predefined discounts � vendor bank account details � purchasing deliver to and bill to information � freight terms � goods receipt controls � price lists

Y

4. The system must have the ability to define relationships between parent companies and their franchises or subsidiaries. N

5.

The Accounts Payable must control duplicate vendor entry and merge any duplicate vendors and sites with the correct vendor and site. The system should automatically update the associated purchase orders and invoices for the vendors so they all refer to the correct vendor. There should be reports to review the vendors, sites, invoices, and purchase orders affected by the merge.

Y

6. The following invoice types shall be supported: � standard invoice � credit memo

Y


� debit memo � employee expense claims � mixed invoices supporting both positive and negative line amounts � miscellaneous invoice (do not require matching)

7. There should be automatic validation for duplicate invoice numbers on-line during invoice entry. Y

8.

The system should prompt the user if there are outstanding prepayments or advances during invoice entry and provide an option to apply the prepayment fully or partially to the invoice being entered. The system should also provide an option to apply the prepayment to the invoice at another time.

Y

9. There should be facilities to add user-defined fields (at least 5) in the invoice entry screen to prompt users for additional information. This should be achieved without programming assistance.

N

10. The system should provide a copying function of invoices, debit memos and credit memos. Y

11. There should be facilities for on-line invoice approval and/or batch approval. Y

12.

The system shall provide for account distribution sets or templates which provide for default accounting distributions. For example, it should be possible to automatically distribute an invoice amount to several sub accounts without having to manually input detail lines.

N

13. The system shall comply with the computational and tracking requirements of the Tax regulations in Syria. Y

14. The system should provide for regular payments that are made to a vendor who does not provide an invoice. Examples of recurring payments include rent and lease payments.

Y

15.

Creation of user defined “invoice holds” shall be possible. There should be facilities to: � define holds to only prevent payment of an invoice � define holds to prevent both payment and posting of an invoice � allow only authorized users to release invoice holds from invoices.

Y

16. It should be possible to stop payment of an invoice while still allowing it to update the General Ledger. Y

17. The system should allow authorized users to update invoice amounts and distributions subsequent to General Ledger posting. The necessary adjusting journal entries should be automatically generated.

Y

18.

It should be possible to place a hold on all invoices for a specific vendor site. In addition, to be able to define an invoice amount limit for a vendor site so that the system places a hold on invoices for the vendor site that exceed the amount specified.

Y

19.

It should be possible to automatically alert relevant users via electronic mail of the following exceptions: � vendors put on hold � invoices put on hold.

Y

20.

The following are required to handle prepayments: � Prepayment approvals � Associate a prepayment with a purchase order and apply the prepayment

only to invoices matched to the associated purchase order � Specify a date before which a specific prepayment or advance cannot be

applied to an invoice � Apply or not apply a prepayment or advance to any approved invoice � Apply a prepayment or advance to many invoices � Apply many prepayments or advances to an invoice � Cancel any unpaid prepayment � Notify a vendor of the prepayments applied to an invoice (prepayment

remittance letter).

Y

21. The following information should be maintained for payment processing where Y


needed: � automatic or manual payment number � description � vendor details � payment voucher number � currency details.

22. Multiple payment schedule lines shall be available for an invoice. The system should automatically determine the payment schedule based on the payment terms entered against the invoice.

Y

23. Multiple payment terms should be supported including split terms and terms where discounts are a factor. N

24. Multiple payment methods should be supported including manual cheque, computerized cheque, and electronic funds transfer. Y

25. The system should provide for both full and partial payments. Unpaid balances are retained as open items. Y

26. Foreign currency payments must be supported. The system should automatically calculate any resulting foreign exchange gain or loss. N

27.

The system should support both automatic and manual invoice payment selection. The automatic payment selection facility should provide the following: � Multiple selection criteria for automatic invoice payment selection must be

available. These shall include due date, payment priority (assigned to individual invoice or payment schedule line) and payment group (assigned to a vendor or invoice).

� Generation of preliminary and final payment register � Review and modify items selected by system � Generate cheques and remittance advices

Y

28.

It should be possible to record a stop payment on any payment, then void the payment or release the stop payment. The system should keep the stop payment status up-to-date and provide a Stop Payments Report that can be used to review all current stop payments. It should be possible to Void Payments, including checks, wires, or electronic funds transfers. The system should automatically reverse the payment and accounting records after verifying that the payment has not already cleared the bank.

Y

29.

There should be on-line inquiry for: � open and closed invoices � vendor history � payment schedules � payment history

Y

30.

The system should provide standard interface tables to import: � Payment Reconciliation Information � Purchase Order Information � Invoice Information

Y

31. Where applicable, the Accounts Payable system shall be integrated to the General Ledger and Fixed Assets. Y

32. Fixed Assets Integration - it should be possible to add assets from invoice distribution lines from Accounts Payable without having to re- input the information.

N

Accounts Receivable


1. The system must provide on-line entry of receipt information, receipt issuance, and update accounts receivable automatically. Y

2. The system must provide the ability to record manually issued receipts. Y


3. There should be automatic validation for duplicate receipt numbers on-line during receipt entry. Y

4. The system should provide a copying function for receipts. Y

5. The system must handle splits of receipts among different accounts. Y

6. The system must support deposits and deposit application to receivables (open items). Y

7. The system must provide receivable transaction and receivable schedule maintenance. Y

8. The system must manage receivable information in the form of multiple open item types. Y

9. The system must allow partial payment of receivable amounts. Y

10. The system must accept cash receipts applied against multiple receivable amounts. Y

11. The system must produce daily deposit documents in the form that satisfies cash reporting and audit requirements. Y

12. The system must provide the ability to identify receipt transactions by type (i.e. cash receipt, adjustment, write-off, etc.). Y

13. The system must automatically generate outstanding payable for overpayments. Y

14. The system must project the cash flow of receipts based on historical data (previous years). There are receivables occurring at a specific period of time e.g. circulation license fees etc.

Y

15. The system must provide management reporting including ageing reports. Y

16. The system must support the entry of “lumped” receivables and receipt information by interfacing with other Operational Systems. Y

17. The system must provide customer data maintenance. Y

18.

The system must control duplicate customer entry and merge any duplicates. The system should automatically update any associated outstanding receipts for the customers so that they all refer to the same customer. There should be reports to review the customers and receipts affected by the merge.

Y

19. The system must generate accounting transactions and automatically update the General Ledger system. Y

20.

The system must provide account distribution sets or templates which provide for default accounting distributions. For example it should be possible to automatically distribute a receipt amount to several sub accounts without having to manually input.

N

21. The system must allow authorised users to update receipt amounts and distributions subsequent to General Ledger posting. The necessary adjusting journal entries should be automatically generated.

Y

22. The system must provide automated Bank deposit preparation. Y

23. The system must provide flexible reporting capabilities on receivables information by category, general ledger account, responsibility centre etc., and creation of meaningful ratios for the evaluation of receivables.

Y

24. The system must print reminding statements to be sent to overdue debtors. N

25. The system must process returned cheques due to insufficient funds. Y

26. The system must support multi-currency receivables. Y

27. The system must support interest calculation for overdue debts. Y

28. The system must support the classification of collections into various categories. Y

29. The system must provide the ability to age accounts receivables by ageing periods. Y

30. The system must provide automatic cash allocation facility. Y

Fixed Assets


1.

The system should maintain the fixed assets details, which include but are not limited to: � Asset number � Asset description � Tag number � Serial number � Location � Employee � Asset category � Depreciation expense account � Lease � Purchase order � Invoice

Y

2. The system must be able to track non-depreciating assets, land, leased assets, intangibles, and expensed items. Y

3. Assets number should be manually created by the user or automatically generated by the system. Y

4. The system must be able to define asset subcomponents where one asset is related to another. These subcomponents can be track and manage separately while still automatically group them to their parent asset.

Y

5. The system must have the ability to define and track descriptive information on manufacturer and vendor warranties. N

6. Assets records should be created from: � Accounts Payables when invoice line is identified as an assets item � Direct entry

Y

7.

The system must be able to handle Construction-In-Process transactions such as: � Manual additions, additions from Accounts Payable etc. � Cost adjustments � Transfers � Full retirements � Capitalization of one asset or a group of assets

Y

8. The assets must be able to query on-line by asset tracking information. Y

9. The system will have to create journal entries to account for adjustment, such as, updated cost of assets to correct an invoice error, or change the depreciation method.

Y

10. Differences resulting from the adjustment will have to be expensed out in the current accounting period or amortized over the remaining life of the asset. Y

11. The system must have the ability to change depreciation information for a group of assets. Y

12.

The system must be able to transfer assets, including mass transfers, in current period or retroactively: � Fully or partially between general ledger depreciation expense account � Between locations and employees � Between companies or share assets among companies using the same

corporate book.

Y

13.

The system must be able to retire assets individually or massively in current period or retroactively: � By cost or by units � Fully or partially � By entering a total proceeds of sale and cost of removal � Gain/loss calculations The system must be able to perform assets reevaluation.

Y


14. In the event that an asset was entered in current period or back dated to prior period, system will have to calculates the ‘catch-up’ depreciation and expense it in the current accounting period.

Y

15. The system should provide flexible depreciation calendars such as fiscal year, depreciation calendar and prorate calendar. Y

16. The system must have the ability to use rule-based user-definable depreciation. Y

17. The system must have the ability to define prorate and retirement conventions. Y

18.

The following depreciation methods must be supported, but not limited, by the system: � Straight-line � Declining balance � Sum of year’s digits � Units of production � Flat rate � Diminishing value � Bonus depreciation

Y

19. The system must be able to enter capital budgets manually or load them automatically from spreadsheets and project depreciation expense. Y

20. The system must have the ability to enter unplanned depreciation expense amounts. The system must have the ability to depreciate beyond salvage value up to the depreciation limit.

Y

21.

The users must be allowed to perform what–if depreciation analysis to optimize asset management. What–if depreciation analysis simulates multiple depreciation scenarios using different combinations of depreciation criteria, such as depreciation methods, asset lives, and prorate conventions.

N

22.

The users must be able to select assets for what-if depreciation analysis using various criteria such as: � Range of assets numbers � Asset category � Asset description.

N

23.

The system must provide following ways of entering physical assets inventory information: � Online � Spreadsheet � Bar code reader

Y

24. Where applicable, the Fixed Assets system should be integrated to the General Ledger and Accounts Payable. Y

25. The system should provide a standard interface table to convert assets from any existing system to new system. Y

26. There should be a seamless integration from a spreadsheet system (e.g. MS- Excel to the system to facilitate conversion of existing assets or batch addition of large number of new assets.

N

Cash Management


1. The System should include a cash forecasting planning tool that helps to project cash inflow and outflow based on historical and in–process transactions from the General Ledger and Accounts Payable modules.

Y

2. There should be a forecasting interface to accept cash transaction from other external systems to give organisation-wide cash forecasting. N

3. Users must be allowed to define multiple cash forecast templates to generate periodic cash forecasts. Y


4. Cash forecast must be generated in any currency. Option should be given to analyze currency exposure by forecasting only source transactions with a given transaction currency.

Y

5. Cash forecasts must be able to be queried or printed or exported to spreadsheets. Y

6.

The system must be able to: � Record bank statements manually or automatically via open interface file � Correct bank statement open interface data online � Reconcile bank statements automatically or manually � Reconcile with payments Accounts Payable and external systems � Reconcile correcting statement lines against error statement lines � Clear payments prior to reconciliation � Automatically create miscellaneous transactions to record bank initiated

activities such as bank charges and interest � Automatically generate reconciliation accounting entries for cash clearing,

bank charges, and foreign currency gain or loss � Automatically record foreign currency gains and losses

Y

Warehouse Management


1.

All information stored and all existing registers/ledgers must be produced by the system at every level, including: � Per Item � Per Group (defined by users) � Per category (defined by users) � Per type (defined by users) � Per Location � Aggregating values and quantities totals to all levels.

Y

2. The system should provide appropriate functionality for reconciliation of asset inventory, report on missing assets, and take corrective management action. Y

3.

The system must provide reports to be used to inform fixed assets manager of additions, transfers, retirements, or other changes, ensuring timely and accurate asset inventory data through set message or email alerts to automatically notify management of such changes.

Y

4. The system should provide advanced, real time warehouse management functionality for a wide variety of business types for central as well as regional warehouses.

Y

5. The system should support a number of reports for controlling warehouse(s) on every level of the organization, per category, type, item in quantities as well as cost values.

Y

6. The system should support drill-down from any item to all transactions for this item. Y

7. The system should be based on a rules based architecture, including a flexible and powerful business rules engine, which permits extensive tailoring of key processes such as directed picking and storage.

N

8.

The system should support specific rules to be selected based on the content of any associated business object (e.g. orders, items, suppliers, projects etc.). Rules may vary by warehouse and by effectively date, permitting the system to adapt dynamically to changing needs.

N

9.

The system should be ready to support (exporting/importing exchanging data) mobile hand-held computers and bar code scanning, without the need for any 3rd party middleware, including support for RFID readers and filtering, tag labelling, RFID-enabled transaction processing and feedback mechanisms.

Y

10. The system should allow any number of inventory, shipping and receiving label Y


formats to be defined and printed. These labels should be printed on demand or triggered automatically by any warehouse process. Pre-defined business rules should automatically select the correct label format for that specific transaction based on the recipient, product profile or other transaction attribute.

11.

The system should support receiving goods and services against multiple document types as well as finished goods receipts. Inspection, if required should be performed by various user interfaces for more robust inspection result data capture.

Y

12. The system should provide picking, consolidation, staging and truck loading activities to be directed to staging warehouses. N

13. The system must support several pick methodologies such as cluster picking, bulk picking, order picking and zone picking. Y

14.

The system should support highly flexible, user-configurable lot and serial attributes, which may be used to store additional information. Lots may be split and merged, and a complete genealogy is maintained of any serial or lot controlled item, providing immediate information in the event of a recall. The system should provide control on the eligibility of a specific material holding for various transactions (e.g. damaged goods can’t be distributed, but they can be transferred). Material statuses may be applied at the lot, serial or warehouse location level.

Y

15. The system should support the management of materials having a specific lifecycle (e.g. expiration date, maximum consumption date etc.) Y

16.

The system should allow warehouse managers to monitor and fine-tune process within the area of their respective responsibility using query management and mass update for changes to prioritization, manual task assignment and task release.

Y

17. The system should improve the efficiency of operations by configuring real-time alerts and workflow-based notifications of supply chain exception events. Y

18. The system should capture request/demand information directly from the organisation units (via electronic messaging, including XML and derive combined, consolidated data for defined sectors of the organisation.

N

19. The system should allow organisation units to import orders and returns as well as send order delivery acknowledgements, order change messages and advanced shipment notification.

Y

20. The system should allow users direct access to order information, delivery status, and invoice information. Y

21. The system should deliver easy-to-use tailorable forms to efficiently enter requests/orders and workflow them through the organisation’s warehouse hierarchy at all levels.

Y

22.

Inventory will automatically be reserved at order entry, if the request date is within a user-specified timeframe. If the request date is further into the future, an automatic process will perform the reservation automatically as the requested ship date moves within the allocation window.

Y

23.

The system should provide robust workflow and user tools to efficiently provide tailored processing of requests and orders and line items. Integrated checking, and order holds, combined with the workflow architecture should enable request/order processing to support a range of fulfilment scenarios.

Y

24. The system should streamline the entire logistics process including picking, packing, shipping and final delivery while optimizing transportation and warehouse processes.

Y

25.

Users should easily configure the shipping transactions forms to fit their shipping business process. All shipping related processes (picking, packing and ship confirmation) should be fully automated for processing a high volume of shipments.

Y

26. The system should support both local and central procurement and purchasing Y


procedures and configurable policies, per specific category of items/goods/services and/or per value of requested goods. Consolidation of requests to organisation-wide level should be available so that items which are procured from different organisation units are monitored and possibly procured by central level for all organisation units.

27.

Procurement/purchasing should allow the establishment of sourcing rules to determine how it handles incoming demand. Based on organisation-configurable logic, the application will use the rules to process demand, determine the correct allocation to a supplier or suppliers, and create purchase orders.

Y

28.

The system should ensure that all exceptions are sent to the appropriate person for handling and the organisation will retain complete control of automated buying while freeing warehouse and logistics personnel from repetitive tasks.

Y

29. Procurement/purchasing should provide dock-to-stock tracking of orders, whether goods are delivered to receiving organisation units’ warehouses or directly to central warehouse.

N

30.

Procurement/purchasing should maintain repository of supplier data and approved suppliers list to examine and define the certification status of suppliers for items. Supplier per Item catalogues should be maintained to locate items and pricing on past purchases. The system should support locating qualified suppliers for each item and source from the most current agreements and capturing preferred supplier and volume discounts.

Y

31.

Procurement/purchasing should be able to follow up contract purchase agreements, defining the key aspects of an arrangement with particular suppliers such as goods and services, base pricing, price breaks, payment terms, amount agreed to etc. These agreements can be used for purchases within a single organisation unit or can be shared across multiple units – making it easy for the organisation to benefit from global sourcing. When requests are coming in, the system should automatically find the appropriate agreement and pricing to issue orders.

Y

32. The system should allow the decoupling of the demand source from where the buying actually takes place. Y

33. Procurement/purchasing should provide aggregating/consolidating functionality and production of List of Supplies to be tendered. Y

34. The system must provide on-line on-screen and/or in printed format all appropriate reports for and per every level of the organisation in detail and/or aggregated or consolidated.

Y

35.

The system should maintain the following actual, budget, encumbrance, variance, and statistical balances at detail or summary levels, which must be available for on-line inquiry or reporting purposes: � Period-to-date � Year-to-date � Quarter-to-date � Project-to-date � Full year

Y

36. The system must include an easy to learn, user oriented report writer. All facilities should be available without the need for technical support or programming.

Y

37.

Comprehensive reports and listings should be provided including indicatively: � Trial balance � Transaction Listing � Chart of warehouse items listing � Balance Sheet

Y

38. The system should provide business performance information for key performance indicators such as revenue, expenses etc, highlighting trends, Y


which could then be further analyzed by drilling into detail reports.

Vehicle management


1. The system’s vehicle management component should provide the organization with a comprehensive suite of features to manage the vehicle maintenance process - from dispatch to billing & settlements

Y

2.

Based on the daily collection of the forms prepared by employees using the vehicle, the system should provide all appropriate information regarding � Daily/Monthly/yearly usage per type of vehicle � Daily/Monthly/yearly usage per activity performed � Daily/Monthly/yearly usage per user of vehicle � Fuel cost per kilometre, mile//hour/tons or user defined measure, � Fuel consumption reports, � Fuel/oil cost per individual vehicle/user/activity � Directorate fuel inventories

Y

3.

The system should maintain in electronic form all books regarding the details of each vehicle: � Vehicle equipment inventory, � Vehicle specification details, � Vehicle component specifications, � Vehicle maintenance log book � Purchasing Information � Vehicle Equipment Checkout � Fuel/oil cost per kilometre, mile/hour/tons or user defined measure, � Directorate fuel inventories � Vehicle Costs of ownership � Work/service Orders Billing/History � Parts Inventory � vehicle/Wheel/Tyre � Daily Authorisations � Charge sheet for vehicle repair � Vehicle Pool Tracking per Directorate � Vehicle Depreciation integrated with Fixed Assets system (where

applicable) � Asset Tracking integrated with Fixed Assets (where applicable)

Y

4.

Additionally the system should support the maintenance of the following information: � Work standards, normal and extended maintenance service-plans � Reason for repairs, � Tire changes and reasons � Maintenance cost trends, � Complete purchase parts order system integrated with

Purchasing/Procurements component and inventory, � Part usage, � Preventive maintenance scheduling

Y

5. A range of reports and statistics information should be provided by the system for the usage and the cost of vehicles. Y

6. Both kilometres and miles should be supported by the system, and for some types of vehicles usage may be counted in hours. Y

5.3 Human Resources / Payroll systems

Human Resources systems


1.

All Human Resources information should be date-tracked. The application should record extensive, date-effective information on all aspects of an officer or applicant, from personal histories, applications, events, performance or disciplinary reviews, transfers, medical data, travel, compensation, training attendance, career planning data, use of assets, accomplishments and competencies.

Y

2. The application should allow multiple ‘attachments’ to an employee record to provide access to scanned documents, spreadsheets, video, or text documents.

N

3. The application should have a graphical tool to create, view or make easy drag and drop amendments to organization charts with automatic update of employees affected by the amendment.

Y

4. The application should allow the creation of multiple concurrent organization structures. N

5. The application should allow the Personnel Department the flexibility to define job and position structures. Y

6.

The Personnel Department should be able to define requirements in terms of monetary and headcount-based position budgets, and record required skills, competencies, experience, qualifications, valid grades and other user-defined criteria for each functional role or duty.

Y

7. The Personnel Department should be able to drill down to view a complete history of position occupants. N

8. The application should be able to assign employees to single or multiple roles. Y

9. The Personnel Department should be able to specify any number and type of recruitment needs and link requests together at any level to provide a full picture of recruitment activity, while tracking the cost of each.

Y

10. The application should be able to track the progress of an applicant using applicant status, which the Personnel Department specifies to match administrative steps, acceptance stages, or evaluations.

Y

11. The application should provide facilities to rapidly search for employees whose skills, qualifications, training, or experience match the functional role, or position requirements.

Y

12. The Personnel Department should be able to assess applicants on-line in various ways, ranging from 360 degree assessments, to manager or supervisor assessments, using a competence based approach.

N

13. The application should be able to record basic employee details as well as any role specific special information. Y

14. The application should allow the Personnel Department to store any number of addresses for each person. The addresses should be identified by an address type, e.g. home, vacation, temporary etc.

N

15.

The application should be able to record any number of dependents for employees, with addresses and personal details, as well as indicate the type of relationship so that dependents can then be covered under any medical or other plans.

Y

16. The application should be able to load and store multiple image files for all employees, e.g. photographs, signatures, or documents such as certificates, identifications and resumes. These should be viewable on-line.

Y

17. The application should be able to record details of an employee’s job, organization, position, appraisals, evaluations, penalties, location, costing, supervisory relationships, full time or part time status, and working conditions.

Y

18. The application should be able to record employee skills, qualifications, Y


competencies, and experience as well as user-definable attributes.

19. The application should provide turnover statistics via termination processing. The list of termination reasons should be user-defined and termination records should be retained and be able to reverse if necessary.

Y

20. The application should be able to identify training needs by matching competencies from current and future jobs, positions and organizations to employee competency profiles.

Y

21. The application should provide support for the creation and maintenance of training budget. Y

22.

The application should be able to define any number of training course types and build a schedule of courses to meet training needs. Subsequently, the application should be able to schedule students against the course run and record their attendance.

Y

23. The application should provide an individual training history for each employee, recording the courses attended, and any other training details required.

Y

24. The application should provide support for multiple appraisal formats and contents. Y

25. The application should store a complete appraisal history, with details of who performed the appraisal. Y

26. The application should allow the Personnel Department to hold unlimited numbers of absence types and absence reasons. The Personnel Department should be able to enter absence details in days or hours.

Y

27.

Using analysis tools, the Personnel Department should be able to monitor absence summarized by any criteria, such as job, department or rank and search for absence patterns. The Personnel Department should be able to view a complete absence history for any person, or a summary of all absences for any given absence type a given period.

Y

28. The application should allow the Personnel Department to schedule employee vacation and define multiple vacation plans. Y

29. The application should provide support for employee business travels scheduling, budgeting and down payments. Y

30. The application should allow properly authorised users (e.g. the head of the organisation) to perform sophisticated searches to identify people by skills, personal characteristics, employee information etc.

N

31.

A collection of reports as indicatively summarised below should be provided: � Employee Personal File, including:

� Personal data � Education/Training � Evaluations � Appraisals � Career path � Functional roles served

� Organisational units population per functional role � Functional role population and composition � Shortages of personnel according to organizational chart and functional

roles working positions � Ageing of personnel � Ageing of personnel per functional role � Training programs � List of trainings available � Attendants per thematic area of trainings � Attendants per training � Trainings provided per level � Attendance/presence/absence report per employee � Absence reports per type of absence

Y

Payroll systems


1. Where applicable, the application must be seamlessly integrated with all other ERP subsystems and especially with the Human Resources application Y

2. The application must maintain full historical records of all payroll related data per employee. Y

3. The application must be fully conformant with the laws and regulations related to employee compensations. Y

4. The application must be efficiently designed and fully parametric so that all changes related to compensation plans (e.g. salary raises) are easily incorporated.

Y

5.

The application should allow the Personnel Department to place an employee within a valid rank and to record the valid salary for the rank placement. The Personnel Department should be able to update the salaries of many employees at once by changing the salary ranges for a rank.

Y

6. The application should be able to link rewards and salary scales to employee rank structures. Y

7.

The application should be able to define salary components, overtime, union dues or subscriptions, medical and other insurance, and pension contributions. The Personnel Department should be able to default employer and officer contributions for pension, medical and dental plans, and amounts and cost allocations for other plans.

Y

8.

The application should be able to record a proposed or approved salary for an employee and track changes based on merit, promotion, changes in working conditions, and performance. The Personnel Department must be able to view a full salary history with performance ratings and current salary ranges.

Y

9. The application should be able to perform a budgetary calculation of payroll on a monthly basis for one full year with different scenarios based on hypothetical salary changes.

N

10. The application should be able to calculate all kinds of compensations on a monthly basis or on a different user-defined time scale for either the whole personnel or for a range of employees or for a single employee.

Y

5.4 Project Administration systems


1. Where applicable, the application must be seamlessly integrated with all other ERP subsystems. N

PLANNING – DESIGN OF PROJECTS

2.

The application must support flexible project structures: � Work Breakdown Structures � Project networks � Project activities and the interrelations � Project milestones

Y

3. There must be a graphical user interface based on standards which will simplify the design processes and provide central overview of projects. Y

COST MANAGEMENT

4. Costing of the project at different detail levels Y

5. Automated calculation of the costs of internal and external activities, services and materials from the resources assigned to project activities. Y

6. The application must allow the amendment of budgeted costs. Y


7. Where applicable, the application must be integrated with the Human Resources application for resource allocation. N

BUDGETING

8. The application must provide for initial project budgeting based on costing. Y

9. The application must support revisions and versioning of project budgets. YSCHEDULING

10. The application must support scheduling of project activities. Y

11. Activity scheduling must take into account existing constraints. Y

12. The application must provide for the calculation of critical path and of the earliest and latest dates for the initiation or finishing of activities and projects. Y

PROJECT EXECUTION AND MONITORING

13. The application must provide for the management of project cash flow and for the timely information on imminent payments. Y

14. The application must provide for the monitoring of project progress based on scheduled values. Y

15. The application must provide for the monitoring of project progress based on actual values. Y

16. The application must support checking of budget consumption and provide timely information on deviations from the budget. Y

REPORTING

17. The application must provide for the presentation and printing of basic project information. Y

18. The application must provide reports on project evaluation as a whole or of a specific part. Y

19. The application must provide reports on comparative evaluation of multiple projects. N

5.5 Document Management and Workflow systems

Document Management systems


GENERAL REQUIREMENTS

1. Where applicable, the application must be seamlessly integrated with all other ERP subsystems and especially with the Workflow system. Y

2. Where applicable, the Document Management system should be manufactured by the same company as the Workflow system so as to ensure seamless integration.

N

3. The system must be fully parameterised to reflect the needs of the organisation. Y

4. The system must support the process for electronic document register possibly with different registers in each department or directorate. Y

5. The system must support all the common document types and multimedia files. Y

ARCHITECTURE AND INTERCONNECTIONS

6. The system must support multi-user operation. Y

7. The system must support full-functional operation in Web environment, with automatic creation of the relevant web pages. The system must support the most common web browsers.

N

8. The system must operate under a windows-based graphical user interface. Y


9. The system must provide full support for the Arabic character set (ISO-8859-6) for document storing and retrieval as well as for Full Text Retrieval (FTR). Y

10. The system must provide full support for the Arabic character set (ISO-8859-6) at all its levels and functions. Y

11. The system must provide an interface for data exchange with other common applications as well as an API for the implementation of interfaces with other third-party applications.

Y

12. The system must support the most common operating systems for the workstations. Y

13. The system must support the most common database management systems. Y

14. All stored documents must be accessible through the system and through MS-Office compatible applications and common web browsers. N

15. The system must support the storing of data and metadata in a relational database management system which will exploit the capabilities of external storage (e.g. Storage Area Network) and optical storage media.

Y

16. The system must interoperate with the most common e-mail systems for the sending of e-mail and the automated archiving of incoming and outgoing messages.

Y

17. The system must support the archiving of both the message body and the attachments in their native form. Y

18. The system should retain the links between the email body and its attachments, supporting full-text search. Y

19. The system should provide standard reports on its usage. YDOCUMENT AND DATA ENTRY

20. The documents must be stored in digital format. The system must support the most common types of documents, image files and sound files. Y

21. The storage of a document must be done in either its native form or by transformation to document or image form. Y

22. The system must support the entry of documents directly from MS-Word compatible and other third-party applications. Y

23. The system must support the entry of a unique document and the massive entry of multiple documents or folders. Y

24. The system must support the entry of non-digital data through scanning. Y

25. The system must support the use of scanners. Y

26. The system must support the TWAIN or ISIS protocols for the scanning devices. Y

27. The system must support the scanning of multiple page documents and the selective archiving of one or more pages either as a separate document or as an attachment to an existing document.

Y

28. The system must support both colour and black & white images supporting the JPEG compression algorithm for colour documents and the TIFF CCITT Group IV compression algorithm for black & white documents.

Y

29. The system must support the preview, processing and enhancement of a scanned image. Y

30. The system must support the transformation of images to text documents through the use of Optical Character Recognition (OCR) tools which should support at least the Arabic, English, French and German languages.

Y

31. The system should support the preview of all pages of a scanned document in reduced size on screen so as to facilitate navigation. Y

32. The system should provide a complete set of tools for the processing of a stored document supporting annotating, highlighting, entering of text etc. Y

PROCESSING AND ARCHIVING

33. The system should support the categorisation and classification of documents using fields defined in the classification forms. Y


34. The system should support the linking of a physical document to one or multiple classification forms. N

35. The system should store documents in groups having common characteristics and in multi-level hierarchical folders. Y

36. The system should support the creation of personal or public use folders. Y

37. The folder entity should provide the structure for documents that are physically or logically interrelated. Y

38. Every folder should be accompanied by its own classification fields, should support multiple versions, should have its own history in the system and should support the storage of its files usage information.

Y

39. The system should support interrelations between files and folders. Y

40. The system should support the definition of access levels per document depending on the user and the classification of the document. Y

41. The system should support check in / check out procedures during document management. Y

42. The system should support version control for the documents. Y

43. The system should support the selective creation, maintenance and control of old versions. The system should also monitor potential changes to the documents and automatically activate the version creation mechanism.

Y

44. The system should provide support for allowing or prohibiting access to previous document versions. Y

45. The system should allow the creation of a new document version from any existing version. Y

46. The system should support the definition of the status of a document. Y

47.

The system should support unlimited number of documents defining for each one:

� The archiving space and storage � The version number

Y

48. The system should support the preview of the most common document types through a viewer application without the need to install the application with which the document was created.

Y

DOCUMENT SEARCH

49. The system should support search via Full Text Retrieval (FTR). Y

50. The system should support search via keywords. Y

51. The system should support search in previous search results. N

52. The system should support complex search with multiple criteria (more than one classification attributes) and composite search (FTR and classification attributes concurrently).

Y

53. The system should support search via logical operators (AND, OR). N

54. The system should support the storage for future use of quick search scenarios per user or group of users. Y

Workflow systems


1. Where applicable, the application must be seamlessly integrated with all other ERP subsystems and especially with the Document Management system.

Y

2. Where applicable, the Workflow system should be manufactured by the same company as the Document Management system so as to ensure seamless integration.

N

3. The system should be able to operate either as a traditional Client/Server application or as Web-based application (Internet-Intranet).

Y


4. The system administrator should be able to define the connection protocol (HTTP ή HTTPS) in the case of user access through the Internet.

N

5. The system must provide embedded support for the POP3, SMTP and IMAP standards which are supported by all mail servers.

Y

6. The system must provide support for all the business processes of the organisation.

Y

7. The system must provide support for the implementation of business processes some steps of which may reside in different information systems.

N

8.

The design of a process must be done easily using an embedded system tool. The tool must not require specialised programming knowledge and the design and parameterisation of a process must be done via a graphical user interface.

Y

9. The process steps or tasks must be defined via the graphical user interface. Y

10. Any change to a process in operation must be performed via the same tool and put immediately into operation.

Y

11. The designer must be able to add an attachment control to a form allowing the users of the form to attach any file to be distributed with the specific form.

Y

12. The system must offer the possibility to define that in order for a form to be processed the attached document must be opened.

Y

13. The system must allow the attachment of specific document types only. Y

14. The system must prevent the users from changing an attached document. Y

15. In the case that a form is executed by a web browser, the browser must support the attachment of documents.

Y

16. The system must allow the designer to create forms in each step of the process.

Y

17. The system must allow the designer to control which information a user can view or enter in each step and what decisions he allowed to make.

Y

18. The system must allow the full administration of process amendments as well as the update of process forms that are in operation.

Y

19. The system must allow the creation of new versions of processes. Y

20. For every step of a process the system must allow the definition of conditions affecting the flow of work.

Y

21. The system must allow the definition of values for which an activity for the specific task must be automatically executed.

Y

22. The administrator should receive e-mail messages in the case a specific event or an exceptional situation occurs.

Y

23. The system must keep log files recording automatically all the events the administrator requires. The log files must be kept for as long as the administrator desires.

Y

24. The administrator must be able to monitor the workload of users for current and future assignments.

Y

25. In the case a user is absent, the administrator must be able to reroute any pending work to another user.

Y

26.

The system must provide the administrator with the tools required to fully control the processes:

� Installation/deinstallation of processes � Monitoring of processes � Control of the users workload and task assignments � Creation and maintenance of access rights � Execution of administrative activities

Y

27. The system must provide a tool for the presentation of the sequence of activities that must be performed for the execution of a process as well as the time constraints.

Y

28. For every step of a process the system must allow the definition of the time Y


limits for its execution.

29. After the expiration of the time allowed for the execution of a process step, the system must send automatically a notification to the user.

Y

30. The designer of a process must be able to provide brief instructions to the users for their pending work.

Y

31. Where applicable, the system must allow the designer of process to require that a user uses his digital signature to verify his actions.

N

32. The system should provide a tool for the creation of organisation charts which will be used by the processes.

N

33. The system should be able to relate and base the design and flow of a process on the organisation chart created with the tool.

N

34. The system should support the automated import of an organisation chart from another system (e.g. one of the major ERPs) which should then be used for the design and flow of processes.

N

35. The users should be able to keep a list of actions they must perform which must be sorted (e.g. current, late, urgent etc.)

Y

36. The users should be able to initiate the process they desire from the list of processes they have access to.

Y

37. The users should be able to view the status of a process either as a list of steps or as a graphical representation of the flow for a specific instance.

Y

38. The finalisation of a process step may involve a third party application (e.g. an MS-Office application or an e-mail system).

Y

39. For every significant change in a process its version should be automatically revised.

N

40. Users wishing to initiate a process should be automatically informed of the existence of a new version.

Y

41. In the case a process is updated and reinstalled, the new version should automatically replace the old.

Y

42. A request should be able to be approved or rejected based on user decision. Y

43. The designer of a process should be able to define the number and type of steps without limitations.

Y

44. Every user should be able to provide directions or explanations by communicating with the next user.

Y

45. The system should provide tools for the production of reports based on user queries as well as reports on processes, performance, response times etc.

Y

46. The system should allow the assignment of a process step to a different user than the one originally defined by the designer.

Y

47. The system administrator and properly authorised users should have the ability to monitor fully the flow of a process instance checking both its history of steps and its present status.

Y

48. The system should provide full support for the Arabic language (ISO-8859-6) as well as the English, French and German languages.

Y

49. The system should be based on an object-oriented architecture. N

50. The system should support the most common client operating systems. Y

51. The system should provide an Application Programming Interface (API) based on open and widely accepted standards.

Y

52. The system should provide a fully parametrical logging system. Y

53.

The system should support through the monitoring environment: � Production of statistics and indices. � Presentation of the system status. � Operation of a notification and alert mechanism

Y

54. The system should support through its design environment the definition of checkpoints (flags) on processes so as to produce events for the evaluation of the workflow execution.

N


55. The system should provide an embedded exception handling mechanism. Y

56.

The design tool of the system should provide an environment where the user is able to see the process flow in the following formats:

� Graphical representation � Task list with all the elements of a process � XML format � Source code of the supported API

Y

57. The system should support dynamic processes. Y

58. The system should support both synchronous and asynchronous tasks. Y

59. The system should support the XML technology and the import and export of processes in XML files.

Y

60. The system should support templates for the creation of new processes. Y

61. Every process should consist of discrete tasks. Y

62. Every task should be able to contain sub-tasks. Y

63. The system should support the transfer of a task to any point in a process. Y

64. The system should support for every task the dynamic definition of the person responsible for its execution.

Y

65. The system should support the definition of the logical operators AND / OR between tasks.

Y

66. The system should support the definition of a task for the sending of an electronic message.

Y

67. The system should support the definition of a task for the execution of code. Y

68. The system should support the definition of a task for the initiation of a sub-process.

Y

69. The system should provide a tool for the ad-hoc creation of reports of the process data.

Y