Para qualquer metodologia usada existe a necessidade de um levantamento de requisitos. Se esse levantamento é documentado ou não, é uma escolha à parte. Vimos nos módulos anteriores a fase de levantamento de requisitos e seus métodos de elicitação. Importante que exista uma lista de requisitos para qualquer metodologia que será utilizada.
| Use Case | User Story | |
|---|---|---|
| Definição | São descrições não técnicas da iteração do usuário com o sistema, as ações que o usuário toma e o sistema responde até que o objetivo seja alcançado. | São descrições não técnicas, simples e curtas daquilo que o sistema terá que fazer. |
| Qual a sua utilização | Servem como um protótipo para que todos saibam o que esperar do sistema. | Servem para que a equipe possa estimar o que tem que fazer e quanto esforço será necessário. |
| Quem cria o artefato | Cliente ou Analista | Cliente |
| Tempo de vida dos requisitos | Os requisitos que dão origem ao use case são mantidos até o final do projeto. | Os requisitos utilizados numa user story são excluídos do projeto depois do teste de aceitação. |
| Como tratam os requisitos | Use Cases são exemplos funcionais dos requisitos e são tarefas "macro" do sistema. | User Stories são levantadas diretamente dos requisitos, são tarefas tão "micro" quanto necessário. |
Portanto, pode-se, sim, usar as duas, mas a equipe de desenvolvimento deve escolher como usá-las. Uma mistura onde user stories são utilizadas para incrementar e desenvolver e os casos de uso, simples descritivos, utilizados para a documentação, ajudando na rastreabilidade dos requisitos. Pode-se utilizar modelos gráficos, diagramas de caso de uso, de atividades e classes, para uma comunicação eficiente com o cliente e obter um feedback mais rápido, melhor e recebendo como resposta User Stories.