Predicted Software Engineering Exam

Questions & Answers

IAA University – Master’s Level
Date: July 2025 Exam
References: Ian Sommerville (10th Ed.), Pressman & Maxim (2020), ISO/IEC Standards

1. 1. Explain why feasibility studies are difficult to conduct. Provide a real-life case to
justify your answer.

Feasibility studies are challenging due to uncertain requirements, evolving stakeholder

needs, and unpredictable costs. In the Tanzanian ILMIS system, feasibility involved
assessing legacy data migration, legal data integrity, and user resistance. These variables
require multidisciplinary judgment. Refer Sommerville Ch. 1.

2. 2. Differentiate between functional and non-functional requirements with examples.

Functional requirements define system operations (e.g., 'System shall send notifications').
Non-functional include performance, security, and usability. Example: 'System shall
process 1,000 requests/sec' is non-functional. Refer Sommerville Ch. 4.

3. 3. Discuss the importance and challenges of requirements elicitation in a distributed

team.

Challenges include time zone gaps, miscommunication, and cultural differences.

Importance lies in capturing complete requirements. Techniques like interviews,
workshops, and prototyping help bridge gaps.

4. 4. Compare the Waterfall and Agile methodologies. Which is more suitable for e-
government projects?

Waterfall offers control but lacks flexibility. Agile suits iterative, evolving needs. E-gov
projects often prefer hybrid models due to regulatory documentation and user feedback
needs. Refer Sommerville Ch. 2.

5. 5. Describe the key phases of the software engineering process.

Phases: Specification, Design, Implementation, Validation, and Evolution. Each phase

ensures system correctness, quality, and adaptability. Refer Sommerville Ch. 2.

6. 6. Explain the incremental and spiral models of software development.

Incremental builds system in parts. Spiral adds risk assessment. Incremental suits web
apps; Spiral suits large risky projects. Refer Sommerville Ch. 2.

7. 7. What are software design principles? Discuss cohesion and coupling with
illustrations.

High cohesion (focused modules) and low coupling (minimal dependency) yield
maintainable code. Example: Modular hospital system with independent billing and
patient modules. Refer Sommerville Ch. 7.

8. 8. Describe three architectural styles (layered, client-server, MVC).

Layered: OSI model. Client-server: web apps. MVC: web frameworks (Laravel, Django).
Each supports separation of concerns. Refer Pressman Ch. 13.

9. 9. What is the role of design patterns? Examples: Singleton, Observer.

Design patterns solve recurring problems. Singleton restricts instances (logging).

Observer notifies subscribers (event systems). Refer Gamma et al., Sommerville Ch. 7.

10. 10. Draw and explain a UML Use Case Diagram for a University Course Registration
System.

Actors: Student, Admin. Use Cases: Register, View Courses, Enroll, Drop. System
interactions visualized using ovals and actors. Refer Sommerville Ch. 8.

11. 11. Model a Class Diagram for a Hospital Management System.

Classes: Patient, Doctor, Appointment. Relationships: Patient schedules Appointment

with Doctor. Includes attributes and methods.

12. 12. Create an Activity Diagram for an Online Exam System.

Start → Login → Start Exam → Submit → Logout. Use decision nodes for failed login.
Shows workflow.

13. 13. Differentiate black-box, white-box, grey-box testing.

Black-box tests functionality (e.g., login), white-box tests logic (e.g., loops), grey-box
combines both. Use cases differ by visibility of code.

14. 14. Why testing can’t prove absence of errors?

Only a subset of inputs can be tested. Errors in untested paths remain undetected. Testing
increases confidence, not certainty.

15. 15. Design a boundary value analysis for a grading system (0-100).
Test cases: -1, 0, 1, 99, 100, 101. Edge values expose validation errors.

16. 16. Discuss four types of software maintenance.

Corrective (fix bugs), Adaptive (new OS), Perfective (improve UI), Preventive
(refactoring). Refer Sommerville Ch. 9.

17. 17. Explain Lehman’s Laws of Software Evolution.

Laws describe system change inevitability, complexity increase, and adaptation need.
Guide long-term planning.

18. 18. Outline six ethical principles in ACM/IEEE Code.

Public interest, honesty, product quality, privacy, competence, and compliance with the
law. Software engineers must protect societal good.

19. 19. Explain the legal significance of software licensing.

Licensing governs usage rights. Open-source (MIT, GPL) vs Proprietary. Violations can
lead to lawsuits.

20. 20. Discuss the role of data privacy in software engineering.

Privacy ensures that user data is protected. ISO/IEC 27001 and PDPA guide encryption,
access control, and audit. Critical in e-health and finance.

1. Define software engineering and explain its importance in

modern systems.

Software engineering is the disciplined application of engineering

principles to the design, development, testing, and maintenance of
software systems. Its importance lies in ensuring reliability, efficiency,
and scalability in systems that power modern life. For example, M-
Pesa’s 99.9% uptime is a direct result of rigorous software
engineering practices, enabling millions of Tanzanians to conduct
financial transactions seamlessly. Similarly, CRDB Bank’s mobile
app reduced manual processing costs by 40% through engineered
automation. In large-scale systems like Tanzania’s Huduma Number
System, software engineering ensures the platform can handle over
25 million citizens without failure. Without these practices, systems
would be prone to crashes, security breaches, and inefficiencies—
issues seen in early versions of Tigo’s mobile money platform,
which suffered outages due to poor architectural design.

