E Government Standards

E-GOVERNMENT STANDARDS

E-Government Directorate, Ministry of IT 1/164

E - GOVERNMENT STANDARDS

Draft Version

2009

Government of Pakistan Ministry of Information Technology Electronic Government Directorate

Prepared by: Strategic Planning & Architecture Wing, EGD



Table of Contents INTRODUCTION…………………………………………………………………..…………………………..….....3

EXECUTIVE SUMMARY……………………………………………………………..…………………..………...5

1 COMMON ARCHITECTURAL REFERENCE MODEL………………………………..………..….……...15

1.1 Business Architecture ……………………………………………………………………… …….………....15 1.2 Service Exchange Architecture ……………………………………………..................................................19 1.3 Application Architecture ………………………………………………………..……….... ..22 1.4 Technology Architecture…………………………………………………………………….………………..25

2 PRE- DEVELOPMENT STANDARDS………………………….……………………....................................26

2.1 Business Process Modeling…………………………………………...………………....................................27 2.2 Steps - Business Process Modeling................................................................................................................. 29 3 SERVICE ENGINEERING…………………………………………………………….……… .32 4 DEVELOPMENT STANDARDS………………………………………………….…….………. 43 4.1 Software Requirement Specification (SRS)……………………………………………………… ..……….44 4.2 Software Design Document (SDD)……………………………………..….………...................54

5 IMPLEMENTATION STANDARDS…………………………………………………………………………..64

5.1 Introduction………………………………………………………………………………….…..................64 5.2 Software Implementation…………………………………………………………………….……………..65

6 PAKISTAN GOVERNMENT DATA STANDARDS CATALOGUE………………...……………. 75 7 TECHNICAL VOCABULARY CATALOGUE…………………………………..........................................137

7.1 PRE- DEVELOPMENT STANDARDS………………………………………………………….…………… ..137 7.2 DEVELOPMENT STANDARDS……………………………………………………….....................................138

8 WHAT NEXT?...................................................................................................................... 147 8.1 Government Service Bus (GSB)…………………………………………………...…………………….....147 8.2 Government Discovery, Description and integration (GDDI)……………………..................................... 151 9 APPENDICES…………………………………………………………………………………….………...... 153

9.1 APPENDIX – A: BPD Core Elements Set………………………………………………..……….…….. 153 9.2 APPENDIX – B: Use Case Diagram……………………………………………… ….….…………….... 156 9.3 APPENDIX – C: Class Diagram………………………………………………………………..……....... 157 9.4 APPENDIX – D: Component Diagram…………………………………………………….……….……. 158 9.5 APPENDIX – E: Deployment Diagram………………………………………………..……………….... 159 9.6 APPENDIX – F: Activity Diagram…………………………………..………………………………....... 160 9.7 APPENDIX – G: Sequence Diagram…………………………………………………..……………….... 161 9.8 APPENDIX – H: Issue Card & Factor Table………………………………………..........……………… 162 9.9 APPENDIX – I : System Features……………………………………………………..………………… 163



INTRODUCTION

According to IEEE, standard is a published document that sets out specifications and

procedures designed to ensure that a material, product, method, or service meets its

purpose and consistently perform to its intended use.”

Standards not only solve issues ranging from product compatibility to addressing

interoperability and service delivery but they also simplify product development and

reduce non-value-adding costs thereby increasing a users’ ability in using the

systems.

Standardized systems are used worldwide to manage and control the process using

standardized methods and procedures. Accordingly, the standards are developed to

establish a uniform process and activities for e-government projects of Government of

Pakistan. The foremost objective is to ensure the interoperability of these systems.

This is necessary to provide seamless service delivery to all stakeholders including

citizens of Pakistan. In addition, the investments being incurred on e-government

projects can also be leveraged while replicating the standardized systems across all

government entities.

The following are the main objectives of developing Standards.

• Follow Standardized process for development of e-government projects.

• Ensure Interoperability between systems.

• Adopt the strategy of build once, replicate across with less effort.

• To provide reference for common terminology and vocabulary for development

of e-government projects.

• To establish clear expectations between execution entity (for example EGD)

and its vendors.



Bottom Line The Standards help in satisfying requirements of interconnectivity and interoperability

that is essence of e-government.



EXECUTIVE SUMMARY

The E-government Interoperability Framework (e-GIF) for Government of Pakistan

(GoP here after) is comparing of policies, standards, and guidelines. It envelops ways

to achieve interoperability of public sector data and information resources and

information and communications technology (ICT). It facilitates any agency to adhere

its information, ICT or processes with those of any other agency using a preset

framework based on "open" (i.e. non-proprietary) international standards. The e-GIF

will:

• Help government agencies to work more easily together electronically.

• Make systems, knowledge and experience reusable from one agency to another.

• Reduce the effort needed to deal with government online by encouraging

consistency of approach.

• Reduce the reliance on tapes and disks to exchange data, as these carry their own

security issues and are not scalable for the level of interoperability i.e. motivation

for data centers.

Interoperability is not just a methodological substance of connecting computer

networks. It also embraces the sharing of information between networks and the re-

design of business processes to deliver improved outcomes and efficiencies and to

support the seamless delivery of government services.

Interoperability is fundamental to the success of connected government – the aim for

collaborative, effective and efficient government and the delivery of seamless

government services. However, delivering on the vision of connected government

relies on the willingness and ability of agencies to collaborate. Active commitment

(rather than passive compliance) of the people supporting this collaboration is critical.

Interoperability is an important element in the delivery of government service reform

and integration initiatives. Within this context, it should be understood that:



• Interoperability is not an end in itself, but an enabling capability.

• While standards are necessary, they are not sufficient for interoperability.

• To be interoperable, an organization must actively engage in the ongoing

process of ensuring that its systems, processes and people are managed in a

way which maximizes opportunities for internal and external exchange and

re-use of information.

• Organizational boundaries should not stand in the way of the right people

having access to the right information to make informed decisions or to provide

high quality service.

Interoperability approach for GOP is mainly focused on following three areas:

• Business interoperability

• Information interoperability

• Technical interoperability

Each level of interoperability ensures consistency, efficiency and reliability of business

processes across government also requires effective standards and guidelines. e-GIF

is composed of following documents.

• Common reference architectural model

• Business modeling standards

• Requirement engineering Standards

• Design Description Standards

• Implementation Standards

• Meta Data Standards

E-Gov Initiatives require a flexible, comprehensive architectural model that supports

development of complete requirements when planning, designing, and building major

systems. This is essential because architectural model help in leveraging information



technology investments and avoiding unnecessary duplication of infrastructure and

link business processes through shared, yet sufficiently protected information systems

and leverage disparate business processes, services and activities that are located

outside Agency boundaries. A common reference architectural model for GoP

projects, is an abstract framework for understanding significant relationships among

the entities of governmental environment. It enables the development of specific

reference or concrete architectures using consistent standards or specifications

supporting that environment. A reference model consists of a minimal set of unifying

concepts, axioms and relationships within a particular problem domain, and is

independent of specific standards, technologies, implementations, or other concrete

details. The common reference Architectural model for GOP projects comprise of four

levels / architectures as given below:

• Business Architecture

• Service Exchange Architecture

• Application Architecture

• Technology Architecture

Each level is intended to feature and describe the logical relationships of E-Gov

capabilities, processing / access flows, technologies, and components. The intent is

not to overly constrict the solutions, nor to proffer a solution that may be defined and

implemented in only one manner. In fact, this document attempts to keep the potential

solution sets broad and robust, capable of applying new and better technologies as

they are conceived and delivered.

E-government projects mainly focus towards automation of common and core

processes of each entity. Common are those which are executed by other government

entities as well. These may include HR, Budgeting, Project Management, Inventory,

Procurement etc. while core processes are those which are only executed by a certain

entity. These usually include some services to citizens, businesses and employees.

Examples are Management of Title Deeds, Issuance of various Licenses e.g. driving,



etc., Issuance of various certificates e.g. Domicile, Birth etc. Besides these, there are

certain processes which fall in between the category of Common and Core. Examples

are: Complaint Management System, Library Books Management System etc. In

these processes the basic commonality usually exists however the activities of

escalation usually differs at large.

In this scenario, it is utmost important to comprehend the as-is processes initially

before automating the same. This exercise also provides an opportunity to carry out

the rigorous analysis before automating the processes. This is usually called as pre-

development / business modeling stage where as-is processes are defined, analyzed

and optimized (if required) before these are automated. This definition of processes is

called Business Process Modeling. The use of Business Process Modeling Notations

(BPMN) are recommended as standards in order to ensure the smoothness of

understanding of processes by all stakeholders including process / business analysts

who initially create process drafts, process participants who are usually involved in

execution of routine work, process owners who manage and monitor those processes

and software architects / developers who develop the software. These BPMN

notations are developed by Business Process Management Initiative (BPMI), and are

now being maintained by the Object Management Group (OMG) since the two

organizations merged in 2005.

Once the business processes are modeled, analyzed and new processes are

developed accordingly then effort of automation usually starts. This is called as

development / designing stage where the staring point is to gather the functional and

non-functional requirements so as to design the software based upon the business

requirements.

In delineating the processes, the process consultant has o focus mainly upon each

and every minute activity / task of the process. Later on, these activities / tasks are

looked upon carefully to what can be automated and what can not be automated and

may be left as manual. For example, in the hiring process of government, one of the



most common activities is constitution of hiring committee as per policy of

government. While automating the business processes, this activity is usually kept as

manual due to its nature. These types of considerations play a major role while

gathering the functional requirements. Also, this phase of software is usually felt very

important as it is considered as first and most important building block for any e-

government project. In this regard, the basic course of action is to develop the

Software Requirement Specification (SRS) document that includes documenting the

use cases (functional requirements), components (sub-systems interconnections),

activity diagrams, Sequence Diagrams, Class Diagram etc. These are very important

to be documented so as to produce quality software as this documentation provides

help to system architects, designers and implementers. It is recommended to use non-

proprietary, open-source standards based of Unified Modeling Language (UML 2.x)

while preparing the SRS document.

Once the SRS document is prepared, same will be used as an input for system

designers to develop a blue print of the software to be implemented. The standards

based upon UML 2.x are also recommended for this activity.

Today’s e-government system consists of a large number of components each

offering and requiring services of other components. Such components are often

implemented into distributed, heterogeneous environments adding to the complexity of

software implemented.

In order to make the consistent and reliable information sharing across these

components for streamlining the different process flows, data standards are

recommended for achieving the interoperability.

Basic concept as for the development of data standards start from the categorization

of the information into the different data blocks covering the whole business scenarios

for creating the common business entities use across the different e-government

projects for consistent and reliable information. These information blocks as well as

database development guidelines provide a uniform means for the database analyst



and designer for developing the initial uniform structural data model for data

consistency and uniformity across the e-government entities achieving the

interoperability.

Service Oriented Architectural implementation framework (SOAIF) is recommended as

implementation frame work for e-government systems developed for Government of

Pakistan (GOP). Modern e-government systems are built on a service-oriented

architecture (SOA) which is the latest software architecture style to build flexible and

extensible applications. SOA is described as “a paradigm for organizing and utilizing

distributed capabilities that may be under the control of different ownership domains

(different ministries / departments / organizations). It provides a uniform means to

offer, discover, interact with and use capabilities to produce desired effects consistent

with measurable preconditions and expectations. Web Services represent a set of de

facto SOA implementation technologies, involving the usage of W3C standards such

as WSDL and SOAP for service description and messaging transport respectively.

SOAIF will generate such web services which are component-based, web-oriented

and standard-based.

SOAIF mainly consists of high-level software components that include Web services.

Implementation of an SOA requires tools as well as run-time infrastructure software,

which collectively makes SOAIF as desirable implementation framework for

e-government projects.

SOAIF will focus on internal and cross-enterprise processes, helping e-government

streamline operations, reduce costs, and increase responsiveness. Specifically, an

SOAIF provides general purpose, service-based distributed computing capabilities

that deliver:

• Faster response rate to changing business requirements of e-government.

• Operational efficiencies.

• Faster, less expensive application integration.

• Easier application development and deployment.



Process / business analysts who initially create process drafts, process participants

who are usually involved in execution of routine work, process owners who manage

and monitor those processes and software architects / developers who develop the

software.

Once the business processes are modeled, analyzed and new processes are

developed accordingly then effort of automation usually starts. This is called as

development stage where the staring point is to gather the functional and non-

functional requirements so as to design the software based upon the business

requirements.

In delineating the processes, the process consultant has o focus mainly upon each




most common activities is constitution of hiring committee as per policy of

government. While automating the business processes, this activity is usually kept as

manual due to its nature. These types of considerations play a major role while

gathering the functional requirements. Also, this phase of software is usually felt very

important as it is considered as first and most important building block for any e-

government project. In this regard, the basic course of action is to develop the

Software Requirement Specification (SRS) document that includes documenting the

use cases (functional requirements), components (sub-systems interconnections),

activity diagrams, Sequence Diagrams, Class Diagram etc. These are very important

to be documented so as to produce quality software as this documentation provides

help to system architects, designers and implementers. It is recommended to use non-

proprietary, open-source standards based of Unified Modeling Language (UML 2.x)

while preparing the SRS document.



Once the SRS document is prepared, same will be used as an input for system

designers to develop a blue print of the software to be implemented. The standards

based upon UML 2.x are also recommended for this activity.




software implemented. in order to make the consistent and reliable information sharing

across these components for streamlining the different process flows, data standards

are recommended for achieving the interoperability goal based on IEEE standards

0019.

Basic concept as for the development of data standards start from the categorization

of the information into the different data blocks covering the whole business scenarios

for creating the common business entities use across the different e-government

projects for consistent and reliable information. These information blocks as well as

database development guidelines provide a uniform means for the database analyst

and designer for developing the initial uniform structural data model for data

consistency and uniformity across the e-government entities achieving the

interoperability.

Service Oriented Architectural implementation framework (SOAIF) is recommended as

implementation frame work for e-government systems developed for Government of

Pakistan (GOP). Modern e-government systems are built on a service-oriented

architecture (SOA) which is the latest software architecture style to build flexible and

extensible applications. SOA is described as “a paradigm for organizing and utilizing

distributed capabilities that may be under the control of different ownership domains

(different ministries / departments / organizations). It provides a uniform means to

offer, discover, interact with and use capabilities to produce desired effects consistent

with measurable preconditions and expectations. Web Services represent a set of de

facto SOA implementation technologies, involving the usage of W3C standards such



as WSDL and SOAP for service description and messaging transport respectively.

SOAIF will generate such web services which are component-based, web-oriented

and standard-based.







e- Government Interoperability Framework (eGIF)



1 Common Architectural Reference Model

This document describes the common reference model architectures for all the

e-government projects. These architectures are given below:

• Business Architecture

• Service Exchange Architecture

• Application Architecture

• Technology Architecture

1.1 Business Architecture

Business Architecture is defined as “A strategy to achieve an agreed business goal.

Business process interoperability may result from the pursuit of high-level goals

shared across multiple agencies or it may be introduced at a lower level initially to

enhance the performance of a particular function or program.”

The major objective of Business Architecture in this regard will be to understand

business processes within an entity or across multiple entities vis-à-vis understanding

the connections that exist between government entities in order to assess:

• The degree of commonality in business processes

• The flow of information across those processes and

• The Technology required facilitating those connections.

Major Challenges

• A commitment to streamlining and standardizing business processes around

common elements, internally and with other agencies.



• A user-centric focus (both internal and external), based on a common

understanding of the services needs of users and their preferences for how the

service is provided.

• Agreement on the respective roles and responsibilities of the collaborating

agencies.

The Essence of Business Process Architecture

On of the main objectives of e-government is to ensure the seamless service delivery

to all stakeholders including citizens. In this context, it is very important that all the

applications (regardless of in which entities they are being operated) must exchange

the information online. As a matter of fact, the software applications are developed

and wrapped across business processes to make those transparent and effective for

seamless service delivery. The essence of business process architecture in fact is to

establish Business Process Interoperability that is based upon cross-agency set of

activities (Business Processes) to following kinds of architectural components will be

identified in this phase.

o Private components

These processes are actually internal business process of a certain specific

governmental organization. In general, these processes are called as

organizational workflows.

o Public components

This type of modeling represents the interactions between a private business

process and some process outside organization. It should be noted that only

certain process are allowed to communicate outside organization. Further more

appropriate flow control mechanisms, should be established during modeling of



public process. All other “internal” activities of the private business process may

not be shown in the public process.

o Business interoperability components (Collaborative Components)

Delineating a standardized and uniform set of processes within government

entities will ensure that government is more responsive to both challenges and

change. This is necessitated as to find out what are the common connections

between entities so as these entities can respond efficiently and effectively to

provide seamless service delivery to all stakeholders including citizens.

Moreover, this interoperability will help entitles to carry out any policy or

structural changes as and when required.

In context of above, it is important to first understand the terms orchestration and

choreography. These are basically used for ensuring the loose coupling between

business processes / web services, while concurring with the goal of Interoperability.

These two terms overlap somewhat, but Figure 1 illustrates their relationship to each

other at a higher level.



Orchestration & Choreography: It is the preferred composition style for internal

business processes with tightly coupled internal actors, while choreography is typically

chosen for developing cross-organizational business processes between loosely

coupled partners. Orchestration and Choreography may also be applied

simultaneously. Orchestration, as mentioned may be used either for integrating the

internal business processes of an organization by means of tightly coupling the

processes / information through systems or integrating the business processes

through web services. The decision may lie upon each government entity while

keeping in view the nature of functionality required. However, the ides of integration

through web services is recommended.

In Orchestration, the interactions occur at the message level. These usually include

business logic and task execution order, and they can span applications and

organizations to define a long-lived, transactional, multi step process model.

Orchestration always represents control from one government entity perspective. This

differs from choreography, which is more collaborative and allows each government

entity to describe its part in the interaction.

Choreography tracks the message sequences among multiple parties and sources

typically the public message exchanges that occur between Web services rather than

a specific business process that specific government entity executes.

Common Business Processes

Common Processes are those which are executed by other government entities as

well. The e-government experience revealed that these processes are executed at

each entity having different business rules (discretionary, as defined by policy

guidelines). Also, while executing these processes, the workflow in some entities also

differs due to nature of entity. In this connotation, it is worthwhile to mention here the

practical example of e-office suite of applications developed for Federal Government

of Pakistan. It includes Internal Communication and Movement of Files, HR,



Budgeting, Project Management, Inventory, Procurement. These application /

business processes usually touch the boundary of core processes of the entities. In

this regard, the integration between both of these common and core processes is

done using the concepts of orchestration and Choreography.

Guidelines for Business Architecture

• Adaptation of Standards (Please refer to eGIF) to improve the ability to access,

share and re-use information.

• Strict compliance to Data standards (Please refer to eGIF) to ensure that

information and data can be shared.

• Business processes must be driven by Business modeling documents.

• Sharing of business processes across boundaries should promote trust,

confidence and security of data.

• Sequence of steps to facilitate Business Interoperability must be listed in light of

Choreography & Orchestration, defined above.

1.2 Service Exchange Architecture

The Service Exchange Architecture (SEA) is a second layer in common reference

model of GoP Architecture which shows different system components and their

relevant services.

Actually SEA is strongly based on Business Process Architecture because initially the

business requirements define the service(s) and the service(s) in its turn defines any

required technology support. In this context, it is extremely important that the services

(derived from Business Processes) must have capability to be executed independently

without unnecessarily and adversely affecting the relevant business processes.



Challenges to develop / implement the Service(s)

• The services should be developed using while keeping the perspective of

government processes’ execution along with citizens’ interactions with

Government. The focus must be seamless service delivery to citizens.

• Services must be loosely coupled with the underlying technologies i.e. these

should not be dependent upon any technologies. This is important to ensure

the mitigation of the risks and reduction of costs associated with technology

changes.

• In most of the cases, the services are usually cross entity specific. This means

it might involve number of entities involved in providing the service(s) to

citizens. Thus, it must be taken in account that all the stakeholders providing

the inter-linked service must have enough knowledge (training & expertise) to

execute the underlying business process without much hassle.

• The interoperability approach must ensure that government services are

presented to consumers in a consistent and cohesive manner.

• Services must be able to deal with partially completed transactions. For

example where a sub-service or information source is not available during the

course of a transaction, then the service must maintain its persistence till the

completion of transaction.

• Service Components

Following are two major types of service components is SEA:

o Fine Grained Components / Services

These types of components contain the atomic services / fine grained services. Actually these services are a piece of software that typically is not subject to decomposition analysis activities and its business or technological functionality does not justify break down into smaller components.



Example: Validation of NADRA CNIC by Bank, updated information of stock

from Stock Exchange.

o Coarse Grained Components / Services

Coarse grained components comprise of composite service. A composite

service structure aggregates smaller and fine-grained services.This

hierarchical service formation is characteristically known as coarse-grained

entity that encompasses more business or technical processes. A composite

service may aggregate atomic or other composite services

Example: Application for credit card, hotel booking, e-ticketing etc.

Comparison between Fine-Grained and Coarse-Grained Service Components:

Guidelines for Services Exchange Architecture

• Service(s) should be highly synchronized with business processes. The

alignment of service(s) with technological capability rather than with business

requirements always leads to significant risk due to constant and rapid

advances in technology.



• Universal Description, Discovery Integration (UDDI) based design of services

are always preferable because the externally visible characteristics of

services (for example, inputs, outputs, function, performance, etc.) will need

to be published (in the service catalogue at a minimum) to services users

(current and potential).

• The service architect must understand the active relationships between the

needs of the business and the available services, as well as the technical

details that offer the layer of abstraction required by interoperable services.

• Standards defined in eGIF vis-à-vis SOAIF must be ensured.

1.3 Application Architecture

The application architecture defines the applications required for e-enablement

of business processes and development of e-services. It also includes the

technological supporting capabilities for managing the data and information

needed to support business objectives vis-à-vis efficiency, and performance.

This is in fact the building block of how the different technological nodes will

interact with each other while conforming to the Business Process and Service

Exchange architecture, mentioned above. It facilitates the IT Managers in

deploying different systems having multiple components e.g. View / UI,

Application Logic, Data Access etc.

The following diagram exemplifies the application architecture.



• Components Following are the major components of application architecture:

o View / UI Component:

This component is the front of any application and it interacts with end

users. It should separate all the business information from application

logic component and data transfer object component.

o Application Logic Component:

This component contains all the information related to the business logic.

It gathers all the subsystems that meet the needs of a particular



business domain. If there is any change in the UI component there is no

need re-compile the application logic component.

o Data Access Component:

Data access component will perform the data fetch, data manipulation,

data modification with the database. This component will directly interact

with the database and the application logic component.

Guidelines for Application Architecture

• All above mentioned application architecture components must be loosely

coupled.

• All the validation checks, alerts will be generated on the client side of the

application.

• Web service layer should be separate layer and it should reside in between

the presentation layer and business layer.

• The use of Object Oriented Programming must be adopted while writing the

Application Logic.

• All the business components, developed in the application logic should be

mapped to database entities.

In order to cut the cost of duplication, the concept of Commercial off the Self (COTS)

components (to ensure reusability, integration, consolidation) Collaboration,

interoperability aspects) must be adopted while writing the application logic.

• The Database tier must include the things like query optimization, indexing,

etc.

• One should avoid adding the core business logic while writing the stored

procedure in this tier.

• In order to ensure robustness, universal technology (e.g. Hibernate) must be used to allow transparent persistence that enables the applications to switch to any database. The idea is to simply replace the database and



adjust the applicable portions of the integration tier to query the new database.

1.4 Technology Architecture

The technology architecture defines the platforms needed to provide a technological

infrastructure for the applications that manage the data and support the business

functions.

Guidelines for Technology Architecture

• The Technology Evolution Plan also outlined how, over time, existing

technology would be decommissioned once the new capabilities were in

place and established.

• Technology Evolution plan should be established.

• New technology introduced included Web Service development tools and

adapter frameworks, a global service directory and a global service

management platform for monitoring, configuration management / version

control as well as managing and enforcing the policies to be applied to

Shared Services at runtime (e.g. security, failover, quality of service).

• “Proof of concept” will be adopted as best practices.

• SOA standards and policies, as well as the roles, responsibilities and

processes that had been put in place, the steps undertaken included:

Selecting a candidate Shared Service, given the characteristics identified for the first level of adoption (e.g. Information service type, low complexity).

Analyzing the potential consumers of the selected service to derive

the nature of the operations to be supported.

Defining and validating the WSDL interface for the Pilot Shared

Service.

Defining and gaining approval for the technical architecture

supporting the Pilot Shared Service.



Implementing and testing the Pilot Shared Service based on the

software design patterns and guidelines from the SOA standards and

policies.

Publishing the Pilot Shared Service interface to the Global Service

Directory and deploying the Service Implementation into production,

ready for provisioning to Service Consumers.

Defining the management policies to be associated with the migrated

integration solutions.

Modifying the migrated integration solutions to consume the Pilot

Shared Service and testing them in a QA environment..

Deploying the migrated integration solutions into production and

provisioning them as consumers of the Pilot Shared Service in

accordance with the defined management policies.

2 PRE-DEVELOPMENT STANDARDS

The e-government projects mainly focuses towards automation of common and core

processes of each entity. Common are those which are executed by other government

entities as well. These may include HR, Budgeting, Project Management, Inventory,

Procurement etc. while core processes are those which are only executed by a certain

agency. These usually include some services to citizens, businesses and employees.

Examples are Management of Title Deeds, Issuance of various Licenses e.g. Driving,

Issuance of various certificates e.g. Domicile, Birth etc.

Besides these, there are certain processes which fall in between the category of

Common and Core. Examples are: Complaint Management System, Library Books

Management System etc. In these processes the basic commonality usually exists

however the activities of escalation usually differs at large.

In this scenario, it is utmost important to comprehend the as-is processes initially

before automating the same. This exercise also provides an opportunity to carry out

the rigorous analysis before automating the processes. In this regard, it is important to



understand the Process first and then differentiate between Process efficiency and

Process effectiveness as these both are the main requirements of e-government.

Process is set of activities those are performed together to turn inputs into a product or

service output. Process Efficiency means doing the things right; in this context,

comprehending the as-is processes and automating the same may help in achieving

the goal of efficiency. This phenomenon is also known as Business Process

Management (BPM).

Process Effectiveness means doing the right things; in this context, comprehending

and as-is processes, analyzing those in order to eliminate the non-value added

activities; then automating the same may help in achieving the goal of effectiveness.

This phenomenon is also known as Business Process Reengineering (BPR).

However, these two terms (BPM & BPR) are sometimes used interchangeably.

In order to increase efficiency and effectiveness, the basic course of action is to model

the business processes so as to understand the situation very carefully before moving

forward.

2.1 Business Process Modeling

The business model is a conceptual tool that contains a certain set of notations and

their relationships for expressing the business logic (including set of process activities)

of a certain organization. Business model also present and evaluate value of services

that organization can offer to all stakeholders. Actually the term business model

describes a broad range of informal and formal models that are used by enterprises to

represent various aspects of business, such as operational processes, organizational

structures, etc.

The primary goal of BPMN is to provide a notation that is readily understandable by all

business users, from the business analysts that create the initial drafts of the

processes, to the technical developers responsible for implementing the technology

that will perform those processes, and finally, to the business people who will manage



and monitor those processes. Thus, BPMN creates a standardized bridge for the gap

between the business process design and process implementation.

From E-Government point of view, there are two important goals for the business

process modeling:

• The notation used in modeling the processes should be readily understandable

by the analyst that create initial drafts of the processes, and by the employees in

the government who manage and monitor those processes.

• The used notation should be easily transformed into a business process

modeling language

Modeling Practices

Each Business Process can be categorized as Internal to an organization

(private), public (having some process interfaces with outside of organization) or

collaborative (major process interactions exist between internal and external

organizations).

Private Processes: These processes are actually internal business process of a

certain specific governmental organization. In general, these processes are called

as organizational workflows.

Public Processes: This type of modeling represents the interactions between a

private business process and some process outside organization. It should be

noted that only certain process are allowed to communicate outside organization.

Further more appropriate flow control mechanisms, should be established during

modeling of public process. All other “internal” activities of the private business

process may not be shown in the public process.

Collaborative Processes: A collaboration process depicts the interactions between

two or more business entities. These interactions are defined as a sequence of



activities that represent the message exchange patterns between the entities

involved.

Standard To Follow

BPMN 1.x should be adopted as standard for

modeling the business processes. Minimum set of

Business Process Modeling Notations as per

BPMN 1.0 standards is available in Appendix A

to prepare the Business Process Diagram (BPD)

While developing the above processes using

BPMN 1.x, it is entirely necessary that all the

processes (Private, Public or collaborative) may

be mapped according to collaboration languages /

guidelines of following:

ebXML BPSS,

or the resultant specification from

the W3C Choreography Working

Group.

Note: All above must conform the standard of

Business Process Execution Language (BPEL)

2.2 Steps - Business Process Modeling

The Business Process Modeling will be performed using following steps:



2.2.1 As-Is Model The first stage in business process modeling is to study the existing business

environment and designing of the business process. Actually through “as-is” model,

current process of organization are converted into some black and white form.

Following points should be considered in development of “as-is” model:

• Describe the boundaries of different processes to define their respective input

and outputs. In this regard, it is required that the as-is processes may be

mapped using Swim lanes.

• Determine the few big chunks that the process can be divided into sub-process

that make intuitive sense.

• Map the different sub-processes and activities of a process that specifies the

tasks which are performed.

• Describe the Processes’ activities in Detail.

• Map all the process case that occurs most commonly. Determine the % age of

occurrence.

• Map all the process cases that would appear to cause the most problems or

time delays Determine the %age of occurrence.

• Exceptional Process case may also be mapped.

• List down policies, rules, regulations, guidelines etc. under which the processes

are executes. Exceptions during flow should also be considered.

• Identify the Resources (human, and non human) available to perform various

tasks.

• Identify bottlenecks (issues and problems) associated with the process.

• Identify and document the minimum / maximum Effort time, Cycle time, waiting

time, for each process / sub-process / activity.

2.2.2 Process Analysis



It becomes very necessary for every organization to judge its performance against its

potentials. From the government driven requirement engineering approach, the process

analysis is necessary to be conducted to make the process more efficient and effective.

This will provide an opportunity to enhance the service delivery to all stakeholders while

achieving the target of good governance.

The process analysis involves the assessment of various scenarios through such

