& Architecture

System Integration

System Integration & Architecture 09/11/22

 Introduction

09/11/22
• Many systems are built to easy, improve and
transform organizations.

System Integration & Architecture

• Some organizations have many departments which
run systems which are independent of each other.
• And systems built sometimes, may not have an
abstract view (architecture) which leads to failure
of system interoperability.
• There is need to have architectural view of the
system as a priority to help in the design to avoid
the likeliness of system failure. 2
 Introduction

09/11/22
• Besides after the system has been designed and developed in
consideration of the size of the organization, i.e. most

System Integration & Architecture

especially when the organization is large, need is required to
integrate such systems to ensure flexibility, Speed, Cost ,
Standardization, Data integrity, reliability and robustness.
• This can help Information Technology (IT), energy, and
financial services industry among others to have an easy to
use integrated system. 3
What students need to know

09/11/22
• Systems Integration (SI) process, approaches,
drivers, tools and techniques required for successful

System Integration & Architecture

SI, critical success factors, and best practices.
• The course focuses on how a proposed system will
be integrated with other existing or planned
systems.
• It addresses the System Integration problem using
architectures as the basis and then addresses the
evaluation of the architectures in terms of the
capabilities they provide. 4
What students need to learn

09/11/22
System Integration & Architecture
• The theory and practice of business process integration,

legacy integration, new systems integration, business-to-

business integration, integration of commercial-off-the-

shelf (COTS) products, interface control and

management, testing, integrated program management,

integrated Business Continuity Planning (BCP). 5

 Aims

09/11/22
• To provide the students an understanding
of the technical and business process issues

System Integration & Architecture

involved in systems integration.

6
Learning outcomes

09/11/22
• On completion of this course, the students will be
able to:

System Integration & Architecture

• Identify integration issues upfront in the
process of System Integration and should be
able to identify the best practices that ensure
successful System Integration.
• Have an understanding of the technical and
business process issues involved in systems
integration.
7
Teaching and learning

09/11/22
pattern
• Teaching this course will be in lecture
form. A number of case studies will also be

System Integration & Architecture

used to illustrate some concepts as
mentioned in the indicative content.

8
 Indicative content

09/11/22
• The System of Systems Integration Problem
• Human, Organizational, Societal Cultural, Economic,

System Integration & Architecture

and Technological aspects;
• Processes, approaches, drivers, tools and techniques required
for successful SI, critical success factors, and best practices in
Systems Integration;
• The Role of Architectures in Systems Integration;
• Integration in a System of Systems and a Federation 60 of
Systems;
• Model Based Architecture, Design, and Integration;
• Systems of Systems Interoperability;
• Evaluation of architectures; 9
• Measures of Performance and Effectiveness;
 Indicative content

09/11/22
• Assessment of System Capabilities;
• Analysis of Alternatives;

System Integration & Architecture

• Case studies and examples from the Information Technology
(IT), energy, and financial services industry to illustrate the
concepts discussed.
• The theory and practice of business process integration,
legacy integration, new systems integration, business-to-
business integration, integration of commercial-off-the-
shelf (COTS) products, interface control and
management, testing, integrated program management,
integrated Business Continuity Planning (BCP). Specific
focus will be given to issues of interface integration and 10
interoperability of systems.
 Assessment method

09/11/22
• Assessment will be in form of tests and
practical assignments (40%) and final

System Integration & Architecture

written examination (60%)

11
 Reference books

09/11/22
• Sage A.P. and Rouse, W.B. Handbook of Systems
Engineering and management, John Wiley &

System Integration & Architecture

Sons, 1999.

12
Key terminologies in this

09/11/22
course
• Various key terminologies shall be used
throughout this course as follows
• System

System Integration & Architecture

• Systems thinking
• System Integration
• System Architecture
• Project

13
 System

09/11/22
• An array of components designed to
accomplish a particular objective according to

System Integration & Architecture

plan. Many sub-systems many be designed
which later on are combined together to form a
system which is intended to achieve a specific
objective which may be set by the Project
manager.

14
Systems thinking

09/11/22
Is a way of understanding an entity in terms of its purpose, as
three steps
The three major steps followed in systems thinking

