Example test question from

gemini
Created @May 5, 2025 3:01 PM

Course COS 301

AI keywords

Practice Test Set 1

Scenario: SuperLap Racing Line Optimization System (Uses RL and Computer
Vision to find the fastest racing line on a track image, processes images, runs
simulations, visualizes results).

Instructions: Answer all questions. Allocate your time according to the

points/suggested times.

Question 1 (Requirements & Architecture - 25 points, ~30 mins)

a. List five (5) specific functional requirements (FR) for the SuperLap system
based on its core purpose (e.g., R1: Process Track Image, R2...). (5 points)
b. For the functional requirements listed in (a), identify five (5) corresponding
quality requirements (QR) that are critical for the system's success (e.g., QR1:
Accuracy of Line, QR2: Performance of Optimization...). Ensure each QR clearly
relates to one or more FRs. (5 points)
c. Choose
two of the quality requirements identified in (b). For each, describe specific
architectural tactics or strategies (e.g., using specific algorithms, redundancy,
caching, specific design patterns) that could be employed to achieve that quality
attribute within the SuperLap system's context. Explain how the tactic helps
achieve the quality. (10 points)
d. Why is it important to define and consider quality requirements early in the
design process, alongside functional requirements? Briefly explain using the
SuperLap system as an example. (5 points)
Question 2 (Use Case Specification - 15 points, ~15 mins)

Example test question from gemini 1

 Consider the SuperLap system's function where the AI must be trained using
reinforcement learning, potentially using simulated data or data extracted from
racing games.
Write a detailed Use Case specification for "Train AI Model". Include:

Use Case Name

Actor(s) (Primary and Secondary, if any)

Preconditions (What must be true before training can start?)

Main Flow (Steps involved in initiating and monitoring training)

Postconditions (What is the result of successful training?)

Key Exception/Alternative Flow (e.g., Training fails due to invalid data)

Question 3 (Architectural Concepts - 10 points, ~10 mins)

a. The SuperLap system involves processing data through distinct stages (Image
Input -> Image Processing -> AI Simulation -> Line Calculation -> Visualization
Output). Which architectural pattern (e.g., Pipe and Filter, Layered, Microservices)
might be particularly suitable for managing this workflow? Justify your choice
briefly. (5 points)
b. Explain the concept of
architectural views (e.g., Module View, Component-and-Connector View,
Allocation View). Which view would be most useful for understanding the runtime
interactions and potential performance bottlenecks in the SuperLap system? Why?
(5 points)
Question 4 (Version Control - 10 points, ~10 mins)
a. Explain the difference between git commit , git push , and git pull . (6 points)
b. Why are meaningful commit messages important in a team project like
SuperLap? (4 points)
Question 5 (Software Engineering Fundamentals - 10 points, ~10 mins)

a. What are the main objectives of Software Engineering (e.g., the PQCT goals
mentioned in Kung)? (4 points)
b. Briefly describe the difference between a Software Process and a Software
Methodology, using an example pair (e.g., Agile Process and Scrum
Methodology). (6 points)

Example test question from gemini 2

 (Total: 70 points, ~75 mins)

Practice Test Set 2

Scenario: A University Course Registration System (Allows students to browse
courses, register, view schedules, and pay fees. Allows administrators to manage
course offerings and student records).
Instructions: Answer all questions. Allocate your time according to the
points/suggested times.
Question 1 (Requirements - 20 points, ~25 mins)

a. Write three (3) user stories for a Student using the Course Registration System.
(Format: "As a [type of user], I want [an action] so that [a benefit/goal]"). (6
points)
b. Identify five (5) non-functional requirements (NFRs) crucial for this system,
considering potentially thousands of students accessing it simultaneously,
especially during peak registration periods. Categorize each NFR (e.g.,
Performance, Security, Usability, Availability, Scalability). (10 points)
c. Explain how the NFR of
Scalability impacts the architectural choices for the Course Registration System.
(4 points)
Question 2 (Domain Modeling - 15 points, ~15 mins)
Consider the core entities in the Course Registration System: Student, Course,
Instructor, Registration (linking a student to a course for a semester), Semester.
a. Draw a simple UML Class Diagram showing these five classes. Include at least
one relevant attribute for Student and Course. (5 points)
b. Show the
associations between these classes (e.g., Student registers for Course, Instructor
teaches Course, Registration occurs in Semester). (5 points)
c. Add
multiplicity notations to the associations drawn in (b). For example, how many
Courses can a Student register for? How many Students can be registered for one
Course? (5 points)
Question 3 (Agile Concepts - 15 points, ~15 mins)

Example test question from gemini 3

 Imagine the Course Registration System is being developed using the Scrum
framework.
a. Identify the three main Scrum roles and briefly describe the responsibility of
each. (6 points)
b. What is the purpose of the
Daily Scrum (Stand-up) meeting? What three questions are typically answered by
team members? (5 points)
c. What is a
Sprint Retrospective and why is it important in an Agile process? (4 points)
Question 4 (Use Case Diagram Interpretation - 10 points, ~10 mins)
(Imagine a simple Use Case diagram is provided here showing Actors: Student,
Administrator and Use Cases: Browse Courses, Register for Course, Manage
Course Catalog, Manage Student Records. Associations link actors to the use
cases they perform.)
a. Based on the diagram (described above), which actor(s) can perform the
"Register for Course" use case? (2 points)
b. Which use case(s) can the "Administrator" perform? (3 points)
c. Is "Login" typically shown as a primary use case on a high-level diagram like
this, or handled differently (e.g., as a precondition or included use case)? Briefly
explain why. (5 points)

Question 5 (Architecture & Design Principles - 10 points, ~10 mins)

a. Explain the architectural principle of Separation of Concerns. (4 points)
b. How could the
Model-View-Controller (MVC) pattern help achieve separation of concerns in the
Course Registration System's user interface? (6 points)
(Total: 70 points, ~75 mins)

Practice Test Set 3

Scenario: An Online Food Delivery Service (Connects customers with local
restaurants, allows Browse menus, placing orders, making payments, and tracking
delivery. Restaurants manage their menus and orders. Delivery drivers manage
assigned deliveries).

Example test question from gemini 4

 Instructions: Answer all questions. Allocate your time according to the
points/suggested times.
Question 1 (Requirements Specification - 20 points, ~25 mins)
a. List three (3) functional requirements for the Restaurant user of the Food
Delivery Service. (6 points)
b. List three (3) functional requirements for the
Delivery Driver user. (6 points)
c. A key quality requirement is
Reliability (e.g., orders placed must reach the restaurant accurately, payment
processing must be dependable). Describe how this QR relates to the functional
requirements and what architectural considerations (e.g., error handling,
transaction management, monitoring) might be needed. (8 points)
Question 2 (Architectural Structures & Views - 15 points, ~15 mins)
a. Explain the difference between Module structures and Component-and-
Connector (C&C) structures in software architecture. What does each type
primarily help you reason about? (8 points)
b. For the Food Delivery Service, which involves customers (mobile app),
restaurants (web portal), drivers (mobile app), and a central backend, which
architectural structure type (Module, C&C, or Allocation) would best describe
the
physical deployment of the system components onto servers and devices? Briefly
explain why. (7 points)
Question 3 (Quality Attributes & Scenarios - 15 points, ~15 mins)
Quality Attribute Scenarios help make NFRs specific and testable. Consider the
Performance of the Food Delivery Service app for a Customer.
Write a concrete Quality Attribute Scenario for searching for nearby restaurants.
Use the six parts:

1. Source of Stimulus:

2. Stimulus:

3. Artifact:

4. Environment:

Example test question from gemini 5

 5. Response:

6. Response Measure:

Question 4 (Fill-in-the-Blank: Domain Model - 10 points, ~10 mins)

Consider the following relationships in the Food Delivery Service domain model:

A Customer << A >> Order . (Association name)

An Order contains multiple OrderItem . This is a << B >> relationship, where

Order is the whole.

A Restaurant << C >> MenuItem . (Association name)

Multiplicity: One Order is placed by << D >> Customer (s).

Multiplicity: One Customer can place << E >> Order (s).

Multiplicity: An Order must belong to << F >> Restaurant (s).

Multiplicity: A Restaurant can have << G >> Order (s).

Multiplicity: An Order must have << H >> OrderItem (s).

An OrderItem corresponds to << I >> MenuItem (s).

The Payment details might be modeled as an << J >> class linked to the
Order association.

