Nível de detalhe de Documentação de Casos de Uso [fechado]

Question

Eu estou fazendo um grande esforço para disciplinar os meus projectos e criar um documento de visão / escopo no início. Incluído neste são os diagramas de casos de uso. Apenas listando os casos de uso tem realmente me ajudou a ver plenamente todos os requisitos que o cliente está pedindo, e abriu diálogo.

Eu estou querendo saber sobre como detalhou o caso de uso deve ser. Se eu estou fazendo uma aplicação web eo usuário login para ver um relatório, posso listar todas as colunas do relatório na descrição do caso de uso?

Se não, então quando eu iria documentar esses detalhes?

Answer 1

a vantagem de diagramas de casos de uso é que eles são simples e os usuários finais podem ler e compreender

as colunas para ir em um relatório são parte de uma especificação do projeto ou requisitos (detalhes de um recurso, em termos ágeis) e fazer não pertence a um caso de uso diagrama

qualquer coisa que atravanca o diagrama de caso de uso pertence em outro lugar

onde? não importa, contanto que é um lugar consistente e você sabe onde encontrá-lo; -)

para lembrar às pessoas de que um caso de uso diagrama olha como - e por que não há espaço para mais detalhes espúrias -
_{(fonte: agilemodeling.com )}

Answer 2

Um caso de uso, onde eu trabalho, é uma descrição do aplicativo a partir da perspectiva do usuário. Nesse nível, é muito detalhado. Assim, no seu exemplo de um relatório, o caso de uso descreveria o layout do relatório, os dados que é mostrado, em que ordem, e assim por diante. O que o caso de uso não lhe dizer é como esses dados são adquiridos, ou de onde vem.

Outra maneira de olhar para ele é pensar em entregar o caso de uso de um testador. Eles podem testar qualquer coisa no documento (teste de caixa preta) e registrá-lo como um defeito. Então, se determinados dados é suposto ser mostrado sob certas condições, nesse caso, deve ser especificado em seu caso de uso para que ele possa ser testado.

Outros documentos você pode querer criar para completar o quadro é o que chamamos de SAD (Documento de Arquitetura de Software) e NFR (Requisitos Não Funcionais). A SAD descreveria a partir de uma perspectiva de design de software como você está indo para programar a solução, quais tecnologias você está indo para usar e quais algoritmos são necessários. A NFR irá incluir coisas tais como a recuperação de um software ou falha de hardware, tempos de resposta, e assim por diante.

Answer 3

Se você sabe o que colunas devem ser incluídos, aí sim, colocá-los no documento. Se você tem que pensar um pouco sobre isso em primeiro lugar, em seguida, fazê-lo e documentá-lo. Ele vai salvar o programador ter que pensar ou perguntar sobre isso mais tarde, o que torna todo o processo mais eficiente.

No entanto, se você realmente não sei que colunas devem ser incluídos ainda, porque você não não sei o suficiente sobre como o sistema inteiro vai jogar fora quando o desenvolvimento está em curso, em seguida, preocupação sobre isso e simplesmente dizer "colunas específicas TBD."

Você não pode saber tudo na frente, mas definitivamente documentar o que você sabe.

Answer 4

Use descrição do caso deve ser entre:

• detalhes de baixo: para que o usuário entende, e pensa: " Como fácil é que fazer "
• detalhes Alta: Não há possibilidades abertas (descrição detalhada do que acontece após cada etapa)

Answer 5

diagramas USECASE edifícios com notações UML nos ajudar a entender e especificar os requisitos rapidamente, geralmente diagrama de caso de uso pode ser tirada na frente da equipe de engenheiros de software para entender rapidamente a situação.

Na verdade, A usecase deve estar em formato escrito. Ele tem três formatos.

1. Resumo
2. Casual
3. completamente vestido

No caso de um relatório, Relatório formato e especificação deve ser anexado com o documento SRS, Assim que o teste pode ser realizado em conformidade.

Para mais detalhes ... Veja "Aplicando UML e Patterns: An Introduction to Object-Oriented Analysis and Design e Desenvolvimento iterativo por Craig Larman"