Identificando expectativas de qualidade de SIs com o apoio de Modelos de Negócio

Rosaria Viana Bittencourt

Comissão Nacional de Energia Nuclear - R.Gal.Severiano 90, Botafogo, 22290-040 - Rio de Janeiro, RJ – Brasil

Programa de Pós-Graduação em Informática e Núcleo de

Pesquisa e Prática em Tecnologia Departamento de Informática Aplicada

Universidade Federal do Estado do Rio de Janeiro (UNIRIO) – Av. Pasteur 458, Térreo, Urca, 2290-240 – Rio de Janeiro, RJ

– Brasil

rosaria.viana@uniriotec.br

Renata Mendes de Araujo

Programa de Pós-Graduação em Informática e Núcleo de Pesquisa e Prática em Tecnologia

Departamento de Informática Aplicada Universidade Federal do Estado do Rio de Janeiro (UNIRIO) – Av. Pasteur 458, Térreo, Urca, 2290-240 – Rio de Janeiro, RJ

– Brasil

renata.araujo@uniriotec.br

RESUMO Requisitos Não Funcionais (RNFs) estão associados às expectativas dos clientes, usuários e desenvolvedores sobre a qualidade de um Sistema de Informação (SI). Em geral, a identificação dessas propriedades não funcionais é ad-hoc, não aderente às necessidades do negócio da organização onde o sistema se insere e realizada de forma tardia no processo de desenvolvimento. Este trabalho apresenta o desenvolvimento de uma sistemática de identificação de RNFs apoiada nos Modelos de Negócio organizacionais. Espera-se ao final desta pesquisa avaliar o potencial dos Modelos de Negócio como instrumento para antecipar a identificação de RNFs com a participação dos clientes, usuários e desenvolvedores. ABSTRACT Non-functional Requirements (NFRs) are related to customers’, users’ and developers’ expectations about Information Systems (IS) quality level. Generally, the identification of these non-functional properties is conducted in an ad-hoc manner, not considering the organizational business needs where the system wil operate, and performed lately in the development process. This work presents the inception of a sistematic path to NFRs identification, based on organizational Business Models. At the end of this research it is expected to evaluate the Business Model potential as an instrument to identify NFRs form the beginning of a development process and to improve the customers’, users’ and developers’ participation and commitment to this task.

Categories and Subject Descriptors D.2.1 [software engineering]: requirements specification, elicitation methods, methodologies

General Terms Management, Documentation.

Keywords Sistemas de Informação, Requisitos não-funcionais, Modelos de Negócio, NFR Framework.

1. INTRODUÇÃO Processos e Sistemas não existem isoladamente, o objetivo de ambos é oferecer suporte aos objetivos de uma Organização. Um Processo de Negócio definido torna-se ponto de partida para desenvolver ou adquirir Sistemas de Informação (SIs) que dêem suporte aos objetivos do negócio [27]. Diversos autores reconhecem a importância de modelar a organização antes de identificar requisitos para um SI [11][33][32], mas a ênfase dos trabalhos está nos requisitos funcionais (RFs) [18][6][29][11][12]. Além de funcionalidades, um sistema necessita de requisitos que se relacionam com a qualidade que é traduzida em: desempenho, facilidade de uso, rapidez e confiabilidade na resposta, freqüência de falhas; e restrições como: custo, linguagem, ferramentas, orçamento, políticas organizacionais, culturais, legais, etc [28][17][15]. Essa qualidade tem sido associada ao termo “requisito não funcional” (RNF) [19][4] [21] [32] [23].

Apesar do crescente uso dos Modelos de Negócio (MNs) como instrumentos para identificar requisitos, as propostas tendem a não considerar a aderência dos RNFs às necessidades do negócio da organização onde o sistema se insere [25][32][23]. As dificuldades para identificar RNFs podem ser atribuídas à: 1) sua natureza subjetiva, seus detalhes técnicos, seu impacto global sobre o sistema e sua complexa rede de interdependências [5]; 2) necessidade de diferentes visões de qualidade [16][21] a serem obtidas de usuários finais, clientes e equipe de Tecnologia da Informação (TI) – os stakeholders ou envolvidos em um projeto de SI.[3][17][28][21[24]; 3) dificuldade em se detalhar RNFs em menor granularidade, sendo geralmente expressos em alto nível, carecendo de refinamento [21].

Em função dessas dificuldades, os RNFs são esquecidos ou negligenciados durante a análise de requisitos. A preocupação de identificá-los pode surgir tardiamente durante a fase de projeto, testes ou mesmo somente durante a operação do sistema [15]. O tratamento tardio dos RNFs tem como conseqüência o agrave no custo do projeto. São reconhecidamente os mais caros e difíceis de corrigir após a construção do sistema [19][4][5].

O ciclo de vida de um projeto de sistema não é seqüencial e nem todos os requisitos são identificados antes do desenvolvimento do sistema, mas há expectativas de soluções que auxiliem a

205© 2008 Brazilian Computer Society

Figura 1 – SIG inicial (Fonte:Chung, 2000)

Figura 2 – catálogo de tipos de RNFs (Fonte:Chung, 2000)

