Archive of Requirements gathering Articles

We had a great interview with James Taylor a couple weeks ago, where we talked about his new book, Smart (Enough) Systems.

James is an expert on decision management systems. I spent the late 1990s working on “rules-centric” software systems that allowed us to isolate rules and manage them seperately from other software requirements.

Traditional structured requirements approaches focus on the gathering and management of software requirements, but they gloss over the gathering and management of business rules.

James and I are exploring the best ways to bring these two points of view together.

With a definition of the important use cases for our agile project, we can move to the logical next step - which is what exactly?

Prototyping.

We proposed a strategy for developing use cases as part of an agile development methodology last week. In this article, we will look in more detail at that proposal, and also look at a specific way to apply agile techniques to the development of the use cases. What we propose is essentially incremental development of use cases, and starting what comes next as soon as you can.

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?

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.

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.

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.

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.

Active listening is about more than gaining understanding. Active listening is about giving. Giving assurance that you understand someone’s needs. Giving confidence that you will address those needs. Giving feedback and acknowledgement that someone’s input is valuable. If you haven’t tried active listening, you may think it is a passive, receptive activity. Active listening skills will help you guide your customers and your team to do the right thing, and enjoy the experience.

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.