Estudo de Requisitos do Software Embarcado no Segmento ... - SBIS

Estudo de Requisitos do Software Embarcado no Segmento da
Telemedicina
Márcia Narumi Shiraishi Kondo 1 , José Reinaldo da Silva 2 , Adilson Yuuji Hira 3 ,
Marcelo Knörich Zuffo 4
1,3,4 Núcleo de Telemedicina, Laboratório de Sistemas Integráveis,
Departamento de Engenharia de Sistemas Eletrônicos da Escola Politécnica da USP
2 Departamento de Engenharia Mecatrônica e de Sistemas Mecânicos da Escola Politécnica da USP
Av. Prof. Dr. Luciano Gualberto, Trav.3 , N. 158, 05508-900, São Paulo, SP Brasil.
Resumo – Este artigo apresenta um estudo comparativo acerca da Análise de Requisitos de sistemas
embarcado no segmento da Telemedicina. O caráter multidisciplinar deste trabalho fundamenta-se na
Medicina e nas Engenharias de Design e de Software. A metodologia usada baseou-se nas técnicas de
Análise de Requisitos da Engenharia de Desing e Software, levando em consideração as restrições
funcionais de recentes tecnologias computacionais. O Método Volere apresentou-se mais abrangente para
conduzir ao entendimento do domínio estudado.
Palavras-chave: Software Embarcado, Telemedicina, Requisitos, Método Volere.
Abstract - This paper shows a study of the Requirements Analysis for embedded software support in the
Telemedicine area. This multidisciplinary work is founded on Medicine, Software and Design Engineering.
The methodology used was based on Software and Design Engineering’s Requirements Analysis, taking into
account constraints of recent computational technologies. The Volere Method revealed most extensive to
lead to the agreement of the studied domain.
Key-words: Embedded Software, Telemedicine, Requirements, Volere Method.
Introdução
Em diversas atividades humanas
identificamos a presença de Software Embarcado
(SE), embora passe despercebido por nós,
fazendo parte de artefatos eletrônicos fabricados
pela humanidade, como celulares, relógios,
televisores, equipamentos médicos, automóveis,
vídeo-games, uma lista interminável de produtos
que moldam nosso mundo atual [1]. Um sistema
embarcado é um sistema computacional
embutido em um sistema maior, e programado
para realizar uma tarefa específica. É também
chamado de Software Embutido, do inglês
"Embedded Software". A indústria de SE com seu
alto valor agregado representa uma das melhores
oportunidades para economias emergentes como
o Brasil, dotado de recursos humanos e físicos
abundantes, de ambiente ideal para preencher
uma grande lacuna no que tange a padrões e
modelos orientados à interoperabilidade em
ambientes heterogêneos de software, hardware e
plataformas diversas, do mainframe aos mais
diversificados dispositivos. Interoperabilidade
significa compatibilidade, consenso técnico,
produtos de diferentes plataformas e
fornecedores diversos, funcionando
conjuntamente em grande escala com um mínimo
de falhas ou inconveniências. A interoperabilidade
evidencia uma natureza heterogênea, distribuída
e com variados graus de autonomia e níveis de
abstração.
O foco desta pesquisa está no software
embarcado interativo e em tempo real, com o
intuito de desenvolver outras formas de captura
de dados para formação de uma base de
conhecimento unificado de pacientes, que será
projetada para obter resultados benéficos de
aplicabilidade no segmento de Telemedicina.
Com o aumento da acuracidade dos dados e da
abrangência da base de conhecimento do
paciente, podemos ajudar no aumento da
precisão dos diagnósticos e da qualidade da
análise para tratamentos, no aperfeiçoamento dos
tratamentos já aplicados, no direcionamento de
campanhas de prevenção, na redução de erros
operacionais em toda a cadeia e outras inúmeras
contribuições à comunidade médica.
Segundo a Organização Mundial de Saúde
(OMS), Telemedicina é o uso da tecnologia da
informação para entregar serviços e informações
médicas de um local para outro. Nos casos em
que a distância é um fator crítico, tais serviços
são providos por profissionais da área da saúde,
usando tecnologias de informação e de
comunicação para o intercâmbio de informações
válidas para diagnósticos, prevenção e
tratamento de doenças, e a contínua educação de

