## 3 The Early Phase Project Scope Estimation Methodology
### Compiling Requirements List
#### 3.2.2 Reconciliation of Requirements
Identification of overlapping requirements is performed by calculating the degree of overlap expressed as a percentage, which depends on which parts of the requirement overlap. As there are four main parts in the requirement template (Actor, Action, Condition, and Context), overlapping can occur in any of these parts and their combinations. The analysis of the Action part constitutes the main weight in calculating the degree of overlap. If the verb in the Action part is identified as overlapping with the Action part of the other requirement, a 50% match is calculated. If the rest of the requirement parts (Actor, Condition, Context) match, that makes up the remaining 50%, dividing it for each requirements part accordingly. Each requirement can be assigned as overlapping with one or several other requirements. If the degree of overlap is less than 100% but greater than or equal to 50%, the overlap should be approved or rejected by the domain expert. Usually, if the degree of overlap is less than 50, it is ignored, unless the margin of ignoring the overlap is chosen to be smaller. After this phase, the team members have a list of requirements that reflects their opinion and knowledge of the subject area and scope of the project. The overlapping requirements are then removed from the list, leaving only one of them. When requirements from different sources are identified as overlapping, the decision must be made as to which one of the requirements must be removed. Additionally, the alignment of the sequence of requirements can be useful for the identification of overlaps. It involves sequencing the requirements in one context. The requirements transformed from UML Activity model are perfect for this, and can be supplemented by requirements from other models, requiring them to be sequenced. This is not a mandatory step, but it allows one to determine that there are no missed or redundant requirements in the process. Additional information such as non-functional requirements, technical, architecture requirements, or risks can be added to the requirement set as well. These do not directly reflect functionality; their existence may increase project costs and alter the schedule and the required number of resources; therefore, they should be incorporated into the requirements list. The reconciliation process has its challenges related to both the human-related aspects of team decision-making processes and to the technical side of identifying overlaps and synonyms. As domain understanding can vary between team members and the time allocated to domain analysis is extremely limited, conflicts can arise in the team while realigning requirements and deciding on the most relevant domain vocabulary terms. These conflicts require additional time for discussions and reaching a consensus within the team. From a more technical perspective, while the tool supports basic text analysis, the reconciliation of requirements mainly relies on individual expertise of the team members, and it requires an in-depth text analysis. At the same time, the analysis must also be performed under time pressure, which may hinder identification of the overlaps that are not apparent at first glance.