UiPath Platform: The Backend Engine Powering Your Automation - Session 1
INCOSE 20100121
1.
2.
3.
4.
5.
6.
7.
8.
9.
10. Two domains Problem Domain Actor Needs Static Attributes (physical, documentation, user interface) Structural Attributes (architecture, configurations) Solution Domain Dynamic Attributes (functional requirements)
11. Use cases bridge the domain gap Problem Domain Actor Needs Static Attributes (physical, documentation, user interface) Structural Attributes (architecture, configurations) Solution Domain Dynamic Attributes (Use Case system responses) Use Case (actor steps)
Many of my examples are patient related since it is easy to show (and I’m familiar with patients). All of this applies to weapon systems, IT systems, etc. just as much as medical systems.
Who here has ever written or seen a use case for taking a tech support call by a Phone Support technician? This is actually a very important use case for medical devices. Tech support is the front lines of product surveillance.
Today, most top level documents are really high level System Requirements and not needs at all. They tell you what to build, not why. YOU need why to solve the problem correctly. If you don’t know the needs, you can’t make innovative trade offs as easily.
Before answering the why question, does everyone understand the concept of problem domain vs. solution domain? This can also be shown in a V-model where the top level is user needs system validation is the problem domain.
Importance of bridging the gap: enhanced probability of good product at the end
What actor performs those use case examples?
Point out that map can highlight reused use cases (e.g. clinician). Simple textual “story” style helps with non-technical contributors
Could give different phone numbers to different actor classes, or phone tree.