UNIVERSIDADE FEDERAL DE PERNAMBUCO

PS-GRADUAO EM CINCIA DA COMPUTAO CENTRO DE INFORMTICA

2008.1

Engenharia de Requisitos gil

_______________________________________________

MONOGRAFIA EM ENGENHARIA DE REQUISITOS

Autor Eudes Raphael de S Santana Orientador Jaelson Castro Recife, julho 2008

Resumo
Segundo pesquisa do Standish Groups, 2000, 74% dos projetos foram considerados falhos, e a principal causa apontada foi falha nos requisitos. Ainda segundo o CHAOS REPORT do Standish Group, 1995, cerca 50% dos projetos que falham, deve-se a problemas nos requisitos. Na mesma proporo, os projetos que obtiveram sucesso tiveram seus feitos atribudos ao esforo destinado s atividades de engenharia de requisitos. Alm destes dados, outras pesquisas e estudos de caso atestam a importncia da engenharia de requisitos para o sucesso dos projetos de desenvolvimento de software. Existem vrios modelos de processo de engenharia de requisitos, sendo o definido pelo RUP (Rational Unified Process) o mais comumente utilizado no mercado. As alternativa metodologias ao overhead geis de desenvolvimento pelos processos e surgiram artefatos como das

inserido

metodologias tradicionais de desenvolvimento, onde o principal ponto de divergncia est no tratamento ao controle de mudanas. O processo de engenharia de requisitos, responsvel por otimizar a comunicao das necessidades dos clientes para equipe de desenvolvimento, diretamente afetado sob o aspecto do controle de mudanas, e assume particularidades do processo desenvolvimento em que est inserido. Esta monografia tem por apresentar aspectos da engenharia de requisitos sob a perspectiva dos processos de desenvolvimento gil de desenvolvimento do software, apontando vantagens, limitaes e sugestes de melhoria.

ndice

1. Introduo...................................................................................5 2. Engenharia de Requisitos, Previso e Reao..............................7 3. Engenharia de Requisitos gil: Vantagens e Limitaes.............10 4. Consideraes Finais..................................................................17 5. Referncias................................................................................18

ndice de Figuras
Figura 1...........................................................................................8

1. Introduo

A Engenharia de Requisitos uma das mais importantes disciplinas do processo de desenvolvimento de software, pois suas atividades so principalmente dedicadas a identificar, definir e gerenciar o escopo do produto a ser desenvolvido. O escopo de um projeto de desenvolvimento est diretamente ligado ao escopo dos produtos entregues durante o ciclo de vida do software. Havendo mudanas no escopo do produto, estas precisam ser avaliadas e negociadas sob as perspectivas de esforo, prazo, custo e qualidade. Os processos tradicionais de engenharia de requisitos gerenciam as mudanas com base na previso dos riscos. Sempre que uma mudana sugerida, seus efeitos so propagados a fim de que o impacto possa ser avaliado e acordado entre os interessados. A antecipao s mudanas o ponto principal desta abordagem, e para tanto so exigidos vrios artefatos de controle e padronizao. Em contrapartida, nas abordagens geis de desenvolvimento de software a previsibilidade descartada em favor da habilidade em se adaptar s mudanas. Neste caso, o esforo uma parte considervel do esforo destinado pela disciplina de engenharia de requisitos tradicional na construo de artefatos e processos no contemplado. Contudo, a disciplina de requisitos ainda assim executada, porm com nfase mais uniforme ao longo do desenvolvimento, visto que a comunicao entre o cliente e a equipe de desenvolvimento constante do incio ao fim do projeto. Os captulos seguintes detalham o processo de engenharia de requisitos em processos de desenvolvimento gil de software e destaca suas vantagens e limitaes.
5

O corpo deste trabalho est estruturado da seguinte maneira: O Captulo 2, Engenharia de Requisitos, Previso e Reao; descreve em linhas gerais o processo de requisitos nas duas abordagens e destaca as principais habilidades exigidas em cada caso. O Captulo 3, Engenharia de Requisitos gil: Vantagens e Limitaes, detalha o processo de engenharia de requisitos no contexto do desenvolvimento gil de software, sob aspectos de vantagens e limitaes.

2. Engenharia de Requisitos, Previso e Reao

As disciplinas de desenvolvimento de software, assim como a de Requisitos, so inseridas nos processos tradicionais de desenvolvimento tal como RUP (Rational Unified Process) dentro do contexto de fases. Estas fases so planejadas e dimensionadas atravs de marcos que, dentre outras coisas, so utilizados como parmetro para medir a evoluo do projeto. Durante o planejamento do projeto definido o esforo que ser dedicado (nfase) a cada disciplina do desenvolvimento de software durante as fases: Iniciao, Elaborao, Construo e Transio. A disciplina de requisitos comumente enfatizada nas duas fases iniciais do processo, a fim de que se possa definir o quanto antes o escopo do produto e a partir dele controlar as alteraes. Esta distribuio de esforo das disciplinas entre as fases do desenvolvimento ilustrada a seguir:

