System Planning, Project Initiation, Problem Identification, and Existing System Analysis

Course: System Analysis and Design

Topic: Preliminary Investigation and System Analysis

Case Study: Student Attendance Management System

Learning Outcomes

After completing this tutorial, students should be able to:

Explain the purpose and importance of system planning.
Describe how a project is initiated and authorized.
Identify organizational problems and their root causes.
Distinguish between symptoms, problems, and root causes.
Investigate and document an existing information system.
Use interviews, observations, questionnaires, and document reviews to collect information.
Analyze the weaknesses of an existing system and identify improvement opportunities.
Prepare preliminary system analysis documents for a real-world project.

1. Introduction

Organizations use information systems to manage data, perform daily operations, support decision-making, and provide services. However, an existing system may become inefficient as the organization grows or its requirements change.

For example, a university may initially manage student attendance using paper registers and spreadsheets. When the number of students increases, teachers may face difficulties recording attendance, calculating percentages, identifying students with poor attendance, and preparing reports.

Before developing a new software system, a system analyst must understand the organization, identify the actual problems, investigate the existing procedures, and determine whether a new system is necessary.

System Planning → Project Initiation → Problem Identification → Existing System Analysis → Requirements Analysis → System Design → Development

This sequence is a simplified learning model. In real projects, these activities may overlap or be repeated as new information becomes available.

2. System Planning

2.1 What Is System Planning?

System planning is the process of determining an organization's information-system needs, setting priorities, identifying possible solutions, estimating resources, and deciding which projects should be undertaken.

It helps an organization ensure that its technology projects support its business objectives rather than being developed without a clear purpose.

Example: A university plans to improve its academic services. Management identifies several possible projects, including online registration, student attendance monitoring, result processing, and library automation. System planning helps management decide which project should receive priority.

2.2 Objectives of System Planning

Align IT with organizational goals: Ensure that proposed systems support institutional objectives.
Identify system needs: Determine where information systems can improve performance.
Set priorities: Decide which projects should be implemented first.
Estimate resources: Identify required staff, hardware, software, time, and budget.
Reduce risk: Identify major technical, financial, operational, and organizational risks.
Improve coordination: Coordinate related projects and departments.
Support decision-making: Provide management with evidence for project approval.

2.3 Major Activities in System Planning

Activity	Description	Example
Review organizational goals	Understand the institution's strategic objectives.	Improve academic monitoring and student services.
Identify information needs	Determine what information different departments require.	Teachers need attendance summaries; administrators need section-wise reports.
Identify potential projects	Prepare a list of possible system improvements.	Attendance system, registration system, and result management system.
Prioritize projects	Rank projects according to urgency, benefits, cost, and risk.	Prioritize attendance monitoring because reports are frequently delayed.
Estimate resources	Estimate the budget, personnel, technology, and time needed.	Assign a developer, analyst, database administrator, and faculty representatives.
Prepare a roadmap	Schedule approved projects and major milestones.	Complete investigation before designing the attendance system.

2.4 Project Prioritization

An organization may have several project proposals but limited resources. Therefore, it needs a systematic method for comparing them.

The following illustrative scoring model uses a scale of 1 to 5, where 5 represents the highest priority or strongest performance.

Criteria	Weight	Attendance System Score	Weighted Score
Operational importance	30%	5	1.50
Expected benefits	25%	4	1.00
Technical feasibility	20%	4	0.80
Cost affordability	15%	4	0.60
Implementation urgency	10%	5	0.50
Total weighted score			4.40 / 5.00

These scores are hypothetical and illustrate the method. Actual scores should be supported by stakeholder input and evidence.

Weighted score formula:

Weighted Score = Σ (Criterion Weight × Criterion Rating)

The weights should add up to 100%. A higher score may indicate greater priority, but management should also consider mandatory requirements, legal obligations, dependencies, and risks.

2.5 Deliverables of System Planning

Information-system needs assessment
List of proposed projects
Project priority matrix
Preliminary resource estimates
High-level implementation roadmap
Initial risk assessment

3. Project Initiation

3.1 What Is Project Initiation?

Project initiation is the process of formally starting a specific project. It establishes why the project is needed, what it is expected to achieve, who is involved, and what initial boundaries and resources will apply.

System planning considers information-system needs across an organization. Project initiation focuses on one selected project and establishes a shared understanding of its purpose.

Example: After prioritizing attendance monitoring, university management authorizes a preliminary investigation of a Student Attendance Management System. A project sponsor is appointed, an analyst is assigned, and the department is asked to provide access to relevant attendance records and procedures.

