Como um sistema de informação é criado para desempenhar um conjunto de funcionalidades, é de se esperar que o levantamento de informações para a modelagem desse sistema comece pela identificação das funcionalidades que fazem parte do escopo do projeto.

A lista de funcionalidades deve:

• Definir todas as funcionalidades e seus desdobramentos em funcionalidades menores, mais específicas.
• Definir como as funcionalidades interagem entre si, por onde começam e onde terminam, quais são aquelas que podem funcionar de maneira isolada e quais dependem de outras.
• Definir os comportamentos específicos que o sistema deve realizar, o que é sucesso (e está ok), e o que pode ser considerado errado (e deve ser desfeito ou cancelado).
• Definir todas as interfaces com os usuários, sistemas, componentes etc.
• Prover um cenário de plano de testes desde o início do projeto (e não no final).

Os diagramas de caso de uso não devem focar no processo de trabalho ao longo do tempo, mas sim nos objetivos daquela funcionalidade. Dessa forma, focamos em como satisfazer o usuário, e não em como conduzi-lo à resposta esperada. Trabalhando dessa forma, a solução aparecerá como o menor caminho para se alcançar o resultado, evitando-se assim atividades que podem não agregar valor para o sistema.

Sob essa ideia, nossos futuros sistemas podem não ser uma representação “sistematizada” do que ocorre no presente, mas sim uma reinvenção da forma de se trabalhar, buscando alternativas mais vantajosas e eficientes. Em outras palavras, o sistema não deve focar em como as pessoas trabalham atualmente, mas procurar meios de alcançar os resultados do trabalho de modo mais simples, prático, barato, seguro, eficiente e rápido. E tudo isso é responsabilidade do modelador de sistemas! Exemplo prático.