COMET - UML profile for requirements model
UML mapping
Structuring Concepts
|
Concept |
Extended Property |
Description |
UML Mapping |
Icon |
|
BCE analysis model |
A package that contains a BCE analysis model. |
Package <<BCEAnalysisModel>> | ||
|
Non-functional requirements container |
A package that contains the non-functional requirements |
Package <<Requirements>> |
|
|
|
Prototype |
A package that contains a prototype. |
Package <<Prototype>> |
|
|
|
Requirements model |
The model package that contains the requirements model. |
Model <<RequirementsModel>> | ||
|
System boundary model |
A package that contains a system boundary model. |
Package <<SystemBoundaryModel>> |
|
|
|
System vision |
A package that contains a system vision. |
Package <<SystemVision>> |
Modelling Concepts
|
Concept |
Extended Property |
Description |
UML Mapping |
Icon |
|
Boundary |
BCE Boundary. |
Class <<Boundary>> |
|
|
|
Control |
BCE Control. |
Class <<Control>> |
|
|
|
Entity |
BCE Entity. |
Class <<Entity>> |
|
|
|
Event role |
Used to model initiator of events, e.g. a timer. |
Actor <<EventRole>> | ||
|
Human role |
Specifies that this role is played by a human. |
Actor <<HumanRole>> | ||
|
Manage use case |
This is a type of use case that typically manages a Business Resource. E.g. in a meeting room example there might be a resource management use case performed by the Resource Manager role. The use case indicates handling the resources like room, equipment, participants etc. Will be transformed to CRUD operations in the AM. |
Use Case <<Manage>> | ||
|
Non-functional requirement |
Description of non-functional requirements. |
Class <<Requirement>> | ||
|
System role |
Specifies that this role is played by a system. |
Actor <<SystemRole>> |
|
|
|
Use case non-functional requirement include |
A dependency between a use case and a non-functional requirement |
Dependency <<includeRequirement>> |
Examples
Figure 1: Pilot Use Case Model – SurveyBooking
Figure 1 is an example of a use case model that uses the <<HumanRole>>, <<SystemRole>>, <<EventRole>> and <<Manage>> stereotypes.
Validation rules
|
Name |
MetaClass |
Description |
|
Check Use Case Scenarios |
Package |
Checks that each use case (recursively within the called package) has a primary scenario description.. |
|
Check Actors |
Package |
Checks that each actor (recursively) has a dependency to a business actor/resource. Checks that each actor has a description. |
|
Check Model Structure |
Package |
Checks the first level package structure of a requirements model. |
Predefined views
|
Name |
MetaClass |
Description |
|
Actors View |
Package |
Displays the actors of the package (not recursively), their descriptions and traceability link (Use link to the corresponding business actor/resource). |
|
System View |
Package |
Displays the top-level actors and use cases belonging to the selected system. |
|
Subsystem View |
Package |
Displays the child use cases belonging to the subsystems of the selected package. |
Examples
Figure 2: Actors View
Figure 2 shows an example of Actors View.
Figure 3: System View
Figure 3 shows an example of System View.
Figure 4: Subsystem View
Figure 4 shows an example of Subsystem View.