# Definition of an Information System

An Information System (IS) is a structured set of interconnected components that work together to collect raw
data (input), process it to create meaningful information, and deliver this information to users (output), often
with storage and control mechanisms. These systems utilize key resources, including hardware, software,
people, and procedures, to achieve their goals.

The primary function of an IS is to support organizational activities such as decision-making, coordination,

monitoring, analysis, and visualization. Its main objective is to ensure that accurate and relevant information is
available in a timely manner across the organization, enabling top management to make sound decisions and
take effective action.

Types of Information Systems

Organizations utilize different types of information systems simultaneously because various levels of
management require different types of information for effective operation:

 Senior Managers need summarized data for strategic planning.

 Middle Management requires detailed reports to monitor and control business activities.
 Operational Employees need simple, fast data to perform their daily duties.

The major types of information systems are structured to serve these different organizational levels:
1. Transaction Processing System (TPS)

The TPS is the most fundamental business system, designed to handle the basic, day-to-day activities of an
organization. It operates at the operational level of a business, collecting, modifying, and storing data related to
business transactions. The data gathered by the TPS serves as the input foundation for all higher-level systems.

 Purpose: Record and manage routine business transactions.

 Users: Operational-level employees.
 Example: A billing system that generates customer invoices, or an inventory system that tracks current
stock levels.

2. Management Information System (MIS)

The MIS is designed to support the internal functions and efficient management of various departments within
an organization. It takes the detailed transaction data supplied by the TPS, processes it, and generates summary
reports and performance metrics. These reports help managers organize, evaluate, and monitor business
activities effectively.

 Purpose: Provide regular reports and summaries to monitor performance.

 Users: Middle-level management.
 Output: Summary reports, performance dashboards, and annual budget analysis.

3. Decision Support System (DSS)

A DSS is an interactive, computer-based application designed to aid management in complex decision-

making. It collects and organizes data from multiple internal and external sources, offering analytical tools and
modeling capabilities. The DSS is flexible and allows users to run different simulations (like "what-if"
scenarios) and projections to predict potential outcomes before a final course of action is chosen.

 Purpose: Support decision-making by providing data analysis and forecasting tools.

 Characteristics: Flexible, adaptable, and supports simulations and predictions.
 Users: Middle and senior management for tactical and strategic problems.

4. Executive Support System (ESS)

Also known as an Executive Information System (EIS), the ESS is a specialized DSS designed specifically to
assist senior executives in making high-level, strategic decisions. It provides immediate, easy access to critical
data and key performance indicators (KPIs) necessary for achieving long-term strategic goals. ESS typically
features a user-friendly graphical interface to monitor the entire enterprise's performance and quickly identify
major problems or opportunities.

 Purpose: Facilitate strategic decision-making at the highest level.

 Users: Top-level and senior management.
 Key Feature: Easy-to-use graphical displays of enterprise-wide performance data.

Software Development Life Cycle (SDLC)

The Software Development Life Cycle (SDLC) is a structured process followed by software engineers to
design, develop, test, and maintain high-quality software. It defines clear stages that guide the development
team from the initial idea to the final product, ensuring that the system meets both business goals and user
needs.

Keep space for drawing

1. Requirement Analysis

The first phase of SDLC is Requirement Analysis, which focuses on understanding what the users need from
the software system. Business analysts and system analysts interact with stakeholders, customers, and end users
to gather both functional and non-functional requirements. These requirements are carefully analyzed,
prioritized, and documented in a Software Requirement Specification (SRS) document, which serves as a
foundation for the rest of the project.
Key points:

 Collect requirements through interviews, surveys, and meetings.

 Define functional and non-functional requirements.
 Create the SRS document as a reference for design and development.

2. Feasibility Study
Once the requirements are clearly defined, the Feasibility Study phase determines whether the project is
achievable within the organization’s resources and constraints. This step evaluates the practicality and
profitability of the software project. Different types of feasibility are assessed to make an informed decision on
whether to proceed.
Key points:

 Technical Feasibility: Checks if the required technology, tools, and skills are available.
 Economic Feasibility: Assesses whether the project is financially viable (cost-benefit analysis).
 Legal Feasibility: Ensures compliance with laws, regulations, and licensing agreements.
 Operational Feasibility: Evaluates if the system will function efficiently in the business environment.
 Schedule (Time) Feasibility: Determines if the project can be completed within the set timeline.
