Name : Abdalrahman Yosef Al Dossery

ID : 21561280

Q1
1.1 Requirement Provided by Generative AI Tool and Quality Comment

When prompted with "give me one non-functional requirement for a Virtual Learning
Environment system," a typical generative AI tool will likely provide a requirement
related to Performance or Security. For instance, a common response would be:

"The Virtual Learning Environment (VLE) system shall be able to handle 10,000
concurrent users without any noticeable degradation in response time."

Quality Comment

 Completeness: The requirement states a quantity (10,000 concurrent users)

and a quality attribute (no noticeable degradation in response time), which is
a good start. However, "noticeable degradation" is still somewhat subjective.
What constitutes "noticeable" needs to be defined more precisely. It also
doesn't specify the type of response time (e.g., page load, submission,
navigation).

 Ambiguity: The term "noticeable degradation" introduces ambiguity. What

might be noticeable to one user might be acceptable to another. This lack of
a concrete, measurable metric makes it difficult to objectively test and verify
if the requirement has been met.

 Testability: While the number of concurrent users is testable through load

testing, the "no noticeable degradation" part makes the test outcome
subjective. A more specific metric is needed for clear testability.

 Traceability: The requirement is clear about its purpose (performance under

load) and links directly to the user experience in a VLE.

Assumptions Made by the Tool

The tool makes several assumptions, typical of a general AI:

 Standard VLE Usage: It assumes a typical VLE usage pattern where

concurrent users are interacting with the system, leading to the concern
about response time.

 Importance of Performance: It assumes that performance, specifically

under load, is a critical non-functional aspect for a VLE system, which is
generally true for multi-user platforms.

 Measurability through "noticeable degradation": It implicitly assumes

that "noticeable degradation" is a commonly understood and acceptable
 (albeit vague) way to express performance, rather than requiring a hard
numerical threshold.

 General System Scope: It does not assume any specific underlying

architecture, hardware, or network conditions, focusing solely on the user-
perceived performance.

1.2 Restated Requirement for Clarity and Specificity

To make the requirement clearer and more specific, we need to quantify "noticeable
degradation" and specify the type of response time. Using SMART (Specific,
Measurable, Achievable, Relevant, Time-bound) criteria is helpful.

Restated Requirement:

"The Virtual Learning Environment (VLE) system shall support 10,000 concurrent
active users, where an active user is defined as someone logged in and
performing typical VLE actions (e.g., viewing content, participating in forums,
submitting assignments). For 95% of all user interactions (e.g., page loads, quiz
submissions, file uploads), the system's response time shall not exceed 3
seconds during peak usage periods. The remaining 5% of interactions (e.g.,
complex report generation) shall not exceed 10 seconds."

Explanation of Improvements:

 Specific: We've explicitly defined "active user" and specified the types of
interactions. We've also broken down response times for different interaction
complexities.

 Measurable: Instead of "no noticeable degradation," we use concrete,

quantifiable metrics: "95% of interactions shall not exceed 3 seconds" and
"5% of interactions shall not exceed 10 seconds." This allows for objective
testing.

 Achievable/Relevant (Implicit): While achievability depends on the

specific VLE and resources, this restatement provides clear targets. It is
highly relevant to a VLE, where quick response times are crucial for user
satisfaction and effective learning.

 Time-bound (Implicit): While not a fixed date, "during peak usage periods"
provides a contextual time frame for when these performance levels are
expected. Further refinement could specify exact peak hours or user
numbers.

 Reduced Ambiguity: The clear numerical thresholds eliminate subjective

interpretation of "noticeable degradation."
  Improved Testability: A test plan can now be developed with clear pass/fail
criteria based on these timings and user loads.

Q2
2.1 Mandated Constraint

A possible mandated constraint for a Virtual Learning Environment (VLE) system is:

The VLE system must comply with the General Data Protection Regulation (GDPR)
regarding the collection, processing, and storage of personal data of all users. This
includes provisions for data anonymization, consent management, and data breach
notification.

2.2 List of 4 Functional Requirements

Here are 4 functional requirements for a VLE, each with its type:

1. User Authentication: The system shall allow users (students, instructors,

administrators) to log in securely using a unique username and password.

o Type: Process Requirement (describes an action or process the system

must perform)

2. Course Content Management: The system shall enable instructors to upload,

organize, and publish various types of course materials, including documents
(PDFs, Word files), videos, and presentations.

o Type: Data Requirement (describes the data the system must store,
manage, or manipulate, often implying associated processes)

3. Assignment Submission and Grading: The system shall provide a mechanism

for students to submit assignments digitally and for instructors to grade
these submissions and provide feedback.

o Type: Process Requirement (describes a sequence of actions or

operations)

4. Discussion Forum: The system shall provide a discussion forum where

students and instructors can post questions, replies, and engage in threaded
conversations related to course topics.

o Type: Process Requirement (describes an interactive feature or

communication process)

2.3 List of 4 Non-Functional Requirements (Different Types)

Here are 4 non-functional requirements for a VLE, each of a different type:

 1. Performance (Response Time): The VLE system shall ensure that all common
user actions (e.g., page loads, navigation between modules) complete within
3 seconds for 90% of concurrent users during peak usage hours.

o Type: Performance Requirement (specifies how fast, how much, or how

quickly the system must perform)

2. Security (Access Control): The VLE system shall implement role-based access
control, ensuring that users can only access functionalities and data
commensurate with their assigned roles (e.g., students cannot access
instructor-only content or gradebooks).

o Type: Security Requirement (specifies how the system protects itself

and its data from unauthorized access or malicious attacks)

