III CONGRESO INTERNACIONAL

DE

COMPUTACIN

TELECOMUNICACIONES

Proposta de uma Abordagem para Especificao de Requisitos Baseada em Projeto Axiomtico

Ana Maria Pereira1 , Paulo Czar Stadzisz1, Jean Marcelo Simo1 Universidade Tecnolgica Federal do Paran 1 Programa de Ps-graduao em Engenharia Eltrica e Informtica Industrial (CPGEI) a995479@pos.utfpr.edu.br, stadzisz@utfpr.edu.br, jeansimao@utfpr.edu.br

Resumo
Desde as primeiras dcadas do surgimento da informtica so identificados problemas relativos definio de requisitos de sistemas de software. Entender o que o cliente espera de um sistema de software uma das tarefas mais difceis enfrentadas pelos analistas de negcios e requisitos. Com o objetivo de contornar este problema, foram criadas diversas tcnicas de especificao de requisitos, como especificaes textuais, casos de uso, etc. Apesar destas tcnicas oferecerem resultados promissores na descrio dos requisitos, elas falham na cobertura das necessidades do cliente. Sendo assim, o uso de um mtodo focado no detalhamento e avaliao dos problemas resultaria em um software mais contundentes com as necessidades levantadas. Neste contexto, este trabalho apresenta uma proposta de abordagem para a especificao de requisitos baseada em Projeto Axiomtico. Este mtodo consiste de trs passos: (1) o mapaemento de problemas, necessidades e requisitos em uma matriz de rastreabilidade, (2) avaliao da matriz segundo o Axioma da Independncia e, por fim, (3) a decomposio dos problemas, necessidades e requisitos. Estes passos so repetidos ciclicamente at que se atinja um nvel de detalhamento satisfatrio. Os resultados dos experimentos atestaram que este mtodo oferece auxlio na elaborao de um conjunto de requisitos de sistema mais consistente. Palavras chave: Requisitos, Necessidades do Cliente, Problema, Projeto Axiomtico, Matriz de Rastreabilidade

Abstract
Since the early decades of the rise of computer science it has been identified problems on the definition of requirements for software systems. Understanding what the customer expects from a software system is one of the hardest tasks faced by business analysts and requirements. In order to overcome this problem, have been created several techniques for requirements specification, such as textual specifications, use cases, etc. Although these techniques offer promising results in the description of requirements, they fail to cover the needs of the client. Therefore, the use of a method focused in detailing and evaluating of the problems can result in software more coherent with the client needs. In this context, this paper presents a proposed approach to requirements specification based on axiomatic design. This method consists of three steps: (1) mapping the problems, needs and requirements through a traceability matrix, (2) evaluating the matrix according to the Axiom of Independence and, finally, (3) decomposing problems, needs and requirements. These steps are cyclically repeated until it reaches a satisfactory level of detail. The results of experiments testified that this method offers good results in preparing a more consistent set of system requirements. Keywords: Requirements, Client Needs, Problem, Axiomatic Design, Traceability Matrix

1. Introduo
Desde as primeiras dcadas do surgimento da informtica identificaram-se problemas relativos elaborao e desenvolvimento de projetos de software. Logo no incio dos anos 70
1

III CONGRESO INTERNACIONAL

DE

COMPUTACIN

TELECOMUNICACIONES

foi criado o termo Crise de Software para expressar as dificuldades enfrentadas pelos desenvolvedores na elaborao de seus projetos (DIJKSTRA, 1972). Naquela poca, a engenharia de software era quase que inexistente e os problemas mais comuns costumavam ser: estouro no oramento ou no prazo; baixa qualidade dos projetos; produtos que muitas vezes no atendiam os requisitos; e cdigos difceis de manter. Nos dias atuais, embora muitos avanos tenham sido realizados na rea da engenharia de software, os problemas parecem continuar sendo os mesmos. Estatsticas apresentadas pelo Chaos Report 2009 (DOMINGUEZ, 2009) demonstram que os projetos de software tm percentuais de sucesso que giram em torno de apenas 30% como apresenta a Tabela 1. Alm disso, estudos relacionados Engenharia de Software apontam fortes evidncias de que os mais srios problemas de projetos esto diretamente relacionados definio e entendimento de requisitos (LEFFINGWELL & WIDRIG, 2003). Neste contexto, pode-se afirmar que um dos principais desafios de um projeto de software est em especificar e construir um produto que garanta a satisfao das necessidades do cliente com alta qualidade e dentro dos prazos e custos estimados. Tendo em vista esse desafio de atender as necessidades do cliente, procura-se garantir que todas elas sejam atendidas por meio da especificao e rastreamento de requisitos. Ao bem da verdade, a maioria das abordagens de especificao de requisitos foca na soluo. Entretanto, ainda assim, uma grande parte dos projetos no tem o resultado esperado.
Distribuio de resultados de projetos de software Resultados Sucesso (no prazo, dentro do oramento e com escopo completo) Mudaram (atrasaram, estourou o oramento, e/ou reduziram escopo) Falharam (cancelados ou nunca usados)

Percentual 32% 44% 24%

Tabela 1 Distribuio de resultados de projetos Adaptado de (DOMINGUEZ, 2009)

