The use case describes how an actor uses the system to perform a task. As a rule, actors represent different roles similar to those that users do in relation to the system, i.e. one person can use a system, acting in several various roles. The game “Brickles” has only one player who participates in its actual gameplay. We can postulate for the presence of one more Brickles’ actor, making him responsible for determining parameters values for the game when it is installed on different types of computers, for example, the speed of the hockey puck, the size of the initial supply of pucks, the color of brickles, puddles, pucks and playing area.
The specification does not say anything about such an actor, however, an experienced analyst always considers the necessity of existence some admin user of the system. Naturally, the person who installs the game “Brickles” on a system can be a player as well. (See [FoSb99j or [JCJ092] for an analysis of use cases.) An actor does not necessarily have to be a person, as it can be, for instance, another software system.
Are interested in the game tester job or you just need to test your favourite video game? Be informed that there is a game testing service available to ensure that any game works flawlessly on all device and OS platforms.
Use cases can be described in different levels of abstraction. For example, consider how a player hits high levels of the game “Brickles” (see Figure 1).
None of the use cases indicate how the player starts, pauses, resumes or terminates a match. Actually, none of them even explicitly mention the game “Brickles”. They can be used for many other arcade games. They have one and the same player, they both are tasked with the same responsibility to manipulate the game session, which is the object (or class) identified by us to represent the arcade game in progress. As such, we may consider them as domain level use cases. These use cases may be specified for the game “Brickles” (see Figure 2).
Use cases do not necessarily cover system usage for every requirement. Use cases are usually accompanied by additional descriptions or diagrams that include all the details (such as, for example, performance requirements) that are not clearly understandable to users, and interface requirements for subsystems that are hidden from these users.
Use cases are arranged in a hierarchy using two relations uses and extends. You can specify some use cases into sets of more specific use cases. The first four uses, shown in Fig. 2, are an extension of the use cases shown in Fig. 1. Such a structure helps to streamline what can be a large number of use cases. The search for a specific use case is accompanied by detecting a higher level use case that covers the conceptual scope of the particular case. The high level use case points at successively of more specific use cases.
Add Comment