prestadores de serviços em saúde, assim como,
para fins de pesquisas e avaliações. Tudo com o
interesse de melhorar a saúde das pessoas e de
suas comunidades. Num país de dimensões
continentais e com oferta assimétrica de serviços
na área da saúde, a Telemedicina pode ser uma
oportunidade de resolução da dificuldade de
comunicação entre instituições de saúde,
garantindo a população uma maior qualidade na
oferta dos serviços e benefícios do sistema
nacional de saúde [2].
O contexto da pesquisa objetiva a definição
de um método mais apropriado à análise de
requisitos dos sistemas embarcado no campo da
Telemedicina. Os resultados e benefícios
esperados destes sistemas estão elucidados:
• Proporcionar atendimento médico com melhor
índice de cura às crianças e aos adultos com o
melhor conhecimento do indivíduo a ser tratado;
• Melhorar a qualidade e a disseminação dos
serviços prestados no setor de saúde com todos
os quesitos de segurança atendidos;
• Contribuir com o enriquecimento da base única
de dados do paciente, um futuro repositório com
visão unificada e atualizada do paciente para
atender demandas no segmento da Telemedicina,
principalmente, no que tange à prática médica,
em Câncer Infantil e Adulto;
• Viabilizar uma plataforma embutida de custo
muito reduzido para alimentar a base de
conhecimento;
• Gerar algoritmos matemáticos e estatísticos
para aumentar acuracidade dos dados e obter
inferência estatística [3];
• Definir a melhor metodologia e tecnologias mais
adequadas, valorizando os quesitos de baixo
custo, arquitetura aberta e independente, e as
tendências dos processos de fragmentação no
mundo;
• Escolher o(s) artefato(s) ideal(is) para captura
dos dados, tais como: microcomputadores
pessoais, telefonia celular, hand helds,
eletrodomésticos, veículos, dispositivos médicos,
envolvendo toda uma gama de equipamentos
eletrônicos digitais. Assim podemos avaliar
alternativas de popular a base unificada quanto
ao desenvolvimento de tecnologia de software
embarcado para processamento de imagens [4],
ou até mesmo o processamento e
reconhecimento de voz, atendendo o idioma
português brasileiro.
A seguir, abordaremos alguns sistemas
de SE na Telemedicina e outros SE em outros
campos, bem como o estudo de viabilidade dos
métodos, os princípios de uma boa especificação,
e, finalizando, as conclusões deste estudo.
Informática na Telemedicina
O sistema Oncopediatria é um dos
projetos pioneiros no estabelecimento de uma
rede piloto de Tele-saúde em oncologia pediátrica
(oncopediatria.org.br), que incorporou tecnologias
avançadas de informação para o suporte da
prática médica à distância em território nacional,
dentro de uma articulação entre as universidades,
instituições de pesquisa e instituições médicas do
País [5]. A abordagem implementada trouxe a
concepção prática da Telemedicina no contexto
adequado da realidade brasileira, empenhada em
um modelo de auto-sustentabilidade de baixo
custo para ser disseminado ou adaptado a outras
especialidades médicas. O módulo colaborativo
do sistema [6] possibilita a colaboração
simultânea de informações médicas entre
profissionais remotamente localizados, com
recursos de chat, vídeo conferência, bidimensional,
visualização volumétrica de imagens
médicas, segunda opinião médica para
diagnósticos.
Um dos primeiros projetos do Instituto
Edumed foi o desenvolvimento do Teleduc [7],
que permite a elaboração de cursos pelos
professores e desenvolvedores de conteúdo num
ambiente on-line, agregando várias técnicas de
educação à distância em saúde e tecnologias
como plataforma Web, video-conferência e teleconferência.
As dificuldades no desenvolvimento destes
artefatos são inúmeras. Vão desde a primeira
estimativa irreal do desenvolvimento do projeto
até a especificação de uma solução mal
concebida, desnivelando indicadores de
eficiência, de risco de sucesso, de satisfação do
usuário [8], entre outros. Assim, há um consenso
entre aqueles que estão encabeçando projetos
desta natureza: a necessidade de uma análise de
requisitos mais intensa, mergulhando nos
problemas e validando todo entendimento dos
processos de negócio envolvidos com os
stakeholders. Podemos destacar as seguintes
dificuldades computacionais:
Relativas ao tempo de resposta das
interações com a aplicação: uma das
características essenciais do software de
Telemedicina é o pronto feedback dado ao
médico, ao pesquisador, ou a qualquer
agente de saúde;
Relativa à comunicação humano-computador
[4]: o computador possui um padrão próprio
em seu protocolo de comunicação, nem
sempre apresenta baixa complexidade de
uso;
Relativas à expansão de tecnologias de
telecomunicação robusta e apropriada,
agregada ao baixo custo;
Em adicionar dados na base de
conhecimento do paciente: a construção do
conhecimento baseia-se no conhecimento
pré-adquirido do paciente para atender um
novo assunto.
Metodologia