Estudando-se os trabalhos de inmeros autores possvel perceber que boa parte deles trata superficialmente os termos problema e necessidade do cliente, como possvel observar em (LEFFINGWELL & WIDRIG, 2003), (SUH & DO, 2000) e (BALMELLI, 2007) somente para citar alguns exemplos. Por outro lado, observa-se que o claro entendimento dos problemas e necessidades do cliente costuma ser um ponto chave para o desenvolvimento da especificao de requisitos de software. Por esta razo, um dos principais objetivos deste trabalho foi estudar mais atentamente os Problemas e as Necessidades dos clientes e seu mapeamento para requisitos de software. Outro objetivo desta pesquisa foi estudar e demonstrar a aplicabilidade do Axioma da Independncia proposto por Suh (SUH, 2001) s atividade de anlise do problema e especificao der requisitos de software por meio de matrizes de rastreabilidade. A abordagem proposta pretende oferecer aos engenheiros de requisitos um mtodo eficaz para diminuir as dificuldades em compreender e modelar os requisitos do sistema que deve ser construdo. Assim sendo, o objetivo principal desse artigo propor uma abordagem de especificao baseada no Axioma da Independncia da Teoria de Projeto Axiomtico. O restante deste artigo est organizado da seguinte maneira. Na seo 2 apresentam-se alguns trabalhos anteriores, tanto relacionados ao tema de Projeto Axiomtico como de especificao de requisitos. Na seo 3 trata-se da abordagem proposta de especificao de requisitos baseada em Projeto Axiomtico. A seo 4 apresenta a metodologia utilizada nos experimentos realizados e traz um exemplo da aplicao desta abordagem. As discusses referentes aos resultados obtidos nos experimentos encontram-se na seo 5 e, nalmente, na seo 6 apresenta-se uma breve concluso do trabalho.

III CONGRESO INTERNACIONAL 2. Trabalhos Relacionados

DE

COMPUTACIN

TELECOMUNICACIONES

A teoria de Projeto Axiomtico, apresentada pela primeira vez em 1990 (SUH, 1990), tem como fundamento dois axiomas que, segundo o autor, se aplicam a todos os tipos de projetos sem exceo. O primeiro o Axioma da Independncia, segundo o qual se deve buscar a independncia dos requisitos funcionais do projeto. Isso significa que a independncia entre requisitos deve ser mantida, de maneira que eles sejam atendidos sem afetar uns aos outros (SUH, 2001). O segundo o Axioma da Informao que diz que se deve minimizar o contedo da informao do projeto. Ou seja, entre diversos projetos que satisfazem o primeiro axioma, o melhor aquele que possui a menor contedo de informao (PIMENTEL, 2007). Outro conceito apresentado na teoria de Projeto Axiomtico o de Domnios de Projeto (SUH, 2001). Segundo o autor, o mundo dos projetos consiste de quatro domnios: do cliente, funcional, fsico e de processo. No domnio do cliente encontram-se esto localizadas as necessidades. Os requisitos funcionais encontram-se no domnio funcional e no domnio fsico esto os parmetros de projeto. Por fim, no domnio de processo encontram-se as variveis de processo. Alm disso, o trabalho de Suh apresenta a Matriz de Projeto que uma ferramenta para a avaliao do nvel de dependncia funcional. Nessa matriz so mapeados os relacionamentos entre Requisitos Funcionais (RF) e Parmetros de Projeto (PP) que atendem os requisitos. Uma matriz de projeto em que exista um PP para cada RF e que cada RF seja relacionado com somente um PP chamada de Desacoplada e o tipo de matriz ideal (SUH, 1990). Conforme ilustra a Figura 1, alm da matriz Desacoplada existem outros dois formatos de matriz de projeto: o Semi-acoplado, que aceitvel; e o Acoplado, que no aceitvel e deve ser eliminado. Finalmente, Suh (2001) introduz o conceito de processo em Zig-zag em que, em um primeiro momento, os PPs so mapeados para os RFs em uma matriz e, em seguida, o projeto avaliado de acordo com o primeiro axioma. Caso a matriz seja desacoplada ou semi acoplada, RFs e PPs so decompostos e novamente realiza-se o mapeamento. O processo segue sucedendo-se mapeamento e decomposio at que no seja mais possvel ou necessrio decompor os elementos. Por ter uma natureza livre de domnio, o Projeto Axiomtico pode ser facilmente aplicado nas mais diversas reas, como sistemas de manufatura, engenharia de materiais, administrao e, inclusive, na rea de desenvolvimento de software. Em sistema de software o primeiro trabalho que abordou a aplicao de projeto axiomtico para o desenvolvimento de sistemas de software orientados a objetos foi apresentado por KIM, SUH e KIM (1992). Em Pimentel (2007), apresentada uma abordagem de projeto de software orientado a objetos que se baseia na teoria de Projeto Axiomtico. Neste trabalho so estabelecidas correspondncias dos conceitos de Requisitos Funcionais e Parmetros de Projeto com elementos da UML. Assim, casos de uso so utilizados para representar os requisitos funcionais e colaboraes para representar os parmetros de projeto (BOOCH, RUMBAUGH, & JACOBSON, 2006). Alm disso, o trabalho citado estabelece uma srie de outros conceitos que permitem a decomposio dos elementos da UML em outros nveis de abstrao. Desta forma, o autor estabelece uma inovadora integrao entre projeto axiomtico e as tcnicas mais utilizadas no desenvolvimento de software, que so a UML e o Processo Unificado.
RF1 RF2 RF3 PP1 PP2 X 0 0 X 0 0 Desacoplada PP3 0 0 X RF1 RF2 RF3 PP1 PP2 PP3 X 0 0 X X 0 X 0 X Semi-acoplada RF1 RF2 RF3 PP1 PP2 X X X X 0 X Acoplada PP3 X X X

Figura 1 - Tipos de matriz de projeto

Existem inmeros trabalhos na literatura sobre a especificao de requisitos, em sua grande

3

III CONGRESO INTERNACIONAL

DE

COMPUTACIN

TELECOMUNICACIONES

maioria estes trabalhos so focados nos aspectos de gesto, outros, no entanto so focados em tcnicas. Suh cita rapidamente em seu livro (SUH, 2001) a ideia de mapeamento do domnio do cliente, que o domnio das necessidades do cliente, para o domnio funcional, mas no chega a sugerir nenhum tipo de tcnica neste mapeamento. Por sua vez, Leffingwel e Widrig (2003) tratam da anlise do problema como um processo de entendimento dos problemas e das necessidades do usurio seguida pela proposio de soluo que atende essas necessidades. Eles destacam a necessidade de identificar e descrever o problema que ser solucionado pelo software. Os autores tambm sugerem o uso de matrizes para rastrear as necessidades do cliente para caractersticas do sistema e essas caractersticas para casos de uso. Por outro lado, Jackson (1995) apresenta o conceito de Quadros de Problema (Problem Frames) que se baseia na ideia da decomposio dos problemas do cliente. O autor acredita que esta a melhor forma de realizar a anlise de requisitos. Seu objetivo analisar problemas de maneira mais realstica decompondo-os em subproblemas que correspondem a Quadros de Problemas pr-estabelecidos. Apesar de defender o detalhamento dos problemas como uma forma de identificar os requisitos do cliente, o trabalhos sobre esta abordagem no conseguem explicar de que maneira clara como seria o processo de composio da soluo a partir dos quadros de problemas, o que dificulta sua aplicao comercial (LI, 2007).

3. Proposta de Abordagem de Especificao de Requisitos

O objetivo desta seo apresentar a abordagem de especificao de requisitos proposta neste trabalho de pesquisa. 3.1. Domnios do Desenvolvimento de Software Em seu livro Leffingwell e Widrig (1990) apresentam uma viso de domnios da soluo e do problema que representa o domnio do problema como uma nuvem composta por informaes confusas e desorganizadas. Durante este trabalho de pesquisa o domnio do problema foi reorganizado e a informao que formava a nuvem passou a compor uma pirmide, conforme ilustrado na Figura 2. Desta forma, nessa abordagem, o topo da Pirmide, que representa o Domnio do Problema, possui trs nveis: Necessidades Humanas ou Organizacionais, Problemas e Necessidades do Cliente. J a base da pirmide, que representa o Domnio da Soluo, possui outros trs nveis: Caractersticas, Requisitos e Casos de Uso.

Figura 2 - Nova viso de Domnios de Problema e Soluo

As definies dos termos utilizados neste modelo so apresentadas a seguir:

III CONGRESO INTERNACIONAL

DE

COMPUTACIN

TELECOMUNICACIONES

Necessidades Humanas ou Organizacionais: um estado de insatisfao causado pela falta de algum bem necessrio ao bem estar (CARVER & SCHEIER, 2007). Problema: algo que impulsiona o cliente a buscar uma soluo e gera uma necessidade. Necessidade: um comportamento ou propriedade que o cliente espera do sistema que, na sua interpretao, ir resolver seu problema (LEFFINGWELL & WIDRIG, 2003). Caracterstica: servio ou propriedade oferecida pelo sistema para atender uma necessidade do cliente (LEFFINGWELL & WIDRIG, 2003). Requisito Funcional: uma capacidade do software que o usurio necessita para resolver um problema ou que existe para satisfazer um contrato, padro, especificao ou outra documentao imposta formalmente (DORFMAN & THAYER, 1990). Caso de Uso: a especificao de um conjunto de aes que representa uma utilizao completa do sistema por um ou mais atores (PIMENTEL, 2007).
Na abordagem proposta no considerado o primeiro nvel, das Necessidades Humanas ou Organizacionais nas atividades de especificao de requisitos, uma vez que no objeto de estudo desta pesquisa. O processo proposto nessa abordagem se inicia pela identificao dos problemas do cliente. Desta forma, esta abordagem acrescenta um novo domnio ao conjunto de domnios de projeto propostos por Suh (SUH, 2001) como ilustra a figura 16. Este novo domnio, denominado Domnio do Problema contm toda a informao que define os problemas, que levam ao surgimento das Necessidades do cliente. Outra novidade na viso de domnios de projeto proposta a representao do Domnio Funcional em duas partes, uma pertence rea de Engenharia de Sistemas e contm os Requisitos Funcionais e No Funcionais, a outra pertence rea de Engenharia de Software e contm os Casos de Uso de software. Esta diviso um conceito importante, uma vez que, neste artigo, considera-se que a atividade de especificao de requisitos uma atividade de Engenharia de Sistemas e que, posteriormente, alguns requisitos sero transferidos para a Engenharia de Software, enquanto outros para outras reas como Eletrnica ou Mecnica. Essa viso permite que a abordagem de especificao de requisitos proposta seja independente de domnio, ou seja, que possa ser utilizada em outras reas que no unicamente o desenvolvimento de software. No processo de desenvolvimento de um projeto, realizado um mapeamento entre os elementos dos domnios de projeto, com o objetivo de estabelecer correspondncias entre estes domnios. Este processo de mapeamente ilustrado na Figura 3. Assim, possvel ligar os problemas s necessidades do cliente, as necessidades aos requisitos e assim por diante at a execuo do projeto no domnio fsico. O objetivo do mapeamento relacionar elementos de um domnio, como por exemplo, RFs (Requisitos Funcionais) com elementos do domnio seguinte, no caso os PPs (Parmetros de Projeto) em uma matriz de projeto e avali-la sob o ponto de vista do Axioma da Independncia. As setas que vo e voltam de um domnio para outro representam o conceito de processo em Zig-Zag. Este processo, apresentado no trabalho de Suh (2001), prope que o mapeamento de RFs para PPs seja seguido pelo detalhamento destes elementos, que por sua vez seguido por um novo mapeamento e assim sucessivamente. Nesta pesquisa realizou-se um estudo com objetivo de entender os benefcios de se aplicar o processo em zig-zag aos Domnios do Problema e do Cliente. Essa proposta se baseia na hiptese de que o Axioma da Independncia seria aplicvel tambm a estes domnios e que poderia melhorar consideravelmente o resultado da especificao de requisitos.

III CONGRESO INTERNACIONAL

DE

COMPUTACIN

TELECOMUNICACIONES

Figura 3 - Domnios de projeto

Nesta abordagem a atividade de anlise do problema e especificao de requisitos realizada em um processo de zig-zag, ou seja, alternando entre o mapeamento entre domnios e o detalhamento dos elementos destes domnios. O processo em zig-zag entre dois domnios se mantm at que os elementos dos domnios envolvidos no possam mais ser mais detalhados. A partir do momento em que no for possvel realizar detalhamentos, passa-se a fazer mapeamento somente entre os outros domnios em que ainda possvel realizar o detalhamento. No final, um domnio ter mais nveis de detalhamento que o outro, porm, at o nvel alcanado, existe sempre o mesmo nmero de elementos em ambos os domnios. A tendncia que o nmero de elementos de um domnio seja sempre maior que o nmero de elementos do domnio anterior. A Figura 4 ilustra o processo em zig-zag realizado desta abordagem, levando em conta as caractersticas aqui descritas.

Figura 4 - Mapeamento entre domnios

3.2. Modelos de Especificao de Requisitos Conforme discutido anteriormente, os resultados obtidos no desenvolvimento de sistemas
6

III CONGRESO INTERNACIONAL

DE

COMPUTACIN

TELECOMUNICACIONES

frequentemente causam desapontamentos aos clientes. Sabe-se que uma das maiores causas desses problemas est na dificuldade dos desenvolvedores em entender os objetivos para os quais o sistema foi construdo. De maneira geral, se um sistema no satisfaz seu usurio porque foi projetado sem um correto entendimento de seu propsito. A soluo para esse tipo de problema costuma ser a realizao de uma anlise cuidadosa do objetivo da construo do sistema, antes que se inicie seu desenvolvimento. O mtodo desenvolvido neste trabalho oferece um meio de se compreender os problemas que o cliente pretende resolver por meio do sistema. Uma vez compreendidos os problemas devem ser identificadas suas necessidades e, como consequncia, especificar os requisitos adequados para o sistema. Na Figura 5 so apresentados os passos seguidos no modelo proposto de engenharia de requisitos. A primeira atividade do modelo Analisar o Negcio do Cliente, esta atividade importante para que se comece a compreender o domnio do problema que ser resolvido. Para entender o negcio possvel estudar documentos e manuais de processos internos ou mesmo assistir a realizao das atividades que fazem parte da rotina da empresa. A atividade seguinte Obter a percepo do cliente sobre seus Problemas e Necessidades, sedo que esta percepo normalmente alcanada por meio de reunies e entrevistas com o cliente. Em geral, as informaes obtidas do cliente so confusas e desorganizadas, por este motivo a prxima atividade Organizar os Problemas e Necessidades, colocando-os em listas distintas. Assim que as Necessidades informadas pelo cliente estejam identificadas realizada uma entrevista com o objetivo de interrog-lo sobre o porqu de haver apresentado cada uma das necessidades, realizando assim a terceira atividade Listar o Porqu de cada Necessidade. A partir das respostas do cliente possvel ento Reformular os Problemas e Necessidades. O passo subsequente Mapear Problemas X Necessidades em uma matriz de projeto e Revisar os Problemas e Necessidades com o Cliente, com o objetivo de obter o aceite do cliente sobre a viso dos problemas e necessidades antes de prosseguir. Caso o cliente concorde, passa-se a Estabelecer os Requisitos do Sistema tendo em vista as necessidades identificadas. O prximo passo Mapear as Necessidades X Requisitos em uma matriz e, em seguida, Avaliar a matriz Segundo os Princpios de Anlise, que significa basicamente avaliar a matriz sob o aspecto do Axioma da Independncia. Caso a matriz atenda os requisitos deste axioma e no seja interessante detalhar necessidades e requisitos, passa-se ao Mapeamento dos Requisitos para Casos de Uso e, em seguida, Avaliar a matriz Segundo os Princpios de Anlise. Caso a matriz atenda os requisitos deste axioma e no seja interessante detalhar requisitos e casos de uso, encerrase o processo de especificao de requisitos proposto nesta abordagem. Assim, com a especificao de requisitos encerrada, adentra-se o domnio da Engenharia de Software, na qual so aplicados os conceitos e processos definidos na abordagem de Pimentel (PIMENTEL, 2007). Por esta razo as etapas seguintes, que envolvem o mapeamento de casos de uso para colaboraes e modelagem do sistema, no sero descritas neste trabalho.

