Eliciação e comunicação de requisitos em domínios disjuntos: estudo de caso para automação na área médica

Requirements elcitation and communication in disjoint domains: case study in automation to surgical processes

AUTOMAÇÃO DE PROCESSO

Eliciação e comunicação de requisitos em domínios disjuntos: estudo de caso para automação na área médica

Requirements elcitation and communication in disjoint domains: case study in automation to surgical processes

Ricardo Alexandro de A. Queiroz; José Reinaldo Silva

Universidade de São Paulo -USP, Depto. de Engenharia Mecatrônica e de Sistemas Mecânicos, Av. Prof. Mello Morais, no 2231, 05508-030, São Paulo -SP -Brasil, [e-mail], [e-mail]

RESUMO

O final do século passado foi marcado por um crescente intresse nas fases preliminares do processo de design, especificamente na fase de requisitos e definição do problema. Na área de automação, o gerenciamento de requisitos é determinante para o sucesso dos projetos, embora grande parte do esforço no desenvolvimento de técnicas e métodos ter sido direcionado para as fases posteriores: o design e a implementação. Por não serem formais, os processos de eliciação e análise de requisitos são subestimados por profissionais da área de automação, onde o formalismo é fundamental para a validação dos processos de controle, automação e supervisão. Em especial, quando os ambientes de desenvolvimeno e de aplicação são disjuntos, isto é, usuários e stakeholders pertencem a um domínio com pouca ou nenhuma interseção com a área da engenharia, informática e automação, os processos de eliciação e análise se tornam bastante complicados. Neste trabalho é apresentada uma proposta de sistematização do gerenciamento de requisitos para domínios disjuntos, adaptando técnicas já conhecidas ao processo de prototipagem virtual, consolidado após o início deste século. Um estudo de caso é apresentado onde o desenvolvimento se dá na área de Engenharia de Automação para aplicações em processos pertinentes à cirurgia de catarata. Para aproximar os domínios busca-se uma abordagem mais simplificada das técnicas de prototipagem virtual tornando o processo mais prático, sem no entanto abdicar do formalismo dos modelos. Os dados levantados foram obtidos com a colaboração do Hospital Santa Luzia, Salvador, Bahia, e do Instituto da Visão, UNIFESP, em São Paulo.

Palavras-chave: engenharia de requisitos, domínios dis-juntos, realidade virtual, oftalmologia, automação de processos.

ABSTRACT

By the end of 1990 the academy has experienced a remarkable growing in the interest on early design phases pushed by mass customization. In what concerns automation, requirement is a keyword since the detachment in the mechatronic approach is just the design process, although most of the development effort is still directed to the last design phases: optimization and implementation. In general, control and automation designers underestimate requirements elicitation and analysis, mostly by its semiformal nature. That is understandable, since formal approaches are very important to processes that are supposed to be autonomous.

Especially in the case where the developer and application environment are disjoints, that is, the domain of users and stakeholders is very distinct from the developer domain, elicitation could become a very complex process. In this work it is presented a systematic approach to requirements management in disjoint domains inspired in the known technique of virtual prototyping that appear in the 2000's. A case study is addressed were a requirement elicitation and analysis is made in the domain of medical (ophthalmologic) surgery. To approximate both domains (Medical and Engineering) it is used a practical reduction of the virtual prototyping techniques that makes the process applicable still keeping its soundness. All data used in this work came from an elicitation done at Santa Luzia Hospital, in Salvador, Bahia, and from the Instituto da Visão, UNIFESP, São Paulo.

Keywords: requirements engineering, disjoint domain, virtual reality, ophthalmology, process automation.

1 INTRODUÇÃO

A Engenharia de Requisitos (ER) é uma área de pesquisa de extrema relevância, uma vez que as maiores causas de falhas ocorridas em projetos de engenharia são fruto de erros na fase inicial do processo de aquisição e tradução dos objetivos, necessidades e restrições estabelecidas pelos clientes e/ou usuários do sistema. Sheldon, Kavi, Yu, Brettschneider e Everett (Sheldon et al, 1992) afirmam que 36% dos erros ocorridos em um projeto da Força Aérea Americana estavam relacionados com a interpretação de requisitos e 5% com a falha na aquisição de alguns deles, totalizando 41 % de falha. Steve McConnell e Weinberg Jerry (apud Robertson, 2006) afirmam que esses erros podem chegar a até 60%, todos eles gerados pelo processo de comunicação e transferência de conhecimento entre o cliente e o desenvolvedor (Beyer e Holtzablatt, 1995).

Com este quadro geral, é esperado um crescimento do índice de falha quando os projetos em questão têm domínios dis-juntos, como, por exemplo, nos projetos de automação para a área médica, em especial a área cirúrgica, onde a diferença de linguagens e técnicas (jargões técnicos, métricas, encadeamento de processos, etc.) entre os domínios dificulta o processo de aquisição dos requisitos (Kotonya e Sommerville, 1998). Tais falhas podem inviabilizar a difusão da automação para outras áreas demandantes uma vez que o atendimento completo (ou mesmo parcial) aos requisitos tende a se tornar ainda mais crítico nas áreas distantes da engenharia. Este constitui portanto um problema em aberto de grande relevância para as áreas de automação e mecatrônica.

Entretanto, até este momento, a aplicação da Engenharia de Requisitos (ER) em domínios disjuntos é um assunto pouco explorado, e pouco discutido na literatura (Frey e Dym, 2006). Assim, a proposta deste trabalho é conceber e apresentar um modelo preliminar para a eliciação de requisitos em domínios disjuntos, tomando como exemplo a área médica ciúrgica, e enfocando prioritariamente a visualizaçào de processos, baseado no planejamento de ações de artefatos modelados formalmente (ou aproximadamente) à partir do estudo dos requisitos.

Este processo é equivalente a antecipar a formalização dos requisitos usando recursos e técnicas de prototipagem virtual, isto é, a formalizar demandas, restrições e objetivos, antes mesmo do fechar a especificação do sistema (seguindo uma disciplina recentemente introduzida na engenharia de projetos).

A próxima seção é reservada à apresentação do procedimento padrão da Engenharia de Requisitos. São mencionadas as características, as técnicas, e as limitações envolvidas em cada fase do processo, especialmente para o caso de domínios dis-juntos. O objetivo é propiciar uma melhor compreensão da seção 3, que apresenta o modelo proposto para eliciar requisitos justamente no caso de domínios disjuntos. Na sequência, a seção 4 apresenta a aplicação da proposta em um estudo de caso na área médica, particulamente na cirúrgica oftalmológica. Comenta-se algumas dificuldades enfrentadas, alternativas e soluções para minimizar os efeitos relacionados ao distanciamento entre os domínios. Por fim, na última seção do trabalho são apresentadas as principais conclusões e propostas de trabalhos futuros.

2 ENGENHARIA DE REQUISITOS (ER)

Na literatura existem várias propostas de procedimentos de análise e gerenciamento da ER (Pressman, 2005; Jiang, Eberlin e Far, 2005; Kotonya e Sommerville, 1998). Este trabalho baseia-se nos fundamentos do modelo proposto por Kotonya e Sommerville (1998) que descreve a ER como sendo composta por quatro fases: Eliciação, Análise e Negociação, Documentação e Validação de Requisitos.

A primeira fase, a eliciação de requisitos, tem como finalidade compreender e capturar os requisitos do cliente (stakeholder), as preferências, necessidades, e os limites (constraints) do novo sistema a ser projetado, que em geral resultam da interação do sistema com o seu domínio de aplicação (Nuseibeh e Easterbrook, 2000; Hickey, Davis, e Kaiser, 2003). Esta fase é considerada por alguns autores (Goguen e Linde,1993; Kotonya e Sommerville, 1998; Hickey e Davis, 2002; Robertson, 2006) como sendo a mais crítica dentro do processo da ER: i) pela dificuldade do cliente em descrever seu conhecimento tácito¹ sobre o domínio do problema; ii) devido a divergências entre os pontos de vista dos diversos agentes (classes de clientes) envolvidos; iii) devido a fatores políticos, sociais, psicológicos, legais e financeiros (Goguen, 1996) que se apresentam como restrições; iv) devido à forma dispersa (não estruturada) como são encontrados os conhecimentos explícitos²; v) e pela completa dependência entre o processo de captura e fatores como relacionamento humano (entre engenheiros de requisitos e clientes), comunicação e transferência de conhecimento que são decorrentes da natureza das técnicas convencionais de eliciação de conhecimento (Beyer e Holtzablatt, 1995).