The outcome of this phase is a Feasibility Report, which helps management decide whether to initiate
the project.

3. System Design

The System Design phase transforms the requirements into a detailed blueprint for the system’s structure and
functionality. This includes designing the software architecture, data flow diagrams (DFDs), database schema,
and user interfaces. Designers specify how the system components will interact and what technologies will be
used. This phase bridges the gap between planning and implementation.
Key points:

 Develop architectural designs (system layout and modules).

 Create DFDs, ER diagrams, and database designs.
 Design user interfaces (UI/UX).
 Prepare the System Design Document (SDD) as a guide for developers.

4. Implementation (Coding)

In the Implementation phase, the system design is converted into actual code. Developers write programs in
the chosen programming languages according to the specifications outlined in the design phase. The project is
often divided into smaller units or modules, and each module is coded and tested independently. Coding
standards and best practices are followed to ensure code readability and maintainability.
Key points:

 Developers write source code as per the design specifications.

 Modules are implemented and tested individually.
 Coding standards and documentation are maintained.
 This phase results in a fully functional software system ready for testing.

5. Testing

After coding is complete, the software undergoes the Testing phase to ensure it is free from errors and meets
the specified requirements. The goal is to verify that every function works correctly and the system performs as
intended under various conditions. Testers execute different types of tests to identify and correct defects.
Key points:

 Unit Testing: Verifies individual modules or components.

 Integration Testing: Checks the interaction between modules.
 System Testing: Ensures the entire system works as expected.
 User Acceptance Testing (UAT): Confirms that the software meets user expectations.
 Black Box Testing: Focuses on input and output without looking at internal code.
 White Box Testing: Examines the internal logic and structure of the code.
The result of this phase is a stable, verified, and validated software product.

6. Deployment

The Deployment phase involves delivering the tested software to the production environment where end users
can access it. Depending on the organization’s strategy, deployment may occur in stages (pilot testing) or all at
once. Proper installation, configuration, and user training are essential to ensure smooth adoption.
Key points:

 Install and configure software in the live environment.

 Provide user training and documentation.
 Monitor system performance and gather initial feedback.
  Ensure a smooth transition from testing to production use.

7. Maintenance and Review

The final phase, Maintenance and Review, ensures the software continues to perform effectively after
deployment. Over time, user needs or environments may change, requiring updates or improvements.
Maintenance includes fixing bugs, enhancing functionality, and adapting the system to new technologies.
Regular reviews are conducted to evaluate performance and user satisfaction.
Key points:

 Corrective Maintenance: Fixes errors and bugs discovered after release.

 Adaptive Maintenance: Modifies software for new environments or platforms.
 Perfective Maintenance: Enhances features and performance.
 Preventive Maintenance: Improves software reliability to prevent future issues.
This phase keeps the software relevant, efficient, and aligned with business needs over time.

System Development Model

The waterfall Model

This model is some time called classic life cycle because it suggest a systematic sequential approach to software
development that begins with customer specification of requirements and progress through planning, modeling,
construction etc. It is an oldest type of model for software engineering. It takes the fundamental process activities of
specification, development, validation and evolution & represents them as separate process phases such as
requirements specification, software design, implementation testing and so on.
1. Requirement Analysis and Definition

This is where you figure out exactly what the software needs to do. You talk to the customer and write down
every single feature, button, and rule. Once this list (the specification) is done, the customer signs off, and it
cannot be easily changed.

 Goal: Write a complete list of all features needed.

2. System and Software Design

You now plan how to build the software based on the fixed requirements. You decide the system's structure, the
type of database, and what the screen will look like. This creates the technical blueprint that programmers will
follow.

 Goal: Draw the technical plan and structure of the software.

3. Implementation and unit testing

Programmers start writing the actual code. They build the different parts of the software (like the login screen
or the calculator module). As they finish each small part, they immediately test it to make sure it works
correctly (Unit Testing).

 Goal: Write the source code based on the blueprint.

4. Integration and system testing

All the coded parts are put together, and the entire system is tested thoroughly. Testers try to find every bug and
check if the final software meets all the requirements from Step 1. The software must be perfect before
moving on.

 Goal: Fix all bugs and make sure the software does exactly what the customer asked for.

5. Operation and Maintenance

The software is released to the users. This is the longest phase, where the team takes care of the software, fixing
new bugs that pop up, updating it to work on new phones, and adding small improvements requested by users.

 Goal: Keep the software running well and up-to-date over time.

Prototype Model

This model is applied when there is an absence of detail information regarding input and output requirement of
software. Prototype model is suitable when the requirement of the client is not clear and it is supposed to be
changed. It doesn't cover any risk management.
1. Identify User Problem (Gather Basic Needs)

The team starts by interviewing the user to get a general idea of the system's goals and basic functions. Unlike
the Waterfall Model, they don't try to get every detail right away. They just need enough information to build
a quick, simple model that represents the key features.

2. Develop a Prototype (Build a Quick Model)

The system analyst and programmers quickly build a functional prototype. This is a fast, initial version of the
software that shows what the final product might look like and how it will work. Specialized tools are often
used to build this model quickly, focusing on the visible parts (the user interface) rather than complex, perfect
code.

3. Determine if Prototype is Acceptable (Get Feedback)

The most important step is getting user feedback. The user interacts with the prototype and tells the analyst
what they like, what they don't like, and what features are missing or confusing.

 If the prototype is satisfactory: It is approved and used as the final blueprint for building the high-
quality final software.
  If the prototype is NOT satisfactory: The entire cycle repeats from the beginning. The analyst goes
back, updates the requirements, and a new, improved prototype is quickly built.

Agile model

Agile model believes that every project needs to be handled differently and the existing methods need to be
tailored to best suit the project requirements. In Agile, the tasks are divided to time boxes (small time frames) to
deliver specific features for a release.

Iterative approach is taken and working software build is delivered after each iteration. Each build is
incremental in terms of features; the final build holds all the features required by the customer.

Planning

The Planning phase is the foundational step where the team defines the project's vision, scope, and strategic
goals. This includes determining the feasibility of the project and, in an Agile context, involves high-level
Release Planning and detailed Iteration (Sprint) Planning. The primary output is a prioritized Product
Backlog—a living list of all the features and work required to deliver value, setting the direction for the team's
work.

Requirement Analysis

In Requirement Analysis, the team actively collaborates with stakeholders to understand and document what
the software needs to do from a user's perspective. Requirements are captured as clear, concise User Stories
and are continuously refined. This phase ensures the development effort is focused on delivering features that
genuinely solve user problems and meet business objectives, rather than simply building a pre-defined set of
specifications.

Designing

The Designing phase focuses on creating the blueprint for the software system, covering architecture, user
interface (UI), and technical specifications. In Agile, design is an iterative process, meaning only a sufficient
amount of design is done for the current working increment, allowing the overall architecture to emerge and
adapt as the product evolves. The goal is to ensure the system is stable, maintainable, and scalable.

Building

The Building phase is where the development team writes the actual code, turning the design and requirements
into a functional piece of software. This is a highly collaborative step that involves writing code, conducting
frequent Code Reviews, and employing Continuous Integration to ensure all developed pieces work together
seamlessly. The deliverable for this phase is a small, working, and deployable increment of the product.

Testing

Testing is a continuous process integrated into every iteration, ensuring the built software is high-quality, free
of defects, and meets the user requirements. This involves various types of testing, including unit, integration,
and user acceptance tests. Successful completion of the testing phase validates that the increment is ready for
release, proving it is a reliable and working piece of the larger product.

Advantages of prototyping model

 Helps in reducing risk associated with the the project.

 There is great involvement of user in software development.
Disadvantages of prototyping model

 Time consuming and expensive because if the user is not satisfied by the developed prototype new prototype
should be developed. This process goes on until a perfect prototype is developed which satisfies the user.