System Integration & Architecture

1. Identify a containing whole (system), of which the thing to be
explained is a part.
2. Explain the behavior or properties of the containing whole.
3. Explain the behavior or properties of the thing to be explained
in terms of its role(s)or function(s) within its containing whole
(Ackoff, 1981)

15
System Integration

09/11/22
• Is the combination of inter-related elements to achieve a
common objective (s).

System Integration & Architecture

16
 System Architecture

09/11/22
• The architecture of a system defines its high-level structure,
exposing its gross organization as a collection of interacting
components.

System Integration & Architecture

• Elements needed to model a software architecture include:
• Components, Connectors, Systems, Properties and Styles.

17
What is a project?

09/11/22
• From the key terms described above, a system developer and
architects cannot do anything without first establishing various
projects. These projects may be new or existing.

System Integration & Architecture

• So it is inevitable to first understand what a project is, factors
that influence the project, who the owners are and many more
as discussed below.

18
What Is a Project?

09/11/22
• A project is a temporary endeavor undertaken to

System Integration & Architecture

accomplish a unique product or service
• Attributes of projects
• unique purpose
• temporary
• require resources, often from various areas
• should have a primary sponsor and/or customer
• involve uncertainty

19
 Where do information Systems Projects

09/11/22
Originate (Sources of Projects)?
New or changed IS development projects come from problems,
opportunities, and directives and are always subject to one or more
constraints.

System Integration & Architecture

1.Problems – may either be current, suspected, or anticipated.
Problems are undesirable situations that prevent the business from
fully achieving its purpose, goals, and objectives (users discovering
real problems with existing IS).

2. An Opportunity – is a chance to improve the business even in the

absence of specific problems. This means that the business is hoping
to create a system that will help it with increasing its revenue, profit,
or services, or decreasing its costs.

3.A Directive – is a new requirement that is imposed by 20

management, government, or some external influence i.e. are
mandates that come from either an internal or external source of the
business.
Projects Cannot Be Run in Isolation

09/11/22
System Integration & Architecture
• Projects must operate in a broad organizational
environment
• Project managers need to take a holistic or systems view
of a project and understand how it is situated within the
larger organization

21

21
Stakeholders

09/11/22
• Stakeholders are the people involved in or affected by

System Integration & Architecture

project activities
• Stakeholders include
• the project sponsor and project team
• support staff
• customers
• users
• suppliers
• opponents to the project

22
Importance of Stakeholders

09/11/22
• Project managers must take time to identify,
understand, and manage relationships with all

System Integration & Architecture

project stakeholders
• Using the four frames of organizations can help
meet stakeholder needs and expectations
• Senior executives are very important
stakeholders

23
Table 2-2. What Helps Projects

09/11/22
Succeed?
According to the Standish Group’s report
“CHAOS 2001: A Recipe for Success,” the

System Integration & Architecture

following items help IT projects succeed, in order
of importance:
• Executive support
• User involvement
• Experienced project manager
• Clear business objectives
• Minimized scope
• Standard software infrastructure
• Firm basic requirements
• Formal methodology 24
• Reliable estimates

24
Understanding Organizations
We can analyze a formal organization using the following 4

09/11/22
(four) frames;
Structural frame: Human resources frame:

System Integration & Architecture

Focuses on roles and Focuses on providing
responsibilities, harmony between needs of
coordination and control. the organization and needs
Organizational charts of people.
help define this frame.
Political frame: Symbolic frame:
Assumes organizations Focuses on symbols and
are coalitions composed meanings related to events.
of varied individuals and Culture is important.
25
interest groups. Conflict
and power are key issues.
25
Many Organizations Focus on the
Structural Frame

09/11/22
• Most people understand what organizational charts are

System Integration & Architecture

• Many new managers try to change organizational structure when other
changes are needed
• 3 basic organizational structures
• Functional-
• project
• matrix

26

26
Basic Organizational Structures

09/11/22
• Organizational structure depends on the company and/or the
project.
• The structure helps define the roles and responsibilities of

System Integration & Architecture