Os métodos e técnicas convencionais aplicados nesta fase são: entrevista (estruturada, semi-estruturada, não estruturada, em grupo), reunião, workshop, brainstorming, diagrama de afinidades, observação, etnografia, análise de protocolo, estudo de documentos, questionário, reutilização de requisitos, grade de repertório, CARD, cenário, JAD (Joint Application Development), protótipo, storyboard, investigação contextual, etc. (Liou, 1990; Sommverville et al, 1992; Goguen e Linde, 1993; Atkinson e Hammersley, 1994; Raghavan et al, 1994; Rudd et al, 1996; Goguen, 1996; Macaulay, 1996; Leite et al 1997; Carroll, 2000; Fook e Abdelouahab, 2001; Preece, Rogers e Sharp, 2002; Hickey, Go e Carroll, 2003; Davis e Kaiser, 2003; Li et al, 2004; Gervasi e Zowghi, 2005; Niu e Easterbrook, 2006; Truong et al, 2006). Este número elevado de diferentes abordagens devese ao fato de que não existe um único método ou técnica que apresente uma solução aceitável para todos os projetos (Macaulay, 1996; Roberston, 2006; Kotonya e Sommerville, 1998). Nuseibeh e Easterbrook (2000), Sutcliffe (1997), Hi-key e Davis (2003), Olson e Moran (1996) afirmam que a escolha de uma destas abordagens depende do tipo de informação que se deseja buscar; do tempo e dos recursos disponíveis; do conhecimento geral do domínio da aplicação; da experiência, habilidade e familiaridade do desenvolvedor em relação às técnicas; da natureza da própria técnica; da disponibilidade de especialistas nos processos pertinentes ao domínio, e da fase em que se encontra o desenvolvedor no ciclo de iterações do gerenciamento de requisitos.

Rudman e Engelbeck (1996), Sutcliffe (1997), Jiang et al (2005) afirmam que o processo de eliciação pode ser mais efetivo com uma combinação das técnicas mencionadas acima, possibilitando uma coleta variada e, conseqüentemente, propiciando uma compreensão ampla da variedade de requisitos que se deseja adquirir. Entretanto, uma combinação direta das técnicas deve ser feita com parcimônia sob pena de ter o tempo de eliciação artificialmente ampliado.

A segunda fase, a de análise e negociação, tem como objetivo solucionar os problemas relacionados a requisitos conflitantes (provenientes de diversas percepções do mesmo problema, ocasionado por diferentes pontos de vista), ou requisitos ambíguos, repetitivos, contraditórios e inconsistentes (Roberston, 2006). Beyer e Holtzblatt (1995) afirmam também que nesta fase é necessário verificar se esses problemas não são influenciados pelo foco do desenvolvedor, isto é, se o mesmo se encontra afinado com o contexto da necessidade do cliente e se não está limitado ou até mesmo convencido a ignorar a experiência do próprio cliente/especialista. Como forma de solucionar estes problemas, o desenvolvedor e o especialista discutem, priorizam e negociam tais requisitos, até que se obtenha um acordo, com possíveis modificações ou simplificações, que não comprometam as necessidades do cliente/especialista (Kotonya e Sommerville, 1998). A proposta desta fase é desenvolver um primeiro esboço de documento de requisitos que seja o mais consistente e completo possível.

Na literatura também são encontradas algumas técnicas que auxiliam esta fase. Estas envolvem desde a criação, representação e análise por diagramas esquemáticos (UML - Unified Modeling Language, Redes de Petri, FSM -Máquinas de Estado Finito, data flow diagrams, e etc.), a representação textual (cenários) ou outras soluções para facilitar a comunicação e formatar percepções do próprio problema ou da solução (JAD, protótipo, etc.). Entretanto, o uso destas técnicas depende da experiência do desenvolvedor e do contexto do problema em apreço. Tanto no caso geral, como para os sistemas automatizados, as Redes de Petri são mais adaptáveis, embora requeiram mais expertize do administrador e analista de requisitos. A captura e representação da dinâmica do sistema é o principal ponto em questão, em especial para sistemas discretos autônomos.

A documentação, fase posterior à análise e negociação de requisitos, tem como objetivo achar uma representação semiformal adequada para que, ao mesmo tempo em que capturam os requisitos seja possível representá-los de forma clara. Em geral, a melhor forma de representação é através de uma linguagem que seja compreendida por aqueles envolvidos no processo de ER (e também pelos especialistas³ e usuários). Kotonya e Sommerville (1998) afirmam que o melhor meio de documentar requisitos é através da linguagem natural. Entretanto, alguns autores afirmam que esse tipo de linguagem pode favorecer múltiplas interpretações (Gervasi e Zowghi, 2005; Li et al, 2004). Leite et al (1993) contornam este problema definindo precisamente um vocabulário a ser utilizado nas especificações dos requisitos. No entanto, para projetos complexos e/ou de grande porte, a extensa rede semântica que relaciona estes termos e/ou o grande número destes dificultam bastante uma interpretação segura. Segundo alguns autores (Kotonya e Sommerville, 1998; Peters et al, 2001) uma forma de maximizar a compreensão dessas informações em pouco espaço é através do uso de diagramas, ou um con-junto de modelos gráficos, ou ainda uma coleção de cenários e equações. No final, um bom documento de requisitos deve ser claro, sem ambigüidades, completo, correto, consistente, viável e conciso (Robertson, 2006).

Finalmente, a última fase, a validação, consiste em verificar e confirmar se o documento de requisitos proposto na fase anterior de fato contempla as necessidades do cliente/usuário. Esta fase tem por objetivo detectar a falta de consistência, omissão, ambigüidade e não-conformidade nos requisitos já representados e detalhados (Pressman, 2005). O grande desafio da fase de validação é demonstrar que a especificação dos requisitos do sistema está correta. Algumas técnicas auxiliam esta fase, tais como: revisões de requisitos, validação por prototipagem, teste de requisitos, validação por modelo, etc. (Kotonya e Sommerville, 1998). Como nesta fase em geral não se tem ainda uma representação formal ou especificação do projeto, mesmo em projetos de automação, a validação tem um papel singular na correção dos rumos do projeto⁴. Um bom exemplo são os projetos de automação residencial ou nos projetos motivados por necessidades em outros domínios de aplicação fora da Engenharia (aplicações médicas, bancárias, transporte público, etc.).

Este processo de gerenciamento da ER é repetido em um ciclo fechado até que o objetivo final seja alcançado: a obtenção de um documento de requisitos consistente, sem falhas, conflitos ou ambigüidades (Macaylay, 1996).

3 O MODELO PROPOSTO

Todas as dificuldades mencionadas anteriormente se tornam ainda maiores quando o problema é especificar requisitos de sistemas automatizados (discretos) para aplicações cujo domínio está distante dos processos da engenharia. Estes domínios são ditos disjuntos, explorando o fato de que não existe uma interseção substancial de termos e conceitos entre estes que possa ser usada como base de descrição.

Um estudo de caso para a área médico-cirúrgica será analisado, onde algumas dificuldades se destacam: a primeira delas está relacionada com as dificuldades presentes no próprio uso do processo de gerenciamento da ER, mencionado sucintamente na seção anterior. A segunda se baseia nas restrições e relações através das quais o domínio da aplicação influencia o processo (problemas de comunicação). Isto porque não apenas a diferença de linguagem é um entrave (na verdade talvez seja o problema menor), mas a praxe, os procedimentos de referência, são diferentes, assim como os conceitos fundamentais, as relações de causa-efeito, as métricas, etc.

O primeiro ponto crítico a ser mencionado refere-se à própria dependência da relação, comunicação e transferência de conhecimento entre o cliente/especialista e o desenvolvedor. Este fato pode ser minimizado através do uso de técnicas ou métodos de eliciação de requisitos que desenvolvam uma relação de aproximação maior com o especialista. Entretanto, quando se tenta capturar o conhecimento tácito do domínio de aplicação proposto, verifica-se que existe uma categoria de conceitos (no estudo de caso em apreço) que estão relacionados ao domínio sensorial, ou seja, conceitos baseados na informação táctil, visual e auditiva do cliente/especialista, e que são explorados em toda atividade cirúrgica, seja qual for a especialidade, mas que são interpretados de forma muito diferente na Engenharia. Esses requisitos se tornam muito difíceis de serem plenamente capturados, embora sejam essenciais para o sucesso da empreitada, uma vez que mesmo uma metáfora entre conceitos é de eficiência duvidosa (Silva, 1992).

