Projeto II: Elaboração dos Modelos de Requisitos Funcionais e Não Funcionais do Sistema de Apoio às Atividades dos Agentes Comunitários de Saúde na Identificação de Transtornos Mentais e Comportamentais em Crianças e Adolescentes

(1)

IN1020 - Engenharia de Requisitos Mestrado em Ciência da Computação

Projeto II: Elaboração dos Modelos de Requisitos Funcionais e Não Funcionais do Sistema de Apoio às

Atividades dos Agentes Comunitários de Saúde na Identificação de Transtornos Mentais e

Comportamentais em Crianças e Adolescentes

Professor: Jaelson Freire Brelaz de Castro Equipe:

Maria Cecilia Cavalcanti Jucá Moisés Neves Camelo Vitória Maria da Silva Maciel

Recife Novembro de 2019

(2)

1

Sumário

1. Introdução ... 2

2. Requisitos do Sistema ... 4

2.1 Requisitos Organizacionais ... 4

2.2 Requisitos Funcionais ... 4

2.3 Modelagem de Requisitos Funcionais ... 7

2.4 Requisitos Não Funcionais ... 14

2.4.1 Requisitos Não Funcionais: Proteção ... 16

2.4.2 Requisitos Não Funcionais: Confiança ... 17

2.4.3 Requisitos Não Funcionais: Eficiência ... 18

2.4.4 Requisitos Não Funcionais: Requisitos externos... 19

2.4.5 Requisitos Não Funcionais: Requisitos de processo... 19

2.4.6 Modelagem de Requisitos Não Funcionais ... 21

3 Modelagem Statechart ... 22

4 Conclusão ... 27

(3)

2

1.

Introdução

Este documento de especificação de requisitos é parte da avaliação da disciplina IN1020 Engenharia de Requisitos do Centro de Informática da UFPE.

O objetivo deste trabalho é projetar um sistema de informação através da coleta e análise de requisitos funcionais e não funcionais, além de descrever casos de uso e a construir diagramas de máquina de estado.

O problema estudado gira em torno da necessidade de apoio do governo à crianças e adolescentes que sofrem com transtornos mentais e comportamentais, onde muitas vezes, a identificação e o acesso ao tratamento são considerados processos complexos.

O grande problema sofrido pelo Agente Comunitário de Saúde (ACS) é que, atualmente, eles precisam fazer todas as visitas de forma analógica - ou seja, quando vão visitar as crianças/adolescentes para aplicar a pesquisa de identificação de transtornos mentais e comportamentais, essas são feitas todas em papel. Nisso existe uma grande possibilidade de perda de informações, grande esforço por parte do ACS que deve transpor digitalmente tudo ao chegar ao na unidade de saúde da família - onde muitas vezes os equipamentos necessários são escassos. Além disso, existe um esforço para o cálculo manual dessa pontuação da criança/adolescente no momento da coleta, a falta de mapeamento de quais casas foram visitadas e comunicação manual entre entidades (ACS, coordenador e unidade especializada). Esses principais problemas serão solucionados com o uso do sistema proposto.

O sistema possui as escalas: PHQ-9, MTA-SNAP-IV e PSC-17, e realiza o cálculo do score obtido após cada aplicação com o paciente automaticamente.

Esse cálculo é de fundamental importância, pois conduz a entrevista do ACS, indicando se o paciente deve responder a todas as escalas e ser encaminhado para uma unidade especializada. Além disso, oferece suporte na identificação automática do paciente a partir do número do Cartão Nacional de Saúde do SUS.

As informações dos pacientes são registradas, e em caso de encaminhamento, o sistema prover o envio de tais registros diretamente à unidade especializada.

(4)

3

Para elaborar o presente trabalho, fez-se necessário um conhecimento a respeito da rotina de trabalho dos Agentes Comunitários de Saúde, bem como o funcionamento da coordenação da Unidade de Saúde da Família (USF) a qual o ACS está vinculado. Uma entrevista foi realizada com um ACS, e assim foi possível identificar os requisitos do sistema apresentados nos modelos contidos nesse relatório.

Para reunir os requisitos funcionais do sistema, incluindo influências internas e externas, bem como elas se relacionam com os atores, foi utilizado um diagrama de Casos de Uso. Para representar os Requisitos Não Funcionais utilizamos o framework NFR, que trata os requisitos e suas correlações de forma qualitativa. Um diagrama StateChart foi usado com o objetivo de representar o funcionamento do sistema de forma abstrata, observando seus principais componentes e eventos relacionados.

(5)

4

2.

Requisitos do Sistema

Os requisitos do sistema são condições cujas exigências devem ser atendidas. Os requisitos podem ser divididos em requisitos organizacionais, requisitos funcionais e não funcionais, e estes serão descritos abaixo.

2.1 Requisitos Organizacionais

Os requisitos organizacionais buscam atingir as metas da organização, explicitando o que se deve alcançar mediante o desenvolvimento e a implantação do sistema e suas funções. Para o caso tratado neste trabalho, o sistema em questão busca:

● Automatizar tarefas: alguns procedimentos são realizados manualmente, como por exemplo, o registro das respostas das escalas em questão, que eram feitas em papel, passam a ser feitas pelo sistema. Além disso, o cálculo necessário para saber se é necessário preencher a escala seguinte também seria automatizada, agilizando bastante o trabalho do ACS. A automatização das tarefas tornaria a identificação da necessidade de encaminhamento do jovem/adolescente mais eficiente.

● Manter histórico de informações: O histórico era mantido de forma desorganizada e com forte dependência do comprometimento de cada ACS. Não sendo trivial o seu acesso por demais profissionais.

● Agilizar a visita às residências: Utilizando o sistema, as visitas para as entrevistas se tornam mais rápidas e práticas, sem comprometer o tempo de atividade entre os familiares.

2.2 Requisitos Funcionais

Os requisitos funcionais descrevem as funcionalidades que o sistema deve ter. Abaixo serão descritos os requisitos funcionais identificados durante o processo de identificação de transtornos mentais e comportamentais em crianças e adolescentes. Cada um possui um código identificador único, um nome, uma breve descrição, prioridade e caso de uso relacionado.

[RF01] Identificação da Criança/Adolescente

(6)

5

Descrição

O ACS deverá cadastrar cada criança para ser feita a coleta das informações para a escala de identificação de transtorno.

Prioridade Importante Caso de uso

relacionado

[UC01]

[RF02] Aplicação da 1º Escala

Descrição

O ACS deverá preencher as informações da primeira escala de identificação de transtorno e as perguntas estarão no sistema - de fácil acesso.

Prioridade Essencial Caso de uso

relacionado

[UC05]

[RF03] Cálculo do Resultado das Escalas Descrição

O sistema deverá calcular corretamente a pontuação referente à cada escala em função das respostas do responsável pela criança/adolescente e fornecer essa informação ao ACS para prosseguir o processo.

relacionado

[UC05, UC06, UC07]

Descrição

O ACS poderá preencher as informações da 2º escala de identificação de transtorno, caso a pontuação apresentada seja necessária.

relacionado

[UC06]

Descrição

O ACS poderá preencher as informações da 2º escala de identificação de transtorno, caso a pontuação apresentada seja necessária.

relacionado

[UC07]

[RF06] Apresentação do Resultado Final

(7)

6

Descrição

O resultado final da pontuação da criança/adolescente, juntamente com o direcionamento para encaminhamento deve ser disponibilizado para o ACS.

relacionado

[UC05, UC06, UC07]

[RF07] Consultar Dados Pessoais e Profissionais

Descrição

O sistema deve armazenar os dados do ACS que será ligado ao banco de dados da unidade de saúde correspondente - é de extrema relevância que os dados estejam atualizados para que possa identificar qual ACS realizou a pesquisa com qual criança/adolescente.

relacionado

[UC02]

[RF08] Enviar Solicitação de Tratamento para Unidade Especializada

Descrição

Em caso de a criança/adolescente precisar de um tratamento, o coordenador precisa receber uma notificação sobre o estado dessa criança e fazer a análise manual das opções de unidade especializadas para realização desse tratamento - e poder fazer, pelo sistema, o envio da solicitação de tratamento para a unidade especializada.

relacionado

[UC09]

(8)

7

2.3 Modelagem de Requisitos Funcionais

Figura 1. Diagrama de Caso de Uso

(9)

8

A seguir, são detalhados os casos de usos presentes na modelagem apresentando: Identificador único, nome, breve descrição, atores, prioridade, pré e pós condições e fluxo de eventos.

[UC01] Identificar Novo Paciente (Criança/Adolescente) Descrição

A identificação dos pacientes no sistema é realizada pelo ACS, as informações são puxadas do banco de dados do governo (SUS) apenas via CPF da criança ou número de cartão nacional de saúde.

