Para as regras de negócios, acho que o @Joppe apontou para a UML que todos estávamos pensando.
Os diagramas de casos de uso oferecem uma excelente visão geral de como os atores / funções interagem com o sistema e o que o sistema faz. Para complexe Use Case, informações adicionais explicou textualmente vai ajudar muito ( pré-condições , pós-condições , dependências sobre execuções UC anteriores , etc )
Existem diagramas que também oferecem excelentes visões gerais dos negócios em diferentes níveis:
- Diagrama da máquina de estado se houver algum tipo de estado a ser documentado.
- Diagrama de atividade . Para Caso de Uso complexo, pode ser necessário aprofundar os detalhes. O nível dos detalhes depende de você e depende de quem vai ler a documentação. Essa pode não parecer uma documentação comercial, mas com o nível certo de detalhes, pode ser que isso aconteça.
Apenas um conselho, atribua um código a cada Caso de Uso (por exemplo: UC-1 , UC-n ). Estes serão úteis mais tarde, durante a documentação da interface do usuário.
Para a documentação da interface do usuário, a prática comum (atualmente) é fazer wireframes . Muito melhor do que as capturas de tela porque parece mais limpa e mais simples. Por exemplo, dê uma olhada no WireframeSketcher
Os wireframes podem não ser documentação suficiente; portanto, para cada tela, faça uma breve introdução e descreva cada botão. Além disso, faça referências à UC envolvida na tela ( veja agora por que os códigos UC são úteis ). Isso tornará sua documentação coerente.
O objetivo de ferramentas como o Wireframesketcher é que eles fazem maquetes interativas. Perfeito para oferecer algo interativo ao cliente enquanto você ainda está projetando ou desenvolvendo.
Não se esqueça de documentar o plano de navegação . Nav. O plano não possui diagrama UML, mas o State Machine Diagram pode ser usado. Não é para o que foi feito, mas ainda assim.
Por fim, lembre-se de quem você está se dirigindo.
Técnico : você pode se aprofundar nos detalhes e usar detalhes técnicos.
Não técnico : evite detalhes técnicos (nem relacionados à linguagem nem ao código). Tente ser claro e simples e use os mesmos termos / palavras que o cliente usa. Pense como se você não tivesse ideia de programação.