I've been working on a document for one of my customers named "Use Case Best Practices", but then I decided to search the Internet to see if I could find anything similar to what I was thinking.

The best thing I've found is this Coad Letter on Borland's web site. There is enough meat here that I'm scrapping my plans and just suggesting they read that document instead. Kudos.

One of the things I learned (or was reminded of) is that -- properly done -- Use Cases really bring out some state-related issues that you can't get from plain old requirements.

I'm working with a client on fixed price software development (and have been doing so for nearly two years now), and this brings a lot of risk to my side of the table, so I'm very careful that we all understand exactly what's being developed.

JBuilder has a nice feature that I've started using lately to track "to do" items. These are the places in my Java projects where I know that I need to fix or change something, but I just don't have the time to do it at the moment. So, what I do is create a "todo" Javadoc tag that I can use as both a reminder and a management tool. Here's how it works:

Problem - the CSV file

You have a file that contains columns of data, and each column is separated by a comma (a CSV file). The width of each column can vary, but the column data is guaranteed not to contain any columns itself, so it's safe to think of the comma as truly being a column separator. So, how do you read the data?

Solution - the Perl split function

Okay, so what you're saying is that you have CSV file data that looks like this:

Keith Wood has written a book about the JBuilder OpenTools, appropriately named "Inside the JBuilder OpenTools API". Here is a link to his site, and here is an even more direct link to the JBuilder OpenTools code samples he has on his site.