What is Use Case?

Use case represents requirement in the form of user interactions with the system. Use case is always written with a specific user goal in mind. Each use case must contain an actor and verb. For example, ‘online buyer’ is an actor and ‘add item to cart’ is a verb.

A use case diagram represents the scope of all the features of the solution. It follows Unified Modelling Language™ notation. Use case diagram comprises of several use cases that make the system altogether.

What is User Story?

User story is a business analysis artifact that is also user or persona driven. It describes the business need in the form of an ability user (or system) wants in the solution. It also must state why the ability is required and what the benefits of that ability are. It does not have any mandatory format though

User story is part of the (product/project) backlog. The backlog in turn contains user stories/tasks (requirements) in a linear fashion. Backlog is usually prioritized from high to low, additionally with a ranking when priorities are the same. When it is prioritized by business value of the tasks/stories in it, it is called managed backlog. In many projects, user stories are also represented visually as a user story map, which is a structured visualization of a backlog. User story map is a map of user stories that are transposed from a linear backlog, onto a visual working board.

Each of this concept is a detailed topic in itself. For the context of this article, I will limit it only at the introductory level. Let's now look into differences and similarities between user stories and use cases.

Having explored information system record concepts, the objective of this article is to examine one particular type of field — the record business identifier. Its purpose is to uniquely identify an instance of a record.  Users of an information system are expected to have knowledge of, or access to, this value. The value is used to start down, or stay on, the ‘happy path’ of any business process that deals with the specific record instance it identifies.

When engaging on projects we need to lead our clients to get the outcomes we need for analysis. If we act passively and don’t take charge then they’ll take things all over the place and create chaos. In this article we’ll explore how a problem statement acts as a powerful tool to keep control of our engagement and analysis right through the project lifecycle.

Taking a product from an abstract idea to an item that’s widely available in the marketplace demands a hands-on approach to prevent things from falling through the cracks. A technique that goes back nearly a century, product lifecycle management (PLM) has for decades been used to improve the efficiency of product development and design.

In recent years, however, a growing number of organizations are realizing the capability of cloud-based PLM software to drive fulfillment benefits. There is a recognition that you can strengthen your supply chain management by deploying PLM from product conception to multi-faceted fulfillment. As your product approaches maturity, it necessitates changes to workflow, supply chain, and fulfillment processes as a means of attaining sales objectives and driving overall business strategy.

But before we get into that and how PLM affects fulfillment, first a definition of PLM.

Does it make sense to merge Agile philosophies with data science? The short answer is yes, as long as the organization recognizes and accommodates the ambiguous, non-linear nature of the data science process rather than expecting data scientists to fit into the same mold they’ve adopted for “Agile software development”. The problem, in my experience, is that this rarely happens. Probably because the data science field is still new, many organizations are still trying to shoehorn data science into Agile software engineering practices that compromise the natural data science lifecycle.