identificação de RNFs antes da fase de projeto. O que não se pode ignorar é que necessidades do negócio e do usuário e a compreensão sobre o que se deseja de um sistema podem mudar conforme o passar do tempo e evolução do produto. Faz-se necessário uma constante interação com stakeholders, que para ser bem sucedida no seu objetivo que é a identificação de requisitos deve ter uma comunicação eficaz com os clientes e usuários. O objetivo deste trabalho é propor uma solução para um cenário onde a identificação de RNFs é não-sistemática, realizada de forma tardia no processo de desenvolvimento, com baixa participação dos diversos envolvidos no projeto, implicando em insucessos, re-trabalho, insatisfação e sistemas inadequados e não alinhados ao negócio. A hipótese que se pretende verificar é que MNs possibilitam a identificação de RNFs a partir da análise da qualidade esperada dos elementos explícitos no modelo (atividades, artefatos, atores) com a colaboração dos stakeholders na construção do sistema. Pretende-se contribuir com maior visibilidade para os RNFs, que são tratados de forma secundária e subjetiva e com mais uma evidência da modelagem de processos de negócio como um passo inicial no processo da Engenharia de Requisitos de Sistemas.

O artigo apresenta na seção 2 o conceito de RNFs e sua relação com a qualidade de SIs. Na seção 3 o conceito de MNs e um resumo sobre a aplicação de MNs na identificação de requisitos de sistema. A seção 4 apresenta uma proposta de sistemática para identificar RNFs a partir de Modelos de Negócio e uma primeira aplicação da sistemática em um caso real. São apresentadas as observações obtidas durante esta aplicação e como tais observações ajudaram a ajustar a concepção inicial da sistemática. A seção 5 conclui o artigo, apontando trabalhos futuros.

2. QUALIDADE EM SISTEMAS DE INFORMAÇÃO Para a ISO/IEC 9126 [16] as características de qualidade do sistema são compostas por seu conjunto de funcionalidades, mas também por um grupo subjetivo de atributos como confiança, usabilidade, eficiência, manutenibilidade, portabilidade etc. Esses atributos constituem os RNFs e estão associados às expectativas dos stakeholders, que devem ser exploradas durante a identificação dos requisitos, Em geral, stakeholders devem sinalizar o que têm em mente, mas têm dificuldades em fazê-lo de forma explícita. Essas expectativas envolvem objetivos concretos sobre o que se deseja que o sistema faça, mas também objetivos que representam intenções ou razões dos stakeholders. Estes objetivos sem uma definição clara são denominados softgoals, conceito proposto no Non Functional Requirements Framework (NFR-framework) [4].

O NFR_framework é uma proposta de abordagem completa para representar, analisar e especificar RNFs. O framework propõe uma estratégia para decompor RNFs, priorizar, operacionalizar, e tratar das interdependências entre RNFs. Softgoal Interdependency Graph (SIG) [4][8][21] é um modelo que representam a interdependência entre RNFs, e é utilizado para representar as decisões relacionadas a RNFs em um determinado projeto. A figura 1 representa um SIG em construção para segurança de contas correntes em um sistema de transação bancária. Neste diagrama, é representado que para atingir a segurança de uma conta corrente são necessários três subtipos de RNFs: integridade, confidencialidade e disponibilidade. Por sua

vez, a integridade de contas correntes para ser atingida necessita de dois subtipos: completude e acurácia. As relações representadas neste diagrama decorrem de decisões tomadas pela equipe de projeto sobre o que é esperado em termos de qualidade em segurança para este objeto em particular manipulado pelo sistema – conta bancária.

A decomposição de RNFs através do SIG é facilitada com o uso de catálogos de tipos de RNFs [4][30][9]. Os catálogos de tipos auxiliam a identificação de RNFs pois ajudam a refletir quais os tipos e subtipos necessários para satisfazer as expectativas de

qualidade esperadas para o sistema. Os catálogos de tipos exibem os RNFs organizados em hierarquia, ou seja, decompõem o RNF

de mais alto nível em subtipos. A figura 2 exemplifica um catálogo com quatro RNFs de alto nível: desempenho, custo, amigabilidade e segurança. Desempenho e segurança são decompostos em seus respectivos subtipos de RNFs.

206

Apesar do NFR-Framework permitir a representação e decomposição estruturada de RNFs, a identificação de expectativas de qualidade está baseada nos catálogos previamente definidos. A compreensão dos catálogos e sua tradução para o diálogo com os atores do negócio não é tarefa trivial. Há uma tendência em prevalecer a visão do desenvolvedor e, como conseqüência, parte do conhecimento do domínio, prioridades e terminologias não são capturadas. Os autores do NFR-Framework aplicaram a abordagem em estudos de casos e identificaram que o contato com as pessoas do domínio do negócio é imprescindível para a identificação de softgoals e decomposição de RNFs. Os autores propõem como trabalho futuro um estudo com contatos freqüentes, mais próximo dos problemas reais de uma organização.

As perspectivas de todos os stakeholders devem ser exploradas em função de sua influência sobre os RNFs e envolvimento no sistema. Do ponto de vista dos usuários, o interesse está no uso do sistema e no seu desempenho; para os clientes o interesse esta na aquisição de um sistema e critérios de qualidade do projeto como custo e tempo; e os desenvolvedores estão interessados nos aspectos internos do sistema, decisões de arquitetura e design e nas características requeridas para a manutenção do sistema [31] [16][21].

Este trabalho argumenta que os modelos de processos de negócio ajudam o analista de negócio a orientar os stakeholders a expor expectativas de qualidade para os elementos de seu negócio. E ainda argumenta que através dos MNs seja possível identificar a qualidade nos elementos que conduzem a execução de um processo e que estão explícitos nos MNs, com a participação de stakeholders e considerando a aderência dos RNFs às necessidades do negócio da organização onde o sistema se insere.