Figura 1

Fases do RUP

Esta nfase nas fases iniciais do processo reside na necessidade de se antecipar aos riscos e minimizar os custos de alterar alguma funcionalidade do sistema nas fases posteriores. Esta atividade de prever mudanas e se antecipar a elas requer um grande esforo na execuo de processos e elaborao de artefatos. Em contrapartida, nas metodologias geis de desenvolvimento de software o esforo dedicado disciplina de requisitos tende a ser mais uniforme ao longo do ciclo de vida. A codificao feita em paralelo e so priorizadas as funcionalidades que agregam mais valor ao negcio do sistema. Desta forma as mudanas acontecem de forma mais freqente, e so vistas como uma oportunidade para que o cliente refine os requisitos, seja por uma mudana no negcio e ou por mudana no entendimento dos envolvidos (analistas, especialistas de negcio, usurios...) sobre o processo a ser automatizado. Considerando projetos em que prazo para implantao do sistema critico para o negcio (time-to-market), o tempo dedicado engenharia de requisitos tende a ser restringido a fim de reduzir o cronograma. Contudo, esta soluo pode implicar em requisitos que no atendem satisfatoriamente aos objetivos do negcio. Nestes casos a utilizao de prticas geis engenharia de requisitos, tais como on-site customer, pequenos releases, e refatorao podem facilitar a comunicao e o refinamento dos requisitos, de forma evolutiva, e assim alcanar o desenvolvimento de um sistema que atenda aos reais objetivos do negcio.

2.1 Consideraes Finais

Nesta seo foi feita uma introduo sobre a disciplina de requisitos considerando abordagens tradicionais e geis de desenvolvimento de

software, onde possvel verificar as principais divergncias quanto nfase dada ao processo de requisitos ao longo do ciclo de vida do software. Tambm foram descritas algumas vantagens do processo de requisitos executado em conjunto de prticas geis, em particular para o desenvolvimento de sistemas cujo prazo para entrar no mercado crtico. No prximo captulo sero detalhadas algumas vantagens e

desvantagens da engenharia de requisitos segundo s prticas geis de desenvolvimento de software. Em seguida sero apresentadas algumas sugestes de melhoria para suprir as deficincias apresentadas.

3. Engenharia de Requisitos gil: Vantagens e Limitaes

Projetos de desenvolvimento de software tm como principal objetivo construir sistemas que atendem s necessidades dos seus clientes em acordo com os objetivos do negcio. Sob este aspecto o principal objetivo da engenharia de requisitos transferir de forma efetiva e eficiente o conhecimento e as necessidades dos clientes para os desenvolvedores. Para que isto acontea o cliente precisa elaborar mentalmente um modelo dos processos que sero automatizados via software e transmiti-lo para o desenvolvedor. Este, por sua vez, alm de entender o modelo, precisa conhecer de perto o ambiente em que os processos so executados. Os mtodos de engenharia de requisitos em geral buscam minimizar esta distncia entre clientes e desenvolvedores atravs da documentao dos requisitos, utilizando-se de vrias tcnicas, principalmente no que diz respeito elicitao. A principal vantagem da engenharia de requisitos em processos de desenvolvimento gil se baseia na comunicao verbal, a qual bem mais efetiva do que especificaes escritas. A Engenharia de Requisitos gil (ER gil) foca em comunicar requisitos de forma efetiva e eficiente, e apresenta caractersticas adequadas para projetos em que o time-to-market crtico. Neste captulo sero discutidos os principais aspectos positivos e negativos da Engenharia de Requisitos gil quanto interao com o cliente, requisitos no-funcionais e gerenciamento de mudanas.

10

3.1 Gerenciamento de Mudanas

A engenharia de requisitos tradicional parte do princpio que as atividades de projeto e implementao devem ser precedidas de um esforo considervel para especificao das funcionalidades do sistema. No RUP, o trmino da fase de iniciao caracterizado pela elaborao do documento de requisitos, o qual deve apresentar a maioria dos requisitos que sero entregues ao final do desenvolvimento. Existem algumas razes para que este esforo seja realizado, dentre elas a necessidade de estimar o custo do sistema, e que pode ser razoavelmente mensurado a partir das especificaes de casos de uso atravs de mtricas de tamanho funcional tal como Pontos por Funo. Outra razo seria reunir o mximo de informaes para que a arquitetura componentes do e sistema outros seja projetada, de e assim definir que mdulos, o elementos projeto facilitam

