E-Government Standards

E-GOVERNMENT STANDARDS
E - GOVERNMENT STANDARDS
Draft Version
2009
Government of Pakistan
Ministry of Information Technology
Electronic Government Directorate
Prepared by: Strategic Planning & Architecture Wing, EGD
E-Government Directorate, Ministry of IT 1/164

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.
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 BPMN 1.x should be adopted as standard for

To Follow
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.
Inbound Assessment Review Outbound services

services services services
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).

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
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 UML 2.x is standard to document the following

Follow
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.

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.


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 UML 2.defacto x is standard for this section

Follow
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 Following table is recommended as standard for
Follow this section.
Quality Description
Attribute
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 Following diagram of UML 2.x is recommended as

Follow
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.

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.


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 Service Oriented Architectural implementation

Standard
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.
Recommended Web Services-Interoperability Organization (WS-I)

Standard
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.
Recommended • Web Service Definition Language (WSDL)

Standard
• 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.
Recommended OASIS WS-Security Specification

Standard
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.
Recommended • OASIS WS-Reliable Messaging

Standard
• 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.
Recommended • Business Transactions Protocol (BTP)

Standard
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 The following will act as a standard for testability

Standard
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 Following three considerations will act as standard for modifiability

Standards
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 E-government services should be
without changing the loosely coupled; adding capabilities
interfaces. should not require a change in the
service interface can be done without
affecting service users.
Extend existing services New capabilities that require changes

with changes to to the service interface may have a
interfaces. 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.
Recommended The following will act as a standard for testability

Standards
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.

Recommended The following will act as a standard for usability in

Standards
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.
Recommended Following are the standard strategies to improve

Standards
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.
Value Should be from relevant country.

Default value Islamabad Capital Area.
Owner SP & A Wing
Based On
Verification One or more of the following Certificates are required for verification
purpose.

• 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.
• 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

• Passport
• 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.
Value Should be from District List maintained by EGD.

Owner SP & A Wing
Based On

• Passport
• Domicile
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.
Value Should be from Tehsil List maintained by EGD.

Owner SP & A Wing
Based On
purpose.

• Passport
• Domicile
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.
Value Should be from Tehsil List maintained by EGD.

Default value Larkana
Owner SP & A Wing
Based On

• Passport
• Domicile
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.
Value Should be from Sector List maintained by EGD.

Default value G-6
Owner SP & A Wing
Based On
purpose.

• Passport
• Domicile
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.
Value Should be from Village List maintained by EGD.

Default value
Owner SP & A Wing
Based On

• Passport
• Domicile
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.
Value Should be from Town List maintained by EGD.

Default value
Owner SP & A Wing
Based On

• Passport
• Domicile
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.
• The first character of each occurrence must be ‘C’ and ‘N’.
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
• Transfer Deed
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.
• The first character of each occurrence must be 0- 9.
Value Should be from Varchar (50)

Default value
Owner SP & A Wing
Based On
• Transfer Deed
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
• Transfer Deed
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
• Transfer Deed
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
• Can not have two Fax No in a single row.

Validation
• 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
purpose.

• 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.

2. City Code
3. Phone No
4. Ext No
XML Schema

• Can not have two Phone No. in a single row.

Validation
• The first character of each occurrence must be from 0- 9.
Value
Default value
Owner SP & A Wing
Based On
purpose.
• Official Card.
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.


2. Carrier Code
3. Mobile No
XML Schema
• Can not have two Mobile No. in a single row.

Validation
• The first character of each occurrence must be from 0- 9.
Value
Default value
Owner SP & A Wing
Based On
purpose.
• Official Card.
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
• Can not have two Website URL in a single row.

Validation
• 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
• Can not have two Emails in a single row.

Validation
• Consecutive spaces are not allowed within single word while writing
Email address.
Value
Default value
Owner SP & A Wing
Based On
purpose.
• Official Card.
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
purpose.

• Passport
• 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
• Can not have two Titles in a single row.

Validation
Default value
Owner SP & A Wing
Based On

purpose.

• Passport
• 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
• Can not have two Names in a single row.

Validation


Default value
Owner SP & A Wing
Based On
purpose.

• Passport
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
Default value
Owner SP & A Wing
Based On
purpose.

• Passport
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
• Can not have two Places in a single row.

Validation
Default value
Owner SP & A Wing
Based On
purpose.

• Passport
• 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
• Can not have two Places in a single row.

Validation
Default value
Owner SP & A Wing
Based On
purpose.
• 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