3. Usability (User Interface Consistency): The VLE system shall maintain a

consistent user interface layout, navigation patterns, and iconography across
all modules and pages to minimize user learning curve and errors.

o Type: Usability Requirement (specifies how easy the system is to learn,

operate, or understand)

4. Maintainability (Code Modularity): The VLE system's codebase shall be

designed with modular components and clear APIs to facilitate future
enhancements, bug fixes, and integration with other systems without
extensive re-engineering.

o Type: Maintainability Requirement (specifies how easy it is to modify,

extend, or fix the system)

2.4 Volere Template for a Requirement

Here is a Volere template (minimum 8 sections) for the "User Authentication"

functional requirement identified in 2.2, using sections of the snowcard:

Requirement Identifier: FR001

Requirement Name: User Authentication

Description: The system shall allow users (students, instructors, administrators) to

log in securely using a unique username and password.

Fit Criterion: Users are able to successfully log in within 2 seconds. Invalid login
attempts are blocked after 5 consecutive failures for a duration of 30 minutes.

Customer Value: Enables controlled access to the VLE, ensuring that only authorized
individuals can access their respective content and functionalities, maintaining data
integrity and security.
Dependencies: Requires a user database, a secure hashing algorithm for passwords,
and network connectivity.

Conflicts: None identified at this stage.

History:

 Version: 1.0

 Date: 2025-07-21

 Author: [Your Name]

 Reason: Initial requirement for core system functionality.

2.5
2.6 Discussion About Stereotypes

In the Use Case Diagram, I've used two common stereotypes:

<<include>> and <<extend>>. These stereotypes help to manage
complexity and provide more detail about the relationships between
use cases, making the diagram more readable and informative.

1. <<include>> Stereotype:

o Justification: The <<include>> relationship is used when

one use case always incorporates the behavior of another
use case. For example, "Submit Assignment"
<<include>> "Upload File." This means that whenever a
student submits an assignment, they will necessarily go
 through the process of uploading a file. Similarly, "Grade
Assignment" <<include>> "Provide Feedback" indicates
that providing feedback is an integral part of the grading
process.

o Benefits:

 Reduces Redundancy: Instead of detailing the

"Upload File" process within every use case that
requires file uploading (e.g., submitting an
assignment, uploading profile picture), it's defined
once as a separate use case and included where
needed. This makes the diagram cleaner and easier
to maintain.

 Promotes Reusability: The included use case (e.g.,

"Upload File") becomes a reusable component
across multiple higher-level use cases, simplifying
system design and development.

2. <<extend>> Stereotype:

o Justification: The <<extend>> relationship is used when

a use case conditionally adds behavior to another, base
use case. For example, "Reset Password" <<extend>>
"Log In." This means that during the "Log In" process, a
user might choose to "Reset Password" if they forget it,
but it's not a mandatory part of every login attempt.
Similarly, "Customize Report Parameters" <<extend>>
"Generate System Reports" implies that an administrator
can customize parameters, but it's not always required to
generate a report.

o Benefits:

 Models Optional Behavior: It clearly distinguishes

optional or alternative flows from the main flow of a
use case, making the system's behavior easier to
understand.

 Manages Complexity: By separating optional

functionalities, the core use case remains focused
and less cluttered, improving the clarity of the
 diagram and making it easier to comprehend the
primary user interactions.

2.7 Use Case Textual Description: Submit Assignment

Identifier and Name: UC002 - Submit Assignment

Initiator: Student

Goal: For the Student to successfully submit a completed

assignment to the VLE for grading.

Precondition:

 The Student is logged into the VLE.

 The Student is enrolled in a course with an open assignment.

 The assignment due date has not passed.

Postcondition:

 The assignment is recorded as submitted for the student.

 The instructor can view the submitted assignment.

 The student receives a confirmation of submission.

Assumptions:

 The student has completed the assignment outside the VLE.

 The student has a stable internet connection.

 The uploaded file is within the allowed file size and type limits.

Main Success Scenario:

1. The Student navigates to the relevant course.

2. The Student selects the specific assignment from the course

page.

3. The VLE displays the assignment details page.

4. The Student clicks on the "Submit Assignment" button.

5. The VLE displays the assignment submission interface, which

includes an option to upload a file.
 6. The Student selects the assignment file from their local device.
(This includes "Upload File" Use Case)

7. The Student confirms the submission.

8. The VLE uploads the file and records the submission.

9. The VLE displays a submission confirmation message to the

Student.

10. The VLE sends a submission confirmation email to the

Student.

Extensions:

 1a. Invalid Course or Assignment Selection:

o If the Student attempts to access a non-existent course

or assignment, the system displays an error message and
redirects the Student to the course dashboard.

 5a. Exceeded File Size Limit:

o If the uploaded file exceeds the maximum allowed file

size, the VLE displays an error message indicating the file
size limit and prompts the Student to upload a smaller
file.

 5b. Invalid File Type:

o If the uploaded file is not an allowed file type, the VLE

displays an error message indicating valid file types and
prompts the Student to upload a compatible file.

 7a. Student Cancels Submission:

o If the Student clicks "Cancel" at any point during the

submission process before final confirmation, the VLE
discards the submission and returns the Student to the
assignment details page.

 8a. Network Error during Upload:

o If a network error occurs during file upload, the VLE

displays an error message, retains any partial upload if
possible, and prompts the Student to retry the upload.

 8b. Late Submission:

o If the Student attempts to submit after the due date, the
VLE displays a warning message indicating the
submission is late but allows submission if configured to
do so. The submission is marked as late.
Q3

3.1 3.2 .3.3 3.4

3.5
4.1 4.2 4.3