Fill in the blanks << A >> through << J >> with appropriate terms
(association names, relationship types, multiplicities like 1, 0.., 1.., or entity types).
Question 5 (Version Control - 10 points, ~10 mins)
a. What is the purpose of the staging area (or index) in Git? Which command is
used to add changes to the staging area? (5 points)
b. What does the
git status command tell you? (5 points)
(Total: 70 points, ~75 mins)

Practice Test Set 4

Scenario: An IoT-based Smart Home System (Allows users via a mobile app to
remotely monitor and control lights, thermostats, and security cameras in their

Example test question from gemini 6

 home. The system involves sensors, actuators, a central hub/gateway, cloud
services, and the mobile app).
Instructions: Answer all questions. Allocate your time according to the
points/suggested times.
Question 1 (Requirements & Architecture Importance - 20 points, ~25 mins)
a. List three (3) functional requirements for the Smart Home System from the
perspective of the User interacting with the mobile app. (6 points)
b. Identify three (3) critical
quality requirements for this system, considering its nature (controlling physical
devices, handling personal data, needing responsiveness). Examples: Security,
Reliability, Performance, Energy Efficiency. (6 points)
c. Explain why
Software Architecture is particularly important for a system like this IoT Smart
Home application. Mention at least three reasons based on the "Why Is Software
Architecture Important?" chapter/notes, relating them to the Smart Home context.
(8 points)
Question 2 (Design Principles - 15 points, ~15 mins)

a. Explain the design principle of High Cohesion. Give an example of how you
might achieve high cohesion when designing the software module responsible for
controlling the smart lights in the Smart Home System. (7 points)
b. Explain the design principle of
Low Coupling. Why is low coupling desirable between the mobile app, the cloud
service, and the home hub in the Smart Home System? (8 points)
Question 3 (Process Models - 10 points, ~10 mins)

Would an Agile process model (like Scrum or Kanban) or a Waterfall process

model be more suitable for developing the initial version of the Smart Home
System? Justify your choice by considering factors like requirements stability,
technology uncertainty, and the need for user feedback.
Question 4 (Use Case Diagram Validity - 10 points, ~10 mins)

(Imagine a Use Case Diagram is provided showing:Actors: User, Cloud Service,

Smart Light Bulb.Use Cases: Control Light, Update Device Status.Associations:
User -> Control Light, Smart Light Bulb -> Update Device Status, Cloud Service ->
Update Device Status, Control Light -> Cloud Service.)

Example test question from gemini 7

 Based on the typical rules for Use Case diagrams:

a. Is it valid for "Smart Light Bulb" (a device) to be shown as an Actor initiating the
"Update Device Status" use case? Briefly explain why or why not. (5 points)
b. Is it valid to show an association directly
between two use cases like "Control Light -> Cloud Service"? What mechanism
(e.g., <<include>>, <<extend>>, or actor interaction) is typically used to
show relationships between use cases or their reliance on other services? (5
points)

Question 5 (Version Control Collaboration - 15 points, ~15 mins)

a. What is a Pull Request (PR) or Merge Request (MR) in systems like GitHub or
GitLab? (5 points)
b. Describe two advantages of using a PR workflow for team collaboration on the
Smart Home System project. (6 points)
c. What is the difference between
git fetch and git pull ? (4 points)

(Total: 70 points, ~75 mins)

Disclaimer: These practice tests are based on the materials you provided and aim
to reflect the style and topics covered. They are for practice purposes only and
may not perfectly match the format, content, or difficulty of any actual
examination. Good luck with your preparation!

Practice Test Set 5

Scenario: A Digital Library Management System for a university. It manages both

physical books and e-books. Users (Students, Faculty, Librarians) should be able
to search the catalog, borrow/download items, return physical items, and manage
their accounts. Librarians also manage inventory (adding/removing books/e-
books) and user accounts.

Instructions: Answer all questions. Allocate your time according to the

points/suggested times.

Question 1 (Requirements Engineering - 15 points, ~15 mins)

a. Requirements engineering is often described as an iterative process, especially
when following Agile principles. Give at least four (4) distinct reasons why iteration

Example test question from gemini 8

 is necessary or beneficial during requirements elicitation for a system like the
Digital Library. (8 points)
b. Distinguish between a
requirement and a constraint in the context of software requirements
specification. Provide one example of each for the Digital Library system. (7
points)
Question 2 (UML Use Case Diagram - 15 points, ~15 mins)

Draw a Use Case Diagram for the Digital Library Management System. Include the
following:

Actors: Student/Faculty (as one 'Member' actor is fine), Librarian.

Core Use Cases: Search Catalog, Borrow Item, Return Item (assume applies
mainly to physical), Manage Inventory, Manage Member Account.

Show the relationships between actors and the use cases they perform.

(Optional: Consider if "Login" should be separate or related via

<<include>>).

Question 3 (UML Domain Modeling / Class Diagram - 20 points, ~25 mins)

Develop a Domain Model Class Diagram fragment for the Digital Library's catalog
items. Include classes for:

LibraryItem (a general concept) with attributes like title , callNumber .

PhysicalBook (inherits from LibraryItem ) with an attribute like location .

EBook (inherits from LibraryItem ) with attributes like fileFormat , downloadURL .

Author with name .

Show the inheritance relationship between LibraryItem , PhysicalBook , and EBook .

Show the association between LibraryItem and Author (a LibraryItem can have
one or more Authors, an Author can write one or more LibraryItems). Include
multiplicity.

Show an aggregation or composition relationship if appropriate (e.g., maybe a

LibraryCatalog class that 'contains' LibraryItem s).

Question 4 (Architectural Styles & Patterns - 10 points, ~10 mins)

Example test question from gemini 9

 a. Considering that users (students, faculty) will access the Digital Library via web
browsers or potentially a mobile app, and librarians might use a desktop
application, what basic architectural style (e.g., Client-Server, N-Tier) would likely
form the foundation of the system? Briefly justify. (5 points)
b. Within the server-side, the system needs to handle catalog data, user data,
loan data, and potentially interact with external e-book provider APIs. Would a
Layered Architecture be beneficial inside the server? Explain how it would help
organize these different concerns. (5 points)
Question 5 (Version Control Strategies - 10 points, ~10 mins)

Compare and contrast two different branching strategies discussed in the

materials (e.g., Gitflow vs. GitHub Flow, or Gitflow vs. Trunk-Based Development).
Highlight one key advantage and one potential disadvantage of each strategy,
especially for a student team working on a project like the Digital Library.

(Total: 70 points, ~75 mins)

Practice Test Set 6

Scenario: Online Food Delivery Service (Revisited - connects customers,

restaurants, drivers via mobile/web apps; handles Browse, ordering, payment,
tracking, menu/order management). Assume the system has been running for a
while and is undergoing maintenance and feature additions.

Instructions: Answer all questions. Allocate your time according to the

points/suggested times.

Question 1 (Quality Attributes & Tactics - 20 points, ~25 mins)

Referencing the architectural tactics diagrams/lists from the Software Architecture
notes:

a. List three specific tactics aimed at achieving Availability (under Detect Faults,
Recover from Faults, or Prevent Faults). Briefly explain how one of these tactics
could be applied in the Food Delivery system (e.g., detecting if a restaurant's
ordering system is offline). (10 points)
b. List three specific
tactics aimed at achieving Security (under Resist Attacks, Detect Attacks, or
Recover from Attacks). Briefly explain how one of these tactics could be applied to
protect customer payment information in the Food Delivery system. (10 points)

Example test question from gemini 10

 Question 2 (Architecture Maintenance & Evolution - 15 points, ~15 mins)

a. Explain the concept of Architecture Debt (Technical Debt specifically related to

architecture). (5 points)
b. Describe a scenario where architecture debt might arise in the evolving Food
Delivery Service (e.g., quick fixes implemented over time without considering the
overall structure). What are the potential consequences of accumulating such
debt? (10 points)

Question 3 (Architectural Patterns - 15 points, ~15 mins)

The Food Delivery Service could be implemented using a Microservices
Architecture, where components like Order Management, Restaurant
Management, Driver Tracking, and Payment Processing are separate services.
a. What are two potential advantages of using Microservices for this system
compared to a Monolithic architecture? (6 points)
b. What are two potential
challenges or disadvantages of using Microservices here? (6 points)
c. How does the concept of
low coupling relate to the Microservices pattern? (3 points)

Question 4 (Testing & Process - 10 points, ~10 mins)

