![]() ![]() ![]() In this case, we consider the customers to change their PIN through ATM as a use case. As long as it is a business goal that the business stakeholder want the target system to achieve, it is a use case. Wouldn't 'change pin' be too small to be a use case? The answer is: the identification of use cases is neither based on the amount of work the user need to do, nor based on the number of system functions to develop. 'Login' itself does not yield any observable result - no one would just login an ATM and go away, right? So, we do not consider 'login' as a use case. Here, 'login' is only a part of the other operations. They yield an observable result to the actor who interact with the system to achieve the use case. As said, use cases are business goals to be achieved. You may wonder why there isn't a use case for 'Login', which is an inevitable step of all ATM operations. Record workout, produce workout statistic, challenge a goalīased on the examples above, we might then have the following discussions: Use Case Yields Observable Goal ATMĪTM is a classic example when explaining the concept of use case or use case analysis. Withdraw cash, transfer money, donation, settle bills, change PIN The rule of thumb for the use case identification process is always be the result of active participations and involvements with the business stakeholders. The example given here is just for illustration purposes, there is no definite way as to what use cases should be identified for a particular target system. ![]() Here are some examples to illustrate the usage of use cases. Proposed software features can be planned based on the importance of the use cases, instead of solely depending on the opinions of the front-line stakeholders, which may not be fully aligned with business owner's expectation. Besides, use cases also facilitate meaningful categorizing of requirements. By finding requirements based on use cases, the requirements are highly likely to be within system scope and thus achieving the business values expected by the owners. Due to this reason, use cases directly reflect what the business goals the target system has to achieve. Keep in mind that use cases are found by communicating with business owners and senior executives who oversee the growth of their companies and have the ability to make strategic business decisions. A use case could be served as a placeholder for accommodating a group of related user stories which share a larger and shared business goal and scope among them. When you are going to develop a large scale system which typically involve a lot of stakeholders who have different expectations on the final system, ending up a large collection of requirements in an unmanageable manner. They would rather go straight into identifying system requirements. Many people see the identification of use cases a redundant step. Thus, the use cases identified are all aligned with the business values, needs and strategy of the company. They also have the authority and information required for making business decisions. It is important to identify use cases with business stakeholders but not someone else, as they are clear about the directions and actual operations of the company. We use to call them the business stakeholders. Use cases are found by communicating with business owners or the senior executives of the company. In reality, a role can be played by different person and, conversely, a person can play multiple roles. Note that an actor does not necessarily represent a specific physical entity (e.g. The occurrence of interaction between an actor and a use case is represented by an association (link). Besides use case, a typical use case diagram contains two more elements - actor and link.Īn actor is a role that interacts with the system to achieve one or more business goals as represented by the use cases. A use case is shown as an ellipse in diagram, with its name appear in the middle of the shape. Use Cases can be visualized in a UML Use Case Diagram. In fact, capturing of requirements would be done after the identification use cases (epics) and subsequently spitting into a set of corresponding user stories (business goals). In fact, it is important to stay use cases away from requirements because you need a clear set of use cases that helps you define business goals and system scope. Use cases are neither system requirements nor the functions to be implemented. A use case represents a high level business goal to be achieved by someone, some parties, or some sub-systems through interacting with a system, which can be the system under developed, or the system to maintain, depends on the nature of your software project.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |