mid

Perfect — let’s use these past papers as practice, and I’ll give you the answers + the “why” (the way your professor expects).

Testing individual components/units of code
✅ c) Unit Testing
Why: unit testing = testing one small “unit” (function/class/module) alone.
Agile framework with time-boxed iterations called sprints
✅ a) Scrum
Why: Scrum works in sprints (usually 1–4 weeks).
Primary role of a Product Owner in Agile
✅ c) Defining product features and prioritizing the backlog
Why: PO decides what to build first (priority).
NOT a software validation technique
✅ c) Code reviews
Why: code review is mainly verification (“did we build it correctly?”), not validation (“did we build the right thing for users?”).
Best definition of software verification
✅ b) Checking if the software meets specified requirements
Why: verification = meets specs/requirements.
“User story” in Agile refers to
✅ b) A concise description of a feature from the end-user’s perspective
Why: user story format is like: “As a ___, I want ___ so that ___.”
Primary goal of software validation
✅ a) Ensuring the software meets business needs
Why: validation = meets user/business needs.
Best describes Agile methodology
✅ b) A flexible, iterative approach that emphasizes collaboration and adaptability
Activity typically associated with software validation
✅ c) User acceptance testing
Why: UAT is literally users confirming it meets their needs.

(You had “validation goal” asked twice on the sheet — it’s still (a) both times.)

Stakeholder definition includes “actively contributes to validation”
❌ False
Stakeholder = anyone affected / interested. They may help validate, but not always.
If stakeholders don’t conflict, no need for RE practices
❌ False
You still need elicitation, documentation, validation, etc.
Multi-level requirements is a major systems-of-systems challenge
✅ True
During elicitation consider things inside & outside system/context boundaries
✅ True
You consider system boundary + environment/context while eliciting.
Waterfall assumes all requirements can be elicited at the beginning
✅ True
Effort in RE is inversely proportional to the risk one is willing to take
✅ True
If you accept more risk → you invest less effort; if you want less risk → invest more effort.
System requirements can be functional, quality, constraints
✅ True
Assess shared understanding by validating all explicitly specified requirements
❌ False
Validating explicit requirements helps, but shared understanding is usually checked via workshops, reviews, prototypes, scenario walkthroughs, etc.
Reaction time and cultural issues should be documented in requirements specs
✅ True
Reaction time = performance; cultural issues = usability/localization constraints.
Personas are real individuals selected to test/validate directly
❌ False
Personas are fictional archetypes, based on research.

Actors mentioned: User, Tutor, Exam-Reviewer
Main use cases that must exist:

User (Learner)

Tutor

Exam-Reviewer

(Optionally: Login/Register, but not required unless your course always includes it.)

Actors:

System boundary: “Training System”

Use cases inside the system:

Good UML relationships (the ones professors love):

Request Quiz <<include>> Generate Quiz
Generate Quiz <<include>> Select Questions
Generate Quiz <<include>> Compose Quiz
Take Quiz <<include>> Submit Answers
Submit Answers <<include>> Rate Answers / Calculate Score
Request Hint <<extend>> Take Quiz (because hint is optional, only if user asks)

Tutor:

Exam-Reviewer:

Exam-Reviewer — Review/Certify Question
Review/Certify Question <<include>> Approve or Reject (or you can model approve/reject as alternative outcomes instead of extra use cases)

Pick ONE use case and write a mini-spec. Here’s a strong example you can copy:

Primary Actor: User
Preconditions: User is on the system (optionally logged in) and questions exist in the database and are certified.
Main Flow:
1. User selects “Request Quiz”.
2. System asks for quiz settings (topic, number of questions, difficulty).
3. System selects appropriate questions from database.
4. System composes the quiz.
5. System displays the quiz to the user.
Alternative Flow (A1: Not enough questions):
- System informs user and suggests reducing number of questions or changing topic/difficulty.
Postconditions: A quiz session is created and ready for answering.

(That’s exactly the style many SE/UML midterms want.)

From the ATM diagram shown:

“Transaction is an abstract superclass for Withdrawal, Inquiry, Deposit, Transfer and Invalid PIN.”
❌ False
Invalid PIN is shown as <<extend>>, not a subclass/generalization.
“The relation between Invalid PIN and Transaction does not conform to UML.”
❌ False
<<extend>> from “Invalid PIN” to “Transaction” is acceptable (optional behavior when PIN is wrong).
“Use case should clarify direction of data transfer to/from Central Database.”
❌ False
Use case diagram doesn’t show data flow directions (that’s not its job).
“Central Database should be outside the ATM system box, keep connections.”
✅ True
External systems should be actors outside the system boundary.
“Relation between Customer and GUI is not permitted in UML use case syntax.”
✅ True
Actor-to-actor links aren’t standard; actors connect to use cases (and GUI usually isn’t an actor if it’s part of the system).
“Relations connecting Operator, GUI and Bank to ATM System are missing arrows.”
❌ False
Associations in use case diagrams are normally plain lines (no arrows needed).

Available in English, German, French
❌ False (Non-functional: localization/internationalization)
Allow user to search for books by author and title
✅ True (Functional feature)
Provide list of previously ordered books
✅ True (Functional feature)
Support minimum 1000 transactions per hour
❌ False (Non-functional: performance)
Available to all users 24/7
❌ False (Non-functional: availability)
Allow user to remove books from cart at any moment
✅ True (Functional feature)

If you want, send me one page at a time (clear photo), and I’ll turn it into:

a clean answer key
plus “exam-style wording” you can write in the booklet (especially for UML/requirements questions).