Imagine a university where students wait in long queues to register for courses, lecturers submit examination marks on paper, and students wait weeks to receive their transcripts.
These problems may appear to be caused by slow administrative processes. However, the underlying issue could be a system that relies on manual work, disconnected records, and repetitive tasks.
As developers, we should not rush to write code before understanding the problem. This is where systems analysis and design become important.
In this article, we will explore how a university can move from manual academic processes to a computer-based information system.
1. Understanding Systems, Systems Analysis, and Systems Design
Before building a solution, we need to understand three fundamental concepts.
What is a system?
A system is a collection of interconnected components that work together to achieve a common goal.
In a university, the academic administration system consists of:
- People: Students, lecturers, registrars, and examination officers.
- Processes: Student registration, examination marking, and transcript generation.
- Data: Student details, course registrations, examination marks, and academic records.
- Technology: Computers, databases, networks, and software applications.
These components work together to support academic administration.
From a developer's perspective, this means that a university information system is more than a collection of web pages. It is a combination of people, processes, data, and technology.
What is systems analysis?
Systems analysis is the process of examining an existing system to understand how it works, identify its problems, and determine what users need from a new or improved solution.
For example, before developing a transcript-generation application, we might investigate:
- How examination marks are currently submitted.
- Who verifies and approves the marks.
- How grades are calculated.
- Why transcript requests take so long.
- What information must appear on a transcript.
This investigation helps us define the actual problem instead of making assumptions.
What is systems design?
Systems design translates the requirements identified during analysis into a technical plan for the proposed solution.
For the university, this could involve designing:
- Database tables and relationships.
- User interfaces for students and lecturers.
- APIs for submitting and retrieving examination marks.
- Authentication and role-based authorization.
- Grade calculation and transcript-generation processes.
- Reports and audit logs.
For example, a developer might use Django REST Framework to build an API, PostgreSQL to store academic records, and React to build the user interface.
The important distinction is that analysis determines what the system needs to achieve, while design determines how the system will achieve it.
2. Three Problems with the Manual System and Their Solutions
Let's examine three practical problems and how software can address them.
Problem 1: Slow student registration
When students register using paper forms, university staff must manually review documents, enter details, and update records.
This can create long queues, duplicate records, and delays in confirming registration.
The software solution
An online student registration system could allow students to submit their details electronically.
The system could:
- Validate required fields.
- Check whether a student already exists.
- Verify course prerequisites where applicable.
- Store registration details in a centralized database.
- Generate registration confirmations automatically.
For example, a Django backend could expose a registration API that validates submitted data before saving it to PostgreSQL.
Instead of repeatedly entering information from paper forms, staff could retrieve records from the database.
Problem 2: Errors when recording examination marks
Manual mark entry introduces opportunities for transcription errors, incorrect calculations, and misplaced documents.
For example, a lecturer might record a mark of 76 on a paper sheet, but someone entering the result into a spreadsheet could accidentally enter 67.
Such mistakes can affect a student's final grade and academic progress.
The software solution
A computer-based examination management system could provide:
- Validated mark-entry forms.
- Student and course identification checks.
- Automatic grade calculations based on approved grading rules.
- Audit logs showing who changed a mark and when.
- Approval workflows before results are published.
For instance, the backend could reject marks outside the permitted range, provided the institution's grading rules define that range.
However, validation alone is not enough. The system must also support verification and controlled correction of marks.
Problem 3: Delayed transcript generation
When transcripts are prepared manually, examination officers may need to collect marks from several documents, calculate grades, verify results, and type the final report.
This takes time, especially when many students request transcripts simultaneously.
The software solution
A transcript-generation module could retrieve approved academic records from the database and produce a transcript automatically.
The workflow might look like this:
- The examination officer approves the student's results.
- The system retrieves the student's courses and approved marks.
- The system calculates grades according to university rules.
- The system generates the transcript.
- An authorized officer verifies or approves it before release, where required.
Automation can reduce repetitive work, but the system must preserve accuracy, privacy, and the university's approval procedures.
3. Identifying and Consulting Key Stakeholders
A technically sound application can still fail if it does not address the needs of its users.
That is why systems analysts consult stakeholders during the analysis phase.
The university project would involve several groups.
| Stakeholder | Information to collect |
|---|---|
| Students | Registration challenges, transcript requests, and access requirements |
| Lecturers | Mark submission procedures, grading rules, and correction processes |
| Examination officers | Result verification, grade approval, and transcript preparation |
| Registry staff | Student records, registration workflows, and document requirements |
| ICT staff | Existing infrastructure, integrations, security, and technical constraints |
| University management | Budget, institutional policies, reporting requirements, and project goals |
How would we collect this information?
As a systems analyst, I would use several techniques.
Interviews: Speak directly with examination officers, lecturers, and registry staff to understand their daily challenges.
Observation: Watch how student registration and transcript preparation currently work.
Questionnaires: Collect feedback from a larger number of students and staff.
Document analysis: Review existing registration forms, mark sheets, transcript templates, and academic policies.
The information gathered would help us produce clear system requirements before development begins.
4. Why Analyze the Existing System Before Designing a New One?
One of the biggest mistakes in software development is building a solution before understanding the problem.
Suppose the university's results are delayed because examination officers must obtain approvals from several departments. Developing software that only calculates grades faster will not necessarily solve the main problem.
The approval process itself may need improvement.
Analyzing the existing system helps us:
Identify root causes. We can distinguish between problems caused by manual data entry, inefficient workflows, missing approvals, and technical limitations.
Avoid unnecessary costs. Understanding requirements early reduces the likelihood of building features that users do not need.
Improve user adoption. Consulting stakeholders helps ensure that the new system supports their actual responsibilities.
Reduce implementation risks. Early analysis can reveal data migration challenges, security requirements, and integration issues.
Establish measurable goals. The university can compare performance before and after implementation.
For example, it could measure average registration completion time, the number of mark-entry errors, and the time required to issue approved transcripts.
These measurements help determine whether the new system is delivering meaningful improvements.
5. Connecting Systems Analysis and Design to the Software Development Life Cycle
Systems analysis and design are also closely connected to the Software Development Life Cycle (SDLC).
A simplified development process could look like this:
- Planning: Define the problem, objectives, scope, and available resources.
- Analysis: Investigate current processes and gather user requirements.
- Design: Plan the database, architecture, interfaces, security, and workflows.
- Implementation: Develop the application and integrate its components.
- Testing: Verify functionality, accuracy, security, and performance.
- Deployment: Introduce the system to the university and train users.
- Maintenance: Fix defects, monitor performance, and improve the system over time.
These stages help organize development, although real projects may revisit earlier stages when new requirements or problems emerge.
Conclusion
Moving a university from manual administration to a computer-based information system involves more than digitizing paper records.
The real goal is to understand existing challenges, identify what stakeholders need, and design a solution that improves how the institution operates.
Systems analysis helps us understand the problem. Systems design provides a blueprint for solving it. Software development then turns that blueprint into a working solution.
As developers, we should remember that writing code is only one part of solving a business problem. The quality of the final solution depends heavily on how well we understand the people, processes, and requirements behind it.
A question for fellow developers: Have you ever worked on a project where the technical solution was straightforward, but understanding the business process was the real challenge? What did you learn from that experience?
Top comments (0)