| Name | Use-Case |
| Abbreviation | USC |
| Learning Cost | 120 |
| Playing Cost | 300 |
| Suggested Phases | 1,2 |
Engineers
| Mechanical Engineer | Industrial Design | System Engineer | Electrical Engineer | Production Engineer | Software Engineer |
| ✗ | ✗ | ✔ | ✗ | ✗ | ✔ |
Technique and Issue Views
| BusinessNeeds | Stakeholder | Stakeholder Needs | System Requirements | System Structure Architecture |
| ✗ | ✔ | ✗ | ✔ | ✗ |
| System Functional Architecture | Detail Hardware Design | Detail Service Design | Detail Software Design | Manufacturing Operations |
| ✔ | ✗ | ✗ | ✗ | ✗ |
Technique Traits
| Identify Stakeholders | Elicit Needs | Remove Ambiguity | Layman's Terms | Technical Terms | Teamworkings |
| 2 | 2 | 2 | 3 | 4 | 2 |
| Traceability | Prioritizing | Exploring Breadth | Inside the Box | Outside the box | V&V |
| 2 | 0 | 0 | 0 | 0 | 0 |
Verification and Validation
| Analysis | Calculus | Inspection | Demonstration | Test |
| ✗ | ✗ | ✗ | ✗ | ✗ |
A use case is a list of actions or event steps typically defining the interaction between a role (or actor) and a system to achieve a goal (Wikipedia). In other words, it is a description of how a person who uses a process (or system) will accomplish a goal. It is typically associated with software and systems engineering but can be used in reference to any process [1]. A use case helps the developer understand where errors could occur in the process and understand the design features to resolve those errors. The use case was first introduced by Ivar Jacobson in 1987 [2] and used his technique at Ericson to come with requirements, “using textual, structural and visual modeling techniques to drive analysis and design” [3].
