6-8 minutes<\/p>\n
A Use case has been viewed as a mechanism to capture system requirements in terms of the uses of the system which specifies the expected behavior (what), and not the exact method of making it happens (how) of a system and thus, it is a black-box view of the system; it is therefore well suited to serve as a system context diagram.<\/p>\n
Use cases once specified can be denoted both textual and visual representation (i.e. use case diagram). A key concept of use case modeling is that it helps us design a system from the end user\u2019s perspective. It is an effective technique for communicating system behavior in the user\u2019s terms by specifying all externally visible system behaviors.<\/p>\n
A standard form of use case diagram is defined in the Unified Modeling Language as shown in the Use Case Diagram example below:<\/p>\n
Association Link<\/p>\n
A Use Case diagram illustrates a set of use cases for a system, i.e. the actors and the relationships between the actors and use cases.<\/p>\n
The include relationship adds additional functionality not specified in the base use case. The <> relationship is used to include common behavior from an included use case into a base use case to support the reuse of common behavior.<\/p>\n
The extend relationships are important because they show optional functionality or system behavior. The <> relationship is used to include optional behavior from an extending use case in an extended use case. Take a look at the use case diagram example below. It shows an extend connector and an extension point \u201cSearch\u201d. <\/span><\/p>\n A generalization relationship means that a child use case inherits the behavior and meaning of the parent use case. The child may add or override the behavior of the parent. The figure below provides a use case example by showing two generalization connectors that connect between the three use cases. <\/span><\/p>\n Often, people find it easiest to start the requirements elicitation process by identifying the actors. The following questions can help you identify the actors of your system (Schneider and Winters \u2013 1998): <\/span><\/p>\n Use case granularity refers to how information is organized within use case specifications, and to some extent, the level of detail at which they are written. Achieving the right level of use case granularity eases communication between stakeholders and developers and improves project planning. <\/span><\/p>\n Alastair Cockburn in Writing Effective Use Cases gives us an easy way to visualize different levels of goal level by thinking in terms of the sea: <\/span><\/p>\n The use case diagram for \u201cDrive Vehicle\u201d in Figure 5 depicts the drive vehicle usage of the vehicle system. The subject (Hybrid SUV) and the actors (Driver, Registered Owner, Maintainer, Insurance Company, DMV) interact to realize the use case.<\/span><\/p>\n","protected":false},"excerpt":{"rendered":"Generalization Relationship <\/span><\/h3>\n
How to Identify Actor<\/span><\/h3>\n
\n
Levels of Details<\/span><\/h3>\n
Top Level Use Cases <\/span><\/h3>\n