Business Analysis / Product Management / Requirements / Requirements gathering / Requirements Models / UML Modeling / Use Cases

Use Case vs. UML Statechart – Business Rules

Posted on:

What is the better requirements management model for capturing business rules? The use case, or the UML statechart? In this article, we explore how customer orders are submitted and processed, and contrast how use cases and statecharts expose and document business requirements and business rules.

Business Analysis / Business Process Modeling / Product Management / Requirements / Requirements gathering / Requirements Models / Use Cases

Use Case vs. Process Flow – Failure Handling

Posted on:

Should you use use cases or process flow diagrams to document business requirements? At some level, they both document the same thing, they just document it differently. The best requirements will come from doing both – but what if you are forced to choose one? What are the tradeoffs between use cases and process flows? In this article we look at the documentation of failure handling.

Business Analysis / Communication / Consulting / Requirements / Requirements gathering / Requirements Models

How To Visualize Stakeholder Analysis

Posted on:

The first step of gathering requirements is to identify who can give you the requirements. Business processes include communication between different people inside the organization. Communication also includes people outside the organization. When gathering requirements, it can be easy to overlook the people who don’t use the software directly. Those people may still be stakeholders. Read on to see how to approach stakeholder analysis.

Business Analysis / Product Management / Requirements / Requirements Models / Use Cases

How To Write Use Case Preconditions and Triggers

Posted on:

Use case writing is key to effective requirements management. Each use case represents a single idea or logically grouped behaviors. When you define a use case, there are several mistakes you can make. Preventing those mistakes is the first order of business. The second order of business is making sure that the use cases in the system work together. This requires an understanding of the context in which the use case happens. To fully understand a use case you have to know what is promised to be true before the use case happens, as well as what causes the use case to happen. These are subtly different.