To Manage requirement changes and updates throughout the requirement engineering phase, the following structured change control process will be followed:
Change Request Submission
Any stakeholder (e.g., student, instructor, developer) who wants to add, modify, or remove a requirement must submit a formal change request. The request should include:
A clear description of the proposed change. The reason for the change. A list of requirements potentially affected.
Review and Evaluation
Our team will review the submitted change request and evaluate:
Whether the change is necessary or beneficial. Its impact on the system's functional and non-functional requirements. We use Traceability Matrix 1 to check dependencies between requirements and Matrix 2 to assess which use cases are involved
Feasibility Assessment
Our team will review and analyze the feasibility of the proposed change by evaluating the cost, required effort, and overall impact on the system. The aim is to determine whether the change is technically, operationally, and economically feasible. It considers:
Whether the existing system architecture and technologies can support the change Whether the change aligns with user needs and expectations An estimation of implementation costs versus expected benefits The ability to deliver the change within an acceptable timeline
Decision and Documentation
This step ensures that the team formally documents the outcome of the change request process, whether the change is approved or rejected. The decision is based on the results of the prior feasibility analysis and alignment with stakeholder needs and project goals. Even if no change is implemented, the rationale behind the decision is recorded. If approved, the change is documented, relevant system artifacts are updated, and any dependencies are reviewed to identify further required modifications. This ensures traceability and clarity for future reference.
Versioning
Approved changes are incorporated into the system with updated version numbers to maintain a clear history of modifications and ensure traceability.
Example Change and impact Assessment
Proposed change
Enhance the mentorship feature to include scheduling functionality to allow students to view mentor availability and book mentorship sessions directly within the app.
Reason for change
Without having the scheduling feature it is hard and time consuming to coordinate sessions. If we add a scheduling feature where students can see when mentors are free and book directly, it would make the process much easier and encourage more students to actually use the feature.
Affected Requirement
F44: The system shall provide a mentorship feature that connects students with experienced mentors who can guide them in launching and managing social impact projects.
Functional Impact:
Students will have access to view available time slots and make bookings Mentors will need functionalities to define and update their available time slots A new scheduling module must be developed and integrated within the mentorship feature. The system should prevent double bookings
Traceability Matrix Check:
F44: The system shall provide a mentorship feature that connects students with experienced mentors. Dependencies: The scheduling feature will rely on existing functionalities within F43, which connects students with mentors based on their interests.
Technical Impact:
Update the mentorship module to include a scheduling system that manages available time slots.
Enhance the database to store availability and bookings for mentors and students.
Implement logic to prevent double bookings and ensure accurate scheduling.
Testing Impact:
Update test cases to validate that:
Students can view available time slots accurately. Booking sessions updates the mentor's availability correctly. The system prevents double bookings and notifies users appropriately.