![Roles and Importance of Use Cases in Systems Engineering ,[object Object],[object Object],[object Object]](https://image.slidesharecdn.com/incose2010-01-21-100126221222-phpapp02/85/INCOSE-20100121-1-320.jpg)
![Hard-to-fix engineering issues ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommended
More Related Content
Viewers also liked
Viewers also liked (6)
Similar to INCOSE 20100121
Similar to INCOSE 20100121 (20)
Recently uploaded
Recently uploaded (20)
INCOSE 20100121
- 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)
- 14. Use Case map
- 24. First, describe Actor Steps…
- 25. … then add System Responses
- 26. Use Case Tracing
- 27. Questions? Good place to start: "Writing Effective Use Cases" by Alistair Cockburn
- 28. About William K. Day My email: [email_address] My website: http://williamkday.com/ My LinkedIn profile: http://linkedin.com/in/williamkday/
Editor's Notes
- Lack innovation? Frequent do-overs? Constantly changing requirements? Poor customer satisfaction? Regulatory nightmare?
- 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.
- Test environment (e.g. bomb range)
- MANY variations of this. Can use UML, etc.