As Business Analysts, when we’re at the sharp end of solution delivery that doesn’t match a customers needs, at that time it just can’t be rectified and we can’t help thinking that we might have been able to prevent this at the early stages. In this article we’ll explore 3 ways to get out the trap of being solution oriented up front to shift more into the problem and needs to get better requirements. 

In the eyes of process analysts, quality improvement professionals, and business analysts, who still rely on the more than 100 years-old, strictly procedural notions of a process and on flowcharting notations that were also invented in the last century, IT IS IMPOSSIBLE to perceive and model something like playing soccer as a sequential process.

The most effective business processes are not only structurally sound and efficient but also highly dynamic and agile.  A high-quality business process structure today is one that has been conceived, structured, and can be readily configured as a network of specialized, collaborating, event-driven, and outcome-oriented services, not just as a sequential procedure.   

Being successful as a business analyst is not a feat - reserved for a select few. Neither is it rocket science. It is achievable and within your grasp, if you apply a well-rounded approach to how you manage your career. While these tips are centered around the business analysis career, they can be applied to any career.

We hear the buzzword “business transformation” everywhere. It has become almost expected of any organization to announce they are on their digital transformation journey. What does it mean?

There are many definitions of digital transformation. This abundance points to a broad interpretation of the term. The ambiguity of these statements reflects vague expectations of many organizations embarking on their “digital transformation journeys”.

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.