Atores ACS

Prioridade Essencial

Pré-condições Banco de Dados atualizado com as informações das crianças/adolescentes e atrelado ao sistema

Pós-condições Paciente identificado para realização da pesquisa para identificação de possível transtorno.

Fluxo de eventos

1. Login no sistema

2. Clicar em “Novo Questionário”

3. Aparecerá na tela as instruções para abordagem da criança/adolescente ou seu responsável

4. Solicita autorização para executar a pesquisa de identificação de transtorno para o Responsável pela Criança/Adolescente

5. Clicar em “Continuar”

6. Inserir CPF ou número de cartão nacional de saúde (CNS) da criança/adolescente

7. Clicar em “Buscar”

8. Aparecerá na tela os dados pessoais da

criança/adolescente, e os mesmos deverão ser confirmados pelo próprio (se for de maior) ou responsável

9. Clicar em “Salvar” para finalizar a identificação

Fluxo secundário

1. Caso os dados de endereço não estejam atualizados, é possível que o ACS faça a atualização do dado antes de continuar para a pesquisa

(10)

9

[UC02] Visualizar dados pessoais e profissionais Descrição

Os agentes de saúde podem visualizar os seus próprios dados pessoais e profissionais cadastrados em seu login - para conferência dos mesmos para caso seja pertinente, atualizar o seu cadastro analogicamente na unidade de saúde.

Atores ACS

Prioridade Importante Pré-condições

ACS precisa ser cadastrado na unidade de saúde para realizar essa operação, os dados serão integrados automaticamente do banco de dados.

Pós-condições Conferência de dados e certificação do login Fluxo de eventos

1. Logar com seu usuário 2. Acessar a aba “Meu Perfil”

3. Visualização de seus dados pessoais e profissionais

4. Acessar “Sair”

[UC03] Consultar Histórico de Coleta

Descrição

Os agentes de saúde e os coordenadores podem consultar os históricos de coleta do ACS. No caso do ACS, o mesmo pode consultar para verificar se algum paciente já participou da pesquisa, quantas pesquisas realizou naquele dia ou mês e verificar os resultados, caso seja necessário. Já no caso do coordenador, o mesmo deve monitorar o desempenho dos ACS para coordenar melhor a fluidez das coletas e visualizar o ranking de urgência dos pacientes para auxiliá-lo na alocação de vagas nas unidades especializadas.

Atores ACS e Coordenador Prioridade Importante

Pré-condições ACS precisa salvar os dados de coleta sempre que realizar a mesma

Pós-condições Conferência de informações e verificação de produtividade dos ACS’s

1. Logar com seu usuário

2. Acessar a aba “Histórico de Coleta”

3. Visualização das coletas feitas no dia e em quais pacientes por qual ACS. Quando a visualização é feita pelo ACS, o mesmo só consegue ver suas próprias coletas - já no login de coordenador, é possível ver as coletas de todos os ACS.

4. Acessar a aba “Ranking” para que o

coordenador possa acessar o ranqueamento automático que o sistema faz da urgência de cada paciente - para poder alocá-lo

(11)

10

analogicamente em vagas das unidades especializadas mais próximas.

1. Existe a possibilidade de filtrar o histórico por tempo, ou seja, marcando qual tempo histórico deseja-se visualizar (um dia, uma semana, ou um mês).

[UC04] Visualizar Rota de Visita Descrição

Os agentes de saúde podem visualizar as suas rotas programadas para aquele mesmo dia, para facilitar o seu trabalho e na localização de casas já visitadas.

Atores ACS

Prioridade Importante Pré-condições

Dados de planejamento de rota, com os endereços e rotas sugeridas serem atualizados via banco de dados automaticamente no sistema.

Pós-condições Checar quais casas da rota foram visitadas, verificação se o planejamento foi seguido com sucesso.

2. Acessar a aba “Minhas Rotas”

3. Visualizar a rota do dia

4. Sempre que uma visita terminar, ir nas rotas para marcar como concluído o último endereço visitado

1. Caso uma casa visitada esteja sem ninguém no momento da visita, é possível o ACS marcar

“Remarcar visita” no sistema, onde o mesmo deixará como rota para o dia seguinte.

[UC05] Realizar a Entrevista da 1º Escala (PHQ-9) Descrição

Os agentes deverão aplicar a entrevista da primeira escala, que estará disponível no sistema, perguntando aos responsáveis informações de saúde sobre a Criança/Adolescente.