3. DERIVAÇÃO DE REQUISITOS A PARTIR DE MODELOS DE NEGÓCIO Os MNs [10][14][2][22] permitem compreender o que a organização faz; como são executadas as atividades; quem são os envolvidos em cada atividade; quais eventos determinam o inicio de execução de processos e atividades; quais os objetivos organizacionais e como cada processo contribui para alcançá-los; qual a distribuição geográfica da organização e quais as unidades organizacionais. Esse conhecimento do domínio obtido através dos MNs permite responder ao 5W1H: O que é feito? (What?) Quem faz? (Who?) Quando? (When?) Por quê? (Why?) Onde? (Where?) Como? (How?). Esse conjunto de informações torna explícito nos modelos: “o quê”, caracterizado pelos artefatos manipulados no processo; “como”, caracterizado pelas atividades e sua seqüência de execução; “quem”, caracterizado pelo ator responsável pela execução das atividades.

Os elementos de negócio são conceitualmente as informações utilizadas para a especificação de um SI: as atividades se traduzem em funcionalidades; artefatos que são transformados pelas atividades e que se traduzem em entidades de informação manipuladas pelo sistema; e atores que representam os elementos (cargos, organizações, sistemas equipamentos) que interagem com o sistema.

Pesquisas têm utilizado Modelos de Negócio (MNs) como instrumento para derivar requisitos de sistemas, tentando assegurar alinhamento dos sistemas de apoio aos objetivos da

organização [26][11]. A partir dos modelos organizacionais há diferentes estratégias para se obter os RFs [18][6][29][12].

Santander e Castro [26] apresentam diretrizes de como obter diagramas de casos de uso (DCU) a partir de modelos de processos modelados utilizando a abordagem i* [33]. Os aspectos não funcionais capturados são anexados através de uma descrição textual aos DCU, mas os autores não indicam como transformar as intenções entre os atores em RNFs de baixo nível e como associá-los aos DCU.

Röhrig [25] propõe um método para derivar medidas de segurança através do modelo de processo de negócio, mas não há participação dos stakeholders na definição dos níveis de segurança desejados.

Demirörs et al [13] identificam RFs e RNFs, de acordo com os objetivos e processos do negócio. Os RNFs são identificados a partir da análise dos processos e com suporte da ISO/IEC 9126 [16]. A modelagem de processos foi realizada com a participação de stakeholders,, mas a identificação de RNFs para o sistema foi realizada por analistas sem a participação de clientes ou usuários.

Cunha [7] transpõe requisitos de domínio para requisitos de segurança através da análise dos modelos i*, cujos modelos, segundo o autor, são complexos e tendem a uma dificuldade que compromete a escalabilidade e manutenção [12][1].

Pavlovski e Zou [23] utilizam BPMN [20] para modelar processos e propõem uma extensão à notação para representar a restrição associada a uma atividade RNFs denominada condição de operação e uma descrição do control case. São identificados RNFs de alto nível.

De um modo geral, os trabalhos acima não propõem uma sistemática de identificação de requisitos envolvendo os diversos stakeholders e com técnicas para justificar decisões de todos envolvidos no sistema. Em relação aos RNFs, existe a dificuldade para os usuários em compreender e externalizar o que seja qualidade de sistema [16]. As duas áreas, negócio e tecnologia, necessitam superar barreiras: divergente sintaxe e semântica das respectivas linguagens e diferentes conceitos sobre qualidade de processo e qualidade de sistema. Adicionalmente, os modelos de requisitos propostos pela TI e utilizados para interagir com usuários podem gerar dificuldades de compreensão já que os usuários finais não dominam a linguagem e representação de TI [12]. Entretanto, modelos que facilitem a comunicação durante a análise de requisitos devem ser utilizados. O uso de modelos de processos para o desenvolvimento de SI facilita a compreensão das pessoas e torna a comunicação mais fácil, auxiliando a interação entre usuários e TI [12].

4. SISTEMÁTICA PROPOSTA Dois princípios norteiam este trabalho. O primeiro envolve os MNs como instrumento para identificar requisitos de sistemas com suporte às atividades de um negócio e alinhamento aos objetivos da organização, antecipar a identificação de requisitos no processo de desenvolvimento de sistema e integração das linguagens dos profissionais que têm a visão do negócio e dos profissionais com visão tecnológica. Este trabalho argumenta ser possível estabelecer uma ponte de comunicação entre desenvolvedores, clientes e usuários de sistemas através dos MNs.

207

O segundo princípio que norteia este trabalho envolve o NFR-framework usado para derivar e representar RNFs. Além disso, os catálogos de tipos de RNFs [4][30][9] auxiliam o analista de negócio a refletir e direcionar a discussão com os stakeholders na identificação de qualidades esperadas e a traduzir essas qualidades em RNFs de alto nível.

Os MNs fornecem elementos de negócio explícitos que sugerem qualidades. Os artefatos, por exemplo, têm um ciclo de vida no processo, ora são restritos e privados, ora são públicos e sem confidencialidade. As atividades necessitam de qualidades como tempo de resposta para o usuário de caixas eletrônicas de banco. O perfil de um negócio define atores com diferentes necessidades de qualidades de um sistema. Por exemplo, clientes de um negócio virtual voltado para o aprendizado necessitam de facilidade de uso, clientes de um negócio de vendas virtuais necessitam de segurança, usuários com sobrecarga de digitação necessitam de adequações ergonômicas.

O analista de negócio utiliza os MNs como instrumento para que os clientes possam expor expectativas de qualidade para os elementos de seu negócio. A seqüência de execução de atividades organiza o raciocínio dos stakeholders, auxilia a exposição sobre as qualidades necessárias, permite conduzir as entrevistas através de um contexto semântico conhecido dos envolvidos. Os MNs auxiliam a identificar um “por quê” que não está explícito em seus modelos, e que se traduzem em qualidades esperadas e razões ou justificativas para existência dessas qualidades no SI que deve dar suporte ao negócio e às necessidades de operação do processo.

As premissas para execução da sistemática são: a existência de MNs, o uso de catálogos de tipos de RNFs, a demanda de um SI e a aquisição de conhecimento sobre o domínio do negócio.

A sistemática prevê o uso de MNs já elaborados e atualizados na organização, independente da abordagem, o que oferece a vantagem de reduzir o esforço de modelar. Entretanto, caso a organização não possua MNs existe ai uma oportunidade para modelar os seus processos.

A organização que possui catálogos de RNFs próprios tem a vantagem de reutilizar um conhecimento construído com base em domínio específico. E aquela que não os possui pode utilizar o NFR-framework e os catálogos disponíveis mesmo que com benefícios parciais, já que podem ser necessárias qualidades que não possuam catálogos ficando os RNFs em alto nível.

A sistemática é gerenciada e controlada por um analista de negócio, profissional de TI familiarizado com os termos técnicos sobre a qualidade de sistemas e RNFs, com habilidades de entrevistar diferentes stakeholders e com conhecimentos sobre o NFR-framework e MNs.

Partindo dos princípios descritos para a concepção da sistemática, uma primeira idéia para sua execução foi elaborada, conforme apresentado na seção a seguir.

4.1 Proposta de Sistemática – 1ª Versão A figura 3 resume a sistemática, onde modelos de negócios são analisados pelos diversos envolvidos no projeto, guiados pelo analista de negócios. O analista, com base nos catálogos de RNFs existentes e a partir dos elementos de negócio explicitados no modelo, conduz o levantamento e discussão de expectativas de qualidade, representando-as através de SIG. O SIG não é um fim em si próprio, ele dará inicio a uma nova fase de discussão

voltada para análise de interdependências e prioridades, mas que não são tratadas nesta proposta.

Fase 1 - Levantamento da qualidade: o analista de negócio examina os diagramas de fluxo de trabalho e documentação dos processos. Para cada processo identifica os atores, artefatos e atividades explícitos no modelo. De acordo com o seu ponto de vista e com auxilio dos catálogos de RNFs, o analista atribui qualidades que julgue necessárias ou relacionadas às expectativas já discutidas anteriormente com os stakeholder. Os catálogos de tipos de RNFs auxiliam o analista a refletir sobre a qualidade sugerida pelo processo de negócio. Documentam-se também as qualidades supostas como necessárias para cada elemento de negócio identificado. O produto desta fase é a documentação da identificação dos elementos de negócio, respectivas qualidades identificadas a partir dos MNs e possíveis justificativas para as qualidades sugeridas Essas qualidades são discutidas junto aos stakeholders em fase seguinte.

Fase 2 - Discussão da qualidade: o analista de negócios apresenta os MNs para a equipe de TI e discute as qualidades identificadas na fase anterior. Novas qualidades para os elementos de negócio podem ser sugeridas e são acrescentadas à documentação em construção. As razões apresentadas para as qualidades devem ser documentadas como justificativas para a qualidade..

Em um momento seguinte, o analista de negócios conduz os clientes e usuários em uma análise dos modelos de processos que tem como objetivo discutir as qualidades sugeridas pela visão de TI. As justificativas e as expectativas de qualidades para os elementos de negócio sob o ponto de vista do usuário são então conjugadas às expectativas obtidas pela discussão com a equipe de TI. A condução desta atividade é organizada a partir da seqüência de execução das atividades no processo e da documentação previamente obtida nas etapas anteriores da sistemática. À medida que se conversa com os stakeholders sobre os atores, as atividades e os artefatos, solicita-se a confirmação da qualidade identificada a partir dos MNs.

Finalmente, o analista de negócio traduz a qualidade identificada e justificada em RNFs de alto nível e os decompõe com auxilio dos catálogos. A representação dos RNFs é feita através de SIG. Os tipos de RNFs são associados aos tópicos que representam os

Figura 3 – resumo da sistemática

208

artefatos e atividades do domínio. A decomposição de RNFs, é opcional. Assim como Chung [4], esta sistemática deixa a cargo do analista de negócio decidir o que refinar, quando e quanto refinar. As organizações que possuem catálogos próprios têm a oportunidade de explorar a decomposição de RNFs com base em domínios específicos. E aquelas que não possuem têm nessa atividade a oportunidade construir seus catálogos e acumular um conhecimento específico do domínio sujeito à reutilização e contínua revisão. O objetivo dessa etapa é decompor os tipos e tópicos até níveis mais baixos, quando a granularidade permite definir a operacionalização dos RNFs.

Fase 3 - Validação de RNFs: o analista de negócio conduz a validação com os stakeholders através dos diagramas de fluxo de trabalho e utiliza o SIG e a documentação obtida como guia para esta atividade.

A validação pode levar à reavalição de alguns requisitos especificados, o que significa corrigir especificações, detalhar ou decompor em menor granularidade outros já identificados ou ainda identificar novos requisitos. A figura 3 mostra esse retorno à fase 2.

4.2 Aplicação Uma aplicação preliminar da sistemática proposta foi realizada com o objetivo de avaliá-la em seus aspectos gerais de concepção,

tais como: 1) observar a dinâmica de interação com os stakeholders a partir das informações coletadas pela sistemática e o uso dos MNs para este diálogo, conforme previsto; 2) avaliar a aplicação dos catálogos como fonte de reflexão para a identificação de RNFs e sua relação com os elementos do negócio; 3) avaliar a sistemática como um todo, aplicando ajustes em sua concepção inicial.

Nesta aplicação, as fases propostas na sistemática são executadas para o caso de uma empresa da área nuclear no Brasil, que tem no seu escopo de negócio o processo de Gerenciamento de Dose Ocupacional Externa, representado na figura 4 em um modelo de

processo de negócio proposto para o TO-BE. O processo tem como responsabilidade a custódia de informações sobre doses radiativas a que são submetidos os trabalhadores em instituições ou instalações nucleares no país. Essas doses são denominadas doses ocupacionais por serem recebidas por um indivíduo em decorrência de seu trabalho com radiação ionizante. Essas informações devem ser consistentes, confiáveis e oferecer credibilidade para subsidiar medidas de proteção ao indivíduo ocupacionalmente exposto à radiação ionizante - qualquer partícula ou radiação eletromagnética que, ao interagir com a matéria, ioniza seus átomos ou moléculas.

Os clientes desse processo são: o Judiciário, que solicita histórico de trabalhador para tomada de decisões judiciais trabalhistas;

Figura 4 – modelo de fluxo de trabalho do processo “carregar lote”

209

entidades internacionais e nacionais da área de radioproteção (conjunto de medidas que visam a proteger os indivíduos contra os efeitos indesejados causados pela radiação ionizante) e dosimetria (medição de dose); e trabalhadores que solicitam seu histórico para anexar ao processo de aposentadoria. Os fornecedores do processo são os laboratórios que contribuem com informações sobre doses, instituições e trabalhadores. O sistema existente para apoio ao processo de Gerenciamento de Dose Ocupacional Externa foi desenvolvido na década de 90, é restrito à uma área funcional da empresa e não atende às necessidades do negócio como hoje é executado. Existe a demanda de um novo sistema web que reduza o trabalho manual, ofereça suporte computacional confiável e seguro diante do tipo de informações confidenciais manipuladas e que se integre a outros processos na empresa responsáveis pela fiscalização e credenciamento das entidades envolvidas na utilização de fontes radiativas (equipamentos ou materiais que emitem radiação ionizante ou liberam substâncias ou materiais radioativos).

A modelagem de processos é utilizada nesta organização como ferramenta de apoio ao desenvolvimento ou aquisição de sistemas. Essa modelagem foi realizada com suporte da ferramenta ProVision v5.1.1 (PROFORMA).

A Organização não possui catálogos de tipos de RNFs e foram adotados os existentes na literatura [4][9][30]. A modelagem foi realizada por um dos autores deste trabalho em parceria com um analista de sistemas. O grupo de stakeholders foi composto de profissionais de TI, chefes funcionais das áreas envolvidas e um usuário final responsável pela operação do sistema atual. Para fins de simplificação, a sistemática é exemplificada para a atividade “Enviar lote criticado” do processo “Carregar lote”. O processo é disparado pelo evento da chegada de lote, quando então os laboratórios enviam um lote previamente criticado em relação à obrigatoriedade de informações e consistência com o domínio.

4.2.1. Levantamento da Qualidade A atividade “Enviar lote criticado” é disparada pela chegada de um lote, que pode ser de três tipos – lote de dose, lote de instituição e lote de trabalhador. Na tabela 1 são relacionados os três elementos de negócio a serem analisados: o ator “laboratório”, a atividade “enviar lote criticado” e os artefatos “lote de dose, lote de instituição e lote de trabalhador”.

Tabela 1 . tabela de elementos do negócio

Atividade Artefato Ator

Enviar lote criticado

lote de dose

lote de instituição

lote de trabalhador

laboratório

As qualidades que o analista de negócio julgou necessárias foram associadas para cada artefato, atividade e ator e documentadas como na tabela 2, onde para cada elemento foram sugeridas qualidades com base nos catálogos, através da seguinte análise: a atividade “enviar lote criticado” transfere através da internet os artefatos lotes. Esses artefatos necessitam de qualidades de privacidade e segurança necessárias para reduzir os riscos de roubo e acesso não autorizado a dados pessoais que constam nos lotes.

A tabela 2 tem na coluna “qualidade artefato” os dois RNFs de alto nível: privacidade e segurança. Privacidade [30] está associada à segurança, que por sua vez está associada à confidencialidade, à integridade e à disponibilidade da informação [4]. É necessário preservar contra quebra de confidencialidade, ou seja, que pessoas não autorizadas tenham acesso ao artefato. É necessário preservar a integridade dos lotes para impedir ações de qualquer natureza de alteração ou destruição durante a transmissão. Os lotes devem ser transmitidos de forma completa. Esses três subtipos de RNFs de segurança estão na coluna “qualidade artefato” da tabela 2.

A qualidade para a atividade é “operação segura” que o analista considera necessária para atuar sobre o artefato lote que trafegará na internet. De acordo com o catálogo [4], a “operação segura” contribui para o RNF de mais nível que é segurança e conseqüentemente para os subtipos confidencialidade, integridade, completude para os artefatos, com o objetivo de satisfazer o tipo de mais alto nível que é segurança. A tabela 2 traz uma coluna de qualidade para atividade onde é documentado esse atributo de qualidade.

Há uma recomendação expressa do cliente, traduzida em necessidade do negócio, de preservar com confidencialidade máxima a carteira de clientes de cada laboratório. Essa informação é acrescentada na tabela de elementos do negócio, pois caracteriza uma argumentação que justifica a qualidade de confidencialidade. Na coluna justificativa da tabela 2 é documentada a “confidencialidade máxima” para o lote de instituição.

Não foi identificada uma qualidade para o ator laboratório.

4.2.2. Discussão da Qualidade Nesta fase, a equipe de TI sugeriu estender a confidencialidade máxima aos dois outros lotes transmitidos pela internet. Essa sugestão gerou uma justificativa reforçando a qualidade já identificada e, portanto, a tabela 3 exibe o acréscimo da argumentação da equipe de TI na coluna justificativa.

Tabela 2 – tabela de elementos de negócio

210

Os stakeholders confirmam a qualidade atribuída ao “lote de instituição” e concordam com a extensão da qualidade aos outros dois tipos de lotes.

A construção do SIG é feita baseada nas qualidades identificadas e documentadas na tabela 3. A figura 5 traz o SIG para segurança do artefato ‘lote’, que é decomposta com auxilio do catálogo de segurança [4] em subtipos para a atividade “enviar lote criticado” que manipula o artefato “lote”. Os subtipos de RNFs de mais baixo nível “confidencialidade externa” e “completude” são associados aos tópicos “lote de dose”, “lote de trabalhador” e “lote de instituição”, que por sua vez estão associados à atividade “enviar lote criticado”. A

decomposição do tópico lote nos três tipos: lote de dose, lote de instituição e lote de trabalhador é associada ao ator que nesse caso é o laboratório e está representada no SIG através de Completude[EnviarLoteCriticado(LoteDose, Laboratório)]. A justificativa de segurança para artefato lote é representado através do Claim [“confidencialidade máxima”] no SIG na figura 5.

4.2.3. Validação

A fase de “validação” foi realizada com dois representantes de TI, dois chefes funcionais responsáveis pelo processo “Gerenciamento de Dose Ocupacional Externa” e um funcionário, ator que acumula maiores responsabilidades na execução de atividades no processo.

Alem dos MNs e SIG, foi elaborado um questionário como roteiro para garantir que a oportunidade de validação tivesse o melhor aproveitamento possível. O questionário foi elaborado na ordem de execução das atividades e buscava a confirmação das qualidades até então identificadas. Para a atividade “enviar lote criticado” foi solicitada a confirmação de “confidencialidade máxima para lote de instituição” e apresentada a sugestão da equipe de TI em estender a qualidade para os outros lotes, com o que a cliente concordou. A atividade “enviar lote criticado” em detalhamento não teve alteração.

4.3 Observações A coleta de diferentes visões de qualidade das pessoas com interesse no sistema foi realizada com dois grupos. A primeira interação se deu com a equipe de TI e permitiu discutir aspectos de qualidade para os elementos do negócio; coletar restrições

Tabela 3 – tabela de elementos de negócio e expectativa de qualidade

Figura 5 – SIG de segurança para EnviarLoteCriticado (lote)

211

para o processo de desenvolvimento do sistema como plataforma de desenvolvimento e banco de dados; e explicitar expectativas de melhoria no tempo de processamento para algumas atividades face à adoção de uma nova tecnologia de desenvolvimento.

A segunda interação ocorreu com clientes e usuário final. Durante a aplicação da sistemática um dos clientes reportou uma sensação de proximidade com TI, não observada em outros levantamentos do qual fez parte. Este relato espontâneo do cliente pode apontar para uma evidência de que a sistemática e o uso dos MNs facilite esta aproximação. O uso do conhecimento sobre o domínio do cliente associado a uma ferramenta de fácil entendimento e aceitação como os diagramas de fluxo de trabalho podem ter facilitado a obtenção de expectativas sobre a qualidade do sistema.

Os termos e diagramas utilizados para projetar sistemas são confortáveis para os profissionais de TI, mas podem não ser apropriados para comunicação e validação de requisitos [12]. Nas oportunidades em que foi utilizado o termo “requisito não funcional” a reação do cliente foi negativa, e questionava se aquela atividade não seria de TI ou enfatizava a sua dificuldade para tratar do assunto. Alguns dos termos técnicos de RNFs podem dar uma idéia de algo distante do usuário final. Perguntar ao cliente se deseja determinadas qualidades em uma linguagem associada aos elementos do seu negócio pode ser mais eficaz.

A equipe de TI não pôde contribuir com sugestões para algumas atividades que não estavam definidas em função de mudanças na estrutura organizacional que ocorriam na empresa e evidenciou-se a necessidade de uma modelagem fechada e validada com o cliente para a execução da sistemática.

A avaliação com clientes e usuários foi conduzida com auxilio dos diagramas de fluxo de trabalho através da seqüência de execução de atividades. Com os diagramas foi possível estabelecer uma dinâmica onde o analista de negócio questionava sobre a qualidade dos elementos de negócio e os clientes e usuários finais explicitavam suas expectativas de qualidade para o sistema e justificavam as qualidades solicitadas. As perguntas sobre a qualidade devem ser exaustivas, os subtipos de RNFs em um catálogo devem ser explorados para cada elemento do negócio de forma que possibilite o stakeholder a expor sua opinião se a qualidade é desejável ou não. Nessa interação o analista de negócio faz uma tradução do NFR-framework para os MNs, para o que ele necessita dominar o significado dos subtipos de RNFs. Um exemplo disso talvez esteja na qualidade “privacidade” para o artefato “lote” que permaneceu em alto nível. Não foram identificados subtipos para esse RNF apesar da existência de catálogo.

Na execução do aplicação, os catálogos mostraram-se úteis para o analista de negócio refletir sobre as qualidades dos elementos do negócio e traduzir essa qualidade do mundo real para o tecnológico. Assim como o SIG, que se mostrou um recurso importante para o registro histórico do levantamento e decomposição de RNFs.

