## 3 The Early Phase Project Scope Estimation Methodology
### Compiling Requirements List  
When the workshop is finished, each of the participants in the project scope assessment has information that needs to be coordinated with the other participants. Information consists of lists of requirements, visual models, comments, and restrictions. Collecting and consolidating these requirements into the requirements specification is a complex process. This process is further complicated by the fact that people see and record different things while participating in the workshop. The consolidation process must ensure that their vision and understanding of the requirements are harmonized and allow a proper assessment of the scope of the project. Sometimes, for Scrum-based projects, only a Story map is created, but in most cases, it is not enough if one wants to have a clear picture of the scope. Therefore, other visual models should also be introduced. \begin{table}
\begin{tabular}{c c c} \hline \hline
**Source of Requirements** & **Analyzed Source Elements** & **Additional Recommendations for the Source** \\ \hline Story map & User, Epic, User story, Priority & Avoid design or technical constraints details. \\ \hline UML Use case model & Actor, Use case, Association, Include, Extend, Package & \begin{tabular}{c} Use Actors; \\ Group Use cases with Packages; \\ Avoid creating chains with more than one Include or Extend relationship. \\ \hline UML Activity model & \begin{tabular}{c} Swimlane (Activity Partition), Action, \\ Activity, Object Node, Object Flow, \\ Control Flow, Guard \\ \end{tabular} & \begin{tabular}{c} Use Activities to decompose complex processes; \\ Actions in the Activities should be of Use case level, \\ not going into the detail of the Use case internal \\ scenario; \\ Avoid creating an Activity hierarchy with more than \\ 3 levels; \\ Use Actors for representing Swimlanes; \\ Avoid specifying unnecessary exceptions, \\ concentrate on happy path scenarios; \\ Avoid different types of Actions, as differences do \\ not bring value in high-level requirements. \\ \hline UML domain (Class) model & \begin{tabular}{c} Class, Association (also including \\ composition and aggregation), \\ Enumeration, Package \\ \end{tabular} & \begin{tabular}{c} Identify a high-level picture (only domain entities \\ and their Associations);Group elements using \\ packages, if needed. \\ \end{tabular} \\ \hline Requirements list & ID, Actor, Name, Description, Priority, & \
\begin{tabular}{c} Define hierarchy using ID; \\ Group requirements by Category; \\ Use Actors. \\ \end{tabular} \\ \hline SysML Requirement model & Requirement, Package &
\begin{tabular}{c} Group requirements using packages if needed; \\ Form hierarchy, but not more than 2 levels, to avoid \\ too much detail. \\ \end{tabular} \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Requirements sources. The process of compiling requirements from various sources into requirements specification is presented in Figure 2. In our proposed process, when collecting requirements into the requirements specification, two options are possible: to analyze source models (Steps S1.1-S1.6) and gather requirements from them or to introduce requirements directly (Step S2). Since the process can be repeated as many times as needed, additional sources of requirements or manually added requirements can be introduced at any time. Five types of source models can be used to gather requirements: Story map, UML Use case model, UML Activity model, UML domain (Class) model, SysML Requirement model. Additionally, a simple Requirements list can also be used as a source. The order in which the source models are analyzed is not important, as the primary model is later selected to align the requirements. Once the source model is analyzed, the elements are identified, which can be used to form the requirements. Each model defines a certain set of elements which are chosen to ensure that the high-level information can be modeled and then transformed into requirements specifications.