documentation that contains information about the variance between improved service

delivery and organizations’ potentials. The proper conduction of process analysis will

help the organization in developing to-be process for increasing the efficiency,

effectiveness and responsiveness.

In this regard, it is entirely necessary that following approaches of Process Analysis

may be considered:

Strategic: This approach deals with aligning the processes and procedures with overall

strategy. In order to analyze a process from a strategic point of view, it is important to

get the ‘information’ required to test a process’s alignment to the overall business

strategy. This is achieved by finding out the BPR proposal / directive from the top

management, which is mostly reflecting the business strategy, case for action.

Operational: This approach deals with internal optimization of process. While analyzing

a process from an operational point of view, following must be considered:

• Evaluate the efficiency and effectiveness of the current process.

• Identify key departments / positions involved in execution.

• Span of management control (different levels of approvals).

• Look at the different steps (activities) within the process and identify

delays within the process.

• Question everything about the process – what is being done, why it is

being done, how it is being done etc.



2.2.3 To-Be Model To-be model is actually based upon the understanding of as-is processes and

process analysis This model comprise of new business processes which should be

adopted by organization in order to avoid drawbacks and bottle necks in exiting

scenarios.

Following points should be considered in the development of to-be models:

• More Efficient.

• More Responsiveness.

• Service oriented; focus on providing high quality services that serve in

best interest of all stakeholders e.g. citizens, employees, management

etc.

3 Services Engineering Services are discrete units of functionality which can be utilized to perform specific

tasks or activities. These services may be manual or IT-specific and they support

activities within a business process. Different business processes may consume

some service components which are common with other business processes, and

others that are unique to that process.

Understanding the linkage between activities within a business process and the

services which support them can enable the identification of common services.

These common services can provide opportunities between agencies or across

business units to develop re-usable service components or shared service

arrangements, thereby reducing duplication and promoting standardization.

Business processes which support the core business function of an agency will

tend to be more specific and will present less opportunity for standardization.

However, even within core business processes, there may be opportunities to

utilize common service components.

Often, these common or more generic elements will be found at the more ‘external

facing’ ends of a process. Also, there is often a greater drive for standardization of



these external interfaces to streamline transactions with other agencies,

businesses or citizens.

The following diagram illustrates the link between services and processes, the

difference between common or generic services and unique or specific services

and where they are more likely to reside.

Agencies offering services to citizens that require application and registration, such

as applying for a grant or other forms of financial assistance, registering a birth or

registering a new company, could potentially utilize common application and

registration services provided by another agency as a shared service or as

outsourced to an external third party.

Services

Agencies will deliver a range of services that can be grouped into one of the

following three services groups:

• Information – Includes the provision of information such as

performance data, financial reports, press releases, policies etc.

• Interaction – Two-way communication between agencies and

a customer that does not result in a change of account details or

status (e.g. enquiries, technical advice and feedback).

• Transaction – Results in a change of a customer’s account

details or status (e.g. payment of benefits, submission of tax

returns, registration).

Review services

Assessment services

Outbound services Inbound services



Detail strategy There are three stages of evolution towards a networked or integrated service

delivery: Stage 1 – represents silo-based approaches, where customers, information,

access, distribution and governance Models are owned and controlled by a single

Agency Service improvement or collaborations generally arise opportunistically

through agency initiatives.

Stage 2 – is evidenced by ad hoc collaboration between agencies and some

sharing of infrastructure. Although Information and capability is still agency-based

variable governance arrangements and inconsistent customer Experience exists.

Stage 3 – Reflects a service delivery network and a whole of government service

delivery environment based on the premise of ‘standardize’ not ‘centralize’. Culture

change involving innovative planning and a collaborative multi-agency customer-

centric (networked) service delivery.

SERVICE DESIGN GUIDELINES

The following two principles serve as the foundation guidelines for service design in

the domain of GoP.

Service Coupling

Service coupling refers to the degree of interdependence between business

processes or Web services. The design objective is to minimize coupling, that

is, to make business processes as self contained as possible by ensuring they

need virtually no knowledge or service of any other business processes, thus

increasing their maintainability and reuse potential.

The coupling should be considered in following forms:

Representational coupling:



Business processes should not depend on specific representational or

implementation details and assumptions underlying business processes.

That is, business processes do not need to know the scripting language

that was used to compose their underlying services. Representational

Coupling is useful for supporting:

Interchangeable / replaceable services:

Existing services can be swapped with new service

implementations.

Multiple service versions:

Different versions of a service should be available to work with

different parts of a business processes depending on the

application’s needs.

Identity coupling:

Connection channels between services should be unaware of who is

providing the service.

Communication protocol coupling:

The number of messages exchanged between a sender and addressee

in order to accomplish a certain goal should be minimal. The service that

performs such an operation sums nothing about the consequences of

sending the message.

Service Cohesion Defines the degree of strength of functional relatedness between operations in

a service or business process. The service aggregator should strive to offer

cohesive (autonomous) processes whose services and service operations are

strongly and genuinely related to one another.



The following guidelines should be observed to achieve better cohesion.

The services should be functionally cohesive i.e. should perform one and

only one problem-related task and contain only services necessary for

that purpose.

A logically cohesive service is a one that performs a set of independent

but logically similar functions (alternatives) that are tied together by

means of control flows, such as mode of payment.

Recommended service development life cycle for GoP

The service-oriented service development life cycle is comprised of five instinct

phases. The recommended approach is incremental and iterative in nature and

can accommodate revisions in situations where the scope cannot be

completely defined a priorities.

This approach allow GoP vendor continuous invention, discovery and

implementation with each iteration, forcing the development team to drive the

software development artifacts closer to completion in a predictable and

repeatable manner.

1. THE PLANNING PHASE

Planning sets the scene for all ensuing phases by analyzing the business case

for all feasible combinations of development approaches and realization

strategies.

The following option can adopted in order to develop new services.

i. Green-field development:

Follows a classical development model covering specification down to

development, with this option we assume that the services must be



developed from scratch without any reuse of existing process chunks or

service specifications.

ii. Top-down development:

Usually a blueprint of business use cases provides the skeleton

specification for business services. The top-down process decomposes

the business domain into its functional areas and subsystems, including its

flow or process decomposition into processes, sub-processes and high-

level business use cases.

iii. Bottom-up development:

Starts from existing enterprise applications and repositories and

transforms them to new services by wrapping.

iv. Out-of-the-middle development: Combines top down and bottom-up development by allowing service

aggregators to select those fragments of enterprise resources that best

satisfy new business process requirements. Fragments are then retrofitted

using services.

Realization strategies Following realization strategies are recommended for constructing web

services in GoP projects.

Reuse existing (internal) Web services or business process logic.

Develop new Web services logic from scratch.

Refurbish existing components or existing (legacy) systems in Web

services or business processes.

2. SERVICE AND PROCESS ANALYSIS AND DESIGN PHASE



Service analysis aims at identifying, conceptualizing, and rationalizing

business processes as a set of interacting Web services. This step is

logically succeeded by service design, during which conceptual processes

and services are transformed into a set of related, platform - agnostic

interfaces.

Following are the recommended steps for this phase:

• Service interfaces should be identified in the problem domain by

carving out and grouping service capabilities based on service

coupling and cohesion criteria.

• Recommended standard for specifying services is XML-based Web

service definition language (WSDL).

• Determine style of service composition. Following two composition

styles are recommended in the context of GoP services.

o Orchestration Orchestration describes how Web services can interact

with each other at the message level, including the

business logic and execution order of the interactions from

the perspective and under control of a single endpoint.

Orchestration is recommended composition style for

internal business processes with tightly coupled internal

actors, while choreography is typically chosen for

developing cross-organizational business processes

between loosely coupled partners.

o Choreography Choreography is typically associated with the public

(globally visible) message exchanges, rules of interaction

and agreements that occur between multiple business

process endpoints, rather than a specific business process



that is executed by a single party. Choreography is more

collaborative in nature than orchestration.

Choreography is recommended composition style for

developing cross-organizational business processes

between loosely coupled partners.

• The fourth step during service design is to identify responsibilities

associated with business process activities and the roles that are

responsible for performing them. Roles may invoke, receive and reply

to business activities. The result of this step actually constitutes the

foundation for implementing business policies, notably role-based

access control and security policies.

• Identification of “non-functional service concerns” i.e. A service

development methodology must go far beyond ensuring “simple”

functional correctness, and deal with non-functional process design

concerns including performance, payment model, security model,

and transactional behavior.

SLAs provide a proven vehicle for not only capturing non-functional

requirements but also for monitoring and enforcing them SLAs are special legal

agreements that encapsulate multiple concerns, and symmetrically fuse the

perspective of service supplier and customer.

3. THE CONSTRUCTION AND TESTING PHASE

Once the service and process specifications have reached a steady state, they

need to be transformed into service implementations and subsequently

validated and verified against business service and process specifications.

Business process realization typically adopts a virtualized development model.

This activity encompasses two broad steps: code Web services and code

business processes.



Code Web services.

Web services that were specified in WSDL may be programmed with any

preferred programming language as long as the language is capable of

supporting WSDL’s protocol bindings, including XML-RPC and SOAP.

Code business processes.

Once the Web services have been codified, the flow logic that is comprised in

the BPEL specification is compiled and injected into a BPEL execution engine.

As a preparatory step, the business process is revamped as a coarse-grained

asynchronous operation, which is, like any other service, defined in WSDL.

4. THE DEPLOYMENT PHASE The tasks associated with the deployment phase of the Web service

development life cycle include the following three steps:

• Publish the service interface. The publish operation is an act of service

registration or service advertisement, such as using the Universal Description,

Discovery and Integration (UDDI) protocol. It acts just like a contract between

the service registry and the service provider.

• Deploy the Web service and business process. The runtime code for the

service and process and any deployment meta-data that is required to run it are

deployed during this step.

• Publish service implementation details. The service implementation

definition contains the definition of the network-accessible endpoint(s) where

the Web service can be invoked.

5. THE EXECUTION AND MONITORING PHASE During this phase, the business processes and supporting Web services are

fully deployed and made operational. By doing so, a service requestor can find

the service definition and invoke all defined service operations. Also, the

progress of running business processes can be monitored. For the time being



only reactive monitoring mechanisms are in place. Behaviors towards legacy

systems.

Service-oriented Architecture (SOA) is believed to be the most efficient

integration concept to overcome the complexities of binding legacy systems.

The biggest advantage offered by SOA is functionality reuse through service

enabled applications. This helps engineers to reconfigured existing legacy

systems in order to support new technology. However some problem still need

to be resolved like legacy systems usually follows proprietary standards. This

often creates the semantic discrepancy between them and other applications.

Second, business logics and functionalities with legacy systems are usually

tightly coupled. Exposing useful business processes and logics through web

service in SOA environment requires carefully design with consideration of

service granularity and interaction.

Important Considerations

The following are some important considerations for integrating legacy systems

with new applications.

Is it technically feasible to create a service from the legacy system or

part of the system? Analysis of feasibility should consider factors such

as tool availability, documentation of legacy assets, and needed

technical and domain expertise.

How much would it cost to expose the legacy system as services?

Is this cost, plus the cost of maintaining the existing legacy system, more

than the cost of replacing the legacy system with a new one?

What changes will have to be made to legacy systems in order to use

these services?

Such changes can include restructuring of business logic and user

interface layers, different management of data (particularly for ensuring



data persistence) and modification to calls to components that will

become services.

How much will these changes affect the current end users of the legacy system and

other dependent production systems?

Recommended standards

Web Services are fundamentally based on a small number of widely accepted

standards, namely XML and XML Schema, SOAP, and WSDL

These standards allow developers to specify the operations that a service provides as

well as the inputs and outputs of these operations. Using these standards helps

service consumers represent data in a form that is understood by service providers

and vice versa. The goal of these standards is to ensure that Web Services, tools, and

runtime environments interoperate across vendors and organizations. Service

providers as well as vendors of Web Service-related tools and infrastructure products

adhere to these standards, which should make it possible for services to be platform-

independent.

However, there are many areas in which these standards are vague or too general to

assure syntactic interoperability on their own. In short, Web Services enable syntactic

interoperability, but do not guarantee it. The Web Services Interoperability

Organization (WS-I) provides guidance on the usage of Web Services standards.

Established in early 2002, WS-I is an open industry effort chartered to promote Web

Services interoperability across platforms, applications, and programming languages.

One of its deliverables is the Basic Profile, which is a set of non-proprietary Web

Service specifications that promote interoperability [4]. The idea behind the Basic

Profile is to provide clarifications, refinements, interpretations and amplifications in

areas of the standards that are subject to multiple interpretations. The most important

interoperability issues at the SOAP / WSDL level are well-understood and

documented.



Recommended Web Service standards fall into three broad categories.

1. Basic infrastructure HTTP, XML, XML Schema, SOAP, WSDL, UDDI.

2. Service composition WSCL, WS-Coordination, BPEL, WS-I basic profile 1.1

3. Cross-cutting standards WS-Security, SAML, WS-Transaction, WS-Reliability

4 DEVELOPMENT STANDARDS Once the business processes are modeled, analyzed and new processes are

developed accordingly then effort of automation usually starts. The staring point in this

regard is to gather the functional and non-functional requirements so as to design the

software based upon the business requirements.

In delineating the processes, the process consultant has to focus mainly upon each




most common activities is constitution of committee as per policy of government.

While automating the business process, this activity is usually kept as manual due to

its nature.

These types of considerations play a major role while gathering the functional

requirements in order to develop the robust design of software. Also, this phase of

software is usually felt very important as it is considered as first and most important

building block for any e-government project.

In this regard, the basic course of action is to develop the Software Requirement

Specification (SRS) document. The below material defines the basic structure and

standards to be followed in preparation of SRS for e-government projects.



4.1 Software Requirement Specifications (SRS)

4.1.1 Introduction Introduction includes identification of different subsections of the Software

Requirements Specifications (SRS). It should present an overview of the entire SRS. It

should be noted that as writer of SRS must describe what the system must do – so

that designers can build the system truly using this document.

4.1.2 Purpose In this subsection we identify system whose software requirements are specified in

this document. Revision or release number is also included in this subsection. Scope

of the system should be described by this part of SRS.

Note: The Business Process Model may be reviewed to articulate the purpose of

system.

4.1.3 Document Conventions This subsection contain standards or typographical conventions that were followed

when writing this SRS, such as fonts or highlighting that have special significance.

Following standards must be adopted for document conventions

• Times New Roman will be used as default font.

• Font’s size

o 12 for body text

o 14 bold for main heading

o 12 bold for subheadings.

Moreover priorities among requirements should be indicated exclusively through

numbered list.



4.1.4 Intended Audience and Reading Suggestions

This section will contain the description about the different types of reader for SRS

document such as developers, project managers, users, testers, and documentation

writers etc. It is also necessary to give some details about how the SRS document is

organized.

4.1.5 Scope In this subsection:

• Identify the software product(s) to be produced by name e.g. Title of

Software Module

• Explain what the software product(s) will, and, if necessary, will not do.

• Describe the application of the software being specified, including

relevant benefits, objectives, and goals

• Be consistent with similar statements in higher-level specifications.

4.1.6 Definitions, Acronyms, and Abbreviations

This subsection presents the definitions of all terms, acronyms, and abbreviations

required to properly interpret the SRS. This information may be provided by reference

