## 3 The Early Phase Project Scope Estimation Methodology
### Compiling Requirements List
#### 3.2.1 Compilation of Requirements from Various Sources  
Compiling the requirements into a requirements specification is a step that allows the team to start a discussion about the scope of the project. The main problems encountered at this stage are the incompatibility of terms and the omission of functionality. Irrespective of the competences of the team members, the joint contribution makes it possible to manage the mentioned risks more effectively. Figure 2: The process of compiling requirements and estimating scope. Each model used as a source of requirements has its own list of elements (defined in Table 1) that participate in the formation of a requirement. However, the principles of how the requirement is formulated are common to all models. The template by which the requirement text is formed is as follows:  
[_<Actor>_] [can <Action>_ [if <Condition>]] [in <Context> context]. The text colors can be used for easier identification of the elements of requirement: Actor is written in blue, Action in green, and Context in red font. The main elements of the Requirement template, the additional Requirement attributes, and the sources of Requirements are presented in the metamodel in Figure 3.  
All elements of the Requirement template are optional, but at least one element of Actor, Action, or Context type must exist to form a Requirement. In the template, the <Action> element text is not always straightforwardly mapped from the source model, as it can be formed from several elements of the model. Additionally, the Requirement may have information about the priority, comment, owner (for identifying hierarchy), and previous and/or next elements (for identifying sequences). This information is extracted from source models where it is available. The algorithms for forming the Requirements from source models are presented in Figures 4-9. Figure 4: Algorithm for Story map transformation into Requirements. Figure 3: Requirements metamodel and related source models. Figure 5: Algorithm for UML Use case model transformation into Requirements. Figure 6: Algorithm for UML Activity model transformation into Requirements. Figure 7: Algorithm for UML domain Class model transformation into Requirements. Figure 8: Algorithm for Requirements list transformation into Requirements. Figure 9: Algorithm for SysML requirements model transformation into Requirements. The Story map transformation to Requirements is presented in Figure 4. The Story map is analyzed as a text input, which contains information about Users, User stories, and Epics. Additionally, User story may have priority information, which is later stored in Requirement attribute. During the transformation, the input is exported to the list, and the list elements are analyzed one by one, transforming them into Requirement elements and attributes: Actor, Action, Context, and priority attribute. The UML Use case model is transformed into Requirements according to the algorithm in Figure 3.0 The algorithm starts with exporting the model input into the list, which is further analyzed. While forming the list, for each actor, Use cases connected to it with Association are analyzed. Each Use case with its related Actor and its containing Package (if it exists) are appended to the list as an item. Use cases that are not connected with an Actor, are also analyzed and added to the list, but such list item has only the Use case element and (if exists) the Package element. Use case model Packages that do not have included Use cases are also added to the list as separate items, but these items do not have Actor and Use case elements. If an include relationship exists between the Use cases, only the including Use case is appended to the list as a separate item, but then the list item Use case part (which is further transformed into the Requirement Action) is formulated as follows: \"<including Use case.name> including <included Use case.name(s)>\".