purpose.
• Metric Certificate.
• National Health Service Medical Card
• Child's Certificate of Vaccination
• Certificate or testimonial from employer.
• Passport.
• Life insurance policy.
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
purpose.
• 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
Default value
Owner SP & A Wing
Based On
purpose.

• Passport
• Domicile
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
• Can not have 'S','M','W' in a single row.

Validation
• The first character of each occurrence must be 'S','M','W'
Value Should be from 'S','M','W'
Default value
Owner SP & A Wing
Based On
purpose.

• 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
• Can not have more than one relationship in a single row.

Validation
Value • None
• Christian
• Buddhist
• Hindu
• Jewish
• Muslim
• Sikh
• Any other religion (please write in)
Default value
Owner SP & A Wing
Based On

purpose.
• 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
• Can not have 'F','M' in a single row.

Validation

Value Should be from 'F','M'
Default value
Owner SP & A Wing
Based On
purpose.

• 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
• Should be Image.
Validation
• No Text Item.
Value
Default value
Owner SP & A Wing
Based On
purpose.
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
• Always in Number
Validation
Value
Default value
Owner SP & A Wing
Based On
purpose.

• 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
• Can not have two Nationalities in a single row.

Validation
Value
Default value
Owner SP & A Wing
Based On
purpose.

• Passport
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 The current processes of the organization are called
Processes 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 The business model is a conceptual tool that contains a
Model certain set of notations and their relationships for
expressing the business logic.
Business A diagram representing the business processes of an
Process organization or enterprise by using the BPMN notations
Diagram (BPD)
Business Business Process Execution Language for Web
Process Services BPEL4WS as defined by the BEA, IBM,
Execution Microsoft, SAP AG and Siebel
Language http://www-106.ibm.com/developerworks/library/ws-bpel/
(BPEL) It is a language for specifying business process
behaviour based on Web Services
Business Business process management (BPM) is an approach
Process that promotes business effectiveness and efficiency
Management while striving for innovation, flexibility and integration
(BPM) 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 Business Process Modelling is the activity of
Process representing both the current ("as is") and future ("to
Modelling be") processes of an enterprise, so that the current
process may be analyzed and improved.
Business BPML is "a meta-language for the modelling of business
Process processes, just as XML is a meta-language for the
Modelling modelling of business data.
Language
(BPML)
Business The standardized graphical notation for drawing
Process business processes in a workflow. Its current adopted
Modelling version is 1.1 and the proposed one is 2.0
Notation http://www.bpmn.org/
(BPMN)
Business It is a management approach aiming at improvements
Process by means of elevating efficiency and effectiveness of the

Reengineering processes that exist within and across organizations

(BPR)
Collaborative A collaboration process depicts the interactions between
Processes 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 The processes which are executed by all Government
Processes entities e.g. HR , Budgeting , Project Management,
Inventory & Procurement etc.
Core The processes that are executed by a certain agency
Processes 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 These processes are internal business processes of an
Processes organization. these process are also called
organizational workflows.
Process
Effectiveness
Process
Efficiency
Public This represents the interactions between a private
Processes 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)

Remarks
Activity It is a type of behavioural diagram defined by the UML It
Diagram 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 It is a type of structure diagram defined by the UML and
Diagram 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 It is a type of structure diagram defined by the UML. It
Diagram model the hardware used in system implementations,
the components deployed on the hardware, and the
associations between those components.
Design & The items or issues that will limit the options available to
Implementation the developers e.g. regulatory policies , hardware
Constraints limitations , interfaces to other components etc.
Extensibility
Mechanisms
External
Interfaces
Factor Table
Functional It defines what a software system or its component is
requirements supposed to do. A function is described as a set of
inputs, the behaviour, and outputs.
Hardware The logical and physical characteristics of each interface
Interfaces between the software product and the hardware
components of the system.
Issue Card
Microsoft GUI
Standards
Non- functional It defines how a software system or its component is
requirements 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 The environment in which the software will operate,
Environment including the hardware platform, operating systems and
their versions or any other software components or
applications.
Performance Constraints for regarding performance issues must
Requirements 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 Portable Operating System Interface is the collective
1003) 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 The major functions that product must perform or must
Functions let the end-users to perform.
Protocols
Safety
Requirements
Sequence It is a type of interaction diagram defined by the UML. It
Diagram 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 The connections between this product and other specific
Interfaces software components including databases, operating
systems, tools, libraries and commercial off the shelf
components.
Software The quality characteristics of the product that will be
Quality important either for customers or the developers. e.g.
Attributes adaptability, availability, correctness, interoperability etc.
Software A document that contains the complete descriptions of
Requirements the behaviour of the system to be developed.
Specifications
(SRS)
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 It is a type of behavioural modelling diagram in UML. It is used to
Diagram 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)

