ModellingClass T04
Requirements and Use CasesReferences:• http://www.sysml.org• http://www.omg.org
UML and SysML
2Modelação
UML – An overview…
3Modelação
SysML – An overview…
4Modelação
A Context Diagram(example for a HybridSUV system)
Modelação 5
ibd Automotiv eDomain [Automotiv eDomain] ...
driv er :Driv er
:Passenger
:Maintainer
«diagramDescription»
version="0.1"description="Initial concept to identify top level domain entities"reference="Ops Concept Description"completeness="partial. Does not include gas pump and other external interfaces."
HSUV :HybridSUV
«BlockProperty»
v ehicleCargo :Baggage
«BlockProperty»
«BlockProperty»
driv ingConditions :Env ironment
object :ExternalObject
«BlockProperty»road :Road
«BlockProperty»
weather :Weather
«BlockProperty»
Use Cases• Use cases describes an interaction between the system and other
external entity (an actor).
• The description must be provided from the point of view of the actor!
Therefore it describes "who" can do or is affected by "what" with or
from the system.
• The use case technique is used to elicit functional requirements by
relating them with usage/behavioral scenarios.
• In a document requirements the use cases can be presented before
the lists of requirements, as they can provide good glimpses…
• Use cases are also useful to make the bridge between the
requirements documenting and the modeling of the detailed
systems’ behavior
Modelação 6
High level use cases
Modelação 7
uc HSUVUseCases [TopLev elUseCases]
HybridSUV
Operate the v ehicle
Registered Owner
Insure the v ehicle
Register the v ehicle
Insurance Company
Department of Motor Vehicles
Maintainer
Maintain the v ehicle
Driv er
High level use cases
Modelação 8
uc HSUVUseCases [TopLev elUseCases]
HybridSUV
Operate the v ehicle
Registered Owner
Insure the v ehicle
Register the v ehicle
Insurance Company
Department of Motor Vehicles
Maintainer
Maintain the v ehicle
Driv er
Actors
Use Cases
uc HSUVUseCases [TopLev elUseCases]
HybridSUV
Operate the v ehicle
Registered Owner
Insure the v ehicle
Register the v ehicle
Insurance Company
Department of Motor Vehicles
Maintainer
Maintain the v ehicle
Driv er
High level use cases
Modelação 9
These actors might be the same object, but conceptually we must consider them independents
Modelação 10
Casos de Uso: Example of a templateName UC-8: Search
Summary All occurrences of a search term are replaced with replacement text.
Rationale While editing a document, many users find that there is text somewhere in the file being edited that needs to be replaced, but searching for it manually by looking through the entire document is time-consuming and ineffective. The search-and-replace function allows the user to find it automatically and replace it with specified text. Sometimes this term is repeated in many places and needs to be replaced. Other times, only the first occurrence should be replaced. The user may also wish to simply find the location of that text without replacing it.
Users All users
Preconditions A document is loaded and being edited.
Basic Course of Events
1. The user indicates that the software is to perform a search-and-replace in the document.2. The software responds by requesting the search term and the replacement text.3. The user inputs the search term and replacement text and indicates that all occurrences are to
be replaced.4. The software replaces all occurrences of the search term with the replacement text.
Alternative Paths
1. In step 3, the user indicates that only the first occurrence is to be replaced. In this case, the software finds the first occurrence of the search term in the document being edited and replaces it with the replacement text. The postcondition state is identical, except only the first occurrence is replaced, and the replacement text is highlighted.
2. In step 3, the user indicates that the software is only to search and not replace, and does not specify replacement text. In this case, the software highlights the first occurrence of the search term and the use case ends.
3. The user may decide to abort the search-and-replace operation at any time during steps 1, 2 or 3. In this case, the software returns to the precondition state.
Postconditions All occurrences of the search term have been replaced with the replacement text.
Driver’s use cases
Modelação 11
uc HSUVUseCases [Operational Use Cases]
HybridSUV
Driv er Accelerate
Steer
Brake
Park
Start the v ehicle
Driv e the v ehicle
«include»
«include»
«include»
«extend»
«include»
Driver’s use cases
Modelação 12
uc HSUVUseCases [Operational Use Cases]
HybridSUV
Driv er Accelerate
Steer
Brake
Park
Start the v ehicle
Driv e the v ehicle
«include»
«include»
«include»
«extend»
«include»
Driver’s use cases
Modelação 13
uc HSUVUseCases [Operational Use Cases]
HybridSUV
Driv er Accelerate
Steer
Brake
Park
Start the v ehicle
Driv e the v ehicle
«include»
«include»
«include»
«extend»
«include»
Complex use cases can be detailed in other diagrams…
SysML – An overview…
14Modelação
Requirements and Stakeholders
• Requirements– A requirement specifies a capability or condition that must (or
should) be satisfied.. A requirement may specify a function that a system must perform or a performance condition that a system must satisfy. Requirements are used to establish a contract between the customer (or other stakeholder) and those responsible for designing and implementing the system.
• Stakeholders– Anybody involved in the system’s lifecycle (analysis, design,
development, maintenance, …)– Anybody else who, directly or indirectly, may impose
requirements for the system (business owner, user, …)
Modelação 15
Types of requirements
Modelação 16
• Functional Requirements (FR)– The specification of a function of the system or its components.
– It must refer a behaviour of the system!
• Non-Functional Requirements (NFR)– It must refer how the system must behave.
– Examples of non-functional requirements: Performance; Scalability; Availability; Reliability; Maintainability; Serviceability; Security; Regulatory; Manageability; Usability; Interoperability
Requirements specification
Modelação 17
req HSUVSpecification [HSUV Specification]
HSUVSpecification
(from HSUVModel)
Eco-Friendliness
Braking
FuelEconomy
OffRoadCapability
Acceleration
Ergonomics
Qualification
Safety Test
PerformanceCapacity
Cargo Capacity
Passenger Capacity
Fuel Capacity
Emissions
Requirements derivation
Modelação 18
req HSUVRequirements [Requirement Deriv ation] ...
«rationale»
Power delivery must happen by coordinated control of gas and electricmotors.
«problem»
Power needed for acceleration, off-road performance & cargo capacity conflicts with fuel economy
PowerSourceManagement
Fuel Capacity
(from HSUVSpecification)
OffRoadCapability
(from HSUVSpecification)
Acceleration
(from HSUVSpecification)
Cargo Capacity
(from HSUVSpecification)
FuelEconomy
(from HSUVSpecification)
Range
RegenerativeBraking
Braking
(from HSUVSpecification)
«RefinedBy»
HSUVStructure::HSUV.HSUVOperationalStates
Power
«derive»
«derive»
«derive» «derive»
«derive»«derive»
«derive»
«derive»«derive»
Requirements in the Enterprise Architect…
Modelação 19
VERY IMPORTANT:
Be aware that EA tool supports
requirements diagrams as
formal SysML Requirements
Diagrams
or as
informal requirements diagrams
as extensions to UML
Requirements containment
The containment (cross hair) relationship refers to the practice of decomposing a complex requirement into simpler, single requirements.
Modelação 20
Copy relationship
A Copy relationship is a dependency between a supplier requirement and a client requirement that specifies that the text of the client requirement is a read-only copy of the text of the supplier requirement.
A Copy dependency created between two requirements maintains a master/slave relationship between the two elements for the purpose of requirements re-use in different contexts. When a Copy dependency exists between two requirements, the requirement text of the client requirement is a read-only copy of the requirement text of the requirement at the supplier end of the dependency.
Modelação 21
Callout relationship (notes)
A callout notation can be used to represent derive, satisfy, verify, refine, copy, and trace relationships…
Modelação 22
DeriveReqt relationship
Modelação 23
A DeriveReqt relationship is a dependency between two requirements in which a client requirement can be derived from the supplier requirement.
For example, a system requirement may be derived from a business need, or lower-level requirements may be derived from a system requirement.
As with other dependencies, the arrow direction points from the derived (client) requirement to the (supplier) requirement from which it is derived.
Verify relationship
A Verify relationship is a dependency between a requirement and a test case or other model element that can determine whether a system fulfills the requirement.
Modelação 24
Satisfy relationship
A Satisfy relationship is a dependency between a requirement and a model element that fulfills the requirement.
Modelação 25
Refine relationship
The refine requirement relationship can be used to describe how a model element or set of elements can be used to further refine a requirement.
For example, a use case or activity diagram may be used to refine a text-based functional requirement. Alternatively, it may be used to show how a text-based requirement refines a model element. In this case, some elaborated text could be used to refine a less fine-grained model element
Modelação 26
Trace relationship
A generic trace requirement relationship provides a general-purpose relationship between a requirement and any other model element. The semantics of trace include no real constraints and therefore are quite weak.
As a result, it is recommended that the trace relationship not be used in conjunction with the other requirements relationship...
Modelação 27
Relating requirements with other elements
Modelação 28
Use Cases
Modelação 29
Use cases and requirements
Modelação 30
Traceability
Traceability Diagrams
Modelação 31
Relationship Matrix
A fundamental technique in modelling to relate decisions with their origin or implications
Traceability in the Enterprise Architect tool