III CONGRESO INTERNACIONAL

DE

COMPUTACIN

TELECOMUNICACIONES

Figura 5 - Modelo de Especificao de Requisitos

4. Experimentos e Resultados
Os experimentos realizados neste trabalho consistiram em identificar um problema com ajuda de um voluntrio, que exercia o papel de cliente. Na primeira etapa do experimento era solicitado ao cliente que definisse, de maneira geral, um problema que precisava ser solucionado. O problema sempre era completamente definido pelo cliente de acordo com algum problema do seu dia-a-dia, sem interferncia do pesquisador. Em seguida, era solicitado a ele que definisse o que ele necessitava em um sistema para resolver seus problemas. A seguir, eram especificados os requisitos do projeto sem que houvesse nenhum tipo de preocupao em criar um ou mais requisitos para cada necessidade. At este ponto o principal objetivo era identificar os requisitos do sistema de uma maneira muito semelhante que ocorre comumente nos projetos de software. A segunda etapa do experimento consistia em refazer a especificao dos requisitos, mas desta vez o objetivo era voltar ao ponto em que o cliente definiu as necessidades e passar a aplicar o modelo proposto. Assim, a primeira atividade era questionar o cliente sobre o porqu de ele haver identificado cada uma das necessidades. Com estas respostas obtidas, os problemas e necessidades eram reformulados e seguia-se com a aplicao do modelo at que fosse obtido um conjunto de requisitos que estivesse relacionado com as necessidades atendendo ao Axioma da Independncia. O objetivo final do experimento era comparar os resultados obtidos na primeira e na segunda etapa e avaliar os efeitos positivos ou negativos
8

III CONGRESO INTERNACIONAL

DE

COMPUTACIN

TELECOMUNICACIONES

do uso do modelo proposto. A seguir apresentado o estudo de caso de um dos experimentos realizados. 4.1. Descrio do problema Este estudo de caso diz respeito a uma distribuidora de livros, em que o cliente necessita um sistema de relatrios de visitas a clientes. Apesar de a atividade haver sido realizada somente a ttulo de experimento o problema descrito pelo cliente real assim como a empresa distribuidora de livros. A descrio do problema apresentada pelo cliente a seguinte: Em minha empresa os Gestores conhecem sua carta de clientes, mas esta informao fica somente com eles. Quando um gestor faz uma visita a um cliente no repassa para ningum os detalhes da visita, registra no sistema da empresa somente a data e pessoa com quem conversou. Os acordos realizados com o cliente, sobre condies da compra nem sempre so repassados para a empresa. Sempre que um novo gestor entra na empresa e assume a carteira de cliente de outro, precisa iniciar o relacionamento com o cliente a partir do zero. 4.2. Primeira Etapa Na primeira etapa foram obtidas as necessidades definidas pelo cliente, que so as seguintes: Necessita-se um cadastro com os dados completos do cliente; Necessita-se que o sistema esteja online; Necessita-se um controle de acesso de usurios; Necessita-se que o sistema permita a criao de usurios com perfil de Gestor, que s ter acesso aos dados dos seus clientes; Necessita-se de um usurio Administrador que tenha acesso aos dados de todos os clientes; Necessita-se um relatrio completo de cada visita; Necessita-se manter um histrico de todas as visitas feitas ao cliente; Necessita-se ter um guia dos assuntos que o gestor dever abordar na visita. Necessita-se que o sistema envie um e-mail avisando sempre que um relatrio for cadastrado. Para atender as necessidades descritas pelo cliente foram elaborados pelo analista os seguintes requisitos: O sistema dever ter uma funcionalidade de cadastro do cliente; O sistema dever ser desenvolvido para web; O sistema dever ter uma funcionalidade de controle de acesso de usurios; O sistema dever possuir um perfil de Gestor com acesso exclusivo aos dados dos clientes relacionados a ele; O sistema dever possuir um perfil de usurio de Administrador com acesso aos dados de todos os clientes; O sistema dever criar um relatrio de visitas com todos os detalhes importantes para a empresa; O sistema dever permitir consultar o histrico de todos os relatrios de visitas; O sistema dever ter um guia dos assuntos que o gestor dever abordar na visita. O sistema dever avisar o administrador por email sobre o cadastro de um novo relatrio. 4.3. Segunda etapa Nesta etapa do experimento retornou-se lista de necessidades com o objetivo de entender
9

III CONGRESO INTERNACIONAL

DE

COMPUTACIN

TELECOMUNICACIONES

por que o cliente elaborou cada uma das necessidades que foram apontadas durante a conversa. A forma utilizada para entender cada necessidade simplesmente perguntando Por que isso necessrio?. Assim foi possvel identificar problemas no identificados inicialmente, por meio da explicao do cliente de por que o sistema deveria atender cada uma das necessidades apresentadas. Isso deve ser feito por que, com frequncia, o cliente no deixa explcitos muitos dos problemas que deseja solucionar. Na Tabela 2 encontram-se algumas das respostas obtidas do cliente, no caso estudado.
Lista de Necessidades e Motivaes Descrio da Necessidade e sua explicao Necessita-se um cadastro com os dados completos do cliente. - Por que a empresa no conhece muitos de seus potenciais clientes. - Por que constantemente os gestores esquecem dados fundamentais do cliente. Necessita-se que o sistema permita a criao de usurios com perfil de Gestor, que s ter acesso aos dados dos seus clientes. - Porque desejo evitar eventuais casos de sabotagem entre gestores. - Porque desejo evitar que um gestor jogue a culpa em outros por seus erros. Necessita-se um relatrio completo de cada visita. - Porque frequentemente no recebo todas as informaes sobre a visita, descontos acordados, formas de pagamento e outros dados importantes. O sistema dever avisar o administrador por e-mail sobre o cadastro de um novo relatrio. Para que o administrador saiba imediatamente que foi cadastrado um novo relatrio. (Como o sistema estar on-line este item foi eliminado.) Tabela 2 Motivao das necessidades

ID N1 N4

N6 N9

O passo seguinte do experimento foi redefinir a lista de problemas do cliente com base nas respostas obtidas no passo anterior. Cada resposta, em geral, costuma apontar para um problema que deve ser solucionado pelo sistema. Desta forma, possvel redefinir a lista de problemas e, eventualmente, tambm a lista de necessidades. Em seguida, o ideal revisar a nova lista de problemas em conjunto com o cliente para ter certeza que cada um dos problemas identificados pelos analistas de negcios relevante. Eventualmente, pode-se, inclusive, buscar identificar a raiz dos problemas, caso perceba-se que no esto claros o bastante. A Tabela 3 apresentada a seguir apresenta uma mostra de como ficou a lista de problemas do sistema de Relatrio de Visitas a Clientes.
Lista de Problemas reformulada Descrio do Problema Empresa conhece mal seus clientes. Gerentes se esquecem de solicitar dados importantes do cliente. Demora em receber relatrios por que gestores trabalham em locais distantes e visitam a empresa com pouca freqncia. Risco de que as pessoas no assumam a responsabilidade pelos dados que cadastram no sistema. Informaes incompletas a respeito das visitas realizadas aos clientes Tabela 3 Problemas reformulados

ID P1.1 P1.2 P2 P4.1 P6.1

O conjunto de necessidades tambm foi redefinido, como ilustra a Tabela 4.

Lista de Necessidades reformulada Descrio da Necessidade Necessito um cadastro com os dados completos do cliente O sistema precisa utilizar a web para transmitir os dados para o servidor da empresa O sistema precisa ter um controle de acesso de usurios 10

ID N1 N2 N3

III CONGRESO INTERNACIONAL

N4.1 N4.2 N5 N6.1 N6.2 N7

DE

COMPUTACIN

TELECOMUNICACIONES

O sistema precisa permitir o cadastro dos usurios que tm direito de acesso ao sistema O sistema precisa ter um perfil de Gestor, que s ter acesso aos dados dos clientes individuais do gestor O sistema precisa ter um perfil de Administrador que tenha acesso aos dados de todos os clientes Necessito um relatrio completo de cada visita O sistema ter uma opo de gerar pedidos do cliente Necessito manter um histrico de todas as visitas feitas ao cliente Tabela 4 Necessidades reformulados

Quando uma matriz de Problemas e Necessidades aceitvel obtida, pode-se seguir adiante, e passar a elaborar os requisitos que atendero s necessidades encontradas. Caso contrrio ser necessrio voltar atrs na formulao das necessidades para obter uma matriz aceitvel. No caso estudado no foi necessrio reformular as necessidades por haver sido formada uma matriz semi-acoplada que no apresentada no artigo. Assim, passou-se para a elaborao dos requisitos do sistema. A Tabela 5 apresenta uma lista de requisitos elaborados com o objetivo de atender as necessidades do cliente do Sistema de Relatrio de Visitas.
ID R1 R2 R3 R4.1 R4.2 R5 R6.1 R6.2 R7 Lista de Requisitos Descrio do Requisito O sistema dever ter um cadastro com os dados completos do cliente O sistema dever utilizar a web para transmitir os dados para um Web Server da empresa O sistema dever ter um controle de acesso de usurios O sistema dever ter um cadastro dos usurios do sistema Lista de Requisitos (continuao) O sistema dever ter um perfil de Gestor, que s ter acesso aos dados dos clientes individuais do gestor O sistema dever ter um perfil de Administrador que tenha acesso aos dados de todos os clientes O sistema dever ter uma funcionalidade de gerao de relatrio de visita O sistema dever ter funcionalidade de envio de pedidos do cliente O sistema dever manter um histrico de todas as visitas cadastradas no sistema

Tabela 5 Novo conjuntos de requisitos Por fim, a ltima atividade realizada neste experimento foi o mapeamento dos relacionamentos entre as Necessidades e os Requisitos identificados. O objetivo de elaborar esta matriz avaliar se ela atende ao axioma da independncia definido. Em outras palavras, o que se espera em uma matriz como esta, do ponto de vista dos relacionamentos, obter sempre uma matriz desacoplada ou semi-acoplada. Uma matriz que apresente acoplamento entre Necessidades e Requisitos aponta para problemas de interpretao destas Necessidades e Requisitos e seus relacionamentos. Da mesma forma que na matriz de relacionamento entre problemas e necessidades, espera-se que a matriz seja sempre quadrada, ou seja, que exista o mesmo nmero de Necessidades e Requisitos. Uma matriz no quadrada indicaria a possibilidade de estarem faltando ou sobrando Requisitos. Como possvel ver na Tabela 6 a matriz resultante no caso de estudo apresentado uma matriz quadrada e desacoplada.
R1 R2 R3 R4.1 R4.2 R5 R6.1 R6.2 R7 R8

N1 N2 N3 N4.1

X X X X 11

III CONGRESO INTERNACIONAL

N4.2 N5 N6.1 N6.2 N7 N8

DE

COMPUTACIN

TELECOMUNICACIONES

X X X X X X Tabela 6 Necessidades X Requisitos

5. Discusso dos experimentos

Esta seo apresenta um estudo dos relacionamentos que podem existir dentro de uma matriz de projeto e uma discusso a respeito do significado de cada um destes tipos de relacionamento e da forma como tratar com elas. Estes relacionamentos foram identificados e estudados conforme os resultados dos experimentos eram obtidos. Na Tabela 7 cada clula da matriz marcada com X indica que o Requisito daquela coluna atende a Necessidade correspondente linha. importante lembrar que para exemplificao foram utilizados os domnios de Cliente e Funcional, mas as mesmas regras so vlidas para o relacionamento entre todos os domnios. Outra observao fundamental que, para efeito desta discusso, necessrio que nos relacionamentos analisados sempre existam elementos diagonais (LEE & JEZIOREK, 2006), ou seja, elementos localizados na diagonal da matriz.

R1

R2

R3

R4

R5

R6

R7

R8 X X

N1 N2 N3 N4 N5 N6 N7 N8 N9

X X X

X X X X X X X

Tabela 7 Tipos de relacionamentos em uma matriz de projeto

Caso 1: Relacionamento cclico ou acoplado Quando os relacionamentos formam um ciclo, isso indica acoplamento entre Requisitos e Necessidades, como ilustram as necessidades N1 e N3 na Tabela 7. Esse relacionamento pode indicar que h um erro de interpretao das necessidades, que poderiam ser representados por uma nica necessidade; ou que h um erro de definio dos requisitos que devem atender estas necessidades. No caso da Tabela 7 esto envolvidos apenas dois elementos diagonais (N1 e N3), mas pode-se ter vrios itens formando um ciclo (LEE & JEZIOREK, 2006), como no exemplo da Tabela 8. Sempre que um relacionamento deste tipo for encontrado deve ser eliminado, para que o projeto esteja de acordo com o Axioma da Independncia.

R9

12

III CONGRESO INTERNACIONAL

DE

COMPUTACIN

TELECOMUNICACIONES

R1

R2

R3

R4 X

N1 N2 N3 N4 N5

X X X X X X X

Tabela 8 Relacionamento acoplado 2

Caso 2: Relacionamento triangular ou semi-acoplado A Tabela 7 ilustra, com as necessidades N4 e N5, o caso em que os relacionamentos das clulas formam um tringulo, o que indica um semi-acoplamento que aceitvel, j que seus elementos no formam nenhum ciclo. Caso 3: Relacionamento mltiplo em linha Este relacionamento ocorre quando os relacionamentos das clulas formam uma linha com dois ou mais elementos marcados, sem que existam mais ligaes em nenhuma das colunas envolvidas, conforme ilustra a necessidade N6 da Tabela 7. Isso pode indicar que a necessidade poderia ser dividida em subnecessidades ou que os requisitos deveriam ser reinterpretados para formarem apenas um requisito. Sempre que um relacionamento deste tipo for encontrado deve ser eliminado, por estar ligado ao Teorema 3 que diz que quando o nmero de RFs menor que o nmero de DPs ou o design acoplado ou redundante (SUH, 1990). Caso 4: Relacionamento mltiplo em coluna Este caso, representado na Tabela 7 pelo requisito R8, ocorre quando os relacionamentos das clulas formam uma coluna com dois ou mais elementos marcados com X, desde que no existam mais ligaes em nenhuma das linhas envolvidas. Isso pode indicar que o requisito poderia ser dividido em sub-requisitos ou que as necessidades deveriam ser reinterpretadas para formarem apenas uma. Este tipo de situao deve ser evitado e costuma estar relacionada ao Teorema 1, que diz que quando o nmero de DPs menor que o nmero de RFs ou resulta em um design acoplado ou um requisito no pode ser satisfeito (SUH, 1990). Caso 5: Ausncia de relacionamentos em uma coluna A ausncia de relaes em uma coluna, ilustrado pelo requisito R9 da Tabela 7, pode significar que o requisito no existe ou que a necessidade correspondente no foi identificada. Este tipo de situao costuma estar relacionada ao Teorema 3 e deve ser eliminado. Caso 6: Ausncia de relacionamentos em uma linha A necessidade N9 da Tabela 7 representa o caso em que ocorre a ausncia de relaes em uma linha. Isso pode significar que a necessidade no existe e que o requisito para atender a necessidade no foi definido. Este tipo de situao costuma estar relacionada ao Teorema 1 e deve ser, preferencialmente, eliminado.

