We’re considering trying an experiment in agile software development at Tyner Blain. There aren’t (m)any examples of agile software development that we can watch and study that include agile requirements development. Many people still think that agility and requirements management are mutually exclusive. If the responses to this post don’t […]
Agile / Product Management / Software development / Test Automation / Testing
Posted on:
Is Agile Bad For Software Development?
Last week, Ivan Chalif, a product manager / blogger, tapped into a thread criticising product managers for not adopting and espousing agile, or at least rapid-release techniques. In this article we look at Ivan’s comments and one of the articles that he referenced. We also share our own perspective and an alternative analysis of what may have happened.
Product Management
Posted on:
Four Phases of Implementation
Jacques Murphy Describes the Four Phases of Implementation – Oh Boy!, Oh Shoot!, Oh Well, Oh Wow!
Agile / Business Analysis / Prioritization / Product Management / Project Management / Requirements / Requirements gathering / Requirements Models / Software development / Use Cases
Posted on:
How To Start The Use Case Process For Agile Software Development
One of the goals of agile software development is to deliver value quickly and iteratively. One of the most effective ways to begin the software development process is with use cases. To deliver with agility, you start with the most valuable use case, bang it out, and then move on to the next most valuable use case. How do you know which use case is the most valuable if you haven’t defined all the use cases first?
Business Analysis / Product Management / Requirements / Requirements gathering
Posted on:
Three Types of Requirements Gathering
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.