O processo de criação de software tem
sido estudado sob a perspectiva da Engenharia,
afim de torná-lo exeqüível, resultando em
melhorias nas áreas de qualidade, manutenção e
satisfação do cliente.
Pressman [8] destaca que a Engenharia
de software abrange três componentes básicos:
1. Métodos: proporcionam os detalhes de como
construir o software. Englobam tarefas como
planejamento e estimativa de projeto, análise
de requisitos de software e de sistemas,
projeto da estrutura de dados, arquitetura de
programa e algoritmo de processamento,
codificação, teste e manutenção;
2. Ferramentas: existem para sustentar cada um
dos métodos. São muito usadas ferramentas
CASE;
3. Procedimentos: constituem o elo de ligação
entre métodos e ferramentas. Definem a
seqüência em que os métodos são aplicados.
A Análise de Requisitos é a primeira e a
mais importante atividade técnica no
desenvolvimento do software, e pode ser
entendida por definir os serviços que um sistema
realize em sua interface com os demais
elementos, e sob quais restrições o sistema deve
operar. Os requisitos do sistema devem
estabelecer o que o sistema deve fazer, ao invés
de como isto será feito. O produto final desta
análise fica registrado no Documento de
Requisitos de Software. O termo Análise de
Requisitos ou Engenharia de Requisitos refere-se
a uma coleção de processos: extração
(elicitação), especificação, verificação e
validação.
Segundo Balzer [9]:“... uma especificação
de software é um contrato entre o especificador e
o implementador, definindo o sistema a ser
construído. Portanto, deve ser entendido de forma
clara e sem ambiguidades por ambas as partes.
Deste modo, a transparência é o primeiro critério
para julgar especificações.”
Figura 1 – Ciclo da Análise de Requisitos
De acordo com Pressman [8], modelos
são representações tanto do mundo físico como
do mundo lógico, são feitos usando-se diagramas
que representam graficamente o domínio,
melhorando o entendimento das informações
adquiridas, permitindo a avaliação dos problemas
atuais e das informações desejadas como
entrada/saída. A origem destes problemas é que
os requisitos são a interface entre o requerente e
o analista. Para tal, é necessário o uso de
representações abstratas que descrevam o
funcionamento e a interação do sistema. Através
destas representações abstratas é criado um
modelo do mundo real, ou da parte dele
correspondente ao sistema, sendo que os
requisitos devem ser capazes de descrever
sistemas grandes e complexos.
Destacamos a seguir as técnicas de
modelagem mais expressivas, baseadas em
diferentes tipos de abstração:
• B [10]: a base para a modelagem de um sistema
em B é a máquina abstrata. Em outras palavras, a
modelagem de um sistema é uma associação
lógica de máquinas abstratas onde: vale o
princípio da composicionalidade, isto é, uma
associação de máquinas abstratas é também
uma máquina abstrata;
• Casos de Uso: uma descrição de um conjunto
de seqüências de ações, resultantes da interação
do sistema com um ator (um tipo de requerente).
As ações produzem um resultado que pode ser
observado pelo ator;
• CORE – Controlled Requirements Expression:
domínio a ser modelado é limitado e particionado
em perspectivas, que representam organizações,
homens, entidades de hardware ou software;
• DFD – Diagrama de Fluxo de Dados: concentrase
no fluxo de dados e nas transformações
funcionais dos dados, deixando de lado detalhes
da estrutura de dados;
• Diagrama de Contexto: representação do
sistema por um único processo e suas iterações
com entidades externas;
• ERAE – Entidade-Relação-Atributo-Evento, do
inglês Entity-Relation-Attribute-Event: direciona a
definição dos requisitos do prisma “orientado-acomputador”
para “orientado-a-problema”. Como
resultado: a validação e a completude são
facilitadas;
• KBRA – Assistente de Conhecimento Baseado
em Requisitos, do inglês Knowledge-Based
Requirements Assistant: subsistema do
knowledge-based software assistant, nascido da
aspiração de criar um paradigma de ciclo-de-vida
baseado em conhecimento, capaz de formalizar
os requisitos usados no desenvolvimento;
• MAL - Lógica da Ação Modal, do inglês Modal
Action Logic: definido como uma tentativa de
produzir o formalismo matemático necessário à
especificação de requisitos, sem que para tal
fosse necessário o conhecimento matemático
para escrever e entender as especificações;
• Modelo de Estímulo-Resposta: diagramas de
transição de estado mostram como o sistema
reage a eventos internos e externos;