to one or more appendices in the SRS or by reference to documents.

4.1.6.1 References Reference subsection will focus on following points

• Make available a complete list of all documents which are referenced in

the SRS.

• Reference will be written in following format:

Identification of each document by title.

Report number (if applicable),

Date and publishing organization.



Specify the sources from which the references can be obtained.

Note: This information can be provided by reference to an appendix or to another

document. If your application uses specific protocols, then reference them here so

designers know where to find them.

4.1.7 Overall Description

4.1.7.1 Product Perspective

This section contains the description about the context and origin of the product being

specified in this SRS. For example, state whether this product is a follow-on member

of a product family, a replacement for certain existing systems, or a new system

replacing manual work.

If the SRS defines a component of a larger system, relate the requirements of the

larger system to the functionality of this software and identify interfaces between the

two. A simple component diagrams can show the major components of the overall

system, subsystem interconnections, and external interfaces can be helpful.

Standard To Follow

UML 2.x is standard to document the following

for this section.

• Use case diagram (high level)

• Component diagram

Examples of above diagrams are enclosed as

Appendix B, D.



4.1.7.2 Product Functions

This section will summarize the major functions the product must perform or must let

the end-users to perform. It should be noted that only a high level summary (bulleted

list) is needed here.

Organize the functions to make them understandable to any reader of the SRS. In this

regard all the relevant requirement to one function may be bundled together in a

sensible manner. Specifically, a picture of the major groups of related requirements

and how they relate is required here.

Standard To Follow


for this section.

• Use case diagram (in context of

packaging the requirements)

• Activity diagram

• Sequence diagram

Examples of these diagrams are enclosed as

Appendix B, F, G

4.1.7.3 User Classes and Characteristics

Identify the various user classes that you anticipate will use this product. User classes

may be differentiated based on frequency of use, subset of product functions used,

technical expertise, security or privilege levels,. Describe the pertinent characteristics

of each user class. Certain requirements may pertain only to certain user classes.



Standard To Follow


for this section.

• Class diagram

Examples of these diagrams are enclosed as

Appendix C.

4.1.7.4 Operating Environment

Describe the environment in which the software will operate, including the hardware

platform, operating system and versions, and any other software components or

applications with which it must peacefully coexist.

Standard To Follow Following two standards are recommended for

this section

• Guidelines developed using POXIS

<Under Development>

• Deployment diagram of UML 2.x

Details of these standards can be found at

Appendix E.

4.1.7.5 Design and Implementation Constraints

Describe any items or issues that will limit the options available to the developers.

These might include: corporate or regulatory policies; hardware limitations (timing

requirements, memory requirements); interfaces to other external applications;



specific technologies, tools, and databases to be used; parallel operations; language

requirements; communications protocols; security considerations, etc.

Standard To Follow Extensibility Mechanisms of UML 2.x must be

adapted as standards to describe constrains /

limitations, behaviors etc. Specifically, while

producing the Class Diagram, Component

Diagram, Deployment Diagram mentioned

above. The following extensibility of UML 2.x

must be incorporated

• Stereo types

• Constraints

• Tag values

4.1.7.6 Assumptions and Dependencies

List any assumed factors that could affect the requirements stated in the SRS. These

could include third-party or commercial components that you plan to use. The project

could be affected if these assumptions are incorrect, are not shared, or change. Also

identify any dependencies the project has on external factors, such as software

components that you intend to reuse from another project.

Standard To Follow Following are recommended as standard for

this section.

• Issue Card

• Factor Table

Details of these standards are enclosed at

Appendix H.



4.1.7.7 External User Interfaces

4.1.7.7.1 User Interfaces

Describe the logical characteristics of each interface between the software product

and the users. This may include sample screen images, product family style guides

that are to be followed, screen layout constraints, standard buttons and functions (e.g.,

help) that will appear on every screen, keyboard shortcuts, error message display

standards, and so on.

Standard To Follow Following are recommended as standard for

this section.

• Microsoft GUI Standard

• SUN GUI Standard

4.1.7.7.2 Hardware Interfaces

Describe the logical and physical characteristics of each interface between the

software product and the hardware components of the system. This may include the

supported device types, the nature of the data and control interactions between the

software and the hardware, and communication protocols to be used.

4.1.7.7.3 Software Interfaces

Describe the connections between this product and other specific software

components (name and version), including databases, operating systems, tools,

libraries, and integrated commercial of the shelf components (COTS). Identify the data

items or messages coming into the system and going out and describe the purpose of

each. Describe the services needed and the nature of communications. If the

documents describe detailed application programming interfaces protocols. Identify

data that will be shared across software components.



Standard To Follow

UML 2.defacto x is standard for this section

along with following elements.

• Ports

• Protocols

4.1.7.8 System Features

The following template will be used as Standard for organizing the functional

requirements for the product by system features, the major services provided by the

product. It may be preferred to organize this section by use case, mode of operation,

user class, object class, functional hierarchy, or combinations of these, whatever

makes the most logical sense for the product.

4.1.7.8.1 System Feature 1

State the feature name in just a few words.

4.1.7.8.1 Description and Priority

Provide a short description of the feature and indicate whether it is High, Medium, or

Low priority.

4.1.7.8.2 Stimulus / Response Sequences

List the sequences of user actions and system responses that stimulate the behavior

defined for this feature. These will correspond to the dialog elements associated with

use cases.

4.1.7.8.3 Functional Requirements

Itemize the detailed functional requirements associated with this feature. These are

the software capabilities that must be present in order for the user to carry out the

services provided by the feature, or to execute the use case. Include how the product



should respond to anticipated error conditions or invalid inputs. Requirements should

be concise, complete, unambiguous, and verifiable. Each requirement should be

uniquely identified with a sequence number or a meaningful tag of some kind like

REQ-1:

REQ-2:

4.1.7.8.4 System Feature 2 (and so on)

Please refer Appendix H.

4.1.8 Other Nonfunctional Requirements 4.1.8.1 Performance Requirements If there are performance requirements for the product under various circumstances,

state them here and explain their rationale, to help the developers understand the

intent and make suitable design choices. Make such requirements as specific as

possible. It may be needed to state performance requirements for individual functional

requirements or features.

4.1.8.2 Standards to follow

Standard To Follow Timing Diagram of UML 2.0 is recommended

as standard for this section.

4.1.8.3 Safety Requirements

Specify those requirements that are concerned with possible loss, damage, or harm

that could result from the use of the product. Define any safeguards or actions that



must be taken, as well as actions that must be prevented. Refer to any external

policies or regulations that state safety issues that affect the product’s design or use.

Standard To Follow Following table is recommended as standard for this

section.

Requirement Safeguards Actions to be prevented

4.1.8.4 Security Requirements

<Under Development>

4.1.8.5 Software Quality Attributes

Specify quality characteristics for the product that will be important to either the

customers or the developers. Write these to be specific, quantitative, and verifiable

when possible.

Some to consider are: adaptability, availability, correctness, flexibility, interoperability,

maintainability, portability, reliability, reusability, robustness, testability, and usability.

Standard To Follow

Following table is recommended as standard for this section.

Quality Attribute

Description

Adaptability Availability Correctness Flexibility Interoperability Maintainability Portability Reliability Robustness



Usability

4.1.8.6 Other Requirements

Define any other requirements not covered elsewhere in the SRS. This might include

database requirements, internationalization requirements, legal requirements, reuse

objectives for the project, and so on. Add any new sections that are pertinent to the

project.

4.2 Software Design Document (SDD)

4.2.1 Introduction

It is a representation of a software system created to facilitate analysis, planning,

implementation, and decision making. It is also called as blueprint or model of the

software system. The SDD is used as the primary medium for communicating

software design information.

This document is recommended as a standard practice for describing software

designs for e-government software projects. The SDD for e-government projects is

also based on open source Unified Modeling Language. It does not support nor it is

limited to any particular descriptive technique.

4.2.1.1 Purpose

In this subsection we identify system whose design has been specified in this

document. Revision or release number is also included in this subsection. It should be

noted that as writer of SDD must describe how the system perform different

functionalities which are designed against requirements specified in SRS.



4.2.1.2 Document Conventions

This subsection contain standards or typographical conventions that were followed

when writing this SDD, such as fonts or highlighting that have special significance.

Following standards must be adopted for document conventions:

• Times New Roman will be used as default font.

• Font’s size.

12 for body text

14 bold for main heading

12 bold for subheadings

4.2.2 Intended Audience and Reading Suggestions

This section will contain the description about the different types of reader for SRS


writers etc. It is also necessary to give some details about how the SRS document is

organized.

Scope

In this subsection:

• Identify the different design entities and describe the important

properties and relationships among those entities.

• Match / Trace the different requirements gathered during SRS with

design entities.

Definitions, Acronyms, and Abbreviations


required to properly interpret the SRS. This information may be provided by reference

to one or more appendices in the SRS or by reference to documents.



References

A list of referenced and / or related publications used for preparing the SDD must be

incorporated in this subsection.

Considerations for producing an SDD

This section provides information that should be considered before producing an SDD.

The information will describe how the SDD fits into the software life cycle, where it fits,

and why it is used is discussed.

4.2.3 Software life cycle

The life cycle of a software system is normally defined as the period of time that

starts when a software product is conceived and ends when the product is no longer

available for use. The life cycle approach is an effective engineering management

tool that provides a model for a context within which SDD is the world class approach

to model the blueprint. While it is beyond the scope of this document to prescribe a

particular standard life cycle, a typical cycle will be used to define such a context for

the SDD. The software life cycle mentioned in this document conforms to IEEE / EIA

12207.1-1997 that includes inception, elaboration, testing and transition phases.

For both new software systems and existing systems under maintenance, it is

important to ensure that the design and implementation used for a software system

must satisfy the requirements (gathered during SRS) driving that system. SDD will

be carried out during the elaboration phase.

4.2.4 System Overview

In this section, focus should be to provide a general description of the software

system including its functionality and matters related to the overall system and its

design.



Standard To Follow

Following diagram of UML 2.x is recommended as

standard for this section.

• Package diagram


Design Considerations

This section describes many of the issues which need to be addressed or resolved

before attempting to devise a complete design solution.

Assumptions or Dependencies

Describe any assumptions or dependencies regarding the software and its use.

Standard To Follow



• Class diagram with special emphasis on

Dependency relationships


General Constraints

Describe any global limitations or constraints that have a significant impact on the

design of the system's software (and describe the associated impact). Such

constraints may be imposed by any of the following:



i. Hardware or Software environment

Any constraint which should be imposed due to hardware or software issues

like development of design for some particular hardware platform or operating

system.

ii. End-user Environment

From the business modeling and SRS, the end-user environment is thoroughly

analyzed. These constraints are derived from this study like user friendliness

issue of system.

iii. Availability of resources

These constraints are directly related with availability of resources. For example

availability of technical expertise, budget etc.

iv. Interoperability Requirements

Interoperability is one of prime requirements for e-government projects.

Consideration of other systems (with which system will work) is very necessary

because system will not work in collaborative environment if this aspect is

ignored.

v. Security requirements (or other such regulations)

In the light of security requirements constraints, the necessary information

needs to be supplied here.

vi. Performance requirements

Constraints for regarding performance issues must formulize and followed for

example response time issues etc.



Standard To Follow



• Class Diagram

• Component Diagram

• Deployment Diagram

• State Machine mechanism of UML 2.x

4.2.5 Architectural Strategies

Describe any design decisions and / or strategies that affect the overall organization of

the system and its higher-level structures. These strategies should provide insight into

the key abstractions and mechanisms used in the system architecture. Describe the

reasoning employed for each decision and / or strategy (possibly referring to

previously stated design goals and principles) and how any design goals or priorities

were balanced or traded-off.

Make effective use of factor table and issue cards already developed in SRS. Such

decisions might concern (but are not limited to) things like the following:

• Use of a particular type of product (programming language, database, library

etc.).

• Reuse of existing software components to implement various parts / features of

the system.

• Future plans for extending or enhancing the software.

• User interface paradigms (or system input and output models).

• Hardware and / or software interface paradigms.

• Memory management policies.

• External databases and / or data storage management and persistence.



Make sure that when describing a design decision that you also discuss any other

significant alternatives that were considered, and your reasons for rejecting them.

Sometimes it will be most effective to employ the "standard format" for describing a

strategy.

4.2.6 System Architecture

This section should provide a high-level overview of how the functionality and

responsibilities of the system were partitioned and then assigned to subsystems or

components. Don't go into too much detail about the individual components

themselves (there is a subsequent section for detailed component descriptions). The

main purpose here is to gain a general understanding of how and why the system was

decomposed, and how the individual parts work together to provide the desired

functionality.

Describe how the system was broken down into its components / subsystems

(identifying each top-level component / subsystem and the roles / responsibilities

assigned to it). Describe how the higher-level components collaborate with each other

in order to achieve the required results. Feel free to make use of design patterns,

either in describing part of the architecture or for referring to elements of the

architecture that employ those.

Standard To Follow Following diagram of UML 2.x is recommended as


• Class diagram



• Extensibility Mechanisms of UML 2.x



4.2.6 Sub-system Architecture

If a particular component is one that merits more detailed discussion than what was

presented in the System Architecture section need to be incorporated in a subsection of

the System Architecture section (or it may even be more appropriate to describe the

component in its own design document). If necessary, describe how the component was

further divided into subcomponents, and the relationships and interactions between the

subcomponents.

If the component is very large and / or complex, you may want to consider documenting

its design in a separate document and simply including a reference to it in this section.

Detailed System Design

Most components described in the System Architecture section will require a more

detailed discussion. Other lower-level components and subcomponents may need to be

described as well. Each subsection of this section will refer to or contain a detailed

description of a system software component. The discussion provided should cover the

following software component attributes:

4.2.7 Classification

The kinds of components, such as a subsystem, module, class, package, function, file

etc.

4.2.8 Definition

The specific purpose and semantic meaning of the component.

4.2.9 Responsibilities

The primary responsibilities and / or behavior of this component. What does this

component accomplish? What roles does it play? What kinds of services does it provide

to its clients? For some components, this may need to refer back to the requirements

specification.



4.2.10 Constraints

Any relevant assumptions, limitations or constraints for this component, this should

include constraints on timing, storage or component state and might include rules for

interacting with this component (encompassing pre-conditions, post- conditions,

invariants other constraints on input or output values and local or global values, data

formats and data access, synchronization, exceptions etc.).

4.2.11Composition

A description of the use and meaning of the subcomponents that are a part of this

component.

4.2.12 Uses / Interactions

A description of these components collaborations with other components. What other

components do this entity use (this would include any side-effects this entity might have

on other parts of the system)? This concerns the method of interaction as well as the

interaction itself. Object-oriented designs should include a description of any known or

anticipated subclasses, super classes, and Meta classes.

4.2.13 Resources

A description of any and all resources that are managed, affected, or needed by this

entity. Resources are entities external to the design such as memory, processors,

printers, databases, or a software library. This should include a discussion of any

possible race conditions and / or deadlock situations, and how they might be resolved.

4.2.14 Processing

A description of precisely how this component goes about performing the duties

necessary to fulfill its responsibilities. This should encompass a description of any

algorithms used; changes of state; relevant time or space complexity; concurrency;

methods of creation, initialization, and cleanup; and handling of exceptional conditions.



4.2.15 Interface / Exports

The set of services (resources, data types, constants, subroutines and exceptions) that

are provided by this component. The precise definition or declaration of each such

element should be present along with comments or annotations describing the

meanings of values, parameters etc.

Standard To Follow Following diagrams of UML 2.x are recommended

as standard for this section.

• Class diagram


• State Machine mechanism of UML 2.0

4.2.16 Detailed Subsystem Design

Provide a detailed description of this software component. Complex diagrams showing

the details of component structure, behavior, or information / control flow may be

included in the subsection devoted to that particular component, unless they are very

large or complex, some of these diagrams might be more appropriately included in the

System Architecture section. The description should cover any applicable software

component attributes.

Standard To Follow Following diagram of UML 2.x is recommended as


• Class diagram





5 IMPLEMENTATION STANDARDS

5.1 Introduction

Introduction includes identification of different subsections of the Implementation

document. It should present an overview of the entire document. It should be noted that

writer this document must describe how the system must will be implemented.

Purpose

In this subsection system must be identified which is going to be implemented. Revision

or release number is also included in this subsection. Scope of the system should be

described by this part of document.

Document Conventions

This subsection contains standards or typographical conventions that were followed

when writing implementation document, such as fonts or highlighting that have special

significance.

Following standards must be adopted for document conventions

Times New Roman will be used as default font.

• Font’s size

o 12 for body text

o 14 bold for main heading

o 12 bold for subheadings.

Moreover priorities among requirements should be indicated exclusively through

numbered list.

Intended Audience and Reading Suggestions

This section will contain the description about the different types of reader for this




writers etc. It is also necessary to give some details about how the document is

organized.

Definitions, Acronyms, and Abbreviations


required to properly interpret the document. This information may be provided by

reference to one or more appendices in this document or by reference to documents.

References

Reference subsection will focus on following points:

• Make available a complete list of all documents which have been

referenced.

• Reference will be written in following format

Identification of each document by title

Report number (if applicable)

Date and publishing organization.

Specify the sources from which the references can be

Obtained.

Note: This information can be provided by reference to an appendix or to another

document. If your application uses specific protocols then reference them here so

designers know where to find them.

5.2 Software Implementation




software deployment. This document sets out a standard terminology for the various

implementation activities and the entities over which they operate.



As described most of the systems incorporate the concept of a component which is

defined in the UML2.x specification is a modular part of a system that encapsulates its

contents and whose manifestation is replaceable within its environment. Component is

defined to be a unit of composition with contractually specified interfaces and explicit

context dependencies only. A component defines its behavior in terms of provided and

required interfaces. In this context, an assembly is a set of interconnected

components. An assembly can itself be viewed as a component made up of

subcomponents and offering and requiring interfaces. The required interfaces of the

components in an assembly may be satisfied either by other components in the

assembly or be required from the environment in which the assembly is deployed.

Recommended Standard

Service Oriented Architectural implementation

framework (SOAIF) is recommended as

implementation frame work for e-government

systems developed for Government of Pakistan

(GOP).

5.2.1 SOAIF for e-government

Modern e-government systems are built on a service-oriented architecture (SOA)

which is the latest software architecture style to build flexible and extensible

applications. OASIS describes SOA as “a paradigm for organizing and utilizing

distributed capabilities that may be under the control of different ownership domains”.

It provides a uniform means to offer, discover, interact with and use capabilities to

produce desired effects consistent with measurable preconditions and expectations.

Web Services represent a set of de facto SOA implementation technologies, involving

the usage of W3C standards such as WSDL and SOAP for service description and

messaging transport respectively. SOAIF will generate such web services which are

component-based, web-oriented and standard-based.







SOAIF will focus on internal and cross-enterprise processes, helping e-government

streamline operations, reduce costs, and increase responsiveness. Specifically, an

SOAIF provides general purpose, service-based distributed computing capabilities

that deliver:

• Faster response rate to changing business requirements of

e-government.

• Operational efficiencies.

• Faster, less expensive application integration.

• Easier application development and deployment.

5.2.2 Standard Attributes of SOAIF

Following points will act as a standard attribute for SOAIF. It should be noted that

SOAIF in e-government project will be evaluated against these standard attributes.

5.2.2.1 Interoperability

Interoperability refers to the ability of a collection of communicating entities to share

specific information and operate on it according to an agreed-upon operational

semantics. Increased interoperability is the most prominent benefit of SOAIF,

especially when we consider Web services technology in e-government projects.

Today, mainstream development platforms—such as Microsoft’s .NET and Sun’s Java

Platform, Enterprise Edition (Java EE), as well as open source alternatives (e.g., Perl

and PHP)—provide frameworks to implement web services. Service users and

providers implemented in disparate platforms using different languages can interact

transparently through a call-and-return mechanism. That is possible because web



services define the interface format and communication protocols but do not restrict

the implementation language or platform.


Web Services-Interoperability Organization (WS-I)

was chartered in 2002. WS-I publishes profiles that

prescribe adherence to a group of specific versions

of well-defined standards. It is also their goal to

provide tools to certify conformance with the

profiles. Many web service products were updated

in recent years because of this initiative. The

Compliance with WS-I Basic Profile 1.1 is

recommended for this aspect

5.2.2.2 Performance

Performance can mean different things in different contexts. In general, it is related to

response time (how long does it take to process a request), throughput (how many

requests overall can be processed per unit of time), or timeliness (ability to meet

deadlines, i.e., to process a request in a deterministic and acceptable amount of time).

In most cases, performance is negatively affected in SOA. The architecture should be

carefully designed and evaluated prior to implementation to avoid performance pitfalls.


• Web Service Definition Language (WSDL)

• Simple Object Access Protocol (SOAP)



5.2.2.3 Security

Although security denotes different things with respect to software systems, in

general, it is associated with four principles

• Confidentiality ensures that access to information / services is granted

only to authorize subjects.

• Authenticity is related to trust that the indicated author / sender is the

one responsible for the information.

• Integrity guarantees that information is not corrupted.

• Availability ensures that the service is available in a timely manner.


OASIS WS-Security Specification Note: It should be noted that WS-Security

Specification defines a standard set of SOAP

extensions that can be used to provide message

content integrity and confidentiality. It

accommodates a variety of security models and

encryption technologies and is extensible to support

multiple security token formats.

5.2.2.4 Reliability

Reliability is the ability of a system to keep operating over time without failure. Several

aspects of reliability are important within an SOA but for e-government project

following aspect must get special attention by all concerned.

5.2.2.5 Message Reliability

Services are often made available over a network some times connections break and

messages fail to get delivered or are delivered more than once or in the wrong



sequence. Although techniques for ensuring the reliable delivery of messages are

reasonably well understood and available in some messaging middleware products

today, messaging reliability is still a problem.


• OASIS WS-Reliable Messaging

• IBM WebSphere MQ OR Microsoft

MSMQ

5.2.2.6 Service Reliability

Service reliability means the service operates correctly and either does not fail or

reports any failure to the service user. The main issue to be dealt with is managing the

transactional context in order to preserve data integrity during failures and concurrent

access.

Service reliability is more difficult to achieve in e-government because service

providers are distributed, and, hence, a distributed transaction model for these kinds

of services is needed because services may be implemented in different languages

and platforms.


• Business Transactions Protocol (BTP)

by OASIS



5.2.2.7 Availability

Availability is the proportion of time a system or component is operational and

accessible when required for use. Availability of services both from the user’s and

provider’s perspectives is a concern for the success of an SOA. From the service

user’s perspective, if the service is not available (even transiently), then the system

cannot successfully meet its functional requirements. From the service provider’s

perspective, in order for the service to be used (for which the provider may receive

compensation), it must be available when needed.

recommended Standard

The following will act as a standard for testability

in e-government system

• SOA

• XML

• WSDL

5.2.2.8 Modifiability

Modifiability is the ability to make changes to a system quickly and cost-effectively.

SOA promotes loose coupling between service users and providers. E-government

services should be self-contained, modular, and accessed via cohesive interfaces.

These characteristics contribute to the creation of loosely coupled SOA for

government of Pakistan where there should exist few, well-known dependencies

between services. In this way the cost of modifying the implementation of services is

reduced and the overall system modifiability increases. However, if service interfaces

need to be changed, the change may create problems because once service

interfaces are published and used by applications, it can be difficult to identify who is

using a service and what impact changing its interface will have. Extensibility is a

special case of modifiability. Extensibility is the ease with which the services’

capabilities can be extended without affecting other parts of the system. It is an



important quality because the business environment in which a software system lives

is continually changing.

Recommended Standards

Following three considerations will act as standard for modifiability

Consideration Explanation Adding new services SOA for e-government should allow

for the easy addition of services (or new versions of services) because of the dynamic binding between service users and providers, and the use of W3C and OASIS standard.

Extend existing services without changing the interfaces.

E-government services should be loosely coupled; adding capabilities should not require a change in the service interface can be done without affecting service users.

Extend existing services with changes to interfaces.

New capabilities that require changes to the service interface may have a broad impact on the system. In such cases, the implementation of the service needs to change due to the interface modification

5.2.2.9 Testability

Testability is the degree to which a system or service facilitates the establishment of

test criteria and the performance of tests to determine whether those criteria have

been met. Testing an e-government system that uses an SOA is more complex for the

following reasons.

• It is more difficult to setup and trace the execution of a test when the system

elements reside on different machines across the network.

• The source code of external services may not be available to service users defining

and running the tests. Test cases have to be defined exclusively based on the



published interface and documentation. Besides, service users may not have access

to log files or other outputs generated when the external service is executed.

• In some cases, services are discovered at runtime, so it may be impossible to

predict which service is actually used by a system until the system executes. In

addition, different services from different providers may be used at various times

when the system runs. The services used may be running on different platforms or

operating systems and use different middleware technologies. Building repeatable

tests and automating the testing process for such a system is a challenge.


The following will act as a standard for testability

in e-government system

• SOA

• XML

• WSDL

5.2.2.10 Usability

Usability is a measure of the quality of users experiences in interacting with

information or services. The distributed nature of SOA can have a profound impact

when the processing of a user action involves calls to remote service providers. When

service calls take a long time to respond, it is usually a good idea to move the service

communication to a separate thread on the application that contains the service user.

In that case the user interface of that application can still be responsive while service

requests are being made.




The following will act as a standard for usability in

e-government system

• SOA

• XML

• WSDL

• SOAP

5.2.2.11 Scalability

Scalability is the ability of an SOA to function well (without degradation of other quality

attributes) when the system is changed in size or in volume in order to meet users’

needs. The major issue in SOA scalability is the ability of the site where the services

are located to accommodate an increasing number of service users without

performance degradation. In general web services technology does not offer any

inherent scalability feature. To respond to scalability requirements in e-government

projects, the architect has to rely on the mechanisms provided by the platform

vendors.


Following are the standard strategies to improve

scalability in e-government projects.

• Horizontal scaling: add load-balanced servers.

• Vertical scaling: increase the capacity of server.



Pakistan Government Data Standards Catalogue



Metadata Value

Data Element Address

Is Part Of

Has Parts Country Province City District Tehsil Taulka Sector Village Town Building Type Building Number Street Number Zip Code Postal Code

Version 1.1

Status Final

Previous Versions

Later Versions

Date Agreed 05 April 2008

UML diagram Address UML diagram

Name Address

Description A collection of data describing the addressing of locations.

Business Format EGD Standard

Element Type Information Block

XML Schema

Validation Validation rule for each attribute will be specified individually.

Value

Owner SP & A Wing

Based On

Verification Verified by SP&A wing

Comment



Metadata Value

Data Element Country

Is Part Of Address

Has Parts

Version 1.1

Status Final

Previous Versions

Later Versions



Name Country

Description A String representing a Country.

Business Format varchar(50)

Element Type Attribute

XML Schema

Validation • Validated against Countries List of EGD. • Can not have two Countries in a single row. • Will not make use special char. • The first character of each occurrence must be A - Z. • Consecutive spaces are not allowed within single word.

Value Should be from countries List maintained by GoP.

Default Value Pakistan

Owner SP & A Wing

Based On

Verification One or more of the following Certificates are required for verification purpose.

• National Identity Card issue by concerned country. • Passport • certificate of naturalization

Compliance M

Security Public

Comment



Metadata Value

Data Element Province

Is Part Of Address

Has Parts

Version 1.1

Status Final

Previous Versions

Later Versions



Name Province / State

Description A String representing a Province / State.



XML Schema

Validation • Validated against Districts List of EGD. • Can not have two Districts in a single row. • Will not make use special char. • The first character of each occurrence must be A - Z. • Consecutive spaces are not allowed within single word.

Value Should be from relevant country.

Default value Islamabad Capital Area.

Owner SP & A Wing

Based On


• National Identity Card issue by concerned country. • Passport • Certificate of naturalization • Domicile

Compliance M

Security Public

Comment



Metadata Value

Data Element City

Is Part Of Address

Has Parts

Version 1.1

Status Final

Previous Versions

Later Versions



Name City

Description A String representing a City.



XML Schema

Validation • Validated against City List of EGD. • Can not have two Cities in a single row. • Will not make use special char. • The first character of each occurrence must be A - Z. • Consecutive spaces are not allowed within single word..

Value Should be from City List maintained by EGD.

Default value Islamabad

Owner SP & A Wing

Based On


• National Identity Card issue by concerned country. • Passport • Certificate of naturalization • Domicile • Birth certificate

Compliance M

Security Public

Comment



Metadata Value

Data Element District

Is Part Of Address

Has Parts

Version 1.1

Status Final

Previous Versions

Later Versions



Name District

Description A String representing a District.



XML Schema

Validation • Validated against Districts List of EGD. • Can not have two Districts in a single row. • Will not make use special char. • The first character of each occurrence must be A - Z. • Consecutive spaces are not allowed within single word..

Value Should be from District List maintained by EGD.


Owner SP & A Wing

Based On


• National Identity Card issue by concerned country. • Passport • certificate of naturalization • Domicile • Birth certificate

Compliance MO

Security Public

Comment



Metadata Value

Data Element Tehsil

Is Part Of Address

Has Parts

Version 1.1

Status Final

Previous Versions

Later Versions



Name Tehsil

Description A String representing a Tehsil.



XML Schema

Validation • Validated against Tehsil List of EGD. • Can not have two Tehsil in a single row. • Will not make use special char. • The first character of each occurrence must be A - Z. • Consecutive spaces are not allowed within single word..

Value Should be from Tehsil List maintained by EGD.


Owner SP & A Wing

Based On



Compliance MO

Security Public

Comment



Metadata Value

Data Element Taulka

Is Part Of Address

Has Parts

Version 1.1

Status Final

Previous Versions

Later Versions



Name 1.3 Taulka

Description A String representing a Taulka.



XML Schema

Validation • Validated against Taulka List of EGD. • Can not have two Taulka in a single row. • Will not make use special char. • The first character of each occurrence must be A - Z. • Consecutive spaces are not allowed within single word..

Value Should be from Tehsil List maintained by EGD.

Default value Larkana

Owner SP & A Wing

Based On



Compliance MO

Security Public



Comment

Metadata Value

Data Element Sector

Is Part Of Address

Has Parts

Version 1.1

Status Final

Previous Versions

Later Versions



Name 1.4 Sector

Description A String representing a Sector.



XML Schema

