Thanks to the download squad for pointing me at the Juicy Studio: Readability Test! You can go to Juicy Studio’s site, and calculate the reading level of any URL.
Of the multiple analyses provided, the Gunning Fog index is the easiest result to read - it is a proxy for the number of years of [...]

CRUD (Create, Retrieve, Update, Delete) is an acronym used to refer to a set of mundane, important, and indirect (if not implicit) requirements or use cases. To create a report on orders, you have to first create the orders and retrieve them. Further, the ability to update (edit) and delete the orders is [...]

Need to convince someone in your management chain why they should invest in managing requirements? There are some great arguments…

In Documents vs. Conversations, on the Pyre blog, Greg Wilson does that thing that we so rarely do - he takes a step back, and thinks from an entirely different perspective about managing requirements. He proposes the idea of managing requirements as conversations, instead of as documents.
Greg makes the point that the reason for [...]

The UML way to organize and manage use cases.
Pros

Provides a high level view of the use cases in a system, solution, or application.
Clearly shows which actors perform which use cases, and how use cases combine to form business processes

Cons

Presents an “inside-out” view of the sytem. This description reflects “what it is” not “why it is” [...]

The five most common use case mistakes. The list has grown to ten, but check out these top five - the worst of the worst.

Use cases are a great tool for establishing the scope of a project. They provide a framework for defining what needs to be implemented (if it doesn’t support a use case, we don’t need to implement it). They also set expectations with stakeholders (here’s what you can do with the system).
Many teams fail to leverage [...]

The informal use case is the tool of the Agile Requirements Manager. It is a paragraph describing the user’s goals and steps. Also referred to as a basic use case.

We’ve dealt with user representatives who believed that they knew better than the users. We’ve dealt with people afraid to let consultants talk to the users, because the consultants might mis-set expectations and create bad will when the development team fails to deliver. We’ve dealt with over-protective information-hogs, who don’t want to telegraph their moves, for risk that they might lose control of the project, or lose credit for the project to someone else. How do we get past these barriers?

This is the classic use case as described by someone who talks about Software Engineering. All of the training classes (other than Agile classes) that I’ve been to teach formal use case development as a component in a system of requirements management.