So how do you handle CRUD in your use cases? Please don’t confuse CRUD with CRAP in your use cases. That’s a lot harder to deal with and requires a conversation with your subject matter experts (SMEs). CRUD is an acronym for Create, Read, Update and Delete. It describes the lifecycle in the maintenance of system data, whether that data is stored in a database or is file based data stored in a document management system like SharePoint.
In the world of software development Use Cases are one of many very powerful techniques often used these days. Use cases describe how a person or a system interacts with the solution being modeled/built to achieve a goal. Basically, it’s a step by step explanation of what a user can do and how the solution must respond.
As any other business analysis technique, use cases have their advantages and disadvantages. One of the main disadvantages of use cases is that this technique is not graphical – a use case diagram is but use case descriptions are not, and use case descriptions really lack of visualization especially if there are multiple alternative flows and exception flows that branch out and then loop back into the main one.
Visual analysis models provide a powerful set of tools that let business analysts depict system information at various levels of abstraction. These models serve as an aid to understanding, as well as an aid to communicating. Alas, I fear that modeling is somewhat of a neglected practice. I believe modeling is an essential skill every BA should master. Here’s why.
Several years ago I was looking for examples using the generalization / specialization technique with use cases. They are not easier to find. And they are typically limited to a use case diagram like the two below. This article provides examples of both the diagrams and the scenarios for a future gas station business.
Project Scope. We will see how scope statements, when making reference to business functionality, lead directly to High-Level requirements. Gathering requirements for a business information system is most often done within the context of a project. Approval of a project includes its sponsors signing off on its scope. The scope for a business information system project is typically defined in functional terms. Items in scope make reference to (or should make reference to) business functions, processes and/or activities that are to be delivered.
The problem with many Unified Modeling Language (UML) educational texts is that they present the various concepts each in isolation; so you see a use case diagram for one problem domain, a class diagram for an entirely different problem domain, and you never get to see the important traceability between the diagrams.
In this case study we aim to put it right by working through a single problem from use cases and activity diagrams, through sequence diagrams and state diagrams, to class diagrams and component diagrams. We have arranged the case study as three distinct perspectives or aspects as follows.
The UML Component Diagram along with the complementary UML Deployment Diagram shows how a software solution will be delivered and deployed in the form of interconnected components that interoperate via well-defined interfaces. You can think of this as analogous to how electronic components are wired together, and in this context you should consider that any one component may be replaced by a different but compatible component with no adverse effect.
A UML Use Case is an atomic system function with a well-defined and standardized specification, which is performed by or o behalf of a system user or ‘actor’. This article describes how a UML Use Case Specification should be written.
A typical business function might contain several unique events each of which we want to end up as a component of a larger software application. So how do we go from a table containing textual information to a specification which a developer can use?
This article discusses Stephen King’s creative writing method and provides an example of using it in developing a use case narrative: the main scenario with alternate and exception paths. Yes, that is correct – Stephen King, the prolific writer of contemporary horror, science fiction and fantasy novels.
The UML Class Diagram, sometimes known as the Static Structure Diagram, shows the dependencies and persistent associations between object classes.
brought to you by enabling practitioners & organizations to achieve their goals using: