## 3 Proposed Framework
### Integrated Prioritization Module (IPM)
#### 3.2.1 Grouping Processing Unit (GPU)  
Once the implementation module receives the requirements, they are moved to the GPU. The GPU groups these requirements based on resource availability, importance, and development. The classification is divided into four groups: Preliminary, Group 2, Group 3, and Final. Each category can store a maximum of 12 requirements, and the maximum number of requirements is limited within every category (such as 25% requirements). The 12 \(\times\) 12 matrixes can be easily handled in AHP Engine. By allowing a small amount of time, more requirements are met. For instance, if we have fifty requirements instead of 50 \(\times\) 50, there would be four 12 \(\times\) 12 matrices. It is easy to perform cross-assessment of 12 \(\times\) 12 matrices. The limit of 12 requirements per group in our framework is strategically set to manage the complexity and computational efficiency within the AHP. AHP necessitates pairwise comparisons, within which the number of comparisons increases quadratically with the number of items. Specifically, for n items, the number of required pairwise comparisons is n(n \(-\) 1)/2. By capping each group at 12, the pairwise comparisons are kept to a manageable 66 per group, which significantly enhances the computational feasibility of the AHP, ensuring that the prioritization remains both manageable and effective without overwhelming the system or the analysts. When the number of requirements exceeds 50, the FIFO approach is employed to ensure that the processing of requirements remains systematic and timely. This method is particularly useful in dynamic environments typical of IoT applications, where requirements can frequently accumulate. FIFO facilitates a fair and orderly processing sequence, ensuring that older requirements are addressed before newer ones, and thus preventing any requirement from being indefinitely postponed or ignored. However, these methods come with their potential risks and limitations. While the 12-requirements cap aids in simplifying the prioritization process, it might lead to oversimplification, particularly when there are complex interdependencies between requirements that might span across different groups. This could potentially dilute the precision of prioritization if significant interdependencies are overlooked. Moreover, while FIFO promotes fairness and systematic processing, it could also result in delays for requirements that enter the queue later, particularly if there is a continuous influx of new requirements. This might slow down the response to urgent or evolving needs if not adequately monitored and managed. The requirements from RR are moved to the categories (Preliminary Group, Group 2, Group 3, and Final Group) in the following manner:  
* The first 12 highly important REQs are sent to the Final Group;
* Subsequently, 12 important REQs are shifted to Group 3;
* The next 12 major REQs are sent to Group 2;
* The last 12 significant REQs have been moved to the Preliminary Group. This means that the GPU initially performs grouping without calculation. The initial grouping is performed based on expert opinion, and the proposed system has nothing to do with the initial grouping level. The movement of requirements between groups in our dynamic prioritization process is a carefully considered strategy designed to adapt to the evolving criticalities and dependencies of requirements identified during the review phase. This flexibility is essential in IoT environments, in which project scopes and stakeholder needs can change rapidly. We acknowledge that such movements could potentially disrupt the balance of groups in terms of their requirements capacities. To ensure that the prioritization accurately reflects the most current evaluations of each requirement's importance and urgency, movements between groups are allowed in order to align the groups with the latest insights. To manage the balance of groups after such movements, we have implemented a specific balancing mechanism within our algorithm.