a. Explain the difference between Unit Testing and Integration Testing. (5 points)
b. Within an Agile sprint for the Food Delivery Service project, when and how
would unit tests and integration tests typically be performed? Who is primarily
responsible for writing/running each type? (5 points)
Question 5 (Team Dynamics & Project Success - 10 points, ~10 mins)

Based on the discussions of team factors in the provided test examples (e.g.,
COS301 Semester Test 1 2021, Q4):

List and briefly explain five (5) factors related to team dynamics, communication,
or structure that can contribute positively to the success (or negatively impact, if
absent) of a software engineering team project like the Food Delivery Service.
(Total: 70 points, ~75 mins)

Example test question from gemini 11

 MEMO

Memo: Practice Test Set 1

Scenario: SuperLap Racing Line Optimization System

Question 1 (Requirements & Architecture - 25 points)

(a) Functional Requirements (FRs) (5 points - 1 point each, examples):

R1: The system shall accept a top-down track image as input.

R2: The system shall convert the input track image into a binary format
suitable for processing.

R3: The system shall utilize a Reinforcement Learning (RL) algorithm to

iteratively simulate paths on the track representation.

R4: The system shall determine and output the optimal (fastest) racing line
based on simulation results.

R5: The system shall generate a visual overlay of the optimal racing line on
the original or processed track image.

(b) Quality Requirements (QRs) (5 points - 1 point each, examples linked to

FRs):

QR1: Accuracy: The determined racing line (R4) must be demonstrably

close to a theoretically optimal or known fast line for the given track
physics/constraints. (Supports R4)

QR2: Performance (Optimization Speed): The RL simulation and

optimization process (R3, R4) must complete within a reasonable
timeframe (e.g., minutes/hours depending on complexity) on target
hardware. (Supports R3, R4)

QR3: Usability (Input/Output): The system must provide clear interfaces

for uploading images (R1) and viewing the visualized results (R5).
(Supports R1, R5)

QR4: Reliability (Processing): The image conversion (R2) and RL

simulation (R3) processes must complete without crashing or producing
invalid intermediate data. (Supports R2, R3)

Example test question from gemini 12

 QR5: Modifiability: The RL algorithm or physics simulation parameters
should be adjustable or replaceable to experiment with different models or
conditions. (Supports R3, R4)

(c) Architectural Tactics/Strategies (10 points - 5 points per QR pair):

For QR1 (Accuracy):

Tactic: Increase Simulation Fidelity / Refine Model. Use more accurate

physics models in the simulation (R3). Use higher-resolution track
representations (R2). Employ more sophisticated RL algorithms known
for convergence on optimal solutions.

How it helps: More realistic simulations and better algorithms are more
likely to yield a racing line that translates to real-world speed, thus
improving accuracy.

For QR2 (Performance/Optimization Speed):

Tactic: Increase Computational Resources / Parallel Processing.

Distribute simulation iterations (R3) across multiple CPU cores or even
GPUs if the RL algorithm allows. Optimize algorithms for speed.

How it helps: Parallel execution reduces the wall-clock time needed to

run the large number of simulations required for RL training and
optimization. Algorithmic optimization reduces computation per step.

(Alternative for QR5 Modifiability: Tactic: Encapsulation/Interfaces. Define

clear interfaces between the image processing module, the physics
simulation module, and the RL module, allowing them to be swapped out.)

(d) Importance of Early QRs (5 points):

QRs heavily influence architectural design. Defining them early ensures

the chosen architecture can actually support the how well aspects, not just
the what.

For SuperLap, ignoring performance (QR2) might lead to an architecture

that cannot be parallelized, making optimization impractically slow.
Ignoring accuracy (QR1) might lead to choosing simpler but less effective
algorithms/models. Ignoring modifiability (QR5) might make it impossible
to later adapt the system to different RL techniques or physics engines.

Example test question from gemini 13

 Early consideration allows architects to select appropriate patterns,
tactics, and technologies from the start, avoiding costly rework.

Question 2 (Use Case Specification - 15 points)

Use Case Name: Train AI Model

Actor(s): Primary: System Developer/Administrator (or potentially an advanced

User if training is exposed). Secondary: Data Source (e.g., Simulation Engine,
Game Interface, Telemetry Database).

Preconditions:

Valid track data (image processed/representation available) is accessible.

A simulation environment or data source is configured and available.

Training parameters (e.g., learning rate, number of episodes) are defined.

Sufficient computational resources (CPU/GPU, memory) are available.

Main Flow:

1. Developer initiates the training process via a command-line interface or

GUI.

2. System loads the track representation and training parameters.

3. System connects to the Data Source (Simulation Engine/Game/Database).

4. System starts the RL training loop (e.g., runs simulation episodes, collects
rewards, updates AI model policy).

5. System periodically logs training progress (e.g., episode number, average

reward, lap times).

6. System continues training until a defined stopping criterion is met (e.g.,

number of episodes, convergence threshold, time limit).

7. System saves the trained AI model artifact.

8. System reports successful completion of training.

Postconditions:

A trained AI model artifact is saved and available for use in optimization.

Training logs are saved.

Example test question from gemini 14

 Key Exception/Alternative Flow (Training Failure):

4a. If the Data Source becomes unavailable during training:

1. System attempts to reconnect for a defined period/number of retries.

2. If reconnection fails, the system logs the error, saves the current state
of the AI model (if possible), and terminates the training process,
reporting failure.

Question 3 (Architectural Concepts - 10 points)

(a) Suitable Pattern (5 points):

Pipe and Filter: This pattern seems highly suitable. Each processing stage
(Image Input -> Image Processing -> AI Simulation -> Line Calculation ->
Visualization Output) can be a "filter", and the data flows between them
through "pipes".

Justification: It supports the sequential processing nature of the core

workflow, promotes modifiability (easy to replace a filter, e.g., use a
different RL algorithm), and facilitates reuse (image processing filter might
be reusable).

(b) Architectural Views (5 points):

Component-and-Connector (C&C) View: This view focuses on runtime

elements (components like the image processor, simulation engine,
visualizer) and their interactions (connectors like function calls, data
streams, events).

Why most useful: It directly models the runtime behavior, showing how
components communicate and pass data. Analyzing this view helps
identify communication overhead, potential bottlenecks (e.g., a slow
simulation component), and opportunities for parallelism, all of which are
critical for understanding and improving runtime performance. Module
views show static structure, Allocation views show deployment, neither
directly shows runtime interaction dynamics as well as C&C.

Question 4 (Version Control - 10 points)

(a) Git Commands (6 points - 2 points each):

Example test question from gemini 15

 git commit : Records changes from the staging area into the local
repository's history. Creates a snapshot (commit) with a unique ID and
associates it with a commit message.

: Uploads local repository commits (and associated objects) from a

git push

local branch to a remote repository branch (e.g., GitHub, GitLab). Shares

local changes with others.

: Fetches changes from a remote repository branch and immediately

git pull

tries to merge them into the current local branch. It's often equivalent to git
fetch followed by git merge . Updates the local branch with remote changes.

(b) Commit Message Importance (4 points):

Communication: Clearly explain what changed and why, helping

teammates understand the evolution of the code without reading the diffs.

History Tracking/Debugging: Allows efficient searching/Browse of project

history to find when specific changes were made or bugs were introduced
( git log , git blame ).

Automation: Meaningful messages can be used by tools for generating

changelogs or triggering other actions.

Question 5 (Software Engineering Fundamentals - 10 points)

(a) SE Objectives (PQCT) (4 points):

Productivity: Increase the rate at which software is produced (e.g., lines

of code per person-month, function points per person-month).

Quality: Improve the desirable attributes of the software (reliability,

usability, efficiency, maintainability, etc.).

Cost: Reduce the resources (effort, time, money) required to develop and
maintain software.

Time-to-market: Reduce the time it takes to deliver the software product

to the customer/market.

(b) Process vs. Methodology (6 points):

Software Process: Defines WHAT activities/phases are performed and

WHEN during the software lifecycle (e.g., requirements, design,

Example test question from gemini 16

 implementation, testing). It provides a framework or lifecycle model. It's
generally paradigm-independent. (Example: Agile Process - emphasizes
iterative development, adaptation, collaboration).

Software Methodology: Details HOW the activities defined in a process

are actually carried out. It provides specific steps, techniques, notations,
and guidelines. It's often paradigm-dependent (e.g., OO methodology).
(Example: Scrum Methodology - implements the Agile process using
specific roles like Scrum Master/Product Owner, ceremonies like
Sprints/Daily Scrums, and artifacts like Product/Sprint Backlogs).

Memo: Practice Test Set 2

Scenario: University Course Registration System
Question 1 (Requirements - 20 points)

(a) User Stories (6 points - 2 points each, examples):

As a Student, I want to search for courses by department or keyword so

that I can find classes relevant to my major.

As a Student, I want to add a course to my registration cart so that I can

enroll in it if there are open seats and no conflicts.

As a Student, I want to view my weekly class schedule so that I know when

and where my classes are.

(b) Non-Functional Requirements (NFRs) (10 points - 2 points each,

examples):

Performance: Course search results must be displayed within 3 seconds

under peak load (first week of registration).

Availability: The system must be available 99.9% of the time during the
official registration periods.

Scalability: The system must handle up to 5000 concurrent student

sessions during peak registration without performance degradation.

Security: Student personal information and payment details must be

encrypted during transmission and storage. Access to grade information
must be restricted.

Example test question from gemini 17

 Usability: A first-time student user must be able to successfully register
for at least one course without assistance within 15 minutes.

(c) Scalability Impact (4 points):

High scalability requirement necessitates an architecture that can handle

varying, potentially high loads.

Architectural choices influenced: Likely requires a distributed architecture

(multiple web/application servers), load balancing to distribute requests,
efficient database design (indexing, possibly sharding/replication),
stateless application servers (to easily add/remove instances), and
perhaps caching mechanisms for frequently accessed data (like course
catalog). A single-server, monolithic architecture would likely fail.

Question 2 (Domain Modeling - 15 points)

(a) UML Class Diagram - Classes & Attributes (5 points):

Classes: Student (attributes: studentID, name), Course (attributes:

courseCode, title, credits), Instructor (attribute: name), Registration , Semester

(attribute: termCode e.g., Fall2025).

(b) Associations (5 points):

Between Student and Registration (e.g., places/has)

Between Course and Registration (e.g., for/details)

Between Instructor and Course (e.g., teaches)

Between Semester and Registration (e.g., occurs_in)

(Alternative: Registration could be an association class between Student,

Course, Semester)

(c) Multiplicity (5 points):

Student 1 -- 0..* Registration (A student can have zero or many

registrations)

Course 1 -- 0..* Registration (A course can have zero or many

registrations)

Instructor 1 -- 0..* Course (An instructor can teach zero or many courses)

Example test question from gemini 18

 Course 1..* -- 1 Instructor (A course is taught by one instructor -
simplifying assumption)

Semester 1 -- 0..* Registration (A semester can have zero or many

registrations)

(Multiplicities depend slightly on whether Registration is a class or

association class, but general idea is captured)

Question 3 (Agile Concepts - 15 points)

(a) Scrum Roles (6 points - 2 points each):

Product Owner: Represents the customer/stakeholders. Defines and

prioritizes the Product Backlog items (features, requirements). Responsible
for maximizing the value of the product resulting from the work of the
Development Team.

Scrum Master: Facilitates the Scrum process. Removes impediments

blocking the team. Ensures Scrum practices are followed. Acts as a
servant-leader for the team. Not a traditional manager.

Development Team: Cross-functional, self-organizing group of

professionals (developers, testers, designers, etc.) who do the work of
delivering potentially releasable Increments of "Done" product at the end
of each Sprint.

(b) Daily Scrum (5 points):

Purpose: A 15-minute time-boxed event for the Development Team to

synchronize activities and create a plan for the next 24 hours. It's a
planning meeting, not a status meeting for stakeholders outside the team.

Typical Questions:

1. What did I do yesterday that helped the Development Team meet the
Sprint Goal?

2. What will I do today to help the Development Team meet the Sprint
Goal?

3. Do I see any impediment that prevents me or the Development Team

from meeting the Sprint Goal?

Example test question from gemini 19

 (c) Sprint Retrospective (4 points):

An event held at the end of each Sprint where the Scrum Team inspects
itself and creates a plan for improvements to be enacted during the next
Sprint.

Importance: It allows the team to reflect on its process (what went well,
what didn't, what could be improved) and implement changes, fostering
continuous improvement (a core Agile principle).

Question 4 (Use Case Diagram Interpretation - 10 points)

(a) "Register for Course" Actor: Student (Based on typical system function).
(2 points)

(b) Administrator Use Cases: Manage Course Catalog, Manage Student

Records. (3 points)

(c) "Login" Use Case (5 points):

Login is typically not shown as a primary use case on a high-level

functional diagram.

Reason: It's usually considered a supporting function or a constraint, not a

primary goal of the user interacting with the system's core functionality.
It's often handled as:

A precondition for most other use cases ("User must be logged in").

An included use case (using the <<include>> relationship) if multiple

functional use cases require it, to avoid redundancy.

Handled by security frameworks and not explicitly modeled in

functional use cases.

Question 5 (Architecture & Design Principles - 10 points)

(a) Separation of Concerns (4 points):

A design principle that advocates breaking down a system into distinct

parts (modules, layers, components) where each part addresses a
separate concern or responsibility. A concern is a specific aspect of
functionality or a cross-cutting requirement (e.g., data access, business
logic, UI presentation, logging, security).

Example test question from gemini 20

 (b) MVC for Separation of Concerns (6 points):

MVC separates the application into three interconnected components:

Model: Manages the application's data, logic, and rules (the core
concern). In the registration system, this includes student data, course
data, registration logic.

View: Renders the Model data into a user interface (the presentation
concern). This is what the student or admin sees (web pages, forms,
tables).

Controller: Handles user input, interacts with the Model to perform

actions, and selects the View to display (the input/interaction handling
concern).

This separation allows changes to the UI (View) without affecting the

business logic (Model), or changes to data storage (Model) without
altering the UI presentation, thus improving maintainability, testability, and
parallel development.

Memo: Practice Test Set 3

Scenario: Online Food Delivery Service
Question 1 (Requirements Specification - 20 points)

(a) Restaurant Functional Requirements (6 points - 2 points each,

examples):

FR1: The system shall allow a restaurant manager to add/update/delete

menu items, including descriptions, prices, and images.

FR2: The system shall notify the restaurant (e.g., via dashboard alert,
printout) when a new customer order is received.

FR3: The system shall allow a restaurant manager to confirm an incoming

order and provide an estimated preparation time.

(b) Delivery Driver Functional Requirements (6 points - 2 points each,

examples):

FR4: The system shall assign available delivery orders to nearby, available
drivers.

Example test question from gemini 21

 FR5: The system shall display the pickup location (restaurant address) and
drop-off location (customer address) for an accepted order.

FR6: The system shall allow the driver to update the order status (e.g.,
"Picked Up", "En Route", "Delivered").

(c) Reliability QR Discussion (8 points):

Relation to FRs: Reliability directly impacts FR2 (order must reach

restaurant), FR3 (confirmation must be reliable), payment processing
(implicit FR), FR4 (assignment must work), FR6 (status updates must be
recorded). If the system isn't reliable, orders get lost, payments fail,
restaurants lose business, customers are unhappy, and drivers don't get
paid correctly.

Architectural Considerations:

Error Handling/Recovery: Robust mechanisms to handle network

interruptions between customer-app, backend, restaurant-system, and
driver-app. Implement retry logic for critical operations.

Transactional Integrity: Ensure operations like order placement and

payment are atomic (all or nothing) using database transactions or
distributed transaction patterns (like Saga if using microservices).

Redundancy: Use redundant servers, databases, and network paths to

prevent single points of failure (tactics for Availability also support
Reliability).

Monitoring & Alerting: Implement comprehensive monitoring to detect