Alguns autores (Preece, Rogers e Sharp, 2002) afirmam que, diante de um domínio de natureza sensorial, faz-se necessário desenvolver novos padrões para o reconhecimento do problema. Neste caso, o processo de eliciação, documentação e validação seriam fortemente atingidos pela introdução de relações sensitivas e tácteis. Há um hiato na literatura sobre a proposição destes novos padrões, embora o número de projetos com domínio disjuntos tenha aumentado significativamente nestes últimos anos.

O segundo ponto crítico refere-se ao fato de que mesmo o desenvolvedor sendo de uma área correlata a do cliente/especialista (stakeholder), o processo de conduta da ER é ainda árduo como é o caso do green automation (automação direcionada à preservação do meio ambiente) ou mesmo um sistema automatizado de defesa de navios de combate. Caso as áreas de atuação se distanciem conceitualmente, como no estudo de caso apresentado neste trabalho, a complexidade na captura e análise dos requisitos aumenta exponencialmente com a falta de conhecimento do domínio de aplicação. Por se tratar de um assunto novo, pouco discutido na literatura (Frey et al, 2006), a estratégia adotada para abordar este problema foi desenvolver um modelo mais flexível do que a estrutura convencional de interpretações de dados fornecida pela Engenharia de Requisitos (ER), apresentada na seção 2. Ao invés de modelos prescritivos, foi utilizado o fluxo de informações do domínio de aplicação adquirido, para verificar qual a melhor forma de gerenciamento que poderia ser empregada para esta situação de domínios disjuntos.

O terceiro e último ponto crítico a ser mencionado, refere-se a influência que o domínio de aplicação exerce sobre o processo de automação e sobre os procedimentos em geral. Ou seja, o quanto o modelo será adaptado às restrições do domínio da aplicação. A primeira delas refere-se ao estilo de técnica utilizado para negociar e validar requisitos, que está relacionada com a própria distância entre os domínios, resultando na postura mais dependente do conhecimento nãoformal (no sentido de não ser um conhecimento passível de ser colocado em uma representação matemática) do cliente/especialista. Por outro lado esta mesma distância coloca o engenheiro em uma posição defensiva por não poder enquadrar de pronto o conhecimento eliciado em um processo seqüencial. Este processo fica ainda mais complicado se for acrescentado a isso uma certa indisponibilidade de tempo por parte do especialista. Na literatura encontram-se citações sobre esses tipos de caso para domínios não-disjuntos (Kotonya e Sommerville, 1998). Entretanto não se comenta como contornar o problema.

O problema portanto se resume a superar esta fase inicial onde a distância entre os domínios de atividade do especialista e do desenvolvedor influenciam mais a relação entre estes. Como o gerenciamento tem como objetivo uma especificação final sem conflitos, isto é equivalente a requerer que o processo inicial de eliciação seja rapidamente convertido em uma representação de processo que atenda às necessidades do desenvolvedor, mas que não se distancie do especialista que ainda deve validar este mesmo processo. A proposta se-ria representar os requisitos em uma linguagem no mínimo semi-formal, através de metáforas validades por representações visuais, mais próximas do cliente/especialista, sem que haja perdas nesse processo de transferência semântica. A combinação de elementos subliminares (sensitivos, tácteis, etc.) e a representação formal de processos é a novidade na proposta.

A Figura 1 apresenta uma proposta de modelo que representa esta combinação de elementos. O modelo consta de seis fases, duas a mais que no processo da ER apresentada na seção 2. As fases extra serão dedicadas a combinar o processo convencional com um fase de aprendizado (B), e de um processo de integração dos requisitos (C).

Nas subseções a seguir são apresentadas e justificadas cada uma das seqüências de atividades do modelo.

3.1 Fase de Investigação e Análise de Requisitos - (A)

A investigação e análise de requisitos (A) é a primeira fase do modelo a ser realizada. Possui as mesmas características e atividades do processo de Engenharia de Requisitos (ER) (Kotonya e Sommerville, 1998), com exceção da fase de negociação que é separada da fase de análise de requisitos. Esta por sua vez é transferida para a fase (E) do modelo (figura 1), onde acontece uma reunião formal direta com o especialista. As demais fases a serem apresentadas no decorrer desta seção pressupõem um contato informal com o especialista quando se aplicam as técnicas de eliciação de requisitos propostas para o modelo.

A finalidade da fase (A) é ainda a eliciação clássica de requisitos, como descrito por Kotonya e Sommerville (1998): compreensão do domínio da aplicação, do problema, do negócio e das necessidades e restrições do especialista.

Entretanto em domínios disjuntos este processo clássico não é inteiramente satisfatório porque, dada a distância entre os domínios, o entendimento dos conceitos levantados pelos métodos listados à esquerda da figura 1 fica comprometido. O próprio especialista usualmente omite detalhes que considera óbvios mas que, especialmente neste caso, podem ser muito importantes para completar o quadro e para um entendimento completo do problema. Por fim, além de comprometer o processo de análise dos requisitos, a confirmação pelo especialista (anterior ao processo de negociação) fica também comprometida por terem o especialista e o desenvolvedor diferentes métodos de aferição, métricas, intuição, etc.

Nesta fase, realiza-se também a identificação dos especialistas (Alexander e Robertson, 2004). Uma etapa extremamente fácil de ser realizada, em vista do contexto reduzido em que o modelo foi proposto, isto é, o número de agentes foi reduzido a uma amostragem menor composta somente daqueles que detêm o conhecimento total ou parcial sobre o domínio de análise. Na Figura 2 é apresentada uma representação por zonas/camadas dos agentes que poderiam auxiliar a aquisição dos requisitos.

Com mostrado na figura 2, os agentes de apoio ao processo cirúrgico (auxiliares, enfermeiras, instrumentadores) ficaram inicialmente de fora do escopo do processo de eliciação, que se concentrou basicamente nos médicos residentes e em especial em um conjunto centrado no cirurgião-chefe.

Em relação às técnicas de eliciação abordadas para o contexto, define-se o uso básico de cinco técnicas (observação, etnografia, analise de protocolo, documentação e entrevista semi-estruturada -não formal), que foram selecionadas dentre as vinte e duas técnicas mencionadas na seção 2. O critério de escolha baseou-se nas características e nos pontos críticos discutidos no início da seção 3. Maiores detalhes podem ser encontrados em (Queiroz, 2007). Entretanto, nenhuma dessas técnicas satisfaz a discussão sobre a aquisição do senso de percepção do domínio sensorial (tátil, visual e auditiva). Para tal, a solução adotada é discutida na fase (B) do modelo, denominada de fase de Aprendizado, apresentada a seguir.

3.2 Fase de Aprendizado - (B)

No caso de domínios disjuntos, o maior problema no processo de aquisição dos requisitos é a captura daqueles conceitos que não possuem representação formal ou semi-formal direta (ou que não são nem mesmo verbalizados). Estes estão relacionados ao domínio sensorial do especialista, isto é, ao seu senso de percepção. Seguindo a analogia de Preece, Rogers e Sharp (2002), mencionada na seção 3, este processo foi implementado buscando identificar, dentro do domínio da aplicação, as principais referencias, modelos e o processo de aprendizado do próprio especialista na área (médicos residentes). Para tanto foi necessário imergir nos processos e conceitos do especialista, isto é, no domínio do processo cirúrgico de catarata. A metodologia empregada pode ser qualificada como pesquisa-ação, exploratória, e visa aquilatar a real influência destes conceitos inerentes à área do especialista. Naturalmente não é viável propor que este método imersivo seja incorporado ao trabalho das equipes de projeto em engenharia em geral. A aplicação do método imersivo, neste caso serviu como base para a elaboração de um método mais sistemático para lidar com domínios disjuntos onde um dos domínios de referencia pertence à Engenharia. O aprendizado foi o processo mais geral encontrado para reunir, com a menor possibilidade de falha um conjunto mais completo de conceitos de referência do domínio dos especialistas, incluindo aí a interação com especialistas mais experientes durante o processo cirúrgico, a análise de vídeos, participação em aulas práticas e expositivas, treinamento em laboratórios, com cadáveres, e animais. Uma vez detectado o conjunto principal de conceitos de referência foi possível analisar o efeito que o mal entendimento destes poderia provocar no processo de eliciação e propor uma forma mais pragmática de contornar este problema.

De acordo com a ordem cronológica de atividades apresentadas no modelo proposto, Figura 1, a fase de aprendizado (B) não se inicia simultaneamente com a atividade de investigação e análise de requisitos (A). A razão é que a atividade (B) exige uma base de conhecimento prévia sobre os procedimentos, hábitos e cultura dos especialistas. Portanto, depende de uma coleta inicial de informações.

Pela importância estratégica desta fase (que constitui uma das bases para a pesquisa) três aspectos podem ser discutidos. O primeiro se refere ao ponto de parada (sempre sutil em processo de eliciação de requisitos) isto é, quando se deve interromper o processo. Dado o caráter exploratório da pesquisa escolheu-se o ponto de parada quando foi atingido um ponto de saturação, quando o desenvolvedor não estava mais adquirindo conhecimentos novos ou que as informações e/ou os requisitos passaram a se repetir (conceito baseado na técnica de etnografia). Além disto, a quantidade de dados gerados neste processo modifica as informações obtidas da fase (A) o que torna necessária um processo de integração e verificação de consistência, discutido na seção seguinte.

O segundo aspecto se refere a realimentação do cliente/especialista, processo fundamental para mantê-lo conectado e dirimir os problemas de acessibilidade. Assim, em um processo mais sistemático do que a abordagem imersiva seguida, é preciso que o cliente/especialista acopanhe o processo de inerpretação das referências básicas da fase B. O terceiro e último aspecto se refere ao tempo que o especialista precisa disponibilizar para orientar o desenvolvedor nos procedimentos laboratoriais e ensiná-lo a forma correta dos movimentos e utilização dos instrumentos. Entretanto, este tempo excessivo aconteceu somente na metologia exploratória onde foi preciso ter certeza de não ter deixado nenhuma referência importante sem a devida consideração e não deve se repetir em um método mais sistemático. Nesse caso, a existência de bibliotecas do tipo Wiki (já validados pelo cliente/especialista) é recomendado para integrar os processos de eliciação e podem otimizar o tempo gasto nesta pesquisa.

3.3 Processo de Unificação e Correlação - (C)

O processo de integração e correlação, fase (C), é uma atividade que ocorre seqüencialmente às fases (A) e (B). Tem como proposta correlacionar e unificar as informações e/ou requisitos adquiridos nestas fases anteriores, retificando os requisitos eliciados na fase convencional a partir das referências capturadas na fase B e produzindo novos requisitos para análise.

O processo de integração é baseado no grande volume de informações que os métodos observacionais (etnografia, observação e análise de protocolo) desenvolvem, e que estão correlacionadas com a investigação dos novos requisitos, proporcionados pelo domínio sensorial (B). O objetivo é unificar os dados que foram adquiridos na fase (A) e na fase (B), correlacionando-os de modo a conceber informações mais abrangentes e corretas já em uma representação semi-formal.

Caso o processo de integração e unificação, fase (C), não seja realizado de forma sistemática, a característica disjunta aparecerá na forma de uma discrepância entre os conjuntos resultante das fases (A) e (B), o que fatalmente levará a uma especificação errada do sistema ou artefato em questão. Note-se que necessariamente esta fase inclui parte da análise dos requisitos, pelo menos no que se refere à análise de consistência entre estes.

3.4 Fase de Seleção de Informações e Requisitos - (D)

Como a fase (C) já incorporou parte da análise convencional de requisitos, caberá à fase (D) a inclusão e análise de consistência com os requisitos não-funcionais (normas, leis, regras regionais ou praxes). Nesta fase se faz a integração e unificação final dos requisitos que comporão o primeiro esboço do documento de requisitos que uma vez validados e negociados passarão a compor a especificação. Também nesta fase se espera sintetizar o documento de requisitos eliminando as redundâncias e repetições, ou mesmo aspectos simplesmente derivados de requisitos mais gerais.

Assim, a fase (E) que vem logo em seguida terá que lidar com o problema da verificação, que por sua vez traz de volta o problema da distância entre os domínios, e da comunicação entre o desenvolvedor e o cliente/especialista. Neste caso a intermediação de uma representação em modelos formais de visualização (no mesmo formato da prototipagem virtual) é a forma de reduzir esta distância. No entanto isto irá requerer um esforço redobrado do desenvolvedor como mostrado na Figura 3 e discutido na próxima seção.

3.5 Ciclo de Negociação e Validação - (E)

O ciclo de negociação e validação é de fato a fase onde se trabalha diretamente com o especialista para apresentar e discutir os resultados do levantamento e análise de requisitos. Esta fase fecha o ciclo de eliciação e análise de requisitos, e sintetiza o que se chamará de especificação do sistema.

Apesar de existirem outras fases de interação entre desenvolvedor (que elabora os requisitos) e o especialista, (stackholder) nesta fase, a comunicação assume um papel de destaque, já que o entendimento do modelo até então elaborado pelo desenvolvedor deverá influenciar o assentimento do especialista e será tomado como um sinal para a continuidade do projeto com os requisitos eliciados até então. Portanto, como mostrado na Figura 3, cabe ao desenvolvedor controlar a transferência semântica do modelo no domínio da Engenharia para uma linguagem interativa (processo 1) e daí para o especialista (processo 4) que deve responder nesta mesma linguagem (processo 2), cabendo ainda ao desenvolvedor a transferência de volta ao domínio da Engenharia (processo 3).

Portanto, a linguagem interpretativa proposta é usada como um construtor de metáforas (Silva 1992), capaz de representar tanto aspectos do domínio da Engenharia quanto aspectos mais sensitivos e tácteis do domínio do especialista (no caso específico da área médica). No trabalho desenvolvido até aqui, foi usada uma linguagem gráfica representada por sketchs, que simulavam intervenções do cirurgião, representados no MatLab. Ressalte-se que tanto o modelo do olho humano quanto os movimentos representados, foram rigorosamente modelados pelo desenvolvedor (no caso os autores deste trabalho) enquanto que a anuência (ou correção) do especialista neste caso seria dada verbalmente, o que seria sintetizado em uma nova visualização feita pelo desenvolvedor (em caso de correção) ou na representação corrente (em caso de anuência). Para isto, foram utilizados conceitos da computação gráfica, em especial a realidade virtual, para desenvolver um ambiente tridimensional, não imersivo, do órgão em estudo em conjunto com os movimentos dos instrumentos cirúrgicos (base para aplicação dos requisitos).

O processo geral de negociação é esquematizado na Figura 3 a seguir.

1. atividade destinada a transferir a semântica dos requisitos já eliciados para uma representação virtual animada customizada para atender às referências de medida, movimentação e espaço do usuário. Esta transcrição é realizada através do desenvolvimento de um modelo tridimensional do órgão em estudo e dos movimentos dos instrumentos cirúrgicos no estudo de caso utilizado;

2. atividade na qual o especialista no domínio da aplicação analisa, negocia e confirma se o que está representado no ambiente virtual está correto ou não, podendo acrescentar novas informações.

3. atividade em que o desenvolvedor captura as informações transmitidas pelo especialista e as interpreta para o domínio da Engenharia de Requisitos;

4. atividade na qual o desenvolvedor comunica o modelo virtual até então desenvolvido ao especialista, podendo acrescentar informação que induza este especialista a dar sua opinião sobre o processo, utilizando as referencias já obtidas na fase (B) representadas virtualmente.

O termino desta fase (E) acontece no momento em que não existe mais nenhuma alteração a ser desenvolvida nos requisitos. Isto é, quando os mesmos estão coerentes do ponto de vista do especialista e podem ser formalizados em um documento final, fase (F). Esta forma de representação permite que o especialista valide um grande volume de requisitos em um período de tempo relativamente curto, uma vez que os requisitos corretos e validados (apesar da distância entre os domínios) encontram-se na sua linguagem usual. Além disto, proporciona que de ambos os lados, da engenharia e do domínio de aplicação, todos entendam corretamente os resultados obtidos.

3.6 Documentação de Requisitos - (F)

A elaboração de um documento de requisitos é a ultima fase do modo proposto e coincide com a fase clássica já mencionada. Este documento marca o final do processo e também a completa passagem de todas as informações, incluindo os rationales, isto é, as razões por trás das decisões tomadas em comum acordo com o cliente/especialista durante a negociação.

Na literatura, vários autores afirmam que a linguagem a ser utilizada nesse documento deve ser entendida por todos aqueles envolvidos no processo. Isto porque todos os modelos de ciclo de vida são unânimes em apontar para uma revisão dos conceitos previamente acordados no processo de gerenciamento de requisitos (Jarzabek and Zhang, 2001). No presente trabalho evitou-se o aprofundamento desta discussão, dado que isto levaria obrigatoriamente a uma escolha da linguagem de representação dos requisitos antes de analisar o processo em si. Assim, a documentação dos requisitos foi feita em linguagem natural estruturada operando manualmente um mapeamento entre seções desta e os arquivos de realidade virtual do MatLab. Naturalmente, este processo deve ser total ou parcialmente automatizado no futuro, e inserido nos ambientes de projeto. A conclusão extraída deste trabalho é que um mapeamento automatizado entre especificação formal e uma linguagem interpretativa de interação com o especialista seria, especialmente para domínios disjuntos, um elemento essencial para os atuais domínios de projeto. Este ponto será novamente abordado nas conclusões do presente trabalho.

