Home

Baixar/Abrir

1. 1 Incha Clg Caso Uso Procurar Pedido Casos deU so relacionados por Pr e P s Condi es Casos de Uso selecionados Adicionar Caso de Uso Figura 20 Tela de Casos de Uso Afetados pela Requisi o de Mudan a Cen rio 1 Voltando ao exemplo da Figura 17 na qual foi realizado o cadastro da requisi o de mudan a Adicionar funcionalidades para requisi o e fechamento de compra com fornecedor Ap s selecionada a op o de identificar os casos de uso afetados mostrado na Figura 20 o pr ximo passo adicionar os casos de uso Submeter Proposta Requisi o de Compra e Aceitar Proposta do Fornecedor e Efetuar Compra para atender requisi o As Figuras 21 e 22 mostram a adi o dos casos de uso Submeter Proposta Requisi o de Compra e Aceitar Proposta do Fornecedor e Efetuar Compra A Figura 23 mostra a identifica o da pr condi o do caso de uso Aceitar Proposta do Fornecedor e Efetuar Compra que vinculada com a p s condi o do caso de uso Submeter Proposta Requisi o de Compra 69 a4 Adicionar Caso de Uso BAF Aplica o Sistema de Cota o de Pedidos com Fomecedores Ubjetivo Fomecedor submete proposta para atender requisi o de compra Titulo Submeter Proposta Requisi o de Compra Atores Fomecedor cond o he TEns Requisi o de compra foi submetida aos fornecedores P s Condi es Identificar P s Condi es Objeto Es
2. 3 O Sistema Informa que o pedido n o est cadastrado e solicita que o usu rio verifique se os dados do pedido est o corretos 4 O usu rio corrige os dados 5 Usa Procurar Pedido 6 O Sistema mostra os dados da situa o do pedido e o caso de uso termina 114 Pr condi o O usu rio ter feito o pedido P s condi o A situa o do pedido n o ter sido alterada Caso de Uso Cancelar Pedido Objetivo Cancelar o pedido Atores Cliente Funcion rio Fluxo de Eventos Prim rio caminho b sico O caso de uso come a quando o cliente seleciona Cancelar Pedido Usa Procurar Pedido O Sistema mostra os dados da situa o do pedido O Usu rio requisita cancelar o pedido O Sistema cancela o pedido Pr condi o O usu rio ter feito o pedido P s condi o A situa o do pedido marcada como cancelada Requisitos n o funcionais O registro do pedido permanece para o hist rico de pedidos NEN Caso de Uso Procurar Pedido Objetivo Procurar por pedido Atores Fluxo de Eventos Prim rio caminho b sico 1 O cliente pode fornecer o numero do pedido NP a identifica o ou o nome do cliente 2 O cliente ativa Busca 3 Seo cliente tiver fornecido o NP 1 O sistema devolve o pedido e o caso de uso termina 4 Seo cliente tiver fornecido a identifica o ou o nome do cliente 1 O sistema mostra a lista com todos os pedidos do cliente 2 O cliente seleciona o produto 3 O sistema devolve
3. Mais exemplos de casos de uso relacionados por pr e p s condi es conforme proposto neste trabalho podem ser observados na se o 5 2 4 2 5 Manuten o de Software De acordo com BEN 2000 a manuten o e evolu o do software caracterizam se por demandarem custo muito alto das organiza es e tamb m pela baixa velocidade de resposta implementa o de mudan as 2 5 1 Ciclo de Vida do Software BEN 2000 apresenta um Modelo de fases do Ciclo de Vida do Software conforme mostra a Figura 2 A principal contribui o deste modelo separar a fase de manuten o nos est gios Evolu o Servi os e Descontinua o 27 Desenvolvimento Inicial Mudan as de Evolu o Primeira Vers o Rodando Aplica o de pequenos consertos ajustes T rmino dos consertos ajustes T rmino do periodo de evolu o Descontinua o Desativar T rmino Figura 2 Ciclo de Vida do Software Adaptado de BEN 2000 Desenvolvimento Inicial Nesta fase a primeira vers o do software desenvolvida Esta primeira vers o pode n o conter todas as funcionalidades mas j tem uma arquitetura que persistir pelo resto do ciclo de vida da aplica o Um outro importante resultado do desenvolvimento inicial o conhecimento da aplica o conhecimento do dom nio dos requisitos de usu rio a fun o da aplica o no processo de neg cio as solu es e algoritmos utilizados os formatos de dados pontos f
4. rahe Carel ug gt TO PbesquestoF uncional int Frequencia nd Adicionacasolsed void EataCabollsed void ListaCagosUsolncluidosisoladosd Armay RelaceorarCatosUcoEstend aof oid Relacional hs aa wid Relacione rage aitaan wod RolacionaCasosUsoPrecedentes O wod RelacionaCasosUsoProcedentes wid RemoveRelaceeC linden eid ReroveRelacegClGriensaod uid RermoveRelacaoClieneralizacacd void RemoeRelacaoClPrecedentesd void RemoverelacaoClProcedentes wid LittaCasosUoR lacionados void LitCasosUenAplicanoes uid Tm mm Adiciona asospoMiMadosPorrteguudan ai wid Alinib itot iiti orRegMudancaed vot s emie aporsaa e tados oR eghen a wid ar TR Lista ado ssnApic aos a omheen ied ssbound ryss UCaeos Len et sdis Pi Fosgihed ana ee MostraMequitktoeiMudancat eid 112 OR equisioAplicacac int Disponibilidade int Eteo ini Vers o ini Cialaveremo i ini 2 Aulorvergad int FonteVersac int ObjetreoRequisia inl importa ini E ptabdidade int Comentarios int AdicionaPequinioAplicat ao int EqilaRequisitoAplicar aod int 7A RomoveRequishoAphc ace void RetormaP raamo DFe int ElpgueiaR e quis odpla acap vpid Desbloguaraequisfadphe dedo vid p Adotando role di wold EdiaCasoLheoi void Gio Riema a sola vaid Adhine ass sce void RemoreRelacionamentol amos ei Ed
5. 4 O sistema requisita as seguintes informa es para cadastro do SRS Nome da Aplica o ao qual o SRS est associado Informa es de Suporte Introdu o do SRS e Descri o Geral 5 O usu rio informa os dados e solicita salv los 6 O sistema salva as informa es do novo SRS 7 O Sistema registra dados do hist rico da mudan a efetuada N mero da Vers o Autor da adi o usu rio registrado e Data e Hora da adi o Alternativas Alternativa 1 Edi o 3 O usu rio solicita a edi o de um SRS 4 O sistema mostra a lista de SRS existentes 5 O usu rio escolhe um SRS e altera as Informa es de Suporte Introdu o do SRS ou Descri o Geral 6 O sistema salva as informa es 7 O Sistema registra dados do hist rico da mudan a efetuada N mero da Vers o Autor da edi o usu rio registrado e Data e Hora da edi o Alternativa 2 Remo o 3 O usu rio solicita a remo o de um SRS 4 O sistema mostra a lista dos SRSs existentes 5 O usu rio escolhe um SRS e solicita sua remo o 6 O Sistema verifica que n o existem requisitos de aplica o associados ao SRS e efetua a sua remo o 7 O Sistema registra dados do hist rico da mudan a efetuada N mero da Vers o Autor da remo o usu rio registrado e Data e Hora da remo o Alternativa 2 1 Remo o SRS cont m requisitos associados 6 O Sistema verifica que existem requisitos de aplica o associados ao SR
6. O cap tulo 5 descreve a avalia o do modelo proposto atrav s do prot tipo desenvolvido a partir do modelo Para a demonstra o dos resultados criou se alguns exemplos hipot ticos de sistemas 17 O cap tulo 6 ilustra as considera es finais desta pesquisa S o descritas as contribui es deste estudo bem como suas limita es e trabalhos futuros 18 2 REFERENCIAL TE RICO Este cap tulo descreve o referencial te rico deste trabalho apresentando os principais conceitos envolvidos com o tema da pesquisa engenharia de requisitos requisitos ger ncia de requisitos casos de uso e manuten o de software 2 1 Engenharia de Requisitos Engenharia de Requisitos ER um conjunto de atividades voltadas a identificar e comunicar os objetivos de um sistema de software e o contexto no qual o mesmo usado Portanto ER atua como uma ponte entre as necessidades de usu rios clientes e outras partes do mundo real afetadas pelo software e as capacidades e oportunidades disponibilizadas pelas tecnologias de software EAS 2004 Thayer e Dorfman THA 1990 definem engenharia de requisitos como a ci ncia e disciplina preocupada com a an lise e documenta o dos requisitos incluindo an lise das necessidades e an lise e especifica o dos requisitos Al m disso a engenharia de requisitos fornece mecanismos apropriados para facilitar as atividades de an lise documenta o e verifica o Desde a d cada de
7. o usu rio registrado e Data e Hora da edi o Alternativa 2 Remo o 3 O Usu rio solicita a remo o de uma Aplica o 4 O Sistema mostra a lista de aplica es existentes 5 O Usu rio escolhe uma aplica o e solicita sua remo o 6 O Sistema verifica que n o existe SRS e requisitos de aplica o associados aplica o e remove a mesma 7 O Sistema registra dados do hist rico da mudan a efetuada N mero da Vers o Autor da remo o usu rio registrado e Data e Hora da remo o Alternativa 2 1 Remo o Aplica o cont m SRS e requisitos associados 6 O Sistema verifica que existe SRS e requisitos de aplica o associados aplica o 7 A opera o cancelada Alternativa 3 Consulta 3 O Usu rio solicita a consulta de uma Aplica o 4 O Sistema mostra a lista de aplica es existentes 5 O Usu rio escolhe uma aplica o 6 O Sistema mostra as informa es da Aplica o Pontos de Extens o Requisitos N o Funcionais Associados Caso de Uso Gerenciar SRS Objetivo Permitir que o usu rio possa adicionar editar remover ou consultar SRS do sistema Atores Engenheiro de Requisitos Pr condi o Usu rio est registrado no Sistema 94 P s condi o de Sucesso Passos l O usu rio acessa a funcionalidade de cadastro de SRS 2 O sistema disponibiliza as fun es Adiciona Edita Remove ou Consulta 3 O usu rio solicita a adi o de um SRS
8. o Descri o Geral da SRS respons vel por descrever os fatores gerais que afetam o produto Esta se o 44 cont m outras nove subse es Fun es do Produto Caracter sticas do Usu rio Suposi es e Depend ncias Restri es Gerais Requisitos de Opera o Limites de Mem ria Distribui o dos Requisitos Requisitos de Adapta o de Local e Interfaces representados respectivamente pelas classes FuncoesProduto CaracteristicasUsuario SuposicoesDependencias RestricoesGerais RequisitosOperacao LimitesMemoria DistribuicaoRequisitos RequisitosAdaptacao e Interface FuncoesProduto A classe FuncoesProduto representa a subse o Fun es do Produto da SRS que fornece uma rela o das fun es do sistema a fim de informar os principais objetivos Esta classe composta de outros dois elementos Stakeholders e Objetivo representados respectivamente pelas classes SRS Stakeholder e Objetivo SRS Stakeholder Mant m a lista dos stakeholders usu rios patrocinadores etc envolvidos com o software Objetivo A classe Objetivo respons vel por manter todos os objetivos necess rios para o desenvolvimento completo do sistema CaracteristicasUsuario A classe CaracteristicasUsuario representa a subse o Caracter sticas do Usu rio da SRS que descreve as caracter sticas gerais dos usu rios do sistema SuposicoesDependencias A classe SuposicoesDependencias representa a subse o Suposi es
9. 14 Caso Uso Procurar Pedido Cl Caso Uso Submeter Requisi o de Compra aos Fomecedores 16 Caso Uso Verificar Pedido Cg Caso Uso Cancelar Pedido Editar Caro de Uso SSS Sa Edt Cato de Uso Figura 28 Requisi o de Mudan a Usu rio nao precisa estar autenticado no sistema para submiss o de pedido atendida Cen rio 3 Outro cen rio a ser demonstrado quando o analista recebe uma requisi o de mudan a que tem como conseqii ncia a remo o de casos de uso 14 No exemplo da Figura 29 o analista recebeu duas requisi es de mudan a A primeira descrevia que o sistema de pagamento n o devia mais permitir o pagamento com cheque Para esta requisi o ser atendida o caso de uso Efetuar Pagamento com Cheque foi removido A segunda requisi o de mudan a recebida descrevia que o sistema n o devia mais permitir a cria o de credi rios Para esta requisi o ser atendida o caso de uso Criar Credi rio para Cliente foi removido Respeitando a regra de consist ncia 3 descrita na se o 4 2 2 o sistema tamb m removeu o caso de uso Verificar Cadastro do Cliente no SPC Deve se observar que o sistema n o remove os casos de uso fisicamente Os casos de uso removidos continuam dispon veis para consulta Casos de Uso Afetados pela Requisi o de Mudan a i tos Identihca o dos Casos de Liso Aletados Casos de Liso Aletados pela Requisi o de Mudan a
10. Cancelar Pedido 14 Cato Uso Ciente Especial e Caso Uso Efetuar Login Caso Uso Procurar Pedido Ji Caso Uso Produto em Oferta JR Caro Uso Submeter Pedido a O Inchi a 6 Extendido Por a Di Caso Uso Verificar Pedido a 1G Aplica o Sistema de Pagamento a Jd Aplica o Sistema de Cota o de Pedidos com Fomecedores EE mem Catos de Uso relacionados por Pr e P s Condi es S Jd Casos de Uso cuja pr condi o est relacionada com a p s condi o do Caso Liso Submeter Pedido ig Caso Uso Procurar Pedido 6 Caso Uso Submeter Requisi o de Compra aos Fomecedores Cls Caso Uso Venica Pedido Dg Caso Uso Cancelar Pedido Edta Caso de Uso J Caso Uso Submeter Pedido EdtarCatodelso Remove 0 Figura 38 Requisi o de Mudan a atendida 82 5 4 Considera es do cap tulo Neste cap tulo demonstrou se como o prot tipo inst ncia do modelo de ger ncia de requisitos proposto neste trabalho suporta a an lise do impacto das requisi es de mudan a sobre requisitos de diversas aplica es a atualiza o e a manuten o da consist ncia destes requisitos Os exemplos demonstraram como a solu o atende o requisito 1 que trata da identifica o dos requisitos afetados por uma requisi o de mudan a an lise de impacto o requisito 3 que consiste na manuten o dos requisitos atualizados e consistentes conforme as requisi es de mudan as e o requisito 4 que se refer
11. Ros ngela Penteado e Fern o Germano 3 ed Porto Alegre Bookman 2007 695p LEF 2000 Leffingwell D Widrig D Managing Software Requirements A Unified Approach 1 ed England Addison Wesley 2000 544p LUC 2004 De Lucia A Fasano F Francese R Tortora G ADAMS An artifact based process support system In 16th International Conference on Software Engineering and Knowledge Engineering 2004 Canada Proceedings F Maurer and G Ruhe Eds p 31 36 LUC 2007 De Lucia A Fasano F Oliveto R Tortora G Recovering Traceability Links in Software Artifact Management Systems using Information Retrieval Methods Italia University of Salerno 2007 MOH 2008 Mohan K Xu P Cao L Ramesh B Improving change management in software development Integrating traceability and software configuration management Decision Support Systems v 45 p 922 936 2008 Dispon vel em lt http www sciencedirect com gt Acesso em 10 nov 2008 NOL 2007 Noll R P Ribeiro M B Ontological Traceability over the Unified Process In 14th Annual IEEE International Conference and Workshops on the Engineering of Computer Based Systems 2007 Tucson Arizona Proceedings 2007 NUS 2000 Nuseibeh B Easterbrook S Requirements Engineering A Roadmap Limerick ACM Future of Software Engineering 2000 p 37 45 PAL 2000 Palmer J D Traceability In Software Requirements Engineering Los Alamitos 2 ed
12. cnicos envolvidos com a engenharia de requisitos a gerenciarem mudan as nos requisitos dentro de um dom nio espec fico Segundo o autor uma parte importante de gerenciar requisitos que evoluem ao longo do tempo manter a ordem temporal das mudan as e suportar a rastreabilidade das modifica es 2 4 Casos de Uso Cen rios podem ser teis para facilitar a comunica o com os usu rios Os usu rios geralmente acham mais f cil relacionar exemplos da vida real do que descri es abstratas Os usu rios podem compreender e criticar um cen rio de como poderiam interagir com um sistema de software Os engenheiros de requisitos podem utilizar as informa es obtidas com essa discuss o para formular os requisitos reais do sistema A obten o de requisitos com base em cen rios pode ser realizada informalmente e o engenheiro de requisitos trabalha com os stakeholders para identificar cen rios e captar detalhes desses cen rios SOM 2003 Os casos de uso s o t cnicas baseadas em cen rios para a obten o de requisitos utilizando uma abordagem estruturada Eles s o atualmente uma caracter stica fundamental no uso da UML Unified Modeling Language Linguagem de Modelagem Unificada JAC 1998 Um caso de uso engloba um conjunto de cen rios em que cada cen rio um tra o isolado dentro do caso de uso SOM 2003 Casos de uso descrevem as Intera es entre o usu rio e o sistema focando no que o sistema faz para o usu r
13. o caso de uso mais gen rico possui um passo que uma sess o de generaliza o Esta sess o se liga com o caso de uso especializado representado pela classe CasoUsoNormal Assim como o relacionamento de inclus o e extens o o relacionamento de generaliza o tamb m facilita o suporte consist ncia das informa es dos casos de uso requisito 3 Esta caracter stica tamb m auxilia no suporte ao requisito 1 Mais detalhes podem ser verificados na se o 4 2 2 Regras de consist ncia Representa o da rela o por pr e p s condi es entre os casos de uso Representada pela rela o entre as classes PreCondicao e PosCondicao esta rela o possui a restri o DescricaoCasoUsoNormal distintos que define que ela s poss vel entre casos de uso distintos Isto deve se ao fato que a pr condi o de um caso de uso s pode estar relacionada com a p s condi o de outro caso de uso e n o com a p s condi o do pr prio caso de uso As classes PreCondicao e PosCondicao 53 herdam os atributos Objeto e Estado da classe Restricao A descri o das pr e p s condi es do sistema proposto definida da forma Objeto Estado Sendo que quando uma pr condi o de um caso de uso A relacionada com a p s condi o de um caso de uso B o sistema determina que esta pr condi o formada pelo mesmo Objeto e Estado da p s condi o do caso de uso B permitindo apenas que o ana
14. 61 5 21 Sistema de Vendas eseseseosescosesesessosesesscseseccesesescosesessoseseseoseseseesesessesesessoseseoe 62 5 2 2 Sistema de PAGAMENUO sesscsscdervssevecvetewasdvessseucucssavesdvesesetuasesdeesccuseauedessieseseeesseatins 63 5 2 3 Sistema de Compra de Fornecedores eesssssssecceccssssecccccccsossececcccssseeceecesssseeee 63 5 2 4 Vis o das Rela es entre OS SistemasS sessssssseseccececcccccscssssssseceecesesossssssssoo 64 3 3 Demonstra o dos resultados sisascrseesas sdeeed asians eadeeas TATI ata Ae 65 5 3 1 Identifica o dos requisitos afetados por uma requisi o de mudan a 66 592 Manuten o dos requisitos atualizados e consistentes conforme as requisi es de mudancas aut ca iii dba Err E TREN 76 5 3 3 Manter a rastreabilidade das mudan as dos requisitos de aplica o 78 5 3 4 Reuso de Casos de Uso uai sia pisca a da adiado 81 5 4 Considera es do Capitulo ieasne assa lana otoasioie caindo desde sia Lola data tuna Tod da inda siat 83 6 CONSIDERA ES FINA IS sans spraitasdaniausiisaan las miar anta as Usos a du isto ini cantas 84 6 1 CO MUO IC OCS Syari E seca UR oi na he 85 6 2 Limita coes AO ESQUIdO ares aaa sr 85 0 9 Trabalhos PUTOS Lurene thewiuds nents cust sdesinteseisscalavguedateouliceidubenpivudetvels 86 REFERENCIAS BIBLIOGRAFICAS ssiiisctiscshiccsscensesisesebencnaiasescidsatictoudisestiivebiscacactesssiicatees 87 AP NDICE I Documenta o do Prototipo
15. Alternativas Pontos de Extens o Requisitos N o Funcionais Associados Caso de Uso Alterar Casos de Usos afetados por Requisi o de Mudan a Objetivo Permitir que o usu rio possa alterar casos de usos identificados atrav s de uma requisi o de mudan a Atores Engenheiro de Requisitos Pr condi o Usu rio est registrado no Sistema P s condi o de Sucesso Os requisitos de aplica o alterados por uma Requisi o de Mudan a est o identificados no sistema Passos l O Usu rio seleciona uma Requisi o de Mudan a 2 O usu rio identifica que deve editar um caso de uso para atender requisi o de mudan a 104 O Sistema mostra a lista de casos de uso existentes agrupados por aplica o e com seus relacionamentos inclus o extens o e generaliza o devidamente representados 4 Para cada caso de uso o sistema mostra a lista de casos de uso que precedem e os casos de uso que procedem o mesmo 5 O usu rio seleciona um ou mais casos de uso 6 O sistema apresenta o hist rico de altera es de cada caso de uso selecionado como segue a Lista de requisi es de mudan a que foram implementadas no passado e que afetaram o caso de uso b Para cada requisi o de mudan a listada o sistema deve mostrar todos os casos de uso de aplica es afetados pela requisi o de mudan a 7 O usu rio seleciona um caso de uso afetado pelas requisi es de mudan as anteriores 8 O usu rio repete o passo
16. K Hamlen W T Application Program Maintenance Study Report to Our Respondents G Parikh N Zvegintzov eds Tutorial on Software Maintenance IEEE Computer Society Press pp 13 30 1982 Los Alamitos CA FIN 2000 Finkelstein A Emmerich W The Future of Requirements Management Tools Information Systems in Public Administration and Law G Quirchmayr R Wagner and M Wimmer Eds Oesterreichische Computer Gesellschaft Austria 2000 GOT 1994 Gotel O Finkelstein A An analysis of the requirements traceability problem In Ist International Conference on Requirements Engineering 101 1994 Colorado CO Proceedings California IEEE Computer Society Press 1994 IEE 1998 IEEE Std 830 1998 IEEE Recommended Practice for Software Requirements Specifications New York Institute of Electrical and Electronic Engineers 1998 38p JAC 1998 Jacobson I Grady B Rumbaugh J The Unified Software Development Process New York Addison Wesley 1998 463p KOT 1998 Kotonya G Sommerville I Requirements Enginnering process and techniques New York John Wiley amp Sons Ltd 1998 282p 88 KRU 2000 Kruchten P The Rational Unified Process An Introduction Upper Sadle River 2 ed New Jersey Addison Wesley 2000 320p LAR 2007 Larman C Utilizando UML e Padr es Uma introdu o an lise e ao projeto orientados a objetos e ao Processo Unificado trad Rosana T Vaccare Braga Paulo Cesar Masiero
17. a remove os requisitos 9 O Sistema registra dados do hist rico da mudan a efetuada N mero da Vers o Autor da modifica o usu rio registrado e Data e Hora da modifica o Alternativas Pontos de Extens o Requisitos N o Funcionais Associados Caso de Uso Adicionar Relacionamento Extens o Objetivo Permitir que o usu rio possa relacionar um caso de uso com outro caso de uso que extende o mesmo Atores Engenheiro de Requisitos 109 Pr condi o P s condi o de Sucesso O caso de uso relacionado com o caso de uso que o extende Passos l O Usu rio adiciona um passo ao caso de uso que representa um relacionamento extens o com outro caso de uso j cadastrado no sistema ou seja existe outro caso de uso que estende o caso de uso 2 O Sistema mostra a lista de casos de uso da aplica o ou aplica es que o caso de uso sendo adicionado editado associado 3 O Usu rio seleciona um caso de uso da lista 4 O Usu rio informa a descri o do Ponto de Extens o 5 O Sistema registra o relacionamento extens o entre os casos de uso Alternativas Pontos de Extens o Requisitos N o Funcionais Associados Caso de Uso Adicionar Relacionamento Inclus o Objetivo Permitir que o usu rio possa relacionar um caso de uso com outro caso de uso que inclu do pelo mesmo Atores Engenheiro de Requisitos Pr condi o P s condi o de Sucesso O caso de uso relacionado co
18. acompanhou durante todo o primeiro ano do curso Alberto sua ajuda foi essencial para que eu realizasse este trabalho A minha fam lia por compreender que eu precisava estar ausente em alguns eventos importantes Rodrigo Noll e professor Marcelo Blois muito obrigada pelas suas contribui es neste trabalho Ao Conv nio Dell PUCRS pelo apoio financeiro e profissional para realiza o deste trabalho E por fim agrade o a todos aqueles que me incentivaram a deixar a monotonia de lado e sair em busca de novos desafios Obrigada a todos voc s A parte mais dif cil de construir um sistema de software decidir precisamente o que constuir Frederick Brooks No Silver Bullet Essence and Accidents of Software Engineering RESUMO A manuten o e evolu o do software demanda um custo muito alto das organiza es Um dos motivos para este alto custo a falta de documenta o Os requisitos representam um dos principais meios de documenta o do software Geralmente os requisitos n o s o atualizados depois do t rmino do desenvolvimento do software ou seja n o s o atualizados durante a fase de manuten o O objetivo desta pesquisa propor uma solu o para o problema de manter os requisitos de aplica es de software atualizados e consistentes ao longo de processos de manuten o A solu o consiste em um modelo de ger ncia de requisitos que suporta a atualiza o e consist ncia dos requisitos ao longo de p
19. custo para compreens o do software o registro do conhecimento adquirido valioso Mas na pr tica ao t rmino da mudan a os envolvidos na mudan a do software tendem a voltar sua aten o a coisas novas em vez de atualizar a documenta o Por este motivo existem estudos como apresentado em RAJ 1999 que prop em a documenta o incremental ao longo do processo de mudan a Segundo este m todo depois de certo per odo de cont nuas mudan as uma documenta o significativa tende a ser gerada 30 Requisi o de mudan a Planejamento da mudan a Implementa o da mudan a verifica o e valida o da mudan a Re documenta o Figura 3 Ciclo de vida de mudan a 2 6 Considera es do cap tulo Este cap tulo apresentou a fundamenta o te rica dos principais conceitos envolvidos neste trabalho S o eles engenharia de requisitos requisitos ger ncia de requisitos casos de uso e manuten o de software Dos casos de uso al m da sua defini o na literatura demonstrou se que v rios autores os consideram como uma forma de representar os requisitos funcionais Os poss veis relacionamentos entre os casos de uso tamb m foram apresentados Em rela o manuten o do software apresentou se o ciclo de vida do software dando nfase para as fases de evolu o e servi o pois quando acontecem as requisi es de mudan as O ciclo de vida da requisi o de mudan a tamb m foi apresen
20. de X X eventos Pontos extens o Fluxos X X X X X alternativos stakeholders Para esta propriedade podem ser atribu dos valores num ricos ou algumas express es como vital importante ou interessante se ter DUR 1999 e Coment rios O prop sito desta propriedade permitir ao engenheiro de requisitos informar outras informa es que n o se enquadram nas outras propriedades e Freqii ncia Indica o numero de vezes que se espera que o caso de uso execute Apesar da frequ ncia n o ser um requisito uma informa o importante para os desenvolvedores do software e Fluxo b sico de eventos Descreve o fluxo de eventos ou cen rio principal que o caso de uso deve realizar para atingir o objetivo ou seja descreve o cen rio t pico de sucesso que satisfaz o objetivo dos stakeholders Usualmente descrito atrav s de uma segii ncia de eventos numerados e Fluxos alternativos Representam fluxo de eventos ou cen rios que s o ramifica es do fluxo b sico de eventos cen rio principal e Requisitos Nao Funcionais A especifica o de caso de uso tamb m pode conter a descri o de requisitos n o funcionais relacionados com o caso de uso requisitos especiais Entre esses requisitos podem se ter requisitos de qualidade tais como 24 desempenho confiabilidade usabilidade e restri es de projeto frequentemente relativas a dispositivos de E S que foram impostas ou considerad
21. de Uso Submeter Pedido 1 A regra de consist ncia 2 que descreve que o sistema de ger ncia de requisitos n o deve permitir a remo o de um caso de uso cuja p s condi o pr condicao de outro caso de uso demonstrada na Figura 33 A regra de consist ncia 3 que descreve que o sistema na remo o de um caso de uso deve remover tamb m o caso de uso inclu do caso o mesmo n o possua rela o com ator ou com nenhum outro caso de uso j foi demonstrada no exemplo da Figura 29 cen rio 3 da se o anterior A regra de consist ncia 4 muito semelhante regra 3 com a exce o de que a remo o de um passo do caso de uso que inclui e n o do caso de uso em si As demais regras regras de consist ncia 5 6 7 e 8 n o ser o demonstradas por serem muito semelhantes s regras 3 e 4 com a diferen a de tratarem dos outros tipos de relacionamentos da UML Extens o e Generaliza o af Casos d i Atetado equ Identiica o dos Casos de Uso Afetados Casos de Uso Aletados pela Requisi o de Mudan a Aplica o x Casos de Liso Hist nco de Mudan a do Caso de Uso Caso Uso Submeter Pedido 5 Ji Aplica o Sistema de Vendas a g Cato Uso Cancela Pedido CS Caso Uso Chente E special Lies Cato Uso Procurar Pedido LCi Caso Uso Produto em Oferta e Caso Uso Submeter Pedido s Og Caro Usa Vernhes Pedido a S Apica o Sistema de Pagamento G Aplza o Sistema de Cota o de Pedidos com Fomece
22. de Uso Consultar Hist rico de Mudan as da Aplica o Objetivo Permitir que o usu rio possa consultar o hist rico de mudan as de uma aplica o Atores Engenheiro de Requisitos Pr condi o P s condi o de Sucesso Passos l O Usu rio solicita consultar o hist rico de mudan as de uma aplica o 2 O Sistema mostra a lista de aplica es existentes 3 O Usu rio seleciona uma aplica o 4 O Sistema mostra a lista de requisi es de mudan as que afetaram aplica o os requisitos que foram afetados por cada mudan a de que forma foram afetados adicionados alterados ou removidos a data e hora da modifica o e o autor Alternativas Pontos de Extens o 111 Requisitos N o Funcionais Associados 3 Diagrama de Classes O diagrama de classes abaixo mostra um sub conjunto das classes do prot tipo que representam a funcionalidade que altera casos de uso afetados pelas requisi es de mudan as DRequisicanMudan a o int Estay char Ornigembludars int TipoMudarsa char DetaSubmiggas Date Datadualitecad Gate Desericgs chat EniregaPianejada char a Priceidadelmphamenta o chae Imiplementiaaie ch r Dereon char PriceidadeGerador char Precio chir Tiba thar prio doe gt char Humi art i lt int Aiioierean lt int lt lt boundaspe l Casos Lis od c sios a Hegan a meo HostrafequisicossMudanc a woi sand saach
23. de extens o cont m a descri o do caso de uso de extens o representada pela classe DescricaoCasoUsoExtensao ReqNaoFuncionalGeral Esta classe representa os requisitos n o funcionais referentes ao sistema como um todo Requisitos nao funcionais geral seriam por exemplo requisitos de desempenho que se apliquem a toda a aplica o PontoExtensao A classe PontoExtensao representa o ponto de extens o definido no caso de uso que extendido por outro caso de uso O ponto de extens o um s mbolo do caso de uso extendido que referencia um ponto particular do caso de uso que o extende As intera es definidas no caso de uso que o extende podem ser inseridas neste ponto de extens o atrav s desta classe que est definido o relacionamento de extens o extend entre os casos de uso Cada ponto de extens o est associado com uma ou mais partes representadas pela classe Parte do caso de uso de extens o Estas partes s o conjuntos de passos do caso de uso de extens o representados pela classe PassoCasoUso 47 ReqNaoFuncionalEspecifico Esta classe representa os requisitos nao funcionais referentes ao caso de uso ao qual est o associados Requisitos nao funcionais espec ficos seriam por exemplo requisitos de desempenho que se apliquem apenas a funcionalidade descrita pelo caso de uso DescricaoCasoUso Esta classe representa a especifica o do caso de uso Ela especializada por outras duas classes DescricaoC
24. de que forma eles eram identificados an lise de impacto e atualizados no SRS das aplica es 1 Qual o n mero de requisitos de aplica o afetados e por quais requisi es de mudan as 2 Estes requisitos j foram atualizados no SRS da aplica o 3 De que forma os requisitos da aplica o foram alterados Reescrita ou simples c pia dos requisitos descritos nas ERDs se o 4 4 Quantos requisitos de aplica o foram adicionados modificados e removidos 5 Existe alguma indica o na ERD de quais e como os requisitos de aplica o que devem ser atualizados no SRS Estas perguntas foram respondidas a partir da an lise de 12 ERDs feita pela pesquisadora sem interven o dos analistas No caso das ERDs analisadas cada ERD est associada com uma nica aplica o Seis aplica es s o afetadas por estas ERDs Identificou se que as 12 ERDs analisadas alteram um total de 118 requisitos de aplica o Dentre estes requisitos de aplica o alterados nenhum foi atualizado no SRS das aplica es correspondentes No entanto para todos os requisitos afetados tem se informa o para determinar qual a requisi o de mudan a que os alterou e de que forma eles foram alterados No momento em que foi feita esta an lise todas estas requisi es de mudan a ja haviam sido implementadas e entregues ao cliente De acordo com a pr pria equipe ap s a entrega do produto aos clientes os requisitos das aplica es af
25. de uso deste sistema A especifica o de cada caso de uso pode ser encontrada no Ap ndice II deste trabalho Submeter Requisi o de Compra aos Fornecedores Aceitar Proposta do Fornecedor e Efetuar Compra Funcion rio submeter Proposta Requisi o de Compra Fornecedor Figura 15 Sistema de Compra de Fornecedores 5 2 4 Vis o das Rela es entre os Sistemas Os tr s sistemas apresentados nas se es anteriores est o interligados O Sistema de Vendas necessita do Sistema de Pagamento para efetuar o pagamento de suas vendas assim como necessita do Sistema de Compra de Fornecedores para efetuar a compra de produtos dos seus fornecedores Tanto o Sistema de Pagamento como o Sistema de Compra de Fornecedores n o ser o acionados caso n o tenha acontecido um pedido de compra do cliente atrav s do Sistema de Vendas Estas liga es entre os sistemas est o ilustradas na Figura 16 Pode se perceber que al m das rela es descritas pela UML tamb m est o identificados os relacionamentos por pr e p s condi es conforme apresentado na se o 2 4 3 Para efeito de ilustra o os relacionamentos por pr e p s est o identificados de forma gr fica Por m importante ressaltar que n o est sendo proposta uma extens o da UML A representa o gr fica destes relacionamentos por pr e p s condi es apenas para auxiliar na compreens o dos exemplos 64 Si
26. em rela o ao relacionamento entre os casos de uso por pr e p s condi es Som cita o seguinte Pr condi es e p s condi es s o especifica es impl citas das condi es de seqii ncia dos casos de uso A pr condi o de um caso de uso uma condi o que precisa ser atendida at a execu o do caso de uso enquanto que a p s condi o uma condi o que atendida no final da execu o do caso de uso Apesar de citar que as pr e p s condi es indicam a seqii ncia de execu o dos casos de uso Som SOM 2007 n o prop e o relacionamento direto por pr condi es e p s condi es entre os casos de uso como apresentado nesta disserta o O autor prop e um relacionamento indireto que pode estar baseado nas pr condi es e p s condi es Este relacionamento est representado pelas listas UseCaseEnabling Casos de Uso Habilitados ou que procedem o caso de uso atual e FollowList Casos de Uso que Precedem o caso de uso atual 32 3 2 LUCIA FASANO OLIVETO e TORTORA 2007 Rastreabilidade dos artefatos de software a habilidade de descrever e seguir a vida de um artefato requisitos c digo testes modelos relat rios planos etc desenvolvido durante o ciclo de vida do software em ambas as dire oes dos requisitos ao c digo e vice versa GOT 1994 A rastreabilidade pode fornecer importantes informa es no desenvolvimento e evolu o do software au
27. lo Figura 25 Casos de Uso afetados pela Requisi o de Mudan a Adicionar funcionalidades para requisi o e fechamento de compra com fornecedor Origem da Mudan a Departamento de vendas Wee Usu rio n o precisa estar autenticado no sistema para submiss o de pedido Descri o Usu rio n o precisa estar autenticado no sistema para submiss o de pedido basta informar seus dados Projeto Manuten o do Sistema de Vendas Moi Luciana Beleza O Identifica Casos de Uso Afetados Identificar Requisitos N o Funcionais Geral Afetados Figura 26 Requisi o de Mudan a Usu rio n o precisa estar autenticado no sistema para submiss o de pedido 73 E ESG O A A sos de Usa etad pela Requisi o de Mudane Identifica o dos Casos de Uso Aletados Casos de Uso Afetados pela Requisi o de Mudar Aplica o x Casos de Uso Hist rico de Mudan a do Caso de so Caso Uso Submeter Pedido 6 Aplica o Sistema de Vendas amp i Caso Uso Cancelar Pedido dg Caso Uso Ciente E special Jg Caso Uso Efetuar Login C Caso Uso Procura Pedido 4 Caso Uso Produto em Oferta w 7 Caso Uso Submeter Pedido a Cg Caso Uso Verificar Pedido a 1 dz Aplica o Sistema de Pagamento a Aplica o Sistema de Cota o de Pedidos com Fomecedores Ea th Casos de Uso relacionados por Pr e P s 4 Catos de Uso cuja pr condi o est relaci
28. mudan a com os requisitos que foram afetados e Informe de que forma os mesmos foram afetados Baseado nesta an lise pode se afirmar que as ferramentas do mercado n o est o preparadas para gerenciar os requisitos de uma aplica o ao longo de sua evolu o 1 2 Quest o de Pesquisa Este trabalho tem como principal objetivo propor uma solu o para garantir a consist ncia dos artefatos de requisitos de aplica es Na maioria das vezes o documento de requisitos de uma aplica o concebido no In cio do projeto que visa desenvolv lo e ap s o fim do projeto ou mesmo durante o projeto o documento com os requisitos esquecido e se torna obsoleto Neste sentido a quest o de pesquisa deste estudo a seguinte Como suportar a consist ncia e atualiza o de requisitos afetados por requisi es de mudan a para manuten o de software 1 3 Objetivos Uma vez definida a quest o de pesquisa definiu se o objetivo geral e os objetivos espec ficos deste trabalho os quais s o apresentados a seguir 1 3 1 Objetivo Geral Propor um modelo que suporte a consist ncia e atualiza o das documenta es de requisitos de aplica es 1 3 2 Objetivos Espec ficos 16 e Embasamento te rico e contextualiza o do problema na literatura e An lise das dificuldades relacionadas com a ger ncia de requisitos de aplica es durante a fase de manuten o e Aprofundar o estudo te rico sobre as arquite
29. n o funcionais do Caso de Uso Submeter Pedido 14 UlReqNaoFuncionalEsp x 5 Tela que mostra os casos de uso que n o est o relacionados com outros casos de uso por suas pr e p s condi es 122 ET MRS sr theese PE E Pe 123
30. o Durante a fase de vis o a equipe recebe uma lista de requisi es de mudan as dos usu rios Os engenheiros escrevem os requisitos para atender cada necessidade dos usu rios requisi o de mudan a Estes requisitos s o escritos em um documento customizado criado pela equipe com base no documento SRS denominado ERD Enhancement Request Document para conter os requisitos que atendem a cada necessidade Por conven o da equipe cada ERD est relacionado com apenas uma aplica o A Figura 4 ilustra a estrutura do documento ERD 1 Necessidade do neg cio 2 Estado atual dos requisitos da aplica o 3 Requisitos para atender a necessidade 4 Estado dos requisitos da aplica o ap s as modifica es Figura 4 Estrutura do documento ERD Necessidade do neg cio Uma breve descri o da necessidade de neg cio que a altera o da aplica o ira atender Esta descri o baseada na requisi o de mudan a submetida pelo usu rio Estado atual dos requisitos da aplica o Cont m a descri o dos requisitos da funcionalidade s atingida s pela modifica o Esta descri o uma c pia da descri o contida no SRS da aplica o Cabe ressaltar que a identifica o de qual funcionalidade s deve ser alterada para atender a necessidade do neg cio feita de forma manual baseada no conhecimento pr vio dos Engenheiros de Requisitos sobre a aplica o em quest o No caso da necessidade do neg cio demandar
31. o rollback das altera es feitas por uma requisi o de mudan a requisito 5 Detalhes de como esta solu o suporta o versionamento dos requisitos de aplica o podem ser encontrados na se o 4 2 4 Representa o dos casos de uso como um conjunto de elementos Conforme descrito na se o anterior a classe CasoUso constitu da por um conjunto de classes tais como pr condi es classe PreCondicao p s condi es classe PosCondicao passos do cen rio principal e dos cen rios alternativos classe PassoCasoUso Atores classe Ator Ponto de Extens o classe PontoExtensao entre outros Essa granularidade permite uma verifica o de consist ncia mais eficaz j que poss vel por exemplo relacionar a pr condi o do caso de uso Submeter Pedido com a p s condi o do caso de uso Entrar no Sistema como ilustrado na Figura 1 da se o 2 4 3 Esta caracter stica auxilia no suporte ao requisito 3 que trata da manuten o dos requisitos atualizados e consistentes Representa o da rela o de inclus o entre os casos de uso Esta rela o est representada pelo relacionamento entre as classes IncluiCasoUso que um tipo de passo IncluiCasoUso a especializa o da classe PassoSimples com a classe 52 CasoUsoNormal Ou seja o caso de uso que inclui possui um passo cujo tipo de Inclus o O caso de uso inclu do representado pela classe CasoUsoNormal A representa o do rela
32. p s condi o pr condicao de outro caso de uso visualizar Figura 7 54 Objetivo Autenticar o usu rio no sistema Pr condi o Nenhuma s condi o Usu rio est registrado no Sistema Objetivo Permitir que o usu rio submeta um pedido de compra Cliente Pr condi o Usu rio est registrado no Sistema P s condi o O pedido deve ter sido gravado no sistema e marcado como confirmado Figura 6 Remo o da P s condi o Objetivo Autenticar o usu rio no sistema Pr condi o Nenhuma s condi o Usu rio est registrado no Sistema Objetivo Permitir que o usu rio submeta um d pedido de compra Cliente Pre condicao Usu rio est registrado no Sistema P s condi o O pedido deve ter sido gravado no sistema e marcado como confirmado Figura 7 Remo o de um caso de uso relacionado por P s condi o 3 Quando na remo o de um caso de uso o sistema de ger ncia de requisitos deve verificar se o caso de uso sendo removido inclui outros casos de uso Para cada caso de uso inclu do o sistema deve remover tamb m o caso de uso Inclu do caso o mesmo n o possua rela o com ator ou com nenhum outro caso de uso por inclus o extens o generaliza o ou pr condi o de outro caso de uso Veja na Figura 8 que se o caso de uso Criar Credi rio para Cliente for removido o sistema deve tamb m remover o caso de uso Verificar Cadastro do Cliente no S
33. proposta para atender requisi o de compra 3 O caso de uso termina e nenhuma proposta submetida 3 Sistema de Pagamento Caso de Uso Efetuar Pagamento 117 Objetivo Efetuar o pagamento na forma de cart o de cr dito ou cheque Atores Funcion rio Cliente Pr condi es Compra em andamento P s condi es Pagamento efetuado Fluxo de Eventos caminho b sico 1 Sistema apresenta as formas de pagamento aceitas 2 Sistema solicita uma forma de pagamento 3 Usu rio seleciona uma forma de pagamento Pagamento com cart o de cr dito ou Pagamento com cheque ou Pagamento em dinheiro Alternativas Alternativa 1 Pagamento com cart o de cr dito Usu rio seleciona Pagamento com Cart o de cr dito no passo 3 Sistema solicita os dados do cart o de cr dito Usu rio entra com os dados do cart o de cr dito Sistema apresenta mensagem que informa que o Banco autorizou o pagamento Usu rio confirma o pagamento Sistema imprime comprovante de pagamento Caso de uso termina N E E Alternativa 2 Pagamento com cheque Usu rio seleciona Pagamento com Cheque passo 3 Sistema solicita os dados do cheque Usu rio entra com os dados do cheque Incluir Verificar Cadastro do Cliente no SPC Sistema apresenta mensagem que cliente n o possui restri es Usu rio confirma o pagamento Sistema imprime comprovante de pagamento Caso de uso termina Cee rage Alt
34. software Ambos os trabalhos de LUC 2007 e MOH 2008 n o se preocupam em definir a forma como os requisitos est o representados como eles se relacionam entre si com as aplica es de software e com as requisi es de mudan as Estas s o caracter sticas essenciais para suportar a consist ncia e a atualiza o dos requisitos ao longo da evolu o do software e est o no escopo desta pesquisa O pr ximo cap tulo apresenta um estudo de caso explorat rio para melhor compreens o do problema alvo deste trabalho seguido da descri o do modelo proposto para resolv lo 36 4 MODELO PROPOSTO Este cap tulo ilustra o problema que este trabalho se prop e a resolver ressaltando as principais dificuldades identificadas a partir de um estudo de caso explorat rio realizado na f brica de software citada anteriormente A partir das dificuldades identificadas apresentada a proposta de solu o para o problema atrav s do Modelo Conceitual do problema regras de consist ncia e do versionamento dos requisitos 4 1 Descri o do Problema Nesta se o ser apresentada a descri o de um estudo explorat rio importante para a compreens o do problema e a identifica o dos principais requisitos que o modelo de ger ncia de requisitos que ser proposto deve atender 4 1 1 Estudo de caso explorat rio Com o objetivo de identificar as principais dificuldades envolvidas na manuten o dos requisitos consistentes e a
35. uso selecionado Funcionalidades de Adicionar Editar e Remover um caso de uso Quando o analista identifica que um caso de uso deve ser editado ou removido pela requisi o de mudan a ele deve selecionar o caso de uso da rvore Aplica o x Casos de Uso ou da rvore Hist rico de Mudan a do Caso de Uso Cada caso de uso selecionado adicionado lista Casos de Uso selecionados Nesta lista o analista pode optar por editar ou remover um caso de uso Quando o analista identifica que para atender a requisi o de mudan a um novo caso de uso deve ser adicionado ele deve selecionar o bot o Adicionar Caso de Uso 68 Aba Casos de Uso Afetados pela Requisi o de Mudan a Esta aba mostra a lista dos casos de uso que foram adicionados alterados ou removidos pela requisi o de mudan a Um exemplo desta funcionalidade pode ser visto na Figura 25 24 Casos de Uso Afetados pela Requisi o de Mudan a Jol Idenilica o dos Casos de Uso Afetados Casos de Uso Afetados peta Requisi o de Mudan a EE Aplica o x Casos de Uso Hist rico de Mudan a do Caso de Usa Cf Aplica o Sistema de Vendas 6 Caso Uso Cancelar Pedido Jd Caso Uso Ciente E special Jd Caso Uso Procurar Pedido 6 Caso Uso Produto em Oferta Je Caso Uso Submeter Pedido a Clg Caso Uso Venica Pedido Oe eee Site de Pagamerio ee ee DA Cato Uso Submeter Requisi o de Compra aos Fomecedores
36. usu rio seleciona um caso de uso para ser removido 6 O sistema apresenta o hist rico de altera es deste caso de uso como segue a Lista de requisi es de mudan a que foram implementadas no passado e que afetaram o caso de uso b Para cada requisi o de mudan a listada o sistema deve mostrar todos os casos de uso de aplica es afetados pela requisi o de mudan a com informa o se o caso de uso foi adicionado alterado ou removido 7 O usu rio seleciona um caso de uso afetado pelas requisi es de mudan as anteriores que tamb m deve ser removido 8 O usu rio repete o passo 5 a 7 at selecionar todos os casos de uso que devem ser removidos pela requisi o de mudan a 9 O Sistema executa o caso de uso Remover Caso de Uso para cada caso de uso selecionado 10 O Sistema relaciona os casos de uso removido com a requisi o de mudan a indicando que a requisi o de mudan a remove os casos de uso 11 O Sistema registra dados do hist rico da mudan a efetuada N mero da Vers o Autor da modifica o usu rio registrado e Data e Hora da modifica o Alternativas 106 Pontos de Extens o Requisitos N o Funcionais Associados Caso de Uso Adicionar Requisitos N o Funcional Geral afetados por Requisi o de Mudan a Objetivo Permitir que o usu rio possa adicionar requisitos n o funcional geral afetados por uma requisi o de mudan a Atores Engenheiro de Requisitos Pr condi o Usu rio est r
37. 1 Remo o de um caso de uso relacionado por Generaliza o 4 2 4 Versionamento dos requisitos Al m da representa o dos casos de uso conforme demonstrado no Modelo Conceitual da Figura 5 e das regras de consist ncia apresentadas na se o anterior outro artif cio utilizado nesta solu o para o suporte consist ncia e atualiza o dos requisitos requisito 3 e o hist rico da evolu o da aplica o requisito 4 o versionamento dos requisitos Para o versionamento dos requisitos foi utilizado o conceito de Revis o COL 2004 A cada altera o de um requisito de aplica o o sistema de ger ncia de requisitos deve criar uma nova revis o A revis o um n mero que representa o estado do requisito depois de uma transa o Sendo que a transa o pode ser de cria o do requisito altera o ou remo o do mesmo Se um elemento de um caso de uso requisito funcional como por exemplo um passo alterado uma nova revis o do caso de uso gerada Esta revis o est associada com todos os elementos que comp em o caso de uso no momento da transa o Quando um requisito criado ele est automaticamente associado com a revis o de n mero 1 Se ele sofrer qualquer tipo de altera o o sistema automaticamente criar a revis o de n mero 2 e assim consecutivamente Cada requisito cont m sua pr pria numera o de revis o ou seja a numera o n o nica entre os requisitos 58 Quan
38. 5 a 7 at selecionar todos os casos de uso alterados pela requisi o de mudan a 9 O Sistema executa o caso de uso Editar Caso de Uso para cada caso de uso selecionado 10 O Sistema relaciona os casos de uso alterados com a requisi o de mudan a indicando que a requisi o de mudan a altera os casos de uso identificados 11 O Sistema registra dados do hist rico da mudan a efetuada N mero da Vers o Autor da modifica o usu rio registrado e Data e Hora da modifica o Alternativas Pontos de Extens o Requisitos N o Funcionais Associados 105 Caso de Uso Remover Casos de Usos afetados por Requisi o de Mudan a Objetivo Permitir que o usu rio possa remover casos de usos identificados atrav s de uma requisi o de mudan a Atores Engenheiro de Requisitos Pr condi o Usu rio est registrado no Sistema P s condi o de Sucesso Os requisitos de aplica o removidos por uma Requisi o de Mudan a est o identificados no sistema Passos 1 O Usu rio seleciona uma Requisi o de Mudan a 2 O usu rio identifica que deve remover um caso de uso para atender requisi o de mudan a 3 O Sistema mostra a lista de casos de uso existentes agrupados por aplica o e com seus relacionamentos Inclus o extens o e generaliza o devidamente representados 4 Para cada caso de uso o sistema mostra a lista de casos de uso que precedem e os casos de uso que procedem o mesmo 5 O
39. 70 problemas com ER persistem como uma causa chave para a inefici ncia e falhas de projetos de software Melhorias no processo de ER t m potencial de reduzir custos e tempo de desenvolvimento e aumentar a qualidade do software SAD 2007 A engenharia de requisitos no contexto da engenharia de software um processo que engloba todas as atividades que contribuem para a produ o de um documento de requisitos e sua manuten o ao longo do tempo Segundo AUR 2003 a ER ambos uma atividade organizacional e uma atividade de projeto uma atividade organizacional quando o enfoque definir qual o conjunto de requisitos que s o apropriados para o software e quais requisitos ser o entregues uma atividade de projeto quando este conjunto de requisitos direcionado para a equipe que ira desenvolver o software Este dualismo envolve um conjunto de decis es que tem que atender tanto as necessidades da organiza o assim como as necessidades do projeto 2 2 Requisitos Segundo DOR 1990 requisitos de software podem ter duas defini es 19 Uma condi o ou capacidade do sistema de software necess ria para o usu rio resolver um problema ou alcan ar um objetivo Uma condi o ou capacidade que deve ser encontrada ou possu da por um sistema ou componente do sistema de software para satisfazer um contrato padr o especifica o ou outro documento imposto formalmente Alguns autores definem um requisito como
40. Aplica o x Casos de Uso Hist rico de Mudan a do Caso de Use Apbcacdo Sistema de Pagamento Aplica o Sistema de Vendas Requisi o Mudan a Remover luncionaidade do Sistema de Pagamento que permite o pagamento com cheque dg Aplica o Sistema de Pagamento JQ Remo o Caso Uso Pagamento com cheque Jg Cato Uso REMOVIDO Criss Credi rio para Ciente Jd Requisi o Mudan a O sistema n o deve mais permita cria o de credi rios Jd Caso Uso Efetuar Pagamento IL Remo o Caso Usa Venica Cadastro do Chente no SPC 16 Caso Uso Pagamento com cart o de cr dito G3 Remo o Caro Uso Criar Credi rio para Chant dg Caso Uso REMOVIDO Pagamento com cheque Lig Caso Uso REMOVIDO Verica Cadastro do Ciente no Si a eG Apbca o Sistema de Cota o de Pedidos com Fomecedores iss gt 4 gt Casos de Uso relacionados por Pr e P s Condi es Casos de Uso selecionados Acciona Caso de Uso Figura 29 Requisi es de Mudan a que removem casos de uso Cen rio 4 Segue um outro cen rio para ilustrar como a proposta auxilia na an lise de impacto Supondo se que chegue uma requisi o de mudan a com a seguinte descri o 66 o f p Funcion rio deve garantir que a proposta do fornecedor cont m o pre o de cada produto com o pre o vista e com o pre o a prazo Considerando que esta requisi o trata se de uma mudan a no recebimento da proposta do fornecedor o analista dev
41. Atores Pr condi o e P s condi es 2 O usu rio informa o passo do cen rio principal ou cen rio alternativo 3 O sistema repete o passo 2 at que todos os passos sejam informados 96 4 O usu rio Informa os requisitos n o funcionais espec ficos associados com o caso de uso Alternativas Alternativa 1 Casos de Uso que precedem o caso de uso sendo adicionado 2 O usu rio identifica que existem casos de uso que devem ser executados antes precedem do caso de uso sendo adicionado 3 O sistema mostra uma lista dos casos de uso das aplica es associadas com o caso de uso sendo adicionado 4 O usu rio pode selecionar um ou mais casos de uso 5 O sistema salva a rela o de preced ncia entre os casos de uso e volta ao passo 2 da Subse o Adicionar Caso de Uso Alternativa 2 Adicionar Relacionamento Extens o 2 O Usu rio informa um passo que representa um relacionamento extens o com outro caso de uso 3 O Sistema executa o caso de uso Adicionar Relacionamento Extens o 4 O Sistema volta ao passo 2 da Subse o Adicionar Caso de Uso Alternativa 3 Adicionar Relacionamento Inclus o 2 O Usu rio informa um passo que representa um relacionamento inclus o com outro caso de uso 3 O Sistema executa o caso de uso Adicionar Relacionamento Inclus o 4 O Sistema volta ao passo 2 da Subse o Adicionar Caso de Uso Alternativa 4 Adicionar Relacionamento Generaliza o 2 O Usu rio infor
42. Caso de Uso o sistema mostra abaixo do caso de uso uma sub rvore com o seu hist rico de mudan a 2 Casos de Uso Afetados pela Requisi o de Mudan a BAX Idenilica o dos Casos de UsoAfetados Casos de Uso Afetados pela Requisi o de Mudan a Aplica o x Casos de Uso Hist rico de Mudan a do Caso de Use a l Caso Uso Cancelar Pedido A Ji Caso Uso Ciente E special Ch Caso Uso Efetuar Login De Casa Uso Prague Pedido Caio Uso onde Pedido gt Og In Ire 3 Oe ExenddoPor 6 Caso Uso Ciente Especial Cie Coto Use ibid Ce Aplica o aii de Podarili lG Aplica o Sistema de Cota o de Pedidos com Fomecedo gt Casos de Uso relacionados por Pr e P s Condi es Casos de Uzo selecionados Figura 19 Representa o do relacionamento de Extens o rvore Casos de Uso relacionados por Pr e P s Condi es O objetivo desta rvore mostrar ao analista os casos de uso relacionados por pr e p s condi es com um caso de uso selecionado Quando um caso de uso da rvore Aplica o x Casos de Uso selecionado o sistema mostra duas listas com as seguintes informa es os casos de uso cuja p s condi o est relacionada com a pr condi o do caso de uso selecionado casos de uso que precedem o caso de uso selecionado e os casos de uso cuja pr condi o est relacionada com a p s condi o do caso de uso selecionado casos de uso que procedem o caso de
43. LUCIANA MESQUITA BELLEZA MODELO PARA SUPORTAR A ATUALIZA O E CONSIST NCIA DE REQUISITOS EM PROCESSOS DE MANUTEN O DE SOFTWARE Disserta o apresentada como requisito parcial a obten o do grau de Mestre em Ci ncia da Computa o pelo Programa de P s Gradua o em Ci ncia da Computa o da Faculdade de Inform tica Pontif cia Universidade Cat lica do Rio Grande do Sul Orientador PROF DR RICARDO MELO BASTOS PORTO ALEGRE MAR O de 2009 Dados Internacionais de Cataloga o na Publica o CIP B442m Belleza Luciana Mesquita Modelo para suportar a atualiza o e consist ncia de requisitos em processos de manuten o de software Luciana Mesquita Belleza Porto Alegre 2009 122 f Diss Mestrado Fac de Inform tica PUCRS Orientador Prof Dr Ricardo Melo Bastos 1 Inform tica 2 Engenharia de Software 3 Software Manuten o I Bastos Ricardo Melo II T tulo CDD 005 1 Ficha Catalogr fica elaborada pelo Setor de Tratamento da Informa o da BC PUCRS FAC se r a Pontificia Universidade Cat lica do Rio Grande do Sul i E l _ FACULDADE DE INFORM TICA ty A PROGRAMA DE P S GRADUA O EM CI NCIA DA COMPUTA O PLK TERMO DE APRESENTA O DE DISSERTA O DE MESTRADO Disserta o intitulada Modelo para Suportar a Atualiza o e Consist ncia de Requisitos em Processos de Manuten o de Software apresentada por Luciana Mesquita Belleza como par
44. PC porque o mesmo n o tem rela o com ator e nem com nenhum outro caso de USO 55 Remo o do caso de uso Criar Credi rio para Cliente Funcion rio Caso de Uso verificar Cadastro do Cliente no SPC tamb m deve ser removido Figura 8 Remo o de um caso de uso relacionado por Inclus o 4 Quando na remo o de um passo de um caso de uso que inclui outro caso de uso O sistema deve remover tamb m o caso de uso Inclu do caso o mesmo n o possua rela o com ator ou com nenhum outro caso de uso Veja na Figura 9 que se o passo que do caso de uso Criar Credi rio para Cliente que inclui o caso de uso Verificar Cadastro do Cliente no SPC for removido o sistema deve tamb m remover o caso de uso Verificar Cadastro do Cliente no SPC Remo o do passo que inclui o caso de uso verificar Cadastro do Cliente no SPC Criar Credi rio para Cliente E lt include gt Funcion rio Caso de Uso Verificar Cadastro do Cliente no SPC tamb m deve ser removido Figura 9 Remo o do passo de um caso de uso relacionado por Inclus o 5 Quando na remo o de um caso de uso o sistema de ger ncia de requisitos deve verificar se o caso de uso sendo removido estendido por outros casos de uso Para cada caso de uso que estende o caso de uso sendo removido o sistema deve remov lo caso o mesmo n o possua rela o com ator ou com nenhum outro caso de uso Um exemplo de
45. R H Thayer and M Dorfman Eds IEEE Computer Society Press 2000 p 412 422 FJE 1982 Fjeldstad R K Hamlen W T Application Program Maintenance Study Report to Our Respondents G Parikh N Zvegintzov eds Tutorial on Software Maintenance IEEE Computer Society Press pp 13 30 1982 Los Alamitos CA 89 RAJ 1999 Rajlich V Varadajan S Using the Web for Software Annotations Software Engineering and Knowledge Engineering Singapore v 9 p 55 72 1999 RAJ 2000 Rajlich V Modeling Software Evolution by Evolving Interoperation Graphs Annals of Software Engineering J C Baltzer AG Science Publishers Red Bank NJ v 9 2000 SAD 2007 Sadraei E Aurum A Beydoun G Paech B A field study of the requirements engineering practice in Australian software industry Requirements Engineering Springer Verlag New York 18p 2007 SAY 2005 Say o M Leite J C S P Rastreabilidade de Requisitos Revista de Inform tica Te rica e Aplicada RITA Porto Alegre v XII num 1 2005 SOM 1998 Sommerville I Software Engineering Massachusetts Addison Wesley Reading 1998 SOM 2003 Sommerville I Engenharia de Software 6 ed Sao Paulo Addison Wesley 2003 606p SOM 2005 Sommerville I Integrated Requirements Engineering A Tutorial IEEE Software v 22 1 p 16 23 Janeiro Fevereiro 2005 SOM 2006 Som S S Supporting Use Case based Requirements Engineering Information an
46. S 7 A opera o cancelada 95 Alternativa 3 Consulta 3 O Usu rio solicita a consulta de um SRS 4 O Sistema mostra a lista de SRSs existentes 5 O Usu rio escolhe um SRS 6 O Sistema mostra as Informa es do SRS Pontos de Extens o Requisitos N o Funcionais Associados Caso de Uso Adicionar Requisito de Aplica o Objetivo Permitir que o usu rio possa adicionar Requisitos de Aplica o no sistema Atores Engenheiro de Requisitos Pr condi o Usu rio est registrado no Sistema P s condi o de Sucesso Passos l O Usu rio solicita a adi o de um Requisito de Aplica o 2 O Sistema requisita que o usu rio informe com qual ou quais as aplica es que o novo requisito deve ser associado 3 O Usu rio informa uma aplica o 4 O Sistema mostra os tipos de Requisitos de Aplica o N o Funcional Geral ou Caso de Uso 1 Se o usu rio escolher N o Funcional Geral ver subse o Adicionar Requisito N o Funcional Geral 2 Se o usu rio escolher Caso de Uso ver subse o Adicionar Caso de Uso 5 O sistema salva o requisito 6 O Sistema registra dados do hist rico da mudan a efetuada N mero da Vers o Autor da adi o usu rio registrado e Data e Hora da adi o Subse o Adicionar Requisito N o Funcional Geral l O Usu rio informa a descri o do requisito n o funcional geral Subse o Adicionar Caso de Uso l O usu rio informa o Objetivo T tulo
47. TR FORM E N E A E RBD RO AUGE O 12 Figura 28 Requisi o de Mudan a Usu rio n o precisa estar autenticado no sistema para submiss o de pedido ME AL 5 6 E PA E E E E E E O E S E RN EE 13 Figura 29 Requisi es de Mudan a que removem casos de USO ccccccccececcecceceseeseseeeeseseeseesaaeaeeeeeeeeeseeeeeeseeeeneees 74 Figura 30 Rela es por pr e p s condi es do caso de Uso Submeter Pedido 75 Figura 3 1 Edi o caso de Uso Submeter Pedido nsa ne E A aa 16 Figura 32 Mensagem de erro na remo o da p s condi o do caso de Uso Submeter Pedido 16 Figura 33 Mensagem de erro na remo o do caso de Uso Submeter Pedido eee 17 Figura 34 Hist rico de mudan a da aplica o Sistema de Cota o de Pedidos com Fornecedores 78 Figura 35 Hist rico do Caso de Uso Submeter Pedido re rerereeerenaeearrerereeenaaaneranos 19 Figura 36 Detalhes das vers es do Caso de Uso Submeter Pedido eres 80 Figura 37 Exemplo de inclus o de caso de uso de outra apliCagao ccccccccesesseeseeesesenseaeaaeeeeeeeeeeeeeeeeeeeeneeenenes 81 Figura 36 Requisi o de Mudan a atendida Seuren a ead ara dO Casa Uia qu dai E sa RE 81 LISTA DE TABELAS Tabela 1 Conte do da especifica o de casos de uso adaptada de AND 2001 LISTA DE SIGLAS CR Change Request ERD Enhancement Request Document LSI Latent Se
48. a aplica o Sistema de Cota o de Pedidos com Fornecedores ap s as modifica es pela requisi o de mudan a O primeiro n vel da rvore mostra as requisi es de mudan as que afetaram requisitos deste sistema No segundo n vel mostrada a lista dos casos de uso afetados Antes do nome do caso de uso mostrada a descri o do tipo de modifica o sofrida Remo o Altera o ou Adi o Outro exemplo de hist rico da aplica o foi mostrado na Figura 29 com a diferen a que ao inv s de adi o de casos de uso neste exemplo foi realizada a remo o de casos de uso do Sistema de 99 Pagamento 2 Casos de Uso Afetados pela Requisi o de Mudan a Cof Identiica o dot Caros de Uso Aletados Catot de Uso Afetados pela Requisi o de Mudan a Aplica o x Casos de Uso Hist nco de Mudan a do Caso de Uso Aplica o Sistema de Cota o de Pedidos com Fomecedores Cli Aplica o Sistema de Vendas 16 Requisi o Mudan a Adicionar funcionalidades para requisi o e fechamento de compra com fomecedor G Aplica o Sistema de Pagamento 1 Adi o Caso Uso Submeter Proposta Requisi o de Compra Aplhza o Sistema de Cola o de Pedidos com Fomecedores p Adi o Caso Uso Processar Proposta gs Caso Uso Processar Proposta dg Cato Uso Submeter Proposta Requisi o de Compra a Caso Uso Submeter Requisi o de Compra aos Fomecede Casos de Uso relacionados por P
49. a as informa es referentes s interfaces do sistema Os tipos de interface s o Interfaces de Usu rio Interfaces do Hardware Interfaces do Software e Interfaces de Comunica o InformacoesSuporte A classe InformacoesSuporte define a se o Informa es do Suporte da SRS respons vel por tornar a SRS mais f cil de ser utilizada Esta se o constitu da por duas subse es Tabela de Conte do e ndice e Ap ndices representadas respectivamente pelas classes Tabela e Apendices Tabela A classe Tabela representa a subse o Tabela de Conte do e ndice do SRS seguindo as pr ticas convencionais Apendices A classe Apendices representa a subse o Ap ndices da SRS que os especifica se necess rio Caso sejam identificados deve ser informado se eles s o ou n o parte dos requisitos Classe que representa a Aplica o Aplicacao Esta classe representa a aplica o de software Nela devem estar definidos os dados da aplica o como a sua descri o a data em que foi criada por quem ela foi criada qual o seu objetivo qual o contexto no qual ela est inserida dentro da organiza o n mero de usu rios tipos de usu rios que utilizam a aplica o entre outras informa es Classes que constituem os Requisitos da Aplica o Requisito Aplicacao Esta classe deve conter os requisitos da aplica o Esta classe deve conter informa es como o objetivo do requisito a Import ncia coment rios d
50. a cria o de uma funcionalidade nova esta sess o deve indicar que a funcionalidade n o existe na aplica o atualmente Caso seja identificado que a necessidade de neg cio implica em modifica es em mais de uma aplica o um ERD criado para cada aplica o Requisitos para atender a necessidade Nesta se o s o identificados e devidamente descritos os requisitos que devem ser alterados removidos ou adicionados aplica o Estado dos requisitos da aplica o ap s as modifica es Esta se o deve conter a descri o dos requisitos da aplica o que ser o alterados removidos ou adicionados de tal forma que estes estejam prontos para serem transcritos para o SRS da aplica o 38 A partir de entrevistas com membros da equipe de analistas observou se que a principal preocupa o da equipe de manter os SRSs consistentes contendo os requisitos das aplica es atualizados ao longo do processo de manuten o Tendo em vista esta preocupa o apontada pela equipe identificou se a necessidade de entender melhor o problema identificar as principais dificuldades e qual a dimens o das mesmas Para isso partiu se para uma an lise dos documentos de requisitos SRSs e ERDs criados pela equipe Seguem abaixo as perguntas que guiaram a an lise Estas perguntas foram elaboradas pela pr pria autora com o objetivo de identificar se os requisitos afetados por requisi es de mudan as estavam sendo atualizados e
51. a rastreabilidade poss vel recuperar o estado anterior a uma requisi o de mudan a O requisito 2 que trata do gerenciamento da concorr ncia dos requisitos de aplica o ser o tratadas como trabalho futuro Estas considera es em rela o ao escopo atendido por esta solu o ser o ilustradas no pr ximo cap tulo 60 5 AVALIA O DO MODELO PROPOSTO Este cap tulo visa apresentar a avalia o do modelo proposto Para viabilizar esta avalia o foi desenvolvido um prot tipo que ser descrito na se o 5 1 Ap s o desenvolvimento do prot tipo fez se um levantamento de todos os cen rios relevantes ao contexto deste trabalho considerando todas as peculiaridades desta solu o Considerando os cen rios selecionou se tr s sistemas hipot ticos para utiliz los nas demonstra es Estes exemplos est o descritos na se o 5 2 As demonstra es de como o sistema se comporta nos diversos cen rios est o apresentadas na se o 5 3 5 1 Prot tipo Com o objetivo de auxiliar a avalia o do modelo proposto neste trabalho um prot tipo de software foi desenvolvido A implementa o iniciou com a escolha da arquitetura e das linguagens para a implementa o do prot tipo Foi definido que a persist ncia seria feita em um banco de dados com a entrada de dados feita atrav s de uma interface gr fica Assim optou se pela arquitetura em tr s camadas no modelo MVC Model View Control Microsoft CH N
52. a requisi o de mudan a e identificar que para atend la deve remover a p s condi o do caso de uso Submeter Pedido o sistema mostrar uma mensagem de erro informando que a opera o n o poss vel conforme mostra a Figura 32 2 Casos de Uso Afetados pela Requisi o de Mudan a x Identifica o dos Casos de Uso Aletados Casos de Uso Afetados pela Requisi o de Mudan a Aplhca o x Casos de Uso Hist nco de Mudan a do Caso de Uso Caso Use Submeter Pedido 16 Aplica o Sistema de Vendas G Caso Uso Cancela Pedido 16 Caso Uso Chente E special Ls Caso Uso Procurar Pedido Clg Caso Uso Produto em Oferta ve djs Caso Uso Submeter Pedido de inchi E 4 Extendido Pos OS Cato Uso Verica Pedido 6 Aplica o Sistema de Pagamento h Aplica o Sistema de Cota o de Pedidos com Fomecedores Casos de Uso relacionados por Pr e P s Condi es TIL Caros de Uso cuja pr condi o est relacionada com a p s condi o do Caso Uso Submeter Pedido Clg Caso Use Procurar Pedido 14 Caso Uso Submeter Requisi o de Compra sos Fomecedores 16 Caso Uso Verihcar Pedido Lle Caso Uso Cancelar Pedido Casos de Uso selecionados Edi Remover Titulo Adiciona Caso de Uso Editar Caso de Uso RemoverCasodelso Caso Uso Submeter Pedido Figura 30 Rela es por pr e p s condi es do caso de Uso Submeter Pedido 16 E Casos de Use Afotados pola Re
53. abilidade reduz significativamente o tempo necess rio para a identifica o das liga es se comparado com o m todo manual e M todos de Recupera o de Informa o IR Information Retrieval fornecem um suporte til na identifica o das liga es de rastreabilidade mas n o conseguem identificar todas as liga es existentes A limita o da recupera o da rastreabilidade atrav s de IR que estes m todos n o podem auxiliar na identifica o de todos as 33 liga es corretas for ando o engenheiro de software a analizar e descartar um alto n mero de falso positivos e O m todo incremental de recupera o da rastreabilidade foi identificado como melhor do que o m todo de identifica o em uma nica vez e M todos baseados em IR pode auxiliar na identifica o de problemas de qualidade da descri o textual de artefatos de software Conforme pode ser observado a proposta do trabalho de LUC 2007 bastante similar proposta desta disserta o pois tamb m prop e uma solu o para suportar a evolu o do software A diferen a principal que a solu o apresentada LUC 2007 prop e auxiliar na evolu o do software a partir da rastreabilidade entre todos os artefatos do software tendo o suporte de uma ferramenta de ger ncia de artefatos e um m todo para gera o autom tica das liga es de rastreabilidade Enquanto que o trabalho que est sendo apresentado se prop e a suportar a evolu
54. ado no sistema P s condi o O pedido deve ter sido gravado no sistema e marcado como confirmado Fluxo de Eventos caminho b sico 1 O caso de uso come a quando o cliente seleciona submeter pedido 2 O cliente fornece seu nome e endere o 3 Se o cliente fornece apenas o CEP o sistema coloca automaticamente a cidade e o estado 4 O cliente fornece os c digos do produto 5 O sistema devolve as descri es e o pre o de cada produto 6 O sistema calcular os valores totais para cada produto fornecido 7 O sistema verifica que o pagamento foi efetuado marca o pedido como pendente 8 Inclui caso de uso Efetuar Pagamento com cart o de cr dito 9 Quando o pagamento confirmado o pedido marcado como confirmado e o n mero de pedido NP dado ao cliente Alternativas Alternativa 1 4 Enquanto o cliente quiser pedir itens fa a 1 O chente fornece c digo do produto 2 O sistema fornece a descri o e pre o do produto 3 O sistema atualiza o valor total 5 O sistema verifica que o pagamento foi efetuado marca o pedido como pendente Inclui caso de uso Efetuar Pagamento com cart o de cr dito 113 7 7 6 Quando o pagamento confirmado o pedido marcado como confirmado e o n mero de pedido NP dado ao cliente Requisitos N o Funcionais A qualquer momento antes de submeter o cliente pode selecionar cancelar O pedido n o gravado e o caso de uso term
55. ador Nome do Projeto T tulo da Requisi o de Mudan a e o Verificador b Lista de Requisitos de Aplica o afetados pela mesma Pontos de Extens o Requisitos N o Funcionais Associados l Na remo o o sistema n o deve remover a Requisi o de Mudan a e os relacionamentos com requisitos de aplica o fisicamente do Sistema A remo o deve ser apenas l gica 103 Caso de Uso Adicionar Casos de Usos afetados por Requisi o de Mudan a Objetivo Permitir que o usu rio possa adicionar casos de usos identificados atrav s de uma requisi o de mudan a Atores Engenheiro de Requisitos Pr condi o Usu rio est registrado no Sistema P s condi o de Sucesso Os requisitos de aplica o adicionados por uma Requisi o de Mudan a est o identificados no sistema Passos l O Usu rio seleciona uma Requisi o de Mudan a 2 O usu rio identifica que deve adicionar um caso de uso para atender requisi o de mudan a 3 O Sistema executa o caso de uso Adicionar Caso de Uso 4 O Sistema relaciona o caso de uso adicionado com a requisi o de mudan a indicando que a requisi o de mudan a adiciona o caso de uso 5 O Sistema registra dados do hist rico da mudan a efetuada N mero da Vers o Autor da modifica o usu rio registrado e Data e Hora da modifica o 6 O Sistema repete os passos de 2 a 5 at identificar todos os requisitos de aplica o adicionados pela requisi o de mudan a
56. ados da vers o do requisito e seu estado que indica se o requisito est ativo ou 46 Inativo caso tenha sido removido Existem dois tipos de requisitos de aplica o requisitos funcionais e requisitos nao funcionais representados no modelo pelas classes CasoUso e RegNaoFuncionalGeral respectivamente CasoUso Esta classe cont m os requisitos funcionais da aplica o que s o representados por casos de uso Esta classe deve contem informa es como t tulo do caso de uso a freqii ncia em que ele executado entre outras informa es sobre o mesmo Existem dois tipos de casos de uso no modelo casos de uso normal e caso de uso de extens o representados pelas classes CasoUsoNormal e CasoUsoExtensao Os casos de uso normais podem conter pontos de extens o representados no modelo pela classe PontoExtensao Esta defini o da composi o dos casos de uso baseada no trabalho de SOM 2007 CasoUsoNormal Esta classe representa os casos de uso que n o s o extens o de outro s caso s de uso Um caso de uso normal define o comportamento completo de um caso de uso Sua execu o resulta no atendimento de um objetivo ou em uma situa o de erro CasoUsoExtensao Esta classe representa os casos de uso que extendem outro s caso s de uso Um caso de uso extendido especifica um conjunto de comportamentos que s o desvios com o objetivo de extender o comportamento definido por outros casos de uso O caso de uso
57. as prov veis LAR 2004 2 4 2 Requisitos Funcionais como Casos de Uso Cockburn COC 2005 define que casos de uso representam requisitos que especificam o que o sistema de software deve fazer Por m eles n o s o todos os requisitos j que nao especificam interfaces externas formatos de dados regras de neg cio e f rmulas complexas Ou seja segundo o autor os casos de uso constituem somente uma fra o de todos os requisitos do sistema O trabalho de DUR 1999 prop e uma solu o para o problema da representa o dos requisitos dos clientes de forma que possam ser entendidos tanto pelos engenheiros de software como tamb m por profissionais n o envolvidos com computa o e usu rios finais Para tanto s o apresentados padr es de representa o dos requisitos funcionais e n o funcionais O padr o para requisitos funcionais apresentado est no formato de casos de uso Ou seja os autores consideram casos de uso como forma de descrever de forma padronizada os requisitos funcionais de um sistema Segundo Som SOM 2006 casos de uso que descrevem as poss veis Intera es envolvendo o sistema e seu ambiente v m cada vez mais sendo adotados como meio de elicita o e an lise dos requisitos funcionais Neste trabalho o autor apresenta um m todo suportado por uma ferramenta de engenharia de requisitos baseada em casos de uso O m todo inclui a formaliza o dos casos de uso uma forma restritiva de descri o d
58. as respectivamente pelas classes IntroducaoSRS DescricaoGeral InformacoesSuporte e RequisitoAplicacao Esta defini o da composi o do SRS baseada na representa o do SRS apresentado em CER 2007 IntroducaoSRS A classe IntroducaoSRS representa a se o Introdu o da SRS e cont m informa es que d o uma vis o geral sobre o documento Na SRS esta se o composta de outras cinco subse es Prop sito Escopo Defini es Refer ncias e Vis o Geral representadas respectivamente pelas classes Proposito EscopoSRS Definicoes Referencias e VisaoGeral Proposito A classe Proposito representa a subse o Prop sito da SRS que indica seu objetivo geral Indica tamb m a audi ncia pretendida para a SRS EscopoSRS A classe EscopoSRS representa a subse o Escopo da SRS e descreve os objetivos espec ficos focando no software que est sendo especificado Definicoes A classe Definicoes representa a subse o Defini es Acr nimos e Abreviaturas que cont m as defini es de todos os termos siglas e abreviaturas necess rias para interpretar apropriadamente a SRS Referencias A classe Referencias representa a subse o Refer ncias da SRS que identifica todos os documentos referenciados VisaoGeral A classe VisaoGeral representa a subse o Vis o Geral da SRS que apresenta informa es referentes organiza o do documento DescricaoGeral A classe DescricaoGeral representa a Se
59. asoUsoNormal especifica o do caso de uso que n o extende outros casos de uso e DescricaoCasoUsoExtensao especifica o do caso de uso que extende outros casos de uso DescricaoCasoUsoNormal Classe que representa a especifica o completa t tulo pr condi es p s condi es passos do cen rio principal passos dos cen rios alternativos etc do caso de uso que n o extende nenhum outro caso de uso Esta classe composta pelas seguintes classes PreCondicao PosCondicao Alternativa e PassoCasoUso PreCondicao Esta classe representa o conjunto de pr condi es associadas a um caso de uso PosCondicao Esta classe representa o conjunto de p s condi es associadas a um caso de uso Restricao Esta classe cont m a descri o de uma restri o A restri o formada pelas informa es objeto e estado As pr condi es e p s condi es representadas pelas classes PreCondicao e PosCondicao respectivamente s o tipos de restri es A p s condi o Usu rio est registrado no Sistema mostrada na Figura 1 mostra um exemplo de restri o Neste caso Usu rio o objeto e est registrado no Sistema o estado Alternativa A classe Alternativa representa os cen rios alternativos do caso de uso Uma alternativa especifica uma continua o poss vel do caso de uso ap s a execu o de um passo As alternativas s o usadas para descrever exce es situa es de erro ou cur
60. bem como descri o detalhada de cada uma e Objetivo Esta informa o deve conter o motivo pelo qual o requisito necess rio para atender um objetivo de neg cio DUR 1999 Apesar de n o ser identificada com uma propriedade frequente em templates de casos de uso adotou se esta propriedade como uma informa o adicional que deve auxiliar os stakeholders a compreender o caso de uso e T tulo Cont m o nome do caso de uso Cada caso de uso deve ter um nome nico que sugira o seu objetivo e Atores Consiste na lista de atores que interagem com o caso de uso S o entidades externas usu rios ou outros sistemas que interagem com o caso de uso para atingir um determinado objetivo N o se deve confundir ator com usu rio uma vez que um usu rio pode realizar diferentes pap is no uso de um sistema enquanto que um ator representa apenas um papel e Pr condi es Listagem das condi es que se devem ser atendidas antes de iniciar o caso de uso e P s condi es Descrevem o que deve ser verdadeiro quando da bem sucedida conclus o do caso de uso seja o cen rio principal ou algum outro caminho alternativo E uma garantia de sucesso do caso de uso que deve atender s necessidades de todos os stakeholders e Import ncia Esta propriedade indica o quanto o requisito importante para os 23 TABELA 1 CONTE DO DA ESPECIFICA O DE CASOS DE USO ADAPTADA DE AND 2001 fe A s ice A o S D Fluxo b sico
61. ca Esta classe representa as informa es da Requisi o de Mudan a que devem alterar uma ou mais aplica es de software Esta classe deve conter informa es como qual a origem da requisi o de mudan a a data em que fol submetida a sua descri o o seu objetivo a data em que as mudan as devem ser entregues aos clientes a prioridade de implementa o o t tulo a pessoa que ir 50 verificar se a mudan a foi atendida o autor da requisi o de mudan a entre outras Informa es 4 2 2 Principais caracter sticas do Modelo Conceitual Nesta se o apresentado como o Modelo Conceitual se prop e a atender aos requisitos identificados na se o 4 1 2 Os requisitos da aplica o podem estar relacionados com mais de uma aplica o Isto poss vel atrav s do relacionamento entre as classes Aplicacao e RequisitoA plicacao que determina que uma aplica o pode estar associada com nenhum ou v rios requisitos de aplica o e que os requisitos de aplica o devem estar associados com pelo menos uma aplica o podendo estar associados com mais de uma aplica o A vantagem desta caracter stica que ela permite o reuso dos requisitos Considerando o exemplo de um requisito funcional representado pelo caso de uso Entrar no Sistema demonstrado na Figura 1 da se o 2 4 3 este caso de uso pode estar associado com duas ou mais aplica es que possuam a mesma funcionalidade para registrar os seus usu ri
62. caso de uso e o caso de uso inclu do referenciado no passo SessaoGeneraliza Esta classe representa um passo do caso de uso que generaliza um outro caso de uso Esta classe permite a rela o de generaliza o entre os casos de uso ou seja possibilita representar que um caso de uso generaliza outros casos de uso DescricaoCasoUsoExtensao Esta classe representa a descri o do caso de uso de extens o A descri o do caso de uso de extens o constitu da por um conjunto de partes representadas pela classe Parte Parte Representa uma parte do caso de uso de extens o E nestas partes que se encontram as descri es dos passos do caso de uso representados pela classe PassoCasoUso Cada parte do caso de uso de extens o est relacionada com um ou mais pontos de extens o representados pela classe PontoExtensao CasoUsoExtensao Representa o caso de uso de extens o E constitu do pela descri o do caso de uso de extens o definido pela classe DescricaoCasoUsoExtensao Participante Esta classe representa o sistema ou o ator que interage com os casos de uso Existem dois tipos de participantes Sistema representado pela classe Sistema e Ator representado pela classe Ator Sistema Esta classe representa o pr prio sistema que reage a opera es disparadas pelo ator do caso de uso Ator Esta classe representa os atores do caso de uso Classe que representa as Requisi es de Mudan a RequisicaoMudan
63. cccscsccccsssssssssssssssssssssssesssssssesesssssssssssseseseees 92 AP NDICE II Especifica o dos Casos de uso dos sistemas de exemplo 113 AP NDICE III Telas do Prot tipo ss sseesesscsseoscoscoseossossoseoscoscoscoscoscoseossossoseossossoseosses 120 1 INTRODU O A Engenharia de Requisitos ER uma sub rea da Engenharia de Software estuda o processo de defini o dos requisitos que o software dever atender O processo de defini o de requisitos uma interface entre os desejos e necessidades dos clientes e a posterior implementa o desses requisitos em forma de software A engenharia de requisitos um processo que engloba todas as atividades que contribuem para a produ o de documentos de requisitos e sua manuten o ao longo do tempo A ger ncia de requisitos em processos de manuten o uma atividade que acompanha a evolu o dos requisitos ao longo do ciclo de vida de uma aplica o de software ou produto Os requisitos da aplica o devem ser gerenciados desde seu nascimento e enquanto estiverem presentes na aplica o Frequentemente estas aplica es passam por processos de manuten o que alteram seus requisitos Estas altera es devem ser devidamente registradas na documenta o da aplica o para possibilitar a rastreabilidade e garantir que os requisitos atuais da aplica o estejam atualizados consistentes e dispon veis Organiza es de desenvolvimento de soft
64. cionamento de inclus o entre os casos de uso tamb m auxilia na garantia da consist ncia requisito 3 Por exemplo se uma requisi o de mudan a afeta um caso de uso que inclui outro caso de uso dependendo do tipo de mudan a o analista precisa verificar se a inclus o ainda v lida ou se alguma mudan a deve tamb m ser feita no caso de uso inclu do Tendo o relacionamento devidamente mapeado esta an lise facilitada Esta caracter stica tamb m auxilia no suporte an lise de impacto requisito 1 Mais detalhes podem ser verificados na se o 4 2 2 Regras de consist ncia Representa o da rela o de extens o entre os casos de uso Esta rela o est representada pelo relacionamento entre as classes PontoExtensao do caso de uso extendido e a classe Parte que o conjunto de passos do caso de uso que extende A representa o do relacionamento de extens o entre os casos de uso pelos mesmos motivos que o relacionamento de inclus o auxilia no suporte consist ncia dos casos de uso requisito 3 Esta caracter stica tamb m auxilia no suporte ao requisito 1 Mais detalhes podem ser verificados na se o 4 2 2 Regras de consist ncia Representa o da rela o de generaliza o entre os casos de uso Esta rela o est representada pelo relacionamento entre as classes SessaoGeneraliza que um tipo de passo SessaoGeneraliza a especializa o de PassoSimples com a classe CasoUsoNormal Neste caso
65. d Software Technology v 48 p 43 58 2006 SOME 2007 Som S S Petri Nets Based Formalization of Textual Use Cases School of Information Technology and Engineering University of Ottawa Ontario Canada 2007 Dispon vel em http www site uottawa ca eng school publications techrep 2007 TR 2007 11 pdf Acesso em 26 abr 2008 THA 1990 Thayer R Dorfman M System and Software Requirements Engineering IEEE Computer Society Press Tutorial Los Alamitos 718p 1990 UML 2007 UML OMG Unified Modeling Language OMG UML Superstructure Version 2 1 2 Object Management Group 738p 2007 Dispon vel em http www omg org spec UML 2 1 2 Superstructure PDF Acesso em 20 mar 2008 90 YAU 1978 Yau S S Collofello J S MacGregor T Ripple effect analysis of software maintenance In Compsac IEEE Computer Society Press Los Alamitos CA Proceedings p 60 65 1978 91 AP NDICE I DOCUMENTA O DO PROT TIPO 1 Modelo de Casos de Uso do prot tipo 4 E lt sad nd gt gt lt lt extend gt gt cceriends P i i i i i eeincludes gt F e al a lt include gt gt 4 92 2 Especifica o dos casos de uso do prot tipo Caso de Uso Registrar Usu rio Objetivo Permitir que o usu rio se identifique no sistema Atores Engenheiro de Requisitos Pr condi o P s condi o de Sucesso Usu rio registrado no Sistema Passos l O Usu rio acessa o S
66. de mudan a um determinado requisito surgiu foi removido ou alterado Essa rastreabilidade entre as requisi es de mudan as e os requisitos afetados fornece o hist rico da evolu o da aplica o Este hist rico pode auxiliar por exemplo os stakeholders na identifica o das causas de problemas na aplica o podendo agilizar a sua manuten o Requisito 5 Suporte ao rollback das altera es feitas por uma requisi o de mudan a Uma requisi o de mudan a implementada os requisitos est o atualizados e entregue aos usu rios por m ap s certo per odo verificado que a mudan a deve ser desfeita rollback Considerando os requisitos listados acima as principais prioridades deste trabalho ser encontrar uma solu o para os seguintes requisitos Identifica o dos requisitos afetados requisito 1 manuten o dos requisitos atualizados e consistentes conforme as requisi es de mudan as requisito 3 e manter a rastreabilidade das mudan as dos requisitos de aplica o requisito 4 O requisito 2 que trata do suporte ao gerenciamento da concorr ncia n o ser abordado nesta disserta o por se tratar de um t pico de pesquisa complexo que exige um estudo aprofundado do assunto e n o foi poss vel realiz lo no tempo de desenvolvimento desta disserta o Estes problemas ficam em evid ncia para os analistas durante a fase de manuten o da aplica o que quando na maioria das vezes se de
67. der um dado caso de uso e quais os casos de uso que devem suceder executar ap s o caso de uso Mais detalhes sobre o trabalho SOM 2007 pode ser encontrado na se o 3 1 que descreve os estudos relacionados 26 Larman LAR 2007 descreve os Contratos de Opera o como artefatos relacionados com a an lise orientada a objeto Os contratos de opera o usam pr e p s condi es para descrever modifica es detalhadas em objetos do Modelo de Dom nio como resultado de uma opera o do sistema Segundo o autor as p s condi es descrevem modifica es no estado dos objetos do Modelo de Dom nio Tais modifica es no estado do Modelo do Dom nio incluem inst ncias criadas associa es formadas ou desfeitas e atributos modificados A Figura 1 mostra um exemplo de dois casos de uso que est o relacionados por pr e p s condi es No exemplo a p s condi o do caso de uso Entrar no Sistema pr condi o do caso de uso Submeter Pedido Objetivo Autenticar o usu rio no sistema Entrar no Pr condi o Nenhuma Sistema P s condi o Usu rio est registrado no Sistema Objetivo Permitir que o usu rio submeta um pedido de compra Cliente Submeter e Pedido 4 Pre condi o Usuario esta registrado no Sistema P s condi o O pedido deve ter sido gravado no sistema e marcado como confirmado Figura 1 Exemplo de casos de uso relacionados por pr e p s condi es
68. descri o do requisito n o funcional Subse o Editar Caso de Uso l O usu rio informa o Objetivo T tulo Atores Pr condi o e P s condi es 2 O usu rio informa os passos do cen rio principal e cen rios alternativos 3 O usu rio Informa os requisitos n o funcionais espec ficos associados com o caso de USO Alternativas Alternativa 1 Casos de Uso que precedem o caso de uso 2 O usu rio identifica que existem casos de uso que devem ser executados antes precedem do caso de uso sendo editado 3 O sistema mostra uma lista dos casos de uso das aplica es associadas com o caso de uso sendo editado 98 O usu rio pode selecionar um ou mais casos de uso O sistema salva a rela o de preced ncia entre os casos de uso e volta ao passo 2 da Subse o Editar Caso de Uso Alternativa 2 Adicionar Relacionamento Extens o O Usu rio informa um passo que representa um relacionamento extens o com outro caso de uso O Sistema executa o caso de uso Adicionar Relacionamento Extens o O Sistema volta ao passo 2 da Subse o Editar Caso de Uso Alternativa 3 Remover Relacionamento Extens o O Usu rio solicita remover um passo que representa um relacionamento extens o com outro caso de uso j cadastrado no sistema ou seja existe outro caso de uso que estende o caso de uso sendo editado O Sistema remove o relacionamento extens o entre os casos de uso O Sistema volta ao passo 2 da Subse o Editar Ca
69. do uma requisi o de mudan a cria ou altera um requisito uma nova revis o do requisito gerada e a requisi o de mudan a associada a esta nova revis o conforme mostra a Figura 12 O objeto ReguisitoAplicacaol foi criado pela RequisicaoMudancal e a revis o de numero foi criada Quando o mesmo requisito RequisitoAplicacao foi alterado pela RequisicaoMudanca2 a revis o de numero 2 foi criada O estado do objeto RequisitoAplicacaol associado com a revis o de n mero 1 mantido para hist rico Isto permite que o analista saiba exatamente qual o estado do requisito ap s as modifica es de uma determinada requisi o de mudan a O sistema deve permitir que o analista possa visualizar o estado do requisito em cada revis o Revis o RequisicaoMudancal RequisicaoMudanca RequisitoAplicacaol RequisitoAplicacao Adiciona FequisicaoMudanca RequisicaoMudanca RequisitoAplicacaol RequisitoAplicacao Revis o 2 Figura 12 Versionamento de Requisitos Este recurso de versionamento viabiliza o armazenamento do hist rico da evolu o da aplica o conforme descrito no requisito 4 da se o 4 1 2 Mais detalhes em rela o ao recurso de versionamento ser o fornecidos nos exemplos que demonstram os resultados no pr ximo cap tulo se o 5 3 3 4 3 Considera es finais O requisito 1 que consiste na identifica o dos requisitos afetados por uma requisi o de mudan a foi atendido parcialmen
70. dores z Casos de Uso relacionados pos Pr e P s e Dg Casos de Uso cuja pr condi o eil mao possivel remover o Caso Liso Submeter Pedido porque uma de suas p s condi es pr condi o de outro Caso de Liso 14 Cato Use Procura Pedido 4 Caso Uso Submeter Requisi 6 Caso Uso Verificar Pedido Cg Cato Uso Cancela Pedido Casos de Uso selecionados Editar Remove Titulo Adicionar Caso de Uso Editar Caso de Uzo Remover Cato de Uso Cato Uso Submeter Pedido b Figura 33 Mensagem de erro na remo o do caso de Uso Submeter Pedido 5 3 3 Manter a rastreabilidade das mudan as dos requisitos de aplica o O sistema permite que o analista visualize o hist rico de mudan as de uma aplica o Este hist rico cont m informa es como por quais requisi es de mudan a a aplica o fol afetada mostrando para cada requisi o de mudan a quais os requisitos modificados e de que forma eles foram modificados Nesta se o ser demonstrado como a solu o suporta o requisito 4 78 Na se o 5 3 1 foi demonstrada a adi o dos casos de uso Submeter Proposta Requisi o de Compra e Aceitar Proposta do Fornecedor e Efetuar Compra para atender requisi o de mudan a Adicionar funcionalidades para requisi o e fechamento de compra com fornecedor cen rio 1 Na Figura 34 pode se observar na rvore Hist rico de Mudan a do Caso de Uso o hist rico d
71. e Depend ncias da SRS que define os fatores que afetam os requisitos expressos na SRS como condi es espec ficas de hardware RestricoesGerais A classe RestricoesGerais representa a subse o Restri es Gerais da SRS que fornece uma descri o geral de qualquer outro item que limite as op es dos desenvolvedores como normas reguladoras limites de hardware protocolos etc Para isto o atributo idRestricao foi definido para manter a identifica o da restri o e o atributo descricao para manter sua Informa o RequisitosOperacao A classe RequisitosOperacao representa a subse o Opera o da SRS e descreve todas as opera es normais e ou especiais requisitadas pelo usu rio como rotinas de inicializa o processamento backup s e restaura o 45 4 2 1 2 4 2 1 3 LimitesMemoria A classe LimitesMemoria representa a subse o Limites de Mem ria da SRS que especifica a mem ria interna e externa a ser provavelmente utilizada pelo software DistribuicaoRequisitos A classe DistribuicaoRequisitos representa a subse o Distribui o dos Requisitos na SRS que identifica os requisitos que podem ser adiados at vers es futuras do sistema RequisitosAdaptacao A classe RequisitosAdaptacao representa a subse o Requisitos de Adapta o do Local da SRS que cont m a especifica o das situa es em que o software dever ser adaptado antes da instala o Interface A classe Interface represent
72. e a como manter a rastreabilidade das mudan as dos requisitos de aplica o definidos na se o se o 4 1 2 deste trabalho Embora n o tenham sido apresentados todos os exemplos poss veis da aplica o do modelo proposto neste trabalho os apresentados contribu ram facilitando a visualiza o da proposta e comprovando seu funcionamento diante dos objetivos inicialmente propostos Mais Ilustra es de telas do prot tipo podem ser observadas no Ap ndice III O pr ximo cap tulo apresenta as considera es finais obtidas com o desenvolvimento desta disserta o 83 6 CONSIDERA ES FINAIS 7 A engenharia de requisitos uma das atividades cr ticas e mais importantes do processo de desenvolvimento de software visto que a partir dela que o sistema final sera desenvolvido Atualmente tida como um dos principais desafios na engenharia de software e como a principal raz o de muitas das falhas ocorridas nos sistemas A manuten o e evolu o do software caracterizam se por demandarem custo muito alto das organiza es Se na fase de evolu o do software os requisitos n o forem eficientemente gerenciados muito tempo pode ser demandado para a manuten o e no pior caso Informa es sobre funcionalidades Importantes do sistema podem ser perdidas Neste contexto o tema abordado nesta disserta o busca auxiliar a atividade de ger ncia dos requisitos durante a evolu o do sistema de software atrav
73. e identificar que o caso de uso Aceitar Proposta do Fornecedor e Efetuar Compra pode sofrer uma altera o Sendo que o caso de uso Aceitar Proposta do Fornecedor e Efetuar Compra est relacionado com o caso de uso Submeter Proposta Requisi o de Compra ver Figura 24 existe grande 15 probabilidade da altera o tamb m afetar este caso de uso Ambos os casos de uso manipulam o mesmo objeto proposta que alvo da requisi o de mudan a recebida 5 3 2 Manuten o dos requisitos atualizados e consistentes conforme as requisi es de mudan as Como ja foi demonstrado nos exemplos ilustrados na se o anterior como o sistema mant m os requisitos atualizados de acordo com as requisi es de mudan as nesta se o se dar enfoque a como o sistema mant m a consist ncia destes requisitos requisito 3 Este trabalho se prop e a suportar a consist ncia respeitando as regras apresentadas na se o 4 2 2 Para exemplificar a regra de consist ncia 1 que descreve que o sistema n o deve permitir a remo o da p s condi o de um caso de uso que est associada com a pr condicao de outro caso de uso seguem as Figuras 30 31 e 32 Conforme mostra a Figura 30 a p s condi o do caso de uso Submeter Pedido pr condi o dos casos de uso Procurar Pedido Submeter Requisi o de Compra aos Fornecedores Verificar Pedido e Cancelar Pedido Se o analista receber um
74. ecionado Aceitar Proposta do Fornecedor e Efetuar Compra A nica requisi o de mudan a que afetou este caso de uso foi a requisi o de mudan a Adicionar funcionalidades para requisi o e fechamento de compra com fornecedor Abaixo da requisi o de mudan a o sistema mostra os outros casos de uso 70 afetados pela mesma Neste caso a requisi o de mudan a tamb m afetou o caso de uso Submeter Proposta Requisi o de Compra I x Adicionar Caso deo Jog Aplica o Sistema de Cota o de Pedidos com Fomecedores aE Objetivo Funcion rio aceita proposta do fomecedor e efetua a compra Titulo Processar Proposta Atores Funcion rio Pr condi es Identificar Pr Condi es Objeto Estado Proposta for submetida ao funcion rio P sCondi es Identifica P sCond es Objeto Estado Compra eletuada Importancia Comentaros Frequencia L Cen rio Principal Adicionar Cen rio Principal Cen rios Altemativos Adicionar Cen rios Altemativos Requisitos N o Funcionais Requisitos N o Funcionais Salvar Caso de Uso Figura 22 Adi o do caso de uso Aceitar Proposta do Fornecedor e Efetuar Compra Cen rio 2 Outro cen rio para demonstrar como a proposta suporta a identifica o dos requisitos afetados por uma requisi o de mudan a ilustrado nas Figuras 26 27 e 28 Digamos que o analista receba uma requisi o de mudan a descrevendo que o usu rio do Siste
75. eeereerereaaererernada 56 Figura 9 Remo o do passo de um caso de uso relacionado por Inclus o c ii ieeeeerrereeanea 56 Figura 10 Remo o de um caso de uso relacionado por Extens o ceccccceeesssceceeseseceeeeeseeceeeeesnaeeceeseseeeeeeeseaaes 57 Figura 11 Remo o de um caso de uso relacionado por Generaliza o ccccceecesseeeceeseneceeeeesneeceeeeseeeeeeeeeaees 58 Figura 12 Versionamento de Requisitos sacas a dO da aan ba a 59 Peura Se Sistema de Vendas ereenn E da qua E oo 62 Figura 14 Sistema de Pagamento sisese a a Ud TAS DSO a 63 Figura 15 sistema d Compra de FOMECEd TES assa aisia e E ds qa A UE cada RU aan E 64 Figura 16 Rel c es entre OS SISICMAS naea e ips ia a a aa ad O a 65 Figura 23 Identifica o da pr condi o do caso de uso Aceitar Proposta do Fornecedor e Efetuar Compra 72 Figura 24 Casos de Uso Adicionados pela Requisi o de Mudanga ccccsssccceesesnceeceeseneeeeeeeseeeceesesaeeceeeeeeaes T2 Figura 25 Casos de Uso afetados pela Requisi o de Mudan a Adicionar funcionalidades para requisi o e techamento de compra com fomEcedor wasran a a e a a a A 71 Figura 26 Requisi o de Mudan a Usu rio n o precisa estar autenticado no sistema para submiss o de pedido ia nad r a honey he di AR a A a RA DR o O Ameer dE meee 2 Figura 27 Requisi o de Mudan a Usu rio n o precisa estar autenticado no sistema para submiss o de PE a A a O
76. egistrado no Sistema P s condi o de Sucesso Os requisitos de aplica o n o funcional geral adicionados por uma Requisi o de Mudan a est o identificados no sistema Passos l O Usu rio seleciona uma Requisi o de Mudan a 2 O Usu rio identifica que deve adicionar um requisito n o funcional geral para atender a requisi o de mudan a 3 O Sistema executa o caso de uso Adicionar Requisito N o Funcional Geral 4 O Sistema relaciona o requisito n o funcional geral adicionado com a requisi o de mudan a indicando que a requisi o de mudan a adiciona o requisito 5 O Sistema registra dados do hist rico da mudan a efetuada N mero da Vers o Autor da modifica o usu rio registrado e Data e Hora da modifica o 6 O Sistema repete os passos de 2 a 5 at identificar todos os requisitos n o funcional geral adicionados pela requisi o de mudan a Alternativas Pontos de Extens o Requisitos N o Funcionais Associados Caso de Uso Editar Requisitos N o Funcional Geral afetados por Requisi o de Mudan a Objetivo Permitir que o usu rio possa alterar requisitos n o funcional geral afetados por uma requisi o de mudan a Atores Engenheiro de Requisitos Pr condi o Usu rio est registrado no Sistema 107 P s condi o de Sucesso Os requisitos de aplica o n o funcional geral alterados por uma Requisi o de Mudan a est o identificados no sistema Passos e O Usu
77. ento Generaliza o O Usu rio remove um passo que representa um relacionamento de generaliza o com outro caso de uso j cadastrado no sistema ou seja existe outro caso de uso que a especializa o caso de uso filho do caso de uso sendo adicionado O Sistema registra a remo o do relacionamento generaliza o entre os casos de uso O Sistema volta ao passo 2 da Subse o Editar Caso de Uso Alternativa 9 Casos de Uso que procedem o caso de uso sendo adicionado O Usu rio informa um passo que representa um habilitador de outros casos de uso ou seja outros casos de uso s o habilitados pelo caso de uso sendo adicionado O sistema mostra uma lista dos casos de uso das aplica es associadas com o caso de uso sendo editado O usu rio pode selecionar um ou mais casos de uso O sistema salva a rela o de proced ncia entre os casos de uso e volta ao passo 2 da Subse o Editar Caso de Uso Alternativa 10 Casos de Uso que procedem ao caso de uso sendo adicionado O Usu rio remove um passo que representa um habilitador de outros casos de uso ou seja outros casos de uso s o habilitados pelo caso de uso sendo adicionado O Sistema registra a remo o do relacionamento de proced ncia entre os casos de uso e volta ao passo 2 da Subse o Editar Caso de Uso 100 Pontos de Extens o Requisitos N o Funcionais Associados Caso de Uso Remover Requisito de Aplica o Objetivo Permitir que o usu rio possa re
78. er Requisi o de Compra aos Fomecedores Aphca o Sistema de Vendas Jd Aphca o Sistema de Pagamento e Caso Uso quente com cart o de cr dito nie Cas q Ligo Tr per J Generalza Jg Caso Uso cio com cart o de cr dio Catos de Uso relacionados por Pr e P s Condi es 3 J Casos de Uso cuja p s condi o est relacionada com pr condi o do Caso Uso Submeter Requisi o de Compra aos Fornecedores Cla Caso Uso Submeter Pedido Casos de Uso selecionados Etar Titulo Adoiona Caso de Uso Edita Caso de Uso Caso de Uso Remover Caso de Uso Cano de Uso Caso Uso Submeter Requisi o de Compr E Figura 18 Representa o do relacionamento de Generaliza o rvore Hist rico de Mudan a do Caso de Uso O objetivo desta rvore mostrar ao analista o hist rico de modifica o de uma aplica o ou de um caso de uso selecionado Ent o quando uma aplica o ou um caso de uso da rvore Aplica o x Casos de Uso selecionado o seu hist rico de mudan as mostrado na rvore Hist rico de Mudan a do Caso de Uso O primeiro n vel desta rvore cont m a lista das requisi es de mudan as que afetaram a aplica o ou o caso de uso O segundo n vel cont m a lista dos casos de uso exceto o caso de uso selecionado afetados por cada requisi o de mudan a Para cada caso 67 de uso selecionado na rvore Hist rico de Mudan a do
79. ernativa 3 Pagamento em dinheiro 1 Usu rio seleciona Pagamento em Dinheiro passo 3 2 Funcionario informa a quantia 3 Sistema imprime comprovante de pagamento 4 Caso de uso termina Verificar Cadastro do Cliente no SPC Objetivo Verificar se o cliente est no SPC Atores Pr condi es P s condi es Fluxo de Eventos caminho b sico 1 Sistema verifica se cliente possui cadastro no SPC 2 Sistema informa que cliente n o possui cadastro Alternativas 118 Alternativa 1 2 Sistema Informa que cliente possui cadastro no SPC e mostra o valor da d vida Criar Credi rio para Cliente Objetivo Criar credi rio para cliente Atores Funcion rio Pr condi es P s condi es Credi rio criado Fluxo de Eventos caminho b sico 1 Usuario solicita cria o de credi rio para o cliente 2 Incluir Verificar Cadastro do Cliente no SPC 119 AP NDICE III TELAS DO PROT TIPO 1 Tela para adi o do Caso de Uso Submeter Pedido Adicionar Caso de Usc _ Efe x Sistema de Vendas Pesmitir que o usu rio submeta um pedido de compra Submeter Pedido Requisitos N o Funcionais Adicionar Requisitos N o Salvar Caso de Uso 2 Telas para defini o do cen rio principal do Caso de Uso Submeter Pedido Can rio Principal Joe Descri o do Passo O sistema devol
80. est registrado no Sistema P s condi o de Sucesso Requisi o de mudan a cadastrada e os requisitos de aplica o afetados pela mesma est o identificados no sistema Passos l O usu rio acessa a funcionalidade de cadastro de Requisi es de Mudan as 2 O sistema disponibiliza as fun es Adiciona Altera ou Remove 3 O usu rio solicita a adi o de uma Requisi o de Mudan a 4 O sistema requisita as seguintes Informa es Origem da Mudan a Descri o Tipo de Mudan a Data de Entrega Planejada Prioridade de Implementa o Implementador Gerador Prioridade do Gerador Nome do Projeto T tulo da Requisi o de Mudan a e o Verificador 5 O usu rio informa os dados e solicita salv los 6 O Sistema salva a requisi o de mudan a e informa es como Data de Submiss o Data e Hora da Atualiza o Nome do Autor e N mero da Vers o da modifica o Alternativas Alterntativa 1 Edi o oe 4 O usu rio solicita a edi o de uma Requisi o de Mudan a O sistema permite que o usu rio modifique as seguintes informa es Origem da Mudan a Descri o Tipo de Mudan a Data de Entrega Planejada Prioridade de Implementa o Implementador Prioridade do Gerador Nome do Projeto T tulo da Requisi o de Mudan a e o Verificador O usu rio informa os dados e solicita salv los O Sistema registra dados do hist rico da mudan a efetuada N mero da Vers o Autor da edi
81. et foi a linguagem de implementa o utilizada para as camadas de dados controle e interface J para a camada de persist ncia que d suporte a camada de dados foi utilizado o banco de dados Microsoft Access Estas escolhas foram feitas por sua grande utiliza o tanto no meio acad mico como no meio industrial por experi ncias de sucesso alcan adas anteriormente pela disponibilidade das ferramentas e tamb m pela facilidade de integra o entre o banco de dados e a linguagem definida Os documentos do prot tipo criados Modelo de Casos de Uso Especifica o dos Casos de Uso e Diagrama de Classes podem ser encontrados no Ap ndice I 5 2 Descri o dos sistemas utilizados para exemplifica o Com o prop sito de avalia o da solu o apresentada neste trabalho atrav s do prot tipo definiu se um exemplo hipot tico envolvendo tr s sistemas Segue a descri o do que se tratam estes sistemas para melhor compreens o dos resultados que ser o apresentados na posterior se o 5 3 61 5 2 1 Sistema de Vendas Este sistema tem como objetivo possibilitar a venda online de produtos de uma empresa O sistema realiza o atendimento ao cliente permitindo que o mesmo selecione os produtos e solicite compr los Para solicitar a compra dos produtos o cliente deve informar o c digo de cada produto Quando informado o c digo o sistema verifica se o produto n o est em oferta e caso esteja o sistema calcula o desconto no
82. etadas devem ser atualizados nos SRSs de cada aplica o A n o atualiza o acarreta numa desatualiza o e inconsist ncia dos dados que pode ter consequ ncias como falha na an lise de impacto falha no 39 entendimento dos requisitos por parte da equipe de desenvolvedores e testadores entre outros problemas N o se sabe por que estes requisitos de aplica o n o foram atualizados j que uma preocupa o apontada pela pr pria equipe Uma hip tese de prov vel causa o fato de n o haver uma ferramenta conhecida pela equipe que auxilie no processo de atualiza o destes requisitos A equipe utiliza o editor de texto Microsoft Word para escrita e atualiza o de requisitos Conforme relatado pela equipe e constatado na an lise por n o existir ferramenta apropriada para atualiza o dos requisitos de aplica o ao longo do ciclo de vida da mesma principalmente na fase de manuten o a tarefa de manter os requisitos de aplica o atualizados torna se bastante penosa e por consegii ncia deixada de lado na maioria dos Casos 4 1 2 Identifica o dos principais requisitos para resolver o problema O problema que motivou este trabalho est relacionado com a dificuldade de manter a documenta o de requisitos de aplica o atualizados ao longo do seu ciclo de vida De acordo com o caso pr tico descrito os seguintes requisitos para a solu o se destacam por descreverem as principais caracter sticas q
83. fetuar mudan as baixo Descontinua o Esta fase se d quando nenhum servi o de manuten o fase de Servi o necess rio mas a aplica o ainda est em produ o Os usu rios precisam conviver com defici ncias e limita es conhecidas T rmino Na fase de t rmino o software desativado e os seus usu rios s o direcionados a outro software substituto As fases de Evolu o e Servi o que est o destacadas na Figura 2 s o foco principal deste trabalho Em ambas as fases a mudan a da aplica o a opera o principal com a nica diferen a que na fase de Evolu o as mudan as tendem a ser mais complexas do que na de Servi o 2 5 2 Ciclo de Vida de Mudan a Em BEN 2000 tamb m apresentado o Ciclo de Vida de Mudan a conforme Ilustrado na Figura 3 com as seguintes etapas e Requisi o de mudan a Na maioria das vezes originada dos usu rios do sistema e pode ter a forma de um relato de um problema bug ou a requisi o por uma funcionalidade nova Normalmente expressa em termos que representam conceitos do dom nio da aplica o por exemplo Adicione uma nova funcionalidade ao sistema de registro do estudante em cursos que impe a estudantes cujo registro esteja no estado retido n o possam se registrar 7 e Planejamento da mudan a Esta atividade compreendida por duas sub atividades s o elas o Compreens o do software A compreens o do software um pr requ
84. fornecedores 3 O usuario seleciona os fornecedores para os quais deseja submeter a requisi o de compra 4 O sistema submete a requisi o para os fornecedores proverem suas cota es Caso de Uso Aceitar Proposta do Fornecedor e Efetuar Compra Objetivo Funcion rio aceita proposta do fornecedor e efetua a compra Atores Funcion rio Pr condi o Proposta do fornecedor foi submetida Rela o com Pos condi o do caso de uso Submeter Proposta para Requisi o de Compra P s condi o Compra efetuada Fluxo de Eventos caminho b sico 1 O caso de uso come a quando o funcion rio recebe e aceita uma proposta do fornecedor 2 O funcion rio solicita ao sistema para efetuar a compra Inclui caso de uso Efetuar Pagamento com cart o de cr dito 3 Quando o pagamento confirmado o sistema confirma a compra Caso de Uso Submeter Proposta Requisi o de Compra Objetivo Fornecedor submete proposta para atender requisi o de compra Atores Fornecedor Pr condi es Requisi o de compra foi submetida pelo funcion rio P s condi es Proposta foi submetida ao funcion rio Fluxo de Eventos caminho b sico 1 O caso de uso come a quando o fornecedor recebe uma requisi o de compra do funcion rio da empresa 2 O fornecedor informa uma proposta para a requisi o de compra 3 O sistema submete a proposta ao funcion rio Alternativas Alternativa 1 2 O fornecedor n o tem
85. i snida 29 2 6 Consideracoes do Capo spaces grana e piada aa dE Da cata da 31 3 ESTUDOS REEACIONADOS sara aii E uia 32 T GON OOO T E TO ee 32 3 2 LUCIA FASANO OLIVETO e TORTORA 2007 eee erre 33 3 3 NOLLEBEOIS 2 OO ria E EE 34 3 4 MOHAN XU CAG RAMESH OS ae E accede 35 3 5 CONSideracOes do Capitulo area E E T aah 35 4 MODELO PROPOSTO sap pas Ta TS Di aaa 37 4 1 Descni ao do Prope ie os secre ees Grier esac SL Sa DRE Sd 37 4 1 1 Estudo de caso Cxploratorid cccccssssssssssssssssscscscscscscscscscscscscososososososososooes 37 4 1 2 Identifica o dos principais requisitos para resolver o problema 40 4 2 RODO CA quartos in rod rd a a Da eens i Ri a o esas ieee 4 4 2 1 Detalhes do Modelo Conceitual cccccccsssssssssssssscssssscccccccccsscssssssssssssssscecs 44 4 2 2 Principais caracter sticas do Modelo Conceitual sssssssssssssssssssesesecessssecee 51 4 2 3 Regras de conSISLencia salas srtaransinecaninesinaTo nda ve dloio deegoasandadEi sue ssa Decon iaoea 54 4 2 4 Versionamento dos FECUISITOS ccccccccccsssssscccccccccssssssscccccccccssscsccccscssssssescecs 58 4 3 Considera es FINAIS esas pec cntyeaette senegal ede Rain E 59 S AVALIA O DO MODELO PROPOSTO eeeeoooococscssssssssccecececcecoscssossssesececccecesoo 61 5 1 POOU memantine ias E I Cd ere eer 61 5 2 Descri o dos sistemas utilizados para exemplifica o ceeececceceeceeseeeeeeeeeeeeees
86. ica es descritas na se o 5 2 Sistema de Vendas Sistema de Pagamento e Sistema de Cota o de Pedidos com Fornecedores est o cadastradas no sistema No segundo n vel da rvore est o os casos de uso pertencentes a cada aplica o Para cada caso de uso listado o sistema gera tr s sub arvores com os casos de uso Inclu dos sub rvore Inclui 66 que extendem sub rvore Extendido Por ou que s o generalizados sub rvore Generaliza pelo caso de uso No caso da aplica o Sistema de Cota o de Pedidos com Fornecedores apenas o caso de uso Submeter Requisi o de Compra aos Fornecedores est cadastrado Pode se observar que o caso de uso Submeter Requisi o de Compra aos Fornecedores possui uma sub rvore Inclui que mostra o caso de uso inclu do Procurar Pedido Figura 20 Os outros casos desta aplica o ser o adicionados pela requisi o de mudan a cadastrada na Figura 17 As Figuras 21 e 22 mostram os casos de uso sendo adicionados As Figuras 18 e 19 mostram exemplos de sub rvores Extendido Por Generaliza estas sub rvores s s o mostradas quando o caso de uso possui os respectivos relacionamentos E l j Casos de Uso Afetados pela Requisi o de Mudan a Jos Identhea o dos Casos de Uso Aletados Casos de Uso letados pela Requisi o de Mudan a Aplica o x Casos de Uso Hist rico de Mudan a do Caso de Uso Caso Uso Submet
87. icionar funcionalidades para requisi o e fechamento de compri e 6 Aplica o Sistema de Pagamento 10 Caso User Submeter Proposta Requisi o de Compra 1 Aplica o Sistema de Cota o de Pedidos com Fomecedones FIR Caso Use Processar Proposta ij e D Inchi Jg Caso Uso Pagamento com cart o de cr dito Jd Caso Uso Submeter Proposta Requin o de Compra Jg Caso Uso Submeter Requisi o de Compra aos Fomecedores DD Inclui 4 Caso Use Procurar Pedido Caros de Uso relacionados por Pr e P s Condi es a 4 Casos de Uso cus p r condi o est relacionada com a pr condi o do Cato Uso Processat Proposta Ji Caso Uso Submeter Proposta Requia o de Compra Edita Remover o Edta Cano de Uso J Remover Caso de Uso Caso Uso Submeter Proposta Requisi z Edhar Caso de Uso Remover Caso de Uso Caso Uso Submeter Proposta Requisi Edhar Caso de Uso Remover Caso de Uso Caso Uso Processar Proposta a E eee i Figura 24 Casos de Uso Adicionados pela Requisi o de Mudan a 72 ma i Pe E E zarae e ga oe E a hee TEN 505 O Jo Afetados p a Regu Di danca Identifica o das Casos de Uso Aletados Casos de Uso Aletados pela Requisi o de Mudan a Casos de Uso Afetados por esta Requis o de Mudan a Adicionar funcionalidades para requisi o e fechamento de compra com fomecedos ae Submeter Proposta Requisi o de Compra
88. ina No passo 7 se alguma informa o estiver incorreta o sistema pede ao cliente para corrigir a Informa o Caso de Uso Cliente Especial Objetivo Calcular valor total das compras do cliente especial baseado no desconto Estende 1 Submeter Pedido antes do passo 6 Fluxo de Eventos Prim rio caminho b sico 1 O sistema procura o valor do desconto para o cliente 2 O sistema mostra o desconto ao cliente 3 O sistema atualiza o total subtraindo o valor do desconto Pr condi o Cliente ser Cliente Especial P s condi o Valor do desconto total calculado e subtra do do total de compras Caso de Uso Produto em Oferta Objetivo Fornecer valor de produto em oferta Estende 1 Submeter Pedido antes do passo 5 Fluxo de Eventos Prim rio caminho b sico 1 O sistema procura o valor do desconto para o produto 2 O sistema mostra o desconto do produto ao usu rio 3 O sistema calcula o valor do desconto 4 O sistema atualiza o total subtraindo o valor do desconto Pr condi o Produto estar em oferta P s condi o Valor do desconto calculado Caso de Uso Verificar Pedido Objetivo Verificar os dados da situa o do pedido Atores Cliente Funcion rio Fluxo de Eventos Prim rio caminho b sico 1 O caso de uso come a quando o cliente seleciona Meu pedido 2 Usa Procurar Pedido 3 O Sistema mostra os dados da situa o do pedido e o caso de uso termina Fluxo de Secund rio caminho alternativo
89. informar os dados do cart o de cr dito do cliente O sistema verifica o cr dito do cliente e em caso positivo efetua o pagamento e Com cheque Neste caso o cliente deve informar os dados do cheque O sistema verifica o cr dito do cliente junto ao SPC e em caso positivo efetua o pagamento e Em dinheiro O sistema solicita que o funcion rio informe a quantia recebida em dinheiro O sistema efetua o pagamento A Figura 14 ilustra o modelo de casos de uso deste sistema A especifica o de cada caso de uso pode ser encontrada no Ap ndice II deste trabalho Cliente Efetuar Pagamento i Efetuar _ pe Pagamento Funciona Efetuar em Dinheiro Efetuar Pagamento com Cheque Pagamento com Cart o de Cr dito lt lt include gt _ Cadastro do Criar Credi rio ss Cliente no SPC para Cliente Figura 14 Sistema de Pagamento 5 2 3 Sistema de Compra de Fornecedores Este um sistema online cujo objetivo permitir que o funcion rio da empresa submeta requisi es de compra aos seus fornecedores a fim de atender aos pedidos dos seus 63 clientes O sistema permite que os fornecedores informem suas cota es de pre os de produtos e ent o submetam propostas que atendam as requisi es de compra enviadas pela empresa O funcion rio da empresa pode ent o aceitar a proposta enviada pelo fornecedor e enfim efetuar a compra do mesmo A Figura 15 ilustra o modelo de casos
90. io O modelo de casos de uso descreve na totalidade o comportamento funcional do sistema LEF 2000 De acordo com a especifica o UML OMG 01 um caso de uso consiste na especifica o de uma seqii ncia de a es incluindo varia es que o sistema pode executar interagindo com atores do sistema Um caso de uso descreve uma por o do comportamento do sistema sem revelar a estrutura interna do sistema Sendo assim casos de uso s o teis para a captura e documenta o de requisitos externos Eles tamb m s o ideais para a valida o de requisitos atrav s de prot tipos V rios processos de desenvolvimento de sistemas de software incluindo o M todo Unificado de Desenvolvimento de Software Unified Software 22 Development Process recomendam a utiliza o de casos de uso para a documenta o dos requisitos dos usu rios SOM 2006 2 4 1 Especifica o de Casos de Uso Um padr o de especifica o de casos de uso recomendado porque uma estrutura pr definida auxilia aos engenheiros de requisitos a identificarem e incluirem importantes elementos em cada caso de uso JAC 1998 Existem diferentes padr es e guias para a especifica o de requisitos na literatura Exemplos podem ser encontrados em JAC 1998 COC 2001 SCH 1998 KRU 2000 e LEF 2000 O conte do encontrado com mais frequ ncia mostrado na Tabela 1 Seguem abaixo as propriedades dos casos de uso que ser o adotadas neste trabalho
91. ise de ferramentas de ger ncia de requisitos existentes no mercado Em BEL 2007 a autora realizou um estudo comparativo das ferramentas de ger ncia de requisitos existentes no mercado com o objetivo de analisar como as mesmas suportam o gerenciamento dos requisitos ao longo do ciclo de vida das aplica es Segue uma breve descri o dos resultados deste estudo Primeiramente gerou se uma lista dos requisitos que uma ferramenta de ger ncia de requisitos deve atender para resolver o problema foco deste trabalho Considerando estes requisitos fez se uma an lise de tr s ferramentas do mercado ReguisitePro Compuware Optimal Trace Enterprise e DOORS A conclus o do estudo mostrou que nenhuma das tr s ferramentas atendem os seguintes requisitos e Gerenciamento de mudan as A ferramenta deve fornecer a possibilidade de manipula o de CRs Change Requests Requisi es de Mudan a formais A ferramenta deve armazenar a informa o de quais os requisitos foram afetados pela requisi o de mudan a e de que forma estes requisitos foram afetados adicionados removidos ou alterados e Gerenciamento dos requisitos da aplica o as ferramentas analisadas s o orientadas a projeto Habilidade de manter requisitos de aplica o atrav s dos projetos de manuten o Habilidade de ligar requisitos de aplica o com requisi es de mudan as atrav s de rela es como Adicionar Alterar Remover Habilidade de atualizar os requ
92. isi o de mudan a e salv la o analista deve identificar os requisitos de aplica o que a requisi o de mudan a modifica Para esta identifica o o sistema fornece as op es para identificar os casos de uso afetados atrav s do bot o Identificar Casos de Uso Afetados e identificar os requisitos n o funcionais afetados atrav s do bot o Identificar Requisitos N o Funcionais Geral Afetados Como esta requisi o de mudan a se trata da adi o de novas funcionalidades neste exemplo o analista deve selecionar a op o Identificar Casos de Uso Afetados a7 Adicionar Requisi o de Mudanca Mix Ongem da Mudan a Requisn o de Mudan a dos usu rios do sistema T itula Adicionar funcionalidades para requisa o fechamento de compra com fomecedor Descri o Projeto Manuten o Sistema de Cota o de Pedidos com Fomecedores Venhcador Luciana Beleza Salva identica Casos de UsoAfetados Identificar Requistos N o Funcionais Geral Afetados Requisi o de Mudan a salva com sucesso Figura 177 Cadastro da Requisi o de Mudan a Quando o analista seleciona a op o de identifica o dos casos de uso afetados o sistema mostra uma tela com as seguintes informa es rvore Aplica o x Casos de Uso O primeiro n vel de elementos desta rvore cont m lista de todas as aplica es cadastradas nos sistema Conforme pode ser observado na Figura 18 as apl
93. isito para a mudan a e tem sido t pico de diversas pesquisas Relatos mostram que esta fase consome mais do que a metade dos recursos de manuten o FJE 1982 Uma substancial parte da compreens o do software a localiza o dos conceitos do dom nio da aplica o no c digo Como no exemplo do registro do estudante em cursos encontrar onde no c digo se encontra o registro de estudante em cursos 29 o An lise de impacto da mudan a a atividade pela qual os respons veis pela aplica o avaliam a extens o da mudan a isto identificam os componentes que ser o afetados pela mudan a A an lise de impacto indica quanto custosa ser a mudan a a fim de indicar a viabilidade da mesma Implementa o da mudan a Consiste na implementa o da mudan a nos componentes de software identificados previamente Pode acontecer de ap s modificar um determinado componente este n o se relacionar mais adequadamente com outros componentes ent o estes outros componentes tamb m devem ser alterados Isso se chama propaga o da mudan a YAU 1978 RAJ 2000 Verifica o e valida o da mudan a Consiste na verifica o se a requisi o de mudan a foi atendida como esperado Re documenta o Atualiza o da documenta o do software Se n o existe documenta o do software ou se ela incompleta o fim do ciclo de mudan a o momento de registrar a compreens o adquirida durante a mudan a Considerando o alto
94. isitos de aplica o de forma autom tica quando a implementa o da requisi o de mudan a entregue ao cliente da aplica o Habilidade de exportar um documento de requisitos da aplica o e Hist rico de cada requisito da aplica o apresenta informa o sobre qual projeto ou requisi o de mudan a o requisito foi criado modificado removido quais foram os autores das modifica es em que data as modifica es ocorreram A partir desta an lise pode se observar dois problemas cr ticos e As ferramentas n o est o preparadas para suportar os requisitos das aplica es ao longo da sua evolu o Uma vez que elas s o orientadas a projeto os requisitos 15 existem apenas enquanto o projeto estiver ativo Uma vez que o projeto termine os requisitos tamb m deixam de existir Portanto para manter os requisitos das aplica es mesmo ap s o t rmino do projeto necess rio se efetuar uma c pia dos requisitos gerados ou atualizados pelo projeto Este tipo de procedimento n o garante a consist ncia e atualiza o dos requisitos necess rio que se mantenha um reposit rio centralizados com os requisitos da aplica o e As ferramentas n o suportam as requisi es de mudan as crucial que se tenha o hist rico dos requisitos da aplica o desde sua origem at o atual momento Muitas vezes uma requisi o de mudan a afeta mais de um requisito importante que a ferramenta ligue a requisi o de
95. istema 2 O Sistema requisita que o usu rio informe o nome do usu rio 3 O usu rio informa seu nome 4 O Sistema registra o Usu rio no Sistema Alternativas Pontos de Extens o Requisitos N o Funcionais Associados Caso de Uso Gerenciar Aplica o Objetivo Permitir que o usu rio possa adicionar consultar editar e remover aplica es do sistema Atores Engenheiro de Requisitos Pr condi o Usu rio est registrado no Sistema P s condi o de Sucesso Aplica o foi adicionada editada ou removida Passos l O usu rio acessa a funcionalidade de cadastro de aplica o 2 O sistema disponibiliza as fun es Adiciona Edita Remove ou Consulta 3 O usu rio solicita a adi o de uma Aplica o 4 O sistema requisita as seguintes informa es para cadastro da nova aplica o Nome Descri o 5 O usu rio informa as informa es e solicita salv las 6 O sistema salva as informa es 7 O Sistema registra dados do hist rico da mudan a efetuada N mero da Vers o Autor da adi o usu rio registrado e Data e Hora da adi o Alternativas 93 Alternativa 1 Edi o 3 O Usu rio solicita a edi o de uma Aplica o 4 O Sistema mostra a lista de aplica es existentes 5 O Usu rio escolhe uma aplica o e altera o Nome ou a Descri o 6 O Sistema salva as informa es 7 O Sistema registra dados do hist rico da mudan a efetuada N mero da Vers o Autor da edi
96. itaRelacionamentoEensaD wid aiii Controke armel Ph A plc aca Pa FS ao Adicssa no asoliso void E EdityCasolhro nbs RemeCapoLIso void i Adiciona olacionamentho aposUso void ce A Remimeelscionamento Casos inn void sf EdtaRelacignameninEtercant void Fa Homa ir Gescricad ir sad al CORT CH Oe ee i s ca es rahi vos E Dataviergao inl daiceviars o i int FielarionaAplicacaohequiniolglicaradd S Lista Cases soP onglicacacd void Aon BA pi demo woid Perrier plic mt ace oad Editadplca o woid ContuRadphe acao chir BabraHistoricoAplica a o void AP NDICE II ESPECIFICA O DOS CASOS DE USO DOS SISTEMAS DE EXEMPLO 1 Sistema de Vendas Caso de Uso Entrar no Sistema Objetivo Autenticar o usu rio no sistema Atores Cliente Pr condi o P s condi o Usu rio est autenticado no sistema Fluxo de Eventos caminho b sico 1 O caso de uso come a quando o cliente entra no sistema 2 O sistema requisita que o usu rio informe o login e a senha 3 O usu rio informa os dados 4 O sistema autentica o usu rio e redireciona para a p gina principal do sistema Alternativas Alternativa 1 4 O sistema informa ao usu rio que o login ou a senha s o inv lidos Caso de Uso Submeter Pedido Objetivo Permitir que o usu rio submeta um pedido de compra Atores Clente Pr condi o Usu rio est autentic
97. lista complemente a defini o do Estado com algum coment rio ou defini o que julgue necess rio Este relacionamento por pr e p s condi es auxilia no suporte consist ncia requisito 3 e na an lise do impacto das requisi es de mudan as requisito 1 Detalhes sobre como esta caracter stica auxilia no suporte consist ncia podem ser obtidos na pr xima se o Em rela o analise de impacto uma vez que uma requisi o de mudan a altere um caso de uso cuja p s condi o pr condi o de outro caso de uso este outro caso de uso tamb m deve ser revisado pois dependendo da mudan a tamb m pode ser afetado 4 2 3 Regras de consist ncia A partir da defini o do Modelo Conceitual partiu se para a defini o das regras de consist ncia que devem ser respeitadas pelo sistema de ger ncia de requisitos que siga o modelo proposto neste trabalho Estas regras de consist ncia ap iam a solu o no atendimento do requisito 3 identificado na se o 4 1 2 O requisito 3 determina que os requisitos de aplica es devem ser atualizados e estarem consistentes para refletirem as altera es das requisi es de mudan a 1 O sistema de ger ncia de requisitos n o deve permitir a remo o da p s condi o de um caso de uso que est associada com a pr condicao de outro caso de uso visualizar Figura 6 2 O sistema de ger ncia de requisitos n o deve permitir a remo o de um caso de uso cuja
98. liza o entre os casos de uso Por este motivo neste trabalho foi adicionada a classe SessaoGeneraliza para permitir a representa o do relacionamento o Adi o das classes Participante Sistema e Ator Som n o define estas classes no seu meta modelo de casos de uso e UML 2007 A defini o dos relacionamentos generaliza o inclus o e extens o entre os casos de uso est baseada na especifica o UML 42 oc Descricaoteral 0 a interessado RequisicaoMudanca Altera 0 0 1 rier i MA i RegNaoFuncionalGeral i 0 mm Reaanruncona specico qoUsolmcluido Passos condicanAl altematvasGlobals Figura 5 Modelo Conceitual do Problema 43 4 2 1 Detalhes do Modelo Conceitual Esta se o apresenta a descri o das classes e dos relacionamentos entre as classes do Modelo Conceitual do problema apresentado As principais classes que comp em o modelo s o a classe que representa o SRS SRS a classe que representa a Aplica o Aplicacao a classe que representa os Requisitos da Aplica o RequisitoA plicacao e a classe que representa as Requisi es de Mudan a RequisicaoMudanca 4 2 1 1 Classes que constituem o documento SRS SRS A classe SRS representa o documento SRS da aplica o Este documento mostra que um SRS composto de quatro se es maiores Introdu o Descri o Geral Informa es de Suporte e Requisitos de Aplica o representad
99. m o caso de uso inclu do Passos l O Usu rio informa um passo que representa um relacionamento inclus o com outro caso de uso j cadastrado no sistema ou seja existe outro caso de uso que inclu do pelo caso de uso 2 O Sistema mostra a lista de casos de uso da aplica o ou aplica es que o caso de uso sendo adicionado editado associado 3 O Usu rio seleciona um caso de uso da lista 4 O Sistema registra o relacionamento inclus o entre os casos de uso Alternativas Pontos de Extens o Requisitos N o Funcionais Associados 110 Caso de Uso Adicionar Relacionamento Generaliza o Objetivo Permitir que o usu rio possa relacionar um caso de uso com outro caso de uso que sua especializa o Atores Engenheiro de Requisitos Pr condi o P s condi o de Sucesso O caso de uso relacionado com o caso de uso especializado Passos l O Usu rio informa um passo que representa um relacionamento de generaliza o com outro caso de uso j cadastrado no sistema ou seja existe outro caso de uso que a especializa o caso de uso filho do caso de uso 2 O Sistema mostra a lista de casos de uso da aplica o ou aplica es que o caso de uso sendo adicionado editado associado 3 O Usu rio seleciona um caso de uso da lista 4 O Sistema registra o relacionamento generaliza o entre os casos de uso Alternativas Pontos de Extens o Requisitos N o Funcionais Associados Caso
100. ma de Vendas n o precisa mais estar autenticado no sistema para submeter pedidos de compra conforme mostra a Figura 26 O sistema informa na Figura 27 que a pr condi o do caso de uso Submeter Pedido est relacionada com a p s condi o do caso de uso Efetuar Login Neste caso para atender esta requisi o de mudan a deve se remover a pr condi o do caso de uso Submeter Pedido que est vinculada com a p s condi o do caso de uso Efetuar Login A Figura 28 mostra como ficam as rela es por pr e p s condi es do caso de uso Submeter Pedido ap s as modifica es para atender a requisi o de mudan a 71 Objeto Proposta _ _ Objeto da p s condi o selecionada abaixo Estado foi submetida ao funcion rio Estado da p s condi o selecionada abaixo Esta Pr Condi o est ligada com a p s condi o de outro Caso de Uso 4 Selecione a Aplica o a qual o Caso de Uso pertence 7 r s f 14 80 luntana y Figura 23 Identifica o da pr condi o do caso de uso Aceitar Proposta do Fornecedor e Efetuar Compra ed Cacos de Uko Afetados nela Requisic o de Mudanca Identihca o dos Casos de Uso Aletados Casos de Uso tados pela Requisi o de A Apbcap o x Casos de Usa Hist rico de Mudan a do Caso de Usa Caso Uso Processar Proposta a ds Aplica o Sistema de Vendas Jd Requisi o Mudan a Ad
101. ma um passo que representa um relacionamento de generaliza o com outro caso de uso 3 O Sistema executa o caso de uso Adicionar Relacionamento Generaliza o 4 O Sistema volta ao passo 2 da Subse o Adicionar Caso de Uso Alternativa 5 Casos de Uso que procedem o caso de uso sendo adicionado 2 O sistema mostra uma lista dos casos de uso das aplica es associadas com o caso de uso sendo adicionado 3 O usu rio pode selecionar um ou mais casos de uso 97 4 O sistema salva a rela o de proced ncia entre os casos de uso e volta ao passo 2 da Subse o Adicionar Caso de Uso Pontos de Extens o Requisitos N o Funcionais Associados Caso de Uso Editar Requisito de Aplica o Objetivo Permitir que o usu rio possa editar Requisitos de Aplica o do sistema Atores Engenheiro de Requisitos Pr condi o Usu rio est registrado no Sistema P s condi o de Sucesso Passos l O usu rio seleciona um Requisito de Aplica o para edi o 1 Se o requisito sendo editado for do tipo N o Funcional Geral ver subse o Editar Requisito N o Funcional Geral 2 Se o requisito sendo editado for do tipo Caso de Uso ver subse o Editar Caso de Uso 2 O sistema salva o requisito 3 O Sistema registra dados do hist rico da mudan a efetuada N mero da Vers o Autor da edi o usu rio registrado e Data e Hora da edi o Subse o Editar Requisito N o Funcional Geral l O Usu rio informa a
102. mantic Indexing MVC Model View Control PU Processo Unificado SCM Software Configuration Management SRS Software Requirements Specification UML Unified Modelling Language SUM RIO INTRODU O amos DR e 14 1 1 An lise de ferramentas de ger ncia de requisitos existentes no mercado 15 12 Ohestao de PESQUISA resina a A a als eaten 16 1 3 OD CU VOS n A A RE arNeee 16 1 3 1 Objetivo Geral sas edad A caras rasas sapo E 16 1 3 2 Objetivos Especificos siiis oenn neie eea aer E ERa 16 1 4 Organiza o do Volume sisinio e sasre rasa sesaresesetanadao 17 2 REFERENCIAL TEORI O veacssescacersssciscsvnesssdeteeaccuasvacivssetsneteosteeweccevseavcnasinagoseevseneiees 19 2 1 Ensenharia de REQUISILOS sassaresi R SAT a 19 22 REQUISITOS ccdsctiiess i aan aaa Sa ni DO A coche dan acess E DU RR 19 2 3 Ger nerde REGO UOS ca sesapaidado san toc asnandnccce a aaa 21 2 4 Casos de USO annaa E DOGS E Gt a 22 2 4 1 Especifica o de Casos d USO cissccicsscssecccsscecccdaceccecseshvansedeaseccssasevssees eaecucweccaass 23 2 4 2 Requisitos Funcionais como Casos de Uso sssseececececccccccscssssseseeceoesossssssssoo 25 2 4 3 Relacionamentos entre Casos de US0 cccccccccsssssssssssssssssssssscscccccscsscsscsssceees 25 2 5 Manutencao dE SOW E aa DD ea eames 27 2 5 1 Ciclo de Vida do SoftWare ssisseicicicesivecandecvsescevessedsenceesseaseneuensoteansevncewsssesseonseene 27 2 5 2 Ciclo de Vida de Nid ana asia ni De
103. monstrado na Figura 10 56 Remo o do caso de uso Submeter Pedido Casos de Uso Pedido em Oferta e Cliente Especial tamb m devem ser removidos Figura 10 Remo o de um caso de uso relacionado por Extens o 6 Quando na remo o de um passo de um caso de uso que representa a extens o por outro caso de uso O sistema deve remover tamb m o caso de uso que estende caso o mesmo n o possua rela o com ator ou com nenhum outro caso de uso 7 Quando na remo o de um caso de uso o sistema de ger ncia de requisitos deve verificar se o caso de uso sendo removido generaliza outros casos de uso Para cada caso de uso especializado pelo caso de uso sendo removido o sistema deve remov lo caso o mesmo n o possua rela o com ator ou com nenhum outro caso de uso A Figura 11 ilustra um exemplo desta situa o 8 Quando na remo o de um passo de um caso de uso que generaliza outros casos de uso Para cada caso de uso especializado pelo caso de uso sendo removido o sistema deve remov lo caso o mesmo n o possua rela o com ator ou com nenhum outro caso de uso 57 Remo o do caso de uso Efetuar Pagamento Efetuar Pagamento com Cart o de Cr dito Efetuar Pagamento com Cheque i Caso de Uso Efetuar i lt lt include gt gt Pagamento em mirins i Dinheiro tambem deve i f ser removido Cadastro do Cliente no SPC Processar Proposta Figura 1
104. mover Requisitos de Aplica o do sistema Atores Engenheiro de Requisitos Pr condi o Usu rio est registrado no Sistema P s condi o de Sucesso Passos l O usu rio seleciona um Requisito de Aplica o para remo o 2 O Sistema mostra a lista de Aplica es que o requisito est associado e confirma se o usu rio deseja remover o requisito 3 O usu rio confirma a remo o 1 Se o requisito selecionado for do tipo N o Funcional Geral executa passo 4 2 Se o requisito selecionado for do tipo Caso de Uso ver subse o Remover Caso de Uso 4 O sistema remove o requisito 5 O Sistema registra dados do hist rico da mudan a efetuada N mero da Vers o Autor da remo o usu rio registrado e Data e Hora da remo o Subse o Remover Caso de Uso l O sistema verifica que o caso de uso sendo removido inclui outros casos de usos que n o tem relacionamento com nenhum outro caso de uso nem relacionamento com atores 2 O sistema remove o caso de uso e os casos de uso Inclu dos Pontos de Extens o Requisitos N o Funcionais Associados l Na remo o o sistema n o deve remover o requisito de aplica o fisicamente do Sistema A remo o deve ser apenas l gica Caso de Uso Gerenciar Requisi es de Mudan as Objetivo Permitir que o usu rio possa adicionar editar remover ou consultar requisi es de mudan a do sistema 101 Atores Engenheiro de Requisitos Pr condi o Usu rio
105. nalista est alterando um caso de uso utilizado por mais de uma aplica o at que ponto modifica es s o aceit veis para ainda se caracterizar o caso de uso reutilizado Dependendo das altera es pode ser necess ria a cria o de outra inst ncia do caso de uso separando o caso de uso alterado do caso de uso comum as outras aplica es Em rela o ao suporte consist ncia mais avan os podem ser realizados no que diz respeito defini o de regras de forma o e consist ncia na defini o dos casos de uso Com mais regras evita se que casos de uso sejam descritos como texto livre o que facilita o suporte atualiza o e consist ncia dos mesmos pelas ferramentas Um exemplo de nova regra poderia ser quando o analista remover a pr condi o de um caso de uso o sistema verificaria que pelo menos um passo deste caso de uso deve ser alterado Outra possibilidade de trabalho futuro a gera o do Modelo de Dom nio dos sistemas cadastrados a partir dos conceitos descritos nos casos de uso Al m do Modelo de Dom nio desejado que o sistema avance para suportar a rastreabilidade com os outros artefatos do software como Diagrama de Classes Diagrama de Seqii ncia etc 86 REFER NCIAS BIBLIOGR FICAS AND 2001 Anda B Sj berg D Jorgensen M Quality and Understandability of Use Case Models In ECOOP 2001 Object Oriented Programming 15th European Conference p 18 22 v 2072 2001 Budapest Hunga
106. ngo de sua evolu o Em MOH 2008 os casos de uso s o armazenados como um nico elemento enquanto que neste trabalho os casos de uso s o uma composi o de elementos T tulo Pr condi es P s condi es Objetivo Atores etc A vantagem desta representa o que ela permite explorar o conte do dos casos de uso como por exemplo o relacionamento entre os casos de uso por suas pr condi es e p s condi es conforme descrito na se o 2 4 3 Relacionamentos entre Casos de Uso Outra diferen a entre os trabalhos que MOH 2008 n o prop e o reuso dos artefatos 3 5 Considera es do Cap tulo Neste cap tulo foi apresentada uma breve descri o do trabalho de Som SOM 2007 Embora o prop sito do trabalho do autor n o seja o mesmo deste trabalho algumas de suas defini es como o meta modelo de representa o dos casos de uso e a identifica o de pr e p s condi es como indica es da seqii ncia de execu o dos casos de uso contribu ram para o desenvolvimento da solu o apresentada neste trabalho 35 Neste cap tulo tamb m foram apresentados dois trabalhos de LUC 2007 e MOH 2008 com prop sito muito semelhante ao desta disserta o Em suma a principal diferen a deste trabalho em rela o a estes dois citados que ele tem como foco a ger ncia dos requisitos representados por casos de uso Enquanto que os outros dois trabalhos focam na ger ncia de todos os artefatos do
107. o usu rio registrado e Data e Hora da atualiza o Alterntativa 2 Remo o 2 4 5 O usu rio solicita a remo o de uma Requisi o de Mudan a O sistema verifica se n o h requisitos de aplica o associados Requisi o de Mudan a e remove a mesma O Sistema registra dados do hist rico da mudan a efetuada N mero da Vers o Autor da remo o usu rio registrado e Data e Hora da atualiza o 102 Alterntativa 3 Remo o com Requisitos Relacionados 3 O usu rio solicita a remo o de uma Requisi o de Mudan a 4 O sistema verifica se h requisitos de aplica o associados Requisi o de Mudan a e mostra uma mensagem ao usu rio indicando que a remo o da Requisi o de Mudan a implicar na perda dos relacionamentos entre Requisi o de Mudan a e requisitos de aplica o 5 O usu rio confirma a remo o 6 O Sistema remove a requisi o de mudan a e os relacionamentos com os requisitos de aplica o 7 O Sistema registra dados do hist rico da mudan a efetuada N mero da Vers o Autor da remo o usu rio registrado e Data e Hora da atualiza o Alterntativa 4 Consulta 3 O usu rio solicita a consulta de uma Requisi o de Mudan a 4 O sistema mostra as informa es da Requisi o de Mudan a tais como a Origem da Mudan a Descri o Tipo de Mudan a Data de Entrega Planejada Prioridade de Implementa o Implementador Gerador Prioridade do Ger
108. o dos requisitos do software atrav s de liga es de rastreabilidade entre as requisi es de mudan as e os requisitos funcionais representados por casos de uso e n o funcionais liga es entre os casos de uso pelos relacionamentos propostos por UML 2007 e SOM 2006 e atrav s do hist rico dos requisitos ao longo do ciclo de vida do software Enfim este trabalho menos abrangente no sentido que n o apresenta uma solu o que abranja todos os artefatos do software por m mais espec fico e por consegii ncia mais detalhista no suporte aos artefatos de requisitos 3 3 NOLL e BLOIS 2007 Este trabalho prop e a integra o de ontologias no Processo Unificado PU a fim de fornecer rastreabilidade baseada em conceitos ao longo do ciclo de vida do software Este m todo permite a integra o de diferentes modelos do sistema de software incluindo neg cio requisitos modelos de an lise e de projeto Para auxiliar os projetistas na cria o da ontologia e liga o dos conceitos dos artefatos o autor disponibiliza uma ferramenta integrada com um modelador UML A principal diferen a do trabalho de Noll NOL 2007 em rela o a este trabalho que ele apresenta uma proposta de rastreabilidade dos artefatos do software mas n o apresenta uma proposta para manter a consist ncia e o controle de vers o dos mesmos O controle de vers o essencial para que seja poss vel se ter o hist rico da evolu o do soft
109. o pedido e o caso de uso termina Fluxo de Secund rio caminho alternativo 2 O sistema n o encontra o pedido 3 O sistema solicita que o usu rio verifique se os dados do pedido est o corretos 4 O caso de uso encerrado Pr condi o O usu rio ter feito o pedido P s condi o A situa o do pedido n o ter sido alterada Caso de Uso Fornecer produto Objetivo Entregar os produtos comprados Atores Fornecedor Pr condi o A compra de produtos do fornecedor j foi efetuada Fluxo de Eventos caminho b sico 1 O caso de uso come a quando o fornecedor pega a lista de produtos comprados 2 O Fornecedor entrega os produtos de acordo com as especifica es 3 O Sistema atualiza a quantidade dispon vel de produtos 4 Quando o sistema realizar a atualiza o deve ser emitido uma confirma o de recebimento para o fornecedor 115 P s condi o Lista de produtos deve estar atualizada 116 2 Sistema de Compra de Fornecedores Caso de Uso Submeter Requisi o de Compra aos Fornecedores Objetivo Funcion rio submete requisi o de compra aos fornecedores para atender ao pedido do cliente Atores Funcion rio Pr condi o Pedido do cliente foi gerado P s condi o Requisi o de compra foi submetida aos fornecedores Fluxo de Eventos caminho b sico 1 O caso de uso come a quando o funcion rio seleciona um pedido do cliente Inclui Procurar Pedido 2 O sistema mostra a lista de
110. onada com a p s condi o do Caso Uso Submeter Pedido Clg Caso Uso Procurar Pedido Ca Caso Uso Submeter Requisi o de Compra aos Fomecedores lda Caso Uso Venica Pedido C Caso Uso Cancelar Pedido 4 Casos de Uso cuja p s condi o est relacionada com a pr condi o do Caso User Submeter Pedido p 14 Caso Uso Efetuar Login Eta Caso de Uso __ Remover Caso de Uso _ Caso Uso Submeter Pedido pe Ree Figura 27 Requisi o de Mudan a Usu rio n o precisa estar autenticado no sistema para submiss o de pedido 2 Casos de Uso Afetados pela Requisi o de Mudan a Ideniihca o dos Casos de Uso Aletados Casos de Uso Afetados pela Requisi o de Mudanca Aplica o x Casos de Uso Hist rico de Mudan a do Caso de Uso Caso Uso Submeter Pedido 6 Aphca o Sistema de Vendas lg Requn o Mudan a Usu rio n o precisa estar autenticado no sistema para submiss o de pedido Edi o Jt Caso Uso Cancelar Pedido 14s Caso Uso Ciente Especial 14 Caso User Efetuar Login 6 Caso Uso Procurar Pedido Ca Caso Uso Produto em Oleta SMU Caro Uno Submeter Pedido E DA Inchi dg Extendido Por e Dg Cato Uso Verifica Pedido e dz Aplica o Sistema de Pagamento a Aplica o Sistema de Cota o de Pedidos com Fomecedores lt Catos de Uso relacionados por Pr e P s Condi es Jd Casos de Uso cuja pr condi o est relacionada com a p s condi o do Caso Liso Submeter Pedido
111. ortes e fracos da arquitetura ambiente de opera o da aplica o etc Este conhecimento um pr requisito para a subsequente fase Evolu o Evolu o Esta fase s inicia quando o desenvolvimento inicial foi bem sucedido O objetivo desta fase adaptar a aplica o para qualquer mudan a nos requisitos do usu rio e no ambiente operacional A evolu o tamb m corrige as falhas da aplica o identificadas a partir do aprendizado do desenvolvedor e do usu rio no qual requisitos mais acurados s o baseados na experi ncia passada com a aplica o Em termos de neg cio a aplica o est evoluindo porque ela bem sucedida no mercado ela lucrativa existe forte demanda dos usu rios sobre a mesma a atmosfera de desenvolvimento vibrante e positiva e a organiza o suporta a aplica o Resumindo o retorno do investimento na aplica o excelente A arquitetura e o conhecimento da aplica o s o respons veis por tornar a evolu o poss vel Elas permitem que a equipe fa a mudan as substanciais no software sem danificar a sua integridade Uma 28 vez que um ou outro aspecto desaparece o programa n o mais pass vel de evolu o e entra no est gio de Servi o Servi o Durante esta fase somente pequenas mudan as t ticas concertos ajustes s o poss veis Para a organiza o quando a aplica o entra neste est gio porque ela n o mais um produto essencial e o custo benef cio de se e
112. os Esta caracter stica auxilia no atendimento dos requisitos 1 e 3 O reuso dos requisitos por mais de uma aplica o facilita a an lise de impacto requisito 1 Por exemplo uma vez que se identifique que uma requisi o de mudan a afetou um requisito associado com mais de uma aplica o j se sabe que estas aplica es foram afetadas pela mudan a Sem este recurso teria que se identificar todas as inst ncias do requisito relacionados com cada aplica o O reuso dos requisitos tamb m auxilia no suporte a consist ncia e atualiza o dos requisitos requisito 3 pois uma vez alterado o requisito a modifica o j refletir para todas as aplica es associadas sem a necessidade de replica o das modifica es Liga o entre requisi o de mudan a e requisitos de aplica o Esta liga o se d atrav s dos relacionamentos Adiciona Altera e Remove entre a classe RequisicaoMudanca e Requisito A plicacao O relacionamento Adiciona determina que uma requisi o de mudan a pode adicionar requisitos de aplica o O relacionamento Altera determina que uma requisi o de mudan a pode alterar requisitos de aplica o E o relacionamento Remove determina que uma requisi o de mudan a pode remover requisitos de aplica o Atrav s destas liga es poss vel se obter a rastreabilidade das mudan as dos requisitos de aplica o a fim de se ter 51 informa es tais como a pa
113. os casos de uso em linguagem natural e a deriva o de uma especifica o execut vel bem como um ambiente de simula o dos casos de uso DAR 2003 DOU 2008 e LAR 2007 tamb m identificam casos de uso como forma de descrever os requisitos funcionais de um sistema 2 4 3 Relacionamentos entre Casos de Uso A UML UML 2007 define os relacionamentos Inclus o representado por include Extens o representado por extende e Generaliza o entre casos de uso O relacionamento de Inclus o define que um caso de uso cont m o comportamento definido em outro caso de uso O caso de uso que inclui pode depender apenas do resultado valor do caso de uso Inclu do Este valor obtido como um resultado da execu o do caso 25 de uso inclu do A execu o do caso de uso inclu do n o opcional ou seja sempre requerida pelo caso de uso que inclui O relacionamento de inclus o permite a composi o hier rquica e o reuso dos casos de uso O relacionamento de Extens o define que o comportamento de um caso de uso pode ser estendido pelo comportamento de outro caso de uso O caso de uso estendido definido independentemente do caso de uso que estende ou seja ele existe independente do caso de uso que o estende Por outro lado o caso de uso que estende pode definir comportamento que n o necessariamente fa a sentido por si s Neste caso o caso de uso que estende define um conjunto de comportamento modula
114. pdating and consistency of the requirements during the maintenance This model is formed by a Conceptual Model that represents the concepts involved in the problem and how they are related to each other in order that it is possible to reach the purpose consistency rules and a process to track the versions of the requirements The results are presented through examples illustrating various possible scenarios using the prototype developed based on the proposed model The main contribution of this research is a model that helps to maintain the software requirements up to date and consistent along the maintenance process besides to help on the impact analysis of change requests Keywords Requirements Engineering Requirements Management Requirements Use Cases Software Maintenance LISTA DE FIGURAS Figura 1 Exemplo de casos de uso relacionados por pr e p s condi es cccccceeseessseeeceeceeseesseeeeeeeseeeeseeeeeees 21 Figura 2 Ciclo de Vida do Software Adaptado de BEN 2000 ccccccscccccccessesenteceeceesseseseceeeeesseseseeeeeees 28 Tewa Ss Cielo devida de mudane deoin E E E ad 31 Figura Estrutura do documento ERD issiran a a E r RO a A 38 EFisura 6 Remocao da POS CON CIC AO ca sais sines a a a E a Doda And nad 55 Figura 7 Remo o de um caso de uso relacionado por P s condi o c e ieeerreereeeeereernanea 55 Figura 8 Remo o de um caso de uso relacionado por Inclus o ee eerere
115. pre o Caso o cliente seja um cliente especial da loja o sistema calcula um desconto em cima do pre o total da compra O controle do pagamento dos produtos feito atrav s da interface com outro sistema chamado Sistema de Pagamento O sistema permite que o cliente acompanhe o andamento do seu pedido e que cancele o mesmo caso queira desistir da compra O sistema recebe os produtos de seus fornecedores e entrega os produtos aos seus clientes atrav s de uma transportadora A cota o de pre os dos produtos e compra dos produtos dos fornecedores feita por outro sistema Sistema de Compra de Fornecedores A Figura 13 abaixo ilustra o modelo de casos de uso deste sistema A especifica o de cada caso Condi o Produto esta em oferta Entrarno Sistema Submeter a prr Lo lt lt extend gt ne E Cliente Especial Cvertear Pedido gt Pedido hise CCcancetar Pedido gt Pedido _ a SINCIURE fes j C Procurar Pedido gt Pedido de uso pode ser encontrada no Ap ndice II deste trabalho ENS rir AR C Especial C Comum Fornecer Produto X i Fornecedor Entregar Produto i ee nn aa Ave Calcular Postagem Figura 13 Sistema de Vendas 62 5 2 2 Sistema de Pagamento O sistema de pagamento tem como prop sito permitir que o cliente efetue o pagamento para a empresa O cliente pode efetuar o pagamento de tr s formas e Com cart o de cr dito Neste caso o funcion rio deve
116. qualquer fun o ou caracter stica necess ria a um sistema os comportamentos quantific veis e verific veis que um sistema deve ter as restri es que deve atender ou outras propriedades que devem ser fornecidas de forma a satisfazer os objetivos das organiza es e resolver um conjunto de problemas Outros afirmam que os requisitos de um sistema definem o que o sistema deve fazer e as circunst ncias sobre as quais deve operar Em outras palavras os requisitos definem os servi os que o sistema deve fornecer e disp em sobre as restri es opera o do mesmo Diversos autores THA 1990 NUS 2000 KRU 2000 LEF 2000 SOM 2005 dividem os requisitos de software em dois tipos funcionais o que o software deve fazer e nao funcionais como o software se comporta em rela o a alguns atributos observ veis Requisitos funcionais devem definir as a es fundamentais que devem ser tomadas pelo software na aceita o e processamento das entradas e no processamento e transforma o das sa das IEE 1998 Requisitos funcionais devem ser descritos de forma completa e consistente onde a completeza significa que todas as fun es requeridas pelo usu rio devem estar descritas e consist ncia significa que os requisitos n o devem ter defini es contradit rias SOM 2005 Segundo LEF 2000 requisitos funcionais podem ser representados por uma simples senten a ou na forma de casos de uso Requisitos nao funcionai
117. quisa 84 6 1 Contribui es Uma das principais contribui es desta pesquisa a possibilidade de manter os requisitos de aplica es de software atualizados ao longo da sua evolu o Os sistemas de ger ncia de requisitos existentes atualmente no mercado s o orientados a projeto Uma vez terminado o projeto os requisitos tendem a serem esquecidos e n o mais atualizados Com o modelo de ger ncia apresentado poss vel se obter o hist rico de cada requisito de aplica o desde sua cria o at o seu t rmino desativa o do ambiente de produ o do software Al m de auxiliar na manuten o dos requisitos atualizados uma outra importante contribui o o suporte consist ncia dos requisitos funcionais representados por casos de uso No geral os casos de uso s o definidos pelos analistas de software como texto livre sem muitas regras de forma o No modelo apresentado neste trabalho o caso de uso representado por sub elementos ator pr condi es p s condi es passos da sequ ncia b sica etc que auxiliam o analista na descri o dos casos de uso O modelo tamb m suporta regras de consist ncia nos relacionamentos entre os casos de uso inclus o estens o e generaliza o definidos pela UML e por pr e p s condi es proposto neste trabalho Este modelo tamb m traz benef cios para an lise de impacto das requisi es de mudan as atrav s dos recursos que mostram o hist rico dos
118. quisi o de Muda AphcacSo x Caro da Uru Tdi Aphea o Sistema de Vendas E Jd Caso User Cancels Pedido Cga Como User Ciente special LlG Caso Uso Procurar Pedido dz Caso Use Produto em Oleta a F Cano Use Submete Pedido a hg Caso User Verea Pedido a dis Aplica o Sistema de Pagamento E dg Aplica o Sistema de Cota o de Pedidos com Casos de Uso relacionados por Pr e P s Condi es dg Casos de Uso cuja pr condi o est relacionad 4 Caso Use Procurar Pedido Clg Caso User Submete Fiequisi o de Compes js Caso Usg Verica Pedido 14 Caso Liso Cancela Pedido Cano de Use palecanados ENE Fere aaa S S Cano de io dD Remover Caso c ES Identiica o dos Casos de Liso Aletados Casos de Uso Aet dplca o Sistema de Vendas ga Dhjetra Perdi que o utu rio submeta um pedido de compra Titulo Submneter Pedido Atotes Ciente Pr condi es Frequencia o Requisitos N o Funcionar Adicionar Requistos N o Funcionam Figura 31 Edi o caso de Uso Submeter Pedido W Identificar P s Condi es P s condi o Objeto N o possivel remover a p s condi o Pedido deve ter sido gravado no sistema e marcado como confirmado porque a mesma est relacionada com a pr condi o de outro Caso de Uso i Figura 32 Mensagem de erro na remo o da p s condi o do caso
119. r e P s Condi es Casos de Uso selecionados Adicionar Caso de Uso Figura 34 Hist rico de mudan a da aplica o Sistema de Cota o de Pedidos com Fornecedores Outra funcionalidade do sistema de ger ncia de requisitos proposto neste trabalho o hist rico dos requisitos O analista pode visualizar as altera es do requisito desde sua cria o at sua remo o Outro exemplo da se o 5 3 1 mostrado nas Figuras 26 27 e 28 foi a altera o do caso de uso Submeter Pedido para atender a requisi o de mudan a Usu rio n o precisa 19 estar autenticado no sistema para submiss o de pedido Neste caso ap s a altera o do caso de uso Submeter Pedido o sistema gerou uma nova vers o do mesmo Este hist rico do caso de uso est ilustrado na Figura 35 Quando o analista selecionar o bot o Ver Vers o ele pode visualizar os detalhes do caso de uso associado com a vers o da linha em que o bot o se encontra conforme mostrado na Figura 36 Nesta figura pode se observar que o caso de uso na sua primeira vers o tinha a pr condi o Usu rio est autenticado no sistema Enquanto que na sua segunda vers o esta pr condi o foi removida Neste modelo proposto cada vers o do caso de uso est associada com uma requisi o de mudan a exceto se o caso de uso n o foi criado na fase de manuten o da aplica o Para cada requisi o de mudan a que afeta requisitos uma no
120. r associado com uma condi o representada pela classe Restricao que deve ser verdadeira para que o passo seja executado e ou com um atraso representada pela classe Atraso A condi o para o passo pode ser descrita atrav s das palavras chave se ent o Um passo simples pode estar associado com um ponto de extens o classe PontoExtensao Atraso Representa o tempo que o sistema deve aguardar para a execu o de um passo do caso de uso PassoOperacao Esta classe representa passos que s o opera es Uma opera o pode ser executada por um ator do ambiente atrav s de um gatilho ou pelo pr prio sistema atrav s de uma rea o Portanto uma opera o pode ser um gatilho representado pela classe Gatilho ou pode ser uma rea o representada pela classe Reacao Um passo de opera o pode estar associado com uma ou mais alternativas representada pela classe Alternativa Gatilho O gatilho uma opera o disparada por um ator do sistema Reacao A rea o uma opera o disparada pelo pr prio sistema 49 4 2 1 4 Ramificacao Esta classe representa passos que s o ramifica es Um passo de ramifica o inclui a refer ncia para um passo i de forma que o fluxo de eventos do caso de uso seja desviado para o passo i IncluiCasoUso Esta classe representa um passo do caso de uso que inclui um outro caso de uso Este passo representa a realiza o de um relacionamento de inclus o entre um
121. r que complementa a execu o do caso de uso estendido quando determinada condi o encontrada O relacionamento Generaliza o usado quando um caso de uso especializa outro caso de uso mais geral ou seja diz se que o caso de uso um tipo de outro caso de uso COC01 Segundo a UML UML 2007 um relacionamento de generaliza o entre casos de uso implica que o caso de uso filho cont m todos os atributos sequ ncias de comportamento e pontos de extens o definidos no caso de uso pai e participa de todos os seus relacionamentos Al m dos relacionamentos entre casos de uso definidos pela UML UML 2007 ser considerado neste trabalho o relacionamento entre casos de uso por suas pr condi es e p s condi es Pr condi es s o condi es que devem ser verdadeiras quando a execu o do caso de uso for invocada UML 2007 P s condi es s o condi es que ser o verdadeiras quando o caso de uso completar a sua execu o com sucesso assumindo que suas pr condi es foram satisfeitas P s condi es s o particularmente importantes quando o caso de uso executado leva o sistema para um determinado estado que caracterize uma pr condi o para outro caso de uso COC 2005 Som SOM 2007 define que pr e p s condi es s o especifica es impl citas da sequ ncia de execu o dos casos de uso Pr condi es e p s condi es permitem especificar que casos de uso devem prece
122. rande do Sul Porto Alegre 2007 COC 2005 Cockburn A Escrevendo Casos de Uso Eficazes Porto Alegre Bookman Companhia ED 2005 254p COL 2004 Collins Sussman B Fitzpatrick B W Pilato C M Version Control with Subversion Calif rnia O Reilly Media 2004 320p DAR 2003 Kulak D Guiney E Use Cases Requirements in Context 2 ed New York Addison Wesley 2003 272p 87 DOR 1990 Dorfman M Thayer R Standards Guidelines and Examples of System and Software Requirements Portland IEEE Computer Society Press 1990 620p DOU 2008 Douglas C W Visual Language Representation for Use Case Evolution and Traceability 2008 147 p Disserta o requisito parcial para Doutorado em Filosofia The Department of Computer Science Louisiana State University Louisiana 2008 DUR 1999 Dur n A Bern rdez B Ruiz A Toro M A Requirements Elicitation Approach Based in Templates and Patterns In II Ibero American Workshop on Requirements Engineering 1999 Buenos Aires Argentina 1999 EAS 2004 Easterbrook S What is Requirements Engineering 2004 Disponivel em lt http www cs toronto edu sme papers 2004 FoRE chapter01 v 7 pdf gt Acesso em 20 maio 2007 ESP 2006 Espindola R Uma Arquitetura de Informa o para Ger ncia de Requisitos em Desenvolvimento Distribu do de Software 2006 125p Disserta o de Mestrado FACIN PPGCC PUCRS Porto Alegre 2006 FJE 1982 Fjeldstad R
123. requisitos e como os requisitos das aplica es est o relacionados O relacionamento por pr e p s condi es auxilia na identifica o dos requisitos associados com um mesmo objeto al m de representar a ordem de sequ ncia de execu o dos casos de uso 6 2 Limita es do Estudo Este trabalho atendeu ao objetivo ao qual se prop s por m existem algumas limita es a serem trabalhadas e An lise de impacto automatizada Apesar de auxiliar na an lise de impacto o modelo proposto s auxilia na identifica o dos requisitos afetados se o analista identificar pelo menos um primeiro requisito A identifica o de requisitos afetados pelas requisi es de mudan as de forma autom tica seria um recurso que traria muitos benef cios e Controle de concorr ncia O modelo proposto n o suporta o controle de concorr ncia descrito pelo requisito 2 da se o 4 1 2 85 e Suporte ao rollback das altera es feitas por uma requisi o de mudan a Apesar do modelo proposto suportar o rollback n o foi desenvolvido o mecanismo de rollback das altera es dos requisitos feitas para atender uma requisi o de mudan a 6 3 Trabalhos Futuros Al m de atender s limita es apontadas na se o anterior a partir deste trabalho identificou se algumas oportunidades de desenvolvimento de trabalhos futuros Por exemplo o reuso dos casos de uso pode ser mais explorado de tal forma que o sistema verifique quando um a
124. rio identifica que deve alterar um requisito n o funcional geral para atender requisi o de mudan a 2 O Sistema mostra a lista de requisitos n o funcional geral existentes agrupados por aplica o 3 O Usu rio seleciona um requisito para edi o 4 O sistema apresenta o hist rico de altera es deste requisito n o funcional geral como segue a Lista de requisi es de mudan a que foram implementadas no passado e que afetaram o requisito n o funcional geral b Para cada requisi o de mudan a listada o sistema deve mostrar todos os requisitos n o funcional geral de aplica es afetados pela requisi o de mudan a 5 O usu rio seleciona um requisito n o funcional geral afetado pelas requisi es de mudan as anteriores 6 O usu rio repete o passo 4 a 6 at selecionar todos os requisitos alterados pela requisi o de mudan a 7 O Sistema executa o caso de uso Editar Requisito N o Funcional Geral 8 O Sistema relaciona o requisito n o funcional geral adicionado com a requisi o de mudan a indicando que a requisi o de mudan a adiciona o requisito 9 O Sistema registra dados do hist rico da mudan a efetuada N mero da Vers o Autor da modifica o usu rio registrado e Data e Hora da modifica o Alternativas Pontos de Extens o Requisitos N o Funcionais Associados Caso de Uso Remover Requisitos N o Funcional Geral afetados por Requisi o de Mudan a Objetivo Permi
125. rocesso de manuten o Este modelo constitu do por um Modelo Conceitual representando os conceitos envolvidos no problema e como eles devem estar relacionados para que seja poss vel alcan ar o objetivo regras de consist ncia e um mecanismo de versionamento dos requisitos Os resultados s o demonstrados atrav s de exemplos ilustrando os diversos cen rios poss veis utilizando um prot tipo desenvolvido a partir do modelo proposto A principal contribui o deste trabalho um modelo que auxilie a manter os requisitos de software atualizados e consistentes ao longo de processos de manuten o al m de auxiliar na an lise de impacto das requisi es de mudan a Palavras chave Engenharia de Requisitos Ger ncia de Requisitos Requisitos Casos de Uso Manuten o de Software ABSTRACT The maintenance and software evolution demands a high cost to the organizations One of the reasons for this high cost is the lack of documentation The requirements represent an important way of documenting the software Very commonly the requirements are not updated after the end of the software development project The requirements are not updated during the maintenance phase The purpose of this research is to propose a solution to the problem of keeping the software application requirements up to date and consistent during the software maintenance process The solution is represented by a requirements management model that supports the u
126. rtir de qual requisi o de mudan a um determinado requisito surgiu foi removido ou alterado Essa rastreabilidade unida com um controle de vers o dos requisitos fornece o hist rico da evolu o da aplica o Esta caracter stica auxilia no atendimento dos requisitos 1 3 4 e 5 A rastreabilidade entre as requisi es de mudan as e os requisitos de aplica o e o hist rico dos requisitos de aplica es auxiliam na an lise de impacto requisito 1 Uma vez identificado que um determinado requisito foi afetado por uma requisi o de mudan a o sistema fornece o hist rico de mudan as que afetaram este requisito no passado junto com os outros requisitos que tamb m foram afetados pela mesma requisi o de mudan a Se uma requisi o de mudan a do passado afetou os requisitos A e B quando se identificar que uma nova requisi o de mudan a afeta o requisito A existe a possibilidade dela tamb m afetar o requisito B Esta caracter stica tamb m auxilia na manuten o dos requisitos atualizados e consistentes requisito 3 em rela o s requisi es de mudan as j que permite identificar os requisitos de aplica o que foram afetados por uma requisi o de mudan a e de que forma eles foram afetados Esta caracter stica atende ao requisito 4 rastreabilidade das mudan as dos requisitos de aplica o A rastreabilidade entre requisi es de mudan as e requisitos de aplica o afetados essencial para que seja poss vel
127. ry Proceedings Springer Berlin Heidelberg 2001 27p ANQ 2007 Anquetil N Oliveira K M Sousa K D Dias M G B Software maintenance seen as a knowledge management issue Information and Software Technology v 49 p 515 529 2007 Dispon vel em lt http www sciencedirect com gt Acesso em 20 nov 2008 AUR 2003 Aurum A Wohlin C The fundamental nature of requirements engineering activities as a decision making process Information and Software Technology v 45 p 945 954 2003 Dispon vel em lt http www sciencedirect com gt Acesso em 11 ago 2008 BEL 2007 Belleza L An lise de ferramentas de ger ncia de requisitos com foco em manuten o cont nua 2007 59 f Trabalho Individual II Mestrado em Ci ncia da Computa o Programa de P s Gradua o em Ci ncia da Computa o da Faculdade de Inform tica Pontif cia Universidade Cat lica do Rio Grande do Sul Porto Alegre 2007 BEN 2000 Bennett K H Rajlich V T Software Maintenance and Evolution a Roadmap In International Conference on Software Engineering 2000 Limerick Ireland Proceedings 2000 CER 2007 Cerri E Um modelo de rastreabilidade entre o documento de especifica o de requisitos e o modelo de casos de uso do sistema 2007 190 f Disserta o Mestrado em Ci ncia da Computa o Programa de P s Gradua o em Ci ncia da Computa o da Faculdade de Inform tica Pontif cia Universidade Cat lica do Rio G
128. s de um modelo de sistema de ger ncia de requisitos que suporte a atualiza o e a consist ncia dos requisitos de software afetados por requisi es de mudan a O sistema de ger ncia de requisitos proposto instanciado atrav s do prot tipo apresentado no Cap tulo 5 fornece as seguintes principais funcionalidades manter a rastreabilidade entre requisi es de mudan as e os requisitos afetados pelas mesmas relacionar requisitos entre si pelos relacionamentos definidos na UML inclui estende e ceneraliza e por pr e p s condi es o registro do hist rico dos requisitos desde a sua cria o at o seu t rmino e o reuso entre requisitos de diferentes aplica es Com estas funcionalidades descritas no cap tulo 4 e demonstradas no Cap tulo 5 pode se afirmar que o objetivo geral desta pesquisa foi atingido O referencial te rico apresentado no Cap tulo 2 surgiu devido pesquisa bibliogr fica realizada sobre o tema onde os principais pontos foram considerados e apresentados O estudo de caso explorat rio realizado na empresa auxiliou na compreens o do problema e na identifica o das principais dificuldades envolvidas A instancia o do modelo proposto atrav s do prot tipo e o detalhamento do seu comportamento perante os diferentes cen rios levantados atrav s dos sistemas de exemplos apresentados no Cap tulo 5 permitiram avali lo para a confirma o do alcance dos objetivos desta pes
129. s s o requisitos que especificam as propriedades de um sistema de software tais como restri es de ambiente e implementa o desempenho depend ncia de plataformas manutenabilidade extensibilidade e confiabilidade JAC 1998 Segundo LEF 2000 requisitos nao funcionais s o tipicamente documentados em linguagem natural A falha em se cumprir um requisito n o funcional pode ser muito pior do que a falha em se cumprir um requisito funcional Muitos requisitos nao funcionais dizem respeito ao sistema como um todo Enquanto a falha em um 20 requisito funcional pode degradar parte do sistema a falha em um requisito n o funcional pode tornar todo o sistema in til SOM 2003 2 3 Ger ncia de Requisitos Sommerville SOM 2005 considera a atividade de Ger ncia de requisitos como uma das principais atividades do processo de engenharia de requisitos Atualmente tem se convic o de que mudan as em requisitos ao longo do processo de desenvolvimento de software fazem parte do processo A ger ncia de requisitos est associada ao processo de acompanhar a evolu o dos requisitos ao longo do processo de desenvolvimento SAY 2005 De acordo com KOT 1998 as principais responsabilidades da ger ncia de requisitos e Gerenciar mudan as em requisitos j aprovados e Gerenciar os relacionamentos entre os requisitos e Gerenciar as depend ncias entre o documento de requisitos e outros documentos produzidos durante o proces
130. so de Uso Alternativa 4 Editar Relacionamento Extens o O Usu rio solicita alterar um passo que representa um relacionamento extens o com outro caso de uso j cadastrado no sistema ou seja existe outro caso de uso que estende o caso de uso sendo editado O Usu rio altera a descri o do Ponto de Extens o O Sistema salva a altera o do relacionamento extens o entre os casos de uso O Sistema volta ao passo 2 da Subse o Editar Caso de Uso Alternativa 5 Adicionar Relacionamento Inclus o O Usu rio informa um passo que representa um relacionamento inclus o com outro caso de uso O Sistema executa o caso de uso Adicionar Relacionamento Inclus o O Sistema volta ao passo 2 da Subse o Editar Caso de Uso Alternativa 6 Remove Relacionamento Inclus o 99 2 O Usu rio remove um passo que representa um relacionamento inclus o com outro caso de uso j cadastrado no sistema ou seja existe outro caso de uso que inclu do pelo caso de uso sendo editado O Sistema remove o relacionamento inclus o entre os casos de uso O Sistema volta ao passo 2 da Subse o Editar Caso de Uso Alternativa 7 Adicionar Relacionamento Generaliza o O Usu rio informa um passo que representa um relacionamento de generaliza o com outro caso de uso O Sistema executa o caso de uso Adicionar Relacionamento Generaliza o O Sistema volta ao passo 2 da Subse o Editar Caso de Uso Alternativa 8 Remover Relacionam
131. so de desenvolvimento do sistema Os requisitos evoluem devido a mudan as no ambiente do sistema e devido evolu o da compreens o dos stakeholders de suas reais necessidades Novos requisitos surgem e requisitos existentes mudam em qualquer est gio do processo de desenvolvimento do sistema Isto pode causar s rios problemas para os desenvolvedores do sistema Para minimizar estas dificuldades necess rio controlar e documentar estas mudan as O impacto das mudan as deve ser avaliado e se as mudan as forem aceitas o projeto e a implementa o do sistema tamb m devem ser modificados ESP 2006 Indispens vel tarefa de ger ncia de requisitos a disponibilidade de facilidades de rastreamento SAY 2005 Um requisito rastre vel se poss vel descobrir quem sugeriu o requisito a fonte por que o requisito existe raz es e motiva es que outros requisitos est o relacionados a ele depend ncia entre requisitos e como o requisito se relaciona com outras informa es tais como arquitetura do sistema implementa o e documenta o do usu rio SOM 1998 21 Algumas pesquisas apontam que os principais motivos que levam a atrasos na entrega aumento de custos e inefici ncia de um software s o todos relacionados com pr ticas de ger ncia de requisitos LEF 2000 Existem diversos estudos relacionados ger ncia de requisitos Por exemplo DOU 2008 apresenta m todos para auxiliar os stakeholders n o t
132. software ou seja s o mais abrangentes Por ser mais espec fico com o escopo limitado ao n vel de requisitos este trabalho se aprofunda mais no t pico e prop e uma solu o para o suporte da consist ncia e atualiza o dos requisitos Esta solu o se difere pelos seguintes motivos prop e um padr o de forma o dos requisitos funcionais representados por casos de uso suporta a representa o dos relacionamentos entre os casos de uso n o s os propostos na UML mas tamb m relacionamento dos casos de uso por suas pr e p s condi es fornece a rastreabilidade entre a requisi o de mudan a e os requisitos afetados pela mesma mant m o hist rico de cada requisito do software possibilita a associa o de um mesmo requisito com mais de uma aplica o reuso Mais detalhes sobre a solu o proposta s o apresentados no pr ximo cap tulo Com estes recursos este trabalho permite o suporte atualiza o e consist ncia dos requisitos durante a manuten o O foco principal de LUC 2007 definir a rastreabilidade entre os artefatos do software de forma semi autom tica atrav s do m todo LSI Mas esta rastreabilidade n o garante que os requisitos est o definidos de forma consistente e que est o sendo atualizados a partir de cada requisi o de mudan a evolu o do software O foco principal de MOH 2008 a integra o entre as pr ticas de ger ncia de configura o e a rastreabilidade dos artefatos de
133. sos de eventos menos comuns As alternativas s o constitu das por restri es condi es que devem ser verdadeiras para que a alternativa seja executada passos da alternativa e pelo atraso caso a alternativa tenha um tempo de espera delay associado Estas informa es s o representadas no modelo pelas classes Restricao PassoCasoUso e Atraso respectivamente 48 PassoCasoUso Esta classe representa os passos do caso de uso Um passo pode ser um bloco de repeti o representados pela classe RepeteBloco ou um passo simples representados pela classe PassoSimples RepeteBloco Esta classe define blocos de repeti o Um bloco de repeti o define uma execu o iterativa de uma sequ ncia de passos do caso de uso de acordo com uma condi o e ou um atraso Blocos de repeti o s o descritos por palavras chave de repeti o tais como enquanto e at que PassoSimples Esta classe representa todos os passos do caso de uso exceto os que s o blocos de repeti o Um passo simples pode ser dos seguintes tipos passo que representa uma opera o passo de representa um desvio ou ramifica o passo que representa uma diretiva de inclus o de outro caso de uso e passo que representa uma diretiva de generaliza o de outro caso de uso Os diferentes tipos de passos dos caso de uso est o representados pelas classes PassoOperacao Ramificacao IncluiCasoUso e SessaoGeneraliza respectivamente Um passo simples pode esta
134. spende muito tempo para identificar o impacto da mudan a na aplica o e as modifica es s o feitas na aplica o sem se preocupar em atualizar a documenta o dos requisitos 4 2 Proposta A partir do problema detalhado na se o anterior desenvolveu se um Modelo Conceitual como primeiro passo para se encontrar a sua solu o O modelo representa os conceitos envolvidos no problema O modelo est demonstrado na Figura 5 O Modelo Conceitual foi desenvolvido com base nos seguintes trabalhos e Cerri CER 2007 A composi o do SRS apresentado na Figura 5 se baseia no Modelo Conceitual do SRS apresentado pela autora 41 e Som SOM 2007 A defini o dos elementos que comp em o Caso de Uso foi baseada no meta modelo de casos de uso apresentado no trabalho do autor com apenas duas exce es S o elas o Relacionamento entre as pr e p s condi es Diferente desta disserta o Som n o prop e o relacionamento direto entre pr e p s condi es Em vez disto ele prop e que o relacionamento impl cito e cria novas classes para representar estes relacionamentos lista dos casos de uso que precedem o caso de uso atual FollowList e lista dos casos de uso que sucedem o caso de uso atual UseCaseEnabling Estas duas classes definidas por Som n o ser o utilizadas pelo modelo apresentado neste trabalho o Defini o do relacionamento de generaliza o O autor n o aborda o relacionamento de genera
135. star associado com uma ou mais aplica es Nesta se o ser apresentado um exemplo de como o sistema suporta este reuso Na Figura 37 o caso de uso Submeter Requisi o de Compra aos Fornecedores da aplica o Sistema de Compra de Fornecedores inclui o caso de uso Procurar Pedido da aplica o Sistema de Vendas Da mesma forma um caso de uso de uma aplica o pode ser estendido ou generalizado por um caso de uso de outra aplica o A Figura 38 mostra outro exemplo de reuso por m atrav s do relacionamento por pr e p s condi es O caso de uso Submeter Pedido da aplica o Sistema de Vendas est relacionado por sua p s condi o com o caso de uso Submeter Requisi o de Compra aos Forecedores da aplica o Sistema de Compra de Fornecedores 81 Hist rico de Mudan a do Caso de Uso 6 Caso Uso Produto em Oferta e Cato Uso Ciente Especial w 6 Caso Uso Submeter Pedido Og Caso Uso Procurar Pedido e Jd Caso Uso Verificar Pedido a ds Caso Uso Cancelar Pedido a ds Aphca o Sistema de Pagamento 6 Aphca o Sistema de Cota o de Pedidos com Fomecedores Jd Caso Uso Submeter Requisi o de Compra aos Fomecedores 4 Inchi p E Can User Procura Pedido nanda Esa erence al a oe Conny see 6 Aplhca o Sistema de Vendas lg Requa o Mudan a Usu rio n o precisa estar autenticado no sistema para submiss o de pedido Edi o dg Cato Uso
136. stema de Vendas Condi o Produto esta am oferta amp nt a Entrar no 4 Sistema i Pedido em Oferta Pa 2 Pr condi o lt adgnd a a Condi o Clienie especial a ie 1 EM P o Procurar Pedindo i a Pr condip o d esbnelydas r RS R ci Sistema de Pagamento i Sistema de Compra de Fomecedores 3 r r a Pr condi o includes P E Werilicar Coastro do Cliente no SPC Qeineludes m Figura 16 Rela es entre os sistemas 5 3 Demonstra o dos resultados Conforme descrito na se o 4 1 2 do cap tulo anterior dos cinco requisitos listados a solu o apresentada neste trabalho se prop e a resolver quatro requisitos 1 3 4 e 5 Seguem abaixo demonstra es a partir de cen rios utilizando os sistemas da se o 5 2 para exemplifica o de como o sistema atende estes requisitos O sistema de ger ncia de requisitos est representado pelo prot tipo desenvolvido 65 5 3 1 Identifica o dos requisitos afetados por uma requisi o de mudan a Nesta se o ser o mostrados cen rios ilustrando como o sistema atende o requisito 1 atrav s do cadastro de requisi es de mudan a e da identifica o dos requisitos de aplica o que s o afetados pelas mesmas A Figura 17 mostra a tela do prot tipo onde o analista deve preencher os dados da requisi o de mudan a Ap s preencher os dados da requ
137. tado No pr ximo cap tulo ser o apresentados alguns trabalhos relacionados ao tema de pesquisa 31 3 ESTUDOS RELACIONADOS Ap s a pesquisa bibliogr fica foram encontrados alguns trabalhos relacionados ao tema de pesquisa apresentado nesta disserta o Este cap tulo apresenta uma breve descri o dos mesmos seguido das caracter sticas relevantes para este trabalho 3 1 SOME 2007 Som prop e em SOM 2007 uma formaliza o da representa o textual dos casos de uso Segundo o autor o fato dos casos de uso serem intuitivos centralizados no usu rio e Ov textuais uma das raz es para o seu sucesso Por m um certo n vel de formaliza o necess rio para automatizar o desenvolvimento incluindo a modelagem verifica o e valida o dos sistemas que se baseiam nos mesmos No n vel sint tico um meta modelo em UML e uma forma restringida de linguagem natural s o definidas para a descri o dos casos de uso A sem ntica de execu o proposta como um conjunto de Regras de Mapeamento Mapping Rules dos casos de uso bem formados para as redes de Petri B sica O trabalho de Som contribui com este trabalho de duas maneiras A representa o da descri o dos casos de uso atrav s de um meta modelo auxiliou na defini o dos elementos que constituem o caso de uso bem como na sua representa o no modelo proposto conforme descrito na se o 2 4 3 Outra contribui o deste trabalho
138. tado Proposta foi submetida ao funcion rio importancia Comentarios Frequencia 1l Cen rio Principal Adicionar Cen rio Principal Cen rios Alemativos Requisitos N o Funcionais Adicionar Requisitos N o Funcionais Salvar Caso de Uso Figura 21 Adi o do caso de uso Submeter Proposta Requisi o de Compra Ap s adicionados os casos de uso Submeter Proposta Requisi o de Compra e Aceitar Proposta do Fornecedor e Efetuar Compra o sistema atualiza a tela Casos de Uso Afetados pela Requisi o de Mudan a como mostrado na Figura 24 Os casos de uso foram adicionados rvore Aplica o x Casos de Uso O caso de uso Aceitar Proposta do Fornecedor e Efetuar Compra inclui o caso de uso Pagamento com cart o de cr dito da aplica o Sistema de Pagamento Quando o caso de uso Aceitar Proposta do Fornecedor e Efetuar Compra selecionado o sistema mostra a rela o por pr condi o que o mesmo tem com o caso de uso Submeter Proposta Requisi o de Compra Neste caso a pr condi o Proposta foi submetida ao funcion rio do caso de uso Aceitar Proposta do Fornecedor e Efetuar Compra est relacionada com a p s condi o Proposta foi submetida ao funcion rio do caso de uso Submeter Proposta Requisi o de Compra Outra observa o que deve ser feita na Figura 24 que o sistema est mostrando o hist rico de mudan as do caso de uso sel
139. te A solu o proposta auxilia na identifica o dos requisitos considerando que mostra ao analista todos os requisitos das aplica es e como eles est o relacionados inclusive propondo novos relacionamentos por pr e p s condi es e pelo hist rico de mudan as Por m a identifica o continua sendo manual Uma vez identificado que uma requisi o de mudan a afeta um caso de uso espec fico o modelo proposto pode auxiliar na identifica o dos outros casos de uso afetados a partir do hist rico de mudan as e tamb m das depend ncias entre os casos de uso O requisito 3 que corresponde manuten o dos requisitos atualizados e consistentes conforme as requisi es de mudan as tamb m foi parcialmente atendida pela solu o Parcialmente porque apesar de suportar a atualiza o e consist ncia dos requisitos este modelo n o considera o estado da requisi o de mudan a para s efetivar as altera es a partir do momento em que a requisi o de mudan a seja entregue ao usu rio 59 O requisito 4 que consiste em manter a rastreabilidade das mudan as dos requisitos de aplica o foi totalmente atendido por esta solu o atrav s do Modelo Conceitual e tamb m do recurso de versionamento O requisito 5 que consiste em suportar o rollback das altera es feitas por uma requisi o de mudan a foi atendido parcialmente pelo relacionamento entre a requisi o de mudan a e os requisitos de aplica o Com est
140. te dos requisitos para obten o do grau de Mestre em Ci ncia da Computa o Sistemas de Informa o aprovada em 18 03 09 pela Comiss o Examinadora E Prof Dr Ricardo Melo Bastos E PPGCC PUCRS Orientador PPGCC PUCRS a F Pi AAA Pio j if fi j LS Prof Dr Marcelo Soares Pimenta UFRGS Homologada em 83 70 E q E TA Conforme Ata No As sec pela Comiss o Coordenadora a a pee oy j iJ Fa A F i a 4 j if f a FU f Prof Dr Fernando Gehm Moraes Coordenador Campus Central PUC Av Ipiranga 6681 P32 sala 507 CEP 90619 900 Fone 51 3320 3611 Fax 51 3320 3621 E mail 7 pucrs br Dedico ao meu amado Alex da Silva Corr a pela paci ncia e amor AGRADECIMENTOS Em primeiro lugar quero agradecer a DEUS por estar sempre comigo e me dar for a para completar este desafio de fazer um mestrado tendo que trabalhar mais de 40 horas por semana Muito obrigada por tudo Ao amor da minha vida Alex que sempre esteve do meu lado me incentivando me ajudando a seguir em frente nesta jornada Muito obrigada pela tua paciencia e compreens o quando nos finais de semana eu tive que ficar fazendo o trabalho Ao professor Ricardo Melo Bastos um orientador sempre presente compreensivo e muito competente Um exemplo de professor a ser seguido Ao meu colega e amigo Alberto que me incentivou a fazer o mestrado ajudou a definir o tema desta disserta o e me
141. tir que o usu rio possa remover requisitos n o funcional geral afetados por uma requisi o de mudan a Atores Engenheiro de Requisitos 108 Pr condi o Usu rio est registrado no Sistema P s condi o de Sucesso Os requisitos de aplica o n o funcional geral removidos por uma Requisi o de Mudan a est o identificados no sistema Passos l O Usu rio identifica que deve remover um requisito n o funcional geral para atender requisi o de mudan a 2 O Sistema mostra a lista de requisitos n o funcional geral existentes agrupados por aplica o 3 O Usu rio seleciona um requisito para remo o 4 O sistema apresenta o hist rico de altera es deste requisito n o funcional geral como segue a Lista de requisi es de mudan a que foram implementadas no passado e que afetaram o requisito n o funcional geral b Para cada requisi o de mudan a listada o sistema deve mostrar todos os requisitos n o funcional geral de aplica es afetados pela requisi o de mudan a 5 O usu rio seleciona um requisito n o funcional geral afetado pelas requisi es de mudan as anteriores 6 O usu rio repete o passo 4 a 6 at selecionar todos os requisitos removidos pela requisi o de mudan a 7 O Sistema executa o caso de uso Remover Requisito N o Funcional Geral 8 O Sistema relaciona os requisitos n o funcional geral removidos com a requisi o de mudan a indicando que a requisi o de mudan
142. tualizados ao longo de projetos de manuten o de software realizou se uma an lise de como uma equipe de 5 Analistas de Sistemas trabalham com os requisitos de mais de 25 aplica es que passam por constante processo de evolu o na f brica de software Para cada aplica o que o grupo tem a responsabilidade de manter existe um SRS Software Requirements Specification onde est o descritos todos os requisitos da mesma A maior parte destes SRSs foram criados a partir de um processo de Engenharia Reversa A Engenharia Reversa foi realizada com o objetivo principal de adquirir conhecimento da aplica o considerando que a equipe em quest o n o tinha conhecimento pr vio das mesmas at ser designada a mant las Observou se que os requisitos funcionais dos SRSs existentes est o organizados por funcionalidade onde cada funcionalidade descrita da seguinte forma e Introdu o Objetivo da funcionalidade Cont m a descri o do objetivo geral da funcionalidade e Sequ ncia de seqii ncia de par est mulo resposta Cont m a seqii ncia de entradas e respostas do sistema para alcan ar os resultados desejados e Requisitos Associados Cont m os requisitos de entrada e sa da e requisitos n o funcionais associados 37 No processo de manuten o das aplica es seguido pela equipe est o definidas todas as fases de um processo de desenvolvimento fase de vis o planejamento desenvolvimento teste e estabiliza
143. turas das ferramentas existentes no mercado e Especificar um modelo de arquitetura que atenda s necessidades identificadas e Desenvolvimento de uma Inst ncia do modelo de arquitetura especificado atrav s de um prot tipo de ferramenta de ger ncia de requisitos Avaliar o uso do prot tipo a partir de exemplos hipot ticos 1 4 Organiza o do Volume Este volume est organizado em sete cap tulos O cap tulo 1 corresponde a esta introdu o No cap tulo 2 apresentado o referencial te rico desta pesquisa envolvendo os principais conceitos e reas do estudo engenharia de requisitos requisitos ger ncia de requisitos casos de uso e manuten o de software O cap tulo 3 apresenta os estudos relacionados com o tema de pesquisa deste trabalho Foram selecionados artigos sobre estudos em reas relacionadas ou complementares a pesquisa aqui apresentada Durante este cap tulo s o feitas considera es sobre estes trabalhos No cap tulo 4 o problema de pesquisa detalhado e o modelo de ger ncia de requisitos durante a manuten o do software apresentado No modelo proposto apresentado o Modelo Conceitual com a representa o dos principais conceitos envolvidos no problema e como estes se relacionam de forma a auxiliar no suporte a consist ncia e atualiza o dos requisitos Neste cap tulo tamb m s o apresentadas regras de consist ncia dos casos de uso e o mecanismo de versionamento dos mesmos
144. ue devem ser encontradas em um modelo de suporte atualiza o e consist ncia dos requisitos para manuten o de software IN Requisito 1 Suporte identifica o dos requisitos afetados por uma requisi o de mudan a an lise de impacto A identifica o dos requisitos afetados de forma manual baseada no conhecimento dos stakeholders considerando que uma requisi o de mudan a pode afetar mais de uma aplica o e que uma aplica o pode ter muitos requisitos dependendo de sua complexidade uma atividade muito complexa e propensa a erros Requisito 2 Suporte ao gerenciamento da concorr ncia Duas ou mais requisi es de mudan a podem afetar os mesmos requisitos de uma mesma aplica o em um mesmo per odo sendo essencial o gerenciamento da concorr ncia Requisito 3 Os requisitos de aplica es devem ser atualizados e estarem consistentes para refletirem as altera es da requisi o de mudan a Neste caso al m da atualiza o dos requisitos deve se ter cuidado para que estas atualiza es s sejam consideradas como definitivas a partir do momento que a mudan a entregue aos usu rios At este momento as 40 mudan as devem ser feitas de forma que possam ser descartadas caso a requisi o de mudan a n o seja atendida Requisito 4 Deve ser poss vel obter a rastreabilidade das mudan as dos requisitos de aplica o a fim de se ter informa es tais como a partir de qual requisi o
145. va vers o de cada requisito afetado ser gerada e a rastreabilidade entre a requisi o de mudan a e a nova vers o do requisito mantida Genter Caso de Uia max TTo O O Desericaersao Atores Veves o 1 Submeter Pedido O Cria o do Caso Chente Ver Vers o o 2 Submeter Pedido O Edi o Ciente Vet Versao Titulo Frequencia Figura 35 Hist rico do Caso de Uso Submeter Pedido 80 wc Apheac Sc Sistema de Vendas Obeta Permitir que o usu rio submeta um pedido de compra Titu o Submete Pedido Aloes Certe Pr condi es Lizu rio est autenticado no sistema P sCondi es Pedido deve ter sido gravado no sistema e marcado como confirmado a Consultar Caso de Uso Cato Uso Cen rios Requistios N o Funcionais Associados Hist rico de Mudan as Aphca o Sistema de Vendas Olbpetro Peir que o usu rio submeia um pedido de compra Titulo Submeter Pedido Allones Ciente Pr cordi es P s Londi es Pedido deve ter sido gravado no sitema marcado como confirmado Impertancia Comentanoz Fiagu ncia ii Figura 36 Detalhes das vers es do Caso de Uso Submeter Pedido 5 3 4 Reuso de Casos de Uso O modelo proposto tamb m prov a possibilidade de reuso dos casos de uso entre as diversas aplica es que auxilia no atendimento dos requisitos 1 e 3 No Modelo Conceitual apresentado na se o 4 2 1 um caso de uso pode e
146. ve as descri es e o pre o de cada produto Lota ce ope e are a Edo rider E Uso comente seo item de Vendar r mam l prera TO caso de uso come a quando o ciente seleciona submete pedido O chente fomece seu nome e endere o Se o ciente fomece apenas o CEP o sistema coloca automaticamente j O ciente fomece os c digos do produto 120 Tipo de Passo sen o i NimeodoPaso 6 Descri o do Passo O sithema calcular ot valret totais para cada produto fornecido Lista de Casos de Liso Selecione um Caso de Uso que Extende o Caso de Uso comente O caso de uso come a quando o chente seleciona submeter pedido To c enie fomece seu nome e endere o Se o ciente fomece apenas o CEP o sistema coloca automaticamente 0 ciente fomece os c digos do produto O sistema devolve as descri es e o pre o de cada produto Bl O ciente fomece ox c digos do produto O sistema devolve as descri es e o pre o de cada produto BL 3 Tela para defini o do cen rio alternativo do Caso de Uso Submeter Pedido 121 Enquardo o chente quiser peda tens laga 0 ciente fomece c digo do produto D sistema atusica o valor bolal O sistema verifica que o pagamento foi efetuado Pagamento com cant o de cr dito ii 4 Tela para defini o dos requisitos
147. ware Outra 34 diferen a que neste trabalho o autor prop e a rastreabilidade de todos os artefatos enquanto que neste trabalho o enfoque apenas artefatos de requisitos 3 4 MOHAN XU CAO e RAMESH 2008 Ger ncia de configura o do software ou Software Configuration Management SCM e rastreabilidade s o duas pr ticas importantes no desenvolvimento do software que suporta a evolu o do sistema e o controle de mudan as SCM auxilia a gerenciar a evolu o dos artefatos de software e suas documenta es enquanto que a rastreabilidade auxilia a gerenciar o conhecimento sobre o processo do desenvolvimento dos artefatos Neste trabalho apresentada uma solu o que integra a rastreabilidade e SCM a fim de suportar o gerenciamento de mudan as durante o desenvolvimento e evolu o dos artefatos de software apresentada uma ferramenta chamada Tracer que suporta a integra o destas duas pr ticas Tracer se caracteriza por uma ferramenta de rastreabilidade integrada com o MS Visual SourceSafe O trabalho de MOH 2008 tamb m apresenta uma proposta de solu o de escopo mais abrangente do que esta disserta o pois prop e uma solu o que suporta a ger ncia de todos os artefatos do software ao longo de sua evolu o No entanto o trabalho desta disserta o por ter o foco apenas em requisitos apresenta uma solu o mais aprofundada para suportar a consist ncia e atualiza o dos requisitos do software ao lo
148. ware est o se dando conta que seu principal artefato sua pr pria experi ncia e o conhecimento ganho a partir dela Elas est o dando passos em dire o a estabelecer bases de conhecimento corporativo que tornam este artefato tang vel Os requisitos s o pontos chave para esta base de conhecimento Portanto existe a necessidade de um movimento do foco de ger ncia de requisitos ao longo do ciclo de vida de um projeto para o gerenciamento dos requisitos como uma contribui o cont nua para o conhecimento geral da organiza o FIN 2000 ANQ 2007 chama a aten o para a import ncia da dissemina o do conhecimento das aplica es no processo de manuten o de software A ger ncia de requisitos em processos de manuten o cont nua uma atividade que acompanha a evolu o dos requisitos ao longo do ciclo de vida de uma aplica o ou produto A fim de compreender as dificuldades relacionadas com a ger ncia dos requisitos em processos de manuten o realizou se um estudo de caso explorat rio detalhado na se o 4 1 1 deste trabalho junto a uma equipe de Engenheiros de Requisitos em uma f brica de software que pertence a uma empresa multinacional 14 Esta pesquisa visa encontrar uma solu o para a defici ncia identificada na literatura e Ilustrada no caso particular da empresa no suporte manuten o dos requisitos de aplica es consistentes e atualizados ao longo do Ciclo de Vida da Aplica o 1 1 An l
149. xiliando na compreens o do software na an lise de impacto e reuso de softwares existentes PAL 2000 A principal defici ncia de sistemas de ger ncia de artefatos de software a falta de gera o autom tica ou semi autom tica de liga es de rastreabilidade e manuten o destas liga es Neste trabalho o autor prop e a integra o de um sistema de ger ncia de artefato conhecido como ADAMS ADvanced Artefact Management System proposto em LUC 2004 com uma ferramenta de recupera o de rastreabilidade baseada numa t cnica de Recupera o de Informa o IR Information Retrieval denominada LSI Latent Semantic Indexing As liga es de rastreabilidade armazenadas no ADAMS s o teis para an lise de impacto e manuten o durante a evolu o do software notificando os engenheiros que um artefato tem que ser modificado por consequ ncia de mudan as aplicadas com artefatos que eles dependem O sistema ADAMS auxilia na manuten o dos artefatos consistentes atrav s das liga es de rastreabilidade entre os mesmos Quando uma mudan a afeta um artefato por exemplo um caso de uso existe a possibilidade de afetar os artefatos dependentes desse primeiro identificado A representa o da depend ncia entre os artefatos se d atrav s das liga es de rastreabilidade Seguem abaixo algumas conclus es identificadas pelo autor ap s a avalia o da ferramenta e O uso da ferramenta de recupera o da rastre

Baixar/Abrir

Contents

Download Pdf Manuals

Related Search

Related Contents