Course outline

1. introduction

2 Analyst's role; Feasibility studies

3 Requirements elicitation

4 Context & Level 0 DFDs

5 Detailed DFDs; Decision tables/trees

6 ER modeling & normalization

7 Top-down/bottom-up design; CASE tools

8 Input/output & UI prototyping

9 Midterm exam

10 System architecture & detailed design

11 Data & file design

12 System implementation & testing

13 Training & changeover strategies

14 System maintenance; Final review & Exam

Introduction to Systems & SDLC

1. What is a System?

 Definition: A system is an organized collection of interrelated components working towards

 Types:

o Natural (e.g., ecosystem)

o Human-built (e.g., computer, social systems)

1.1 Information Systems

 A specialized system that captures, processes, stores, and distributes information to support
organizational functions.

 Five components:

1. Hardware – physical devices

2. Software – system and application programs

3. Data – raw inputs transformed into meaningful outputs

4. Processes – procedures and workflows

5. People – users and stakeholders

2. Systems Analysis vs. Systems Design

 Systems Analysis: Understanding and specifying what a system must do Systems Design:
Defining how system components should work together to meet those requirements

3. The Systems Development Life Cycle (SDLC)

3.1 Purpose

An SDLC is a structured framework guiding the planning, creation, testing, deployment, and maintenance
of an information system ‐ with the goal of delivering high-quality software on time and within budget.

3.2 Common Phases

1. Planning / Initiation

o Identify business needs, scope the project, conduct feasibility (technical, economic,
organizational) and cost–benefit analysis.

2. Analysis / Requirements
 o Gather and document requirements, model business processes and data

3. Design

o Architect the system: UI, database, interfaces, and detailed design specs

4. Development / Construction

o Write code, configure systems, build data structures.

5. Testing

o Create test plans, conduct unit, integration, system, and user-acceptance tests.

6. Implementation / Deployment

o Deploy to production (pilot, go-live), train users

7. Maintenance / Support

o Fix defects, enhance features, monitor performance and usage 3.3 Iterative & Agile
Alternatives

 Traditional Waterfall models are linear and sequential

 Iterative models (e.g., V-Model, Spiral) allow revisiting earlier steps, reducing risk.

 Agile approaches (Scrum, XP) emphasize flexibility, collaboration, and delivering working
software in short increments

4. Why SDLC Matters

 Ensures clear structure and defined deliverables.

 Helps manage resources, timelines, and scope effectively.

 Promotes stakeholder involvement, accountability, and documentation.

 Enables quality assurance through systematic reviews and testing.

5. Key Concepts Recap

Term Definition

System Interconnected set of elements working toward a goal

Information System processing data into actionable info via hardware, software, data, processes,
System people

Systems Analysis Determining system requirements and boundaries

Systems Design Structuring how requirements are technically accomplished

SDLC Step-by-step framework guiding system development lifecycle

Lecture Notes:

Role of the Systems Analyst & Feasibility

1. Introduction

The role of a systems analyst is central to successful system development. The analyst acts as a bridge
between business needs and technology solutions, ensuring the final product meets stakeholder
expectations and organizational goals.

Feasibility studies are conducted early in the system development life cycle (SDLC) to determine whether
a proposed project is viable and worth pursuing.

2. Who is a Systems Analyst?

Definition:

A systems analyst is a professional who analyzes, designs, and implements information systems to
support business needs and models.

3. Core Roles of a Systems Analyst

a. Problem-Solver

 Understands organizational challenges

 Diagnoses problems and proposes solutions using IT systems

b. Liaison

 Acts as a bridge between technical teams (developers, engineers) and non-technical

 Translates business requirements into system specifications

c. Facilitator

 Leads and organizes requirement gathering sessions

 Mediates between conflicting stakeholder interests

 Evaluates current systems and identifies areas for improvement

 Performs feasibility studies

e. Designer

 Helps in system design—both logical (data flow, processes) and physical (hardware/software
configurations)

f. Project Contributor

 Participates in planning, budgeting, and scheduling of IT projects

 Supports documentation, training, and post-implementation reviews

4. Stakeholder Communication

Who are Stakeholders?

 Individuals or groups affected by or involved in the system

o Users

o Managers

o Clients

o IT Staff

o Vendors

o Regulatory Bodies

Why is Communication Important?

 Ensures mutual understanding of goals

 Helps gather accurate and complete requirements

 Builds trust and reduces resistance to change

 Aligns project outcomes with business needs

Communication Techniques:

 Interviews and Questionnaires

 Joint Application Development (JAD) sessions

 Workshops and Meetings

 Use Cases and User Stories

 Prototypes and Mockups

5. Feasibility Studies as Subheading

Feasibility studies help determine whether the proposed system is practical, sustainable, and aligned
with strategic goals.

Main Types of Feasibility:

a. Operational Feasibility

Definition:

Assesses whether the system will function effectively within the organization and be accepted by users.

Key Considerations:

 Will the system solve the intended problems?

 Is there adequate support and training for users?

 Does it align with business operations and culture?

 Will users adopt the system?

Indicators:

 Management support

 User willingness

 Organizational readiness

b. Technical Feasibility

Definition:

Evaluates whether the organization has the technology, expertise, and infrastructure to build and
maintain the system.

Key Considerations:

 Availability of technology and tools

 Technical expertise of staff or vendors

 Compatibility with existing systems

 Security and scalability

Indicators:
  Hardware and software requirements

 System architecture

 IT staff skills

c. Economic Feasibility

Definition:

Determines if the expected benefits outweigh the costs—often referred to as cost-benefit analysis.

Key Considerations:

 Development and implementation costs

 Operating and maintenance costs

 Tangible and intangible benefits (e.g., efficiency, user satisfaction)

Indicators:

 Return on Investment (ROI)

 Net Present Value (NPV)

 Payback Period

d. Schedule Feasibility

Definition:

Assesses whether the system can be developed in a reasonable time frame.

Key Considerations:

 Project deadlines and milestones

 Availability of personnel and resources

 Risk of delays

Indicators:

 Project timeline

 Time estimates for each phase

 Critical path analysis

6. Conducting a Feasibility Study

1. Define the project scope

2. Identify alternatives and assumptions

3. Analyze each type of feasibility

4. Compare alternatives

5. Make recommendations

Outcome:

A Feasibility Report, which guides decision-makers on whether to proceed with, revise, or abandon the
project.

7. Importance of Feasibility Studies

 Prevents resource wastage

 Reduces risk of project failure

 Improves planning and design

 Helps secure stakeholder approval and funding