3.2 Why Is Project Initiation Important?

Clarifies the reason for starting the project.
Defines the initial scope and boundaries.
Identifies the project sponsor and key stakeholders.
Establishes preliminary objectives.
Authorizes investigation and the use of agreed resources.
Creates a basis for deciding whether the project should continue.

3.3 Major Activities in Project Initiation

Step	Activity	Practical Output
1	Recognize the need	Initial statement of the organizational problem.
2	Identify the sponsor	Person or authority responsible for supporting the project.
3	Identify stakeholders	List of people affected by or involved in the system.
4	Define preliminary objectives	Measurable or testable statements of intended outcomes.
5	Establish initial scope	Initial list of included and excluded functions.
6	Assign project responsibilities	Named project roles and decision-making responsibilities.
7	Authorize the project	Approved project charter or initiation document.

3.4 Project Charter

A project charter is a high-level document that formally authorizes a project or investigation. Its exact format depends on the organization.

A typical project charter includes:

Project name
Background and business need
Problem statement
Project objectives
Preliminary scope
Project sponsor and project manager
Key stakeholders
Initial schedule and budget estimates
Major risks and assumptions
Approval and authorization

3.5 Sample Project Charter

Project Charter: Student Attendance Management System

Project ID: SAMS-01

Project Sponsor: University administration

Project Team: System analyst, developer, database specialist, faculty representative, and academic administration representative

Background: Attendance records are currently maintained through paper registers or separate spreadsheets. Preparing consolidated attendance reports requires additional manual effort.

Problem Statement: The current process may cause delays, duplicate data entry, inconsistent records, and difficulty identifying students whose attendance falls below institutional requirements.

Project Objective: Investigate and develop a secure system that records class attendance, calculates attendance percentages, and generates reports by student, course, section, and date.

Preliminary Scope — Included:

Student, teacher, course, and section records
Class-session management
Attendance entry and correction with authorization
Attendance percentage calculation
Attendance reports

Preliminary Scope — Excluded:

Online examination management
Tuition fee collection
Full student registration management

Initial Technical Possibility: JSP, Java, JDBC, and Oracle Database, subject to technical and infrastructure assessment.

Success Criteria: Authorized users can record attendance, retrieve accurate reports, and correct errors through an auditable process. Specific performance and accuracy targets will be agreed after requirements investigation.

Approval: To be completed by the authorized project sponsor.

3.6 Identifying Stakeholders

A stakeholder is a person, group, or organization that can affect a project, is affected by it, or has an interest in its outcome.

Stakeholder	Interest or Responsibility	Information Required
University management	Institutional monitoring and policy compliance	Consolidated reports and overall performance indicators
Head of Department	Departmental monitoring	Course-wise and section-wise attendance reports
Teachers	Recording and verifying attendance	Class lists and attendance-entry interface
Students	Checking attendance records	Personal attendance summaries and correction procedures
Academic administration	Maintaining official records	Standardized reports and authorized corrections
IT team	Technical operation and security	Infrastructure, access control, backup, and maintenance requirements

4. Problem Identification

4.1 What Is Problem Identification?

Problem identification is the process of discovering and clearly defining the gap between the current situation and the desired situation.

The goal is not simply to collect complaints. A system analyst must investigate the evidence, identify the people affected, understand the consequences, and determine the underlying causes.

4.2 Problem, Symptom, and Root Cause

These three concepts are related but different.

Concept	Meaning	Attendance Example
Symptom	An observable sign that something may be wrong.	Attendance reports are submitted late.
Problem	The operational difficulty that needs to be addressed.	The university cannot obtain reliable consolidated attendance information quickly.
Root cause	An underlying reason contributing to the problem.	Records are maintained separately, and report preparation requires repeated manual calculations.

Important: Do not assume that every symptom has only one root cause. Interviews, observation, and record review may reveal several contributing causes. A software system may help, but policy, training, staffing, or process changes may also be necessary.

4.3 Common Sources of Problems

People: Insufficient training, unclear responsibilities, or inconsistent work practices.
Process: Repeated manual entry, unnecessary approval steps, or poorly defined procedures.
Technology: Slow software, incompatible systems, unreliable networks, or limited access.
Data: Duplicate records, missing fields, inconsistent identifiers, or inaccurate information.
Management: Unclear policies, limited resources, or insufficient monitoring.
Security: Excessive access permissions, weak authentication, or missing audit trails.