• Modelo do Processo: mostra as principais
atividades do processo;
• QFD – Quality Function Deployment [11]: um
método de avaliação de qualidade dos produtos
que precedesse ao processo de manufatura e
mesmo ao design;
• Redes de Petri – Petri Nets [12]: formadas por
dois tipos de componentes: a transição,
componente ativo correspondente a alguma ação
realizada dentro do sistema, e o lugar, passivo e
relacionado a alguma variável de estado do
sistema;
• RLP – Requirements Language Processor: na
tentativa de solucionar o problema dos diversos
tipos de leitores, o RLP permite o
desenvolvimento de linguagens formais para os
requisitos de especificação das aplicações;
• RML – Requirements Modelling Language:
Assim como a ERAE, procura dar destaque ao
ambiente do sistema. Sua especificação consiste
numa série de objetos relacionados, que
procuram representar conceitos do mundo real.
Os objetos são agrupados em classes, que
agrupam características comuns;
• SCS – Structured Common Sense: foi
desenvolvido como um método de auxílio ao
desenvolvimento de especificações formais a
partir de conceitos da aplicação. É dirigido para
extração e formalização dos requisitos usando o
MAL;
• UML [13, 16] – Unified Modeling Language [6]:
linguagem para visualizar, especificar, construir e
documentar os requisitos e informações de um
sistema;
• Pontos de Vista, do inglês Viewpoints [8]:
mecanismo que permite considerar aspectos do
sistema percebidos por diferentes requerentes.
Ao se analisar o sistema por vários aspectos,
obtém-se uma especificação mais adequada, a
qual permite um melhor entendimento das
necessidades dos usuários através de cada uma
das atividades do processo;
• Volere [14]: é um método completo de obtenção
de requisitos, baseado nos casos de uso.
A especificação dos Requisitos do SE
dentro da Telemedicina poderia ser concebida
sob qualquer um dos modelos citados. Na
seleção do método, foram considerados os
seguintes pontos: um método que fosse bem
documentado, adaptável ao domínio da
Telemedicina, uma técnica específica a este
domínio, e que tivesse uma seqüência bem
definida e criteriosa. Assim, o método Volere é
um dos métodos que obteve maior aderência aos
pontos citados.
Método Volere
O Método Volere é um roteiro bem
estruturado e completo para obtenção de
requisitos. Baseia-se nos casos de uso, tendo
como finalidade conduzir ao entendimento de
forma mais abrangente, do domínio estudado e
foi o que melhor correspondeu às necessidades.
O esquema simplificado do método é mostrado
na Figura 1. O caso de uso descreve a parte do
serviço, do ponto de vista do usuário. Os
requisitos funcionais descrevem as ações
pertinentes ao sistema. Os requisitos nãofuncionais
descrevem a experiência obtida pelo
usuário durante a utilização do sistema, ou seja
os requisitos não-funcionais são as propriedades
ou qualidades que o sistema computacional deve
conter que o tornam atrativo e próprio ao uso. Os
requisitos não-funcionais não definem ou alteram
a funcionalidade do produto, mas conferem a este
a característica que corresponde à impressão
causada ao usuário pelo seu uso.
Figura 2 – Esquema do Método Volere
O Portal de Qualidade do Método Volere aplicase
aos requisitos obtidos realizando uma série de
testes, que permitem testar conflitos e verificar se
o requisito atende às especificações do sistema.
Este permite que cada requisito tenha
completude 1 , rastreabilidade, consistência,
relevância, corretude, ambigüidade e viabilidade.
Os requisitos são testados contra as restrições
globais do sistema, e é feito um cruzamento
requisito a requisito verificando
incompatibilidades. Em geral, são verificados
conflitos entre requisitos solicitados por diferentes
stakeholders. O resultado final da aplicação da
técnica é o Documento de Requisitos de
Software.
A Análise de Requisitos para o Projeto de
Software Embarcado na Telemedicina
O problema a ser estudado é a aplicabilidade
do software embarcado na Telemedicina, focando
num ambiente humano-computador interoperável,
de baixo custo e com mínimo de falhas. Outros
1 Completude: a definição deve incluir todos os requisitos e restrições
pretendidas pelos usuários do sistema .

