## 3 The Early Phase Project Scope Estimation Methodology
### Compiling Requirements List
#### 3.2.1 Compilation of Requirements from Various Sources
If an Extend relationship exists between the Use cases, both the extending and the extended Use cases are appended to list as separate items, and the extension related information is incorporated into the list item as a comment, formulated as follows: for the extended Use case \"is extended by <extending Use case.name>\"; for the extending Use case \"extends <extended Use case.name>\". The transformation of the UML Activity model into Requirements (Figure 6) also starts with exporting the model information to the list and further analyzing the list items consecutively. Any type of Action from the Activity model is appended to the list, but initial and final Activity nodes are not analyzed. Information about Action sequence is extracted from incoming and outgoing Control Flows for each Action and is included in the Requirement attributes as previous and next. If the Action has incoming or outgoing Object flow, it must be connected to the Object node. The Object node name is treated as Object node type. If the list item (Activity model Action) has incoming Object Flow, the Requirement Action text is formed as follows: \"<Action> with input(s): <Object Node.name>\". If the Activity model Action has an outgoing Object Flow, the Requirement Action text is formed as follows: \"<Action> with result(s): <Object Node.name>\". If the Action is in the Activity Partition (Swimlane), the element, which represents the Swimlane is transformed to the Actor in the Requirement. The Guard of the incoming Control Flow of the Action is used as a Condition element of the Requirement. Action may have priority and sequence information that is stored in the attributes of the Requirement. The Activity or the Package, where the Action is contained, is transformed into the context of Requirement, but if both Package and Activity are present, Activity is used to denote the Context. The UML Class model can be used as a source of Requirements if it is used for modeling domain concepts and their relationship. The transformation of the UML Class model to Requirements is presented in Figure 3.1 While forming the list from the Class model, Associations between Classes are appended to the list and then transformed into Requirements. These Requirements do not have an Actor element, only Action and Context elements. Classes that are not connected with Associations are not analyzed, but Enumerations are included, even if they are not connected with Associations. For each Association and its two connected Classes C1 and C2, a Requirement is created, where the list item part further transformed into Action is formed as follows: \"<C1.name> <Association.name> <C2.AssociationEnd.Multiplicity> <C2.name>(s)\". If the name of the Association is not defined, the word \"has\" is used instead. The reading direction of the Association is from the lesser multiplicity number to the greater or by the Association direction if it exists. If the Association type is aggregation or composition, the Action text is formed as follows: \"<C1.name> consists of <C2.AssociationEnd.Multiplicity> <C2.name>(s)\", where C1 is the Class with the aggregation or composition end of Association. If Enumerations exist in the source model, they are appended to the list as separate items. The Action part of this item is formed using the Enumeration and its literals: \"<Enumeration.name> can have values: <enumeration literals>\". The transformation of the Requirements list to Requirements is presented in Figure 3.2 Requirements list is a simple textual list, it does not need to be exported and is analyzed as is, going through all its items consecutively. The Requirements list item may have Priority, which is transformed to the Requirement priority attribute and description that is transformed to the comment attribute of the Requirement. A hierarchy in the Requirements list is stored in the ID of each list item.