4.4 Techniques for Identifying Problems

A. Interviews

The analyst asks questions directly to people who use, manage, or depend on the existing system.

Sample questions for teachers:

How do you currently record attendance?
How much time do you spend preparing attendance reports?
What errors occur most frequently?
How do you correct an attendance entry?
What information should an improved system provide?

B. Observation

The analyst observes the actual work rather than relying only on what people say they do.

Example: The analyst observes a teacher taking attendance in class and later transferring the information into a spreadsheet. This may reveal duplicate entry, delays, and opportunities for mistakes.

C. Questionnaires

Questionnaires help collect structured information from a large group of users.

Example questions:

How often do you check attendance records?
Have you experienced an incorrect attendance entry?
How easy is it to obtain attendance information?
Which reports would be most useful to you?

D. Document Review

The analyst reviews existing forms, attendance registers, spreadsheets, reports, policy documents, and correction requests.

Example: Comparing a paper attendance register with the final spreadsheet may reveal differences between the original and consolidated records.

E. Root-Cause Analysis

Root-cause analysis attempts to discover why a problem occurs instead of addressing only its visible effects.

Example using the Five Whys:

Why are attendance reports late? Because the data must be consolidated manually.
Why is consolidation manual? Because different teachers maintain separate files.
Why are separate files used? Because there is no shared attendance database.
Why is there no shared database? Because the current process was designed around individual registers and spreadsheets.
Why has the process not changed? Because system requirements and improvement options have not been formally evaluated.

This example suggests possible causes, but the analyst must validate each answer with evidence rather than treating the Five Whys as proof.

4.5 Fishbone Analysis

A fishbone diagram organizes possible causes into categories. The following simplified diagram illustrates possible causes of inaccurate attendance records.

 People ------------------\
 - Inadequate training     \
 - Inconsistent practice    \
                             \
 Process --------------------\
 - Duplicate entry            \
 - No standard correction     \
                                > INACCURATE
 Technology -----------------/  ATTENDANCE RECORDS
 - Separate spreadsheets     /
 - Network or device issues /
                            /
 Data ---------------------/
 - Missing student IDs
 - Duplicate records

The diagram is a starting point for investigation. Each proposed cause should be tested by reviewing records, observing work, or interviewing stakeholders.

4.6 Writing a Good Problem Statement

A problem statement should explain:

The current situation
The specific difficulty
The people or processes affected
The operational consequences
The evidence available or evidence that must be collected

Weak problem statement: The university needs a modern attendance application.

Improved problem statement: Attendance information is currently maintained in separate paper registers or spreadsheets. Consolidated reports require manual collection and calculation, which may delay reporting and increase the risk of inconsistent records. The frequency of errors, report-preparation time, and affected user groups will be verified during the preliminary investigation.

The improved version describes the problem without prematurely deciding that a particular technology is the only solution.

4.7 Problem Identification Matrix

Observed Issue	Possible Cause	Operational Impact	Evidence to Collect
Reports take a long time to prepare.	Manual consolidation of separate files.	Delayed academic monitoring.	Report-preparation times and current report samples.
Some records are inconsistent.	Duplicate entry or inconsistent identifiers.	Reduced confidence in reports.	Compare registers, spreadsheets, and correction records.
Students question attendance totals.	Unclear correction procedures or delayed updates.	Additional administrative work.	Review complaints and the correction workflow.
Authorized staff cannot obtain a report quickly.	Information is distributed across multiple files.	Delayed decisions.	Observe report requests and retrieval procedures.

5. Existing System Analysis

5.1 What Is Existing System Analysis?

Existing system analysis is the systematic investigation of how the current system operates, including its users, procedures, data, documents, software, hardware, controls, and limitations.

Its purpose is to understand the current situation before deciding what should be changed.

In system analysis, the current system is often called the AS-IS system, while the proposed improved system is called the TO-BE system.

AS-IS: How the system works today

↓ Investigation and analysis

TO-BE: How the improved system should work

5.2 Objectives of Existing System Analysis

Understand the current workflow.
Identify users and their responsibilities.
Understand how data enters, moves through, and leaves the system.
Identify documents, forms, reports, and databases.
Evaluate current controls and security practices.
Identify bottlenecks, duplication, errors, and unnecessary work.
Identify useful features that should be retained.
Establish a factual baseline for requirements and system design.

5.3 Components to Investigate

Component	Questions to Investigate	Attendance Example
People	Who uses the system? Who approves changes?	Teachers record attendance; authorized administrators review records.
Processes	What steps are followed, and in what order?	Record attendance, calculate totals, prepare reports.
Data	What data is collected, stored, and updated?	Student ID, course, section, class date, and attendance status.
Inputs	What information enters the system?	Class list and attendance marks.
Outputs	What reports or results are produced?	Student-wise and course-wise attendance reports.
Technology	What software and hardware are used?	Paper registers, spreadsheets, computers, and printers.
Controls	How are errors, unauthorized changes, and data loss prevented?	Approval for corrections, access restrictions, and backup procedures.
Interfaces	How does information move between departments or systems?	Teachers submit records to academic administration.

5.4 Existing Attendance System: AS-IS Workflow

Assume a university currently uses paper registers and spreadsheets. The analyst discovers the following workflow during observation and interviews.

1. Teacher receives or prepares the class list.
                |
                v
2. Teacher records attendance in a paper register.
                |
                v
3. Attendance information is transferred to a spreadsheet.
                |
                v
4. Separate files are collected from teachers.
                |
                v
5. Administrative staff consolidate the information.
                |
                v
6. Attendance percentages are calculated.
                |
                v
7. Reports are prepared and distributed.

Possible weaknesses include duplicate data entry, delayed consolidation, calculation errors, inconsistent file formats, and difficulty tracing corrections. The analyst must determine which of these weaknesses actually occur in the organization being studied.

5.5 Data Flow in the Existing System

A Data Flow Diagram (DFD) represents how information moves between external entities, processes, and data stores.

The following is a simplified conceptual representation of the existing attendance process.

[Teacher]
    |
    | Attendance marks
    v
(Record Attendance)
    |
    v
[Paper Register]
    |
    | Manual transfer
    v
(Update Spreadsheet)
    |
    v
[Attendance Files]
    |
    | Consolidation
    v
(Prepare Attendance Report)
    |
    v
[Department / Administration]

This diagram is a teaching illustration rather than a formal DFD notation. A formal DFD should use consistent symbols and clearly defined processes, data stores, external entities, and labeled data flows.

5.6 Document and Form Analysis

The analyst should collect and examine the documents used by the existing system.

Document	Information to Examine	Potential Finding
Paper attendance register	Student identifiers, dates, presence marks, signatures.	Missing identifiers or difficult-to-read entries.
Attendance spreadsheet	Column structure, formulas, validation, naming conventions.	Inconsistent formats or incorrect formulas.
Attendance report	Report layout, calculations, recipients, and frequency.	Missing course or date information.
Correction request	Reason for correction, approval, and update history.	No consistent way to track changes.
Attendance policy	Definitions, thresholds, exceptions, and approval rules.	Different interpretations of the same policy.

Personal student data should be handled securely. The analyst should use authorized access, collect only necessary information, and avoid including identifiable student records in teaching examples or public reports.

5.7 Evaluating the Existing System

A common way to organize the investigation is to examine the following areas.

Evaluation Area	Meaning	Questions for the Analyst
Performance	How quickly and reliably work is completed.	How long does attendance entry and report preparation take?
Information	Accuracy, completeness, availability, and usefulness of information.	Are attendance reports accurate and available when needed?
Economics	Costs and use of organizational resources.	How much staff time and material are required?
Control	Protection against errors, unauthorized access, and data loss.	Who can change attendance records? Are changes traceable?
Efficiency	How much unnecessary work or duplication occurs.	Is the same information entered more than once?
Service	How well the system serves its users.	Can teachers and students obtain understandable information?

5.8 Measuring the Current System

System analysis becomes more reliable when observations are supported by measurements.

Possible baseline measures include:

Average time required to record attendance for one class.
Average time required to prepare a consolidated report.
Number of attendance corrections requested during a defined period.
Number of duplicate or incomplete records found in a sample.
Time required to retrieve a student's attendance history.
Number of manual steps in the reporting process.

Illustrative measurement: If preparing one consolidated report takes 90 minutes under the current process, the project team may establish a target of generating it within 5 minutes after the data is finalized. These figures are examples only. Actual baselines and targets must be based on observation and agreed requirements.

5.9 Strengths and Weaknesses of the Existing System

Possible Strengths	Possible Weaknesses
Paper registers provide a physical record.	Manual searching can be time-consuming.
Spreadsheets are familiar to many staff members.	Separate files can create inconsistent versions of the data.
Initial implementation cost may be low.	Manual consolidation can require substantial staff time.
Teachers may already understand the process.	Reports may depend on individual formulas and working practices.