the members of the department, work group, or
organization.
• It is generally a system of tasks and reporting policies in
place to give members of the group a direction when
completing projects.
• A good organizational structure will allow people and
groups to work effectively together while developing hard
work ethics and attitudes.
• The four general types of organizational structure are
27
functional, divisional, matrix and project-based.
Basic Organizational Structures

09/11/22
• Functional Structure - People who do similar tasks,
have similar skills and/or jobs in an organization are
grouped into a functional structure. The advantages of

System Integration & Architecture

this kind of structure include quick decision making
because the group members are able to communicate
easily with each other. People in functional structures can
learn from each other easier because they already possess
similar skill sets and interests.
• Divisional Structure - In a divisional structure, the company will
coordinate inter-group relationships to create a work team that can
readily meet the needs of a certain customer or group of customers.
The division of labor in this kind of structure will ensure greater
output of varieties of similar products. An example of a divisional
structure is geographical, where divisions are set up in regions to
work with each other to produce similar products that meet the needs
of the individual regions. 28
Basic Organizational Structures

09/11/22
• Matrix Structure - Matrix structures are more complex in
that they group people in two different ways: by the function
they perform and by the product team they are working with. In a

System Integration & Architecture

matrix structure the team members are given more autonomy and
expected to take more responsibility for their work. This
increases the productivity of the team, fosters greater innovation
and creativity, and allows managers to cooperatively solve
decision-making problems through group interaction.
• Project Organization Structure - In a project-organizational
structure, the teams are put together based on the number of
members needed to produce the product or complete the project.
The number of significantly different kinds of tasks are taken
into account when structuring a project in this manner, assuring
that the right members are chosen to participate in the project.
29
 Structures
Basic Organizational

System Integration & Architecture 09/11/22

30

30
Project Phases and the Project Life

09/11/22
Cycle

System Integration & Architecture

• A project life cycle is a collection of project phases
• Project phases vary by project or industry, but some general
phases include
• concept
• development
• implementation
• support

31

31
 System Integration & Architecture 09/11/22
32
Phases of the Project Life Cycle

32
Product Life Cycles

09/11/22
Products also have life cycles

System Integration & Architecture

The Systems Development Life Cycle (SDLC) is a
framework for describing the phases involved in
developing and maintaining information systems

Systems development projects can follow

Predictive models: The scope of the project can be clearly articulated and
the schedule and cost can be predicted.
Adaptive models: Projects are mission driven and component based, 33
using time-based cycles to meet target dates.

33
Predictive Life Cycle Models

09/11/22
The waterfall model has well-defined, linear stages of systems
development and support.

System Integration & Architecture

The spiral model shows that software is developed using an
iterative or spiral approach rather than a linear approach.

The incremental release model provides for progressive

development of operational software.

The prototyping model is used for developing prototypes to

clarify user requirements.
34
The RAD model is used to produce systems quickly without
sacrificing quality.
 Adaptive Life Cycle Models

09/11/22
Extreme Programming (XP): Developers program

System Integration & Architecture

in pairs and must write the tests for their own code.
XP teams include developers, managers, and users.

Scrum: Repetitions of iterative development are

referred to as sprints, which normally last thirty days.
Teams often meet every day for a short meeting, called
a scrum, to decide what to accomplish that day. Works
best for object-oriented technology projects and
requires strong leadership to coordinate the work 35

35
Distinguishing Project Life Cycles

09/11/22
and Product Life Cycles

System Integration & Architecture

• The project life cycle applies to all projects, regardless of the products
being produced
• Product life cycle models vary considerably based
on the nature of the product
• Most large IT systems are developed as a series of projects
• Project management is done in all of the product life cycle phases

36

36
Why Have Project Phases and

09/11/22
Management Reviews?

System Integration & Architecture

• A project should successfully pass through each of the project
phases in order to continue on to the next

• Management reviews (also called phase exits or kill points) should

occur after each phase to evaluate the project’s progress, likely
success, and continued compatibility with organizational goals

37

37
System Development Life
Cycle

09/11/22
(Kendall & Kendall terminology)

System Integration & Architecture

38
 Topic 1
Requirements

System Integration & Architecture 09/11/22

39
Requirements

09/11/22
• A system cannot be analyzed, designed, implemented and
evaluated unless the problem is understood and requirements
elicited.

System Integration & Architecture

• Requirements are fundamental basis of all the system
development processes.
• System architects will always base of the requirements elicited
by the system analyst to design an architectural view of the
system. Besides much as the system is designed and there is
need for integration say business process integration, legacy
integration, new systems integration, business-to-business
integration, integration of commercial-off-the-shelf (COTS)
products, interface control and management, testing, integrated
program management, integrated Business Continuity Planning
(BCP), requirement is the basis. 40
Sub Topics

09/11/22
Requirements elicitation,
documentation, and maintenance

System Integration & Architecture

Modeling tools and methodologies
Using Unified Modeling Language
Testing

41
 Core learning outcomes:

09/11/22
• Compare and contrast the various requirements modeling techniques.
• Distinguish between non-functional and functional requirements.
• Identify and classify the roles played by external users of a system.

System Integration & Architecture

• Explain and give examples of use cases.
• Explain the structure of a detailed use case.
• Detail a use case based on relating functional requirements.
• Describe the types of event flows in a use case and under which
conditions they occur.
• Explain how requirements gathering fits into a system development
lifecycle.
• Explain how use cases drive testing throughout the system lifecycle.
42
What are requirements?

09/11/22
• Requirements are statements that identify the
essential needs of a system in order for it to have

System Integration & Architecture

value and utility.

43
Characteristics of Good Req’ts

09/11/22
• 1. Describes What, Not How.
• 2. Atomic. i.e., it should have a single purpose
• 3. Unique.

System Integration & Architecture

• 4. Documented and Accessible.
• 5. Identifies Its Owner.
• 6. Approved. After a requirement has been revised, reviewed,
and rewritten, it must be approved by its owner.
• 7. Traceable. A good requirement is traceable; it should be
possible to trace each requirement back to its source.
• 8. Necessary.
44
Characteristics of Good Req’ts

09/11/22
cont….
• 9. Complete.
• 10. Unambiguous
• 11. Quantitative and testable

System Integration & Architecture

