Giving a functional spec to developers and testers is not sufficient for creating great software. To a developer, a spec is only the what and not the why. And for a tester, the software requirements specification is neither. Use cases provide the why that explains the intent of the system for the implementation team.

We can build a prototype of what the stakeholders don’t want, and then get feedback and fix it. Or we can review use cases of what we intend to build, confirm that each stakeholder wants it, and build it right the first time.

What is a data dictionary and how is it used when communicating and managing requirements?

Business Analysts often start with four erroneous assumptions when eliciting requirements. 50% of errors in software projects are caused by requirements errors. These four faulty assumptions, presented by James A. Ward, can exacerbate the error-prone process of gathering requirements.

Seilevel has a post that presents the top 10 signs that you should not pursue a career writing requirements, check it out. Thanks Joy for the great article!

The next piece in the puzzle of how and why we apply use cases to product management. Verification of requirement correctness.

63% of product managers report to marketing and 24% report to development. 22% of requirements managers report to marketing with 55% in the development organization. These reporting structures can over-emphasize the needs of new users and super-users, while shortchanging the needs of the majority of users. Product managers will constantly be playing tug-of-war to get time to do the right thing.

In our article, The 8 Goals of Use Cases, the first goal is that our use cases must support requirement-completeness validation. In this article, we explore how to address this goal and how use cases can help. There are many pieces to this puzzle, and this article is one of them.

While effective meetings may not be the key to success, ineffective meetings are inarguably one of the largest time wasters in corporations. Applying these tips before, during, and after meetings will make us much more effective.

If This Be Treason, Make the Most Of IT! (Patrick Henry)

The customer is always right, except when he is wrong. When we have bad customers, we should fire them. Declare today as Customer Independence Day, where we declare our independence from bad customers.