Here are a couple of notes I just sent someone on how to get started writing a software requirements specification.

They may be a little vague, but I hope they show my intent, or perhaps my frame of mind, when writing a software specification.

Fred,

Here are two notes on my mental approach when writing software requirements specifications:

Question: I want to show how my application classes are segregated into packages. Is there a UML diagram for this?

Yes, you pretty much named it. A UML package diagram is good for demonstrating the packages (or packaging) in a software application, as well as the dependencies between packages.

Question: Is there a UML diagram to visually show the processes in a system?

Yes, you can use use case diagrams to represent the use cases (processes) in a software system. Use case diagrams show the actors in a system, and the ways in which these actors use the system.

This is why I use the terms "use cases" and "processes" interchangeably. IMHO, "use case" is a fancy way of saying "process", or perhaps more accurately, user-initiated processes, or event-driven processes.

Question: What UML diagram can I use to show how an object state changes during its lifetime?

A UML state diagram will do the trick. A state diagram is very good for showing how an object state changes over the lifetime of a software application, and the triggers (triggering events) that cause the state to be changed.

Question: I want to visually model a multi-threaded software application. Can UML help?

Yes, UML activity diagrams can be a great tool for visually modeling the flow of control in a multi-threaded application. A UML state diagram can also be used to show the states objects can be in during their lifetimes.