Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[US24] Eu, como administrador, desejo criar um relatório de avaliação de um paciente para documentar o andamento do tratamento do mesmo. #47

Open
18 tasks
m4rllon opened this issue Jan 25, 2025 · 0 comments

Comments

@m4rllon
Copy link
Contributor

m4rllon commented Jan 25, 2025

História de Usuário:

Eu, como administrador, desejo criar um relatório de avaliação de um paciente para documentar o andamento do tratamento do mesmo.

Definition's of Ready (DoR):

  • A descrição da história deve estar clara e bem compreendida. Deve seguir o formato “Eu como… quero… para…” com detalhes suficientes para a equipe entender o que precisa ser feito.
  • Os critérios de aceitação devem estar definidos para garantir que os objetivos do requisito sejam entendidos.
  • O requisito deve ter sido priorizado e ter um valor definido para o negócio, alinhado com os objetivos do projeto.
  • Todas as dependências do requisito precisam ser identificadas e tratadas para que o desenvolvimento possa prosseguir.
  • O requisito deve ser analisado e aprovado pelo Product Owner para garantir que está alinhado com as necessidades dele.
  • O item precisa ter um tamanho adequado para ser completado dentro de uma sprint ou período estipulado.

Definition's of Done (DoD):

  • O código deve respeitar os padrões estabelecidos pela equipe, como padronização de tecnologias, bibliotecas, nomenclaturas e comentários de código.
  • O código deve passar por testes unitários, de integração e end to end.
  • O código deve atender aos critérios de aceitação específicos da User Story.
  • O código deve passar por uma revisão de QA e ser aprovado antes da entrega.
  • O código deve estar conforme o design prototipado, ser responsivo e seguir as diretrizes de acessibilidade da WCAG.
  • A nova funcionalidade deve ser documentada para facilitar manutenção futura.
  • O código deve ser verificado para garantir que não tenha bugs de qualquer severidade.

Critérios de aceitação:

  • O relatório deve conter todos os campos existentes nos documentos fornecidos pela cliente.
  • O usuário deve poder criar três tipos de relatório diferentes: de RPG, de Pilates, de Avaliação Neurológica ou de Avaliação Uroginecológica.
  • Cada relatório deve conter as informações específicas do paciente e as informações específicas do tipo de relatório.
  • O relatório criado pelo administrador deve ser associado a um usuário, de forma que o paciente seja capaz de visualizar seu relatório em sua conta de usuário.
  • O relatório criado deve ser devidamente adicionado ao banco de dados.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant