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?
Abstraction And “Requirements”
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.
Requirement Naming – Stick A Fork In It?
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.
Subordinate and Superordinate Use Cases
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.
Happy Birthday Tyner Blain!
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)!
Fifteen Ways to Shut Down
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?
Gifts for Geeks: Pre-Black Friday
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 […]
Ten Requirements Gathering Techniques
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.
Pairing Business Analysts
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?