Validation • Validated against Sector List of EGD. • Can not have two Sectors in a single row. • Will not make use special char. • The first character of each occurrence must be A - Z. • Consecutive spaces are not allowed within single word.

Value Should be from Sector List maintained by EGD.

Default value G-6

Owner SP & A Wing

Based On



Compliance MO

Security Public



Comment

Metadata Value

Data Element Village

Is Part Of Address

Has Parts

Version 1.1

Status Final

Previous Versions

Later Versions



Name Village

Description A String representing a Village.



XML Schema

Validation • Validated against Village List of EGD. • Can not have two Villages in a single row. • Will not make use special char. • The first character of each occurrence must be A - Z. • Consecutive spaces are not allowed within single word..

Value Should be from Village List maintained by EGD.

Default value

Owner SP & A Wing

Based On



Compliance MO

Security Public



Comment

Metadata Value

Data Element Town

Is Part Of Address

Has Parts

Version 1.1

Status Final

Previous Versions

Later Versions



Name Town

Description A String representing a Town.



XML Schema

Validation • Validated against Town List of EGD. • Can not two Districts in a single row. • Will not make use special char. • The first character of each occurrence must be A - Z. • Consecutive spaces are not allowed within single word..

Value Should be from Town List maintained by EGD.

Default value

Owner SP & A Wing

Based On



Compliance MO

Security Public



Comment

Metadata Value

Data Element Building Type

Is Part Of Address

Has Parts

Version 1.1

Status Final

Previous Versions

Later Versions



Name Building Type

Description A String representing a Village.

Business Format enum('C','N')


XML Schema

Validation • Validated against building type i.e. ‘C’ and ‘N’ • Can not have both types in a single row. • Will not make use special char. • The first character of each occurrence must be ‘C’ and ‘N’. • Consecutive spaces are not allowed within single word..

Value Should be from enum ('C','N')

Default value ‘C’

Owner SP & A Wing

Based On


• Registry Certificate. • Transfer Deed • Any other property documents issued by concerned authorities which

clearly shows building type.

Compliance MO

Security Public

Comment



Metadata Value

Data Element Building Number

Is Part Of Address

Has Parts

Version 1.1

Status Final

Previous Versions

Later Versions



Name Building No

Description A String representing a Building No.

Business Format Varchar (50)


XML Schema

Validation Validated against the given business format.

Value Should be within Varchar (50)

Default value

Owner SP & A Wing

Based On




Compliance MO

Security Public

Comment



Metadata Value

Data Element Street No

Is Part Of Address

Has Parts

Version 1.1

Status Final

Previous Versions

Later Versions



Name Street No

Description A String representing a Street No.



XML Schema

Validation • Can not have two Street No. in a single row. • Will not make use special char. • The first character of each occurrence must be 0- 9. • Consecutive spaces are not allowed within single word..

Value Should be from Varchar (50)

Default value

Owner SP & A Wing

Based On




Compliance MO

Security Public

Comment



Metadata Value

Data Element Zip Code

Is Part Of Address

Has Parts

Version 1.1

Status Final

Previous Versions

Later Versions



Name Zip Code

Description A String representing a Street No.



XML Schema

Validation • Can not have two Zip Codes in a single row. • Will not make use special char must be included in Zip code List of

relevant country. • Numeric part is a positive integer less than 10000. The alpha part is

a capital letter A-Z.


Default value

Owner SP & A Wing

Based On




Compliance MO

Security Public

Comment



Metadata Value

Data Element Postal Code

Is Part Of Address

Has Parts

Version 1.1

Status Final

Previous Versions

Later Versions



Name Postal Code

Description A Number representing a Postal Code.

Business Format Number


XML Schema

Validation Validated against the Number

Value Should be Number

Default value

Owner SP & A Wing

Based On



clearly show Postal Code.

Compliance O

Security Public

Comment






Metadata Value

Data Element Contact

Is Part Of

Has Parts Fax No Phone No Mobile No Web Site URL Email

Version 1.1

Status Final

Previous Versions

Later Versions


UML diagram Contact UML diagram

Name Contact

Description A collection of data describing the conatct information



XML Schema


Value

Owner SP & A Wing

Based On


Comment



Metadata Value

Data Element Fax No

Is Part Of Contact

Has Parts Country Code City Code Fax No

Version 1.1

Status Final

Previous Versions

Later Versions


UML diagram Fax No UML diagram

Name Fax No

Description A String representing a Fax No



Has Part 1. Country Code 2. City Code 3. Fax No

XML Schema

Validation • Can not have two Fax No in a single row. • Will not make use special char. • The first character of each occurrence must be A- Z. • Consecutive spaces are not allowed within single Number.

Value

Default value

Owner SP & A Wing

Based On




• Official Card. • NTN certificate / sale Tax certificate • Telephone Directory.

Compliance MO

Security Public

Comment

Metadata Value

Data Element Phone No

Is Part Of Contact

Has Parts Country Code City Code Fax No Ext No

Version 1.1

Status Final

Previous Versions

Later Versions


UML diagram Phone No UML diagram

Name Phone No

Description A Number representing a Phone No.



Has Part 1. Country Code 2. City Code 3. Phone No 4. Ext No

XML Schema



Validation • Can not have two Phone No. in a single row. • Will not make use special char. • The first character of each occurrence must be from 0- 9. • Consecutive spaces are not allowed within single Number.

Value

Default value

Owner SP & A Wing

Based On



Compliance M

Security Public

Comment

Metadata Value

Data Element Mobile No

Is Part Of Contact

Has Parts

Version 1.1

Status Final

Previous Versions

Later Versions



Name Mobile No

Description A Number representing a Mobile No.





Has Part 1. Country Code 2. Carrier Code 3. Mobile No

XML Schema

Validation • Can not have two Mobile No. in a single row. • Will not make use special char. • The first character of each occurrence must be from 0- 9. • Consecutive spaces are not allowed within single Number.

Value

Default value

Owner SP & A Wing

Based On



Compliance MO

Security Public

Comment

Metadata Value

Data Element Website URL

Is Part Of Contact

Has Parts

Version 1.1

Status Final

Previous Versions



Later Versions



Name Web Site URL

Description A String representing a Web Site URL.

Business Format URLs are sequences of characters, i.e., letters, digits, and special characters. The characters ";", "/", "?", ":", "@", "=" and "&" are the characters which have been reserved for special meaning.


XML Schema

Validation • Can not have two Website URL in a single row. • Will not make use special char. • Consecutive spaces are not allowed within single word while writing

Web Site URL.

Value

Default value

Owner SP & A Wing

Based On

Verification IETF RFC1738

Compliance MO

Security Public

Comment

Metadata Value

Data Element Email

Is Part Of Contact

Has Parts

Version 1.1

Status Final



Previous Versions

Later Versions



Name Email

Description A String representing a Email.



XML Schema

Validation • Can not have two Emails in a single row. • Will not make use special char. • Consecutive spaces are not allowed within single word while writing

Email address.

Value

Default value

Owner SP & A Wing

Based On



Compliance MO

Security Public

Comment






Metadata Value

Data Element Financial Information

Is Part Of

Has Parts Bank Account No Pay Order No Check No National Tax No Sales Tax No Property Tax No EOBI Pension Salary / Income Tax Social Security

Version 1.1

Status Final

Previous Versions

Later Versions


UML diagram Financial UML diagram

Name Financial

Description A collection of data describing the financial information



XML Schema


Value

Owner SP & A Wing

Based On


Comment



Metadata Value

Data Element Bank Account No

Is Part Of Financial

Has Parts

Version 1.1

Status Final

Previous Versions

Later Versions



Metadata Value

Data Element Pay Order No


Has Parts

Version 1.1

Status Final

Previous Versions

Later Versions



Metadata Value

Data Element Check No


Has Parts

Version 1.1



Status Final

Previous Versions

Later Versions



Metadata Value

Data Element National Tax No


Has Parts

Version 1.1

Status Final

Previous Versions

Later Versions



Metadata Value

Data Element Sales Tax No


Has Parts

Version 1.1

Status Final

Previous Versions

Later Versions





Metadata Value

Data Element Property Tax No


Has Parts

Version 1.1

Status Final

Previous Versions

Later Versions



Metadata Value

Data Element EOBI


Has Parts

Version 1.1

Status Final

Previous Versions

Later Versions



Metadata Value

Data Element Pension


Has Parts



Version 1.1

Status Final

Previous Versions

Later Versions



Metadata Value

Data Element Salary / Income


Has Parts

Version 1.1

Status Final

Previous Versions

Later Versions



Metadata Value

Data Element Tax


Has Parts

Version 1.1

Status Final

Previous Versions

Later Versions





Metadata Value

Data Element Social Security


Has Parts

Version 1.1

Status Final

Previous Versions

Later Versions











Metadata Value

Data Element Person

Is Part Of

Has Parts Name Title Father / Husband Name Mother Name Place of Birth Place of Death Date of Birth Date of Death Domicile Martial Status Religion Gender Photograph NIC No Nationality

Version 1.1

Status Final

Previous Versions

Later Versions


UML diagram Person UML diagram

Name Person

Description A collection of data describing the Person information



XML Schema


Value

Owner SP & A Wing

Based On


Comment



Metadata Value

Data Element Name

Is Part Of Person

Has Parts First Name Middle Name Family Name

Version 1.1

Status Final

Previous Versions

Later Versions


UML diagram Name UML diagram

Name Name

Description A String representing a Name.



XML Schema

Has Parts • First name • Middle name • Family name

Validation 1. Any allowable character from UNICODE set of characters. 2. Each element of the name must be separated by a space. 3. Consecutive spaces are not allowed within single word..


Default value

Owner SP & A Wing

Based On


• National Identity Card issue by concerned country. • Passport • certificate of naturalization • School certificate or report. • Marriage Certificate • Foreign birth certificate issued by registration authority of the foreign



country.

Compliance M

Security Public

Comment

Metadata Value

Data Element Title

Is Part Of Person

Has Parts

Version 1.1

Status Final

Previous Versions

Later Versions



Name Title

Description A String representing a Title.



XML Schema

Validation • Can not have two Titles in a single row. • Will not make use special char. • The first character of each occurrence must be A- Z. • Consecutive spaces are not allowed within single word.


Default value

Owner SP & A Wing

Based On




• National Identity Card issue by concerned country. • Passport • certificate of naturalization • School certificate or report. • Marriage Certificate • Foreign birth certificate issued by registration authority of the

foreign country.

Compliance MO

Security Public

Comment

Metadata Value

Data Element Father / Husband Name

Is Part Of Person

Has Parts

Version 1.1

Status Final

Previous Versions

Later Versions



Name Father / Husband name

Description A String representing a Father / Husband Name.



XML Schema

Validation • Can not have two Names in a single row. • Will not make use special char.



• The first character of each occurrence must be A- Z. • Consecutive spaces are not allowed within single word.


Default value

Owner SP & A Wing

Based On



foreign country.

Compliance MO

Security Public

Comment

Metadata Value

Data Element Mother Name

Is Part Of Person

Has Parts

Version 1.1

Status Final

Previous Versions

Later Versions



Name Mother name



Description A String representing a Mother Name.



XML Schema

Validation • Can not have two Names in a single row. • Will not make use special char. • The first character of each occurrence must be A- Z. • Consecutive spaces are not allowed within single word..


Default value

Owner SP & A Wing

Based On



foreign country. • Credit Card / Debt Card information.

Compliance MO

Security Public

Comment

Metadata Value

Data Element Place of Birth

Is Part Of Person

Has Parts

Version 1.1



Status Final

Previous Versions

Later Versions



Name Place of Birth

Description A String representing a Place of Birth.



XML Schema

Validation • Can not have two Places in a single row. • Will not make use special char. • The first character of each occurrence must be A- Z. • Consecutive spaces are not allowed within single word..


Default value

Owner SP & A Wing

Based On


• National Identity Card issue by concerned country. • Passport • Certificate of naturalization • Domicile • Birth certificate.

Compliance M

Security Public

Comment



Metadata Value

Data Element Place of Death

Is Part Of Person

Has Parts

Version 1.1

Status Final

Previous Versions

Later Versions



Name Place of Death

Description A String representing a Place of Death.



XML Schema

Validation • Can not have two Places in a single row. • Will not make use special char. • The first character of each occurrence must be A- Z. • Consecutive spaces are not allowed within single word.


Default value

Owner SP & A Wing

Based On


• Notification from Hospital • Police Statement • Death certificate.



Compliance M

Security Public

Comment

Metadata Value

Data Element Date of Birth

Is Part Of Person

Has Parts

Version 1.1

Status Final

Previous Versions

Later Versions



Name Date of Birth

Description A String representing a Date of Birth.

Business Format Date, 10 Characters in the format MM-DD- YYCC.


XML Schema

Validation 1. Values less than 10 in the day, month or year elements should be entered with a zero in the first position. 2. Days must not be greater than 30 in April, June, September and November. 3. Days must not be greater than 28 in February except when 29 are allowed for a leap year.

Value • YYCC should be a valid year number. • MM in Range 01-12. • DD in Range 01-31.

Default value

Owner SP & A Wing

Based On




• Metric Certificate. • Marriage Certificate • National Health Service Medical Card • Child's Certificate of Vaccination • Certificate or testimonial from employer. • Certificate of naturalization • Passport. • Life insurance policy. • School certificate or report.

Compliance M

Security Public

Comment

Metadata Value

Data Element Date of Death

Is Part Of Person

Has Parts

Version 1.1

Status Final

Previous Versions

Later Versions



Name Date of Death

Description A String representing a Date of Death.

Business Format Date time, 20 Characters in the format MM-DD- YYCC, HH-MM-SS


XML Schema



Validation 1. Values less than 10 in the day, month or year elements should be entered with a zero in the first position. 2. Days must not be greater than 30 in April, June, September and November. 3. Days must not be greater than 28 in February except when 29 are allowed for a leap year.

Value • YYCC should be a valid year number. • MM in Range 01-12. • DD in Range 01-31. • Values should be less than equal to 24 in the hours. • Values should be less than 60 in the Minutes. • Values should be less than 60 in the Seconds.

Default value

Owner SP & A Wing

Based On


• Notification from Hospital • Police Statement • Death certificate.

Compliance MO

Security Public

Comment

Metadata Value

Data Element Domicile

Is Part Of Person

Has Parts

Version 1.1

Status Final

Previous Versions

Later Versions





Name Domicile

Description A String representing a Domicile.



XML Schema

Validation • Can not have two Names in a single row. • Will not make use special char. • The first character of each occurrence must be A- Z. • Consecutive spaces are not allowed within single word..


Default value

Owner SP & A Wing

Based On


• National Identity Card issue by concerned country. • Passport • Certificate of naturalization • Domicile • Birth certificate.

Compliance MO

Security Public

Comment

Metadata Value

Data Element Martial Status

Is Part Of Person



Has Parts

Version 1.1

Status Final

Previous Versions

Later Versions



Name Marital Status

Description A String representing a Marital Status

Business Format enum('S','M','W')


XML Schema

Validation • Can not have 'S','M','W' in a single row. • Will not make use special char. • The first character of each occurrence must be 'S','M','W' • Consecutive spaces are not allowed within single word..

Value Should be from 'S','M','W'

Default value

Owner SP & A Wing

Based On


• National Identity Card issue by concerned country. • marriage certificate/ NikahNama • Foreign marriage certificate (under religious or national law of the

country). • Affidavit of marriage

