SOUTHERN LEYTE STATE UNIVERSITY

COLLEGE OF COMPUTER STUDIES

AND INFORMATION TECHNOLOGY

Module One & Two: Introduction of System Integration and Architecture

COURSE OVERVIEW

Course No.

Course Code IT 303

Descriptive Title System Integration and Architecture 1

Credit Units 3 Units

School Year/Term 1st Semester, AY: 2021-2022

Mode of Delivery Online and Modular Learning

Name of Instructor/ Professor Randy M. Siervo

Course Description This course will introduce to the student on how to design and
build systems and integrate them into an organization. This
knowledge area develops the skills to gather requirements, then
source, evaluate and integrate components into a single system,
and finally validate the system. It also covers the fundamentals
of project management and the interplay between IT
applications and organizational processes.

Course Outcomes Knowledge (Think)

1. Analyze the fundamental requirements and techniques in
building and integrating system and architecture into an
organization.
Skills (Do)
2. Perform the techniques in building and integrating
system and architecture to a specified requirements.
Values (Feel)
3. Adapt system integration and architecture in
implementing an enterprise platform.

SLSU Vision A high quality corporate science and technology university

SLSU Mission Produces S and T leaders and competitive professionals;

generate breakthrough research in S and T based disciplines;
transform and improve the quality of life in the communities in
the service area; and be self –sufficient and financially viable.
SOUTHERN LEYTE STATE UNIVERSITY
COLLEGE OF COMPUTER STUDIES
AND INFORMATION TECHNOLOGY

MODULE GUIDE

In this module, we will

continue our exploration in
the world of Object-
Oriented Programming
(OOP). OOP-based
architecture proves to be
beneficial especially when
dealing with special types of
data which need to
be packaged into one entity.
What would you do if you
have so much
capability at your hand? Of
course, you will use it. This
ideology will be
SOUTHERN LEYTE STATE UNIVERSITY
COLLEGE OF COMPUTER STUDIES
AND INFORMATION TECHNOLOGY

covered in this module

together with the principles
that surround OOP. Hard
might it be at first, however
their important role in OOP’s
implementation
will be eviden
In this module, provide an understanding of the technical and business process issues
involved in systems integration.

PRE-TEST

Test I. Essay
1. What is System Integration?
2. What is System Architecture?
3. Did you previously used any architectural pattern? If yes what architectural pattern did
you used? And how convinent it is?

LEARNING PLAN

Intended Learning Outcome: Define the system integration and architecture.

Discuss the fundamental requirements & techniques in building system integration
and architecture.

Introduction

Many systems are built to easy, improve and transform organizations. Some organizations have
may 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 likeness of system failure.
SOUTHERN LEYTE STATE UNIVERSITY
COLLEGE OF COMPUTER STUDIES
AND INFORMATION TECHNOLOGY

Besides after the system has been designed and developed in consideration of the size of the
organization, i.e. most especially when the organization is large, need is required to integrate such
systems to ensure flexibility, Speed, Cost, Standardization, Data integrity, reliability and
robustness.

Key to Remember:

 System - is a set of rules, an arrangement of things, or a group of related things that work
toward a common goal
 System Thinking - is a holistic approach to analysis that focuses on the way that a system's
constituent parts interrelate and how systems work over time and within the context of
larger systems.
 System Integration - is the process of connecting different sub-systems (components) into
a single larger system that functions as one.
 System Architecture - defines its high-level structure, exposing its gross organization as a
collection of interacting components.

Discussion:

In System Integration and Architecture, we have 5 things that we should learn this are the
following:
1. System
2. System Thinking
3. System Integration
4. System Architecture
5. Project

System
An array of components designed to accomplish a particular objective according to 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.

System Thinking
Is a way of understanding an entity in terms of its purpose. The three major steps followed in
systems thinking:
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)

