Começando um sistema OOP

Escolha uma metodologia de desenvolvimento de software(RUP, Praxis, XP, SCRUM etc), que ela descreverá os passos para a construção do seu sistema, desde a modelagem à documentação.
Basicamente você vai começar pela coleta de requisitos, para depois partir para a modelagem do sistema.
Espero que isso seja um pontapé para você

Tem alguma que você acha mais fácil para começar ou então que seria melhor para o meu projeto?

Valeu pela dica!

Eu acharia interessante você dar uma olhada em padrões de projeto orientados a objetos…
É isso que estou fazendo atualmente. Está me ajudando muito com essa questão de ‘onde começar’.

Começe sempre começando e terminando pelo cliente.

1) Anote tudo o que o cliente deseja (ouça o cliente muito) 
      2) Faça a lista de Recursos (pontos importantes do que o cliente quer, ou ele acha que quer... inconstâncias e atributos comuns)
      3) Destes recursos, extraia os requisitos e tente montar um esboço de forma informal do sistema (escrito numa linguagem que o cliente entenda, geralmente textual... e não em diagramas)
      4) Faça o processo chamado de "Análise de Domínio", que é onde você mostra para o cliente o que você conseguiu abstrair pra ele ter certeza se é realmente aquilo que ele quer. (Estes passos são muito importantes para diminuir o risco das coisas darem erradas no futuro... do que cliente perceber que você não fez o que ele queria e ele, consequentemente não te pagar como você queria... :-) )
      5) A partir do aval do cliente, verifique os pontos mais importantes dos recursos e começe por eles... analizando se sabe o que realmente significa e se sabe que tecnologia utilizar/como implementar o recurso/requisito... caso não saiba, perca mais tempo nesta etapa descobrindo, por que isso realmente pode ser um problema no futuro.
      6) Faça o diagrama de casos de uso.
      7) Faça os casos de uso...
      8) Faça a análise textual dos casos de uso pra descobrir os candidatos a classes e a metodos
      9) Descubra as classes e faça análise de OO, use os princípios fundamentais de OO (SRP, OCP, DRY, LSP, etc) e implemente os Design Patterns apropriados...
      10) etc... etc... etc...

Como os colegas já disseram, não existe uma fórmula pronta para isso… e talvez sejam necessários mais ou menos passos para realizar uma boa análise (consequentemente uma boa codificação), gerando menos dores de cabeça no futuro para a extensão do software (manutenção/extensão). Afinal, “O software sempre vai mudar!”. Todas estas etapas são importantes quando você está elaborando uma arquitetura/projeto para uma equipe de desenvolvimento aonde os riscos tendem a ser maiores. A recomendação é uma boa leitura de livros sobre análise e projeto orientado a objetos (A&POO)… por lá, conseguiremos sempre aprender mais e mais coisas desta ciência interminável e sempre mutável.

Abraço,

Rodrigo, espetacular sua explanação, muito obrigado, vou sim procurar algum livro que me dê até mais segurança para começar.

Olá!

Uma dica que dou é criar uma lista de funcionalidades do seu sistema, ou seja, o QUE ele vai fazer e o que ele NÃO vai fazer.

Abraços