A qualidade final de uma soluc¸˜ao depende de v´arios factores verificados ao longo do seu processo de desenvolvimento. Uma das primeiras fases ´e a definic¸˜ao dos requisitos, portanto, uma fase basilar. A eliminac¸˜ao de erros cometidos nesta fase torna-se cada vez mais dif´ıcil e dispendiosa `a medida que o sistema avanc¸a para iterac¸˜oes posteriores do seu ciclo de vida. Atendendo a estes factores, ´e poss´ıvel concluir que uma correcta definic¸˜ao de requisitos pode evitar alguns dissabores no futuro. Nesta secc¸˜ao pretende-se identificar quais os requisitos funcionais e n˜ao funcionais dos m´odulos em an´alise.
5.4.1 Requisitos Funcionais
Os requisitos funcionais dos m´odulos EDA e Filtros Globais foram j´a identificados nos casos de uso. Cada caso de uso corresponde a uma funcionalidade que se pretende ver implementada.
5.4.2 Requisitos N˜ao-Funcionais
Os requisitos n˜ao-funcionais agregam todos os requisitos da soluc¸˜ao que n˜ao corres- pondem a funcionalidades. Segue-se a sua identificac¸˜ao.
5.4.2.1 Requisitos de Qualidade
Atendendo ao facto de que uma falha ou execuc¸˜ao incorrecta do sistema pode afectar negativamente vidas humanas, a soluc¸˜ao insere-se no grupo de sistemas cr´ıticos. Por este motivo, existe todo o interesse em analisar os requisitos de qualidade mais significativos nesta ´area bem como outros que proporcionem uma melhor experiˆencia de utilizac¸˜ao.
Apesar de o foco serem os m´odulos EDA e Filtros Globais, os requisitos a seguir iden- tificados s˜ao igualmente aplic´aveis `a soluc¸˜ao na sua generalidade. A ordem de apresentac¸˜ao n˜ao representa qualquer hierarquia de prioridades ou importˆancia.
Acessibilidade: A soluc¸˜ao dever´a ter todas as suas funcionalidades e suporte em l´ıngua Portuguesa. No caso de as funcionalidades estarem descritas por uma imagem, se o utilizador colocar o cursor do rato sobre as ligac¸˜oes dessas mesmas funcionalidades os seus nomes/descric¸˜oes dever˜ao surgir tamb´em em l´ıngua Portuguesa.
Coerˆencia de Funcionamento: Os dados apresentados como resultados das pesquisas devem ser coerentes com os v´arios crit´erios de pesquisa definidos.
Disponibilidade: No caso particular de SI na ´area da Sa´ude, atendendo `a gravidade das consequˆencias, a fiabilidade ´e prefer´ıvel `a disponibilidade. No entanto, um n´ıvel de disponibilidade a rondar os 100% ´e o ideal. O objectivo da soluc¸˜ao ´e auxiliar o pessoal m´edico na identificac¸˜ao e acompanhamento de patologias, motivo pelo qual a indispo- nibilidade do sistema pode influenciar o rendimento do pessoal m´edico, prejudicando indirectamente os pacientes.
Eficiˆencia: O sistema dever´a ter um tempo de resposta `as acc¸˜oes realizadas pelo uti- lizador reduzido (2 a 3 segundos). Sempre que seja inevit´avel um per´ıodo de espera supe- rior a este limite, a interface deve fornecer informac¸˜ao ao utilizador acerca do progresso da operac¸˜ao. Atendendo ao facto que a informac¸˜ao estar´a armazenada num reposit´orio para o efeito, tamb´em o desempenho deste deve ser tomado em conta.
Experiˆencia de Utilizac¸˜ao: Pretende-se que a soluc¸˜ao seja desenhada tendo como ob- jectivo permitir uma boa experiˆencia de utilizac¸˜ao. A disposic¸˜ao dos dados deve ser estruturada de forma a promover o reconhecimento imediato da informac¸˜ao pretendida. A curva de aprendizagem deve ser o mais baixa poss´ıvel. Para tal deve ser realizada uma aposta no reconhecimento dos passos a efectuar em detrimento da memorizac¸˜ao. Ao longo de todas as interfaces, deve ser fornecida ao utilizador informac¸˜ao acerca do estado das operac¸˜oes ou da forma de as iniciar. Sempre que poss´ıvel, a interface deve informar quais as operac¸˜oes dispon´ıveis no estado actual de execuc¸˜ao. O utilizador deve sentir que controla a aplicac¸˜ao e n˜ao o contr´ario. No caso de ocorrer um erro de utilizac¸˜ao, o sis- tema deve ser capaz de esclarecer o utilizador da forma correcta de o fazer e recuperar da situac¸˜ao de erro.
Fiabilidade: A soluc¸˜ao deve ter todas as suas funcionalidades dispon´ıveis em qual- quer momento, n˜ao sendo consideradas para o caso falhas exteriores `a mesma. A robus- tez da aplicac¸˜ao dever´a ser o mais apurada poss´ıvel, evitando perda ou incoerˆencia de informac¸˜ao. Neste aspecto, a apresentac¸˜ao de dados errados poder´a ter consequˆencias mais gravosas do que a pr´opria n˜ao apresentac¸˜ao, na medida em que poder´a ser realizado um diagn´ostico e aplicadas terapˆeuticas desajustadas, com preju´ızo da pr´opria vida do paciente.
Manutenc¸˜ao: A manutenc¸˜ao dos dados inseridos no sistema fica a cargo do cliente, eventualmente com o apoio da CPCHS, caso a situac¸˜ao o justifique. No que respeita a manutenc¸˜ao na vertente t´ecnica, a actualizac¸˜ao do sistema para correcc¸˜oes de eventuais
falhas do sistema ´e da responsabilidade da CPCHS. Exclui-se do apoio prestado quest˜oes relativas a hardware.
Seguranc¸a: A seguranc¸a dever´a ser um pilar da soluc¸˜ao, quer pela necessidade de controlo de acessos afim de proteger a informac¸˜ao de acessos indevidos, quer pela pre- cis˜ao dos dados apresentados.
Suporte: Dever´a existir suporte relativamente ao produto desenvolvido assim como a possibilidade de os utilizadores reportarem eventuais erros ou dificuldades de utilizac¸˜ao.
5.4.2.2 Requisitos de Interface Externos
Nesta secc¸˜ao s˜ao apresentados os requisitos de interface com elementos externos que a soluc¸˜ao dever´a proporcionar.
Interface de comunicac¸˜oes: O ambiente de execuc¸˜ao t´ıpico da soluc¸˜ao ser´a uma in- tranet na unidade hospitalar. Para que o funcionamento seja poss´ıvel, deve existir uma rede de suporte, ligando todos os poss´ıveis componentes f´ısicos da aplicac¸˜ao, nomea- damente, posto de trabalho, aplicac¸˜ao cliente, servidor aplicacional e servidor de dados. Eventualmente, todos estes pap´eis podem concentrar-se numa ´unica m´aquina, contudo, continua a ser necess´aria a rede de suporte para que as aplicac¸˜oes externas possam enviar os resultados produzidos.
Interface de hardware: A versatilidade da arquitectura da soluc¸˜ao permite diferen- tes tipos de distribuic¸˜ao f´ısica da mesma, tendo como implicac¸˜ao directa o hardware ne- cess´ario. Contudo, do ponto de vista do utilizador final (localizado num posto de trabalho) este necessita apenas de um computador com os respectivos perif´ericos comuns (monitor, teclado e rato).
Interface de software: No que diz respeito a software, para a execuc¸˜ao da aplicac¸˜ao ´e necess´ario um browser. As vers˜oes suportadas s˜ao Internet Explorer 6 ou 7. Dada a natureza do componente de pesquisa de doentes, ´e necess´ario que a m´aquina cliente possua o Silverlight 2.0 Beta 2 instalado.
Interface com utilizadores: Para a visualizac¸˜ao de resultados e gest˜ao de filtros glo- bais os utilizadores interagir˜ao com a aplicac¸˜ao atrav´es de um browser. Cada um dos m´odulos ser´a disponibilizado numa p´agina Web diferente, sendo que a navegac¸˜ao ´e reali- zada atrav´es de um menu comum.
5.4.2.3 Requisitos de Ambiente
Os m´odulos em quest˜ao n˜ao exigem bastantes recursos da m´aquina cliente pelo que uma m´aquina com 1GB de RAM e um processador com 2GHz possui capacidades sufi- cientes para executar a aplicac¸˜ao. Ao n´ıvel da(s) m´aquina(s) servidor as caracter´ısticas exigidas variam consoante o conjunto de aplicac¸˜oes instaladas e qual o volume e picos de acessos. Dada a importˆancia da rede para o bom funcionamento da soluc¸˜ao devem ser considerados os tempos de latˆencia da mesma, que se pretendem baixos. Deve ser considerado o volume de tr´afego na rede para cada situac¸˜ao particular de execuc¸˜ao.
5.4.2.4 Requisitos de Utilizadores
Para interacc¸˜ao com o sistema n˜ao s˜ao necess´arios conhecimentos t´ecnicos avanc¸ados de inform´atica. A interface deve ser desenhada de forma a ser simples, eficaz e eficiente, pelo que conhecimentos b´asicos de utilizac¸˜ao de TI s˜ao suficientes. J´a no dom´ınio m´edico, exigem-se conhecimentos avanc¸ados para a correcta interpretac¸˜ao dos resultados.