desenvolvimento e diminuem o custo das alteraes. Alm destas, outra razo muito importante nesta abordagem definir o escopo do produto e partir dele estabelecer baselines e controlar mudanas. Uma vez definido o documento de requisitos, este passa a ser visto como um contrato entre cliente e desenvolvedores, que fixa previamente os limites do sistema. Desta forma, solicitaes de mudanas no escopo do produto so avaliadas e negociadas quanto ao impacto sobre custo e cronograma. Em geral existe uma tendncia a evitar mudanas em fases mais adiantadas do desenvolvimento. Em abordagens geis de desenvolvimento trabalham com a idia de modelo de contrato com escopo negocivel. Desta forma, cada iterao planejada visando a implementao das funcionalidades de mais relevncia para os objetivos de negcio. O pagamento feito por iteraes e as atividades de projeto do lugar habilidade de se adaptar s mudanas atravs da refatorao.
11

Neste sentido a nfase dada s atividades de engenharia de requisitos mais uniforme ao longo do ciclo de vida do software, concorrentemente s atividades de programao. As mudanas so inerentes ao processo de desenvolvimento gil, pois medida que novos requisitos emergem faz-se necessrio o uso de tcnicas de refatorao em combinao com outras prticas prprias do processo gil para minimizar o custo das mudanas. Neste momento surge a oportunidade de incorporar mudanas provenientes de um novo entendimento por parte dos envolvidos a respeito de um requisito anteriormente implementado. A principal vantagem desta abordagem em relao aos modelos tradicionais de desenvolvimento de software consiste na grande flexibilidade em alterar o escopo do produto e assim desenvolver um sistema que atenda s necessidades reais do cliente, sem que este seja penalizado pela especificao de requisitos desnecessrios nas fases iniciais do projeto, quando a viso acerca do sistema ainda muito superficial.

3.1.1 Consideraes
Para que o custo das mudanas nos processos de desenvolvimento gil seja vivel, preciso que algumas prticas sejam executadas, tais como refatorao, propriedade coletiva do cdigo, definio de padres de projeto e de codificao e programao em pares, dentre outras. Embora as prticas acima citadas minimizem o custo das mudanas, estas poderiam ser gerenciadas no sentido de registrar sua evoluo e desta forma evitar re-trabalho. Contudo, para que este controle seja feito os requisitos precisam ser gerenciados. Em XP os requisitos de alto nvel so expressos atravs das User Stories, e as especificaes mais detalhadas podem ser extradas dos testes de aceitao, porm de forma ainda incompleta. Informaes adicionais acerca dos requisitos so normalmente expressas verbalmente e inseridas no cdigo sem documentao, fazendo com que o prprio cdigo fonte seja a principal fonte de documentao do sistema.
12

Uma vez que a implementao de um requisito pode estar dispersa em diversas unidades de cdigo, a dificuldade de se estabelecer um mapeamento entre requisitos e cdigo diminui a capacidade de executar atividades essenciais ao gerenciamento de requisitos tais como identificao e rastreabilidade.

3.2 Interao com o Cliente

A forma de interao entre cliente e desenvolvedores um dos pontos chaves ER gil, e baseia-se em algumas prticas que permitem que o conhecimento seja transferido do cliente para o desenvolvedor de forma mais eficiente e efetiva, em curto espao de tempo e baixo custo: On-site customer: pelo menos um representante do cliente integrado equipe de desenvolvimento, preferencialmente no mesmo ambiente. Ele responsvel por tirar dvidas dos desenvolvedores, priorizar e selecionar os requisitos a serem implementados de acordo com os objetivos do negcio. Pequenos releases: permite que o usurio possa avaliar o quanto antes o sistema que est sendo desenvolvido, gerando um feedback que propicia um melhor entendimento dos requisitos. Os requisitos de alto nvel so expressos por meio das Estrias escritas pelos usurios e facilmente comunicadas entre os membros da equipe, servindo de base para o planejamento do escopo das iteraes. Os usurios tambm so responsveis pela elaborao dos Testes de Aceitao, os quais detalham todas as verificaes que sero realizadas para validao da funcionalidade, servindo portando como base contratual. Os testes de aceitao so utilizados como artefato de detalhamento dos requisitos do sistema (Test Driven Development) e orienta a implementao das funcionalidades do sistema.

13

Os desenvolvedores por sua vez so responsveis por elaborar os testes unitrios a partir dos testes de aceitao, antes de realizar qualquer outra atividade. Ao final de cada release o sistema deve passar por todos os testes unitrios.

3.2.1 Consideraes
Antes do incio do levantamento dos requisitos, a engenharia de requisitos sugere que os envolvidos sejam identificados e selecionados com base no grau de relevncia das suas necessidades para se atingir os objetivos do negcio. XP por exemplo considera todos os envolvidos de forma homogenia, independentemente da relevncia que cada um age sobre o negcio. importante que os envolvidos sejam identificados, e que sejam selecionados e priorizar os requisitos daqueles mais representativos ao objetivo do negcio. Em geral integrado equipe de desenvolvimento apenas um representante do cliente, o qual tem a funo de priorizar os requisitos. Embora esta deciso simplifique o processo de tomada de deciso quanto ao planejamento das iteraes, importante considerar vrios pontos de vista para que minimizar o risco de desenvolver um sistema que atenda somente s necessidades de um grupo ou de requisitos que no esto alinhados aos objetivos de negcio. XP no utiliza tcnicas muito elaboradas de elicitao de requisitos (prototipao e stories) e pressupe que o cliente sabe exatamente o que precisa. Tambm no considera que existem perspectivas diferentes para o mesmo problema.

3.3 Requisitos no-funcionais

Um dos principais problemas nesta abordagem recai sobre a elicitao requisitos no-funcionais. Estes requisitos descrevem restries que devem ser impostas ao sistema, e que em geral se aplicam a vrias funcionalidades. Contudo a implementao dos requisitos funcionais
14

normalmente iniciada

quando ainda no se tem uma especificao

detalhada destas restries.

3.3.1 Consideraes
Sugere-se que os requisitos no-funcionais sejam elicitados o quanto antes. Por mais eficientes que sejam as ferramentas e prticas utilizadas em ambientes de desenvolvimento gil, importante que aspectos gerais do sistema possam ser elicitados o quanto antes. Um exemplo seria a identificao da necessidade de manter um controle de acesso ao sistema baseado em perfis de usurios: todas as funcionalidades do sistema sero afetadas por este requisito no-funcional. Uma abordagem interessante para requisitos no-funcionais o NFR framework, de Chang, que permite refinar requisitos no-funcionais e identificar conflitos. A construo deste modelo estaria atrelada coleta das user stories e deveria ser posteriormente validado.

3.4 Consideraes Gerais

Em algumas situaes processos geis de engenharia de requisitos podem no ser muito adequados, tais como: Pessoas externas equipe de desenvolvimento precisam ter acesso aos requisitos. o A informao precisa perdurar por muito tempo (famlia de produtos). o Equipes de desenvolvimento distribudas, podendo ter membros que falam idiomas diferentes. Alta rotatividade da equipe Modelo Contratual no permite mudana nos requisitos

15

Algumas melhorias podem ser sugeridas na elicitao de requisitos, principalmente quando no possvel aplicar on-site customer, tal como neuro-lingstica.

16

4. Consideraes Finais

O processo de engenharia de requisitos em metodologias geis de desenvolvimento de software permite uma comunicao mais eficiente e efetiva dos requisitos entre clientes e desenvolvedores. As prticas de on-site customer, pequenos releases e comunicao verbal otimizam a atividade de levantamento dos requisitos. A priorizao dos requisitos mais relevantes aos objetivos do negcio outro ponto importante nesta abordagem. Com esta filosofia o risco de serem implementados requisitos desnecessrios bastante reduzido, considerando que cerca de 20% dos requisitos mais relevantes do sistema atendem a cerca de 80% dos objetivos de negcio. Neste trabalho foram apresentados os principais ganhos

provenientes das prticas geis de desenvolvimento, e algumas sugestes de melhoria baseadas nas prticas tradicionais de engenharia de requisitos quanto a aspectos relacionados interao com usurio, gerenciamento de mudanas e o levantamento dos requisitos no-funcionais. Observou-se, portanto, oportunidades de inserir alguns processos e ferramentas de controle comuns engenharia de requisitos tradicional sem prejudicar de forma incisiva a filosofia dos processos de desenvolvimento gil.

17

5. Referncias

[1] Ben Kovitz. Hidden Skills that Support Phased and Agile Requirements Engineering. Agil Alliance: 2002. [2] Rolf Goetz. How Agile Processes Can Help in Time-Constrained Requirements Engineering. SOPHIST GROUP, Germany. [3] Armin Eberlein, Julio Cesar Sampaio do Prado Leite. Agile Requirements Definition: A View from Requirements Engineering. International Workshop on Time-Constrained Requirements Engineering: 2002. [4] Schwaber, Ken. The Impact of Agile Processes on Requirements Engineering. Agil Alliance: 2002. [5] Julio Cesar Sampaio do Prado Leite. Extreme Requirements. PUC-Rio: 2001. [6] Kent Back, Martin Fowler. Planning Extreme Progamming. Addison Wesley. 2000. 160 p. [7] Gary Chin. Agile Project Management: How to Succeed in the Face of Changing Project Requirements. AMACON: 2004. 229 p. [8] Anderson, David James. Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results. Prentice Hall PTR: 2003. 336 p. [9] The Standish Group International. 2004 CHAOS Demographics and Project Resolution. p. 2, 2004. Disponvel em: http://www.standishgroup.com/chaos_resources/index.php.

18