failures quickly (e.g., if restaurant systems aren't responding) and alert
support staff.

Asynchronous Communication: Use message queues (like RabbitMQ,

Kafka) for critical communication (e.g., sending order to restaurant) to
ensure delivery even if the recipient is temporarily unavailable.

Question 2 (Architectural Structures & Views - 15 points)

(a) Module vs. C&C Structures (8 points):

Module Structures: Describe the static organization of the system's code

and implementation units. Elements are modules (e.g., classes, packages,

Example test question from gemini 22

 layers). Relations show dependencies like 'uses', 'is-a', 'is-part-of'. They
help reason about modifiability, understandability, dependencies, and
team work allocation. They represent the system at compile-time or
development time.

Component-and-Connector (C&C) Structures: Describe the dynamic,

runtime organization of the system. Elements are runtime components
(e.g., processes, services, clients, servers, databases). Connectors are
interaction mechanisms (e.g., procedure calls, messages, events, data
streams). They help reason about runtime qualities like performance,
availability, scalability, and concurrency.

(b) Best Structure for Deployment (7 points):

Allocation Structure (specifically, the Deployment Structure view).

Reason: Allocation structures explicitly map software elements to non-

software elements in the environment. The Deployment Structure shows
how runtime software components (like the mobile app, web portal,
backend services, databases) are allocated to physical or virtual hardware
resources (customer phones, restaurant computers, driver phones, cloud
servers/VMs/containers) and how these hardware nodes communicate
(network paths). This view is essential for planning deployment, and
analyzing system-level performance, availability, and security based on
the physical configuration.

Question 3 (Quality Attributes & Scenarios - 15 points)

Concrete QA Scenario (Performance - Restaurant Search):

1. Source of Stimulus: Customer using the mobile app.

2. Stimulus: Customer enters their location (or allows GPS) and initiates a
search for nearby restaurants.

3. Artifact: Mobile app UI, Backend Search Service, Restaurant Database.

4. Environment: Normal operating conditions, during peak dinner hours (e.g.,

7 PM Friday), with ~10,000 other users active in the same geographic
region.

Example test question from gemini 23

 5. Response: The system retrieves a list of restaurants within a 5km radius
that are currently open, sorts them by estimated delivery time (or rating),
and displays the first 20 results (name, cuisine type, rating, delivery
estimate) in the mobile app.

6. Response Measure: 95% of searches complete (results displayed) in

under 2 seconds. Average search response time is under 1 second.

Question 4 (Fill-in-the-Blank: Domain Model - 10 points - 1 point each)

<< A >> - places / has

<< B >> - Aggregation (or Composition if OrderItems cannot exist without an

Order)

<< C >> - offers / contains

<< D >> - 1

<< E >> - 0..*

<< F >> - 1

<< G >> - 0..*

<< H >> - 1..* (An order must have at least one item)

<< I >> - 1 (An order item refers to one specific menu item)

<< J >> - Association

Question 5 (Version Control - 10 points)

(a) Staging Area (5 points):

Purpose: The staging area (or index) in Git is an intermediate area where
you prepare changes before committing them to the local repository. It
allows you to select specific changes (from modified files, even parts of
files) to be included in the next commit, rather than committing everything
that has changed in the working directory.

Command: git add <file(s)> (or git add . to stage all changes, git add -p for
interactive staging).

(b) git status (5 points):

Example test question from gemini 24

 The git status command shows the current state of your working directory
and staging area relative to the last commit (HEAD). It tells you:

Which branch you are currently on.

Whether your local branch is ahead of, behind, or diverged from its
remote counterpart.

Which files have been modified but not staged.

Which files are staged and ready to be committed.

Which files are untracked (new files Git doesn't know about yet).

Memo: Practice Test Set 4

Scenario: IoT-based Smart Home System
Question 1 (Requirements & Architecture Importance - 20 points)

(a) User Functional Requirements (Mobile App) (6 points - 2 points each,

examples):

FR1: The user shall be able to view the current status (on/off, temperature,
live feed) of connected devices (lights, thermostat, camera) via the mobile
app.

FR2: The user shall be able to remotely turn smart lights on or off via the
mobile app.

FR3: The user shall be able to set a target temperature for the smart
thermostat via the mobile app.

(b) Critical Quality Requirements (6 points - 2 points each, examples):

Security: Unauthorized users must be prevented from accessing or

controlling the smart home devices. Communication between app, cloud,
and hub must be encrypted.

Reliability: Commands sent from the app (e.g., turn light off) must reliably
reach the device and be executed. Status information displayed must be
accurate.

Performance (Responsiveness): Commands sent from the app should

result in device action (or status update) within a short, noticeable

Example test question from gemini 25

 timeframe (e.g., < 2 seconds). Live camera feed should have low latency.

(Also valid: Availability, Usability, Energy Efficiency)

(c) Importance of Architecture (Smart Home) (8 points):

Enables Quality Attributes: Critical QRs like Security, Reliability, and

Performance are heavily dependent on architectural choices. A poorly
designed architecture might have security holes (e.g., unencrypted
communication), be unreliable (e.g., single points of failure in the hub or
cloud), or be unresponsive (e.g., inefficient communication protocols).
Architecture allows reasoning about and designing for these QAs. (Relates
to Architecture Notes/Baas Ch2)

Manages Complexity/Separation of Concerns: The system involves

diverse components (hardware devices, hub firmware, cloud backend,
mobile app) potentially using different technologies. Architecture provides
structures (e.g., layers, components) to manage this complexity, separate
concerns (e.g., device communication logic from cloud data storage from
app UI), and define clear interfaces between them. (Relates to Arch
Notes/Baas Ch2)

Supports Change & Evolution (Modifiability): Smart home systems evolve

(new device types, new features). A well-designed architecture (e.g.,
modular, low coupling) makes it easier to add support for new devices or
update specific parts (like the mobile app UI) without breaking the entire
system. (Relates to Arch Notes/Baas Ch2)

(Also valid: Stakeholder Communication, Constraints Implementation,

Reuse, etc.)

Question 2 (Design Principles - 15 points)

(a) High Cohesion (7 points):

Explanation: Cohesion refers to the degree to which the elements within a

single module (e.g., a class, a component) are related in performing a
single, well-defined task or function. High cohesion means the module
does one thing and does it well, with all its internal parts contributing to
that single purpose.

Example test question from gemini 26

 Example (Smart Light Module): To achieve high cohesion, the module
responsible for controlling smart lights should only contain logic related to
lights (e.g., turning on/off, setting brightness/color, querying status). It
should not contain logic for thermostats or security cameras. All functions
and data within the module should directly support light control.

(b) Low Coupling (8 points):

Explanation: Coupling refers to the degree of interdependence between

different modules. Low coupling means modules rely on each other as little
as possible, interacting through stable, well-defined interfaces without
needing to know about each other's internal implementation details.

Desirability (Smart Home): Low coupling between the mobile app, cloud
service, and home hub is desirable because:

Modifiability/Independence: The mobile app UI can be updated without

changing the cloud backend or hub firmware, as long as the interface
(API) remains the same. Similarly, the cloud service provider could be
changed with minimal impact on the app or hub if interfaces are stable.
New types of hubs or apps could be added more easily.

Testability: Each component (app, cloud, hub) can be tested more

independently.

Reliability: A failure in one component is less likely to cascade and

cause failures in others if they are loosely coupled.

Question 3 (Process Models - 10 points)

Agile Process Model (like Scrum or Kanban) would likely be more suitable.

Justification:

Requirements Uncertainty/Evolution: Smart home features and user

expectations can evolve rapidly. Users might not know exactly what they
want initially. Agile excels at handling changing requirements.

Technology Uncertainty: Integrating various IoT devices, cloud platforms,

and mobile OSs can involve technical challenges and discoveries. Agile's
iterative nature allows for flexibility and adaptation as these are
encountered.

Example test question from gemini 27

 Need for User Feedback: Getting user feedback early and often (via
demos of working increments) is crucial for usability and ensuring the
system meets real needs. Agile processes prioritize this.

Incremental Delivery: Delivering core functionality (e.g., controlling one

type of light) early and adding more devices/features incrementally
provides value sooner and reduces risk compared to a Waterfall "big
bang" delivery.

(Waterfall might be less suitable due to potential for changing

requirements, difficulty defining everything upfront, and delayed
feedback).

Question 4 (Use Case Diagram Validity - 10 points)

(a) Device as Actor (5 points):

Generally not valid in standard UML Use Case diagrams.

Explanation: Actors typically represent external entities (usually human

users or other independent systems) that interact with the system to
achieve a goal. A Smart Light Bulb is usually considered part of the system
being designed or an internal component, not an external initiator with its
own goals. System-internal triggers or scheduled events are often
modeled differently (e.g., within activity diagrams or state machines, or
triggered by a generic 'Timer' actor if needed). The interaction should
likely be Cloud Service -> Update Device Status or Hub -> Update Device
Status.

(b) Association Between Use Cases (5 points):

Showing a direct association arrow between two primary use cases is

generally not valid for showing dependency or invocation in standard
UML.

Mechanism: Relationships between use cases are typically shown using:

: Indicates that one use case (the base) mandatorily

<<include>>

incorporates the behavior of another (the included) use case. Often

used for common shared functions like "Authenticate User".

Example test question from gemini 28

 <<extend>> : Indicates that one use case (the extending) optionally adds
behavior to another (the extended) use case at a specific extension
point. Used for optional or exceptional behavior.

Interaction via Actor: If one use case produces something an actor

uses to initiate another use case, it's implied through the actor's
interaction, not a direct use case link.

Reliance on other services (like the Cloud Service) is usually modeled

via an actor representing that service interacting with the use case, or
implicitly assumed in the use case description.

Question 5 (Version Control Collaboration - 15 points)

(a) Pull Request (PR) / Merge Request (MR) (5 points):

A mechanism provided by platforms like GitHub/GitLab/Bitbucket that

allows a developer to notify teammates about changes they've pushed to a
branch in a repository. It serves as a request to pull (or merge) the
changes from their feature branch into another branch (often main , develop ,
or a release branch). It bundles the commits, shows the differences (diffs),
and provides a platform for code review, discussion, and automated
checks before merging.

(b) Advantages of PR Workflow (6 points - 3 points each):

Code Review: Provides a structured way for teammates to review code

changes before they are merged into the main codebase, improving code
quality, catching potential bugs, ensuring adherence to standards, and
sharing knowledge.

Discussion/Collaboration: Allows for inline comments and discussion

about specific changes, facilitating collaboration and consensus before
merging.

Integration Testing/CI: PRs can trigger automated builds and tests

(Continuous Integration - CI) to ensure the changes don't break the
existing system before merging.

Clearer History: Merging via PRs (especially using squash merges or clear
merge commits) can lead to a cleaner, more understandable history on the
main branch compared to direct pushes.

Example test question from gemini 29

 (c) git fetch vs git pull (4 points):

git fetch : Downloads commits, files, and refs from a remote repository into
the local repository, updating the remote-tracking branches (e.g.,
origin/main ). It does not automatically merge these changes into your local

working branches. It lets you see what's new on the remote without
immediately changing your local work.

: Does a git fetch first, and then immediately tries to merge the
git pull

downloaded changes from the fetched remote branch into your current
local working branch. It's a shortcut for Workspace + merge .

Memo: Practice Test Set 5

Scenario: Digital Library Management System
Question 1 (Requirements Engineering - 15 points)

(a) Reasons for Iterative Requirements Engineering (8 points - 2 points

each):

1. Changing Needs: User and organizational needs evolve over time. An

iterative approach allows incorporating these changes in later cycles
rather than freezing potentially incorrect requirements early on.

2. Complexity Management: Complex systems like a digital library are hard

to fully understand upfront. Iteration allows focusing on core functionalities
first and adding complexity gradually.

3. Improved User Understanding/Feedback: Users often don't fully know

what they want until they see a working part of the system. Iterative
development provides opportunities for early user feedback on prototypes
or increments, leading to better requirement clarification. (Relates to
wicked problems - Kung Ch2).

4. Developer Understanding: The development team's understanding of the

domain and technical possibilities also grows during the project. Iteration
allows refining requirements based on this improved understanding.

5. Risk Reduction: Addressing high-risk requirements or technical

uncertainties early in iterations helps mitigate project risks sooner.

(b) Requirement vs. Constraint (7 points):

Example test question from gemini 30

 Requirement: Defines a capability the system must possess or a function
it must perform to meet user needs. It specifies what the system should do
or how well it should do it (functional or non-functional). (3 points)

Example (Digital Library): "The system shall allow members to search

the catalog by title, author, or keyword." (Functional Requirement) OR
"The system shall display search results within 3 seconds." (Non-
functional/Performance Requirement). (1 point)

Constraint: Imposes a limitation or restriction on how the system can be

designed or implemented, or on the project itself. It limits the solution
space. (3 points)

Example (Digital Library): "The system must be developed using the

Java programming language." OR "The system must integrate with the
university's existing single sign-on authentication service." OR "The
project must be completed within a budget of R500,000." (1 point)

Question 2 (UML Use Case Diagram - 15 points)

Diagram Description:

Actors: Member (representing Student/Faculty), Librarian . (2 points)

Use Cases: Search Catalog , Borrow Item , Return Item , Manage Inventory , Manage Member

Account . (5 points)

Associations:

Member associated with Search Catalog , Borrow Item , Return Item (if members
return directly), Manage Member Account (e.g., view history, update details).
(3 points)

associated with Search Catalog , Manage Inventory , Manage Member Account

Librarian

(e.g., create/delete accounts), potentially Borrow Item and Return Item (if
handling check-out/in). (3 points)

Optional Login: A Login or Authenticate User use case could be shown with an
<<include>> relationship pointing from Borrow Item , Manage Member Account , etc.,

indicating it's a required prerequisite step. Alternatively, login is simply

stated as a precondition for those use cases. (2 points)

Question 3 (UML Domain Modeling / Class Diagram - 20 points)

Example test question from gemini 31

 Diagram Description:

Classes & Attributes:

LibraryItem (Abstract or Concrete) - Attributes: title: String , callNumber: String .

(3 points)

PhysicalBook - Attribute: location: String . (2 points)

EBook - Attributes: fileFormat: String , downloadURL: String . (2 points)

Author - Attribute: name: String . (2 points)

(Optional: LibraryCatalog - No specific attributes needed for this

fragment).

Inheritance: A generalization relationship (triangle arrow pointing to

LibraryItem ) from both PhysicalBook and EBook to LibraryItem . (4 points)

Association (LibraryItem <-> Author): A standard association line between

LibraryItem and Author . (3 points)

Multiplicity: LibraryItem side: 1..* (An author writes one or more items).
Author side: 1..* (An item has one or more authors). (2 points)

Aggregation/Composition (Optional): If LibraryCatalog is included, an

aggregation (empty diamond) or composition (filled diamond) on the
end of an association line connecting LibraryCatalog to LibraryItem ,
LibraryCatalog

likely with multiplicity 1 (Catalog) to 0..* (LibraryItem). (2 points)

Question 4 (Architectural Styles & Patterns - 10 points)

(a) Foundational Architectural Style (5 points):

Client-Server (or more specifically, N-Tier Architecture, often 3-Tier:

Presentation/Client, Application/Business Logic, Data).

Justification: Users (students, librarians) interact via clients (web

browsers, mobile apps, desktop apps). These clients communicate over a
network with backend server(s) that handle the core logic (searching, loan
processing, data storage) and data persistence. This separation is the
essence of Client-Server/N-Tier.

(b) Layered Architecture (Server-Side) (5 points):

Example test question from gemini 32

 Yes, a Layered Architecture would be beneficial within the server.

How it helps: It separates concerns vertically. For example:

Presentation/API Layer: Handles incoming requests from clients

(web/mobile/desktop), exposes APIs.

Business Logic Layer: Contains core library rules (loan logic, search
logic, user management).

Data Access Layer: Handles communication with the database

(storing/retrieving catalog, user, loan data).

(Potentially an Integration Layer for external APIs).

This separation improves modifiability (can change database access

without affecting business logic), testability (can test layers
independently), and understandability.

Question 5 (Version Control Strategies - 10 points)

Comparison (e.g., Gitflow vs. GitHub Flow):

Gitflow: (2 points)

Description: A structured model with long-lived branches ( main for

production, develop for integration) and supporting branches ( feature/* ,
release/* , hotfix/* ). Features are developed in isolation, merged to develop ,

prepared for release in release branches, and finally merged to main and
tagged. Hotfixes are done off main .

Advantage: Very structured, enforces separation between

development, release preparation, and production code. Good for
scheduled releases and managing multiple versions.

Disadvantage: Can be complex for small teams or projects with

continuous deployment; many branches to manage.

GitHub Flow: (2 points)

Description: Simpler model. main branch is always deployable.

Features/fixes are developed on short-lived branches created from
main . Changes are merged back to main via Pull Requests frequently,

Example test question from gemini 33

 often triggering automated deployment. No develop or release branches
typically.

Advantage: Simple, fast iteration, well-suited for continuous

deployment/delivery (CD). Easy for teams to understand.

Disadvantage: Requires robust automated testing and deployment

pipeline as main is always live. Less explicit support for managing
multiple release versions simultaneously compared to Gitflow.

Suitability for Student Team/Digital Library: (1 point for choice + 1 point

justification for each)

GitHub Flow might be more suitable. Simplicity is key for student teams.
Frequent merges and focus on deployable main (even if deployment is just
to a test server) encourages continuous integration. The overhead of
Gitflow's release/hotfix branches might be unnecessary for a typical
university project timeline.

Gitflow could be suitable if the project aims to simulate a more formal

release process or if multiple distinct versions need to be maintained, but
the complexity might hinder a student team.

Memo: Practice Test Set 6

Scenario: Online Food Delivery Service (Revisited)

Question 1 (Quality Attributes & Tactics - 20 points)

(a) Availability Tactics (10 points):

List 3 Tactics: (Referencing Arch Notes Fig 9.1 or similar) (6 points - 2

points each)

Detect Faults: Ping/Echo, Heartbeat, Exception Detection, Voting,

Resource Monitoring.

Recover from Faults: Redundant Spare (Hot/Warm/Cold), Rollback,

Software Upgrade (Hitless), Retry, Graceful Degradation,
Reconfiguration.

Prevent Faults: Removal From Service (for maintenance), Transactions

(ACID), Predictive Model.

Example test question from gemini 34

 Application Example (1 Tactic): (4 points)

Tactic: Ping/Echo (Detect Faults).

Application: The central backend service could periodically send a

"ping" message to each connected restaurant's ordering system
endpoint. If it doesn't receive an "echo" response within a timeout
period after a few retries, the backend can mark that restaurant as
temporarily offline/unavailable in the customer app, preventing
customers from placing orders that won't be received.

(b) Security Tactics (10 points):

List 3 Tactics: (Referencing Arch Notes Fig 9.3 or similar) (6 points - 2

points each)

Resist Attacks: Limit Access (Authentication, Authorization), Limit

Exposure (Minimize attack surface, Ring-fence resources), Encrypt
Data (Confidentiality), Use Secure Defaults.

Detect Attacks: Intrusion Detection Systems (implied by

monitoring/logging), Determine Message Integrity, Event Logging and
Analysis.

Recover from Attacks: Limit Damage (Drop connection/requests),

Restore State, Update Access Rules.

Application Example (1 Tactic): (4 points)

Tactic: Encrypt Data (Confidentiality) (Resist Attacks).

Application: When a customer enters their credit card details, the

mobile app must transmit this data to the backend payment processing
service over an encrypted channel (e.g., HTTPS/TLS). Furthermore, if
the system stores any part of the payment information (even if
tokenized), that stored data must also be encrypted using strong
algorithms to prevent unauthorized access even if the database itself is
compromised.

Question 2 (Architecture Maintenance & Evolution - 15 points)

(a) Architecture Debt (5 points):

Example test question from gemini 35

 Architecture debt (a form of technical debt) refers to the implied cost or
negative consequences resulting from choosing an easy, short-term
architectural solution or design now, instead of using a better approach
that would take longer but be more sustainable. It represents architectural
design decisions that compromise long-term quality attributes (like
modifiability, performance, reliability) for short-term gains (like faster
delivery). Like financial debt, it accrues "interest" in the form of increased
effort for future changes, bug fixing, or maintenance. (Reference Baas Ch
23).

(b) Scenario & Consequences (10 points):

Scenario: During initial development of the Food Delivery Service, to meet

a tight deadline, the team decides to put the order management logic,
restaurant notification logic, and driver dispatch logic all within one large
monolithic service, even though they recognized these were distinct
concerns. They might have hardcoded dependencies between these parts
instead of using clear interfaces or events. (5 points)

Consequences: (5 points)

Reduced Modifiability: Changing the driver dispatch algorithm later

becomes difficult and risky because it's tangled with order and
notification logic. Adding a new notification method (e.g., SMS)
requires modifying the large, complex monolith.

Reduced Scalability: The entire monolith must be scaled together,

even if only the driver dispatch part is under heavy load, leading to
inefficient resource use.

Reduced Reliability: A bug in the notification logic could potentially

crash the entire service, halting order management and driver dispatch
as well.

Slower Development: Future changes take longer due to complexity

and the risk of unintended side effects. Onboarding new developers is
harder.

Question 3 (Architectural Patterns - 15 points)

(a) Microservices Advantages (6 points - 3 points each):

Example test question from gemini 36

 1. Independent Scalability: Each service (Orders, Restaurants, Drivers,
Payments) can be scaled independently based on its specific load. If
driver tracking is resource-intensive, only that service needs more
instances, saving costs compared to scaling a monolith.

2. Independent Deployability/Faster Releases: Changes to one service (e.g.,

updating the payment gateway integration) can be deployed independently
without redeploying the entire system, leading to faster feature releases
and bug fixes. Teams can work and deploy more autonomously.

3. Technology Diversity: Different services can potentially use different

programming languages, databases, or technologies best suited for their
specific task.

4. Improved Fault Isolation: Failure in one non-critical service (e.g., menu

recommendation service) is less likely to bring down the entire system
compared to a monolith failure.

(b) Microservices Disadvantages/Challenges (6 points - 3 points each):

1. Operational Complexity: Managing many independent services

(deployment, monitoring, logging, configuration) is significantly more
complex than managing a single monolith. Requires sophisticated DevOps
practices and tooling.

2. Distributed System Challenges: Dealing with network latency, eventual

consistency, distributed transactions (e.g., ensuring an order is saved AND
payment is processed reliably), and inter-service communication failures
adds complexity.

3. Testing Complexity: End-to-end testing requires coordinating multiple

services, which can be difficult to set up and manage.

4. Data Consistency: Maintaining data consistency across multiple service-

specific databases can be challenging (often requires eventual
consistency patterns).

(c) Low Coupling & Microservices (3 points):

Low coupling is a fundamental goal and characteristic of the microservices

pattern. Each microservice should be largely independent, communicating
with others only through well-defined, stable APIs (e.g., REST, gRPC,

Example test question from gemini 37

 message queues). This loose coupling is what enables independent
deployment, scaling, and development.

Question 4 (Testing & Process - 10 points)

(a) Unit vs. Integration Testing (5 points):

Unit Testing: Focuses on verifying the smallest testable parts of the

software (units - often methods or classes) in isolation. Dependencies on
other units are typically mocked or stubbed out. Aims to ensure each
individual piece of code works correctly according to its specific contract.
(Usually automated).

Integration Testing: Focuses on verifying the interaction and

communication between different units or components after they have
been integrated. Aims to ensure that integrated parts work together as
expected, checking interfaces, data flow, and combined behavior. (Can be
automated or manual).

(b) Testing in an Agile Sprint (5 points):

Unit Tests: Written and run continuously by developers as they write the
production code (often using Test-Driven Development - TDD). They are
typically run frequently (e.g., before every commit, as part of CI builds) to
provide fast feedback on code correctness. Responsibility: Developer.

Integration Tests: Typically written/run after related units are developed

and integrated, often towards the end of implementing a feature or user
story within the sprint, or as part of the Continuous Integration (CI) pipeline
triggered by commits or Pull Requests. They verify that the pieces connect
correctly before the feature is considered "done". Responsibility:
Developer (for component integration) / QA/Testers (for broader
integration) / CI System.

Question 5 (Team Dynamics & Project Success - 10 points - 2 points each)

(Factors for Success - Examples based on test examples/SE principles):

1. Clear Communication: Open, honest, and frequent communication

channels (meetings, chat, documentation) between all team members and
stakeholders are essential to avoid misunderstandings and keep everyone
aligned.

Example test question from gemini 38

 2. Defined Roles & Responsibilities: Each team member understanding their
role (e.g., developer, tester, product owner, scrum master) and
responsibilities prevents confusion, duplication of effort, and tasks falling
through the cracks.

3. Shared Vision/Goals: The entire team understanding and being committed

to the project's overall goals and the specific sprint goals ensures
everyone is pulling in the same direction.

4. Mutual Trust & Respect: Team members trusting each other's abilities and
respecting diverse opinions fosters collaboration, psychological safety,
and constructive feedback, rather than blame or conflict.

5. Effective Leadership/Facilitation: Good project management (or Scrum

Master facilitation) helps organize tasks, remove impediments, manage
conflicts constructively, and keep the team focused and motivated.

6. (Other valid factors: Team Cohesion, Constructive Conflict Resolution,

Accountability, Empowerment, Appropriate Skills/Training, Effective
Tooling).

Practice Question Set 7 - Question 1

Scenario: An Online Banking Application allows customers to manage their bank
accounts, view transactions, transfer funds, pay bills, and update their personal
information securely via a web or mobile interface.
Task: Using the Online Banking Application as an example, specify five (5) high-
level functional requirements (R1, R2, ... R5). For each high-level requirement,
provide three (3) sub-requirements (e.g., R1.1, R1.2, R1.3, etc.).
(Time Suggestion: 10 minutes)

Memo for Practice Question Set 7 - Question 1

R1: Account Information Access

R1.1: The user must be able to log in securely using their username/account
number and password, potentially with multi-factor authentication (MFA).

R1.2: The user must be able to view the current balance for all their associated
accounts (e.g., checking, savings, credit cards).

Example test question from gemini 39

 R1.3: The user must be able to view the transaction history for a selected
account, including date, description, and amount.

R2: Fund Transfers

R2.1: The user must be able to transfer funds between their own accounts
linked within the application.

R2.2: The user must be able to initiate electronic fund transfers (EFTs) to
external bank accounts by providing the recipient's account details.

R2.3: The user must be able to view the status (e.g., pending, completed,
failed) of past and scheduled fund transfers.

R3: Bill Payment

R3.1: The user must be able to add and manage payees (billers) by providing
necessary details (e.g., company name, account number).

R3.2: The user must be able to schedule and make one-time or recurring
payments to registered payees from a selected account.

R3.3: The user must be able to view a history of past bill payments, including
payee, date, and amount.

R4: Profile Management

R4.1: The user must be able to view and update their personal contact
information (e.g., address, phone number, email).

R4.2: The user must be able to change their login password and manage
security settings (e.g., MFA options).

R4.3: The user must be able to set preferences for account alerts and
notifications (e.g., low balance alerts, large transaction notifications).

R5: Transaction Search & Filtering

R5.1: The user must be able to search their transaction history using keywords
or amounts.

R5.2: The user must be able to filter their transaction history by date range.

R5.3: The user must be able to filter their transaction history by transaction
type (e.g., debits, credits, transfers).

Example test question from gemini 40

 (Note: Other valid requirements exist, such as applying for loans, mobile check
deposit, viewing statements, etc.)

Practice Question Set 7 - Question 2

Scenario: A Ride-Sharing Application (like Uber or Bolt) connects passengers

needing rides with available drivers. Passengers use a mobile app to request
rides, track driver arrival, make payments, and rate drivers. Drivers use a separate
interface (usually within the same app) to accept ride requests, navigate, and
track earnings.
Task: Using the Ride-Sharing Application as an example, specify six (6) high-level
functional requirements (R1, R2, ... R6), ensuring at least one relates specifically to
the Driver user. For each high-level requirement, provide three (3) sub-
requirements (e.g., R1.1, R1.2, R1.3, etc.).
(Time Suggestion: 10 minutes)

Memo for Practice Question Set 7 - Question 2

R1: Passenger - Ride Request

R1.1: The passenger must be able to input or select their pickup location on a
map interface.

R1.2: The passenger must be able to input their destination address.

R1.3: The passenger must be able to select a desired ride type (e.g., standard,
XL, premium) and view the estimated fare.

R2: Passenger - Ride Monitoring

R2.1: After a ride is accepted, the passenger must be able to view the assigned
driver's details (name, photo, car model, license plate).

R2.2: The passenger must be able to track the driver's current location and
estimated time of arrival (ETA) on the map in real-time.

R2.3: The passenger must be able to contact the driver (e.g., via anonymized
call or in-app message) if needed.

R3: Passenger - Payment & Rating

Example test question from gemini 41

 R3.1: The passenger must be able to add, select, or remove payment methods
(e.g., credit card, digital wallet).

R3.2: The system must automatically process the payment using the selected
method upon ride completion.

R3.3: The passenger must be prompted to rate the driver (e.g., 1-5 stars) and
optionally provide comments or a tip after the ride.

R4: Driver - Ride Acceptance & Management

R4.1: The driver must receive notifications for nearby ride requests, including
pickup location and estimated fare/distance.

R4.2: The driver must be able to accept or decline an incoming ride request
within a specified time limit.

R4.3: Upon acceptance, the driver must be provided with navigation guidance
to the passenger's pickup location.

R5: Driver - Trip Execution

R5.1: The driver must be able to notify the system upon arrival at the pickup
location.

R5.2: The driver must be able to start the trip in the app once the passenger is
in the vehicle.

R5.3: The driver must be able to end the trip in the app upon reaching the
destination, which triggers payment processing.

R6: User Account Management (Common to Passenger/Driver)

R6.1: Users (passengers and drivers) must be able to register and log in to their
accounts.

R6.2: Users must be able to view their past ride/trip history.

R6.3: Users must be able to access help/support resources or report issues

related to rides or payments.

Practice Question Set 7 - Question 3

Scenario: A Music Streaming Service (like Spotify or Apple Music) allows users to
listen to a vast library of music tracks and podcasts. Users can search for content,

Example test question from gemini 42

 create playlists, follow artists, download music for offline listening, and receive
personalized recommendations.

Task: Using the Music Streaming Service as an example, specify six (6) high-level
functional requirements (R1, R2, ... R6). For each high-level requirement, provide
two (2) sub-requirements (e.g., R1.1, R1.2, R2.1, R2.2, etc.).
(Time Suggestion: 10 minutes)

Memo for Practice Question Set 7 - Question 3

R1: Music Discovery & Search

R1.1: The user must be able to search for tracks, albums, artists, playlists, or
podcasts using keywords.

R1.2: The system must allow users to browse music by genre, mood, or
curated charts (e.g., Top Hits, New Releases).

R2: Playback Control

R2.1: The user must be able to play, pause, skip forward, and skip backward
selected audio content (tracks/podcast episodes).

R2.2: The user must be able to control the playback volume and view playback
progress.

R3: Playlist Management

R3.1: The user must be able to create new personal playlists and add tracks or
podcast episodes to them.

R3.2: The user must be able to edit existing playlists (rename, reorder tracks,
remove tracks) and delete playlists.

R4: Library & Offline Access

R4.1: The user must be able to save favorite tracks, albums, artists, or
podcasts to their personal library for easy access.

R4.2: Premium users must be able to download selected content (playlists,

albums, podcasts) to their device for offline playback.

R5: Personalization & Recommendations

Example test question from gemini 43

 R5.1: The system must generate personalized music or podcast
recommendations based on the user's listening history and preferences.

R5.2: The user must be able to follow specific artists or podcasters to receive
notifications about new releases.

R6: User Authentication & Subscription

R6.1: The user must be able to register for an account (free or premium) and
log in.

R6.2: The user must be able to manage their subscription status (e.g., upgrade
to premium, view billing information).

Practice Question Set 7 - Question 4

Scenario: A Project Management Tool (like Trello or Asana) helps teams organize,
track, and manage their work. It typically involves creating projects or boards,
adding tasks (often represented as cards), assigning tasks to team members,
setting deadlines, and visualizing progress through different stages (e.g., To Do, In
Progress, Done).
Task: Using the Project Management Tool as an example, specify five (5) high-
level functional requirements (R1, R2, ... R5). For each high-level requirement,
provide three (3) sub-requirements (e.g., R1.1, R1.2, R1.3, etc.).
(Time Suggestion: 10 minutes)

Memo for Practice Question Set 7 - Question 4

R1: Project/Board Setup

R1.1: The user must be able to create a new project or board.

R1.2: The user must be able to invite team members to collaborate on a

project/board.

R1.3: The user (e.g., admin) must be able to define stages or lists within a
board (e.g., "To Do", "In Progress", "Done").

R2: Task Creation & Management

R2.1: The user must be able to create new tasks (cards) within a specific
project/board list.

Example test question from gemini 44

 R2.2: The user must be able to add details to a task, such as a description,
checklist items, and attachments.

R2.3: The user must be able to assign one or more team members to a task.

R3: Task Organization & Workflow

R3.1: The user must be able to move tasks (cards) between different
stages/lists to reflect progress.

R3.2: The user must be able to set due dates for tasks.

R3.3: The user must be able to add labels or tags to tasks for categorization
(e.g., "Bug", "Feature", "Urgent").

R4: Collaboration & Communication

R4.1: Users must be able to add comments to tasks to discuss progress or ask
questions.

R4.2: The system must provide notifications to relevant users about task
updates (e.g., assignment, comments, due date changes).

R4.3: Users must be able to view an activity feed or history for a specific task
or project/board.

R5: Task Viewing & Filtering

R5.1: Users must be able to view all tasks assigned to them across different
projects/boards.

R5.2: Users must be able to filter tasks within a project/board based on criteria
like assignee, due date, or label.

R5.3: The system must provide different views for tasks, such as a list view,
board (Kanban) view, or calendar view.

Example test question from gemini 45