Atores ACS

Pré-condições Ter a escala PHQ-9 automatizada no sistema

Pós-condições Acesso ao resultado do cálculo da pontuação referente a essa escala

1. ACS deve acessar a aba “Iniciar Questionário”

2. Preencher o CPF ou CNS da Criança/Adolescente

3. Entrar “Continuar para a Pesquisa”

4. Entrar na 1º Escala (PHQ-9)

(12)

11

5. Fazer perguntas em voz alta para o responsável da Criança/Adolescente

6. Colher respostas do responsável 7. Adicionar corretamente no sistema

8. Ao finalizar, aguardar cálculo de pontuação 9. Caso o resultado aparecer acima da pontuação

de encaminhamento, prosseguir para a escala 2

1. Caso não, finalizar a entrevista e agradecer ao responsável pela disponibilidade.

[UC06] Realizar a Entrevista da 2º Escala (MTA-SNAP-IV) Descrição

Os agentes deverão aplicar a entrevista da segunda escala, que estará disponível no sistema, perguntando aos responsáveis informações de saúde sobre a Criança/Adolescente.

Atores ACS

Prioridade Essencial Pré-condições

Ter a escala MTA-SNAP-IV automatizada no sistema e a pontuação da escala anterior (PHQ-9) ser acima da pontuação mínima de encaminhamento.

1. Entrar na 2º Escala (MTA-SNAP-IV)

de encaminhamento, prosseguir para a última escala

1. Caso não, o ACS deve finalizar a entrevista 2. Em seguida, mostrar o resultado e agradecer ao

responsável pela disponibilidade.

[UC07] Realizar a Entrevista da 3º Escala (PSC-17) Descrição

Os agentes deverão aplicar a entrevista da terceira e última escala, que estará disponível no sistema, perguntando aos responsáveis informações de saúde sobre a Criança/Adolescente.

(13)

12

Atores ACS

Prioridade Essencial Pré-condições

Ter a escala PSC-17 automatizada no sistema e a pontuação da escala anterior (MTA-SNAP-IV) ser acima da pontuação mínima de encaminhamento.

1. Entrar na 3º Escala (PSC-17)

de encaminhamento prioritário, apresentar o resultado para o responsável e solicitar o

encaminhamento da criança/adolescente para a unidade especializada

1. Caso o resultado não fique acima da pontuação de encaminhamento, o ACS deve finalizar a entrevista

2. Em seguida, mostrar o resultado e explicar os procedimentos de saúde necessários em função do resultado para o responsável

3. Finalizar a visita agradecendo ao responsável pela disponibilidade.

[UC08] Atualização do Status de Tratamento

Descrição

As unidades especializadas devem acompanhar o processo de tratamento da criança/adolescente e para isso, devem atualizar o status de tratamento em seu cadastro, contendo informações de uso de medicamentos, período de tratamento e médico responsável por aquele tratamento. Para que o ACS possa acompanhar a evolução da criança e ter no registro o detalhamento e resultado do tratamento para que o ACS possa dar auxílios pontuais à domicílio.

Atores Unidade Especializada Prioridade Desejável

Pré-condições O cadastro da criança já deve ter sido feito e

armazenado, para acesso da unidade especializada.

Pós-condições

O acesso ao status atual do tratamento da criança/adolescente e verificação de uso de medicamentos, período de tratamento e médico responsável por aquele tratamento.

Fluxo de eventos 1. Logar com seu usuário de Unidade Especializada

(14)

13

2. Acessar o histórico do paciente em questão 3. Acessar o botão de “STATUS”

4. Atualizar o status entre as 3 opções

encontradas: "tratamento não iniciado" , "em tratamento" ou "tratamento finalizado"

5. Cada status pode ser acompanhado de um comentário

6. Salvar a operação

1. Uma vez que o paciente esteja evoluindo ou regredindo no tratamento, as unidades

especializadas podem atualizar o status quantas vezes sejam necessárias para o total

acompanhamento.

[UC09] Envio/Recebimento de Solicitação de Tratamento

Descrição

Nos casos onde a pontuação da escala de uma dada criança/adolescente for suficiente para iniciar o encaminhamento da mesma, o sistema irá enviar automaticamente uma notificação para o coordenador com as informações sobre o jovem em questão e assim o coordenador fará a análise analógica de suas informações e encaminhará para a unidade especializada coerente com seu resultado. O coordenador irá consultar o ranking do paciente, para entender o nível de urgência do tratamento. Assim, o coordenador fará uma análise de nível de urgência e de localização para enviar a solicitação de tratamento para as unidades especializadas

Atores Coordenador e Unidades Especializadas Prioridade Essencial

Pré-condições

Registro das escalas feitas corretamente pelo ACS e salvos no sistema, notificação de criança ou

adolescente que deve ser encaminhado para uma unidade especializada com as informações do paciente e seu nível de urgência ranqueada.

Pós-condições

Unidade especializada recebe informações da criança ou adolescente que receberá tratamento em seu centro e começa os preparativos para recebê-la.

2. No caso do coordenador, receber notificação de encaminhamento de criança/adolescente

3. Acessar os dados enviados do paciente e seu nível de urgência através do ranking, para aprofundar seu conhecimento sobre o mesmo 4. Localizar analogicamente as possíveis unidades

especializadas que cuidam daquele transtorno e com disponibilidade de vagas para tratamento

(15)

14

5. Enviar solicitação de tratamento para a Unidade especializada - que irá receber as informações e entrar em contato com o paciente

7. Salvar a operação

1. As unidades especializadas precisarão logar 2. Receber a notificação com a solicitação de

tratamento (com as informações do paciente) 3. Entrar em contato com o paciente

analogicamente para agendar a consulta 4. Atualizar seu status de tratamento

5. Salvar

2.4 Requisitos Não Funcionais

Requisitos não funcionais (NRFs) estão relacionados às restrições e aspectos de qualidade do software. Esses requisitos fixam as restrições sobre como os requisitos funcionais deverão ser implementados. Os requisitos não- funcionais têm efeito global no sistema e são de extrema criticidade para o sucesso do software, já que está diretamente relacionado com a satisfação do usuário.

As características dos requisitos não funcionais são subjetivas, relativas e interativos. Por esse motivo, vários pesquisadores da área propuseram maneiras de classificação desses NRFs, dentre elas: Lista de Boehm, Lista de MacCall, IEEE-Std 830-1998 lista 13 requisitos não-funcionais e a proposta por Sommerville.

Para a descrição dos requisitos não funcionais, tomamos como base a classificação de Sommerville que gerou 3 categorias: requisitos de produto, requisitos organizacionais e requisitos externos. Através destas categorias, foram classificados e elencados os requisitos não funcionais que serão críticos para o sucesso da implementação do sistema em questão. Os “Requisitos de Produto” são os que especificam o comportamento do produto, do sistema.

Como exemplo podemos citar a rapidez de operação ou a memória requerente.

Dentro da classificação “Requisitos de Produtos”, foram utilizadas as subclassificações: Requisitos de Usabilidade, Requisitos de Eficiência, Requisitos de Confiança e Requisitos de Proteção.

(16)

15

A descrição de cada sub-classificação é importante para a melhor compreensão do objetivo do requisito:

● Requisitos de Usabilidade: São de extrema importância para uma melhor experiência do usuário na ferramenta - com facilidade de manuseio e propriedade na hora de realizar alguma atividade essencial. Para atingir esses requisitos, serão solicitadas, principalmente, habilidades no campo do design - tanto de interface (UI) como o de experiência do usuário (UX) - para entregar o nível desejado de usabilidade.

● Requisitos de Eficiência: Para uma boa aceitação do usuário, o sistema deve realizar consultas ao banco em tempo adequado, retornando pesquisas relacionadas à dados do possível paciente, dados do ACS (profissionais e pessoais), resultados da aplicação das escalas. Os pontos que auxiliam são a segurança (pela otimização da validação de informações) e confiabilidade (para recuperação de falhas).

● Requisitos de Confiança: Uma aplicação bem desenvolvida deve ter preocupação com falhas que podem ocorrer por falta de sincronismo ou ação humana indevida e por causa disso a recuperação de falhas, esses requisitos são úteis para evitar retrabalho e perda de informações úteis dos usuários.

● Requisitos de Proteção: O ponto crítico de qualquer sistema é este. O acesso das informações deve ser direcionado para as pessoas certas, portanto a preocupação em autenticação do cliente é importante. Com a criação de perfil para usuário, criando níveis de acesso e/ou modificação de informações, evitará que dados sejam alterados por pessoas não autorizadas. A validação otimizada reforça esta ideia e auxilia a verificar os dados que estão sendo inseridos, alterados ou excluídos sem perda de performance.

