Use Case Diagram. Unified Modeling Language is the modeling toolkit used by BA to build diagrams.Use case diagram is the primary form of system requirements for a new software program under developed. What is use case Diagram: Use case diagram gives us the picture of who is using the system and its functionality. Use case diagram is dynamic in nature by depicting the behavior of the system. It will summarize the details of the system's users (actors), use cases (functionalities), and the relationships between them. In simply we can say use case diagram will describe and represent how the user will interact with the systems. Use case diagram will be structured and organized from the perspective of actors who are interacting the system. When to apply: Use case diagram depicts a high-level overview of relationships between actors, use case and systems. It will not give the details of the system by model the order of steps which are going to be performed next. The main purpose of the use case diagram is to identify and gather the requirements of a system including internal and external influences. Use cases and actors are identified an dprepared while gathering the functinalities for the system. That's why use case diagrams are mainly based upon functionality and focused on the "what" and not the "how". Actors are represented by stick figures, use cases by ovals, and relationships by connecting lines. Use case diagrams won't describes how the system is implemented instead of that it will specify the events of a system and their flows by relationships. Although use case is not a good candidate for forward and reverse engineering, still they are used in a slightly different way to make forward and reverse engineering. Use case diagrams are easy to understand and due to the simplistic nature, use case diagrams can be a good communication tool for stakeholders. Use case diagrams are mainly for: *Representing the system-user interaction. *Models the basic flow of the system. *Focus on the main requirement of the system. *Show the outside view of the system. *It will identify and organize the functional requirement. *Identifying the external and internal factors influencing the system. What all are the Components: The common components include actors, system, and use case. Actors: *The users who interact with a use case (system function). *An actor can be a person, or some internal or external applications that interacts with the system. *We should give suitable and named by noun. *Actor plays a role in the business. *Actor has responsibility toward the system (inputs), and Actor have expectations from the system (outputs). How to Identify Actor: Answers for these questions will be helpful to find the actors: *Who uses the system? *Who gets information from this system? *Who provides information to the system? etc. By answering to these questions we will be able to identify the actors. System: *Itself (rectangular block) that sets a system scope to use cases where the sequence of actions and interactions between actors and the system are take place. *Entire system as defined in the requirements document. Use case: *System's functions. *Name of use case should be chosen very appropriately because its going to represent the functionalities performed. *Each Actor must be linked to a use case, while some use cases may not be linked to actors. How to Identify Use Cases: The following questions can be asked to identify use cases: *What functions will the actor want from the system? *What actors will create, read, update or delete this information? *Does the system need to notify an actor? Associations: *The participation of an actor in a use case is shown by connecting a actor to a use case by a solid link. *It show relationships and dependencies clearly in the diagram. *It is indicating that the actor and the use case communicate with one another using messages. Notes are also available, Whenever required we can use notes also to clarify some important points. What are the Use Case Relationship: There are mainly three use case relationships, extend, include and generalization. We specify these relationships in the diagram according to their needs. Extends: *Extend is a directed relationship that specifies the behavior defined in usually supplementary (optional). *Depict with a directed arrow having a dotted line. *Has at least one explicit extension location. *Could have optional extension condition. Include: *Included use case required, not optional. *No explicit inclusion location but is included at some location. *No explicit inclusion condition. Generalization: *Generalization is shown as a directed arrow with a triangle arrowhead. *The child use case is connected at the base of the arrow and the tip of the arrow is connected to the parent use case. *It is a parent-child relationship between use cases. *It is an enhancement of the parent use case.
What is the requirement elicitation? Have you ever participated in these elicitation meetings?
Introduction Requirement elicitation is a critical process in the field of business analysis. It involves …