• 12. Identifies applicable states
• 14. States Assumptions. All assumptions should be stated.
• 15. Use of Shall, Should, and Will. A mandatory requirement
should be expressed using the word shall (e.g., "The system shall
conform to all state laws
• 16. Avoids Certain Words. The words optimize, maximize, and
minimize should not be used in stating requirements, because we
could never prove that we had achieved them. 45
 Requirements Life cycle

09/11/22
SPECS
Analys Complet
Raw Organise ed e user

System Integration & Architecture

The Req’ts d Req’ts Req’ts Req’ts
User

Elicitation Organisati Analysis Prototype Transform

Phase on Phase Phase Phase to spec

46
Requirement Life Cycle .. Cont..

09/11/22
Elicitation Phase
The starting point of the requirements engineering process is an elicitation
process that involves a number of people to ensure consideration of a

System Integration & Architecture

broad scope of potential ideas and candidate problems
Organisation Phase
In this step there is no transformation of the requirements, but simple
classification and categorization. For example, requirements may be
grouped into functional vs. nonfunctional requirements.
Analysis Phase
This represents a transformation.

47
Requirement Life Cycle ..

09/11/22
Cont..
Prototype Phase
In this way poorly understood requirements may be tested and

System Integration & Architecture

perhaps strengthened, corrected, or refined. This activity is
often done as a proof of concept and serves to induce feedback
from both the stakeholders and engineers.
Requirements documentation and specification
This represents the requirements as the finished product of the
stakeholder requirements team. The requirements are compiled
into a requirements list or into some equivalent document
format. These collected requirements are then transformed into
a specification.
48
Requirements
elicitation,

09/11/22
documentation, and

System Integration & Architecture

maintenance

49
Requirements elicitation

09/11/22
• Requirements determination addresses the
gathering and documenting of the true and

System Integration & Architecture

real requirements for the Information System
being developed.

• Requirements is the wants and /or needs of the

user within a problem domain. elicit

50
Requirements determination

09/11/22
questions
• Requirements determination questions
• Who does it?

System Integration & Architecture

• What is done?
• Where is it done?
• When is it done
• How is it done
• Why is it done?

51
 09/11/22
Systems Requirements
• Characteristics or features that must be included to
satisfy business requirements

System Integration & Architecture

• Outputs
• Inputs
• Processes
• Timing
• Controls
• Volumes. sizes, and frequencies

• Data/Information collected can be about; people,

organisation, work and work environment.
52
Fact – Finding Methods

09/11/22
• Sampling (of existing documentation, forms, and
databases).
• Research and site visits. (Participation)

System Integration & Architecture

• Observation of the work environment.
• Questionnaires.
• Interviews.
• Prototyping.
• JAD/Joint requirements planning (JRP).

53
 Types of Requirements

09/11/22
User Requirements: these are statements in Natural language plus
diagrams of services the system provides, together with its operational
constraints. These can be categorised into 2; functional requirements and
non-functional requirements

System Integration & Architecture

Functional requirements
Describe what the system should do
Non-functional requirements
Consists of Constraints that must be adhered to during
development (design and implementation)
Remember ‘Constraints.’

System requirements
What we agree to provide
Describes system services 54

Contract between Client and contractor

Functional requirements

09/11/22
• What inputs the system should accept

• What outputs the system should produce

System Integration & Architecture

• What data the system should store that other systems might use

• What computations the system should perform

• The timing and synchronization of the above

55
Non-functional requirements

09/11/22
• Non-functional requirements are global constraints on a
computer system
• e.g. development costs, operational costs, performance, reliability,

System Integration & Architecture

• The challenge of Non-functional requirements:
• Hard to model
• Usually stated informally, and so are:
• often contradictory,
• difficult to enforce during development
• difficult to evaluate for the customer prior to delivery

56
 09/11/22
Non-functional requirements
• Define system properties and constraints e.g.
reliability, response time and storage

System Integration & Architecture

requirements. Constraints are I/O device
capability, system representations.
• Process requirements may also be specified
mandating a particular programming language
or development method
• Non-functional requirements may be more
critical than functional requirements. If these are
not met, the system is useless. 57
Examples of NFR

09/11/22
• Interface requirements
• how will the new system interface with its

System Integration & Architecture

environment?
• User interfaces and “user-friendliness”
• Interfaces with other systems
• Performance requirements
• Time - response time
• Throughput - transactions per second

58
Examples of NFR

09/11/22
• Security
• permissible information flows

System Integration & Architecture

• Or who can do what
• Survivability – e.g. system will need to survive fire
natural catastrophes, etc
• Operating requirements
• physical constraints (size, weight),
• personnel availability & skill level
• accessibility for maintenance
• environmental conditions
59
Examples of NFR

09/11/22
• Lifecycle requirements
• Maintainability, Enhanciability, Portability, expected market or

System Integration & Architecture

product lifespan
• limits on development
• E.g. development time limitations, resource availability and
methodological standards.
• Economic requirements
• e.g. restrictions on immediate and/or long-term costs.

60
Requirements Documentation

09/11/22
• There are basically two types of documents realised

System Integration & Architecture

from the requirements elicitation phase. These
include;

• User Requirements Specification Document

• System requirements specification Document

61
User Requirements Specification –

09/11/22
URS/URD
The URS document outlines precisely what the User (or customer) is
expecting from this system.

System Integration & Architecture

User Requirement Specification may incorporate the functional
requirements of the system or may be in a separate document
labelled the Functional Requirements Specification - the FRS.

The URD has the following

information:
1. Functional Requirements
2. Non-Functional Requirements 62
System Requirements

09/11/22
Specification Document
A detailed description of the system services.

System Integration & Architecture

• What do we agree to provide?
• A structured document setting out detailed
descriptions of the system services.
• Written as a contract between client and
contractor.
63
TOOLS THAT AID IN DEVELOPING &

09/11/22
UNDERSTANDING
• Affinity diagrams
SYSTEM REQ’TS
• Force-field analysis

System Integration & Architecture

• Ishikawa fishbone (cause-and-effect) diagrams
• Pareto diagrams
• Pugh charts
• Quality function deployment (QFD)

64
 Comparison of the tools

System Integration & Architecture 09/11/22

65