Information Systems – Course Summary

Vocabulary flashcards covering key terms and definitions from the Information Systems course summary, spanning systems theory, organisational IT levels, project management, software life-cycle models, feasibility, problem solving, and software development roles.

System

A set of elements that work together in an organized way to achieve an objective.

Structure (in systems)

The set of relationships among a system’s components that differentiates a system from a mere aggregate.

Supersystem

A larger system of which a given system forms a part; also called metasystem.

Process (in systems)

A set of actions that involve production, transformation or transport of matter, energy and/or information to yield a product.

Block Diagram

A schematic representation of the units or phases of a process using blocks and arrows that show inter-relationships and flows.

Open System

A system that continually exchanges energy, matter or information with its environment.

Closed System

An idealised system with no exchange of energy, matter or information with the external world; only possible in abstraction.

Entropy (in open systems)

Measure of disorder; kept low in open systems through continuous energy flow.

Element (system component)

A living or non-living component of a system that can itself be a subsystem.

System Boundary

Physical, legal or mental frontier that separates a system from its environment and defines its study scope.

Cloud (system symbol)

Symbolic representation of sources or sinks outside a system’s boundaries.

Communication Network

Physical or mental connections enabling exchanges of matter, energy or information within or between systems.

Deposit (system)

Place where materials, energy or information are stored (e.g., library, fuel tank).

Information Flow

Quantity of energy, matter or information that circulates through a system per unit of time.

Control Element (Valve)

Component that regulates the circulation and rate of a flow by converting information into actions (e.g., switch, manager).

Delay (system)

Time lag due to transport, storage or processing that affects system behaviour.

Feedback Loop

Path that feeds part of a system’s output back to its input to adjust behaviour.

Positive Feedback

Feedback that amplifies output changes, increasing divergence and potential instability.

Negative Feedback

Feedback that counteracts output changes, promoting stability and convergence.

Analytical Approach

Study method that isolates and examines system parts in detail, suitable for few variables or simple relations.

Systemic Approach

Method that studies the whole system, its interactions and interdependencies, prioritising overall view over detail.

Main Function (software system)

The principal reason for a software system’s existence, identified at the start of analysis.

Scope (system)

Description of all functionalities included—and excluded—in a software system or project.

Operational Level (pyramid)

Lowest organisational level dealing with routine transactions and day-to-day operations.

Transaction Processing System (TPS)

Computerised system that processes large volumes of routine transactions efficiently and reliably.

Knowledge Level

Organisational tier focused on analysis, knowledge creation and office automation.

Office Automation System (OAS)

Application that helps workers create, analyse and share information (e.g., Microsoft Office).

Knowledge Work System (KWS)

System that aids professionals in creating and integrating new knowledge (e.g., CAD tools, Notion).

Administrative Level

Management tier supporting non-routine decision making and performance control.

Management Information System (MIS)

System producing structured information for managerial decision making, often drawing on TPS data.

Decision Support System (DSS)

Interactive system that supports all phases of decision making using data and analytical models.

Expert System

AI-based system that captures expert knowledge to select optimal solutions to specific problems.

Strategic Level

Top organisational tier concerned with long-term planning and strategy formulation.

Executive Support System (ESS)

System providing executives with critical information and tools for strategic decisions.

Group Decision Support System (GDSS)

Computer-based system that facilitates problem solving by groups using techniques such as brainstorming.

Computer-Supported Cooperative Work (CSCW)

Collaborative work facilitated by groupware over computer networks (e.g., Google Workspace).

Enterprise Resource Planning (ERP)

Integrated software suite that supports and automates core business processes across an organisation.

Service-Oriented Architecture (SOA)

Design paradigm in which systems provide services to other components over a network via well-defined interfaces.

m-Commerce

Mobile commerce: buying and selling via wireless devices.

Open Source Software (OSS)

Software whose source code is freely available for study, modification and distribution (e.g., Linux).

Project (generic)

Temporary endeavour undertaken to create a unique product, service or result.

Project Life-cycle Processes

Initiation, Planning, Execution, Monitoring & Control, and Closing stages of a project.

Triple Constraint

Interrelated factors of Scope, Cost and Time that determine project quality; changing one affects the others.

Feasibility Study

Assessment of whether a project is viable in operational, technical, economic and political terms.

Operational Feasibility

Likelihood that a system will be accepted and effectively used by people in the organisation.

Technical Feasibility

Assessment of whether required technology exists, is mature, available and within budget/time limits.

Economic Feasibility

Cost-benefit analysis evaluating tangible and intangible returns versus development and operational costs.

Political Feasibility

Evaluation of organisational power dynamics, policies, legal or social factors influencing system adoption.

Problem (definition)