A discussão da qualidade foi conduzida através de um mapeamento com os catálogos e os elementos de negócio em parceria com os stakeholders. O analista de negócio questiona sobre a qualidade dos elementos de negócio com base nos catálogos e na lista de RNFs (Chung, 2000) através de perguntas que devem explorar os tipos e os subtipos de RNFs para os elementos de negócio. Torna-se necessário um esforço do analista

de negócio em fazer essa associação e questionar sobre a qualidade que os stakeholders julguem necessárias. Eles devem responder “por que” a qualidade é atribuída ao elemento de negócio. As razões refletem os “por quês” que estão na intenção e são as justificativas que são documentadas e representadas em gráfico (SIG). Isto pode também indicar a necessidade de criar roteiros de apoio à condução deste levantamento, evitando o uso direto dos catálogos de RNFs durante a discussão. O questionário aplicado na validação pode ser uma solução para orientar o analista na busca de qualidades desejadas para os elementos de negócio. Questionar se o stakeholder deseja integridade para o seu “Lote de dose” pode gerar resistências na sua participação. É necessário explicar as conseqüências da violação da integridade e discutir em que a violação de um artefato que pode afetar no negócio. Cabe ao cliente decidir a importância e necessidade dessa qualidade para o seu negócio

Na avaliação da aplicação da sistemática, observou-se necessidade de ajustes na primeira fase definida como o levantamento da qualidade. A visão do analista de negócio sobre a qualidade dos elementos de negócio posteriormente submetida aos stakeholders limita a discussão sobre qualidade, comprometendo a intenção da proposta de reflexão ampla entre os diversos stakeholders. Esta observação aponta para a necessidade de ajuste na sistemática, indicando que a fase inicial seja realizada já em parceria com os stakeholders.

As limitações da sistemática proposta observadas durante a sua aplicação podem estar:

• na qualidade dos MNs já que o detalhamento de informações dos modelos pode influenciar a identificação de qualidades dos elementos do negócio;

• na disponibilidade de catálogos de RNFs, a organização que possua catálogos próprios tem vantagens com o uso da sistemática sobre aquela que não os possui. São poucos os catálogos disponíveis na literatura, o que implica em ter RNFs identificados em alto nível;

• no perfil do analista de negócio que necessita dominar a semântica dos catálogos, o que também pode influenciar na granularidade dos RNFs.

5. CONCLUSÃO A realização preliminar de aplicação da sistemática proposta permitiu rever sua concepção e identificar os ajustes necessários. Através desta aplicação verificou-se a possibilidade de se ter nos MNs uma ferramenta para conduzir e orientar clientes e usuários na exposição de expectativas de qualidade para seus elementos de negócio. Por outro lado a sistemática é dependente do analista de negócio em relação a sua habilidade em traduzir os catálogos para os stakeholders e capacidade para traduzir as expectativas em RNFs.

Encontra-se em planejamento um estudo de caso de aplicação da sistemática com a participação de equipes externas ao desenvolvimento desta proposta, aplicado também em contextos reais. O estudo de caso será planejado com o objetivo de avaliar: a viabilidade de aplicação da sistemática proposta; os benefícios e limitações do uso de MNs na comunicação entre stakeholders; os elementos dos MNs como indicadores de qualidade e, consequentemente, RNFs; a capacidade da sistemática em identificar RNFs com uma menor granularidade que as obtidas em

212

outras propostas; a relação entre o detalhamento dos modelos e a possibilidade de identificar requisitos.

Para trabalhos futuros são necessárias: pesquisas sobre os atributos de qualidade de uma arquitetura de sistema que são pouco explorados [34]; estudos de como tratar expectativas conflitantes de qualidade entre diferentes stakeholders; a possibilidade de aplicação da sistemática em modelos intencionais como i* [33]; estudos de caso comparativos em relação aos resultados obtidos com a sistemática.

6. AGRADECIMENTOS À Comissão Nacional de Energia Nuclear, pelo apoio ao desenvolvimento deste trabalho.

7. REFERENCIAS [1] Alencar, F.; Castro, J.; Monteiro, C.; Ramos, R.; Santos, E.,

2008. Towards Aspectual i*.In Proceedings of the 3rd International i* Workshop (Recife, Brazil, Feb,2008). IStar’08.322, 1-4.

[2] Berio, G; Verdanat, F.Enterprise Modelling with CIMOSA: Functional and Organizational Aspects, 2001. Production Planning &Control, 12, 128-136.

[3] Boehm, B.W.; In, H., 1996. Identifying Quality Requirements Conflicts, IEEE Software,13, 25-35.

[4] Chung, L; Nixon, B.; Yu, E; Mylopoulos, J., 2000. Non-Functional Requirements in Software Engineering .Massachusetts.USA. Kluwer Academic Publishers.

[5] Cleland-Huang, J.; Settimi,R.; Zou, X.; Solc, P., 2007. Automated Classification of Non-Functional Requirements, Requirements Engineering Journal, 2, 103-120. (april 2007)

[6] Cruz, P.O., 2004. Heurísticas para identificação de requisitos de sistemas de informação. Dissertação de M.Sc. NCE/UFRJ, Rio de Janeiro, RJ, Brasil.

[7] Cunha, H., 2007. Uso de Estratégias Orientadas a Metas para modelagem de requisitos de Segurança. Dissertação de M.Sc. Departamento de informática. PUC-Rio de Janeiro, RJ, Brasil.

[8] Cysneiros, L.M., 2007. Evaluating the Effectiveness os using Catalogues to Elicit Non-Functional Requirements. In Proceedings of 10th Workshop in Requirements Engineering (Toronto, Canada, May, 2007), 107-115