Remarks
Architectural The design decisions and / or strategies that affect the
Strategies 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 The kinds of components, such as subsystem, module,
a Component 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 The specific purpose and semantic meaning of a
Component 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 It describes the detailed description of system software
System Design 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 It provides a common framework for developing and
12207.1-1997 managing software that includes inception, elaboration,
testing and transition phases.
Interfaces of a The set of services (resources, data, types, constants,
Component subroutines, and exceptions) that are provided by this
component.
Interoperability
requirements

Memory
Management
Policies
Package It is a type of structure diagram defined by the UML that
Diagram 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 It describes what does a component accomplish? What
of a role does it plays? What kind of services does it provide
Component to its clients?
Software A blueprint or model of the software system to be
Design created. It is primary medium for communicating
Document software design information.
Software
Interface
Paradigms
Software life The period of time that starts when a software product is
Cycle conceived and ends when the product is no longer
available for use.
State Machine It is a type of behavioural diagram defined by the UML
Diagram 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 It describes how the system architecture components
Architecture are further subdivided into subcomponents, and the
relationships and interaction between sub-components
System A high level overview of how the functionality and
Architecture 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 It is designed to allow coordination of application work
Transaction between multiple participants or controlled by
Protocol (BTP) 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 It provides a Universal Messaging Backbone on
Sphere MQ 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 Microsoft Message Queuing (MSMQ) technology
Message enables applications running at different times to
Queuing communicate across heterogeneous networks and
(MSMQ) 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/technolog
ies/msmq/default.mspx
Modifiability It is the ability to make changes to a system quickly and
cost effectively.
OASIS WS- WS-Reliability is SOAP based specification that fulfills
Reliable reliable messaging requirements critical to application of
Messaging web services.
http://docs.oasis-open.org/wsrm/ws-reliability/v1.1
/wsrm-ws_reliability-1.1-spec-os.pdf
OASIS WS- It defines a standard set of SOAP extensions that can
Security 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 The SOAIF envisions a comprehensive framework that
Oriented provides all the technology that an enterprise might
Architectural need to build and run an SOA. An SOAIF includes both
Implementation design-time and run-time capabilities as well as all the
Framework software functionality an enterprise needs to build and
(SOAIF) operate an SOA.
Service Service-oriented architecture (SOA) is a software
Oriented architecture where functionality is grouped around
Architecture business processes and packaged as interoperable
(SOA) 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 The service operates correctly and either does not fail or
Reliability reports any failure to the service user.
Service It is used to define a set of protocols to coordinate the
Transaction outcomes of distributed application actions.
(Ws-Tx) http://msdn.microsoft.com/en-us/library/ms951262.aspx
Simple Object SOAP is a protocol for exchanging XML-based
Access messages over computer networks, normally using
Protocol HTTP/HTTPS. SOAP forms the foundation layer of the
(SOAP 1.2) 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 WSDL is an XML format for describing network services
Description as a set of endpoints operating on messages containing
Language either document-oriented or procedure-oriented
(WSDL) 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 – The Web Services Interoperability Organization (WS-I)
Interoperability is an open industry organization chartered to establish
(WS-I) Best Practices for Web services interoperability, for

Organization selected groups of Web services standards, across

platforms, operating systems and programming
languages.
World Wide The World Wide Web Consortium develops
Web interoperable technologies (specifications, guidelines,
Consortium software, and tools) to lead the Web to its full potential.
(W3C)
Table 5 Specifications for Testing Standards

Remarks
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 The dependencies between the test case to identify that
Dependencies 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 It is a report to document the specific inputs, predicated
Specification results, and a set of execution conditions for test item.
Test Case An identifier used to identify the test case specification
Specification Identifier
Test Design A report that will specify the test approach for a software
Specification feature or combination of software features and
identifying the associated tests.
Test Design An identifier used to identify the test design
Specification Identifier 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 It will classify all the steps required to exercise the
Specification specified test cases in order to implement the
associated test design.
Test Procedure An identifier used to identify the test procedure
Specification Identifier 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
• 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.
Integration
• Bus needs to support Transformation and
Pattern
Mediation
Support
• 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
• Support for MQ and JMS
Protocol
• Support for File System protocols
and Format
Mediator • Support for ODBC/JDBC
• Support for JMS transports.
Transports • Support for MQ transport.
• Support for HTTP/S transport.
• GSB needs to work with external Security
Providers
Security • GSB needs to support Authentication
services.
• GSB needs to support Authorization services.
Web
Services • GSB needs to work with Web Services
Manageme management components.
nt
Monitorin • GSB needs to support monitoring services