A situation requiring analysis, reflection and decision making to determine steps toward a solution.

Exercise vs. Problem

Exercises apply practiced techniques; problems require new strategies using existing knowledge.

Problem-Solving Step 1

Understand the problem: read carefully, identify data and unknowns, sketch the situation.

Problem-Solving Step 2

Devise a plan: compare with similar problems, explore alternative formulations, use all data.

Problem-Solving Step 3

Execute the plan: perform steps, verify each, backtrack if obstacles arise.

Problem-Solving Step 4

Review: check results, validate logic, look for other methods or new problems.

Software Life-cycle Activity: Communication

Collaborate with stakeholders to elicit objectives and requirements.

Software Life-cycle Activity: Planning

Create a project map detailing tasks, risks, resources, deliverables and schedule.

Software Life-cycle Activity: Modeling

Build abstractions (analysis & design models) to understand problem and solution structure.

Software Life-cycle Activity: Construction

Generate code and perform testing to discover and fix errors.

Software Life-cycle Activity: Deployment

Deliver, install, train users, collect feedback and maintain the system.

Waterfall Model

Linear, rigid software development model with sequential, non-overlapping phases and frozen requirements.

Incremental Model

Lifecycle model delivering the product in a series of functional increments, each an iteration of a mini-waterfall.

Evolutionary/Prototyping Model

Iterative model that builds successive prototypes to refine unclear requirements.

Disposable Prototype

Prototype built to clarify requirements and then discarded before real development.

Evolutionary Prototype

Prototype that is gradually refined into the final system through iterations.

Spiral Model

Risk-driven evolutionary model combining prototyping and systematic aspects, iterating through risk analysis cycles.

Component Assembly Model

Development approach that reuses existing components from libraries, creating or adapting others as needed.

Formal Transformation Model

Method that transforms formal specifications through correctness-preserving steps into executable code.

Project Manager

Role responsible for planning, organising and controlling resources to meet project objectives on time, budget and quality.

Project Manager Objective

Deliver the product on time, within budget and according to defined quality requirements.

Project Manager Skills

Abstraction, concretisation, organisation, leadership, experience, creativity and persuasion.

Analyst

Role that decomposes complex problems, elicits and specifies user and software requirements.

User Requirements Document (URD/DRU)

Specification capturing customer needs and high-level objectives of the system.

Software Requirements Specification (SRS/DRS)

Detailed description of software functions, constraints and interfaces for the development team.

Designer

Role that creates architectural and detailed design of the system, ensuring alignment with requirements.

Architectural Design

High-level structure of a software system defining subsystems, interfaces and interactions.

Decomposition Algorithmic

Design method that breaks a system into parts representing steps in a larger process, focusing on control flow.

Decomposition Object-oriented

Design method dividing the system into classes/objects representing domain entities that collaborate.

Programmer

Role that translates specifications into executable code, debugs, documents and participates in testing.

Programming Objective

Reduce software complexity, produce reliable code quickly and with few errors.

Code Review (peer)

Inspection of code by another developer to find design, logic or style defects before testing.

Tester

Role that designs and executes test cases to detect defects and verify system quality.

White-Box Testing

Technique deriving tests from internal code structure to exercise paths, decisions and loops.

Black-Box Testing

Technique deriving tests from functional requirements without regard to internal implementation.

Quality Assurance (QA) Engineer

Role ensuring processes and products meet defined quality standards, often via formal technical reviews.

Formal Technical Review (FTR)

Structured meeting to inspect a small product (e.g., module design) for errors before further work.

Configuration Management (CM)

Discipline that identifies, controls, records and audits changes to software items throughout the lifecycle.

Baseline

Formally reviewed and agreed version of a configuration item that serves as a basis for further work.

Version Control

Systematic management of changes to documents, code and other artifacts over time.

Change Control

Process of proposing, evaluating, approving and implementing modifications to configuration items.

Status Accounting (CM)

Recording and reporting of configuration item information, change status and implementation state.

Documentation of Process

Records of development activities, plans, decisions and communications to make the process visible.

Documentation of Product

Technical and user materials describing system requirements, design, installation, use and maintenance.

Documenter

Role responsible for creating, updating and organising project documents and repositories.

Repository (documentation)

Central storage system for all project documents, versions and access control.

Client (committed)

Stakeholder accountable for providing requirements, resources, approvals and acceptance testing.

Acceptance Test Plan

Client-created set of tests applied at project end to decide on product acceptance.

Interview (requirements)

Structured conversation conducted by analysts to gather information and opinions from stakeholders.

Open Question

Interview question allowing the respondent to elaborate freely.

Closed Question

Interview question with limited, predefined set of answers.

Sonde (probe) Question

Follow-up query used to obtain clarification or deeper insight during an interview.