System Integration
In very broad terms, system integration is the process of connecting different sub-systems
(components) into a single larger system that functions as one. With regards to software solutions,
system integration is typically defined as the process of linking together various IT systems,
services and/or software to enable all of them to work functionally together.
SOUTHERN LEYTE STATE UNIVERSITY
COLLEGE OF COMPUTER STUDIES
AND INFORMATION TECHNOLOGY

The main reason for organizations to use system integration is their need to improve productivity
and quality of their operations. The goal is to get the organizations various IT systems to “talk to
each other” through the integration, to speed up information flows and reduce operational costs
for the organization. But system integration is not used only to connect an organization’s internal
systems, but also third parties that the organization operates with.

System Integration Methods

Typical System integration methods are divided into the following different categories:

Point-to-Point Integration
One could argue that a point-to-point integration (or point-to-point connection) is not a system
integration as such since there are only two system components involved. However, while it lacks
the complexity of “true” system integration, it still connects a system to another system for them to
function together. Typically, such point-to-point integration handles only one function and does
not involve any complex business logic. Many cloud-based applications offer these types of point-
to-point integrations as productized, “out of the box” integration modules for the most common IT
systems.
Vertical Integration
In vertical integration method, the system components (sub-systems) are integrated by creating
functional "silos", beginning with the basic bottom function upward. This is normally relatively
simple and easy method that only involves a limited number of systems (more than two), but on
the other hand, this integration method is quote rigid and more difficult to manage in the long term
as any new functionally will require its own functional” silo”. Still, this method can be used
effectively to create simple integrations, that only need to address a single function.
Star Integration
Star integration means that a system where each sub-system is connected with other sub-systems
using point-to-point connections. This allows for more functionality, but as the number of
integrated systems increases the number of integrations also increases significantly, and the
management of the integrations becomes very demanding.
Example, to connect ten systems to each other using this method, will require 45 separate
integrations, and every time there is a change in one system, nine connections may need to be re-
done as well.
Horizontal Integration
In horizontal integration, a separate sub-system is used as a common interface layer between all
sub-systems.  Very often this layer is referred to as an Enterprise Service Bus (ESB).  This method
allows each sub-system to have just one single interface to communicate with all the other sub-
systems connected to the common interface layer (i.e., with ten systems, there are only ten
connections).  The benefit of this method is also that each sub-system can be changed or even
replaced without having to re-do the interfaces of any other systems.

Steps of system integration process

1. Requirements gathering
2. Analysis
3. Architecture design
4. System integration design
5. Implementation
6. Maintenance
SOUTHERN LEYTE STATE UNIVERSITY
COLLEGE OF COMPUTER STUDIES
AND INFORMATION TECHNOLOGY

Integration Objects
1. Integration platforms
2. Data integration
3. Application integration
4. Integration of business processes

System Architecture
The architecture of a system defines its high-level structure, exposing its gross organization as a
collection of interacting components.
Elements needed to model a software architecture include:

 Components
 Connectors
 Systems
 Properties
 and Styles

System Architecture Techniques

Iterative and Incremental Approach

An Iterative and Incremental approach consisting of five main steps that helps to generate
candidate solutions. This candidate solution can further be refined by repeating these steps and
finally create an architecture design that best fits the application.

Identify Architectural Goal

Identify the architecture goal that form the architecture and design process. Flawless and defined
objectives emphasize on the architecture, solve the right problems in the design and helps to
determine when the current phase has completed, and ready to move to the next phase.
This steps includes the following activities:

 Identify your architecture goals at the start.

 Identify the consumer of our architecture.
 Identify the constraints.

Key Scenarios
Key scenarios are those that are considered the most important scenarios for the success of your
application. It helps to make decisions about the architecture. The goal is to achieve a balance
among the user, business, and system objectives.

Application Overview
Build an overview of application, which makes the architecture more touchable, connecting it to
real-world constraints and decisions.
It consists of the following activities:
SOUTHERN LEYTE STATE UNIVERSITY
COLLEGE OF COMPUTER STUDIES
AND INFORMATION TECHNOLOGY

1. Identify Application Type

