Welcome to Evaluating a System!
Hello and welcome! In the Systems Development Life Cycle (SDLC), after you design, build, and test a software solution or digital system, there is one final and crucial step: System Evaluation.
Don't worry if this sounds formal — think of evaluation like baking a birthday cake. Before you serve it to your guests, you check: Did it rise properly? Does it taste good? Does it look the way the birthday person wanted? And what could you do better next time?
In this chapter, you will learn how developers evaluate their finished digital systems against user requirements, collect real feedback, and plan for future improvements.
1. What is System Evaluation?
System Evaluation is the process of critically reviewing a completed digital system to judge how well it works and whether it solves the original problem it was created for.
Evaluation happens at the very end of the development process, but it looks all the way back to the start. The main question to answer is: Is the system fit for purpose?
Fit for Purpose means the system does exactly what the user needed it to do, reliably and effectively.
Did you know? Even massive tech companies like Apple, Microsoft, and Sony spend millions of pounds evaluating their software after it is built. Every software update or patch you download on your phone is the result of continuous evaluation!
Key Takeaway:
Evaluation is not just testing for bugs; it is judging whether the finished product actually satisfies the user's needs and original goals.
2. The Core Criteria for Evaluation
When evaluating any digital system, we break our review down into specific areas. Here are the four key areas you must consider:
A. Meeting User Requirements (Fitness for Purpose)
At the start of any project, a list of user requirements (or objectives) is agreed upon. When evaluating, you must go through these requirements one by one.
• Did the system meet every requirement? (e.g., If the user wanted an automatic email receipt sent upon purchase, does it actually do this?)
• How well were they met? (Are all features fully working, or only partially working?)
B. User Interface (UI) and Usability
A system can have powerful code, but if people cannot figure out how to use it, it will fail!
• Ease of Navigation: Are buttons, menus, and links clearly labelled and placed logically?
• Visual Presentation: Are the font sizes, colour schemes, and layouts clear and accessible?
• Consistency: Do all screens and pages look like they belong to the same program?
C. Performance and Robustness
Performance looks at how smoothly the system runs under normal and heavy use.
• Speed / Response Time: Does the system load screens and process data quickly?
• Robustness & Error Handling: If a user enters invalid data (like typing letters into a phone number box), does the system crash, or does it display a helpful error message?
D. Maintainability and Scalability
• Maintainability: Is the code neat, well-commented, and organised so another programmer can fix issues later?
• Scalability: Can the system handle more users or more data in the future without breaking down?
Quick Memory Trick: The "F.U.P.S." Rule
To remember the key areas of an evaluation, remember F.U.P.S.:
• F – Fitness for purpose (Does it meet user requirements?)
• U – Usability & User Interface (Is it easy and pleasant to use?)
• P – Performance (Is it fast, reliable, and error-free?)
• S – Scalability & Maintenance (Can it grow and be updated?)
Key Takeaway:
Evaluating a system involves judging requirement fulfilment, interface usability, system speed/reliability, and future maintenance needs.
3. Gathering Feedback: How Do We Evaluate?
You cannot evaluate a system properly just by sitting alone in a room and guessing! You must gather real data from end users (the actual people who will use the system every day).
Common Methods for Gathering Feedback:
1. User Questionnaires and Surveys:
Distributing short surveys to a group of target users asking specific questions (e.g., "On a scale of 1 to 5, how easy was it to book an appointment?"). This provides quantitative data that is easy to graph and analyse.
2. User Interviews:
Talking directly with users face-to-face or online to gather detailed, qualitative feedback about their thoughts, frustrations, and suggestions.
3. Direct Observation:
Watching an end user interact with the software in real-time. This helps you spot where users get confused or click the wrong buttons without them having to explain it.
4. User Acceptance Testing (UAT):
Giving users a set of everyday tasks to complete using the system to see if the software handles their daily work routine smoothly.
Common Mistake to Avoid:
Mistake: Thinking that the developer's opinion is the most important.
Correction: The end user's opinion is what matters most! Developers already know how the system works, so they cannot judge usability objectively.
Key Takeaway:
Always collect feedback from actual end users using methods like surveys, interviews, observation, and acceptance testing.
4. Identifying Limitations and Future Improvements
No piece of software is ever 100% complete or totally perfect on version 1.0! A great evaluation honestly identifies weak spots and suggests realistic improvements.
Identifying Limitations:
A limitation is something the system cannot currently do, a feature that doesn't work as smoothly as intended, or a restriction in the system's design.
• Example Limitation: The system only allows users to pay via credit card, leaving out customers who want to pay using PayPal or digital wallets.
Suggesting Future Improvements:
For every limitation you find, you should suggest a practical solution or upgrade for a future version (e.g., Version 2.0).
• Example Improvement: "In the next update, add an API integration for PayPal and Apple Pay to give users more payment flexibility."
• Example Improvement: "Upgrade database indexing to improve search speeds when the product catalogue exceeds 10,000 items."
Quick Review: Limitations vs. Improvements
• Limitation: What the system lacks or struggles with right now.
• Improvement: How developers can fix or enhance it in the future.
Key Takeaway:
Being critical of your work is a strength in digital technology. Spotting limitations and planning future upgrades shows high-level evaluative skill.
5. Evaluating Your Own Performance (Self-Evaluation)
In GCSE Digital Technology project work, you are often asked to evaluate your own role and development practice as well as the software itself.
Questions to Ask Yourself:
• Time Management: Did I stick to my project schedule, or did I leave coding and testing to the last minute?
• Technical Skills: Which programming or software skills did I improve during the project?
• Problem-Solving: When I encountered unexpected errors or bugs, how effectively did I research and fix them?
• Resource Management: Did I use available help guides, documentation, and design plans effectively?
Key Takeaway:
Evaluating yourself helps you identify your personal strengths and areas where your digital and project management skills can grow.
Chapter Summary & Exam Checklist
Before moving on, make sure you can answer these key review points:
• Can I explain what fitness for purpose means?
• Can I describe at least three areas used to evaluate a system (e.g., user requirements, usability, performance)?
• Can I list methods for gathering user feedback (surveys, interviews, observations)?
• Can I explain the difference between a system limitation and a future enhancement?
• Can I reflect on personal project performance, including time management and problem-solving?