| [Home](home) | [Arquitetura](arquitetura) |[Banco de Dados](banco_dados) | [Configuração](configuracao) | [Gerenciamento do Projeto](Gerenciamento_projeto) | [Instalação](instalacao) | [Materiais de Estudo](Materiais_estudo) | [Mockups](mockups) | **Requisitos** | [Reuniões](reunioes) | [Sprints](sprints) | | ------ | ------ | ------ | ------ | ------ | ------ | ------ | ------ | ------ | ------ | ------ | ## Acesso rápido:

* [Material](http://tools.ages.pucrs.br/dtool/wiki/wikis/requisitos#exemplos-e-material-de-apoio) * [Próximos artefatos](http://tools.ages.pucrs.br/dtool/wiki/wikis/requisitos#pr%C3%B3ximos-artefatos) # Página dos Requisitos do Projeto ## User Stories ### Fluxo inicial de seleções |US|Descrição| |---|---| US 01|Eu como usuário gostaria de identificar o hospital aonde trabalho para que possa recuperar informações específicas do hospital| US 02| Eu como usuário gostaria de selecionar a função que desempenho no hospital para que tenha acesso as atividades da minha posição| US 03| Eu como usuário gostaria de poder ter a minha função salva no app para que não precise selecionar sempre que inicio o app| US 04| Eu como usuário gostaria de selecionar uma tecnologia em que executo minhas atividades para o poder ter acesso as atividades desta tecnologia| US 05| Eu como usuário gostaria de poder ter uma tecnologia salva no app para que não precise selecionar sempre que inicio o app| US 06| Eu como usuário gostaria de cadastrar um paciente que vai iniciar um atendimento para que o usuário possa identificar as atividades realizadas nesse paciente| US 07| Eu como usuário gostaria de que se o paciente já foi cadastrado quero poder recuperar apartir do id o status de atendimento para que possa iniciar a contagem de uma nova atividade| ### Fluxo de coleta de tempos das atividades |US|Descrição| |---|---| US 09|Eu como usuário tendo acesso as atividades a serem realizadas quero poder selecionar uma atividade para iniciar a contagem de tempo| US 10| Eu como usuário durante a contagem de tempo gostaria de poder pausar a contagem, retomar, finalizar e pular para que consiga contar o tempo executado com precisão| US 11| Eu como usuário devo ter a possibilidade de executar mais de uma atividade simultaneas para que eu conte o tempo de todas as tarefas que faço no dia| ### Fluxo de exportação de Dados |US|Descrição| |---|---| US 12| Eu como usuário gostaria de ter acesso a um relatório simplificado dos tempos de atividades por função e por atividade para ter como forma de engajar a utilização do app| US 13| Eu como pesquisador devo ter a possibilidade de exportar um relatório no formato csv com medias, mediana e ICQ por atividade e função para que possa realizar análises dos dados| ## Requisitos não funcionais ## Exemplos de fluxos e material de apoio [Considerações dos clientes da entrega da Sprint 0 - Considerações.docx](uploads/5882d102d7fa27733ab089dacc63cfbe/Considerações.docx) [matrizes_e_fluxo_exemplo_só_fluxo.xlsx](Arquivos/matrizes_e_fluxo_exemplo_só_fluxo.xlsx) [fluxo_avc_microcusteio.xlsx](Arquivos/fluxo_avc_microcusteio.xlsx) [Exemplo.xlsx](uploads/9fc9ee19ae32ec6803bf16af902429b4/Exemplo.xlsx) ## Teste funcional do App Os casos de teste do App iniciaram na ferramenta [Monday](https://dtool.monday.com/) e agora estão na ferramenta [Airtable](https://airtable.com/invite/l?inviteId=inv1tiSVoadRJdczD&inviteToken=032689d030ca9941206aca6759c2b9ee363b55ae690e44403c1da9d9566b3237). **O que é isso?** Como falamos antes, na API serão feitos testes unitários para certificar que as funcionalidades estão ok e estes testes unitários serão escritos por quem estiver responsável pela task e validado no code-review, então: sempre que uma alteração na API for feita é um critério de aceitação que esteja passando nestes testes unitários que vão ir sendo incrementados. Já, pro App, o que agrega mais valor com o tempo que temos pra desenvolver, são os testes funcionais, que basicamente validam se o que foi desenvolvido está de acordo com os requisitos. E para essa validação precisamos ter com o que comparar para validar = casos de teste. Nesses casos de teste estão documentados os comportamentos para User Stories que definimos e que estão no nosso Trello. **O que faço com isso?** Quando estiver desenvolvendo sua tarefa, vá na ferramenta e verifique se o que você está desenvolvendo possibilita que as situações documentadas aconteçam como esperado. Estes casos de teste podem/devem funcionar como um guia para você, sobre qual objetivo da tarefa (em conjunto com as outras documentações). E também, no final da sprint, antes da entrega, vamos pedir para que algumas pessoas testem o aplicativo e documente em que estado está cada caso de teste, no nosso caso pode ser: `Blocked`, `Failed`, `Passed` ou `N/A`. Como vocês podem imaginar, se todos os casos de teste de uma US estiverem marcados como Passed , a User Story alcançou todos os requisitos funcionais definidos até então (:heavy_check_mark:). **Como acesso a ferramenta?** * Você já deve ter recebido um link no e-mail * Senão, fala no slack o teu e-mail que te adiciono (provável que precise fazer um cadastro no Airtable) **Status do teste** ![blocked](uploads/2353dfd3476ce04d2bd47b84b0d98f8d/blocked.JPG) => Tem dependência em outra funcionalidade para que seja possível testar este caso. ![failed](uploads/110fbbcf4a2c31dcb82081b7ddee184d/failed.JPG) => Testado e não se comporta como especificado no caso de teste. ![passed](uploads/588a867f3ae4a54803b7d496ec899c88/passed.JPG) => Testado e se comporta como especificado no caso de teste; ![na](uploads/d2598337b9aa82fd998ab558ff434024/na.JPG) => Não é necessário testar, não se aplica à situação. ## Organização para a Sprint 1: ### Divisão pra execução dos testes funcionais: - Bianca Camargo: US 04 - Camila: US 01 - Igor Brehm: US 05 - Lucas Castro: US 03 - Rafael Araujo: US 01 Obs.: - Nem todo o código das USs foram entregues/estão na develop ainda, nestes casos acompanhe a sua respectiva US até o final da noite de domingo (12/04), se não for entregue até lá, marcar como Blocked, Failed ou N/A (dependendo da situação) - Se algum teste não passar (Blocked, Failed ou N/A), descreva o porque nos updates do caso de uso em questão - Realize, no mínimo, os testes descritos no Airtable para cada US - Atualize o Test Status do casos de uso na ferramenta - Dúvidas/problemas sobre os testes funcionais devem ser discutidos no canal #teste-funcional - Ao finalizar seus testes, avise no canal #teste-funcional - Ao finalizar seus teste, atualize o card correspondente no trello (marcando no checklist que o teste funcional foi feito) e adicione um print do Test status dos casos de teste relacionados - O quanto antes o teste for realizado, melhor, pois maiores são as chances de possíveis ajustes de problemas encontrados até a entrega * Resultado do teste funcional da **sprint 1**: [sprint1-testeFuncional.pdf](uploads/7afe0922d5973eca57a35728daf02bab/sprint1-testeFuncional.pdf) * Resultado do teste funcional da **sprint 2**: [DTool__Sprint_2-TesteFuncional-_Airtable.pdf](uploads/12d24e40f15a6d1db7d5d94fffb11bab/DTool__Sprint_2-TesteFuncional-_Airtable.pdf) * Resultado do teste funcional da **sprint 3**: [DTool__Sprint_3_-_Airtable-Resultado.pdf](uploads/9aa564bd2f38e3ee8aa0a4633e32b7b4/DTool__Sprint_3_-_Airtable-Resultado.pdf) * Resultado do teste funcional da **sprint 4**: [DTool__Sprint_4_-_Airtable-Resultado.pdf](uploads/0abde1959d3346fb41500aa2eb166ceb/Resultados-DTool__Sprint_FINAL_-_4_-_Airtable.pdf)