4 APLICAÇÃO DO MODELO

O estudo de caso proposto para testar o modelo foi na área cirúrgica oftalmológica e contou com o apoio de duas instituições. Um hospital, Hospital Santa Luzia, localizado em Salvador - Bahia, e uma Instituição de Ensino e Formação de Médicos Profissionais na área oftalmológica, Instituto da Visão - UNIFESP, localizado em São Paulo - SP, que proporcionou práticas laboratoriais para a aquisição do domínio sensorial, fase (B) do modelo proposto.

A seguir é apresentado o estudo de caso realizado, discutindo-se os pontos positivos e negativos de cada uma das fases do modelo com base na experiência prática adquirida.

4.1 Fase de Investigação e Análise de Requisitos - (A)

Como mencionado na seção anterior, esta fase é constituída do levantamento de requisitos propriamente dito, que foi feito através de entrevistas com os especialistas, primeiramente na base do "chief programming", isto é trabalhando com o especialista mais destacado, no caso cirurgiões-chefe dos respectivos hospitais. Verificado o caso extremo e delimitado o escopo dos requisitos, a entrevista foi então ampliada para capturar outros pontos de vista dos demais membros da equipe (assistentes e outros cirurgiões), e finalmente do pessoal de suporte (enfermeiras, etc.).

Posteriormente, foram acompanhados cerca de 450 casos cirúrgicos nas duas instituições mencionadas, estendendo bastante o processo de aprendizado que se mescla a este processo clássico. O objetivo, no primeiro instante, foi compreender, identificar limitações, restrições e as tarefas envolvidas no domínio de aplicação, do ponto de vista do desenvolvedor, o que facilita o diálogo com o especialista. A falta de uma ferramenta de apoio se fez sentir tão logo os requisitos coletados atingiram um número considerável. Entretanto, o propósito de não comprometer a pesquisa com um modelo específico de ciclo de vida ou mesmo com uma estratégia de gerenciamento particular de requisitos prevaleceu. Naturalmente, a proposta deste trabalho não é repetir o processo nestas condições, e sim, à partir dos dados levantados, propor um método para tratar domínios disjuntos em algum ambiente consolidado, como o Rational ou outro ambiente que implemente o RUP (Rational Unified Process).

Como compensação à falta de um ambiente, utilizou-se de outros meios de aquisição de dados como a gravação em vídeo. Foi registrada tanto a visão interna do microscópio do especialista, como a visão externa dos movimentos de suas mãos (fato ocasionado devido ao problema do registro de informações ficar limitado apenas ao foco da câmera).

A utilização de gravações de vídeos nesse domínio de aplicação foi benéfica. Análises posteriores permitiram a captura de requisitos que não tinham sido observados de forma direta. Foi possível comparar os movimentos utilizados por diferentes especialistas durante a cirurgia, além de observar uma série de conhecimentos tácitos. Alguns vídeos também foram gravados utilizando a técnica de análise de protocolo em conjunto, ou seja, o especialista executa os procedimentos e, ao mesmo tempo, comenta e justifica as atividades que estão sendo realizadas. Os vídeos são ricos em informações e despertam uma série de curiosidades e questionamentos. A desvantagem está no grande número de horas/dias para realização da análise e organização do grande volume de dados adquiridos (não estruturados). As dúvidas e questionamentos foram elucidadas com o auxílio de outra técnica: a entrevista semi-estruturada não formal. Esta permite que o especialista se sinta mais a vontade para falar sobre o questionamento do desenvolvedor, desde que este último mantenha o controle da entrevista.

O processo de eliciação inicial foi aprofundado através da técnica de etnografia, ou seja, por uma observação mais profunda do processo, e por um estudo minucioso das atividades do especialista, em especial dos movimentos e do acesso aos recursos durante a cirurgia. Os casos cirúrgicos foram analisados mais de perto, acompanhados pela segunda visão do microscópio, o que proporciona uma visão mais apurada do processo cirúrgico, com a introdução da visão estéreo (sensação de profundidade).

Alguns autores (Kotonya e Sommerville, 1998) entre outros, afirmam que em um processo de gerenciamento padrão, o especialista pode se retrair ou se deixar influenciar com a presença do desenvolvedor no seu ambiente de trabalho. Na estudo de caso em questão não foi detectada esta retração nos especialistas. É possível que este fator esteja relacionado com a experiência, prática e segurança no domínio da aplicação. Além disto, o cliente/especialista principal também está acostumado com a presença de outros indivíduos ao seu redor no ato da realização do seu procedimento, uma vez que é também professor.

A distância entre domínios, que se reflete particularmente na comunicação, foi minorada pelo uso consciente do paralelismo entre o processo convencional (clássico) de eliciação de requisitos por entrevista direta com o processo de aprendizado, tanto pela observação de casos como pelo estudo do processo de treinamento dos cirurgiões (que será mostrado na seção seguinte). Isto deixou os especialistas bem mais à vontade e permitiu fossem observados em estado natural, sem uma pressão extra por parte do desenvolvedor. Registre-se uma diferença, embora sutil, entre o especialista que trabalha diretamente no assunto e outro que é professor (titular) da UNIFESP. Embora ambos tenham se esforçado para facilitar a comunicação, processos de transferência semântica são mais familiares a quem trabalha também com ensino, o que tem que ser levado em conta no processo de generalização dos resultados obtidos deste estudo de caso. O processo etnográfico também se encaixou muito bem neste caso e pode ser sem ressalvas recomendado para processos de domínios disjuntos.

Aspectos já conhecidos e considerados triviais no processo de eliciação também aconteceram neste estudo de caso com domínios disjuntos, só que com maior intensidade: por exemplo, a densidade de informação verbalizada ou a omissão de detalhes considerados óbvios pelo especialista. Neste caso, a da fase de aprendizado (B) contribuiu bastante, não apenas como um método para capturar as referências do cliente/especialista mas como um modelo alternativo para a correção dos requisitos capturados pelo método convencional.

Por fim, um último ponto a ser discutido (também inserido em qualquer processo de elicação) refere-se a diferença de pontos de vistas de diferentes especialistas. Este fato, natural em todo processo de eliciação teve neste estudo de caso um tratamento diferenciado, motivado pela análise prévia dos agentes, representados, na Figura 2. Desta figura se concluiu que a abrangência do conhecimento aponta como determinante a posição do cirurgião-chefe sobre o processo (com relação aos assistentes e residentes) e complementar com relação ao pessoal de apoio. Assim, para os aspectos inerentes ao processo cirúrgico e para a análise da possibilidade e das alternativas de automação deste processo foi tomado como referência a opinião de três experientes cirurgiões, tendo um deles em torno de trinta mil cirurgias realizadas e um ciclo atual de duzentas operações por mês (Dr. Lincoln Lemes Freitas, chefe do setor de catarata do Instituto da Visão UNIFESP).

Tomando-se como base este cirurgião a referência de desempenho do processo automatizado seria a execução de uma cirurgia bem sucedida em 5 minutos, o que torna um processo de robotização baseado em manipuladores bastante questionável.

4.2 Fase de Aprendizado - (B)

Seguindo o modelo proposto, a fase de aprendizado foi desenvolvida praticamente em paralelo com o processo de eliciação clássico.

A primeira atividade realizada nesta fase foi a identificação dos meios que a instituição de ensino (UNIFESP) disponibilizava para instruir os especialistas. Foi realizada uma imersão especialmente profunda para o estudo de caso (não para a composição do método proposto mas para validá-lo absorvendo informação o mais consistente possível), utilizando a estrutura laboratorial e a programação de cursos de treinamento normalmente ministrados aos candidatos a cirurgião. Esta imersão permitiu detectar in loco algumas nuances e situações a que estará submetido o especialista e sua real necessidade de assistência, além de permitir, no mesmo processo, a captura do ponto de vista do pessoal de apoio. O experimento no caso foi o de praticar o processo cirúrgico de catarata em olhos de porcos.

