Artigo de Engenharia de Requisitos

Carlos F. H. Santos, Julian L. Fagundes, Fernando Wartchow

Departamento de Informtica Universidade de Santa Cruz do Sul (Unisc) 91.501-970 Santa Cruz do Sul RS Brazil

{julian.lfs,karllitos.kk}@gmail.com, fernando_wartchow@yahoo.com.br

Abstract. Requisite Engineer is considered nowadays as the most important part of a system development, the reason is that all tasks and procedures must be written in a document and it will be used as a reference for everyone involved in the development process. Resumo. A Engenharia de Requisitos pode ser tratada hoje como a parte mais importante no desenvolvimento de um sistema, pelo fato que sero definidos todas as funcionalidades e servios que o sistema ter quando estiver concludo. Este documento servir de referencia para todas as pessoas que estaro envolvidas no processo de desenvolvimento do software.

1. Elicitao de Requisitos
A elicitao de requisitos uma fase muito importante em qualquer projeto de desenvolvimento de software, pois se elaborada de maneira incorreta, todo o projeto estar comprometido. importante, pois nesse momento que identificamos e definimos a estratgia de desenvolvimento do produto/servio. agora que conhecemos algumas informaes como: Fonte de Requisitos; Quais so as partes interessadas no produto/servio; Quais so as principais necessidades do usurio; Definimos as fronteiras do sistema; Quais so as premissas e restries do sistema ou do ambiente.

 normal, que durante a identificao das fontes de requisitos, tenhamos que realizar reunies com profissionais de todos os nveis hierrquicos e conhecer as necessidades de cada um. Muitas empresas, quando terceirizam o servio, elegem uma pessoa (stakeholder) para ser o ponto focal entre o contratante e contratada. Isso pode ser muito perigoso, pois caso esse profissional no conhea as reais necessidades dos usurios finais, ou passe alguma informao errada, todo o projeto estar comprometido. Sei que muitos podem estar pensando que isso no problema da empresa contratada, pois a responsabilidade do stakeholder ou contratante, porm, como sempre frisamos, devemos nos preocupar em entregar valor para o nosso cliente, e s atingiremos esse objetivo trabalhando como parceiros. Por essa razo, sempre que possvel, prefira conhecer e conversar pessoalmente com todos os envolvidos no projeto, conhecer suas reais necessidades, e se necessrio, fazer a observao "in loco", que nada mais que sentar ao lado do operador do sistema por um determinado tempo e conhecer seu trabalho. Para conhecermos quem so as pessoas interessadas no produto/servio, devemos fazer perguntas como: No caso de sucesso ou falha do projeto, quais as pessoas afetadas? Quem so os usurios finais do produto? Quem so os responsveis pela aprovao/reprovao da soluo, quando implantada? Quem ser o responsvel pelo desenvolvimento e manuteno do produto? Quem so os responsveis pelos testes? Definir as fronteiras do sistema ajuda na definio de escopo do sistema. Temos uma viso mais clara do que est dentro e principalmente fora do escopo. Conhecer as reais necessidades do usurio no significa que atenderemos todos os desejos dele. Temos que nos focar na soluo do problema. Como citei anteriormente, nem sempre o usurio sabe de sua real necessidade. Essa etapa critica. Ter desvios de foco a coisa mais comum nesse momento. Identificar premissas e restries de ambiente de extrema importncia, pois dependendo destas, o valor e o tamanho do projeto podem ser significantemente maiores ou menores.

1.1 Tcnicas de Elicitao: entrevistas A comunicao de extrema importncia para uma boa elicitao. Uma das tcnicas mais usadas na elicitao so as entrevistas com os usurios ou stakeholders. Normalmente a entrevista a primeira tcnica utilizada para descobrir as necessidades dos usurios. Agora o momento de escutar mais do que falar. Para os analistas iniciantes, o incio das entrevistas ode ser um pouco confuso, pois muitas informaes so despejadas de uma s vez, sem organizao. O usurio est falando de determinado assunto, de repente lembra-se de outra funcionalidade, para ento retornar ao assunto inicial. realmente um momento em que devemos estar muito atentos. Eu, particularmente, aprendi a usar gravadores, mas no sempre que essa tcnica bem vista pelas pessoas do outro lado. Para tornarmos as entrevistas mais produtivas, recomendado estruturar da seguinte maneira: Informando os temas que sero abordados: assim, tanto o entrevistado quanto voc conseguiro se preparar com perguntas e respostas mais completas. Informando sua durao: dizer a hora de incio e do fim da entrevista uma maneira de ambos organizarem seus compromissos para antes e depois. Nunca deixe uma entrevista durar mais do que 2 horas. A partir desse tempo, ambos estaro cansados e comearo a se dispersar, fugindo completamente do objetivo. Fazer uma breve apresentao sobre si e o que espera conseguir com ela: no "ao vivo", na hora da entrevista, apresentar-se fundamental, assim como explicar o motivo do encontro, mesmo que isso j tenha sido feito anteriormente, provavelmente por email ou telefone; Explicar como ser a conduo da entrevista: dessa forma, o entrevistado se sentir menos intimidado ou preocupado com suas atitudes. Um bom exemplo o caso do gravador - preciso explicar o motivo de se gravar a entrevista e pedir autorizao para o entrevistado para gravar a conversa. Ao terminar a entrevista, interessante que voc recapitule as informaes obtidas, mesmo que de maneira resumida. Se necessrio, j deixe uma nova entrevista agendada. Informe tambm o entrevistado, que voc poder entrar em contato para tirar eventuais dvidas.

1.2 Questionrios Utilizaremos os questionrios quando usurios, stakeholders e outros envolvidos no tm disponibilidade para a realizao da entrevista. Porm, os questionrios jamais substituiro as entrevistas diretas. Tambm utilizamos os questionrios quando usurios esto distribudos geograficamente. importante que voc trabalhe bem as perguntas antes de envi-las. Faa sempre perguntas cuja resposta possa ser aberta e eficaz. Jamais faa perguntas que sejam respondidas simplesmente com "SIM" ou "NO". Um questionrio bem feito deve ter suas questes claras e no ambguas (como uma especificao); Ter seu fluxo bem definido; Novamente, cito trabalhar bem as perguntas a serem feitas e tentar detalha-las ao mximo. Exemplo de uma pergunta aberta para o gerente de uma locadora de veculos: Durante o aluguel de um veculo, ocorre um problema mecnico com o mesmo. O locatrio aciona a RENTCARSUV. Qual o procedimento completo que o atendente do chamado dever registrar no sistema? A resposta para essa pergunta ser completa e com ela muitas outras dvidas podem se esclarecidas e novas podem surgir, lapidando melhor a necessidade do usurio. 1.3 Observao "In Loco" A observao in loco nada mais do que quando o analista responsvel pela elicitao inserido no dia-a-dia da organizao. Normalmente isso feito nos setores que utilizaro o servio/produto. O analista deve compreender e descrever as atividades que so realizadas. Essa tcnica excelente para oferecermos mais valor do que o prprio cliente espera. Oferecer algo que possa facilitar determinadas tarefas e reduzir custos envolvidos. J vi situaes em que o processo de atendimento da empresa foi mudado, pois os atendentes realizavam o trabalho de maneira mais gil, utilizando outros meios permitidos no processo anterior, pulando determinada etapa, que foi revisada e definida,

j que sua utilizao gerava apenas mais tempo no atendimento aos clientes. A isso eu chamo de agregar valor ao negcio. 1.4 Brainstorming Brainstorming so as reunies na qual participam todos os envolvidos na idealizao do produto, como os analistas, clientes e usurios finais. O formato dessa reunio um pouco diferente das demais, pois todos os envolvidos devem expor suas ideias e necessidades em relao ao produto/servio, da maneira que vier em sua cabea, sem a necessidade de formar a ideia toda. Aps todos terem exposto suas ideias de maneira bagunada, hora de organizlas e verificar o que realmente importante para o momento, ou o que ficar para futuras reunies. H muitas situaes em que muitas ideias iguais so vistas de maneiras diferentes, fornecendo mais informaes para o analista e, consequentemente, oferecendo uma documentao mais completa.

Etapa de Anlise dos Requisitos

Nesta etapa onde se busca compreender os requisitos do cliente atravs de um estudo de viabilidade para o sistema de software. Esta atividade envolve o trabalho da equipe tcnica em conjunto com os usurios do sistema a fim de estabelecer o domnio da aplicao do sistema, como os servios que dever prover e tambm suas restries operacionais. Estaro envolvidos os usurios finais, gerentes, engenheiros, responsveis pela manuteno do sistema, especialistas, etc., podendo surgir alguns conflitos, sendo necessria uma negociao e aceitao por parte de todos os envolvidos. Para uma boa prtica de anlise importante elaborar diagramas UML, prottipos, anlise de viabilidade, priorizao dos requisitos e a criao de um dicionrio de dados. Diversos modelos podem ser produzidos durante a atividade de anlise de requisitos.

Figura 2.1. Processo de Anlise de Requisitos

Existem algumas formas diferentes de entendimento pelos diversos tipos de usurios participantes do sistema. Cada um possui um ponto de vista diferente do problema. A anlise sob vrias perspectivas importante pois no existe uma forma correta de se analisar os requisitos do sistema e s podemos contemplar o sistema completamente se procurarmos vrias alternativas. Para cada ponto de vista o sistema composto por um conjunto de servios oferecidos, sendo que cada ponto de vista representa uma forma natural para a descoberta dos requisitos. Com os modelos de diagramas, prottipos e afins fica mais fcil de visualizar as operaes e mtodos que devem ser trabalhados no projeto. Alm da anlise de erros e omisses o processo de definio de requisitos possibilita a anlise por diferentes perspectivas tais como, viabilidade, custo, tempo, prioridades, reuso, completude, corretude, variabilidade, evoluo, dentre outras. Descreverei abaixo sobre a Prototipao e Casos de Uso. 2.2 Prototipao A prototipao surgiu como uma soluo para o problema da anlise de requisitos, permitindo que o usurio simulasse a aplicao que ainda no foi produzida, ajudando-o a terem uma ideia de como o sistema ir parecer no futuro, facilitando a tomada de decises no projeto e reduo do custo total, j que poderemos aproveitar o prottipo.

Portanto a prototipao tem alguns problemas como: tempo de entrega do projeto final baseando-se no tempo do prottipo, foco dos projetistas e usurios na interface do sistema ao invs do foco nas regras do negcio, entre outras. 2.3 Casos de Uso Um 'Caso de Uso' uma tcnica para capturar os requisitos em potencial de um novo sistema ou manuteno de software. Cada caso de uso promove um ou mais cenrios de indicam como o sistema deve interagir com o usurio final ou outro sistema para atingir um objetivo de negcio especfico. Casos de uso tipicamente evitam o jargo tcnico, preferindo ao invs disto a linguagem do usurio final ou de um expert no domnio. Os casos de uso so frequentemente de coautoria dos desenvolvedores de software e usurios. Casos de usos so ferramentas enganosamente simples para descrever o comportamento de um software. Um caso de uso deve conter uma descrio textual de todos os passos que o usurio futuramente poder vir a utilizar no software atravs de sua interface. Casos de uso no descrevem nenhum comportamento interno do software, nem fazem explanaes de como o software ser implementado. Eles simplesmente mostram os passos que o usurio deve seguir para usar o software no seu trabalho. Todas as formas com que o usurio ir interagir com o software devero ser descritas nos casos de uso.

3. Etapa de Validao de Requisitos

Esta etapa de uma extrema importncia, que visa trazer uma garantia de qualidade para o processo de desenvolvimento do software em questo, atravs de um documento de requisitos claro e livre de ambiguaes. Validar os requisitos ajudar a livrar de possveis problemas nas etapas seguintes no desenvolvimento do software, bem como seu custo menor, cerca de 90% a menos do que esse mesmo erro ser achado nas prximas etapas. Nos processos de desenvolvimento, existe uma tendncia natural de se acelerar esse processo de validao, para que se possa logo comear com o desenvolvimento do sistema. Porm, no possibilitar um tempo suficiente para que se possa fazer este trabalho, tornar o processo de desenvolvimento pouco confivel, e quando problemas surgirem ter mais trabalho para se fazer a correo destes erros.

Figura 3.1. Etapas de Validao

Temos com entrada o documento de requisitos, o qual dever ser uma verso completa e formatada de acordo com os padres da empresa; O conhecimento organizacional que consiste em um conhecimento implcito da organizao que servir para avaliar o realismo dos requisitos, e os Padres Organizacionais, que so os padres utilizados pela empresa. Aps as validaes, ter-se- como sada uma possvel lista de problemas que foram encontrados na verificao dos requisitos, e as aes concordadas, que consiste em uma lista de aes que devem ser feitas em reposta a lista de problemas mencionados anteriormente, sendo que alguns destes podem ter vrias aes para fazer sua correo, bem como alguns no ter nenhuma ao para ser associada. Com esse raciocnio, podemos empregar algumas tcnicas para se conseguir essas validaes, que pode ser feita atravs de prottipos, revises dos requisitos, gerao de casos de teste, anlise automatizada da consistncia e validao atravs de ponto de vistas. Uma das abordagens mais usadas para se fazer a validao dos requisitos a conhecida como reviso, sendo feito isso atravs de um cheklist, no qual so listados todos os objetivos que devem existir nos requisitos presentes no documento, sendo que se eles satisfaam esses objetivos estaro validados. Assim, o requisito pode ser validado com base na sua completeza, consistncia, relevncia, clareza, entre outras validaes. A tcnica de prototipagem pode ser considerada uma das melhores formas de reviso dos requisitos, j que a partir dele, o usurio ter uma viso breve de como ser o sistema que esta sendo desenvolvido, j que ele constitudo com base nos requisitos elicitados. Os melhores testadores que podem ser envolvidos so os usurios que tem um grande conhecimento e que tenham as idias abertas sobre o uso do novo sistema. Importante tambm que se envolvam usurios com base de funes diferentes, para que se possam testar diferentes reas dos prottipos. Durante esse processo seria interessante definir um formulrio para que os usurios possam preencher ao encontrar possveis problemas nos prottipos.

Outra forma que pode ser mencionada o teste de requisitos, que consiste em testar todos os requisitos funcionais do sistema. Deve ser possvel a criao de mais de um caso de teste para cada requisito do sistema, onde para cada um dever ser possvel definir um teste para fazer a checagem do mesmo. Se no for possvel fazer testes com base em um determinado requisito, isto pode indicar que o mesmo pode estar incompleto ou ainda no estar claro, o que indica que ele deve ser refeito. Esta tcnica tem como o objetivo eliminar informaes ambguas e incompletas que podem dificultar o desenvolvimento do sistema. Contudo, para que possamos chegar nessas etapas, alguns passos importantes devem ser tomados, como planejar a reviso. Forma-se um time de pessoas que sero as responsveis por essa validao, atravs da leitura e anlise destes documentos. Neste time de revisores tem-se como presena importante dos stakeholders, com diferentes nveis de conhecimento sobre o projeto que est sendo construdo, assim tendo diferentes vises sobre os requisitos que esto sendo revisados. Mas deve-se tomar cuidado e avaliar se o time ter um conhecimento bem claro dos requisitos levantados, bem como a completude dos mesmos. Outro fator importante que deve ser levado em considerao na hora de fazer a reviso o custo que essa etapa ter, visto que envolvera certo numero de pessoas que avaliaro o documento. Com isso pode ser recomendado uma pr-reviso, que consiste em uma pessoa fazer uma checagem no mesmo de uma forma que possa eliminar possveis erros mais simples, como falta de aderncia a um padro ou falta de um requisito.

References
http://wer.inf.pu-crio.br/WERpapers/artigos/artigos_WER03/priscilla_pagliuso.pdf http://prope.unesp.br/xxi_cic/27_37013940836.pdf PRESSMAN, Roger S. Engenharia de Software. 6. Ed. So Paulo: McGraw-Hill, 2006. http://www.cin.ufpe.br/~if119/aulas/cap4.PDF http://www.inf.puc-rio.br/~wer/WERpapers/artigos/artigos_WER09/couto.pdf http://www.slideshare.net/tiago.barros/engenharia-de-requisitos-aula-2#