Compliance MO

Security Public

Comment



Metadata Value

Data Element Religion

Is Part Of Person

Has Parts

Version 1.1

Status Final

Previous Versions

Later Versions



Name Religion

Description A String representing a Religion

Business Format enum('F','M')


XML Schema

Validation • Can not have more than one relationship in a single row. • Will not make use special char. • The first character of each occurrence must be 'S','M','W' • Consecutive spaces are not allowed within single word.

Value • None • Christian • Buddhist • Hindu • Jewish • Muslim • Sikh • Any other religion (please write in)

Default value

Owner SP & A Wing

Based On




• Passport • Any other documents issued by concerned authorities which clearly

show Religion.

Compliance MO

Security Public

Comment

Metadata Value

Data Element Gender

Is Part Of Person

Has Parts

Version 1.1

Status Final

Previous Versions

Later Versions



Name Gender

Description A String representing a Gender

Business Format enum('F','M')


XML Schema

Validation • Can not have 'F','M' in a single row. • Will not make use special char. • The first character of each occurrence must be 'S','M','W' • Consecutive spaces are not allowed within single word..



Value Should be from 'F','M'

Default value

Owner SP & A Wing

Based On


• National Identity Card issue by concerned country. • marriage certificate/ NikahNama

Compliance MO

Security Public

Comment

Metadata Value

Data Element Photograph

Is Part Of Person

Has Parts

Version 1.1

Status Final

Previous Versions

Later Versions



Name Photograph

Description A String representing a Photograph

Business Format BLOB




XML Schema

Validation • Should be Image. • No Text Item.

Value

Default value

Owner SP & A Wing

Based On


• National Identity Card issue by concerned country.

Compliance MO

Security Public

Comment

Metadata Value

Data Element NIC No

Is Part Of Person

Has Parts

Version 1.1

Status Final

Previous Versions

Later Versions



Name NIC No

Description A String representing a NIC No





XML Schema

Validation • Always in Number

Value

Default value

Owner SP & A Wing

Based On


• National Identity Card issue by concerned country. • Passport

Compliance M

Security Public

Comment

Metadata Value

Data Element Nationality

Is Part Of Person

Has Parts

Version 1.1

Status Final

Previous Versions

Later Versions



Name Nationality

Description A String representing a Nationality





XML Schema

Validation • Can not have two Nationalities in a single row. • Will not make use special char. • The first character of each occurrence must be A- Z. • Consecutive spaces are not allowed within single word.

Value

Default value

Owner SP & A Wing

Based On


• National Identity Card issue by concerned country. • Passport • Birth certificate. • Certificate of naturalization

Compliance M

Security Public

Comment




.



Metadata Value

Data Element Mark of Identification

Is Part Of Security/ Biometric

Has Parts

Version 1.1

Status Final

Previous Versions

Later Versions


UML diagram Security/Biometric UML diagram

Metadata Value

Data Element Blood Group


Has Parts

Version 1.1

Status Final

Previous Versions

Later Versions





Metadata Value

Data Element Height Ft


Has Parts

Version 1.1

Status Final

Previous Versions

Later Versions



Metadata Value

Data Element Chest In


Has Parts

Version 1.1

Status Final

Previous Versions

Later Versions





Metadata Value

Data Element Weight Kg


Has Parts

Version 1.1

Status Final

Previous Versions

Later Versions



Metadata Value

Data Element Face Color


Has Parts

Version 1.1

Status Final

Previous Versions

Later Versions





Metadata Value

Data Element Hair Color


Has Parts

Version 1.1

Status Final

Previous Versions

Later Versions



Metadata Value

Data Element Eye Color


Has Parts

Version 1.1

Status Final

Previous Versions

Later Versions








Metadata Value

Data Element Passport No

Is Part Of Travel

Has Parts

Version 1.1

Status Final

Previous Versions

Later Versions


UML diagram Travel UML diagram

Metadata Value

Data Element Visa No

Is Part Of Travel

Has Parts

Version 1.1

Status Final

Previous Versions

Later Versions





Metadata Value

Data Element Ticket No

Is Part Of Travel

Has Parts

Version 1.1

Status Final

Previous Versions

Later Versions



Metadata Value

Data Element Flight No

Is Part Of Travel

Has Parts

Version 1.1

Status Final

Previous Versions

Later Versions





Metadata Value

Data Element Visa Type

Is Part Of Travel

Has Parts

Version 1.1

Status Final

Previous Versions

Later Versions





Technical Vocabulary Catalogue

DRAFT VERSION

August 2008

Government of Pakistan Ministry of Information Technology Electronic Government Directorate



7 Technical Vocabulary Catalogue

7.1 Pre- Development Standards Technical policies for Pre-development standards are outlined in the e-GIF

Table 1 Specifications for Business Process Modeling

Term Definition Comments/Remarks

As-Is Model A model representing the current/ As-Is processes of the organization.

As-Is Processes

The current processes of the organization are called are As-Is Processes.

BPMN 1.x The version of Business Process Modelling Notation 1 or higher than 1. http://www.bpmn.org/

Business Analyst

Business Model

The business model is a conceptual tool that contains a certain set of notations and their relationships for expressing the business logic.

Business Process Diagram (BPD)

A diagram representing the business processes of an organization or enterprise by using the BPMN notations

Business Process Execution Language (BPEL)

Business Process Execution Language for Web Services BPEL4WS as defined by the BEA, IBM, Microsoft, SAP AG and Siebel http://www-106.ibm.com/developerworks/library/ws-bpel/It is a language for specifying business process behaviour based on Web Services

Business Process Management (BPM)

Business process management (BPM) is an approach that promotes business effectiveness and efficiency while striving for innovation, flexibility and integration with technology. As organizations strive for attainment of their objectives, BPM attempts to continuously improve processes - the process to define, measure and improve your processes – a ‘process optimization' process

Business Process Modelling

Business Process Modelling is the activity of representing both the current ("as is") and future ("to be") processes of an enterprise, so that the current process may be analyzed and improved.

Business Process Modelling Language (BPML)

BPML is "a meta-language for the modelling of business processes, just as XML is a meta-language for the modelling of business data.

Business Process Modelling Notation (BPMN)

The standardized graphical notation for drawing business processes in a workflow. Its current adopted version is 1.1 and the proposed one is 2.0 http://www.bpmn.org/

Business Process

It is a management approach aiming at improvements by means of elevating efficiency and effectiveness of the



Reengineering (BPR)

processes that exist within and across organizations

Collaborative Processes

A collaboration process depicts the interactions between two or more business entities. These interactions are defined as a sequence of activities that represent the message exchange patterns between the entities involved.

Common Processes

The processes which are executed by all Government entities e.g. HR , Budgeting , Project Management, Inventory & Procurement etc.

Core Processes

The processes that are executed by a certain agency only e.g. Issuance of Licenses, Title deeds etc

Cycle Time ebXML BPSS Electronic business using eXtensible Mark-up Language

, Business Process Specification Scheme v1.1 as defined by OASIS http://www.ebxml.org/specs/ebBPSS.pdf

Effort Time Exceptional Processes

Private Processes

These processes are internal business processes of an organization. these process are also called organizational workflows.

Process Effectiveness

Process Efficiency

Public Processes

This represents the interactions between a private business process and another process or participant. Only those activities that communicate outside the private business process are included in the public process.

Service Delivery

Stakeholders A person, group, organization, or system who affects or can be affected by an organization's actions.

Technical Developers

To-Be Model To-be model comprises of new business processes which should be adopted by organization in order to avoid drawbacks and bottlenecks.

Waiting Time

7.2 Development Standards

Technical policies for development standards are outlined in the e-GIF Table 2 Specifications for Software Requirements Specifications (SRS)


Activity Diagram

It is a type of behavioural diagram defined by the UML It shows activities and actions to describe Workflows. It represents the business and operational step-by-step



workflow of components in a system and also the overall flow of control.

Assumptions The factors that could affect the requirements stated in the software requirements specification document.

Class Diagram It is a type of static structure diagram defined by the UML that describes the structure of a system by showing the system's classes, their attributes, and the relationships between the classes.

Communication Interfaces

Component Diagram

It is a type of structure diagram defined by the UML and depicts how a software system is split up into components and shows the dependencies among these components. Physical components include files, headers, link libraries, modules, executables, or packages.

Constraints A constraint is a semantic relationship among model elements that specifies conditions and propositions that must be maintained as true.

Deployment Diagram

It is a type of structure diagram defined by the UML. It model the hardware used in system implementations, the components deployed on the hardware, and the associations between those components.

Design & Implementation Constraints

The items or issues that will limit the options available to the developers e.g. regulatory policies , hardware limitations , interfaces to other components etc.

Extensibility Mechanisms

External Interfaces

Factor Table Functional requirements

It defines what a software system or its component is supposed to do. A function is described as a set of inputs, the behaviour, and outputs.

Hardware Interfaces

The logical and physical characteristics of each interface between the software product and the hardware components of the system.

Issue Card Microsoft GUI Standards

Non- functional requirements

It defines how a software system or its component is supposed to be. These requirements specify criteria that can be used to judge the operation of a system, rather than specific behaviours. These are often called “qualities” or “constraints” of the system.

Operating Environment

The environment in which the software will operate, including the hardware platform, operating systems and their versions or any other software components or applications.

Performance Requirements

Constraints for regarding performance issues must formulize e.g. response time issues etc.

Ports Ports define the interaction between a classifier and its environment. A port can appear on the boundary of a contained part, a class or a composite structure. A port



may specify the services a classifier provides as well as the services that it requires of its environment.

POSIX (IEEE 1003)

Portable Operating System Interface is the collective name of a family of related standards specified by the IEEE to define the application programming interface (API), along with shell and utilities interfaces for software compatible with variants of the Unix operating system, although the standard can apply to any operating system.

Process Consultant

Product Functions

The major functions that product must perform or must let the end-users to perform.

Protocols Safety Requirements

Sequence Diagram

It is a type of interaction diagram defined by the UML. It shows how processes operate one with another and in what order. The parallel vertical lines depicts, different processes or objects that live simultaneously, and, as horizontal arrows, the messages exchanged between them, in the order in which they occur.

Software Interfaces

The connections between this product and other specific software components including databases, operating systems, tools, libraries and commercial off the shelf components.

Software Quality Attributes

The quality characteristics of the product that will be important either for customers or the developers. e.g. adaptability, availability, correctness, interoperability etc.

Software Requirements Specifications (SRS)

A document that contains the complete descriptions of the behaviour of the system to be developed.

Stereotypes It is one of the extensibility mechanism in UML. They allow designers to extend the vocabulary of UML in order to create new model elements, derived from existing ones, but that have specific properties that are suitable for a particular problem domain or otherwise specialized usage.

SUN GUI Standards

System Features

Tag Values Timing Diagram

It is a type of behavioural modelling diagram in UML. It is used to display the change in state or value of one or more elements over time. It can also show the interaction between timed events and the time and duration constraints that govern them.

UML 2.x It is a standardized visual specification language for object modelling. It is a general-purpose modelling language that includes a graphical notation used to create an abstract model a system, referred to as a UML model.

Use Case It is a type of behavioural diagram defined by the UML



Diagram and created from a Use-Case analysis. Its purpose is to present a graphical overview of the functionality provided by a system in terms of actors, their goals (represented as use cases), and any dependencies between those use cases

User Classes User Interfaces The interface between the software product and the

users.

Table 3 Specifications for Software Design Document (SDD)


Architectural Strategies

The design decisions and / or strategies that affect the overall organization of the system and its higher-level structures. These strategies provide insight into the key abstractions and mechanism used in the system architecture.

Classification of a Component

The kinds of components, such as subsystem, module, class, package, function, file etc.

Composition A description of the use and meaning of the subcomponents that are part of this component.

Data Storage Management

Data Storage Persistence

Definition of a Component

The specific purpose and semantic meaning of a component.

Design Entity An element (component) of a design that is structurally and functionally distinct from other elements that is separately named and referenced

Design View A subset of design entity attribute information that is specifically suited to the needs of a software project activity.

Detailed System Design

It describes the detailed description of system software components.

Entity Attributes A named characteristics or property of a design entity .It provides a statement of fact about the entity.

Extensibility Mechanism

External databases

Hardware Interface Paradigms

IEEE / EIA 12207.1-1997

It provides a common framework for developing and managing software that includes inception, elaboration, testing and transition phases.

Interfaces of a Component

The set of services (resources, data, types, constants, subroutines, and exceptions) that are provided by this component.

Interoperability requirements



Memory Management Policies

Package Diagram

It is a type of structure diagram defined by the UML that used to reflect the organization of packages and their elements. When used to represent class elements, package diagrams provide a visualization of the namespaces. The most common use for package diagrams is to organize use case diagrams and class diagrams.

Resources Resources are entities external to the design such as memory, processors, printers, databases, or a software library

Responsibilities of a Component

It describes what does a component accomplish? What role does it plays? What kind of services does it provide to its clients?

Software Design Document

A blueprint or model of the software system to be created. It is primary medium for communicating software design information.

Software Interface Paradigms

Software life Cycle

The period of time that starts when a software product is conceived and ends when the product is no longer available for use.

State Machine Diagram

It is a type of behavioural diagram defined by the UML to model the behaviour of a single object, specifying the sequence of events that an object goes through during its lifetime in response to events.

Sub-System Architecture

It describes how the system architecture components are further subdivided into subcomponents, and the relationships and interaction between sub-components

System Architecture

A high level overview of how the functionality and responsibilities of the system were partitioned an then assigned to subsystems or components

User Interface Paradigms



Table 4 Specifications for Implementation Standards



Term Definition Comments / Remarks

Assembly A set of interconnected components Authenticity It is related to trust that the indicated author / sender is

the one responsible for information.

Availability It is the proportion of time, a system, component or service is operational and accessible when required for use.

Business Transaction Protocol (BTP)

It is designed to allow coordination of application work between multiple participants or controlled by autonomous organizations. It uses a two phase outcome coordination protocol to ensure the overall application achieves a consistent result. http://www.oasis-open.org/committees/download.php /1184/2002-06-03.BTP_cttee_spec_1.0.pdf

Component A unit of composition with contractually specified interfaces and explicit context dependencies only.

Confidentiality It ensures that access to information / service is granted only to authorized subjects.

Distributed Environment

Heterogeneous Environment

Horizontal Scaling

IBM Web Sphere MQ

It provides a Universal Messaging Backbone on distributed platforms to connect virtually any commercial IT system. http://www-306.ibm.com/software/integration/wmq/

Integrity It guarantees that information is not corrupted. Interoperability A collection of communicating entities to share specific

information and operate on it according to agreed-upon operational semantics.

Microsoft Message Queuing (MSMQ)

Microsoft Message Queuing (MSMQ) technology enables applications running at different times to communicate across heterogeneous networks and systems that may be temporarily offline. It provides guaranteed message delivery, efficient routing, security, and priority-based messaging. It can be used to implement solutions for both asynchronous and synchronous messaging scenarios. http://www.microsoft.com/windowsserver2003/technologies/msmq/default.mspx

Modifiability It is the ability to make changes to a system quickly and cost effectively.

OASIS WS-Reliable Messaging

WS-Reliability is SOAP based specification that fulfills reliable messaging requirements critical to application of web services. http://docs.oasis-open.org/wsrm/ws-reliability/v1.1 /wsrm-ws_reliability-1.1-spec-os.pdf

OASIS WS-Security

It defines a standard set of SOAP extensions that can be used to provide message content integrity and



Specifications confidentiality. http://www.oasis-open.org/committees/download.php/ 16790/wss-v1.1-spec-os-SOAPMessageSecurity.pdf

Reliability It is the ability of the system to keep operating over time without failure.

Scalability The ability of service oriented architecture to function well (without the degradation of other quality attributes) when the system is changed in size or volume in order to meet user’s needs.

Service Oriented Architectural Implementation Framework (SOAIF)

The SOAIF envisions a comprehensive framework that provides all the technology that an enterprise might need to build and run an SOA. An SOAIF includes both design-time and run-time capabilities as well as all the software functionality an enterprise needs to build and operate an SOA.

Service Oriented Architecture (SOA)

Service-oriented architecture (SOA) is a software architecture where functionality is grouped around business processes and packaged as interoperable services. SOA also describes IT infrastructure which allows different applications to exchange data with one another as they participate in business processes. The aim is a loose coupling of services with operating systems, programming languages and other technologies which underlie applications.

Service Reliability

The service operates correctly and either does not fail or reports any failure to the service user.

Service Transaction (Ws-Tx)

It is used to define a set of protocols to coordinate the outcomes of distributed application actions. http://msdn.microsoft.com/en-us/library/ms951262.aspx

Simple Object Access Protocol (SOAP 1.2)

SOAP is a protocol for exchanging XML-based messages over computer networks, normally using HTTP/HTTPS. SOAP forms the foundation layer of the web services protocol stack providing a basic messaging framework upon which abstract layers can be built.

Testability It is the degree to which a system or service facilitates the establishment of text criteria and the performance of tests to determine whether those criteria have been met.

Usability It is measure of the quality of a user’s experience in interfacing with information or services.

Vertical Scaling Web Service Description Language (WSDL)

WSDL is an XML format for describing network services as a set of endpoints operating on messages containing either document-oriented or procedure-oriented information. The operations and messages are described abstractly, and then bound to a concrete network protocol and message format to define an endpoint. Related concrete endpoints are combined into abstract endpoints (services).

Web Service –Interoperability (WS-I)

The Web Services Interoperability Organization (WS-I) is an open industry organization chartered to establish Best Practices for Web services interoperability, for



Organization selected groups of Web services standards, across platforms, operating systems and programming languages.

World Wide Web Consortium (W3C)

The World Wide Web Consortium develops interoperable technologies (specifications, guidelines, software, and tools) to lead the Web to its full potential.

Table 5 Specifications for Testing Standards


Environmental needs The hardware, communications system, software or any other objects required for the execution of the test case.

Input Specifications The details of each input and its relationships with other inputs required to execute the test case.

Intercase Dependencies

The dependencies between the test case to identify that which tests case must be executed first.

Item Fail Criteria The criteria to describe that the testing of the item is not successful.

Item Pass Criteria The criteria to describe that the testing of item is successful.

Output Specifications The details of outputs and features required as results of test case execution

Responsibility Matrix A matrix identifying the people responsible for managing, designing, preparing, executing, checking and resolving the testing activities.

Test Case Specification

It is a report to document the specific inputs, predicated results, and a set of execution conditions for test item.

Test Case Specification Identifier

An identifier used to identify the test case specification

Test Design Specification

A report that will specify the test approach for a software feature or combination of software features and identifying the associated tests.

Test Design Specification Identifier

An identifier used to identify the test design specification.

Test items It is an software item on which testing is performed, e.g source code, object code, job control code, control data etc.

Test Plan Identifier An identifier used to identify the test plan. Test Procedure Specification

It will classify all the steps required to exercise the specified test cases in order to implement the associated test design.

Test Procedure Specification Identifier

An identifier used to identify the test procedure specification

Testing Approach The major activities, techniques, and tools that are used to test the features.

Testing Plan It will describe the scope, approach, resources, and schedule of the testing activities.



8 What Next?

8.1 Government Service Bus (GSB)

The Enterprise Service Bus / Government Service Bus (GSB) in GoP context is based

on the general concept of a bus. The concept of a bus is a very powerful architectural

pattern, proven in many fields. For example, a bus is at the very core of any computer

(hardware) architecture, and transfers data between the various components of the

computer (both internal and external). By using standard interfaces, such a bus can

connect, in a logical sense, several types of peripherals, made by different vendors,

over the same set of wires, without needing point-to-point and one-off connections.

GSB, as its name rightly implies, is itself a pattern based on the general concept of a

bus. And just as advances in hardware bus technologies resulted in various

generations and types of hardware buses with different capabilities (e.g., a parallel

bus versus a USB), implementations of the GSB pattern for services have different

capabilities, some with basic, and some with advanced features. The GSB

architecture at GGD will have advanced capabilities to enable Government of Pakistan

to meet its needs.

The GSB will provide the middleware capabilities throughout the Government of

Pakistan to support service interactions. Additionally, the GSB supports the

communication and integration technologies required by the services, and is capable



of distributed deployment with a common model for management and administration.

The key features of GSB include:

• Capability to perform routing, transformation, security and other functions

commonly referred to as "intermediary" functions.

• An administration service to administer the services it supports such as

deployment, access management etc. In a geographically deployed GSB, the

administration services maintain a consistent configuration across a network of

cooperating GSBs.

• A number of inbound ports. Each inbound port is configured to receive service

requests on a set of addresses using a particular protocol, e.g., SOAP / HTTP.

• A number of outbound ports. Each outbound port is configured to forward

service requests to and receives responses from a set of addresses using a

particular protocol.

In addition, a GSB can provide transformations between a variety of security, data

format, or transactional models between service consumers and providers. In this way

the GSB acts as a control and encapsulation point for the inevitable complexity and

heterogeneity encountered in an enterprise.

A Service registry serves as a repository for service meta-data and configuration. It

also supports the discovery, management (create, retrieve, update, delete), role-

based ACL enforcement, query and selection, customizable state transition

management, socialization (notification of changes), artifact storage and customizable

classifications.

The next table provides a summary of the requirements for the Government of

Pakistan GSB, including the Service Registry / Repository.





Category Requirement

Integration Pattern Support

• GSB needs to support Synchronous and Asynchronous service interactions

• GSB needs to support Routing, Distribution, Publish-Subscribe

• GSB needs to support Multiplexers, both Concentrators and Normalizers.

• Bus needs to support Transformation and Mediation

• GSB needs to support sub-patterns: Filters, Enrichers, Wrappers, Aggregation, Re-sequencers and Split-Sequence

• GSB needs to support Consumers: Scheduler, Event-Based, Polling, Selective and Durable Subscribers and Service Activator.

Message Protocol and Format Mediator

• Support for MQ and JMS • Support for File System protocols • Support for ODBC/JDBC

Transports • Support for JMS transports. • Support for MQ transport. • Support for HTTP/S transport.

Security

• GSB needs to work with external Security Providers

• GSB needs to support Authentication services.

• GSB needs to support Authorization services. Web Services Management

• GSB needs to work with Web Services management components.

Monitoring and Tracing

• GSB needs to support monitoring services • GSB needs to support tracing and logging

services

Quality of Service

• GSB needs to support scalability. • GSB needs to support Transaction / XA. • GSB needs to support and work with Reliable

Messaging. Exception Handing

• Retry • Logging

Message Format

• EMF • CMM



Category Requirement Standards • STAR (for external business partner

communications)

8.2 Government Discovery, Description and integration (GDDI)

The GSB should provide a ‘service directory’, which is a directory that allows service

providers to publish and link their services online for other systems and users to

access them. Service metadata should be maintained as part of the catalogue.

E-Service Providers should be able to manage and maintain the metadata of their

published services.

A standard that has gained some acceptance in the industry and which provides the

necessary protocols and structure for a service directory is UDDI (Universal

Description Discovery and integrations).

The Service directory should natively support UDDI.

The workshop will present the proposed elements for the service registry and cover

the following aspects which will help in formulating the final requirements:

• Registry publishing support: allowing entities to electronically publish services

to the repository.

• Registry authentication and authorization requirements and integration with the

identity management system.

• Registry notification support: whereby users or entities are notified when

services undergo changes.





9 APPENDICES APPENDIX - A: BPD Core Elements Set

Following are 04 Basic Categories of Element Set

Flow Objects: These are the main graphical elements to define the behavior of a

Business Process. There are three Flow Objects:

(i) Events: It is something that “happens” during the course of a business

process. These events affect the flow of the process and usually have a Cause

(trigger) or an impact (result).

(ii) Activities: An activity is a generic term for work that government entity

performs. The types of activities that are a part of a Process Model are:

Process, Sub Process, and Task.

(iii) Gateways: A Gateway is used to control the divergence and convergence of

Sequence Flow. Thus, it will determine branching, forking, merging, and joining

of paths.

Connecting Objects: There are three ways of connecting the Flow Objects to each

other or other information.

(i) Sequence Flow: It is used to show the order that activities will be performed in

Process.

(ii) Message Flow: It is used to show the flow of messages between two

participants that are prepared to send and receive them.

(iii) Association: It is used to associate information with Flow Objects. Text and

graphical non-Flow Objects can be associated with the Flow Objects

Swim lanes: There are two ways of grouping the primary modeling elements through

“Swim lanes:”



(i) Pools: It represents a Participant in a Process. A Participant can be a specific

entity (e.g. Ministry) or can be a more general government role (e.g., Legal

Department, Technical Wing etc.)

(ii) Lanes: It is a sub-partition within a Pool and will extend the entire length of

the Pool, either vertically or horizontally. Lanes are used to organize and

categorize activities. These may be used as Internal Roles (e.g. Joint

Secretary, Deputy Secretary etc.), Systems (e.g. ERP), Internal Department

(e.g. Development, Admin etc.)

Artifacts: Artifacts are used to provide additional information about the Process. There

are 03 standardized Artifacts

(i) Data Object: Data Objects are considered Artifacts because they do not

have any direct effect on the Sequence Flow or Message Flow of the Process,

but they do provide information about what activities require to be performed

and / or what they produce.

(ii) Group: A grouping of activities that does not affect the Sequence Flow. The

grouping can be used for documentation or analysis purposes.

(iii) Annotation: Text Annotations are a mechanism for a modeler to provide

additional information for the reader of a BPMN Diagram





APPENDIX – B: Use Case Diagram

Description: In this Use Case diagram, there are six use cases, Namely Employee,

Qualification, Training, PER, Posting History & Promotion Consideration. User will first

enter Employee basic Information & then other related Information as shown in the

figure. Promotion Consideration is derived from Qualification, Training & PER

(Personal Evaluation Report). On the basis of these three, Promotion Consideration

takes place.



APPENDIX – C: Class Diagram

EmployeeEmp_IdEmp_NameGenderReligionDepartment

PERPeriod FromPeriod ToGradeEmp_Id

TrainingTrainig_IdCourse/TrainigLocationInstituteEmp_Id

Promotion considertionGradePromotion_DateAuthorityRemarksEmp_IdPosting History

Posted AsBPSDepartmentPeriod FromPeriod ToEmp_Id

QualificationQualification_IdNameEducationYear of Passingname2Emp_Idname3

Description: In the above diagram Employee is the main Class. This class contains

Employee Personal information. Qualification Class contains information about

Employee Education. While Training Class explains Training / Courses information

plus location & Institute in which Employee got trained. Similarly Posting History Class

is for recording Posting History, Department in which he served & also his BPS Status.

PER class is for storing Employee Evaluation Report. Promotion Consideration Class

contains Information about Employee Promotion Status. Moreover Promotion depends

upon qualification, Trainings, & PER report.



APPENDIX – D: Component Diagram

Employee

Promotion Consideration

PER

Qualification

Posting History

Training

Component Diagram

Description: As component diagram describes the organization of physical software

components. Here we have six main components. All components are dependent on

Employee Component. As all components are connected to Employee component. All

Components have relationship with Employee.



APPPENDIX – E: Deployment Diagram

Web Browser

preemptiv e

Application Server

User will access the Employee info from Establishment Div Application

(Establishment Div Application hosted on the Server)

Client Request

Response

Description: Deployment diagram describes the physical resources of the system. In

this diagram there are two nodes namely Web Browser & Application Server. Client

send request to Application Server via Web Browser & application server responds to

client.



APPENDIX – F: Activity Diagram

Description: In this activity diagram, user first record Employee basic information. After

this Next two activities takes place simultaneously. i.e. Qualification Information &

Training information. These two activities lead to (PER) Personal Evaluation Report.

PER results in Employee Promotion. Which is last activity. Also there is an activity

named Posting History which is independent of all activities



APPENDIX- G: Sequence Diagram

:TrainingWeb Browser :Employee :Qualification :PER :Posting History :Promotion Consideration

Database ServerUser

User Access Application

Unauthorized Login

Request

Request

Response

Response

Response

Response

Response

Response

Response

Request

Request

Request

Request

Request

User Access Emp Info

Successful/ Unsuccessful






User Access Qualification Info

User Access Training Info

User Access PER info

User Access Posting History

User Access Promotion Info



APPENDIX – H: Issue Card & Factor Table

Issue:- Change in Software As the technology grows there is a need to accommodate the new software technologies in the system. Further more the system will interact with verity of software systems and technologies. These software systems and technologies are expected to be change time to time. Influencing Factors

• The changes in the Operating system technologies. • New trends in the image processing. • More and more powerful encryption techniques. • New ideas in the DBMS systems.

Solution As we follow the CBD (Component based development) the system will exhibit the loose coupling so the changes will be easily accommodated. Strategy System components which use this software can be made cohesive and interaction with this software should be loose. Related Strategy

Factor Table

Factor Flexibility / Changeability Impact

The changes in the Operating system technologies.

Operating system will be upgraded after one year.

Operating system should be upgraded after one year and the impact of this upgrading should be minimum.



APPENDIX- I: System Features

System Features: System contains the following features:

1) Security:

Description: This system will provide high level security regarding authentication,

permissions & user verification.

Stimulus / Response Sequence: If unauthorized user tries to enter the system, it will

not allow & will send a message. Also if a user mistakenly enters invalid data, system

will not save it & will send error message.

Functional Requirements: System will be able to search Employee Information in a

secure way. System will make it easy to get Employee status, his qualification

information, trainings attended, his posting history & Performance Evaluation Report.

It will minimize the manual work & system will be able to find which Employee is

eligible for promotion. System will generate a detail report of all Employees. In this

way only those employee will be promoted who are really eligible on basis of their

qualification, trainings & Performance report. All these activities will be done in safe

mode.

2) Officers Management:

Description: This system will be able to manage officers, their personal information &

all other related information regarding qualification, Training etc.

Stimulus/ Response Sequence: If user mistypes any mandatory field, system will not

allow it & will send an error message.

Functional Requirements: System will manage key information of over all employees

in the context of their joining date, department name & qualification. On the basis of

these information their designation, BPS & their salary will be managed.

3) Flexibility:

Description: This Application will be designed for multiple users to work at a time.



Stimulus / Response Sequence: If multiple users work at a time & application hangs

up then there will be a mechanism to overcome the problem.

Functional Requirements: This will be scalable from a single screen to much more

screens. The flexibility of the application allows numerous users to manage their

related work. All the work done will be stored in the database.

Documents

E Government Standards