SmartCampus 2.
0 – Requirements Quality
Workshop
Context
The university is building SmartCampus 2.0, a platform designed to improve student services.
It will allow students to:
• Register for courses
• Book study rooms
• Pay tuition online
• Receive notifications about campus events
The system must integrate with the existing Student Information System (SIS) and support more
than 25,000 students. Your group’s task is to apply the concepts from lecture (Quality of
Requirements, Specification, Agile, Validation, and Change) to improve and analyze
requirements.
You will:
1. Identify flaws in given requirements.
2. Rewrite them in a clearer, testable way.
3. Express some in Agile user story format.
4. Validate requirements using standard checks.
5. Handle a simulated change request.
Flawed Requirements
1. The system shall provide easy access to course registration and payments.
2. Students shall be able to book study rooms and the system should automatically
send reminders and cancel bookings if necessary.
3. The system shall be available all the time except when it is down for maintenance.
4. The system shall support mobile and desktop users with a consistent interface, but
the mobile version may exclude some functions.
5. Users shall log in securely.
6. The platform shall be integrated with the university’s SIS, library, and other
systems if required.
7. The system shall generate reports that are accurate and useful for administrators.
Student Tasks
Phase 1 – Quality of Requirements
• Identify problems in the flawed requirements (ambiguity, vagueness, contradictions, etc.).
• Rewrite at least 3 into better, testable forms.
Example rewrite:
• Flawed: “Users shall log in securely.”
• Improved: “The system shall require users to authenticate using their university ID and
password, and enforce password rules (minimum 8 characters, one number, one special
character).”
Phase 2 – Requirements Specification
• Write 3 functional and 2 non-functional requirements for SmartCampus 2.0 using
structured natural language.
• Optional: Draw a simple use-case diagram.
Phase 3 – Requirements in Agile
• Rewrite requirements from Phase 2 as user stories (e.g., “As a student, I want to book a
study room so that I can prepare for exams with my peers.”).
• Compare benefits/drawbacks of Agile vs. traditional specifications.
Phase 4 – Requirements Validation
• Exchange your requirements with another group.
• Validate them using the checklist:
o Validity
o Consistency
o Completeness
o Realism
o Verifiability
Phase 5 – Requirements Change
• Instructor introduces a change request
• Analyze its impact, decide whether to accept, and update at least one requirement.
Deliverables
• Improved versions of flawed requirements.
• Mini SRS extract (functional + non-functional requirements).
• Agile user stories.
• Peer validation feedback.
• Updated requirement after a change request.