Nas atividades laboratoriais foram feitas as avaliações sensoriais e de referência que foram mencionadas anteriormente como pertencendo ao processo de eliciação (Fase B) e que são de fundamental importância para se ter uma medida de precisão de instrumentos e eventuais dispositivos de apoio em um processo de automação. Verificou-se que esta sensibilidade transcende em muito à avaliação numérica (atribuição de valores segundo uma métrica) tão comum no domínio da Engenharia. Assim, um processo de entrevista onde

o especialista (particularmente um que não seja o cirurgião chefe) seja induzido a declarar valores, mostrou-se incerto e pouco confiável (embora o desenvolvedor da área de engenharia sempre insista neste preciosismo).

A execução das atividades (A) e (B) em paralelo possibilitou também ao desenvolvedor observar um conjunto de requisitos na fase (A) e experimentá-los na prática laboratorial. O objetivo foi o de avaliar o domínio sensorial, as métricas utilizadas, o senso de percepção sobre dados importantes, e especialmente, a capacidade de aquisição destes dados durante o processo cirúrgico.

Em resumo, esta fase proporcionou a aquisição do senso de percepção, observações e sensações envolvidas no domínio da aplicação, além de obter aptidões extra, conhecimento, habilidade, experiência e conseqüentemente maturidade para compreender e discutir com o especialista o procedimento cirúrgico, além de buscar aqueles requisitos difíceis de serem verbalizados. Por outro lado, nesta primeira fase do trabalho o conhecimento sobre a aplicação foi adquirido de forma muito subjetiva, exatamente para evitar qualquer corte prévio que pudesse prejudicar o próprio estudo de caso. A conclusão geral é que a imersão é importante quando se trata de domínios disjuntos mas deve ser minimizada e programada com cuidado no processo de gerenciamento de requisitos.

4.3 Processo de Integração e Correlação - (C)

O processo de integração e correlação é a fase que se sucede às atividades das fases (A) e (B), lembrando muito a estratégia prescrita no método unificado. No estudo de caso foi confirmada a conveniência de se ter uma defasagem entre a fase de eliciação convencional e a fase de aprendizado, que são separadas pela análise dos agentes e dos seus pontos de vista (Figura 2). Esta classificação prévia dos agentes facilitou e tornou mais objetivo o processo de aprendizado na medida que foi possível estabelecer objetivos e metas no que se pretendia extrair de cada um destes agentes, assim como no processo de composição dos pontos de vista.

Outro aspecto importante e que não havia sido previsto na elaboração do método foi que, quando da paralelização efetiva dos processos, a fase de aprendizado serviu já como filtro para detectar incorreções e omissões nos requisitos extraídos pelos métodos convencionais, antecipando parte do que seria a integração. Entretanto note-se que este processo é localizado e pertinente a requisitos funcionais. Mesmo assim, uma fase de integração mais abrangente se faz necessária e é onde questões mais sutis, relacionadas com as referencias dos clientes/especialistas podem ser unificadas com os requisitos funcionais e não-funcionais.

Pode-se concluir desta atividade que pela sua natureza esta fase deveria ser particularmente contemplada pelos ambientes de apoio ao projeto, embora sua importância tenda a se reduzir quando os domínios do desenvolvedor e do especialista forem muito próximos.

4.4 Fase de Seleção de Informações e Requisitos - (D)

Na fase (D) o objetivo foi o de selecionar um número de informações e/ou requisitos, resultantes da fase (C), para alimentar a fase de negociação. Portanto a questão básica nesta fase são os critérios de importância (saliência) que norteiam esta seleção de requisitos. Em uma primeira abordagem deve ser colocado como primeiro critério a escolha dos requisitos que apresentarem conflito entre diferentes pontos de vista de especialistas. Segundo, devem ser escolhidos aqueles requisitos para os quais não foram resolvidos os conflitos levantados entre as fases (A) e (B), ou seja, aqueles em que as fases de aprendizado e etnográficas apontaram conflitos que não foram satisfatoriamente correlacionados na fase (C). Seguem os requisitos cuja fase etnográfica aponta como incompletos ou com lacunas não explicadas. Finalmente, a cada ciclo, se apresenta ao especialista o modelo elaborado até então, de modo que este possa dar um retorno sobre pontos que faltam ou que são importantes e não foram escolhidos pelo desenvolvedor.

No estudo de caso, a falta de um ambiente de apoio não se fez sentir de maneira muito forte porque não existe nenhum ambiente que dê um suporte muito substancial ao processo descrito acima (além de recursos de interface). Na prática, para o caso da cirurgia de catarata, a imersão muito forte suplantou as dificuldades desta fase, já que tornou o processo muito informal e misturado às fases (A), (B) e (C). Ainda assim, a necessidade de se ter uma negociação levou a que pelo menos os dois primeiros critérios de seleção fossem seguidos à risca. Na fase final do ciclo, a apresentação de um modelo mais acabado foi feita utilizando os recursos de realidade virtual. Isto acentuou demais a importância dos movimentos em relação ao conjunto do processo cirúrgico e das questões de posicionamento e acesso a recursos. Felizmente a experiência do próprio especialista mitigou este aspecto e acabou por trazer o processo de volta ao seu curso.

4.5 Ciclo de Negociação e Validação - (E)

Como discutido na seção 3 deste artigo, o ciclo de negociação e validação é a parte mais importante em termos estratégicos, porque direciona o processo de eliciação e de consolidação dos requisitos, assim como a sua convergência para se tornar o documento inicial de especificação.

A proposta em geral é ter um mecanismo gerador de metáforas que tem como domínio fonte os requisitos levantados até então, e portanto pertencentes ao domínio do desenvolvedor, e como domínio imagem ou alvo, o domínio do especialista. Neste caso, deve-se usar alguma representação facilmente interpretável pelo especialista. No caso de domínios disjuntos tem-se de fato uma metáfora pela distância entre estes dois domínios (Silva, 1992). Se os domínios não forem disjuntos, tem-se somente um símile, que é uma forma mais simples de metáfora.

No estudo de caso em questão, não foi desenvolvido nenhum software ou dispositivo gerador, mas todo esforço foi dirigido para a forma de representação, utilizando recursos de realidade virtual e sketchs de simulação, utilizando o Matlab.

No estudo de caso, oito simulações foram desenvolvidas e apresentadas aos especialistas representando os movimentos mais importantes do processo cirúrgico. A tabela 1 apresenta alguns exemplos de imagens do ambiente virtual desenvolvido.

Foi discutido inicialmente no desenvolvimento desta proposta se esse tipo de representação seria satisfatória para o processo de negociação e validação. Ou seja, se a exploração do senso de percepção visual do especialista através do uso da realidade virtual (ambiente 3D, não imersivo) seria uma boa opção para analisar os processos e analisar as possibilidades de automação. Até este momento não se tinha conhecimento ou informação de trabalhos correlatos sobre o comportamento ou reação dos clientes/especialistas perante esse tipo de representação. Entretanto, foi observado que o ambiente 3D para domínios disjuntos motivou os especialistas a analisarem os movimentos conforme a amplitude e os diferentes ângulos e posições, auxiliando a busca por falhas, ambigüidades e omissões. A representação tridimensional concretizou as referências e o senso de percepção do cirurgião diante do processo cirúrgico. Abstraiu de forma natural o grande volume de requisitos que foram analisados, negociados e validados, em um período de tempo curto (uma hora de duração). O ciclo se repetiu duas vezes, confirmando todas as especificações dos requisitos nesta primeira fase do trabalho. Acredita-se que tal fato foi influenciado não só pela representação escolhida, mas pelas constantes orientações fornecidas pelos especialistas durante as observações práticas e laboratoriais, e pela boa relação e aproximação entre desenvolvedor e cliente/especialista, pelo amadurecimento de conceitos relacionados ao domínio de aplicação proporcionado pela fase (B) e pelo grande número de horas disponibilizadas para análise e aplicação dos métodos observacionais.

A validação foi realizada apresentando diretamente os esquemas de simulação ao especialista. Estes esquemas foram baseados em modelos previamente desenvolvidos do olho humano que foram extraídos da literatura ou obtidos por processo etnográfico e posteriormente modelados no Matlab. As aproximações ficaram por conta do desenvolvedor, embora tenham sido plenamente validadas.

Embora o processo tenha se baseado quase que integralmente nos movimentos do processo cirúrgico, a interação com o usuário levou ao questionamento da própria abordagem e à consideração de que o processo de automação da cirurgia deveria ser focado na informação e não nos movimentos. Este discussão foi o principal resultado que foi levado para a fase seguinte, a elaboração geral do documento de requisitos.

4.6 Documentação de Requisitos - (F)

