What does it mean to model organization as systems?

Organizations and their members are usefully conceptualized as systems designed to accomplish
predetermined goals and objectives through people and other resources that they employ.
Organizations are composed of smaller, interrelated systems (departments, units, divisions, etc.)
serving specialized functions. Typical functions include accounting, marketing, production, data
processing, and management. Specialized functions (smaller systems) are eventually reintegrated
through various ways to form an effective organizational whole.

The significance of conceptualizing organizations as systems is that systems principles allow

insight into how organizations work. To ascertain information requirements properly and to
design appropriate information systems, it is of primary importance to understand the
organization as a whole. All systems are composed of subsystems (which include information
systems); therefore, when studying an organization, we also examine how smaller systems are
involved and how they function.

Why is this important to an IS professionals?

It allows system analyst to understand businesses before they begin their tasks

Shows the scope and boundaries of a system at a glance including the other systems that
interface with it.

It’s easy to expand by adding different levels of Data Flow Diagrams

How can you depict organizational systems graphically?

A system or subsystem as it exists within the corporate organization may be graphically depicted
in several ways. The various graphical models show the boundaries of the system and the
information used in the system.

Context-level data flow diagrams;

The context-level data flow diagram is used to establish the context and boundaries of the system
to be modelled: which things are inside and outside of the system being modelled, and what is
the relationship of the system with these external entities.

Another name for a Context Diagram is a Context-Level Data-Flow Diagram or a Level-0 Data
Flow Diagram.  Since a Context Diagram is a specialized version of Data-Flow Diagram,
understanding a bit about Data-Flow Diagrams can be helpful.
 A Data-Flow Diagram (DFD) is a graphical visualization of the movement of data through an
information system. DFDs are one of the three essential components of the structured-systems
analysis and design method (SSADM). A DFD is process centric and depicts 4 main
components.
 Processes (circle)
 External Entities (rectangle)
 Data Stores (two horizontal, parallel lines or sometimes and ellipse)
 Data Flows (curved or straight line with arrowhead indicating flow direction)

Process

Process is a procedure that manipulates the data and its flow by taking incoming data, changing
it, and producing an output with it. A process can do this by performing computations and using
logic to sort the data or change its flow of direction. Processes usually start from the top left of
the DFD and finish on the bottom right of the diagram.

External Entity

An external entity, which are also known as terminators, sources, sinks, or actors, are an outside
system or process that sends or receives data to and from the diagrammed system. They’re either
the sources or destinations of information, so they’re usually placed on the diagram’s edges.

Data Store

Data stores hold information for later use, like a file of documents that’s waiting to be processed.
Data inputs flow through a process and then through a data store while data outputs flow out of a
data store and then through a process.

Data flow

Data flow is the path the system’s information taken from external entities through processes and
data stores. With arrows and concise labels, the DFD can show you the direction of the data
flow.

Entity-relationship model;

An entity–relationship model (or ER model) describes interrelated things of interest in a

specific domain of knowledge. A basic ER model is composed of entity types (which classify the
things of interest) and specifies relationships that can exist between entities (instances of those
entity types).

An entity relationship model, also called an entity-relationship (ER) diagram, is a graphical

representation of entities and their relationships to each other, typically used in computing in
regard to the organization of data within databases or information systems. An entity is a piece of
data-an object or concept about which data is stored.

Relationships between Entities

A relationship is how the data is shared between entities. There are three types of relationships
between entities:

One-to-One
One instance of an entity (A) is associated with one other instance of another entity (B). For
example, in a database of employees, each employee name (A) is associated with only one social
security number (B).

One-to-Many
One instance of an entity (A) is associated with zero, one or many instances of another entity
(B), but for one instance of entity B there is only one instance of entity A. For example, for a
company with all employees working in one building, the building name (A) is associated with
many different employees (B), but those employees all share the same singular association with
entity A.

Many-to-Many
One instance of an entity (A) is associated with one, zero or many instances of another entity
(B), and one instance of entity B is associated with one, zero or many instances of entity A. For
example, for a company in which all of its employees work on multiple projects, each instance of
an employee (A) is associated with many instances of a project (B), and at the same time, each
instance of a project (B) has multiple employees (A) associated with it.
Use case modeling;

A use case model shows a view of the system from the user perspective, thus describing what a
system does without describing how the system does it. Use case modelling is a useful tool for
requirements elicitation. It provides a graphical representation of the software system's
requirements.

The key elements in a use case model are actors (external entities), and the use
cases themselves. In outline, a use case is a unit of functionality (a requirement), or a service, in
the system. A use case is not a process, or program, or function.