Os requisitos funcionais definem funções (conjunto de entradas, comportamento e saídas) da totalidade de um sistema e dos seus componentes. Desta forma, o conjunto de to- dos os requisitos é essencial para descrever o comportamento do sistema perante as suas funcionalidades. Para além da descrição, os requisitos são identificados com um tipo obri- gatório (M) ou opcional (O) e a sua origem poderá ser do cliente (C) - através de pedidos ou necessidades do cliente - ou interna (I) - estratégia definida pela empresa.
ID Descrição Tipo Origem
RF1 Os protocolos dos dispositivos devem poder ser instala- dos em máquinas localizadas perto dos dispositivos ou em máquinas localizadas em datacenters distantes.
M I
RF2 Os protocolos dos dispositivos devem guardar os resulta- dos recebidos dos dispositivos numa cache local persis- tente antes de os enviarem para o Clinidata®. Caso exis- tam problemas/cortes temporários na ligação de rede en- tre protocolos e Clinidata®, os protocolos devem assegu- rar que continuam a receber resultados dos dispositivos, enviando-os para o Clinidata® logo que a ligação seja res- tabelecida.
M I
RF3 Os protocolos dos dispositivos devem implementar uma cache de programação para conseguir continuar a progra- mar dispositivos mesmo que ocorram quebras temporárias na ligação entre os protocolos e o Clinidata®.
O I
RF4 Os protocolos dos dispositivos devem comunicar com o Clinidata® através de WebServices.
Capítulo 3. Análise e Desenho 26
ID Descrição Tipo Origem
RF5 Os protocolos dos dispositivos devem arrancar automati- camente como um serviço, garantindo-se que caso se rei- nicie o servidor onde estão instalados, os protocolos ar- rancam automaticamente (i.e, sem qualquer intervenção humana).
M I
RF6 Mesmo que não exista ligação ao Clinidata® no (re)arranque dos protocolos, os protocolos devem arran- car e aguardar pela ligação ao Clinidata® para iniciarem o seu funcionamento.
M I
RF7 No momento do arranque, caso não exista ligação ao Cli- nidata® mas já tenha existido anteriormente uma ligação com sucesso ao Clinidata®, o protocolo deve assumir as configurações anteriores e usar a cache local para operar.
O I
RF8 O debug produzido pelos dispositivos deverá ser acessível a partir de ecrãs do Clinidata®.
O I
RF9 Os dispositivos deverão poder ser controlados remota- mente a partir de ecrã do Clinidata®: verificar se estão a executar e parar / iniciar dispositivos. Este controlo re- moto deverá funcionar de forma similar aos processos au- tomáticos do Clinidata®, ou seja, em vez de ser o Clini- data® a enviar comandos ao sistema de protocolos, deverá ser o sistema a questionar periodicamente o Clinidata® se existem novos comandos.
M I
RF10 Os protocolos deverão ter a capacidade de atualização au- tomática da versão a partir do Clinidata® (que por sua vez se liga ao Clinidata®CRM ou outro repositório) ou a partir de ficheiro colocado em pasta local.
M I
RF11 Cada dispositivo poderá ter um ou dois canais de comuni- cação. A forma de funcionamento de cada canal será es- pecificada no Clinidata®. Os parâmetros do 1º canal são os existentes hoje em dia no Clinidata®: tipo de ligação, velocidade, IP, porto, etc. Os parâmetros do 2º canal terão de ser adicionados ao modelo de dados uma vez que hoje em dia não existem os campos correspondentes.
M I
RF12 O sistema a implementar não deverá depender de interface gráfica para permitir a operação em sistemas operativos sem ambiente gráfico.
Capítulo 3. Análise e Desenho 27
ID Descrição Tipo Origem
RF13 Para permitir interação com os dispositivos e protocolos na máquina em que estão instalados, deverá existir uma aplicação independente que permita executar um conjunto de comandos sobre os protocolos: listar dispositivos exis- tentes, parar dispositivo, arrancar dispositivo e atualizar protocolo do dispositivo.
O I
RF14 Os protocolos deverão usar um ficheiro de configuração local com a informação mínima necessária para a sua ope- ração.
M I
RF15 As labels e mensagens produzidas pelos protocolos deve- rão ser em inglês e não deverão ser configuráveis. Todas as mensagens produzidas pelos protocolos deverão ser escri- tas no ficheiro de debug e precedidas pela data e hora atual tal como acontece em outros programas da Maxdata. O fi- cheiro de debug deverá ser criado automaticamente após o arranque do protocolo caso ainda não exista. O nome do ficheiro deverá conter o nome do protocolo e o ID do dispositivo no Clinidata®.
M I
RF16 No arranque do protocolo, deverá ser impressa mensagem no ficheiro de debug com a seguinte informação: data e hora, nome do protocolo, IP da máquina local e tipo de ligação (para cada canal).
M I
RF17 Os protocolos deverão estar preparados para comunicar com os dispositivos usando diferentes tipos de ligação: TCP/IP cliente, TCP/IP servidor, RS232 e partilha de fi- cheiros. Estes tipos de ligação poderão aumentar no fu- turo. Independentemente do tipo de ligação, o processa- mento das mensagens recebidas e das mensagens a enviar deverá ser exatamente o mesmo, ou seja, deverá ser usado o mesmo pipeline de validação e tratamento nos vários ti- pos de ligação atuais e futuros.
Capítulo 3. Análise e Desenho 28
ID Descrição Tipo Origem
RF18 Quando o tipo de ligação é TCP/IP cliente, o protocolo es- tabelece uma ligação com o dispositivo usando o endereço IP e porto especificados na configuração do Clinidata®. Caso não consiga estabelecer a ligação, deverá tentar no- vamente em intervalos periódicos até conseguir estabele- cer a ligação. Em cada tentativa, imprimir uma mensagem de erro no ficheiro de debug indicando o IP e porto para o qual não conseguiu estabelecer a ligação. Quando conse- guir estabelecer ligação, imprimir uma mensagem de su- cesso no ficheiro de debug indicando o IP e porto para o qual conseguiu estabelecer a ligação.
M C
RF19 Quando o tipo de ligação é TCP/IP servidor, o protocolo faz bind a um Porto local em todas as interfaces de rede e aguarda ligação do dispositivo. Caso não consiga realizar bind ao Porto, imprimir mensagem de erro no ficheiro de debug. Caso consiga, imprimir uma mensagem de sucesso no ficheiro de debug indicando o IP e Porto em que foi rea- lizado bind. Quando o dispositivo estabelecer uma ligação com sucesso, imprimir mensagem no debug com a infor- mação de que a conexão foi estabelecida no respectivo IP e Porto.
Capítulo 3. Análise e Desenho 29
ID Descrição Tipo Origem
RF20 Para cada protocolo X desenvolvido, codificar um 2º pro- tocolo espelho X-mirror que serve para testar o protocolo X. O protocolo espelho X-mirror deverá produzir as tra- mas principais do dispositivo para possibilitar a realiza- ção de testes básicos iniciais do protocolo X. A configura- ção/operação dos 2 protocolos depende do tipo de ligação: • Se o protocolo X for TCP-IP cliente, o X-mirror será
TCP-IP servidor
• Se o protocolo X for TCP-IP servidor, o X-mirror será TCP-IP cliente
• Se o protocolo X for RS232, o protocolo X-mirror será também RS232. Neste caso usar software que gere portas série virtuais e criar uma ligação entre as 2 portas COM usadas pelos protocolos X e X- mirror.
• Se o protocolo X for de partilha de ficheiros, o pro- tocolo X-mirror será também de partilha de fichei- ros, usando os mesmos caminhos/endereços de fi- cheiros de programação e receção do protocolo X.
O I
RF21 Centralizar o código que é comum para o uso entre os di- ferentes protocolos e programar em cada protocolo apenas a componente específica desse protocolo.
M C
RF22 Após a gravação de resultados via webservices, deve ser desencadeada a integração de resultados, para que os atu- ais processos automáticos de integração de resultados de dispositivos passem a ser necessários apenas em cenários muito específicos.
O I
Tabela 3.8: Requisitos Funcionais