Identificação de Requisitos Não Funcionais de Sistemas através de Modelos de Negócio

Transcrição

1 Identificação de Requisitos Não Funcionais de Sistemas através de Modelos de Negócio Aluna: Rosaria Viana Bittencourt¹ Orientadora: Renata Araujo¹ ¹Programa de Pós-Graduação em Informática Universidade Federal do Estado do Rio de Janeiro (UNIRIO) Av. Pasteur 458, Térreo, Urca, Rio de Janeiro, RJ Brasil {rosaria.viana, Nível: Mestrado Ano de Ingresso: 2007 Previsão de Conclusão: Dezembro de 2008 Aprovação da Proposta: Abril de 2008 Resumo. Os Requisitos Não Funcionais (RNFs) estão associados às expectativas dos clientes e desenvolvedores sobre as qualidades de um Sistema de Informação. 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 propõe uma forma sistemática de identificação de RNFs apoiada nos Modelos de Negócio organizacionais. Espera-se avaliar o potencial dos Modelos de Negócio como instrumento para antecipar a identificação de RNFs com a participação dos stakeholders. Palavras-chave: Requisitos não-funcionais, identificação, Modelos de Negócio, NFR Framework. 37

2 1. Caracterização do Problema Os Requisitos Não Funcionais (RNFs) desempenham um papel crítico no desenvolvimento de sistemas e são reconhecidamente os mais caros e difíceis de corrigir após sua construção (Mylopoulos et al, 1992; Chung et al, 2000; Cleland-Huang, 2007). A identificação de RNFs é dificultada por seus detalhes técnicos, seu impacto global sobre o sistema, sua complexa rede de interdependências e sua subjetividade (Cleland- Huang, 2007; Chung et al, 2000). Na década de 90, Mylopoulos et al (1992) apontavam como problema a pouca atenção que a pesquisa em Engenharia de Software dedicava aos RNFs. O resultado do trabalho daqueles autores foi um framework para representar RNFs e que ainda é o catálogo mais citado e utilizado nos trabalhos consultados (Chung et al., 2000; Cysneiros, 2007). O tema cresceu em importância (Cunha, 2007; Cleland-Huang, 2007; Cysneiros, 2007), mas ainda percebe-se a ausência de um processo completo para tratar RNFs desde sua identificação até sua implementação. Este trabalho aborda, em particular, a questão da identificação de RNFs, em geral realizada de forma ad-hoc e tardia no processo de desenvolvimento (Cleland- Huang, 2007). Sua identificação informal durante a análise de requisitos compromete a qualidade do produto resultando na insatisfação do cliente e re-trabalho. Adicionalmente, as propostas de identificação de RNFs tendem a não considerar a aderência destes requisitos às necessidades do negócio da organização onde o sistema se insere (Röhrig, 2003; Weiß et al., 2008; Pavlovski and Zou, 2008). O objetivo deste trabalho é propor uma forma sistemática para identificar RNFs, com a participação dos interessados no desenvolvimento do sistema. Dois princípios norteiam este trabalho. O primeiro envolve os Modelos de Negócio (MNs) como instrumento para identificar requisitos de sistemas, com suporte às atividades de um negócio, alinhamento aos objetivos da organização e antecipar a elicitação no processo de desenvolvimento de software. O segundo envolve o NFR-framework, que oferece um suporte sistemático para decompor, representar, priorizar, operacionalizar, tratar das interdependências entre RNFs e registrar as justificativas que dão suporte à priorização e ao refinamento de propriedades não funcionais. A hipótese que se pretende verificar é que MNs possibilitam a identificação sistemática de RNFs a partir da análise da qualidade esperada dos elementos explícitos no modelo (atividades, artefatos, atores) com a colaboração dos envolvidos na construção do sistema. 2. Fundamentação teórica 2.1. Requisitos Não Funcionais A complexidade de um sistema é determinada pela sua funcionalidade e por requisitos que se relacionam com a qualidade esperada do sistema 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 (Sommerville, 2003; Leite, 2006). O NFR_framework (Chung et al, 2000) propõe uma forma sistemática para decompor RNFs, priorizar, operacionalizar, tratar das interdependências e registrar o rationale que define as decisões do projeto a ser desenvolvido. O conceito fundamental 38

3 é o softgoal que representa as intenções ou razões dos envolvidos no sistema. Esse objetivo flexível e subjetivo tem em seu conjunto de tipos o NFR-softgoal, que representa RNFs. O framework tem a vantagem de oferecer aos desenvolvedores um conhecimento representado em catálogos, que dão suporte a uma obtenção sistemática dos RNFs de mais baixo nível. No entanto, a técnica não propõe uma forma sistemática para identificar os RNFs de alto nível e o processo de captura de decisões para o projeto tende a concentrar na visão dos desenvolvedores do sistema. 2.2 Modelo de Negócio Modelos de Negócio (MNs) (Berio e Verdanat, 2001) são uma abstração da realidade de organizações sob o ponto de vista do negócio e representam o ambiente no qual estão inseridas. MNs podem ser elaborados através de diferentes metamodelos ou linguagens - UML, BPMN, IDEF, fluxogramas - que oferecem elementos para representar um negócio: atividades de um fluxo de trabalho, pessoas ou papéis da organização envolvidas nas atividades do negócio, artefatos produzidos e manipulados. E representam também os objetivos estratégicos e organizacionais, a estrutura da organização e sua distribuição geográfica, e as trocas, realizadas na fronteira do negócio, representadas através da interação com clientes e fornecedores. Os MNs têm sido sugeridos como um instrumento que pode oferecer à Engenharia de Requisitos um suporte para a identificação de requisitos de sistemas que atendam às necessidades do negócio, ao perfil da organização e aos objetivos que o sistema deve atender (Santander and Castro, 2000; Cruz, 2004; MacKnight et al., 2005; Villanueva et al., 2005; De La Vara et al, 2007). Argumentamos que MNs auxiliam a identificação da qualidade percebida e esperada para os diversos elementos que representam um processo de negócio e facilitam os stakeholders a expor suas expectativas de qualidade ajudando a pensar no que desejam como um todo através de seus processos de negócio. Os desenvolvedores traduzem essas expectativas em qualidade de sistema. 3. Caracterização da contribuição A execução da sistemática proposta para a identificação de RNFs a partir de MNs tem inicio em uma solicitação de automação de atividades na organização, que se não possuir MNs elaborados e atualizados pode modelar seus processos com a finalidade de discutir o sistema necessário ao negócio. 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. A sistemática possui os seguintes passos: analisar a qualidade esperada nos elementos do negócio: compreender o domínio do negócio através dos MNs e associar atores, atividades e artefatos às qualidades sugeridas pelo processo; identificar os NFR-softgoals de alto nível: utilizando MNs e em parceria com a equipe de desenvolvimento são discutidas as qualidades dos elementos do negócio, as restrições de desenvolvimento na organização e expectativas de qualidades do sistema. 39

4 As qualidades são associadas aos NFR-softgoals de alto nível com auxilio de catálogos disponíveis (Chung, 2000; Webster et al, 2005; Cysneiros, 2005); capturar claim-softgoals: a qualidade necessária para os elementos do negócio é analisada em parceria com stakeholders com auxilio dos MNs. As justificativas dos stakeholders descartam e incluem RNFs de alto nível e são representadas no SIG através de claim-softgoals; decompor RNFs: a qualidade contribui com os tipos de RNFs que são decompostos com o auxilio de catálogos e associados aos tópicos obtidos a partir dos elementos dos MNs. O SIG representa a decomposição de tipos e tópicos específicos para o domínio; especificar RNFs: documentar a associação entre processos, atividades, tipos de RNFs e tópicos com suporte da notação proposta por Chung et al.(2000) onde tipotópico é expresso no formato tipo-rnf [atividade(artefato, ator)] e a argumentação no formato claim [ argumento ]; Validar RNFs: a equipe de desenvolvimento, os usuários finais e gerentes do negócio validam os RNFs. O produto é composto por RNFs e argumentos identificados, documentados e confirmados pelos stakeholders. 4. Estado atual do trabalho O levantamento bibliográfico permitiu entendimento do cenário de pesquisa sobre Modelos de Negócio (MNs) e RNFs, desenvolvimento da proposta, escrita deste artigo e da parte conceitual da dissertação envolvendo RNFs, MNs e Trabalhos Relacionados. O processo de aprendizado conceitual envolveu RNFs, NFR-framework e a técnica i* (Yu, 1995). A pesquisa teve continuidade com a busca de trabalhos que tivessem como ponto de partida o NFR-framework ou a técnica i* para tratar de RNFs em diversas fases da Engenharia de Requisitos. Atualmente a sistemática está sendo detalhada em termos de procedimentos e instruções para sua aplicação, bem como as ferramentas e documentação necessárias para sua execução. Um exercício exploratório de aplicação da sistemática visando ajustes é previsto nesta fase. 5. Trabalhos Relacionados A pesquisa permitiu identificar diferentes estratégias para se obter os Requisitos Funcionais (RFs) a partir de modelos organizacionais (MacKnight et al., 2005; Cruz, 2004; Villanueva et al, 2005; De La Vara et al, 2007). Apesar da relevância dos RNFs para os SI que oferecem suporte aos negócios, o foco está nos RFs. Santander and Castro (2000) têm como objetivo obter requisitos com a técnica i*, mas os RNFs são tratados de forma secundária e não sistemática. Cunha (2007) identifica requisitos de segurança tendo como base a técnica i*, mas os modelos, segundo o autor, são complexos e tendem a uma dificuldade que compromete a escalabilidade e manutenção (De la Vara, 2007; Alencar et al.,2008). Röhrig (2003) apresenta um método para definir medidas de segurança, mas não há uma sistemática para definir os níveis de segurança como também não há participação dos stakeholders. 40

5 Demirörs et al (2003) utilizam grupos de trabalho distintos e trabalham de forma diferenciada para identificar requisitos de segurança e os demais RNFs. Pavlovski e Zou (2008) propõem uma extensão ao BPMN para representar RNFs. Os RNFs identificados estão em alto nível de abstração e os não operacionalizáveis são tratados posteriormente na fase de projeto. 6. Avaliação dos Resultados Serão realizados exercícios preliminares aplicando o método proposto, com objetivo de rever a especificação da sistemática e aplicar os ajustes necessários. Como exercícios, planejamos a aplicação da sistemática em diferentes contextos/processos organizacionais com o objetivo de desenvolvimento de sistemas em: Proteção Radiológica de Trabalhador (Comissão Nacional de Energia Nuclear), Apoio ao Processo de Seleção de Candidatos (Programa de Pós-Graduação em Informática UNIRIO) e Processos de Controle de Acesso de Pessoas em uma empresa nacional. Um estudo de caso posterior com a participação de equipes externas ao desenvolvimento desta proposta 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 e desenvolvedores; 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 outras propostas; a relação entre o detalhamento dos modelos e a possibilidade de identificar requisitos. Estudos de caso comparativos em relação aos resultados obtidos com a sistemática poderão ser realizados como trabalhos futuros em continuidade aos resultados obtidos com esta dissertação. Agradecimentos: À Comissão Nacional de Energia Nuclear, pelo apoio ao desenvolvimento deste trabalho. 7. Referências Alencar, F.; Castro, J.; Monteiro, C.; Ramos, R.; Santos, E. (2008) Towards Aspectual i*.in:proc.3rd Intern. i* Workshop, pp 1-4, Recife, Brazil, Feb. Berio,G; Verdanat, 2001, F. Enterprise Modelling with CIMOSA: Functional and Organizational Aspects, Production Planning &Control v 12, nº 2, p Chung, L; Nixon, B.; Yu, E; Mylopoulos, J.(2000) Non-Functional Requirements in Software Engineering.Massachusetts. USA, Kluwer Academic Publishers. Cleland-Huang, J.; Settimi, R.; Zou,X.; Solc, P.(2007) Automated Classification of Non-Functional Requirements, Requirements Engineering Journal, v2, nº2 (april), pp 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. 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. 41

6 Cysneiros, L.M.; Werneck, V.; Kushniruck, A.(2005) Reusable Knowledge for Satisficing Usability Requirements, In: Proc 13th IEEE International Conference on Requirements Engineering RE 05,vol. 29, pp , septemb. Cysneiros, L.M.(2007) Evaluating the Effectiveness os using Catalogues to Elicit Non- Functional Requirements. In: Proc. of 10th Workshop in Requirements Engineering, pp , Toronto, Canada, May. 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, pp 35-46, Toronto, Canadá, May. Demidörs, O.; Gencel, Ç; Tarhan, A.(2003) Utilizing Business Process Models for Requirements Elicitation.In: Proc of the 29 th EUROMICRO Conference, IEEE CS Press Leite, J.C.S.P.(2006) Requisitos: a ponte entre a organização e o software. Palestra em Seminário Internacional de Engenharia de Software, Julho. Disponível em acesso 16/04/2008. MacKnight, D.; Araujo, R; Borges, M.R.S.(2005) A Systematic Approach for Identifying System requiremts from the Organization s Business Model. In: I Simposio Brasileiro de Sistemas de Informação.SBSI Porto Alegre, RS, Brasil. Mylopoulos, J.; Chung, L; Nixon, B.(1992) Representing and using Nonfunctional Requirements:A Process-Oriented Approach, IEEE.Trans on software engineering, v18, n.6 (jun), pp Pavlovski, C.J.; Zou, J. (2008) Non-Functional Requirements in Business Process Modeling. In: 5 th Asia-Pacific Conference on Conceptual Modeling, v 79, Wollongong, NSW, Australia. Röhrig, S. (2003) Using Process Models to Analyse IT Security Requirements. Tese de D.Sc.Universidade de Zurique, Suiça. Santander,V.F.A; Castro, J.F.B. (2000) Desenvolvendo Use Cases a partir de Modelagem Organizacional. In: Worshop em Engenharia de Requisitos, pp , Rio de Janeiro, Brasil, Julho. Sommerville, I.(2003) Engenharia de Software. 6ª ed. São Paulo.Addison Wesley. Villanueva, I.; Sánchez,J.; Pastor, O.(2005) Elicitación de requisitos em sistemas de gestión orientados a procesos. In: Workshop em Engenharia de Requisitos, pp 38-49, Porto,Portugal. junho. Webster,I.; Amaral,J.; Cysneiros,L.M., 2005, Reusable Knowledge for Achieving Privacy: A Canadian Health Information Technologies Perspective in Proc. VIII Workshop in Requirements Engineering, Porto, Portugal, pp Weiß, D.; Leukel, J.; Kirn, S. (2008) A Method for Aligning Business Process Modeling and software Requirements Engineering.Process Innovation with Business Software. Garching, Germany, Feb. Yu, E.(1995) Modelling Strategic Relationships for Process reengineering. Tese de D.SC Department of Computer Science. University of Toronto. Canadá. 42