R5 X X

13

III CONGRESO INTERNACIONAL 6. Concluses

DE

COMPUTACIN

TELECOMUNICACIONES

Este trabalho apresenta uma abordagem de especificao de requisitos de sistemas de software baseada na Teoria de Projeto Axiomtico, que pode ser aplicada em conjunto com um processo de desenvolvimento de software como o Processo Unificado, abordagem proposta prov um modelo para auxiliar os analistas de negcios e requisitos na definio dos requisitos adequados para o projeto. O entendimento do negcio do cliente, bem como de seus problemas, e a identificao dos requisitos corretos contribuem para a realizao de um bom projeto. Foi possvel concluir, durante esta pesquisa, que o detalhamento dos problemas e/ou desejos que levam o cliente a tomar a deciso de adquirir um produto permite que os Engenheiros de Sistemas tenham uma viso ampliada do contexto em que a soluo dever se inserir e, desta maneira, possam propor solues alternativas. possvel que estas solues sejam at mais eficientes do que aquelas imaginadas pelo cliente atravs das caractersticas e necessidades apontadas por ele. Ou seja, buscar conhecer os problemas do cliente, sem se prender as necessidades ou caractersticas citadas por ele, ajuda a equipe de engenharia de requisitos a encontrar solues inovadoras ou melhor fundamentadas para o problema. Outra concluso importante deste trabalho que a estrutura formada pela decomposio entre os diversos domnios pode ser triangular. Isso quer dizer que o nmero de necessidades pode ser maior que o nmero de problemas assim como o nmero de requisitos pode ser maior que o nmero de necessidades. O importante , que at determinado nvel de decomposio, exista uma correspondncia no nmero de itens de cada domnio. A partir do momento em que o nmero de itens de um domnio no puder mais ser detalhado deixa-se de utilizar a matriz entre estes domnios e passa-se a fazer o mapeamento apenas dos outros domnios que ainda podem ser detalhados. A respeito do mapeamento de elementos de dois domnios em uma matriz, com objetivo de avali-la do ponto de vista do Axioma da Independncia, concluiu-se que essa atividade pode auxiliar na identificao de inconsistncias na interpretao dos elementos de cada domnio. Eventualmente, essa anlise pode ajudar a identificar elementos que esto faltando ou sobrando e assim levar a melhorias na matriz e, consequentemente, no projeto. A utilizao da matriz de projeto para o mapeamento entre os diversos domnios ajuda a manter a consistncia e a rastreabilidade de problemas, necessidades, requisitos e elementos de arquitetura do sistema. Embora este trabalho tenha trazido algumas concluses importantes, o tema de Especificao de Requisitos bastante complexo e trabalhos futuros certamente podero trazer novos avanos que iro agregar ainda mais conhecimento a respeito deste assunto.

Referncias
BALMELLI, L. (2007). An Overview of the Systems Modeling Language for Products and Systems Development. Journal of Object Technology , 6, pp. 149-177. BOOCH, G., RUMBAUGH, J., & JACOBSON, I. (2006). UML Guia do Usurio (2 ed.). CARVER, C. S., & SCHEIER, M. F. (2007). Perspectives on Personality. Boston: Allyn and Bacon. DIJKSTRA, E. W. (Oct de 1972). The humble programmer. ACM , 859866. DOMINGUEZ, J. (2009). Acesso em 14 de Junho de 2010, disponvel em ProjectSmart: http://www.projectsmart.co.uk/pdf/the-curious-case-of-the-chaos-report-2009.pdf DORFMAN, M., & THAYER, R. H. (1990). Standards, Guidelines, and Examples on System and Software Requirements Engineering. IEEE Computer Society Press. JACKSON, M. (1995). Problems & Requirements. Proceedings of the IEEE Second International Symposium on Requirements Engineering (pp. 2-8). ACM Press.

14

III CONGRESO INTERNACIONAL

DE

COMPUTACIN

TELECOMUNICACIONES

KIM, S. J., SUH, N. P., & KIM, S. K. (1992). Design of software systems based on axiomatic design. Anais do CIRP General Assembly . LEE, T., & JEZIOREK, P. N. (2006). Understanding the Value of Eliminating An Off-Diagonal Term in a Design Matrix. Proceedings of ICAD 2006. Firenze. LEFFINGWELL, D., & WIDRIG, D. (2003). Managing Software Requirements. Boston: Addison Wesley. LI, Z. (2007). Progressing Problems from Requirements to Specifications in Problem Frames. London, United Kingdom: Department of Computing - The Open University. PIMENTEL, A. R. (2007). Uma abordagem para projeto de software orientado a objetos baseado na teoria de projeto axiomtico. Curitiba-PR: UTFPR. SUH, N. P. (2001). Axiomatic Design: advances and applications. New York, EUA: Oxford University Press. SUH, N. P. (1990). The Principles of Desgin. New York: Oxford University Press. SUH, N. P., & DO, S. H. (2000). Axiomatic design of software systems. CIRP annals. Sidney, Australia.

15