All About Use Case Diagram

Requirements Engineering

The stages of Requirements Engineering is as below:

Stages:

• Inception
• Elicitation
• Elaboration
• Negotiation
• Specification
• Validation
• Management

What are some modeling principles?

The primary aim of the development team is to develop software, not to construct models.

• Travel light — do not build more templates than you need.
• Strive to generate the simplest model that explains the problem or program.
• Create models in a way that makes them adaptable to change
• To be able to state a specific intent for each model that is generated
• Get your reviews as soon as you can

Analysis of the ling approach

Structured Analysis:

Considers data and processes that turn the data into independent entities.

• Data objects are modeled to describe their attributes and relationships.
• Processes represent the transformation of data objects as they move through the system.
• Considers the data and processes that convert the data into autonomous entities.
• Data objects are modeled in order to define their attributes and relationships.
• Processes are the creation of data objects as they pass through the network.

Data Flow Diagram

Notations used to make DFD (Data Flow Diagram)

What is Data Flow?

What are data stores?

Properties of DFD

• Data Flow Diagram Focus on flow of data
• Data Flow DiagramShow ‘what’ and not ‘how’
• Data Flow DiagramConstructed top down
• It is Partitioned
• Data Flow Diagramdo not show sequence explicitly or separately
• Data Flow Diagram do not show iterations explicitly
• Data Flow Diagram do not show conditions explicitly

Partitioning in a DFD

Context diagrams

• Contains only one process/bubble reflecting the research domain
• Contains net device inputs/outputs and external entities

DFD 1st Level (Intermediate Levels)

• The refinement of the 0 stage DFD, partitioning takes place
• Data centers are being implemented
• Data flow needs to be balanced between rates

Unit names are different from level to level

DFD lower level (primitive level)