(17)

16

2.4.1 Requisitos Não Funcionais: Proteção

[RNF01] Confidencialidade

Descrição

Os dados do sistema devem ser confidenciais, portanto, podendo ser acessados apenas por pessoas que possuam as permissões necessárias no sistema.

relacionado

[NENHUM]

[RNF02] Autenticação do usuário

Descrição

O usuário deve autenticar-se utilizando login e senha previamente cadastrados no sistema, de forma a aumentar a segurança do mesmo.

relacionado

[NENHUM]

[RNF03] Perfis de acesso

Descrição

O sistema deve garantir que cada tipo de usuário acessar apenas as informações disponíveis para o seu perfil.

relacionado

[NENHUM]

[RNF04] Integridade de Dados

Descrição Os dados coletados devem ser íntegros.

relacionado

[Todos]

[RNF05] Armazenamento

Descrição O sistema deve realizar o armazenamento dos dados a cada uma hora.

relacionado

[UC03, UC05, UC06, UC07, UC08]

(18)

17

2.4.2 Requisitos Não Funcionais: Confiança

[RNF06] Disponibilidade

Descrição O sistema deve estar disponível e acessível durante 24 horas dos sete dias da semana.

relacionado

[Todos]

[RNF18] Taxa de Ocorrência de Falhas

Descrição A taxa de ocorrência de falha deve ser no máximo 1 ocorrência a cada 540 execuções.

relacionado

[Todos]

2.4.3 Requisitos Não Funcionais: Usabilidade

[RNF07] Simplicidade no Uso

Descrição

O sistema deverá ser de simples utilização e possuir uma interface amigável, sendo trabalhados por designers de ux e de ui.

relacionado

[Todos]

[RNF08] Linguagem Simples e Clara

Descrição

O sistema deve apresentar informação textual utilizando linguagem tão clara e objetiva quanto possível, de forma a facilitar o entendimento do conteúdo.

relacionado

[Todos]

[RNF09] Design Simples

Descrição

O sistema deve utilizar primitivas gráficas bem estabelecidas como grids, barras de rolagem, menus drop-down, entre outros, para compor sua interface gráfica, de forma a apresentar informações de forma familiar ao usuário.

(19)

18

relacionado

[Todos]

[RNF10] Uso de Componentes Gráficos

Descrição A interface gráfica de ser de fácil interação e intuitiva para o usuário.

relacionado

[Todos]

[RNF11] Feedback dos usuários

Descrição O sistema deve auxiliar o usuário no uso do mesmo e permitir que o usuário envie feedback do sistema.

Prioridade Desejável Caso de uso

relacionado

[Nenhum]

[RNF12] Completude

Descrição

O sistema deve atender satisfatoriamente a todas as necessidades de análise dos stakeholders em relação às consultas e coletas dos dados.

relacionado

[UC02, UC03, UC04, UC05, UC06, UC07, UC08]

2.4.3 Requisitos Não Funcionais: Eficiência

[RNF12] Eficiência

Descrição

O sistema deve responder rapidamente a todas as interações do usuário, de forma a manter a sensação de interatividade.

Consultas que exigem maior processamento devem levar apenas o tempo estritamente necessário para a sua realização para retornar seu resultado. O sistema deve manter essas características de performance mesmo sob

grande quantidade de acessos.

(20)

19

Caso de uso relacionado

[Todos]

[RNF13] Tempo de Resposta

Descrição Nenhuma consulta no sistema deve levar mais de 20 segundos para retornar sua resposta.

relacionado

[Todos]

[RNF14] Manutenabilidade

Descrição

O sistema deve ser capaz de lidar facilmente com possíveis alterações, correções de bugs, novos requisitos ou melhorias.

relacionado

[Nenhum]

2.4.4 Requisitos Não Funcionais: Requisitos externos

[RNF15] Manuais de diagnóstico e estatística das perturbações mentais - DSM

Descrição

Os instrumentos de avaliação vêm se tornando, cada dia mais, ferramentas indispensáveis tanto para a clínica como também na área de pesquisa - dentro da área psiquiátrica e de saúde mental, elas se mostraram utensílios estratégicos para uma maior padronização de critérios diagnósticos.

relacionado

[Todos]

2.4.5 Requisitos Não Funcionais: Requisitos de processo

[RNF17] Desenvolvimento da aplicação

