There are many different activities that are a form of requirements gathering. So many that it can be difficult to determine which approach to use in what circumstance. By classifying requirements gathering into three different types of activities we can simplify the choices.
Business Analysis / Product Management / Requirements / Requirements gathering / Requirements management software / Requirements Models / UML Modeling
Posted on:
UML Statecharts and Documenting Business Rules
In yesterday’s article we compared use cases and UML statecharts as tools for discovering business rules. James Taylor asked a question about how we would document those rules, and then followed up my comment response with an article about business rules and RUP. In this article we move the conversation slightly forward – recognizing that we’re slowly entering the ocean of business process management.
Business Analysis / Product Management / Requirements / Requirements gathering / Requirements Models / UML Modeling / Use Cases
Posted on:
Use Case vs. UML Statechart – Business Rules
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
Posted on:
Use Case vs. Process Flow – Failure Handling
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 / Product Management / Project Management / Requirements / Requirements Models / Use Cases
Posted on:
Writing Use Cases For Estimation
You write use cases to define the scope of your project. Use cases describe what people are using your product to accomplish. Use cases provide a framework for defining the details of the product. You can estimate your project effort with use cases. But you have to write the use cases at the right level of detail.
Business Analysis / Product Management / Requirements / Requirements Models / Use Cases
Posted on:
How To Write Use Case Preconditions and Triggers
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.
Product Management
Posted on:
Ten Ways To Be A Better Product Manager
In product management training, we spend a lot of time focusing on what we do. Adrienne reminds us that this isn’t enough, we also have to focus on how we do it, with her tips on how to be a better product manager.
Product Management / Software development / UX
Posted on:
Product Management and User Experience
There’s a buzz going around about the conflict and collaboration between product managers and user experience professionals. It started with a pair of articles co-written by Jeff Lash and Chris Baum. In short, with a user-centric view of products, both roles are responsible for the success of the user-interactions. Who makes the decisions?
Product Management / Project Management
Posted on:
Scheduling Product Releases
When you define a product roadmap, you also define the release dates for your product. Change happens. Your market changes, your customers change, your requirements change. Unpredictable events happen. Your competitors release a new killer feature, your developers have an epiphany (or run into a roadblock). Should you change your release schedule?