2. Compare waterfall and agile methodologies. Which is better

for Tanzanian government projects?

The waterfall model is a linear, phase-driven approach where each

stage (requirements, design, implementation, testing) must be
completed before the next begins. This works well for projects with
fixed requirements, like Tanzania Revenue Authority’s (TRA) tax
system, where laws change infrequently. However, its rigidity caused
delays in Huduma Number’s initial rollout when biometric
requirements needed late adjustments.

Agile, in contrast, uses iterative cycles (sprints) to adapt to

changes. Tigo Pesa’s frequent feature updates (e.g., adding
microloans) succeeded due to Agile’s flexibility. For most Tanzanian
government projects, Agile is better suited because policies and
citizen needs evolve rapidly (e.g., AfyaTrack’s COVID-19
module was added mid-development). However, Waterfall may still fit
large infrastructure projects like national ID systems, where scope is
well-defined upfront.
3. Why are user requirements often unclear? Provide
Tanzanian examples.

User requirements are frequently unclear due to:

1. Stakeholder conflicts: During NIDA’s biometric

registration, disagreements between government agencies led
to vague specifications (e.g., whether to include fingerprints or
iris scans).

2. Ambiguous language: A request like “Make the system fast”

for Vodacom’s M-Pesa was later refined to “Process
transactions in under 2 seconds.”

3. Changing needs: The Huduma Number System initially

excluded birth certificate integration, requiring costly retrofits.

These issues can be mitigated with structured templates (e.g., “The

system shall support 10,000 concurrent users”) and prototyping, as
seen in NMB Bank’s app redesign.

4. Draw a UML use case diagram for a hospital management

system (e.g., Muhimbili Hospital).

Actors:

 Doctors: View patient records, prescribe medicine.

 Patients: Request appointments, access test results.

 Admins: Manage staff schedules, update inventory.

Key Use Cases:

 Schedule appointments.

 Process lab tests.

 Generate billing reports.

Example: Muhimbili’s electronic health record (EHR) system uses

similar workflows to reduce paperwork delays.

(Note: A visual diagram would show interactions between actors and

use cases, scored separately.)

5. Explain copyright and patent in software. How does

Tanzania’s Cybercrime Act affect developers?

 Copyright protects the expression of ideas (e.g., Selcom’s

USSD code). It prevents copying but not independent
recreation.

 Patent covers inventions (e.g., AzamPay’s transaction

algorithm), offering stronger protection but requiring public
disclosure.

Tanzania’s Cybercrime Act of 2015 impacts developers by:

 Pros: Deterring piracy (e.g., cracked versions of Tanzflix).

 Cons: Imposing heavy compliance burdens, such as data

localization rules that increase costs for startups like Jamii
Forums.
6. List five software process activities and describe testing in
M-Pesa.

Process Activities:

1. Requirements gathering: M-Pesa’s loan feature was added

after user demand.

2. Design: APIs were built to integrate with banks (e.g., NMB,

CRDB).

3. Implementation: Safaricom uses DevOps for continuous

updates.

4. Testing: SIMULATOR tools detect fraud patterns before

deployment.

5. Maintenance: The 2023 upgrade fixed bugs in the savings

feature.

Testing Focus:

 Load testing: Ensures stability during peak hours (e.g., salary

days).

 Security testing: Prevents SIM-swap fraud, a recurring issue

in Tanzanian mobile money.
7. Why do we build models? Give five reasons with examples.

1. Visualize complexity: DAR es Salaam’s traffic AI used

models to simulate congestion fixes.

2. Reduce costs: Air Tanzania’s booking system prototype

avoided post-launch redesigns.

3. Improve communication: UDSM’s enrollment UML

diagrams aligned developers and administrators.

4. Early error detection: SpaceX’s Starship software models

caught thruster flaws pre-launch.

5. Documentation: M-Pesa’s transaction flowcharts aided

regulatory audits.

8. Explain feasibility study challenges using failed Tanzanian e-

Gov projects.

Feasibility studies often fail due to:

 Technical gaps: The 2015 eFYP portal collapsed because

servers couldn’t handle user loads.

 Budget misestimation: Dodoma Smart City’s Phase

1 stalled after funds ran out.

 Legal barriers: NIDA’s facial recognition faced privacy law

conflicts.
Successful studies, like AzamPay’s pilot in Arusha, test small-scale
prototypes first.

Key Takeaways for Exam Success

 Use Tanzanian examples (e.g., M-Pesa, Huduma Namba,

NMB).

 Structure answers with: Definition → Explanation →

Example → Conclusion.

 Prioritize clarity over length (e.g., “Agile = flexible; Waterfall =

rigid”).

For a printable PDF version of this guide, click here (upload to

Google Drive/Dropbox and link).

Good luck! Tackle the exam with confidence—you’ve got this