2. Identify Development Constraints
3. Identify Important Architecture Design Styles
4. Identify the Relevant Techiniques
5. Identify the key issues

Architecture Review
Architecture review is the most important task in order to reduce the cost of mistakes and to find
and fix architectural problems as early as possible. It is a well-established, cost-effective way of
reducing project costs and the chances of project failure.

 Review the architecture frequently at major project milestones, and in response to other
significant architectural changes.
 The main objective of an architecture review is to determine the feasibility of baseline and
candidate architectures, which verify the architecture correctly.
 Links the functional requirements and the quality attributes with the proposed technical
solution. It also helps to identify issues and recognize areas for improvement

Scenario-based evaluations are a dominant method for reviewing an architecture design which
focuses on the scenarios that are most important from the business perspective, and which have
the greatest impact on the architecture.
Following are common review methodologies:
1. Software Architecture Analysis Method (SAAM)
2. Architecture Tradeoff Analysis Method (ATAM)
3. Active Design Review (ADR)
4. Active Reviews of Intermediate Designs (ARID)
5. Cost Benefits Analysis Method (CBAM)
6. Architecture Level Modifiability Analysis (ALMA)
7. Family Architecture Assessment Method (FAAM)

Architectural Pattern
An Architectural pattern is a general, reusable solution to a commonly occurring problem in software
architecture within a given context.

10 Common Software Architectural Pattern

1. Layered pattern
This pattern can be used to structure programs that can be decomposed into groups
of subtasks, each of which is at a particular level of abstraction. Each layer provides
services to the next higher layer.

Usage:

 General desktop applications

 E commerce web applications

2. Client-server pattern
This pattern consists of two parties; a server and multiple clients. The server component will
provide services to multiple client components. Clients request services from the server and the
server provides relevant services to those clients. Furthermore, the server continues to listen to
client requests.
SOUTHERN LEYTE STATE UNIVERSITY
COLLEGE OF COMPUTER STUDIES
AND INFORMATION TECHNOLOGY

Usage:

 Online applications such as email, document sharing and banking.

3. Master-slave pattern
This pattern consists of two parties; master and slaves. The master component distributes the
work among identical slave components, and computes a final result from the results which the
slaves return.

Usage:

 In database replication, the master database is regarded as the authoritative source,

and the slave databases are synchronized to it.
 Peripherals connected to a bus in a computer system (master and slave drives).

4. Pipe-filter pattern
This pattern can be used to structure systems which produce and process a stream of data.
Each processing step is enclosed within a filter component. Data to be processed is passed
through pipes.

Usage:

 Compilers. The consecutive filters perform lexical analysis, parsing, semantic analysis,
and code generation.
 Workflows in bioinformatics.

5. Broker pattern

This pattern is used to structure distributed systems with decoupled components. These
components can interact with each other by remote service invocations. A broker component is
responsible for the coordination of communication among components.

Servers publish their capabilities (services and characteristics) to a broker. Clients request a
service from the broker, and the broker then redirects the client to a suitable service from its
registry.

Usage:

 Message broker software such as Apache ActiveMQ, Apache Kafka, RabbitMQ and
JBoss Messaging.

6. Peer-to-peer pattern
In this pattern, individual components are known as peers. Peers may function both as a client,
requesting services from other peers, and as a server, providing services to other peers. A peer
may act as a client or as a server or as both, and it can change its role dynamically with time.
Usage:

 File-sharing networks such as Gnutella and G2)

 Multimedia protocols such as P2PTV and PDTP.

7. Event-bus pattern
SOUTHERN LEYTE STATE UNIVERSITY
COLLEGE OF COMPUTER STUDIES
AND INFORMATION TECHNOLOGY

This pattern primarily deals with events and has 4 major components; event source, event
listener, channel and event bus. Sources publish messages to particular channels on an event
bus. Listeners subscribe to particular channels. Listeners are notified of messages that are
published to a channel to which they have subscribed before.

Usage:

 Android development
 Notification services

8. Model-view-controller pattern

