Faltou a divisão de responsabilidades por ator (identificação de casos de uso).
Os resumos de casos de uso são casos de uso, não apenas a descrição do objetivo do caso de uso. Alguns dos casos de uso descritos ficaram com a característica de descrição.
Nome: Pesquisar Grupos. Como 'pós-condição' deve ser apresentado o estado do sistema após a realização do caso de uso, nesse caso poderia ser 'Uma lista de grupos foi criada e apresentada'. Terminar o caso de uso com abrir um chat ficou inadequado. Poderia ter terminado apenas com 'Sistema apresenta lista de grupos com assuntos de interesse do usuário'. Não faz sentido a seleção de jogadores...
Qual é o relacionamento de uma partida casual com a busca de grupos de estudo? Esse fluxo alternativo não faz sentido.
Utilizem a ferramenta StarUML para modelar o sistema. Casos de uso não possuem relacionamentos 'normais' entre si, deveria ser um relacionamento de inclusão ou extensão entre 'Procurar grupos de estudo' e 'Formar grupos de estudo'.
(3) TG2: Faltou a modelagem de domínio. O sistema possui apenas uma tela?
(2) TG3: A descrição dos requisitos funcionais e dos requisitos não funcionais ficaram inadequadas. Utilizem o padrão do template apresentado em sala. Apenas as regras de negócio ficaram ok.
(6)TG1: Podem melhorar.
Faltou a divisão de responsabilidades por ator (identificação de casos de uso).
Os resumos de casos de uso são casos de uso, não apenas a descrição do objetivo do caso de uso. Alguns dos casos de uso descritos ficaram com a característica de descrição.
Nome: Pesquisar Grupos. Como 'pós-condição' deve ser apresentado o estado do sistema após a realização do caso de uso, nesse caso poderia ser 'Uma lista de grupos foi criada e apresentada'. Terminar o caso de uso com abrir um chat ficou inadequado. Poderia ter terminado apenas com 'Sistema apresenta lista de grupos com assuntos de interesse do usuário'. Não faz sentido a seleção de jogadores...
Qual é o relacionamento de uma partida casual com a busca de grupos de estudo? Esse fluxo alternativo não faz sentido.
Utilizem a ferramenta StarUML para modelar o sistema. Casos de uso não possuem relacionamentos 'normais' entre si, deveria ser um relacionamento de inclusão ou extensão entre 'Procurar grupos de estudo' e 'Formar grupos de estudo'.
(3) TG2: Faltou a modelagem de domínio. O sistema possui apenas uma tela?
(2) TG3: A descrição dos requisitos funcionais e dos requisitos não funcionais ficaram inadequadas. Utilizem o padrão do template apresentado em sala. Apenas as regras de negócio ficaram ok.