• Bubbles are ‘zooming in’
• Data flow needs to be balanced between rates
• Unit names are different from level to level

  Case Study

  Note: This is very first level in which maximum details are hidden. 

  Note: This is 1^st level DFD in which some of the details are prompted by the user.

  Note: This is the Primitive level DFD that shows each and everything with maximum details.

  What is the case and how to make use of e diagrams?

  Use cases are not Object-oriented but are an integral part of the unified process. Use cases are a commonly used mechanism for discovering and documenting requirements (especially functional) the use case model is the compilation of all use cases – the device features and environment model.

  Use cases are stories about the use of a goal-Ivar Jacobson introduced a summary of domain processes the concept of using cases to define functional specifications in 1986. For example anything with actions, e.g. an individual, a program, an organization.

  The scenario of the use case

  A basic sequence of actions and interactions between stakeholders and processes under discussion

  Format of use case

  Sample Case study

  Previously, The Air Ticket Sales System user interface is old-fashioned. The first release of the existing system took place in the century.ThetechnologyatthetimedidnotallowaGUI (Graphical User Interface).Thismustchangeinthenewsystem.Our highest priority for the new system is the interface clear, for the end-user.

  One of the major problems with our existing system is that it does not have any security measures and its vulnerability to attacks i.e.theadministratormusthavefullaccesstothesystemstock, the advisors will have access to their own stock and respective sales reports only. The office manager is also the only role that can generate all types of reports.

  Our existing system has some functional limitations, which make it difficult to use so our new software must rectify these mistakes. Someexamplesaregivenbelowtoillustratethis

  If arecordaboutasaleisassociatedwithaparticularUSDrate, which was oundtobeincorrect. With the current system, the only way to alter the record is to delete it first and then create it again with the correct rate in a very inefficient way.

  The new system must provide extensive functionality to allow Travel Agents to improve their relationship with these kinds of customers.

  Our new system provides the functionality of sell tickets by Advisor, cancel and buy tickets by Customer, give discounts by Travel agents, update and report stock, office manager can also apply commission rates and the generation of total sales report.

  How to make a use case diagram?

  The use case explains how a consumer uses a program to accomplish a particular objective. The use case diagram consists of the framework, the associated use cases, and the actors, and relates them to each other in order to visualize: what is described?

  (System), who is going to use the system, (Actors) and what do the actors want to do? (Use cases), therefore, use cases to help ensure that the correct framework is built by capturing the criteria from the user’s point of view.

  The use case is a list of actions or event steps that usually describe the interactions between the role of an agent and the mechanism to achieve the objective.

  Case usage is a valuable method for defining, clarifying, and organizing program specifications. The use case consists of a collection of potential interaction sequences between systems and users that describe the features to be introduced and the resolution of any errors that may be encountered.

  Although the use case itself can dig into a lot of detail (such as the flow of events and scenarios) about every possibility, a use-case diagram may help provide a higher-level view of the system. 

  Note: This is the use case diagram for the case study above

  Fully Formatted Description of the single-use case

  Use Case ID: UC1	Use Case: Make Sale
  Brief description: The travel advisor wants to make sales of tickets and this use case started with the success scenario and ends with postcondition.
  Primary Actor:  Travel Advisor
  Secondary Actor:  None
  Pre-Condition:  The system must be in a working state.
  Post Condition: Tickets Sales Report generated successfully, tax and commission rate can be calculated successfully.
  Main Success Scenario (or Basic Flow of Events): 1.      This use case stated when the company has been invited to develop a”forAirViaLtd. 2.      AirVia wants to sell tickets through the local Travel Agent companies. 3.      The Air Ticket Sales (ATS) system will keep records of tickets sold by a Travel Agent company to customers, and producethereportsrequiredbytheFinancialDepartmentofAirViaLtd.
  Alternative Scenario/Flow (or Extensions): 1.      The company has not invited to develop an “IT system to report sales of air tickets” for AirVia Ltd. 2.      AirVia did not sell tickets. 3.      The tax and commission cannot be calculated correctly and the sales report may not be generated correctly.

  Benefits of making use of case diagram

  Using cases is an effective strategy for eliciting and recording black-box functional criteria.

  Since the use of cases is easy to understand and offers an ideal way to communicate with consumers and users, as written in natural language.

  Use cases can help handle the complexity of large projects by splitting the issue into different useful features. A use case can define requirements from the user perspective.

  The use case scenario, often represented by a sequence diagram, includes the coordination of several objects and classes, uses cases to help define messages (operations and information or data required-parameters) that connect objects together.

  The use of cases is an appropriate technique to evoke and document black-box functional requirements. Since the use of cases is easy to understand and offers an excellent way to communicate with customers and users, as written in a natural language.

  Use cases can help handle the complexity of large projects by separating the problem into specific product features (i.e. use cases) and identifying specifications from the user perspective.

  The use case scenario, often described by a sequence diagram, involves organizing multiple objects and classes, using cases to help identify messages (operations and information or data required-parameters) that bind objects together. 

  Steps to identify use cases in the system

  • We should identify the Actors from the given case study
  • We should identify all-important users from the case study.
  • We should identify what users are needed by the program to achieve these goals.
  • Make Use cases for each target.

  Structure cases of use

  • Prioritize
  • Analyze
  • Estimate
  • Verify users.

   Note: The usage case explains how the actors use the process to accomplish a particular goal. The client typically implements use cases in order to fulfill the goals of the project and the differences involved in the achievement of the goal.

   > Use Case

   The time to use the > relationship is after you have completed the first cutout overview of all your key Use Cases. You can now look at Use Cases and recognize common user-system interaction sequences.

   > Use Case

  The extension of the use case is, in effect, an alternative course of the base use case. The >> use case does this by conceptually inserting additional action sequences into the base-case sequence.

  Major parts of the case diagram

  Actor

  Actors are typically individuals who are active in a structure identified by their positions. The actor may be a person or an external machine.

  Use Case

  The use case explains how the actors use the method to accomplish a particular objective. The customer usually introduces use cases in order to satisfy the aims of the operations and variations involved in the achievement of the aim.

  Relationship

  It is the relationships between the actors and the use cases from the scenarios.

  Further visit: 5 Best Challenges When Building On-Demand Applications

  System Boundary

  It is defined as the system boundary that defines the system of interest in relation to the scene around it.

  Mistakes to Avoid while making use cases

  Include User Interface Details

  By far the most common error we see in use cases is that they use the user interface language to speak about user actions.

  The use of user interface information contributes to confusion. This is counter-intuitive because “press the new account button” tends to be much more precise than “create an account.”

  However, often the name of the user interface feature does not clearly define the action the user is taking and therefore creates confusion about the exact move that the user needs in order for the program to be efficient.

  Not Specify a System Response to a User Action

  The next most common mistake we see, particularly from individuals with little exposure to information technology projects, is that the use cases are very process-oriented.

  The use case is clear about all the steps that the user needs to take, but the corresponding device action that needs to be taken in response to each user move is lacking.

  In the use case, just about every user move should have an acceptable user response or action. When it does not, the engineering team does not know what the program is going to do to keep up its end of the contract. This leads to conclusions being made or concerns being answered during implementation.

  Include Technical Details

  Another common error, which appears to come from more technologically trained experts, is that the use case requires technical specifics that are not needed to understand how the user interacts with the device.

  Different examples of technical information shall include:

  • Relevant data elements or tables.
  • Names of system elements that will not be apparent to the ordinary end-user of the program.
  • System-triggered processes or procedures that need to be performed.