g and • GSB needs to support tracing and logging
Tracing services
• GSB needs to support scalability.
Quality of • GSB needs to support Transaction / XA.
Service • GSB needs to support and work with Reliable
Messaging.
Exception • Retry
Handing • Logging
Message • EMF
Format • 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
Qualification PER
Qualification_Id Period From
Name Period To
Education Grade
Year of Passing Emp_Id
name2
Emp_Id
name3
Employee
Emp_Id
Emp_Name
Gender
Religion
Department
Training
Promotion
Trainig_Id considertion
Course/Trainig
Grade
Location
Promotion_Date
Institute
Authority
Emp_Id
Remarks
Posting History Emp_Id
Posted As
BPS
Department
Period From
Period To
Emp_Id
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
Component Diagram
Employee
Promotion
Consideration
Qualification
Posting
History PER
Training
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
Client Request
Web Browser Application Server
User will access the
Employee info from (Establishment Div
Establishment Div Application hosted
Application on the Server)
preemptiv e
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
Web Browser :Em ployee :Qualification :Training :PER :Posting History :Promotion Database Server
Us er
Consideration
User Access Request

Application
Unauthorized
Login Response
User Access
Emp Info Request
Successful/
Unsuccessful Response
User Access
Qualification Info Request
Response
Successful/
Unsuccessful
User Access
Training Info Request
Successful/ Response
Unsuccessful
User Access PER

info Request
Success ful/
Unsucces sful Response
User Acces s Posting

History Reques t
Successful/ Response
Unsuccessful
User Access
Prom otion Info
Request
Success ful/
Unsucces sful Response

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
Operating system should

The changes in the Operating system will be be upgraded after one year
Operating system upgraded after one year. and the impact of this
technologies. 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.

E-Government Standards

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

E-Government Standards

Uploaded by

Copyright:

Available Formats

E-GOVERNMENT STANDARDS

Prepared by: Strategic Planning & Architecture Wing, EGD

E-Government Directorate, Ministry of IT 1/164

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

3 SERVICE ENGINEERING…………………………………………………………….……… .32

6 PAKISTAN GOVERNMENT DATA STANDARDS CATALOGUE………………...……………. 75

8 WHAT NEXT?...................................................................................................................... 147

E-Government Directorate, Ministry of IT 2/164

The following are the main objectives of developing Standards.

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

E-Government Directorate, Ministry of IT 3/164

E-Government Directorate, Ministry of IT 4/164

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

• Help government agencies to work more easily together electronically.

Interoperability is not just a methodological substance of connecting computer

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

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

E-Government Directorate, Ministry of IT 5/164

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

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

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

• Common reference architectural model

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

E-Government Directorate, Ministry of IT 6/164

technology investments and avoiding unnecessary duplication of infrastructure and

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

E-Government Directorate, Ministry of IT 7/164

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

E-Government Directorate, Ministry of IT 8/164

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

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

E-Government Directorate, Ministry of IT 9/164

Service Oriented Architectural implementation framework (SOAIF) is recommended as

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

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

E-Government Directorate, Ministry of IT 10/164

E-Government Directorate, Ministry of IT 11/164

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

Service Oriented Architectural implementation framework (SOAIF) is recommended as

E-Government Directorate, Ministry of IT 12/164

E-Government Directorate, Ministry of IT 13/164

e- Government Interoperability Framework

E-Government Directorate, Ministry of IT 14/164

1 Common Architectural Reference Model

1.1 Business Architecture

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

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

• The degree of commonality in business processes

• A commitment to streamlining and standardizing business processes around

E-Government Directorate, Ministry of IT 15/164

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

The Essence of Business Process Architecture

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

These processes are actually internal business process of a certain specific

This type of modeling represents the interactions between a private business

E-Government Directorate, Ministry of IT 16/164

o Business interoperability components (Collaborative Components)

Delineating a standardized and uniform set of processes within government

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

E-Government Directorate, Ministry of IT 17/164

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

Common Business Processes

E-Government Directorate, Ministry of IT 18/164

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