A good analyst does not assume that every existing practice is bad. Useful controls, familiar procedures, and legally required records may need to be retained during system improvement.

6. Comparing the Existing System with the Proposed System

After investigating the AS-IS system, the analyst can describe a preliminary TO-BE workflow. The proposed workflow must still be validated with stakeholders and tested for feasibility.

Area	Existing System (AS-IS)	Proposed System (TO-BE)
Attendance entry	Paper register and/or separate spreadsheet.	Authorized teacher enters attendance through a web interface.
Data storage	Paper documents and separate files.	Centralized relational database.
Calculation	Manual or spreadsheet-based calculation.	System calculates attendance using approved rules.
Reporting	Information is collected and consolidated manually.	Reports are generated from authorized database records.
Corrections	May depend on handwritten notes or file updates.	Authorized correction workflow with change history.
Access control	May depend on physical access or file-sharing practices.	Role-based permissions and authenticated access.
Backup	May rely on paper copies or manual file copies.	Documented and tested database backup and recovery procedures.

The TO-BE system is a proposal, not proof that every proposed feature is necessary or feasible. Security, usability, infrastructure, costs, and stakeholder needs must be evaluated before final design.

7. Feasibility Considerations

During preliminary investigation, the analyst should determine whether the project appears practical. A more detailed feasibility study may be needed before management commits to full development.

Feasibility Type	Main Question	Attendance System Example
Technical	Can the organization build, operate, and maintain the system?	Are suitable servers, database expertise, and reliable network access available?
Economic	Do expected benefits justify costs?	Will reduced manual effort justify development, hosting, and maintenance expenses?
Operational	Will the system work in the organization's real environment?	Can teachers use the system during class without disrupting teaching?
Schedule	Can the system be completed within the required time?	Can analysis, development, testing, training, and deployment fit the academic calendar?
Legal and compliance	Can the system meet applicable rules and obligations?	Are student-data access, retention, and privacy requirements addressed?

8. Complete Practical Case Study

Case: Student Attendance Management System

A university department wants to improve the way it records and monitors attendance. The department currently uses paper registers, spreadsheets, and manually prepared reports. Management has requested an initial investigation before deciding whether to develop a new system.

Step 1: System Planning

The university reviews its academic monitoring needs and identifies attendance reporting as a potential improvement area. The proposed project is compared with other priorities based on expected benefits, cost, urgency, technical feasibility, and institutional needs.

Output: A prioritized proposal for investigating an attendance management system.

Step 2: Project Initiation

Management appoints a sponsor and an analyst. The analyst receives authorization to interview teachers, inspect sample records, observe the current workflow, and document preliminary requirements.

Output: Project charter, preliminary scope, stakeholder list, and investigation plan.

Step 3: Problem Identification

The analyst interviews teachers and administrative staff, observes attendance reporting, and examines a sample of existing files. The investigation identifies potential problems such as duplicate entry, delayed consolidation, inconsistent file formats, and difficulty tracing corrections.

Output: A documented problem statement and a list of verified issues and their likely causes.

Step 4: Existing System Analysis

The analyst documents who records attendance, where records are stored, how reports are prepared, how corrections are made, and what controls protect the records. The analyst measures reporting time and checks a sample for inconsistencies.

Output: AS-IS workflow, document inventory, data-flow description, baseline measurements, and system strengths and weaknesses.

Step 5: Initial Improvement Proposal

The analyst proposes a centralized web-based application with role-based access, attendance entry, automatic percentage calculation, reporting, and controlled corrections. The proposal is reviewed for feasibility and refined with stakeholder feedback.

Output: Preliminary TO-BE workflow and recommendations for requirements analysis.

Possible System Architecture

Teacher / Authorized Administrator
               |
               v
        Web Browser
               |
               v
       JSP User Interface
               |
               v
      Java Application Logic
               |
               v
         JDBC Connection
               |
               v
       Oracle Database
               |
               v
 Attendance Records and Reports

This architecture is a proposed implementation example. The final architecture should be selected after considering security, maintainability, deployment constraints, performance, and institutional standards.

9. Suggested Database Entities for the Case Study

At the analysis stage, the team can identify the main information entities without committing to every implementation detail.

Entity	Purpose	Example Attributes
STUDENT	Stores student information.	student_id, student_name, section_id
TEACHER	Stores teacher information.	teacher_id, teacher_name, email
COURSE	Stores course information.	course_id, course_title, credit_hours
SECTION	Represents a class group or section.	section_id, section_name, batch
COURSE_OFFERING	Represents a course assigned to a section and teacher for a term.	offering_id, course_id, section_id, teacher_id, term
CLASS_SESSION	Represents a scheduled class meeting.	session_id, offering_id, class_date
ATTENDANCE	Stores each student's attendance for a class session.	attendance_id, session_id, student_id, status, updated_at
USER_ACCOUNT	Supports authentication and access control.	user_id, username, password_hash, role

These are conceptual entities, not a complete production schema. Keys, constraints, enrollment relationships, unique attendance rules, correction history, and security controls must be specified during detailed data and system design.

10. Sample Existing System Analysis Report

Preliminary Investigation Report

Project: Student Attendance Management System

Purpose: To investigate the current attendance-recording process and determine whether a centralized information system could improve reporting and control.

Current Process: Teachers record attendance using paper registers and/or spreadsheets. Attendance data is subsequently consolidated to prepare reports.

Potential Issues to Validate:

Repeated manual data entry
Delayed preparation of consolidated reports
Inconsistent record formats
Difficulty tracking corrections
Limited visibility into attendance trends

Investigation Methods: Interviews, direct observation, document review, and sample record verification.

Initial Recommendation: Continue to requirements analysis if the investigation confirms that a centralized system is feasible and would provide sufficient operational benefits.

Limitations: This sample report is illustrative. The actual report must contain findings supported by the organization's evidence, including measured baselines and stakeholder feedback.

11. Common Mistakes Students Should Avoid

Starting with a solution: Choosing a technology before understanding the problem.
Confusing symptoms with causes: Treating late reports as the root cause rather than investigating why reports are late.
Ignoring users: Collecting requirements only from management while overlooking teachers and administrative staff.
Assuming the existing system is entirely bad: Failing to identify useful features and controls that should be retained.
Relying only on interviews: Not checking statements against actual workflows and records.
Defining scope too broadly: Adding registration, results, finance, and other modules when the initial project concerns attendance.
Using unsupported measurements: Claiming a certain percentage of errors or time savings without evidence.
Ignoring security: Forgetting that attendance records contain information that should be protected.
Confusing analysis with design: Designing database tables and screens before understanding and validating the requirements.

12. Review Questions

Short Questions

What is system planning?
Why is project initiation necessary?
What is a project charter?
Who is a stakeholder?
Differentiate between a problem, a symptom, and a root cause.
What is existing system analysis?
What do AS-IS and TO-BE mean?
List four fact-finding techniques used by system analysts.
What is root-cause analysis?
Why should a system analyst measure the performance of the existing system?

Analytical Questions

A university prepares attendance reports manually. Reports are frequently late. Identify three possible root causes and explain how you would investigate each one.
Explain the difference between system planning and project initiation using the attendance system case.
Prepare an AS-IS workflow for a paper-based library borrowing system.
Develop a problem identification matrix for a university registration process.
Explain why a system analyst should examine existing forms, reports, and records before designing a new system.

13. Practical Classroom Activity

Activity title: Analyze an Existing Student Attendance Process

Task: Assume your university currently uses paper attendance registers and spreadsheets. Work individually to prepare a preliminary system analysis document.

Your submission must include:

A brief description of the current system.
Five interview questions for teachers.
Five possible problems and their potential root causes.
An AS-IS workflow diagram.
A table of existing system strengths and weaknesses.
Three measurable indicators for evaluating the current system.
A preliminary project objective and scope statement.
Three proposed improvements with a short justification for each.

Important: Clearly distinguish assumed facts from verified findings. Do not present hypothetical measurements as actual university data.

14. Summary

Topic	Main Purpose	Typical Deliverable
System Planning	Identify information-system needs and set priorities.	Project portfolio, priority matrix, and roadmap.
Project Initiation	Authorize and establish the initial direction of a project.	Project charter and initial scope.
Problem Identification	Understand the gap between current and desired conditions.	Evidence-based problem statement and root-cause findings.
Existing System Analysis	Understand current processes, data, controls, and limitations.	AS-IS workflow, document inventory, baseline measures, and findings.

Final concept: A successful information system begins with understanding the organization's needs. System planning determines priorities, project initiation establishes authorization and direction, problem identification explains what needs to improve, and existing system analysis reveals how the current process actually works. These activities provide the foundation for accurate requirements and effective system design.