Object Oriented Analysis and Design workflow for developer working alone

Question

Studying about OOAD I've found a simple workflow based on five steps. I don't work with a team, so what I'm interested in is a workflow that can be used by a developer working alone. The workflow I found is:

1. Gather requirements for the application
2. Describe the application with use cases
3. Based on the use cases identify the main objects
4. Identify the relationships between the objects found
5. Write a class diagram

Now, there are two things about this workflow that makes me a little confused: first it seems oversimplified, and second it seems to deal only with the domain layer, but I'm not sure.

So, my questions are:

1. Is this workflow ok, or is it oversimplified?
2. If that's the case, which more information could be added to it in order to make it more clear the way to proceed from the requirements all the way to the class diagram?
3. Am I right in that this is all about the domain model?
4. When we do OOAD do we include on the model and on the class diagrams other classes that might be needed to connect the domain model to the technologies? Or on this step we are just concerned with modeling the domain of the application?

Answer 1

This work flow does seem rather simplistic and in some ways unhelpful to me:

1. It assumes that all requirements of your application can be captured as use cases, but use cases are abstract descriptions of operations that need to be performed on stored data that (a) do not describe user interface and (b) do not describe storage mechanisms. I would, along with the use cases, produce a user interface sketch and a data storage plan, as these will influence the design of your solution too.

2. I rarely see the benefit in producing a class diagram before code. Class diagrams are useful to describe a system to other people, but when working alone or in small teams that communication tends not to be needed until much later, and the design usually changes enough to render diagrams produced before code obsolete before they're useful. Go straight to code.

3. Your work flow appears to assume you can analyse and then implement the entire application in a single pass. For anything other than the simplest of applications, this is unrealistic. Design and implement a portion of it, then repeat until finished.