importantes fatores a serem adicionados: alta
performance e pervasivo 2 . Buscou-se neste
trabalho focalizar o problema através de duas
lentes de aproximação: a lente da Telemedicina e
a lente da Tecnologia da Informação.
Durante o processo de eliciação 3 de
requisitos é preciso representar o conhecimento
de forma estruturada, por conta das indefinições
do início de qualquer projeto, e muito mais
nebuloso quando tratamos de um contexto como
este. De um lado, a diversidade de artefatos
envolvidos no universo de software embarcado e,
por outro lado, pela riqueza de tipos de
stakeholders envolvidos no processo de eliciação
de requisitos. Podemos utilizar o modelo de
processo de requisitos Volere [14] para a
eliciação de requisitos. Este é um modelo de
processos genéricos, necessários para elicitar,
especificar e rever os requisitos. É um guia de
como descobrir e coletar os requisitos a serem
validados. O modelo foca em conteúdo, ou seja,
as dependências entre os processos que são
definidos pelas interfaces. Este modelo não
implica em nenhuma sequência, e traz o
detalhamento de todas as atividades e conexões
entre eles (ver figura 2). No que tange à fase de
definição dos stakeholders, é importante uma
avaliação criteriosa para identificar as pessoas
que vão ajudar a especificar os requisitos.
Adicionalmente, valemos dos dados estatísticos
populacionais para conhecermos os grupos
potenciais de stakeholders da base populacional
[3] envolvidos. Assim, agregaremos os elementos
estatísticos para complementar o processo.
O protótipo, no entanto, não foi testado pelos
stakeholders, o que traria sem dúvidas benefícios
à análise. A partir de sugestões e críticas
levantadas. No entanto, ocasionaria uma nova
rodada em todas as etapas da Análise de
Requisitos.
Como gerenciar os pontos de vista e conciliar
requisitos funcionais, não-funcionais e
restrições?
Em muitos sistemas, os resultados obtidos
pela computação não são aplicáveis, a menos
que satisfaçam uma série de restrições que
podem ser: performance, tempo de resposta,
número de usuários, normas de segurança, e
normas de qualidade. Engloba também as
restrições que os requerentes estipulam:
compatibilidades do sistema, escolha do
hardware, escolha do sistema operacional, entre
outras. Estas restrições não alteram o
funcionamento geral do sistema, mas restringem
os engenheiros a subconjuntos limitados das
2 Pervasivo: Segundo IEEE, defime computação pervasiva como
sistemas que são móveis e que podem estar em qualquer lugar.
3 Eliciação ou entrevista: é o modo mais comum para adquirir o
conhecimento, consistindo em perguntas formuladas pelo engenheiro
ou analista de conhecimento e respostas dadas pelo especialista.
possíveis implementações. Estas restrições
devem ser consideradas na escolha da solução.
O método QFD – Quality Function
Deployment criada por Mizuno e Akao no Japão
em 1960, concebido para prover um método de
avaliação de qualidade dos produtos que
precedesse ao processo de manufatura e mesmo
ao design [11]. É um método que pode ser
utilizado para gerenciar os diversos view-points
dos stakeholders com os requisitos funcionais,
requisitos não-funcionais e as restrições.
Princípios de uma boa especificação:
1. A separação entre funcionalidade no design é
essencial para uma boa especificação. Uma
especificação é uma descrição “do que” deve ser
feito, sem se importar com o “como” deve ser feito
e com o que deve ser definido pelo design (que é
a próxima “fase”);
2. É preciso utilizar uma linguagem orientada a
processo. Principalmente, no caso de sistemas
dinâmicos (distribuídos) onde a evolução do
sistema depende do estado em que este se
encontra no momento e de sua interação com o
ambiente em torno dos agentes externos. É
preciso distinguir entre a ocorrência de um ou
mais estímulos e o seu processamento. A
especificação de sistemas automatizados é
particularmente sensível a este ponto;
3. A especificação deve englobar todo o sistema,
onde o software (de controle) é apenas um
componente;
4. Uma especificação deve incluir o contexto
(ambiente) no qual o sistema atua;
5. A especificação de um sistema deve ser um
modelo cognitivo. A especificação deve incluir a
racionalização do sistema, que de fato justificam
racionalmente o comportamento do sistema
(como solução de algum problema proposto).
Portanto, é mais que um modelo funcional ou
comportamental, mas um modelo adaptado que
acrescenta a racionalização que demandou este
comportamento;
6. A especificação deve ser operacional. Embora
não seja completa na descrição do sistema
(faltam dados de como o comportamento
pretendido seria realizado), a especificação deve
ter um modelo formal consistente e fechado, de
modo a poder ser utilizada tanto para a
verificação dos requisitos (também um modelo, só
que informal), como também para validar ou
verificar a construção;
7. As especificações são em si um sistema
incompleto e devem ser preparadas para admitir
sua evolução;
8. Especificações devem ser localizadas e
fracamente acopladas.
Discussão e Conclusões
O Método Volere possui uma seqüência bem
definida e criteriosa de etapas e baseia-se nos

casos de uso, tendo como finalidade conduzir ao
entendimento de forma mais abrangente do
domínio estudado. A abordagem por casos de
uso na análise de requisitos conduziu à obtenção
dos requisitos de forma estruturada. É uma forma
de se dividir o sistema em partes menores, de
modo eficiente, pois os casos de uso representam
cada um dos serviços (operações) a serem feitos
pelo sistema em estudo. Os requisitos obtidos
desta forma referem-se ao ator, isto é, o que o
sistema deve fazer para permitir que haja uma
interação satisfatória com os diversos atores.
O processo de obtenção de requisitos seguiu os
passos previstos pelo Volere, mas não foram
estes suficientes, sendo necessária a inclusão de
etapas adicionais:
I. QFD – Quality Function Deployment [14],
método que orienta o discernimento acerca dos
conflitos entre os diversos pontos de vista da
eliciação dos requisitos e restrições;
I. O Diagrama de Contexto mostra os sistemas
adjacentes e sua interação com o sistema
proposto através dos eventos;
III. Os eventos que foram identificados e listados
que serviram de guia para validação dos
requisitos.
Portanto, o conjunto destes métodos contribuiu
para o fechamento dos requisitos de forma mais
consistente, estruturada e de fácil compreensão.
Agradecimentos
Agradeço às pesquisadoras Ilana A.
Souza e a Janaína G. Brizante pela revisão do
artigo.
Este trabalho foi financiado pela FINEP
(Financiadora de Estudos e Projeto), dentro do
Projeto de Tele-saúde em Oncologia.
Referências
[1] Li, S., Xiong Z., Li, T. Distributed cooperative
design method and environment for
embedded system, Computer Supported
Cooperative Work in Design. IEEE
Proceedings of the Ninth, 2005.
[2] MIYAZAKI, M., Future of Telemedicine/
Telehealth/e-Health, Business Briefing:
Hospital Engineering & Facilities
Management, http://devserver3.devstudios.
com/ettri/admin/PDFs/12.pdf.
[3] Instituto Brasileiro de Geografia e Estatística;
Ministério do Planejamento, Orçamento e
Gestão. Estimativas populacionais 1980 –
2010: Brasil, regiões geográficas e unidades
da federação . Rio de Janeiro (Brasil): IBGE;
2004. Disponível em: http://www.ibge.gov.br.
[4] Rocha, H.V., Baranaukas, M.C.C. (2000)
Design e avaliação de interfaces
humanocomputador. Escola de Computação
2000. Departamento de Ciência da
Computação IME- USP. São Paulo.
[5] Hira, A. Y.; Bacic, A. S.; Zuffo, M. K.; Lopes,
R. D.; “Sistema de informação em saúde
baseado no paradigma de componentes e
objetos distribuídos: Um estudo de caso em
Oncopediatria”, CBIS’ 2002 Congresso
Brasileiro de Informativa em Saúde, Natal,
Setembro 2002.
6] Rosa, A.L.M; Souza, I.A; Hira, A. Y.; Zuffo, M.
K.; “Development of a Collaborative
Environment applied to Pediatric Oncology”-
SAC’06, Dijon, France, 23-27, April, 2006.
[7] Cardoso, S.; Sabbatini, R. M. E. ; Marques-
Júnior, A.: Desenvolvimento de um Curso de
Capacitação Docente em Educação a
Distância Em Saúde. Anais da Reunião da
Federação das Sociedades de Biologia
Experimental, Caxambu, MG, Agosto 2001.
[8] Pressman, Roger S. Engenharia de Software.
– 5.ed. – Rio de Janeiro: Mc Graw-Hill, pp.
265-291, 2002.
[9] Balzer, R., Goldman, N.; Principles of Good
software specification and their Implications
for Specification Language, in Software
Specification Techniques, Int. Comp. Science
Series, 1986.
[10] H. Ledang. Formal Techniques in the Object-
Oriented Development: an Approach based
on the B method. In the 11th PhDOOS
Workshop: PhD Students in Object-Oriented
Systems, Budapest (H),
http://www.st.informatik.tudarmstadt.de/phdws
/wstimetable.html, June 18-19,2001.
[11]Mizuno S., Akao Y.. QFD: The Customer-
Driven Approach to Quality Planning and
Deployment. 1994. Translated by Glenn
Mazur.
[12]MURATA, T. Petri net: properties, analysis
and applications. Proceedings of the IEEE, v.
77, n. 4, p. 541-579, 1989.
[13]Larman, Craig. Applying UML and patterns: an
introduction to object-oriented analysis and
design and the Unified Process. – 2nd ed. –
New Jersery: Preintice Hall PTR, pp. 41-44,
2001.
[14]Robertson, Suzanne and James. Mastering
the requirements process. London: ACM
Press, 1999.
[15]Vallius, T.; Roning, J.; Implementation of the
"embedded object" concept and an example
of using it with UML, Computational
Intelligence in Robotics and Automation,
2005. CIRA 2005. Proceedings. 2005 IEEE
International Symposium, June 2005 Page: 6.
Contato
Márcia Narumi Shiraishi Kondo
Núcleo de Telemedicina - Laboratório de
Sistemas Integráveis – Escola Politécnica –
Universidade de São Paulo
Tel.: (11) 3091-9739 ou 5659
E-mail: marcia@lsi.usp.br.