Descrição A aplicação deverá ser desenvolvida utilizando tecnologias como React Native e Springbot.

(21)

20

Caso de uso relacionado

[Todos]

(22)

21

2.4.6 Modelagem de Requisitos Não Funcionais

Figura 2. Modelagem RNF (Requisitos Não Funcionais)

(23)

22

3 Modelagem Statechart

A modelagem do comportamento do sistema foi realizada em StateChart, com o objetivo de demonstrar como o sistema deve operar quando realizada as atividades presentes nos casos de uso descritos anteriormente. Inicialmente, o sistema apresenta uma tela de autenticação, que logo após a confirmação de login, redireciona o usuário para uma nova tela. Esta segunda tela, varia entre os 3 perfis de usuários do sistema, que podem ser os Agentes Comunitários de Saúde (ACS), Coordenação da UFS e Unidade especializada.

Figura 3. Comportamento de login do sistema

Considerando o perfil do ACS, a partir da tela de login, ele poderá visualizar uma nova tela para inserção do CNS do paciente e na sequência, iniciar a coleta. Outras opções de Menu também estão disponíveis, como visualizar dados de perfil, histórico da coleta realizada e rota de visitas a ser seguida. Após a inserção do CNS do paciente, os dados de identificação, parentesco e de endereço, são listados para o ACS. Considerando a possibilidade de que base de dados do CNS poderá estar desatualizada e informar um endereço diferente do qual o paciente reside, é permitido que o Agente atualize estes dados caso isso ocorra.

(24)

23

Conforme apresentado na figura 4, após a aplicação de uma escala, o sistema apresenta o score obtido do paciente, exibindo uma tela para que o ACS possa conferir e identificar se será necessário aplicar outra escala. Ao final, os dados são salvos, a coleta é finalizada e o ACS redirecionado para a etapa de identificação do paciente para a próxima coleta.

Figura 4. Comportamento do perfil de usuário ACS

Já o usuário coordenador da UFS, após a autenticação ele é redirecionado para uma tela que exibe as notificações de encaminhamento de pacientes. Essas notificações são apresentadas considerando um ranking de classificação, isto é, cada coleta realizada que indica um encaminhamento possui uma classificação, cuja qual informa um grau de urgência para

(25)

24

tratamento. O paciente que estiver no topo da lista, é tido como prioritário para encaminhamento.

O coordenador é o responsável por enviar as solicitações para a Unidade especializada através do sistema. Antes de realizar o envio, ele precisa observar qual unidade possui disponibilidade para atender o paciente. Outra opção de Menu também disponível para este usuário é a visualização do histórico de coletas realizadas.

Figura 5. Comportamento do perfil de usuário Coordenador da UFS

Por fim, a Unidade especializada recebe as solicitações para iniciar tratamento com o paciente. Dentre as suas atribuições está a alteração de status do paciente, com o objetivo de informar a UFS a situação do encaminhamento.

(26)

25

Figura 6. Comportamento do perfil de usuário Unidade Especializada

A seguir, é apresentado o comportamento do sistema completo

(27)

26

Figura 7. Comportamento completo do sistema

(28)

27

4 Conclusão

O conhecimento adquirido pela equipe na disciplina permitiu a análise de um caso real e a elaboração de um sistema que pode ajudar a otimizar os processos de identificação de transtornos mentais e de comportamento de crianças e adolescentes por parte da iniciativa pública. Além disso, o sistema se propôs a facilitar e ajudar a jornada profissional dos agentes comunitários de saúde (ACS) e otimizar o processo de tratamento dessas crianças/adolescentes com distúrbios.

Para especificar com precisão as necessidades do sistema foram realizadas modelagens diferentes. No presente trabalho, utilizamos o diagrama de caso de uso para especificar as funcionalidades do sistema que se relacionam com os requisitos funcionais. Na sequência, o framework NFR para modelagem dos requisitos não funcionais, e por fim, StateChart para simular como o sistema deve se comportar mediante os casos de uso descritos.

Desta forma, este projeto contribuiu significativamente para o aprendizado da equipe, pois permitiu uma experiência real dentro do contexto de engenharia de requisitos, fazendo com que os conhecimentos passados fossem solidificados e a evolução na compreensão sobre a importância da área no âmbito da computação.

(29)

28

10. Tabela de Esforços

Membro Esforço Assinatura

Maria Cecilia Jucá 33,3%

Moisés Neves 33,3%

Vitória Maciel 33,3%