This pattern, also known as MVC pattern, divides an interactive application in to 3 parts as;

1) model — contains the core functionality and data

2) view — displays the information to the user (more than one view may be
defined)
3) controller — handles the input from the user

This is done to separate internal representations of information from the ways information is
presented to, and accepted from, the user. It decouples components and allows efficient code
reuse.

Usage:

 Architecture for World Wide Web applications in major programming languages.

 Web frameworks such as Django , Rails, Laravel, Yii, Asp.net and
CodeIgniter.

9. Blackboard pattern

This pattern is useful for problems for which no deterministic solution strategies are known. The
blackboard pattern consists of 3 main components.

 blackboard — a structured global memory containing objects from the solution

space
 knowledge source — specialized modules with their own representation
 control component — selects, configures and executes modules.

All the components have access to the blackboard. Components may produce new data objects
that are added to the blackboard. Components look for particular kinds of data on the
blackboard, and may find these by pattern matching with the existing knowledge source.

Usage:

 Speech recognition
 Vehicle identification and tracking
 Protein structure identification
 Sonar signals interpretation.

10. Interpreter pattern

SOUTHERN LEYTE STATE UNIVERSITY
COLLEGE OF COMPUTER STUDIES
AND INFORMATION TECHNOLOGY

This pattern is used for designing a component that interprets programs written in a dedicated
language. It mainly specifies how to evaluate lines of programs, known as sentences or
expressions written in a particular language. The basic idea is to have a class for each symbol of
the language.

Usage:

 Database query languages such as SQL.

 Languages used to describe communication protocols.

Comparison of Architectural Patterns

Project
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.
A project is a temporary endeavor undertaken to accomplish a unique product or service.
SOUTHERN LEYTE STATE UNIVERSITY
COLLEGE OF COMPUTER STUDIES
AND INFORMATION TECHNOLOGY

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

Information Systems Projects Originate (Source of Projects)

New or changed IS development projects come from problems, opportunities, and directives and
are always subject to one or more constraints.
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 management, government, or some
external influence i.e. are mandates that come from either an internal or external source of
the business.

The Stakeholders
Stakeholders are the people involved in or affected by project activities. Stakeholders include:
1. The project sponsor and project team
2. Support Staff
3. Customers
4. Users
5. Suppliers
6. Opponents to the project
Importance of the Stakeholders
1. Project managers must take time to identify, understand, and manage relationships with all
project stakeholders
2. Using the four frames of organizations can help meet stakeholder needs and expectations
3. Senior executives are very important stakeholders

What helps projects succeed?

According to the Standish Group’s report “CHAOS 2001: A Recipe for Success,” the following items
help IT projects succeed, in order of importance:
• Executive support
• User involvement
SOUTHERN LEYTE STATE UNIVERSITY
COLLEGE OF COMPUTER STUDIES
AND INFORMATION TECHNOLOGY

• Experienced project manager

• Clear business objectives
• Minimized scope
• Standard software infrastructure
• Firm basic requirements
• Formal methodology
• Reliable estimates

Organizations
We can analyze a formal organization using the following 4 (four) frames;

STRUCTURAL FRAME: HUMAN RESOURCES FRAME:

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

Why many organizations focus on the Structural Frame?

A. Most people understand what organizational charts are.
B. Many new managers try to change organizations structure when other changes are needed.
C. 3 basic organizational structures:
1. Functional-
2. project
3. matrix

Basic Organizational Structure

Organizational structure depends on the company and / or the project. The structures helps define
the roles and responsibilities of 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:
1. 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 this kind of
SOUTHERN LEYTE STATE UNIVERSITY
COLLEGE OF COMPUTER STUDIES
AND INFORMATION TECHNOLOGY

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.
2. 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.
3. 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 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.
4. 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.

Project Phases and the Project life Cycle

A project life cycle is a collection of project phases.
Project phases vary by project or industry, but some general phases include:

 Concept
 Development