Systems Analyst

A Systems Analyst is an Information Technology (IT) professional who acts as a bridge between business
needs and technology solutions. They use analysis and design techniques to study an organization's existing
computer systems and procedures and then design or recommend improvements to help the organization operate
more efficiently.

The primary function of a Systems Analyst is to translate business objectives into detailed technical
requirements that programmers and developers can use to build or configure a system. They are essentially
problem solvers who leverage IT to achieve business goals.

Key Responsibilities

A Systems Analyst's duties span the entire system development lifecycle, often including:

 Requirements Elicitation and Analysis: They meet with stakeholders, managers, and end-users to
understand business challenges, gather requirements, and define what the new or improved system must
accomplish.
 Feasibility Assessment: They conduct studies to determine the technical, operational, and financial
viability of proposed solutions, including cost-benefit analyses.
 System Design: They create logical design specifications, including data models, process flowcharts,
and system architecture diagrams, translating the user requirements into a technical blueprint.
 Liaison and Coordination: They work closely with developers and programmers to guide the
development process and ensure the final product aligns with the initial design and requirements.
 Testing and Quality Assurance: They collaborate on testing strategies to validate that the new system
functions correctly and meets all quality standards.
 Implementation and Training: They oversee the deployment of the new system and develop training
materials and manuals to help end-users adopt the new technology effectively.
Required Skills

A successful Systems Analyst possesses a balanced mix of technical knowledge and business acumen:

 Analytical and Problem-Solving Skills: The ability to dissect complex business processes, identify
root causes of problems, and devise logical, effective solutions.
 Technical Knowledge: A strong understanding of IT infrastructure, software development
methodologies (like Agile), database systems, and networking.
 Communication Skills: The ability to clearly and effectively communicate complex technical concepts
to non-technical business users and vice-versa.
 Business Acumen: A solid grasp of the organization's mission, goals, and operational processes to
ensure technology decisions are strategically aligned.

Requirement Collection Methods

The process of Requirement Collection (also known as Requirements Elicitation) is a crucial phase in the
Software Development Life Cycle (SDLC). It's the practice of researching and discovering the needs and
expectations of a system from users, customers, and other stakeholders.

A variety of techniques are used to gather comprehensive, clear, and unambiguous requirements. The most
effective approach is often to use a combination of these methods based on the project's nature, scale, and
stakeholders involved.

1. Interviews

Interviews involve direct, one-on-one communication with key stakeholders, users, and subject matter experts.
This method is highly effective for gathering detailed, in-depth, and qualitative information about a user's
workflow, pain points, and needs. The analyst can ask open-ended questions, observe body language, and
immediately clarify any ambiguities, making it a powerful technique for uncovering the "why" behind a
requirement.

2. Questionnaires or Surveys

Questionnaires or Surveys are a systematic method for gathering information from a large and potentially
widespread audience. This technique is excellent for collecting quantitative data on preferences, priorities,
and usage frequency, which can be statistically analyzed. Surveys are time-efficient and cost-effective for
reaching many stakeholders, but the depth of information gathered is limited to the questions asked.

3. User Observation

User Observation involves the analyst watching end-users perform their tasks in their actual work
environment, either passively or actively. The primary goal is to discover implicit requirements—needs the
user might not consciously articulate—by identifying inefficiencies, workarounds, or pain points in the existing
process. This method provides an accurate understanding of the real-world context and workflow that the new
system must support.
4. Analyzing Existing Documents

Analyzing Existing Documents (or document analysis) involves reviewing current system manuals, reports,
forms, business process models, and organizational charts. This is a non-intrusive way to extract business rules,
technical constraints, historical requirements, and 'as-is' process flows. It provides a solid starting point and
context for the new system, ensuring the new design adheres to established policies and standards.

5. Prototyping

Prototyping is an iterative technique where a preliminary, often working, model or mockup of the final system
is built. By having stakeholders interact with the prototype, the development team can visualize and validate
requirements early and continuously. This minimizes misunderstandings, generates immediate feedback, and
helps rapidly refine complex user interface and functional requirements before significant development
investment is made.