UML models and other notations (IE, IDEFx, and so on) are used to model the technical structure (design) of the system being designed. Such models can refine functional and non-functional requirements; however, when there are a large number of elements, working with them becomes extremely inconvenient. Moreover, design elements can have many specific characteristics that need to be recorded, used, and analyzed.
Use the "Components" module to store and track design elements of the system being designed. This is a hierarchical view of design elements such as logical or technical subsystems, modules, entities, objects, and so on. The "Component type" reference list lets you define the set of design elements you use. With the Settings — Attributes module you can define additional custom attributes that are specific to individual component types or common to all component types.
Child components can be created in other projects, so a sprawling design hierarchy can be spread across several projects (project teams).
You can import components from external sources, for example Excel. If you fill in the UID field in Excel, the component identification scheme that existed on import from Excel is preserved after import.
A link to the source requirements lets you document important requirements imposed on design elements. The link between components and requirements is "many-to-many". Linking Enhancements (User Stories) to components lets you document how implementing these requirements affects specific components (design elements) of the system.
For easier communication, create diagrams that show the selected components and the links between them. For the notation you can choose a class diagram or a component diagram. The diagram kind can be set for a specific component type.
A diagram can be inserted into a requirement using the "Insert module/report" module. The diagram elements are clickable and let you jump quickly from the requirement to a specific component.
When you use the "Budgeting" module, you can set a price for a component which, taking the components in use into account, forms the cost. The "Budget" module has a separate item that sums the cost of the solution's components. This matters when the technical solution uses external paid components or technical devices (servers, other computing equipment, or electronic elements). Accounting for the cost of these components helps you plan the project budget better.
The cost of components that contain nested (child) components includes their cost.
You can define your own component identification scheme, different from the one used by the system by default. To do this, open the settings of the "UID" attribute and set a formula there for calculating the default value. Read the Project settings section for more about custom identification settings.
You can define your own scheme for identifying artifacts, different from the one used in the system by default. To do this, open the settings of the "UID" attribute and set a formula there for calculating the default value.
As the formula for calculating the Requirement identifier, write an expression following the example from the description. Here are several variants of custom identification of Requirements:
You can form an identifier using leading zeros; for example, given the expression {Id,6}, the system forms the identifier as 000001, 000002, and so on.