SOUTHERN LEYTE STATE UNIVERSITY
COLLEGE OF COMPUTER STUDIES
AND INFORMATION TECHNOLOGY

 Implementation
 Support

Phases of the Project Life Cycle

Product Life Cycles

Product also have life cycles.

 The Systems Development Life Cycle (SDLC) is a framework for describing the phases
involved in developing and maintaining information systems.
 System development projects can follow:
o Predictive models: The scope of the project can be clearly articulated and the
schedule and cost run be predicted.
o Adaptive models: Project are mission driven and components based, using time-
based cycles to meet target dates.

Types of Predictive Life Cycle Models

1. The waterfall model has well-defined, linear stages of systems development and support.
2. The spiral model shows that software is developed using an iterative or spiral approach
rather than a linear approach.
3. The incremental release model provides for progressive development of operational
software.
4. The prototyping model is used for developing prototypes to clarify user requirements.
5. The RAD model is used to produce systems quickly without sacrificing quality.
Types of Adaptive Life Cycle Models
 Extreme Programming (XP): Developers program 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
SOUTHERN LEYTE STATE UNIVERSITY
COLLEGE OF COMPUTER STUDIES
AND INFORMATION TECHNOLOGY

Distinguishing Project Life Cycle and Product Life Cycles

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. The project management is done all of the product life cycle
phases.

Why have Project Phases and Management Reviews?

• 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

The System Development Life Cycle

Requirements
• A system cannot be analyzed, designed, implemented and evaluated unless the problem is
understood and requirements elicited.
• Requirements are fundamental basis of all the system development processes.
SOUTHERN LEYTE STATE UNIVERSITY
COLLEGE OF COMPUTER STUDIES
AND INFORMATION TECHNOLOGY

• 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.
What are requirements?
• Requirements are statements that identify the essential needs of a system in order for it to
have value and utility.

Characteristics of Good Requirements

1. Describes What, Not How.
2. Atomic. i.e., it should have a single purpose
3. Unique.
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.
9. Complete.
10. Unambiguous
11. Quantitative and testable
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.

Requirements Life Cycle

SOUTHERN LEYTE STATE UNIVERSITY
COLLEGE OF COMPUTER STUDIES
AND INFORMATION TECHNOLOGY

SPE
Analy
sed
Complet CS
Raw Organise e user
Req’ts d Req’ts Req’t Req’ts
The s
User

Elicitati Organiza
Analysis Prototyp
on tion Transform
Phase
Phase e Phase to spec
Phase

 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 broad scope of potential ideas and candidate problems

 Organization 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.

 Prototype Phase

In this way poorly understood requirements may be tested and 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.

Requirements elicitation
SOUTHERN LEYTE STATE UNIVERSITY
COLLEGE OF COMPUTER STUDIES
AND INFORMATION TECHNOLOGY

• Requirements determination addresses the gathering and documenting of the true and real
requirements for the Information System being developed.

• Requirements is the wants and /or needs of the user within a problem domain. elicit

Requirements determination questions

 Who does it?

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

System Requirements

• Characteristics or features that must be included to satisfy business requirements

• Outputs
• Inputs
• Processes
• Timing
• Controls
• Volumes. sizes, and frequencies
• Data/Information collected can be about; people, organisation, work and work environment.

Fact – Finding Methods

• Sampling (of existing documentation, forms, and databases).

• Research and site visits. (Participation)
• Observation of the work environment.
• Questionnaires.
• Interviews.
• Prototyping.
• JAD/Joint requirements planning (JRP).

Types of Requirements

 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
 Functional requirements

 Describe what the system should do

 Non-functional requirements
SOUTHERN LEYTE STATE UNIVERSITY
COLLEGE OF COMPUTER STUDIES
AND INFORMATION TECHNOLOGY

 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

 Contract between Client and contractor

Functional Requirements

• What inputs the system should accept

• What outputs the system should produce
• What data the system should store that other systems might use
• What computations the system should perform
• The timing and synchronization of the above

Non-functional requirements

• Non-functional requirements are global constraints on a computer system

• e.g. development costs, operational costs, performance, reliability,
• 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

• Define system properties and constraints e.g. reliability, response time and storage 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.

Example of NFR

• Interface requirements
• how will the new system interface with its environment?
• User interfaces and “user-friendliness”
• Interfaces with other systems
SOUTHERN LEYTE STATE UNIVERSITY
COLLEGE OF COMPUTER STUDIES
AND INFORMATION TECHNOLOGY

• Performance requirements
• Time - response time
• Throughput - transactions per second
• Security
• permissible information flows
• 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
• Lifecycle requirements
• Maintainability, Enhanciability, Portability, expected market or 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.

Requirement Documentation

• There are basically two types of documents realized from the requirements elicitation phase. These
include;
• User Requirements Specification Document
• System requirements specification Document

User Requirements Specification –URS/URD

 The URS document outlines precisely what the User (or customer) is expecting from this system.

 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

System Requirements Specification Document

A detailed description of the system services.

• What do we agree to provide?

SOUTHERN LEYTE STATE UNIVERSITY
COLLEGE OF COMPUTER STUDIES
AND INFORMATION TECHNOLOGY

• A structured document setting out detailed descriptions of the system services.

• Written as a contract between client and contractor.

Tools and Aid in Developing and Understanding System Requirements

• Affinity diagrams

• Force-field analysis

• Ishikawa fishbone (cause-and-effect) diagrams

• Pareto diagrams

• Pugh charts

• Quality function deployment (QFD)

Comparison of the Tools

Summary:
Summary

 System an array of components designed to accomplish a particular objective according to

plan.
 System Thinking is a way of understanding an entity in terms of its purpose.
 System integration is the process of connecting different sub-systems (components) into a
single larger system that functions as one.
 System Architecture defines its high-level structure, exposing its gross organization as a
collection of interacting components.
 The Source of Project maybe new or changed IS development projects come from problems,
opportunities, and directives and are always subject to one or more constraints.
 Stakeholders are the people involved in or affected by project activities.
 The project may succeed the following items that 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, Reliable estimates.
SOUTHERN LEYTE STATE UNIVERSITY
COLLEGE OF COMPUTER STUDIES
AND INFORMATION TECHNOLOGY

 4 Frames of organization: STRUCTURAL FRAME, HUMAN RESOURCES FRAME, POLITICAL

FRAME, SYMBOLIC FRAME
 Organizational structure depends on the company and / or the project.

 Test
Post

Test I. True of False

1. Stakeholders are the people involved in or affected by project activities
2. Problem is a chance to improve the business even in the absence of specific problems.
3. The waterfall model The waterfall model shows that software is developed using an
iterative or spiral approach rather than a linear approach.
4. The prototyping model is used for developing prototypes to clarify user requirements.
5. System Integration is the combination of inter-related elements to achieve a common
objective (s).

Test II. Enumeration

1. 4 Frame of Organization
2. Items that helps the project succeed.
3. 4 types of organizational structure.
4. Types of Predictive Lfe Cycle Model.

References

https://www.techopedia.com/definition/9614/system-integration-si
https://searchcio.techtarget.com/definition/systems-thinking
https://www.youredi.com/blog/what-is-system-integration
https://headchannel.co.uk/6-steps-of-system-integration-process-321
https://flexberry.github.io/en/gbt_integration-methods.html
https://muele.mak.ac.ug/course/view.php?id=1563
https://www.tutorialspoint.com/software_architecture_design/architecture_techniques.htm
https://www.ou.nl/documents/40554/791670/IM0203_03.pdf/30dae517-691e-b3c7-22ed-
a55ad27726d6
Reference Book:
SOUTHERN LEYTE STATE UNIVERSITY
COLLEGE OF COMPUTER STUDIES
AND INFORMATION TECHNOLOGY

Sage A.P. and Rouse, W.B. Handbook of Systems Engineering and management, John Wiley & Sons,
1999.