A fase de documentação é a que mais amplamente contemplada pelas ferramentas atuais e ambientes de apoio. Quase todos os sistemas, incluindo os de domínio público encontrados na Internet, têm ferramentas de controle de documentos e versões bastante avançados para tornar esta fase menos penosa e bastante rápida. Como já foi enfatizado, não se usou ao longo do nosso experimento nenhum sistema de apoio e portanto não teria sentido introduzi-los somente na fase final, principalmente se estes não possuírem mecanismos de apoio às fases preliminares (de requisitos) do design. Seria o mesmo que reduzir estes ambientes a simples controladores de documentos, o que não seria justo.

Entretanto, é justamente nos sistema automatizados que a volatilidade dos requisitos mais se apresenta (Moreira et al, 2006) e portanto é exatamente neste caso que se torna mais crítica a exploração dos métodos de gerenciamento de requisitos. Neste estudo de caso foi utilizada uma linguagem natural como forma de reduzir os riscos de interpretações errôneas justamente quando temos domínios disjuntos. Neste caso a possibilidade de erros de interpretação é ainda maior que nos casos clássicos.

Diante de uma demanda crescente de cirurgias de catarata, a análise do domínio da aplicação (do ambiente em que os eventuais métodos automatizados se aplicariam) levou a uma hipótese inicial de que uma provável solução seria o uso de aparatos robóticos para aumentar o desempenho enquanto facilitasse a repetição de tarefas, atendendo a um número crescente de casos, especialmente na população carente. Entretanto, de modo semelhante ao já observado em casos ligados a manufatura, com operações de usinagem e soldagem, a velocidade com que uma cirurgia é realizada por um cirurgiãochefe já está no limite. Se o processo incluir residentes, ainda assim, a velocidade não se mostra como o entrave principal, especialmente se contrastado com a eficiência com que a cirurgia é feita. Entretanto, atrasos ou falhas na captura de informação sobre o paciente, do seu estado corrente ou sobre detalhes do seu prontuário que precisam ser revistos, etc. podem ser cruciais e evitar interrupções que poderiam delongar o processo. Assim, a automação é mais critica no processo de assistência e provimento de informação do que na parte operacional. O custo-benefício, associado à precisão de um dispositivo robótico leva à mesma conclusão. Portanto a documentação final, feita em linguagem natural, reflete uma mudança de rumo no processo fruto da introdução dos elementos novos destacados na Figura 3: a inclusão da etnografia e do processo de aprendizado, e a inclusão do processo de correlação separado da seleção de requisitos estratégicos para a fase de negociação.

A inovação na fase de negociação ficou por conta da introdução de metáforas como meio de encarar a distância entre os domínios quando o projeto de automação está muito fora da área da engenharia.

Como não se tem neste momento uma linguagem interpretativa já desenvolvida para expressar a interação entre domínios disjuntos, a documentação do processo no estudo de caso passou pela elaboração de gráficos que representassem a trajetória realizada pelo instrumento cirúrgico nas coordenadas x, y e z do espaço tridimensional, como mostra o exemplo da Figura 4. Ou seja, os resultados validados pelo especialista foram transcritos para uma representação formal no domínio da engenharia. Como todos os processos de transcrição são ainda manuais, coube neste caso ao desenvolvedor a inclusão de uma documentação que enquadra a situação onde se aplica cada requisito (em linguagem natural).

O ambiente de modelagem utilizado para representar ambos os domínios foi o MatLab v2006a, com o auxílio do toolbox de realidade virtual (MatRV, 2006), uma extensão que per-mite criar cenas com objetos 3D, através do uso da linguagem VRML (Virtual Reality Modeling Language) e manipula-los com base nos resultados da simulação. A Figura 5 ilustra a estrutura do ambiente de modelagem que apresenta os dados para ambos os domínios.

5 CONCLUSÕES E TRABALHOS FUTUROS

Concluindo o trabalho, é enfatizada a necessidade de sistematização da fase preliminar de projeto de sistemas automatizados, especialmente a eliciação e análise de requisitos, como forma de reduzir a quantidade de erros e o número de projetos que não atendem plenamente os requisitos que os motivaram.

Uma proposta efetiva de processo foi feita e dados de um estudo de caso especialmente escolhido para investigar as possibilidades de automação da cirurgia de catarata foram registrados. Apesar de se tratar de um único caso, o que não serve como validação do método proposto, este estudo elucidou várias dúvidas sobre o processo, além de dar uma boa noção da importância deste trabalho, da interposição das fases, da natureza dos dados e da influência de cada fase sobre as demais. A generalização destes resultados precisa ser feita com bastante parcimônia mas é bastante relevante, especialmente no caso onde a automação deve ser aplicada em domínios disjuntos.

O objetivo traçado foi um estudo do processo de automação ao invés de se comprometer com um dispositivo específico logo de início, de modo que os resultados são gerais, embora tenham saído de um único caso. Note-se ainda que a proposta de sistematização foi feita independentemente do estudo de caso, e este último serviu apenas para amadurecer e testar alguns aspectos da proposta.

A conclusão principal é que os ambientes de apoio à fase de requisitos deveriam incluir as fases apresentadas na Figura 3 por complementaridade, sendo que em alguns casos, a aplicação mais significativa seria para domínios disjuntos. Porém em nenhum caso, uma das fases propostas se mostrou em desalinho ou em contradição com o caso clássico de gerenciamento de requisitos, mesmo em domínios próximos.

Em especial, a fase de negociação e validação foi interpretada como um processo metafórico, embora se tenha usado apenas processos manuais para fazer o mapeamento entre requisitos já elaborados e modelos apresentados ao especialista. O uso de uma linguagem interpretativa, acessível ao especialista, e onde se possa montar as metáforas não foi completamente explorado no presente trabalho. A inclusão dos sketchs de simulação apelando para o visual e sensitivo mostrou que esta parte, bem distante do domínio da Engenharia, pode ser atingida, desde que haja um mapeamento explícito entre os modelos do sistema de realidade virtual e os requisitos já eliciados. Entretanto a complementação destes modelos virtuais por elementos menos subliminares ainda está por ser explorada. Acredita-se que esta seja uma boa proposta de trabalho futuro, completamente integrada aos modelos mais modernos de prototipagem rápida, relacionados com os processos de design de sistema mecatrônicos (e baseados no MatLab).

Foi também verificada a importância do papel da imersão do desenvolvedor no ambiente do domínio da aplicação, no caso específico de domínios disjuntos. Entretanto, esta é uma recomendação adicional que não deve se traduzir em nenhum artefato ou dispositivo metodológico para o processo de gerenciamento de requisitos.

Os elementos da Figura 3 podem efetivamete compor um ambiente de apoio à fase de requisitos e especificação, de forma compatível com o método unificado, onde requisitos são representados no domínio do desenvolvedor em UML/SysML, e, no domínio do especialista, em XML embebido de recursos de realidade virtual. Entretanto esta é mais uma proposta de trabalho futuro.

6 AGRADECIMENTOS

Os autores agradecem o apoio do Hospital Santa Luzia, localizado em Salvador - Ba, concedido pelo Dr. Eduardo Príncipe e pelo Dr. Alexandre Príncipe, e do Instituto da Visão - UNIFESP, localizado em São Paulo - SP, através do Prof. Dr. Lincoln Lemes Freitas, chefe do setor de catarata, e do Dr. Jonathan Clive Lake, seu assistente.

Ao CNPq pelo apoio financeiro a este trabalho, através da concessão de bolsa de estudo.

Artigo submetido em 05/01/2008 (Id.: 00845)

Revisado em 03/12/2008, 06/03/2009, 06/07/2009, 23/07/2009

Aceito sob recomendação da Editora Associada Profa. Emilia Villani