[9] Cysneiros,L.M., 2008 . DOI= http://www.math.yorku.ca/~cysneiro/nfrs/nfrs.htm.

[10] Davenport, T.H., 1994. Reengenharia de Processos: como inovar na empresa através da tecnologia da informação. 3ª ed. Rio de Janeiro, Editora Campus.

[11] De la Vara, J.L.; Alcolea, D.E; Diaz, J.S., 2007. Descomposición de árboles de metas a partir de modelos de procesos. In Worshop em Engenharia de Requisitos (Toronto, Canadá, May, 2007), 35-46.

[12] De la Vara, J.L.; Sánchez, J.; Pastor, O., 2008.Business Process Modelling and Purpose Analysis for Requirements Analysis of Information Systems, In Advanced Information Systems Engineering, 5074, Lecture Notes in Computer Science, Bellahsène and Léonard (Eds), Springer, Heidelberg, 213-227

[13] Demidörs, O.; Gencel, Ç.; Tarhan, A., 2003. Utilizing Business Process Models for Requirements Elicitation.In Proceedings of the 29th EUROMICRO Conference, IEEE CS Press, 409-412.

[14] Eriksson, H. E; Penker, M., 2000. Business Modeling with UML:Business Patterns at work. New York: Wiley Publishers.

[15] Hochmüller, E., 1997. Requirements Classification as a First Step to Grasp Quality Requirements.In Proceedings of 3rd Iternational Workshop on Requirements Engineering Foundation of Software Quality.REFSQ’97, 133-144.

[16] ISO/IEC 9126:1991(E), 1991, Information Technology – Software product evaluation – Quality characteristics and guidelines for their use

[17] Leite, J.C.S.P. 1994, Elicitação de Requisitos. In Notas de aula, PUC-Rio. Dói http://livrodeengenhariaderequisitos.googlepages.com/ERNOTASDEAULA.pdf.

[18] MacKnight, D., Araújo, R.M.; Borges, M.R., 2005. A Systematic Approach for Identifying System Requirements from the Organizationan Business Model, In II Simpósio Brasileiro de Sistemas de Informação, (Florianopolis, Brasil). SBSI 2005.

[19] Mylopoulos, J.; Chung, L.; Nixon, B., 1992. Representing and using Nonfunctional Requirements: A Process-Oriented Approach, IEEE.Trans on software engineering, 18, 6, 483-497.

[20] OMG: Business Process Modelling Notation (BPMN) Specification (on line). DOI= http://www.bpmn.org.

[21] Paech,.B.;.Kerkow,.D., 2004. Non-Functional Requirements Engineering- Quality is Essential, In International Workshop on Requirements Engineering. REFSQ’04, 27-40.

[22] Paim, R., 2007. As Tarefas para Gestão de Processos. Tese de D.Sc. Programa de Engenharia de Produção COPPE/UFRJ.Rio de Janeiro, RJ, Brasil.

[23] Pavlovski, C.J.; Zou, J., 2008. Non-Functional Requirements in Business Process Modeling. In Proceedings of 5th Ásia-Pacific Conference on Conceptual Modelling,. (Wollongong, NSW, Austrália) APCCM2008. 79

[24] Rashid, A; Wiesenberger, J.; Meder,D.; Baumann, J. 2008. Bringing Developers and Users closer together: The penProposal story. Multikonferenz Wirtschaftsinformatik. PRIMIUM 2008. (Garching, Germany, Feb). DOI= http://ftp.informatik.rwth-aachen.de/Publications/CEUR-WS/Vol-328.

[25] Röhrig, S., 2003. Using Process Models to Analyse IT Security Requirements. Tese de D.Sc.Universidade de Zurique.

[26] Santander, V.F.A; Castro, J.F.B., 2000. Desenvolvendo Use Cases a partir de Modelagem Organizacional. In Worshop em Engenharia de Requisitos (Rio de Janeiro, Brasil, Julho,2000). WER00, 158-180.

[27] Sharp, A; McDermott, P., 2001. Workflow Modeling: Tools for Process Improvement and Application Development. Boston, London. Artech House.

213

[28] Sommerville, I., 2003. Engenharia de Software. 6ª ed. São Paulo.Addison Wesley.

[29] Villanueva, I.; Sánchez,J.; Pastor, O., 2005. Elicitación de requisitos em sistemas de gestión orientados a procesos. In Workshop in Requirements Engineering (Porto, Portugal. Junho, 2005).WER05, 38-49.

[30] Webster, I.; Amaral, J.; Cysneiros, L.M., 2005. Reusable Knowledge for Achieving Privacy: A Canadian Health Information Technologies Perspective. In Proceedings of Workshop in Requirements Engineering (Porto, Portugal, Junho, 2005). WER05, 112-122.

[31] Wiegers, K.E., 2003. Software Requirements. 2ª ed. Washington, USA. Microsoft Press

[32] Weiß, D.; Leukel, J.; Kirn, S., 2008. A Method for Aligning Business Process Modeling and software Requirements Engineering. Multikonferenz Wirtschaftsinformatik. PRIMIUM 2008 (Garching, Germany, Feb). DOI= http://ftp.informatik.rwth-aachen.de/Publications/CEUR-WS/Vol-328.

[33] Yu, E., 1995. Models for supporting the redesign of Organizational Work. In Proceedings of Conference On Organizational Computing Systems (Milpitas, California, August, 1995).COOCS’95, 225-236.

[34] Zou, J.; Pavlovski, C.J.; 2006. Modelling Architectural Non Functional Requirements:From Use Case to Control Case. In:Internatinal Conference on e-Business Engineering (Shanghai, China.,out,2006). ICEBE’06, 315-322.

214