Tool for Business Evaluation – Use Case Diagrams
Jane goes to the Site of Fit For Me. She logs into her account by offering her user name and password. Website exhibits her personal page. Sidebar on the left has connections for her dimensions, her current orders and Billing History. On the top center, she sees ‘New Arrivals’ with icons of outfits from her favorite brand. Jane enjoys a cute dress and clicks on it. System requires her to ‘personalize’ page and shows standard dimensions and ‘Jane’s dimensions’ with dimensions pre-populated according to her profile dimensions. Jane checks ‘her size’ option, selects pretty pink color and strikes checkout button. The entire experience of selecting and ordering a ‘tailor-made’ outfit has taken 2 minutes.
This is an illustration of a Use Case for ‘Select Custom-made dress’ scenario. A pictorial representation of the identical situation is a Use Case Model. Use Case models and Use cases are powerful tool s in a Business Analyst is tool-kit. Origin of use cases is attributed to Swedish computer scientist Dr. Invar Jacobson, who’s also considered father of Unified Modeling Language (UML) and Rational Unified Process (RUP). Dr. Jacobson gave the title Use Case in 1986 and it became an integral part of operational requirements specification by nineties; particularly in emerging Object-Oriented methodology of software development.
A Use case represents An interaction between one or more actors and the system through various processes. The cbap training interaction is described concerning the actions to be taken by the celebrity or response received from the system. A Use case is always in the context of a system. Any interfacing module or system can be represented as a celebrity. Use Case Model Building Blocks: An Actor represented as a individual, A use case, represented with an oval, a system represented as a square and lines to reveal activities or interactions are crucial building blocks of a use case diagram.
Dependencies: Contains and Extends Different use cases within a module may have dependencies or relationships. There are two important dependencies – Contains or Extends. A use case includes or uses another use case when the 2nd use case is called at least once for the initial use case. By way of instance, for the check-in use case, assign chair and weigh bags will probably be just two of the ‘Include’ use cases. A use case extends another use case when it adds particular value to parent use case. Assign seat can be extended by means of a use case ‘Assign window seat’. In our case, Extend and Contains can be depicted as:
