Enough of the debates about requirements and what we call them. Why don’t we just hire great developers and empower them to work directly with the customers?

I don’t know how many of our readers have reached a conclusion to this debate, but we have for now. Thanks to everyone who has contributed to, enjoyed, or at least tolerated this ongoing discussion. Roger had some good comments in our previous article - we’ll try and address one of his points here. His point, I believe, is that using the word “requirements” to describe multiple levels of abstraction in the definition of a product is a bad thing.

The discussion about requirements and the naming of things continues? Can we stick a fork in it already? Maybe, but probably not. Catch up on the cross-blog discussion with Roger and Adam.

Use Cases can be built up by combining other use cases. When a use case is made up of other use cases, the component use cases are known as subordinate use cases. The “parent” use case is referred to as the superordinate use case. This is known as composition. See an example of how composition works for use cases.

The Tyner Blain blog is a year old today! Look back at some of our stats, including most popular posts, and a little bragging (not too much, we hope)!

There are 15 ways for someone to shutdown a laptop running Windows Vista. This adds unwarranted complexity to our software. How can we avoid the same problem in our software?

Many of us who are part of the Tyner Blain community are geeks, gadget hounds, and people who read books that make you think. All of us know someone like this. Tyner Blain is a mostly-for-free site - we just ask that you remember our name, join in on the discussion, and share [...]

The BABoK (Business Analyst Body of Knowledge) lists 10 techniques for gathering requirements. Here’s an overview of each one. For more details, check out the latest Guide to the BABoK.

Pair programming is a bit of a foreign concept for many people in business. A few years ago, it was foreign to most programmers too. Pair programming is a powerful technique for software development because it allows two people to look at the same problem/solution from two different perspectives at the same time. Would that same approach work for business analysis?

Johanna Rothman just wrote an article titled Implicit Requirements are Still Requirements. She points out that her expectations were not met, even though her needs might have been. Johanna also implicitly begs the question - how do we gather implicit requirement?