• Alexander, I.; Robertson, S., 2004, "Understanding Project Sociology by Modeling Stakeholders,"IEEE Software, vol. 21, no. 1, pp. 23-27, Jan/Feb.
• Atkinson, P., and Hammersley, M., 1994, "Ethonography and participant observation. In N.K. Dezin and Y.S. Lincoln (eds). Handbook of Qualitative Research. Lon-gon:Stage.
• Beyer H.R., and Holtzblatt K., 1995. "Apprenticing with the Customer: A Collaborative Approach to Requirements Definition,"Communications of the ACM, vol 38, no. 5, pp 45-52, May.
• Carroll, J. M., 2000, "Introduction to the special issue on "Scenario-Based Systems Development," Interacting with Computers, 13(1), 41-42.
• Fook K.D, Abdelouahab Z., 2001, "Reutilização de Objetivos na Engenharia de Requisitos", Workshop on Requirements Engineering, disponível em: http://wer.inf.pucriorio.br/WERpapers/artigos/artigos_WER01/fook.pdf, Acesso em: 20/10/2006.
• Frey, D. D., Dym C. L., 2006, "Validation of design methods: lessons from medicine", Research in Engineering Design, May, 17.
• Gervasi, V. and Zowghi, D., 2005. Reasoning about inconsistencies in natural language requirements. ACM Trans. Softw. Eng. Methodol. 14, 3 (Jul. 2005), 277-330.
• Goguen, J., 1996, "Formality and Informality in Requirements Engineering". In Proceedings of the 2nd international Conference on Requirements Engineering (ICRE '96) (April 15 -18, 1996). ICRE. IEEE Computer Society, Washington, DC, 102.
• Goguen, J. and Linde, C., 1993, Techniques for Requirements Elicitation. 1st IEEE International Symposium on Requirements Engineering (RE'93), San Diego, USA, 4-6th January 1993, pp. 152-164.
• Hickey, A. M. and Davis, A. M. 2003. Elicitation Technique Selection: How Do Experts Do It? In Proceedings of the 11th IEEE International Conference on Requirements Engineering (September 08 -12, 2003). RE. IEEE Computer Society, Washington, DC, 169.
• Hickey, A. M., Davis, A. M., and Kaiser, D., 2003, "Requirements Elicitation Techniques: Analyzing the Gap Between Technology Availability and Technology Use."Comparative Technology Transfer and Society 1, 3 (December): 279-302.
• Hickey, A. M; Davis, A. M., 2002, Requirements Elicitation and Elicitation Technique Selection: A Model for Two Knowledge-Intensive Software Development Processes, Proceedings of the 36th Hawaii International Conference on System Sciences (HICSS'03) 0-7695-1874-5/03.
• Jarzabek, S., Zhang, H., 2001, "XML-based Method and Tool for Handling Variant Requirements in Domain Models". Procc. of the 5^th IEEE Int. Symposium on Requirements Engineering, pgs. 166-173, Toronto, Ca.
• Jiang L.; Eberlein A.; Far B. H., 2005, "Combining Requirements Engineering Techniques - Theory and Case Study", Proceedings of the 12^th IEEE International Conference and Workshops on the Engineering of Computer-based System (ECBS'05).
• Kotonya G., Sommerville I., 1998, "Requirements engineering: processes and techniques", Chichester: J. Wiley.
• Leite J.C.S.P., Franco, A.P.M., 1993, "A Strategy for Conceptual Model Acquisition". In: International Symposium on Requirements Engineering, 1., SanDiego, Ca. Proceedings. . . IEEE Computer Society Press, p. 243-246.
• Leite, J.C.S.P, Rossi, G., Balaguer, F., and Maiorana, V., 1997., Enhancing a requirements baseline with scenarios. In Proceedings of the Third IEEE International Symposium on Requirements Engineering - RE97, pages 44-53. IEEE Computer Society Press, January.
• Li, K; Dewar, R.G., Pooley, R.J, 2004, "Requirements Capture in Natural Language Problem Statements", Technical Report HW-MACS-TR-0023, disponível em: http://www.macs.hw.ac.uk/techreps, Acesso: 20/10/2006.
• Liou, Y.I., 1990, Knowledge acquisition: issues, techniques, and methodology in ACM SIGBDP Conference on Trends and Directions in Expert Systems Orlando, Florida, United States: ACM Press.
• Macaulay, L. A., 1996, "Requirements for Requirements Engineering Techniques", IEEE Proceedings of ICRE.
• MatRV, 2006, MathWorks, disponível em: http://www.mathworks.com/products/virtualreality/, último acesso: 05/10/06.
• Moreira, A., Araújo, J. and Wittle, J., 2006, Modeling Volatile Concerns as Aspects. In Lecture Notes in Comuter Science 4001, pgs. 544-558, E. Dubois and K. Pohl (Eds.), Springer.
• Niu, N. and Easterbrook, S. 2006. Discovering aspects in requirements with repertory grid. In Proceedings of the 2006 international Workshop on Early Aspects At ICSE (Shanghai, China, May 21 -21, 2006). EA '06. ACM Press, New York, NY, 35-42.
• Nuseibeh, B.; Easterbrook, S., 2000, Requirements Engineering: A Roadmap In: International Conference on Software Engineering, 22.,jun, Limerick, Ireland. Proceedings. . . ACM, 2000, p. 35-46.
• Olson, J.S. and Moran, T., 1995, Mapping the method muddle: Guidance in using methods for user interface design. In Human computer interface design: Success cases, emerging methods, and real world contexts. C. Lewis et al (eds). New York: Morgan Kaufman.
• Peters, J F.; Pedricz, W, 2001, Engenharia de software: teoria e prática Trad: Ana Patrícia Garcia. Rio de Janeiro: Campus.
• Preece J, Rogers Y., Sharp H., 2002, Interaction Design Beyond human-computer interaction, Wiley.
• Pressman, Roger S., 2005, Software engineering: a practitioner's approach. 6 ed. New York: McGraw-Hill.
• Queiroz, R.A.A, 2007, Eliciação e comunicação de requisitos em domínios disjuntos: estudo de caso para a área médica, dissertação de mestrado da Escola Politécnica da Universidade de São Paulo - USP, orientador Prof. Dr. José Reinaldo Silva.
• Raghavan S., Zelesnik, G., Ford, G., 1994, "Lecture Notes on Requirements Elicitation", Educational Materials CMU/SEI-94-EM-10, Software Engineering Institute, Carnegie Mellon University.
• Robertson, S; Robertson J, 2006, Mastering the Requirements Process. Boston: Addison-Wesley.
• Rudd, J. Stern, K., Insensee, S., 1996, "Low vs. High-fidelity Prototyping Debate", Communications of ACM, vol. 37, no. 4, pp. 21-27.
• Rudman, C. and Engelbeck, G. 1995. Lessons in choosing methods for designing complex graphical user interfaces. In Proceedings of A Workshop on Human-Computer interface Design : Success Stories, Emerging Methods, and Real-World Context: Success Stories, Emerging Methods, and Real-World Context (Boulder, Colorado, United States). M. Rudisill, C. Lewis, P. G. Polson, and T. D. McKay, Eds. Morgan Kaufmann Publishers, San Francisco, CA, 198-228.
• Sheldon, F. T., Kavi, K. M., Tausworth, R. C., Yu, J. T., Brettschneider, R., and Everett, W. W, 1992, Reliability Measurement: From Theory to Practice. IEEE Softw. 9, no. 4.
• Silva, J.R., 1992, "Uma formalização do processo de design baseado em metáforas: Sua aplicação na automatização de Sistemas de Eventos Discretos". Tese de doutorado apresentada na Escola Politécnica da USP, orientador Carlos J. P. Lucena.
• Sommerville I., Rodden, T., Sawyer, P., Bentley, M., and Twidale, M., 1992, "Integrating Ethnography Into the Requirements Engineering Process", In Proceedings of the IEEE International Symposium on Requirements Engineering, pages 165173. IEEE Computer Society, ISBN 0818631201.
• Sutcliffe, A, 1997, "A Technique Combination Approach to Requirements Engineering", 3rd IEEE International Symposium on Requirements Engineering (RE'97), Jan., 05 -08, Annapolis, MD.
• Truong, K. N., Hayes, G. R., and Abowd, G. D., 2006, Story-boarding: an empirical determination of best practices and effective guidelines. In Proceedings of the 6th ACM Conference on Designing interactive Systems (University Park, PA, USA, June 26 -28). DIS '06. ACM Press, New York, NY, 12-21.

1

Conhecimentos não codificados os quais não são transmitidos em documentos escritos. Estão presentes no cérebro de quem trabalha com um processo particular de transformação e geralmente são baseados em experiências e hábitos.

2

Conhecimento codificado, isto é, formal e sistemático, armazenado em livros, manuais, e etc.

3

O termo especialista aqui é uma "tradução" de stakeholder, isto é, aquele que entende do processo a que servirá o sistema (automatizado). Este termo é comumente usado entre os profissionais da área de requisitos.

4

A referência aqui mencionada se refere a projetos completos e não a sub-projetos, onde uma especificação já vem montada por outros engenheiros do projeto maior.

Datas de Publicação

• Publicação nesta coleção
  29 Jan 2010
• Data do Fascículo
  Dez 2009

Histórico

• Aceito
  23 Jul 2009
• Recebido
  05 Jan 2008