Home

Notas de Aula - Engenharia de Requisitos - Informática

1. x 7 Modelo de Dominio Projeto de Infraestrutura FE de Dom nio I 1 Arquitetura de Software e Sistema Modelos da Aplica o Projeto dos Componentes Espec fico da Arquitetura Engenharia de Sistema Desenvolvimento com Re so Figura 8 2 Abordagens para e com Re so na Engenharia de Dom nio Nuseibeh e Easterbrook 2000 em seu mapa para o futuro da Engenharia de Requisitos colocaram o re so de modelos como um dos maiores desafios da Engenharia de Requisitos para os anos 2000 Eles acreditavam que para muitos dom nios de aplica o modelos de refer ncia para especifica o de requisitos seriam desenvolvidos de modo que o Engenharia de Requisitos Notas de Aula Cap tulo 8 Qualidade e Agilidade em Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 167 esfor o de desenvolver modelos de requisitos a partir do zero fosse reduzido De alguma forma isso de fato vem ocorrendo ainda que n o propriamente na forma de modelos de refer ncia mas por meio da constru o de diversas ontologias de dom nio e pelo crescente n mero de padr es de an lise dispon veis FALBO et al 2007 assuntos discutidos a seguir 8 3 2 Ontologias de Dom nio Uma grande dificuldade atual no desenvolvimento de sistemas para apoiar processos de neg cio em um mesmo dom nio sobretudo quando os mesmos precisam trabalhar de maneira integrada a exist ncia de
2. Dados de Identifica o Incorretos Sal 1 e 2 tentativas Uma mensagem de erro mostrada para o cliente Retornar ao passo 3 5a 2 3 tentativa bloquear o cart o e abortar a transa o l a 5 Cancelamento O cliente solicita o cancelamento da transa o e a transa o abortada Nome Validar Cart o por An lise de Retina Fluxo de Eventos Normal 3 O caixa autom tico solicita que o cliente se posicione corretamente para a captura da imagem da retina 4 O caixa autom tico retira uma foto da retina do cliente 5 O caixa autom tico envia os dados do cart o e a foto da retina para o sistema banc rio para valida o Nome Validar Cart o por Autentica o de Senha Fluxo de Eventos Normal 3 O caixa autom tico solicita a senha 4 O cliente informa a senha 5 O caixa autom tico envia os dados do cart o e a senha para o sistema banc rio para valida o Figura 5 16 Descri o do Caso de Uso Validar Cart o e suas Especializa es Engenharia de Requisitos Notas de Aula Cap tulo 5 Modelagem de Casos de Uso Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 112 Nome Validar Cart o Fluxo de Eventos Normal 1 O cliente insere o cart o no caixa autom tico 2 O caixa autom tico analisa o cart o e verifica se ele aceit vel 3 Validar cart o 4 O caixa autom tico solicita que o cliente informe o tipo de transa o
3. Tipos de dados geralmente n o s o representados graficamente em um modelo conceitual estrutural de modo a torn lo mais simples Na maioria das situa es basta descrever os tipos de dados espec ficos de dom nio no Dicion rio de Dados do Projeto Contudo se necess rio eles podem ser representados graficamente usando o s mbolo de classe estereotipado com a palavra chave lt lt dataType gt gt Tipos enumerados tamb m podem ser representados usando o s mbolo de classe mas com o estere tipo lt lt enumeration gt gt sendo que ao inv s de apresentar atributos de um tipo de dados enumeram se os valores poss veis da enumera o A Figura 6 2 ilustra a nota o de tipos de dados na UML lt pnumeration gt DiaSemana Cpf Ter a base String Quarta digitoverificador String Quinta sexta S bado Domingo Figura 6 2 Nota o de Tipos de Dados na UML Uma d vida t pica e recorrente na modelagem estrutural se um determinado item de informa o deve ser modelado como uma classe ou como um atributo Para que o item seja considerado uma classe ele tem de passar nos crit rios de inclus o no modelo discutidos na se o anterior Entretanto h alguns itens de informa o que passam nesses crit rios mas que ainda assim podem ser melhor modelados como atributos tendo como tipo um tipo de dado complexo espec fico de dom nio Um atributo deve capturar um conceito at mico i e um nico valor ou um
4. e Deseja se assegurar que os problemas com o sistema corrente foram identificados e tratados em entrevistas que se seguem Uma vez que question rios e entrevistas seguem uma abordagem pergunta resposta seria bastante razo vel pensar que as considera es feitas para entrevistas aplicam se tamb m para question rios Contudo importante ressaltar que h diferen as fundamentais entre essas t cnicas e portanto outros aspectos devem ser considerados Em primeiro lugar entrevistas permitem intera o direta com o entrevistado a respeito das quest es e seus significados Em uma entrevista o analista pode refinar uma quest o definir um termo obscuro alterar o curso do questionamento e controlar o contexto de modo geral Isto n o necessariamente verdade para um question rio e portanto o planejamento de um question rio e de suas quest es deve ser mais cuidadoso Assim um question rio deve ter quest es claras e n o amb guas fluxo bem definido e administra o planejada em detalhes Al m disso devem se levantar antecipadamente as d vidas das pessoas que v o respond lo KENDALL KENDALL 2010 Em rela o s cinco perguntas b sicas valem as seguintes considera es e Porque assim como os demais m todos a primeira coisa a ser feita estabelecer os objetivos de um question rio Conforme citado anteriormente question rios podem ser usados para quantificar o que foi levantado com outros m todos
5. Engenharia de Requisitos Notas de Aula Cap tulo 2 Engenharia de Requisitos de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 17 importante real ar a diferen a entre verifica o e valida o O objetivo da verifica o assegurar que o software esteja sendo constru do de forma correta Deve se verificar se os artefatos produzidos atendem aos requisitos estabelecidos e se os padr es organizacionais de produto e processo foram consistentemente aplicados Por outro lado o objetivo da valida o assegurar que o software que est sendo desenvolvido o software correto ou seja assegurar que os requisitos e o software deles derivado atendem ao uso proposto ROCHA MALDONADO WEBER 2001 No caso de requisitos a verifica o feita sobretudo em rela o consist ncia entre requisitos e modelos e conformidade com padr es organizacionais de documenta o de requisitos J a valida o tem de envolver a participa o de usu rios e clientes pois somente eles s o capazes de dizer se os requisitos atendem aos prop sitos do sistema Nas atividades de V amp V de requisitos examinam se os documentos de requisitos para assegurar que PRESSMAN 2006 KOTONYA SOMMERVILLE 1998 WIEGERS 2003 1 todos os requisitos do sistema tenham sido declarados de modo n o amb guo 11 as inconsist ncias conflitos omiss es e erros tenham sido detectados e corrigidos iii os do
6. bastante til em situa es em que se pode definir um caso de uso significativo com recursos adicionais O comportamento b sico capturado no caso de uso base e os recursos adicionais nos casos de uso de extens o Use a rela o de extens o quando o sistema puder ser usado em diferentes configura es algumas com os recursos adicionais e outras sem eles BLAHA RUMBAUGH 2006 e Tanto a inclus o quanto a extens o podem ser usadas para dividir o comportamento em partes menores A inclus o entretanto implica que o comportamento inclu do uma parte necess ria de um sistema configurado mesmo que seu comportamento n o seja executado todas as vezes ou seja mesmo que o comportamento inclu do esteja associado a uma condi o A extens o por sua vez implica que o sistema sem o comportamento adicionado pela extens o significativo BLAHA RUMBAUGH 2006 5 5 Trabalhando com Casos de Uso Para se utilizar a modelagem de casos de uso para o refinamento de requisitos de usu rio em requisitos de sistema necess rio proceder um exame detalhado do processo de neg cio a ser apoiado pelo sistema Assim atividades de levantamento de requisitos como entrevistas observa o workshop de requisitos e cen rios dentre outras certamente acontecer o em paralelo com a modelagem de casos de uso Uma boa maneira de trabalhar com casos de uso consiste em a partir dos requisitos funcionais de usu rio descritos no Documento d
7. es s o influenciadas por considera es pol ticas e os requisitos s o definidos em fun o da posi o e da personalidade dos indiv duos e n o em fun o de argumentos e raz es KOTONYA SOMMERVILLE 1998 A maior parte do tempo da negocia o utilizada para resolver conflitos de requisitos Quando discuss es informais entre analistas especialistas de dom nio e usu rios n o forem suficientes para resolver os problemas necess ria a realiza o de reuni es de negocia o que envolvem KOTONYA SOMMERVILLE 1998 e Discuss o os requisitos que apresentam problemas s o discutidos e os interessados presentes opinam sobre eles Engenharia de Requisitos Notas de Aula Cap tulo 2 Engenharia de Requisitos de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 15 e Prioriza o requisitos s o priorizados para identificar requisitos cr ticos e ajudar nas decis es e planejamento e Concord ncia solu es para os problemas s o identificadas mudan as s o feitas e um acordo sobre o conjunto de requisitos acertado 2 2 3 Documenta o de Requisitos Os requisitos e modelos capturados nas etapas anteriores devem ser descritos e apresentados em documentos A documenta o portanto uma atividade de registro e oficializa o dos resultados da engenharia de requisitos Como resultado um ou mais documentos devem ser produzidos Uma boa documenta o fornece muito
8. o a ser efetuada A E Fluxos de Eventos de Exce o 2a O cart o n o aceit vel Se o cart o n o aceit vel seja porque sua tarja magn tica n o pass vel de leitura seja porque de um tipo incompat vel uma mensagem de erro de leitura mostrada e se retorna ao passo 1 5a Senha incorreta Sal 1 e 2 tentativas Uma mensagem de erro mostrada para o cliente Retornar ao passo 3 5a 2 3 tentativa bloquear o cart o e abortar a transa o l a 5 Cancelamento O cliente solicita o cancelamento da transa o e a transa o abortada Figura 5 8 Descri o do Caso de Uso Validar Cart o Nome Efetuar Saque Fluxo de Eventos Normal 1 Incluir Validar Cart o O cliente seleciona a op o saque O caixa autom tico solicita que seja informada a quantia O cliente informa a quantia a ser sacada O caixa autom tico envia uma requisi o para o sistema banc rio para que seja efetuado um saque na quantia especificada 6 As notas s o preparadas e liberadas e od Fluxos de Eventos de Exce o 5a Saque n o autorizado Uma mensagem de erro exibida e a opera o abortada 6a N o h dinheiro suficiente dispon vel no caixa eletr nico Uma mensagem de erro exibida e a opera o abortada l a 3 Cancelamento O cliente pode cancelar a transa o enquanto o saque n o for autorizado pelo sistema banc rio A transa o abortada
9. o fornece com seu fornecedor Esse novo produto considerado um evento de dom nio porque o conjunto de cinco eventos estruturais que o comp e visto como um evento nico muito mais f cil para um usu rio dizer ao sistema que o evento de dom nio ocorreu do que dizer explicitamente cada um dos eventos estruturais Engenharia de Requisitos Notas de Aula Cap tulo 7 Modelagem Din mica Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 141 codigo valor quantidadeEstoque Fornecedor fornece P gt Figura 7 1 Fragmento do Modelo Estrutural de um Sistema de Controle de Produtos Cada evento de dom nio possui um conjunto de eventos estruturais chamado de efeito do evento A correspond ncia entre eventos e seus efeitos dada por uma express o de mapeamento O efeito do evento pode ser definido segundo duas abordagens a abordagem de p s condi o e a abordagem procedimental Na abordagem de p s condi o o efeito de um evento definido por uma condi o da base de informa es do sistema que deve ser satisfeita ap s a aplica o do efeito do evento Na abordagem procedimental o efeito de um evento definido por um procedimento indicando os eventos estruturais que comp em o evento de dom nio OLIVE 2007 Neste texto enfocamos apenas a abordagem procedimental Na abordagem procedimental quando o paradigma orientado a objetos adotado o efeito de um evento definido
10. uma linguagem de modelagem n o um m todo de desenvolvimento OO Os m todos consistem pelo menos em princ pio de uma linguagem de modelagem e um procedimento de uso dessa linguagem A UML n o prescreve explicitamente esse procedimento de utiliza o Assim a UML deve ser aplicada no contexto de um processo lembrando que dom nios de problemas e projetos diferentes podem requerer processos diferentes 4 3 O Paradigma Orientado a Objetos Para conduzir o processo de engenharia de requisitos sobretudo a modelagem conceitual estrutural necess rio adotar um paradigma de desenvolvimento Um dos paradigmas mais adotados atualmente a orienta o a objetos OO Segundo esse paradigma o mundo visto como sendo composto por objetos onde um objeto uma entidade que combina estrutura de dados e comportamento funcional No paradigma OO os sistemas s o modelados como objetos que interagem A orienta o a objetos oferece um n mero de conceitos bastante apropriados para a modelagem de sistemas Os modelos baseados em objetos s o teis para a compreens o de problemas para a comunica o com os especialistas e usu rios das aplica es e para a realiza o das tarefas ao longo do processo de desenvolvimento de software O paradigma OO utiliza uma perspectiva humana de observa o da realidade incluindo objetos classifica o e compreens o hier rquica Engenharia de Requisitos Notas de Aula Cap tulo 4 An lise
11. condi es devem ser escritas como uma simples asser o sobre o estado do mundo no momento em que o caso de uso inicia COCKBURN 2005 Muitas vezes uma pr condi o para ser atendida requer que um outro caso de uso j executado tenha estabelecido essa pr condi o Contudo um erro bastante comum escrever como uma pr condi o algo que frequentemente mas n o necessariamente verdadeiro COCKBURN 2005 Seja o caso de uma locadora de v deos em que clientes em atraso n o podem locar novos itens at que regularize suas pend ncias Neste caso uma pr condi o do tipo cliente n o est em atraso como pr condi o de um caso de uso efetuar loca o inadequada Observe que a identifica o do cliente parte do caso de uso efetuar loca o e portanto n o poss vel garantir que o cliente n o est em atraso antes de iniciar o caso de uso Esta situa o tem de ser tratada como uma exce o e n o como uma pr condi o As se es de requisitos e classes relacionados s o importantes para a ger ncia de requisitos A primeira estabelece um rastro entre casos de uso e os requisitos de usu rio documentados no Documento de Requisitos permitindo em um primeiro momento analisar se algum requisito n o foi tratado Em um segundo momento quando uma altera o em um requisito solicitada poss vel usar essa informa o para analisar o impacto da altera o Para documentar os requisitos
12. BASS L CLEMENTS P KAZMAN R Software Architecture in Practice Second edition Addison Wesley 2003 CARDOSO E S Uma Compara o entre Requisitos de Sistema Gerados por T cnicas de Modelagem de Processos com Requisitos de Sistema Gerados por T cnicas Convencionais de Engenharia de Requisitos Projeto de Gradua o Engenharia de Computa o Universidade Federal do Esp rito Santo 2007 CARDOSO E ALMEIDA J P A GUIZZARDI G Uma Experi ncia com Engenharia de Requisitos baseada em Modelos de Processos In Proceedings of the XI Iberoamerican Workshop on Requirements Engineering and Software Environments IDEAS 2008 Recife 2008 CARVALHO E A Engenharia de Processos de Neg cio e a Engenharia de Requisitos An lise e Compara es de Abordagens e M todos de Elicita o de Requisitos de Sistemas Orientada por Processos de Neg cio Disserta o de Mestrado Programa de P s Gradua o em Engenharia de Produ o COPPE UFRJ Rio de Janeiro 2009 DAVENPORT T H Mission Critical realizing the promise of enterprise systems lst edition Boston Harvard Business School Press 2000 FRYE D W GULLEDGE T R End to end Business Process Scenarios Industrial Management amp Data Systems v 107 n 6 pp 749 761 2007 ISO IEC 9126 1 Software Engineering Product Quality Part 1 Quality Model 2001 ISO IEC TR 9126 2 2003 Software Engineering Product Quality Part 2 External
13. Em Atraso e Quebrado s o de fato subestados do estado Em Uso e portanto transi es comuns por exemplo aquelas provocadas pelo evento Devolver Carro s o repetidas Isso torna o modelo mais complexo e fica claro que esta solu o representando diretamente os subestados e omitindo o estado composto n o escal vel para sistemas que possuem muitos subestados levando a diagramas confusos e desestruturados OLIV 2007 A Figura 7 7 mostra uma solu o mais indicada em que tanto o estado composto quanto seus subestados s o mostrados no mesmo diagrama Uma outra op o ocultar a decomposi o do estado composto mantendo o diagrama como o mostrado na Figura 7 4 e mostrar essa decomposi o em um diagrama de estados separado Engenharia de Requisitos Notas de Aula Cap tulo 7 Modelagem Din mica Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 148 Vender Carro Devolver Carro Devolver Carro Devolver Carro Receber Carro Vindo de Outra Localidade Transferir Carro para Outra Localidade Em Prepara o Enviar C rro para Manuten o Liberan Carro para Uso Retirar Carro dataCorrente gt dataDevolucaoPrevista Em Uso Normal Reportar Defeitojem Carro Figura 7 6 Diagrama de Estados da Classe Carro Disponibilidade com Subestados de Em Uso adaptado de OLIVE 2007 Se um objeto est em um estado composto ent o ele deve estar tam
14. Entretanto enquanto a an lise de requisitos convencional enfoca a modelagem dos aspectos do dom nio que s o relevantes para um sistema espec fico a an lise de dom nio mais abrangente e visa capturar elementos de informa o do dom nio potencialmente relevantes para o desenvolvimento de diversos sistemas neste dom nio estando portanto em n vel mais alto de abstra o Em outras palavras ao inv s de explorar requisitos de uma aplica o espec fica na an lise de dom nio os requisitos explorados dizem respeito a uma fam lia de aplica es de uma determinada rea ARANGO PRIETO D AZ 1994 Neste sentido pode se considerar que a An lise de Dom nio direciona a Engenharia de Requisitos pois seus modelos de dom nio Engenharia de Requisitos Notas de Aula Cap tulo 8 Qualidade e Agilidade em Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 166 mais abstratos fornecem uma base para o trato com requisitos no contexto de um projeto espec fico Para se fazer uma an lise de dom nio pode se trabalhar de maneira an loga an lise de requisitos convencional consultando se especialistas do dom nio e modelando o conhecimento capturado de modo que esse conhecimento possa ser reutilizado nos v rios projetos que fa am parte desse dom nio ROBERTSON ROBERTSON 2006 H ainda diversos m todos de an lise de dom nio os quais procuram explorar as especificidades dessa atividad
15. Para tal o processo de ger ncia de requisitos deve incluir as seguintes atividades ilustradas na Figura 2 3 WIEGERS 2003 controle de mudan as controle de vers o acompanhamento do estado dos requisitos e rastreamento de requisitos Ger ncia de Requisitos Acompanhar o estado de requisitos Definir poss veis estados para um requisito Armazenar os estados de cada requisito Documentar os estados de todos os requisitos Controle de Mudan as Controle de Vers o Rastrear requisitos Definir liga es com outros requisitos Definir liga es com outros elementos Propor mudan as Analisar impacto Tomar decis es Atualizar documentos de Requisitos Atualizar plano de projeto Can o I I IIIIIIiI Definir o esquema de identifica o de vers o Identificar vers es do documento de requisitos Identificar vers o de cada requisito E Figura 2 3 Atividades da Ger ncia de Requisitos WIEGERS 2003 O controle de mudan a define os procedimentos processos e padr es que devem ser utilizados para gerenciar as altera es de requisitos assegurando que qualquer proposta de mudan a seja analisada conforme os crit rios estabelecidos pela organiza o KOTONYA SOMMERVILLE 1998 Mudan as podem ser necess rias em diferentes momentos e por diferentes raz es De maneira geral o controle de mudan as envolve atividades como KOTONYA
16. Seu objetivo estabelecer um conjunto acordado de requisitos completos consistentes e sem ambiguidades que possa ser usado como base para as demais atividades do processo de desenvolvimento de software KOTONYA SOMMERVILLE 1998 De forma resumida pode se dizer que a an lise atende a dois prop sitos principais i prover uma base para o entendimento e concord ncia entre clientes e desenvolvedores sobre o que o sistema deve fazer e ii prover uma especifica o que guie os desenvolvedores na demais etapas do desenvolvimento sobretudo no projeto implementa o e testes do sistema PFLEEGER 2004 O processo de engenharia de requisitos dominado por fatores humanos sociais e organizacionais Ele envolve pessoas de diferentes reas de conhecimento e com objetivos individuais e organizacionais diferentes Dessa forma comum que cada indiv duo tente influenciar os requisitos para que seu objetivo seja alcan ado sem necessariamente alcan ar os objetivos dos demais KOTONYA SOMMERVILLE 1998 Problemas e conflitos encontrados nos requisitos devem ser listados Usu rios clientes especialistas de dom nio e engenheiros de requisitos devem discutir os requisitos que apresentam problemas negociar e chegar a um acordo sobre as modifica es a serem feitas Idealmente as discuss es devem ser governadas pelas necessidades da organiza o incluindo o or amento e o cronograma dispon veis No entanto muitas vezes as negocia
17. a UML considera dois tipos de associa es especiais entre objetos composi o e agrega o Ambos representam rela es todo parte A agrega o uma forma especial de associa o que especifica um relacionamento entre um objeto agregado o todo e seus componentes as partes A composi o por sua vez uma forma de agrega o na qual o tempo de vida do todo e das partes coincidente As partes podem at ser criadas ap s a cria o do todo mas uma vez criadas vivem e morrem com o todo Uma parte pode ainda ser removida explicitamente antes da morte do todo BOOCH RUMBAUGH JACOBSON 2006 Generaliza o Especializa o Muitas vezes um conceito geral pode ser especializado adicionando se a ele novas caracter sticas Seja o exemplo do conceito de estudante no contexto de uma universidade De modo geral h caracter sticas que s o intr nsecas a quaisquer estudantes da universidade Entretanto poss vel especializar esse conceito para mostrar especificidades de subtipos de estudantes tais como estudantes de gradua o e estudantes de p s gradua o De maneira inversa pode se extrair de um conjunto de conceitos caracter sticas comuns que quando generalizadas formam um conceito geral Por exemplo ao se avaliar os conceitos de carros motos caminh es e nibus pode se notar que eles t m caracter sticas comuns que podem ser generalizadas em um supertipo ve culo automotor terrestre As abstra es de
18. cada vez que um paciente tratado em uma unidade m dica diferente tem se um tratamento Esta pode contudo n o ser precisamente a concep o do problema original Poder se ia imaginar que um tratamento um tratamento de um paciente em v rias unidades m dicas A classe de associa o n o captura isso Assim um modelo mais fiel ao dom nio aquele que representa Tratamento como uma classe do tipo evento a ser lembrado e que est relacionada com Paciente e Unidade M dica da forma mostrada na Figura 6 13 b Engenharia de Requisitos Notas de Aula Cap tulo 6 Modelagem Conceitual Estrutural Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 133 P Paciente 0 o sua Figura 6 13 Classes Associativas x Classes do Tipo Evento a Ser Lembrado At o momento todas as associa es mostradas foram associa es bin rias i e associa es envolvendo duas classes Mesmo o exemplo da Figura 6 9 Disciplina tem como pr requisito Disciplina ainda uma associa o bin ria na qual a mesma classe desempenha dois pap is diferentes disciplina que possui pr requisito e disciplina que pr requisito Entretanto associa es n rias s o tamb m poss veis ainda que bem menos corriqueiramente encontradas Uma associa o tern ria por exemplo envolve tr s classes como ilustra o exemplo da Figura 6 14 Nesse exemplo est se dizendo que fornecedores podem fornecer produtos para certos
19. cnicas de levantamento de requisitos dentre elas entrevistas cen rios observa o reutiliza o de requisitos e prototipagem Em WIEGERS 2003 h v rios cap tulos que abordam temas discutidos nestas notas de aula Sugere se em especial a leitura dos cap tulos 5 6 7 9 10 12 e 13 O Cap tulo 5 Establishing the Product Vision and Project Scope discute a estrutura de um documento de Engenharia de Requisitos Notas de Aula Cap tulo 3 Levantamento de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 67 escopo e vis o que documenta preliminarmente os requisitos de maneira an loga ao documento de requisitos discutido neste texto O Cap tulo 6 Finding the Voice of the Customer discute dentre outros fontes de requisitos classes de usu rios e seus representantes O Cap tulo 7 Hearing the Voice of the Customer discute a t cnica de workshop de requisitos e a classifica o das informa es obtidas de clientes e usu rios O Cap tulo 9 Playing by the Rules trata de regras de neg cio seus tipos e como document las O Cap tulo 10 Documenting the Requirements discute a estrutura de um documento de especifica o de requisitos que detalha os requisitos de maneira an loga ao documento de especifica o de requisitos discutido neste texto Al m disso este cap tulo discute como rotular e escrever requisitos O Cap tulo 12 Beyound Functional
20. descrevem o comportamento completo do assunto O assunto exibido em um diagrama de casos de uso como um ret ngulo envolvendo os casos de uso que o comp em O nome do assunto sistema ou subsistema pode ser mostrado dentro do ret ngulo e Ator representa um conjunto coerente de pap is que os usu rios ou outros sistemas desempenham quando interagem com os casos de uso Tipicamente um ator representa um papel que um ser humano um dispositivo de hardware ou outro sistema desempenha com o sistema em quest o Atores n o s o parte do sistema Eles residem fora do sistema Atores s o representados por um cone de homem com o nome colocado abaixo do cone e Caso de Uso representa uma funcionalidade que o sistema deve prover Casos de uso s o parte do sistema e portanto residem dentro dele Um caso de uso representado por uma elipse com o nome do caso de uso dentro ou abaixo dela Engenharia de Requisitos Notas de Aula Cap tulo 5 Modelagem de Casos de Uso Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 92 e Relacionamentos de Depend ncia Generaliza o e Associa o s o usados para estabelecer relacionamentos entre atores entre atores e casos de uso e entre casos de uso Assunto Caso de Uso 1 Ator 1 Caso de Uso 2 Ator 1a Ator 2 Caso de Uso 3 Figura 5 1 Diagrama de Casos de Uso Conceitos e Nota o Atores s podem estar conectados a casos de uso por meio de asso
21. dulos gerenci veis para fins de prototipagem n o necess rio e muitas vezes nem desej vel construir um sistema completo e Construa o prot tipo rapidamente a constru o de um prot tipo durante as fases de levantamento e an lise de requisitos n o pode consumir tempo em demasia caso contr rio perde sua finalidade Para acelerar a constru o use ferramentas adequadas e Modifique o prot tipo em itera es sucessivas o prot tipo deve ser alterado em dire o s necessidades do usu rio Cada modifica o requer uma nova avalia o e Enfatize a interface com o usu rio as interfaces do prot tipo devem permitir que o usu rio interaja facilmente com o sistema Um m nimo de treinamento deve ser requerido Sistemas interativos com interfaces gr ficas s o muito indicados prototipagem A prototipagem pode trazer uma s rie de benef cios dentre eles KENDALL KENDALL 2010 e Permite alterar o sistema mais cedo no desenvolvimento adequando o mais de perto s necessidades do usu rio menor custo de uma altera o e Permite descartar um sistema quando este se mostrar inadequado an lise de viabilidade Engenharia de Requisitos Notas de Aula Cap tulo 3 Levantamento de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 52 Possibilita desenvolver um sistema que atenda mais de perto as necessidades e expectativas dos usu rios na medida em que permite uma intera
22. ficos desses atributos na forma de cen rios Engenharia de Requisitos Notas de Aula Cap tulo 4 An lise de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 86 Por fim o Cap tulo 2 de BOOCH RUMBAUGH JACOBSON 2006 Introdu o UML apresenta uma vis o geral da UML incluindo uma breve apresenta o de seu metamodelo descrevendo seus itens estruturais comportamentais de agrupamento e de anota o O Cap tulo 7 Diagramas faz uma breve apresenta o dos principais diagramas da UML e o Cap tulo 12 Pacotes trata de pacotes e diagramas de pacotes Refer ncias do Cap tulo AURUM A WOHLIN C Engineering and Managing Software Requirements Springer Verlag 2005 BASS L CLEMENTS P KAZMAN R Software Architecture in Practice Second edition Addison Wesley 2003 BLAHA M RUMBAUGH J Modelagem e Projetos Baseados em Objetos com UML 2 Elsevier 2006 BOOCH G Object Oriented Analysis and Design with Applications 2 edition Benjamin Cummings Publishing Company Inc 1994 BOOCH G RUMBAUGH J JACOBSON I UML Guia do Usu rio 2a edi o Elsevier Editora 2006 ISO IEC 9126 1 Software Engineering Product Quality Part 1 Quality Model 2001 ISO IEC TR 9126 2 2003 Software Engineering Product Quality Part 2 External Metrics 2003a ISO IEC TR 9126 3 2003 Software Engineering Product Quality Part 3 Intern
23. model los e descrev los com diferentes n veis de precis o O seguinte processo resume a abordagem descrita anteriormente 1 Listar atores e casos de uso relacionados neste momento montada apenas uma lista dos atores associados aos casos de uso de seu interesse Apenas o nome do caso de uso indicado 2 Para cada caso de uso identificado fazer uma descri o sucinta do mesmo Essa descri o deve conter em ess ncia o objetivo do caso de uso Elaborar um ou mais diagramas de casos de uso 4 Revisar a exatid o e a completude do conjunto de casos de uso com os interessados e priorizar os casos de uso 5 Definir o formato de descri o de caso de uso a ser usado e o correspondente modelo de descri o de caso de uso a ser adotado para cada caso de uso Engenharia de Requisitos Notas de Aula Cap tulo 5 Modelagem de Casos de Uso Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 115 6 Definir os fluxos de eventos principais a serem comportados pelo caso de uso de maneira an loga ao passo 1 apenas uma lista dos fluxos de eventos principais elaborada sem descrev los ainda 7 Descrever cada um dos fluxos principais de eventos do caso de uso segundo o modelo de descri o de caso de uso estabelecido no passo anterior De acordo com o modelo predefinido levantar informa es adicionais como pr condi es e requisitos relacionados 8 Identificar fluxos alternativos neste
24. o Figura 7 11 Nota o B sica da UML para Diagramas de Atividades Os elementos da Figura 7 11 s permitem modelar sequ ncias de atividades Contudo a maioria dos fluxos de trabalho envolve fluxos alternativos concorrentes e ou iterativos Para representar essas estruturas de controle s o necess rios outros elementos de modelo Em diagramas de atividades da UML fluxos alternativos concorrentes e ou iterativos podem ser representados por meio de desvios ou ramifica es bifurca es e uni es e regi es de expans o respectivamente Um desvio ou ramifica o permite especificar caminhos alternativos a serem seguidos tomando por base alguma express o booleana Uma ramifica o possui um fluxo de entrada e dois ou mais de sa da Em cada fluxo de sa da colocada uma express o booleana a qual avaliada quando o controle atinge a ramifica o As condi es n o podem se sobrepor pois sen o o fluxo de controle poderia seguir por mais de um caminho o que n o admiss vel em uma ramifica o Al m disso elas t m de cobrir todas as possibilidades pois caso contr rio o fluxo de controle pode ficar sem ter para onde seguir em alguma situa o Para evitar esse problema pode se utilizar a condi o else a qual satisfeita caso nenhuma outra condi o seja satisfeita BOOCH RUMBAUGH JACOBSON 2006 BLAHA RUMBAUGH 2006 Uma ramifica o representada na UML por um losango Quando dois caminhos de c
25. o dos processos a serem apoiados Al m disso o controle de informa es que o neg cio precisa gerenciar para apoiar os processos de neg cio tamb m deve dar origem a requisitos funcionais representando atividades custodiais cadastros Engenharia de Requisitos Notas de Aula Cap tulo 3 Levantamento de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 61 3 4 2 Escrevendo Regras de Neg cio Toda organiza o opera de acordo com um extenso conjunto de pol ticas corporativas leis padr es industriais e regulamenta es governamentais Tais princ pios de controle s o coletivamente designados por regras de neg cio Uma regra de neg cio uma declara o que define ou restringe algum aspecto do neg cio com o prop sito de estabelecer sua estrutura ou controlar ou influenciar o comportamento do neg cio WIEGERS 2003 Sistemas de informa o tipicamente precisam fazer cumprir as regras de neg cio Ao contr rio dos requisitos funcionais e n o funcionais a maioria das regras de neg cio origina se fora do contexto de um sistema espec fico Assim as regras a serem tratadas pelo sistema precisam ser identificadas documentadas e associadas aos requisitos do sistema em quest o WIEGERS 2003 Wiegers identifica cinco tipos principais de regras de neg cio cada um deles apresentando uma forma t pica de ser escrito e Fatos ou invariantes declara es que s o verdade sobre o neg
26. o entre objetos d se por meio de troca de mensagens Para requisitar uma opera o de um objeto necess rio enviar uma mensagem para ele Uma mensagem composta do nome da opera o sendo requisitada e dos argumentos requeridos Assim o comportamento de um objeto representa como esse objeto reage s mensagens a ele enviadas Em outras palavras o conjunto de mensagens a que um objeto pode responder representa o seu comportamento Um objeto pois uma entidade que tem seu estado representado por um conjunto de atributos e associa es uma estrutura de informa o e seu comportamento representado por um conjunto de opera es Cada objeto tem uma identidade pr pria que lhe inerente Todos os objetos t m exist ncia pr pria ou seja dois objetos s o distintos mesmo se seus estados e comportamentos forem iguais A identidade de um objeto transcende os valores correntes de suas propriedades Classes No mundo real diferentes objetos desempenham um mesmo papel Seja o caso de duas cadeiras iguais Apesar de serem objetos diferentes elas compartilham uma mesma estrutura e um mesmo comportamento Entretanto n o h necessidade de se despender tempo Engenharia de Requisitos Notas de Aula Cap tulo 4 An lise de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 78 modelando cada cadeira Basta definir em um nico lugar um modelo descrevendo a estrutura e o comportamento desses obj
27. o para o encapsulamento garantir estabilidade aos sistemas Um encapsulamento bem feito pode servir de base para a localiza o de decis es de projeto que necessitam ser alteradas Uma opera o pode ter sido implementada de maneira ineficiente e portanto pode ser necess rio escolher um novo algoritmo Se a opera o est encapsulada apenas o objeto que a define precisa ser modificado garantindo estabilidade ao sistema Modularidade Os m todos de desenvolvimento de software buscam obter sistemas modulares isto constru dos a partir de elementos que sejam aut nomos e conectados por uma estrutura simples e coerente Modularidade visa obten o de sistemas decompostos em um conjunto Engenharia de Requisitos Notas de Aula Cap tulo 4 An lise de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo TI de m dulos coesos e fracamente acoplados e crucial para se obter sistemas f ceis de manter e estender Abstra o encapsulamento e modularidade s o princ pios sinerg ticos isto ao se trabalhar bem com um deles est se aperfei oando os outros tamb m 4 3 2 Principais Conceitos da Orienta o a Objetos De maneira simples o paradigma OO traz uma vis o de mundo em que os fen menos e dom nios s o vistos como cole es de objetos interagindo entre si Essa forma simples de se colocar a vis o do paradigma OO esconde conceitos importantes da orienta o a objetos qu
28. objetos de neg cio e eventos que disparam ou s o disparados com a execu o das atividades Engenharia de Requisitos Notas de Aula Cap tulo 3 Levantamento de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 56 Modelo Organizacional Modelo de Localidades Modelo de Processos Localiza o Geogr fica sotu o Processo Atividade manipula ad a Objeto Modelo de Objetivos Modelo de Atividades Figura 3 2 Submodelos do Modelo de Neg cio adaptado de KNIGHT 2004 H muitas nota es utilizadas para representar os v rios tipos de modelos citados anteriormente sendo que alguns autores prop em o uso de diagramas da UML ou extens es deles para essa finalidade Em especial os diagramas de casos de uso e de atividades s o bastante utilizados para a representa o de modelos de processos de neg cio Diferentes propostas usam diferentes tipos de modelos para derivar requisitos Um dos usos mais comuns de modelos de processo na Engenharia de Requisitos a deriva o de casos de uso a partir da an lise das informa es capturadas nos diagramas que representam os aspectos do neg cio incluindo a identifica o das atividades dos processos que ser o apoiadas pelo sistema bem como a identifica o dos atores dos casos de uso a partir dos executores pessoas ou m quinas relacionados aos processos Segundo Davenport 2000 dentre os principais benef
29. s o identificadas DRE 2 Um conjunto definido de requisitos do cliente especificado e priorizado a partir das necessidades expectativas e restri es identificadas DRE 3 Um conjunto de requisitos funcionais e n o funcionais do produto e dos componentes do produto que descrevem a solu o do problema a ser resolvido definido e mantido a partir dos requisitos do cliente DRE 4 Os requisitos funcionais e n o funcionais de cada componente do produto s o refinados elaborados e alocados DRE 5 Interfaces internas e externas do produto e de cada componente do produto s o definidas DRE 6 Conceitos operacionais e cen rios s o desenvolvidos DRE 7 Os requisitos s o analisados usando crit rios definidos para balancear as necessidades dos interessados com as restri es existentes Engenharia de Requisitos Notas de Aula Cap tulo 2 Engenharia de Requisitos de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 26 DRE 8 Os requisitos s o validados De uma maneira geral pode se constatar que a Engenharia de Requisitos pela sua import ncia no contexto do desenvolvimento de software cuidadosamente tratada pelos principais modelos de qualidade de processo de software Leitura Complementar Os livros de Kotonya e Sommerville 1998 Wiegers 2003 e Robertson e Robertson 2006 s o dedicados integralmente Engenharia de Requisitos e portanto contemplam v rios dos asp
30. sendo documentado pelo caso de uso Tipicamente pode ser um processo de neg cio um sistema ou um subsistema Vale lembrar que este texto n o aborda a utiliza o de casos de uso para a modelagem de processos de neg cio Assim o escopo vai apontar o sistema subsistema do qual o caso de uso faz parte Descri o do Prop sito uma descri o sucinta do caso de uso na forma de um nico par grafo procurando descrever o objetivo do caso de uso Ator Prim rio nome do ator prim rio ou seja o interessado que tem um objetivo em rela o ao sistema o qual pode ser atingido pela execu o do caso de uso Interessados e Interesses um interessado algu m ou algo um outro sistema que tem um interesse no comportamento do caso de uso sendo descrito Nesta se o s o descritos cada um dos interessados no sistema e qual o seu interesse no caso de uso incluindo o ator prim rio Pr condi es o que deve ser verdadeiro antes da execu o do caso de uso Se as pr condi es n o forem satisfeitas o caso de uso n o pode ser realizado P s condi es o que deve ser verdadeiro ap s a execu o do caso de uso considerando que o fluxo de eventos normal realizado com sucesso Fluxo de Eventos Normal descreve os passos do caso de uso realizados em situa es normais considerando que nada acontece de errado e levando em conta a maneira mais comum do caso de uso ser realizado Fluxo de Eventos Alternativos descreve f
31. tulo 5 de WAZLAWICK 2004 Modelagem Conceitual d uma vis o geral da modelagem estrutural discutindo de maneira bastante did tica diversos de seus aspectos Em BOOCH RUMBAUGH JACOBSON 2006 merecem aten o os cap tulos 4 Classes 5 Relacionamentos 8 Diagramas de Classes 9 Classes Avan adas e 10 Relacionamentos Avan ados As nota es da UML para diagramas de classes s o tratadas com mais detalhes do que nas demais refer ncias citadas anteriormente precisamente por se tratar este de um livro sobre a UML Refer ncias do Cap tulo BOOCH G RUMBAUGH J JACOBSON I UML Guia do Usu rio 2a edi o Elsevier Editora 2006 GUIZZARDI G Ontological Foundations for Structural Conceptual Models Telematics Instituut Fundamental Research Series The Netherlands 2005 JACOBSON I Object Oriented Software Engineering Addison Wesley 1992 MYLOPOULOS J Conceptual Modeling and Telos In Conceptual Modeling Databases and CASE Wiley 1992 OLIV A Conceptual Modeling of Information Systems Springer 2007 WAZLAWICK R S An lise e Projeto de Sistemas de Informa o Orientados a Objetos Elsevier 2004 Engenharia de Requisitos Notas de Aula Cap tulo 7 Modelagem Din mica Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 138 Cap tulo 7 Modelagem Din mica Um sistema de informa o realiza a es O efeito de uma a o pode ser um
32. 11 As notas s o preparadas e liberadas Fluxos de Eventos de Exce o 2a O cart o n o aceit vel Se o cart o n o aceit vel seja porque sua tarja magn tica n o pass vel de leitura seja porque de um tipo incompat vel uma mensagem de erro de leitura mostrada e se retorna ao passo 1 5a Senha incorreta Sal 1 e 2 tentativas Uma mensagem de erro mostrada para o cliente Retornar ao passo 3 5a 2 3 tentativa bloquear o cart o e abortar a transa o 10a Saque n o autorizado Uma mensagem de erro exibida e a opera o abortada lla N o h dinheiro suficiente dispon vel no caixa eletr nico Uma mensagem de erro exibida e a opera o abortada l a 9 Cancelamento O cliente pode cancelar a transa o enquanto o saque n o for autorizado pelo sistema banc rio A transa o abortada Figura 5 4 Descri o do Caso de Uso Efetuar Saque Formato Enumerado Al m dos fluxos de exce o h outro tipo de fluxo de eventos alternativo os fluxos variantes Fluxos variantes s o considerados dentro da normalidade do caso de uso e indicam formas diferentes mas igualmente normais de se realizar uma certa por o de um caso de uso Seja o caso de um sistema de um supermercado mais especificamente um caso de uso para efetuar uma compra Um passo importante desse caso de uso a realiza o do pagamento o qual pode se dar de tr s maneiras distintas
33. Approaches for Requirements Elicitation faz um timo apanhado sobre t cnicas de levantamento de requisitos V rios dos coment rios feitos neste texto foram baseados nas descri es feitas por Zowghi e Coulin autores dessa se o de AURUM WOHLIN 2005 Uma das principais fontes para as descri es feitas neste texto sobre as t cnicas de entrevistas question rios observa o e investiga o de documentos foi a parte II de KENDALL KENDALL 2010 Information Requirements Analysis a qual cont m tr s cap tulos bastante usados nestas notas de aula a saber Cap tulo 4 Information Gathering Interactive Methods que trata dentre outros de entrevistas e question rios Cap tulo 5 Information Gathering Unobtrusive Methods que aborda investiga o de documentos e observa o e Cap tulo 6 Agile Modeling and Prototyping que discute prototipagem Outra fonte importante sobre t cnicas de levantamento de requisitos a parte II de ALEXANDER BEUS DUKIC 2009 Discovery Contexts Esta parte cont m quatro cap tulos sendo tr s deles relacionados a aspectos discutidos neste texto a saber Cap tulo 11 Requirements from Individuals que trata de entrevistas e observa o Cap tulo 12 Requirements from Groups que aborda workshops de requisitos e Cap tulo 13 Requirements from Things que discute prototipagem e reutiliza o de requisitos Em SOMMERVILLE 2007 o Cap tulo 6 Requisitos de So
34. Classe B Classe C e d PN A Classe C r Classe D r a b Figura 2 7 a Colis o de nomes b Heran a repetida No primeiro caso a classe C herda das classes 4 e B Entretanto ambas possuem uma caracter stica com nome x Assim como ser a caracter stica x em C Igual definida na classe 4 ou igual da classe B No segundo caso a classe D herda das classes B e C que por sua vez herdam da classe 4 Assim temos um caso de heran a repetida j que indiretamente a classe D herda duas vezes da classe 4 Mensagens e M todos A abstra o incorporada por um objeto caracterizada por um conjunto de opera es que podem ser requisitadas por outros objetos ditos clientes M todos s o implementa es reais de opera es Para que um objeto realize alguma tarefa necess rio enviar uma mensagem a ele solicitando a execu o de um m todo espec fico Um cliente s pode acessar um objeto atrav s da emiss o de mensagens isto ele n o pode acessar ou manipular diretamente os dados associados ao objeto Os objetos podem ser complexos e o cliente n o precisa tomar conhecimento de sua complexidade interna O cliente precisa saber apenas como se comunicar com o objeto e como ele reage Assim garante se o encapsulamento As mensagens s o o meio de comunica o entre objetos e s o respons veis pela ativa o de todo e qualquer processamento Dessa forma poss vel garantir que clientes n o ser o afetad
35. Directions Workshop on Software Architecture USC Center for Software Engineering Los Angeles EUA 1994 BLAHA M RUMBAUGH J Modelagem e Projetos Baseados em Objetos com UML 2 Elsevier 2006 COTA R I Um Estudo sobre o Uso de Ontologias e Padr es de An lise na Modelagem de Sistemas de Gest o Empresarial Disserta o de Mestrado Mestrado em Inform tica UFES 2004 DEVEDZIC V Ontologies Borrowing from Software Patterns Intelligence vol 10 issue 3 Fall 1999 1999 p 14 24 FALBO R A Experiences in Using a Method for Building Domain Ontologies Proceedings of the 16th International Conference on Software Engineering and Knowledge Engineering International Workshop on Ontology In Action Banff Canada 2004 FALBO R A MARTINS A F SEGRINI B M BAI CO G DAL MORO R NARDI J C Um Processo de Engenharia de Requisitos Baseado em Reutiliza o e Padr es de An lise VI Jornadas Iberoamericanas de Ingenier a del Software e Ingenieria del Conocimiento JISIC 07 Lima Peru 2007 FOWLER M Analysis Patterns Reusable Object Models Addison Wesley Professional Computing Series 1997 FOWLER M Patterns of Enterprise Application Architecture Addison Wesley 2003 Engenharia de Requisitos Notas de Aula Cap tulo 8 Qualidade e Agilidade em Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 172 GAMMA E HELM R JOHNSON R VLISSID
36. Figura 5 9 Descri o do Caso de Uso Efetuar Saque com inclus o Por fim importante frisar que n o h um consenso sobre a possibilidade ou n o de um caso de uso inclu do poder ser utilizado isoladamente Diversos autores dentre eles Oliv 2007 e Blaha e Rumbaugh 2006 admitem essa possibilidade outros n o Em BOOCH RUMBAUGH JACOBSON 2006 diz se explicitamente que um caso de uso inclu do Engenharia de Requisitos Notas de Aula Cap tulo 5 Modelagem de Casos de Uso Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 107 nunca permanece isolado mas apenas instanciado como parte de alguma base maior que o inclui Neste texto admitimos a possibilidade de um caso de uso inclu do poder ser utilizado isoladamente pois isso permite representar situa es em que um caso de uso chama outro caso de uso como uma chamada de subrotina mas este ltimo pode tamb m ser realizado isoladamente A Figura 5 10 ilustra uma situa o bastante comum em que ao se realizar um processo de neg cio no caso a reserva de um carro em um sistema de loca o de autom veis caso uma informa o necess ria para esse processo no caso o cliente n o esteja dispon vel ela pode ser inserida no sistema Contudo o cadastro da informa o tamb m pode ser feito dissociado do processo de neg cio que o inclui no caso o cliente pode se cadastrar fora do contexto da reserva de um carro Ao n o se admitir
37. Metrics 2003a ISO IEC TR 9126 3 2003 Software Engineering Product Quality Part 3 Internal Metrics 2003b KENDALL K E KENDALL J E Systems Analysis and Design Prentice Hall 8th Edition 2010 Engenharia de Requisitos Notas de Aula Cap tulo 3 Levantamento de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 69 KNIGHT D M Elicita o de Requisitos de Software a partir do Modelo de Neg cio Disserta o Mestrado em Inform tica N cleo de Computa o Eletr nica NCE Universidade Federal do Rio de Janeiro Rio de Janeiro 2004 KOTONYA G SOMMERVILLE I Requirements engineering processes and techniques Chichester England John Wiley 1998 PFLEEGER S L Engenharia de Software Teoria e Pr tica S o Paulo Prentice Hall 2 edi o 2004 PRESSMAN R S Engenharia de Software McGraw Hill 6 edi o 2006 ROBERTSON S ROBERTSON J Mastering the Requirements Process 2 Edition Addison Wesley 2006 SOMMERVILLE I Engenharia de Software 8 Edi o S o Paulo Pearson Addison Wesley 2007 WAZLAWICK R S An lise e Projeto de Sistemas de Informa o Orientados a Objetos Elsevier 2004 WIEGERS K E Software Requirements Practical techniques for gathering and managing requirements throughout the product development cycle 2nd Edition Microsoft Press Redmond Washington 2003 Engenharia de Requisitos Notas de Aula Cap tu
38. Notas de Aula Cap tulo 8 Qualidade e Agilidade em Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 159 que envolve a especifica o de suas opera es s o necess rios os modelos estrutural e comportamental Al m disso necess rio compar los para garantir que n o h inconsist ncias entre eles BLAHA RUMBAUGH 2006 Para apoiar a verifica o da consist ncia t cnicas de leitura de modelos de an lise podem ser aplicadas Algumas dessas t cnicas s o discutidas na Se o 8 1 Do ponto de vista de agilidade no processo de Engenharia de Requisitos merece destaque a modelagem gil A modelagem gil prov uma s rie de princ pios e valores que podem ser aplicados para nortear a decis o de quais diagramas produzir de modo que o esfor o despendido na an lise de requisitos seja compensador A modelagem gil discutida na Se o 8 2 Por fim visando tanto qualidade quanto a agilidade podem ser aplicadas t cnicas de reutiliza o de requisitos A reutiliza o tende a proporcionar qualidade uma vez que os requisitos modelos ou outros artefatos reutilizados j foram avaliados em outros contextos e por conseguinte tendem a prover solu es j avaliadas Do ponto de vista da agilidade ao se reutilizar algum artefato da Engenharia de Requisitos espera se que haja um aumento da produtividade uma vez que n o se est partindo do zero A reutiliza o na Engenharia de Requi
39. Requisitos o processo pelo qual os requisitos de um produto de software s o coletados analisados documentados e gerenciados ao longo de todo o ciclo de vida do software AURUM WOHLIN 2005 Este texto aborda o processo de Engenharia de Requisitos concentrando se nas atividades de levantamento de requisitos e modelagem conceitual Este cap tulo apresenta o tema e como o mesmo tratado neste texto A Se o 1 1 discute a rela o entre a Engenharia de Requisitos e o processo de software A Se o 1 2 apresenta a organiza o deste texto 1 1 Desenvolvimento de Software e Engenharia de Requisitos Um processo de software envolve diversas atividades que podem ser classificadas quanto ao seu prop sito em e Atividades de Desenvolvimento ou T cnicas s o as atividades diretamente relacionadas ao processo de desenvolvimento do software ou seja que contribuem diretamente para o desenvolvimento do produto de software a ser entregue ao cliente S o exemplos de atividades de desenvolvimento levantamento e an lise de requisitos projeto e implementa o e Atividades de Ger ncia envolvem atividades relacionadas ao gerenciamento do projeto de maneira abrangente Incluem dentre outras atividades de planejamento e acompanhamento gerencial do projeto processo de Ger ncia de Projetos tais como realiza o de estimativas elabora o de cronogramas an lise dos riscos do projeto etc atividades relacionadas ger ncia d
40. SOMMERVILLE 1998 WIEGERS 2003 Engenharia de Requisitos Notas de Aula Cap tulo 2 Engenharia de Requisitos de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 21 e Verificar se uma mudan a v lida e Descobrir quais os requisitos e artefatos afetados pela mudan a o que envolve rastrear informa es e Estimar o impacto e o custo das mudan as e Negociar as mudan as com os clientes e Alterar requisitos e documentos associados Para garantir uma abordagem consistente recomenda se que as organiza es definam um conjunto de pol ticas de ger ncia de mudan a contemplando KOTONYA SOMMERVILLE 1998 e o processo de solicita o de mudan a e as informa es necess rias para processar cada solicita o e o processo de an lise de impacto e de custos da mudan a al m das informa es de rastreabilidade associadas e os membros que formalmente avaliar o as mudan as e as ferramentas que auxiliar o o processo Se as mudan as n o forem controladas altera es com baixa prioridade podem ser implementadas antes de outras mais importantes e modifica es com custo alto que n o s o realmente necess rias podem ser aprovadas TOGNERI 2002 Ao se detectar a necessidade de altera o em um ou mais requisitos deve se registrar uma solicita o de mudan a a qual deve ser avaliada por algum membro da equipe do projeto de software Nessa avalia o o impacto da
41. Santo 4 e Cap tulo 5 Modelagem de Casos de Uso discute o papel da modelagem de casos de uso na especifica o de requisitos funcionais de sistema Apresenta os elementos centrais da modelagem de casos de uso o diagrama de casos de uso da UML e discute como descrever casos de uso textualmente e Cap tulo 6 Modelagem Estrutural trata da modelagem dos principais conceitos do dom nio suas rela es e propriedades permitindo representar o conhecimento do dom nio relevante para o sistema em desenvolvimento A elabora o de diagramas de classes da UML o foco deste cap tulo e Cap tulo 7 Modelagem Din mica aborda os modelos usados para especificar as mudan as v lidas no estado dos objetos de dom nio bem como para modelar o comportamento esperado do sistema O foco deste cap tulo a elabora o de diagramas de estados e diagramas de atividades e Cap tulo 8 Qualidade e Agilidade em Requisitos explora t cnicas de leitura de modelos visando apoiar a verifica o da consist ncia entre os diversos artefatos produzidos durante a an lise de requisitos apresenta o enfoque da modelagem gil e discute abordagens para reutiliza o na Engenharia de Requisitos dentre elas Engenharia de Dom nio Ontologias e Padr es de An lise Refer ncias do Cap tulo AURUM A WOHLIN C Engineering and Managing Software Requirements Springer Verlag 2005 Engenharia de Requisitos Notas de Aula Cap tulo 2 E
42. WIEGERS 2003 Ao se estabelecer uma escala de medi o e os valores aceit veis o requisito transformado de uma inten o vaga e at certo ponto amb gua em um requisito mensur vel e bem formado Estabelecida uma escala pode se perguntar ao usu rio o que considerado uma falha em atender ao requisito de modo a definir o crit rio de aceita o do mesmo ROBERTSON ROBERTSON 2006 Assim na especifica o de requisitos de sistema importante transformar um requisito de usu rio em um requisito mensur vel adicionando a ele um crit rio de aceita o A ISO IEC 9126 pode ser uma boa fonte de medidas As partes 2 Medidas Externas ISO IEC 20034 e 3 Medidas Internas ISO IEC 2003b dessa norma apresentam diversas medidas que podem ser usadas para especificar objetivamente os requisitos n o funcionais Nas partes 2 e 3 da norma medidas s o sugeridas para as diversas subcaracter sticas de qualidade externa e interna descritas na Parte 1 indicando dentre outros nome e prop sito da medida m todo de aplica o e f rmula e como interpretar os valores da medida Engenharia de Requisitos Notas de Aula Cap tulo 4 An lise de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 84 Seja o exemplo de um sistema que tem como requisito n o funcional ser f cil de aprender Esse requisito poderia ser especificado conforme mostrado na Tabela 4 1 Tabela 4 1 Especifica o de Requ
43. a Oliv 2007 utiliza o termo esquema conceitual para designar o conjunto de artefatos que capturam o conhecimento que um sistema de informa o necessita para realizar suas fun es Contudo a maioria dos textos tais como WAZLAWICK 2004 e BLAHA RUMBAUGH 2006 utiliza o termo modelo conceitual para designar esse conjunto de artefatos Oliv utiliza o termo modelo conceitual para designar tipos de modelos tais como modelos de objetos modelos de casos de uso etc Nestas notas de aula o termo modelo conceitual usado como na maioria dos textos n o sendo feita uma distin o precisa entre as duas acep es do termo De maneira geral o contexto indica ao que se refere o termo Engenharia de Requisitos Notas de Aula Cap tulo 4 An lise de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 71 atividade de an lise de requisitos tanto requisitos funcionais quanto requisitos n o funcionais devem ser especificados em detalhes O produto de trabalho principal da an lise de requisitos o Documento de Especifica o de Requisitos Esse documento deve conter os requisitos funcionais e n o funcionais descritos em n vel de requisitos de sistema Conforme citado anteriormente os requisitos funcionais de sistema s o descritos por um conjunto de modelos interrelacionados Os requisitos n o funcionais de sistema detalham os requisitos n o funcionais de usu rio adi
44. a uma rela o entre classes e n o entre inst ncias Ao se considerar uma classe B como sendo uma subclasse de uma classe 4 est se assumindo que todas as inst ncias de B s o tamb m inst ncias de 4 Assim ao se dizer que a classe EstudanteGraduacao herda da classe Estudante est se indicando que todos os estudantes de gradua o s o estudantes Em resumo deve se interpretar a rela o de heran a como uma rela o de subtipo entre classes A Figura 6 16 mostra a nota o da UML para representar heran a Engenharia de Requisitos Notas de Aula Cap tulo 6 Modelagem Conceitual Estrutural Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 135 Superclasse Figura 6 16 Nota o de Heran a da UML A rela o de heran a aplic vel quando for necess rio fatorar os elementos de informa es atributos e associa es de uma classe Quando um conjunto de classes possuir semelhan as e diferen as ent o elas podem ser organizadas em uma hierarquia de classes de forma a agrupar em uma superclasse os elementos de informa o comuns deixando as especificidades nas subclasses De maneira geral desnecess rio criar hierarquias de classes quando as especializa es subclasses n o tiverem nenhum elemento de informa o diferente Quando isso ocorrer normalmente suficiente criar um atributo tipo para indicar os poss veis subtipos da generaliza o Seja o caso de um dom nio em que
45. a possibilidade de um caso de uso inclu do poder ser utilizado isoladamente n o poss vel modelar situa es desta natureza as quais s o bastante frequentes Cadastrar Cliente j lt include gt L A ia l Reservar Carro Figura 5 10 Exemplo de Associa o de Inclus o 5 4 2 Extens o Uma associa o de extens o entre um caso de uso de extens o e um caso de uso base significa que o comportamento definido no caso de uso de extens o pode ser inserido dentro do comportamento definido no caso de uso base em um local especificado indiretamente pelo caso de uso de extens o A extens o ocorre em um ou mais pontos de extens o espec ficos definidos no caso de uso base A extens o pode ser condicional Neste caso a extens o ocorre apenas se a condi o verdadeira quando o ponto de extens o especificado atingido O caso de uso base definido de forma independente do caso de uso de extens o e significativo independentemente do caso de uso de extens o OLIVE 2007 BOOCH RUMBAUGH JACOBSON 2006 Um caso de uso pode ter v rios pontos de extens o e esses pontos s o referenciados por seus nomes BOOCH RUMBAUGH JACOBSON 2006 O caso de uso base apenas indica seus pontos de extens o O caso de uso de extens o especifica em qual ponto de extens o ele ser inserido Por isso diz se que o caso de uso de extens o especifica indiretamente o local onde seu comportamento ser inserido A as
46. a ser efetuada Fluxos de Eventos Variantes 3a Validar cart o por autentica o de senha 3a 1 O caixa autom tico solicita a senha 3a 2 O cliente informa a senha 3a 3 O caixa autom tico envia os dados do cart o e a senha para o sistema banc rio para valida o 3b Validar cart o por an lise de retina 3b 1 O caixa autom tico solicita que o cliente se posicione corretamente para a captura da imagem da retina 3b 2 O caixa autom tico retira uma foto da retina do cliente 3b 3 O caixa autom tico envia os dados do cart o e a foto da retina para o sistema banc rio para valida o Fluxos de Eventos de Exce o 2a O cart o n o aceit vel Se o cart o n o aceit vel seja porque sua tarja magn tica n o pass vel de leitura seja porque de um tipo incompat vel uma mensagem de erro de leitura mostrada e se retorna ao passo 1 5a Dados de Identifica o Incorretos Sal 1 e 2 tentativas Uma mensagem de erro mostrada para o cliente Retornar ao passo 3 5a 2 3 tentativa bloquear o cart o e abortar a transa o l a 5 Cancelamento O cliente solicita o cancelamento da transa o e a transa o abortada Figura 5 17 Descri o do Caso de Uso Validar Cart o com Variantes Engenharia de Requisitos Notas de Aula Cap tulo 5 Modelagem de Casos de Uso Ricardo de Almeida Falbo UFES Universidade Federal do Esp
47. agrupamento de valores fortemente relacionados que sirva para descrever outro objeto Al m disso para que um item de estrutura complexa seja modelado como um atributo ele deve ser compreens vel pelos interessados simplesmente pelo seu nome bom real ar que com o tempo as classes do dom nio do problema tendem a permanecer relativamente est veis enquanto os atributos provavelmente se alteram Atributos podem ser bastante vol teis em fun o de altera es nas responsabilidades do sistema E muito importante lembrar tamb m que uma vez que atributos e associa es s o tipos de relacionamentos n o devemos incluir na lista de atributos de uma classe atributos representando associa es ou atributos representando chaves estrangeiras como a classe Engenharia de Requisitos Notas de Aula Cap tulo 6 Modelagem Conceitual Estrutural Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 125 fosse uma tabela de um banco de dados relacional Associa es j t m sua presen a indicada pela nota o de associa o ou seja pelas linhas que conectam as classes que se relacionam Um aspecto bastante importante na especifica o de atributos a escolha de nomes Deve se procurar utilizar o vocabul rio t pico do dom nio do problema usando nomes leg veis e abrangentes Para nomear atributos sugerem se nomes iniciando com substantivo o qual pode ser combinado com complementos ou adjetivos omitindo
48. amplamente utilizados Para a modelagem comportamental podem ser usados diagramas de casos de uso de intera o de estados e de atividades A seguir apresentada uma descri o sucinta de cada um desses diagramas baseada em BOOCH RUMBAUGH JACOBSON 2006 e Diagramas de Classes Um diagrama de classes exibe um conjunto de classes e seus relacionamentos Diagramas de classes proveem uma vis o est tica da estrutura de um sistema e portanto s o usados na modelagem conceitual estrutural e Diagramas de Casos de Uso Um diagrama de casos de uso mostra um conjunto de casos de uso e atores e seus relacionamentos Os casos de uso descrevem a funcionalidade do sistema percebida pelos atores externos Um ator interage com o sistema podendo ser um usu rio humano dispositivo de hardware ou outro sistema Diagramas de casos de uso proveem uma vis o das funcionalidades do sistema sendo importantes para a organiz las e model las e Diagramas de Gr fico de Estados ou simplesmente Diagramas de Estados mostram os estados pelos quais um objeto pode passar ao longo de sua vida em Engenharia de Requisitos Notas de Aula Cap tulo 4 An lise de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 74 resposta a est mulos recebidos juntamente com suas a es Os diagramas de estados proveem uma vis o din mica de um objeto sendo importantes para modelar o comportamento dos objetos de uma classe em
49. atingido a uni o a partir da qual o fluxo de controle de sa da prossegue De maneira geral deve haver um equil brio entre bifurca es e uni es indicando que o n mero de fluxos de controle que deixam uma bifurca o deve ser equivalente ao n mero de fluxos que chegam a uma uni o correspondente BOOCH RUMBAUGH JACOBSON 2006 A Figura 7 13 ilustra a nota o de bifurca es e uni es Atividade 7 bifurca o Atividade 9 uni o Atividade 8 Atividade 10 Figura 7 13 Bifurca es e Uni es em Diagramas de Atividades da UML Para representar atividades que ocorrem v rias vezes operando sobre elementos de um conjunto podem se utilizar regi es de expans o Uma regi o de expans o representa um fragmento do diagrama de atividades que realizado operando sobre os elementos de uma lista ou conjunto Ela representada por uma linha tracejada em torno da regi o do diagrama que envolve as atividades iterativas A regi o executada uma vez para cada elemento do conjunto de entrada BOOCH RUMBAUGH JACOBSON 2006 Muitas vezes til representar os objetos requeridos entradas e produzidos sa das por uma atividade em um diagrama de atividades poss vel especificar os objetos envolvidos nas atividades conectando os s atividades que os produzem ou consomem Al m de representar objetos e o seu fluxo nas atividades pode se representar ainda o estado em que se encontra o objeto A Figura
50. cios da implanta o de sistemas de informa o para apoiar processos de neg cio est o 1 a automatiza o de tarefas antes realizadas manualmente ii a racionaliza o dos dados iii a implementa o de melhorias nos processos da organiza o iv ajuste das interfaces entre reas v aperfei oamento dos servi os aos clientes e vi gera o de informa es gerenciais No decorrer da modelagem de processos a reuni o dos envolvidos no processo permite que seja estabelecida uma vis o abrangente de todo o contexto possibilitando a identifica o de diverg ncias e abrindo espa os para a melhoria o que pode levar reengenharia dos processos de neg cio Processos correntes processos 4S IS podem dar origem a novos processos mais eficazes a serem implantados na organiza o processos TO BE O contexto no qual o sistema ser inserido considerado como parte integral na aplica o da abordagem orientada a modelos de processos permitindo que o sistema seja considerado um agente de mudan as e n o apenas a automatiza o das pr ticas correntes sejam elas boas ou n o Engenharia de Requisitos Notas de Aula Cap tulo 3 Levantamento de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 57 A modelagem de processos complementa as pr ticas convencionais de engenharia de requisitos auxiliando o cliente a adquirir maturidade acerca da complexidade do seu pr prio neg cio e revela
51. clientes pode fornecer Fornecedor Produto a E Figura 6 14 Associa o Tern ria Na UML associa es n rias s o mostradas como losangos conectados s classes envolvidas na associa o por meio de linhas s lidas como mostra a Figura 6 14 O nome da associa o colocado dentro ou em cima do losango sem dire o de leitura Normalmente multiplicidades n o s o mostradas dada a dificuldade de interpret las Finalmente algumas associa es podem ser consideradas mais fortes do que as outras no sentido de que elas na verdade definem um objeto como sendo composto por outros WAZLAWICK 2004 Essas associa es todo parte podem ser de dois tipos principais agrega o e composi o A composi o o tipo mais forte de associa o todo parte Ela indica que um objeto parte s pode ser parte de um nico todo J a agrega o n o implica nessa exclusividade Um carro por exemplo tem como partes um motor e quatro ou cinco rodas Motor e rodas ao serem partes de um carro n o podem ser partes de outros carros simultaneamente Assim esta Engenharia de Requisitos Notas de Aula Cap tulo 6 Modelagem Conceitual Estrutural Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 134 uma rela o de composi o como ilustra a Figura 6 15 a O exemplo da Figura 6 15 b ilustra o caso de comiss es compostas por professores Nesse caso um professor pode participar de
52. com os outros diretores n o est Uma op o mais adequada seria O que voc pensa sobre este assunto e Duas quest es em uma O entrevistado pode responder a apenas uma delas ou pode se confundir em rela o pergunta que est respondendo Ex O que voc faz e como A estrutura de uma entrevista diz respeito organiza o das quest es em uma sequ ncia l gica De acordo com KENDALL KENDALL 2010 h tr s formas b sicas de se organizar as quest es de uma entrevista e Estrutura de Pir mide abordagem indutiva inicia com quest es detalhadas e objetivas e medida que a entrevista progride quest es mais gerais subjetivas s o colocadas til para situa es em que o entrevistado necessita de um aquecimento para falar no assunto ou quando o analista deseja obter uma finaliza o sobre o assunto come a com quest es espec ficas termina com quest es mais gerais Engenharia de Requisitos Notas de Aula Cap tulo 3 Levantamento de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 38 e Estrutura de Funil abordagem dedutiva inicia com quest es gerais subjetivas e medida que a entrevista avan a perguntas mais espec ficas usando quest es objetivas s o feitas Essa estrutura prov um meio f cil e mais amig vel para se come ar uma bateria de entrevistas Permite levantar informa o detalhada sendo desnecess rias longas sequ ncias de quest es o
53. como interoperabilidade e seguran a de acesso Assim importante avaliar em que grau o sistema em quest o necessita apresentar tais caracter sticas Engenharia de Requisitos Notas de Aula Cap tulo 3 Levantamento de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 65 Outro ponto importante a destacar que diferentes autores listam diferentes caracter sticas de qualidade usando classifica es pr prias Por exemplo Bass Clements e Kazman 2003 consideram dentre outros os seguintes atributos de qualidade e Disponibilidade refere se a falhas do sistema e suas consequ ncias associadas Uma falha ocorre quando o sistema n o entrega mais um servi o consistente com sua especifica o e Modificabilidade diz respeito ao custo de modifica o do sistema e Desempenho refere se a tempo e Seguran a est relacionada habilidade do sistema impedir o uso n o autorizado enquanto ainda prov seus servi os para os usu rios leg timos e estabilidade refere se ao qu o f cil testar o software e Usabilidade diz respeito ao qu o f cil para o usu rio realizar uma tarefa e o tipo de suporte ao usu rio que o sistema prov Al m das caracter sticas de qualidade que se aplicam diretamente ao sistema ditas caracter sticas de qualidade de produto Bass Clements e Kazman 2003 listam outras caracter sticas relacionadas a metas de neg cio dentre elas tempo para chega
54. da Figura 5 3 Neste texto advogamos em favor do uso do formato enumerado Cada exce o deve ser tratada por um fluxo alternativo de exce o Fluxos alternativos de exce o devem ser descritos contendo as seguintes informa es WAZLAWICK 2004 um identificador uma descri o sucinta da exce o que ocorreu os passos para tratar a exce o a es corretivas e uma indica o de como o caso de uso retorna ao fluxo principal se for o caso ap s a execu o das a es corretivas Quando um formato de descri o enumerado utilizado n o necess rio colocar uma verifica o como uma condicional no fluxo principal Por exemplo no caso da Figura 5 4 o passo 3 n o deve ser escrito como 3 Se o cart o v lido o caixa autom tico solicita que o cliente informe a senha Basta o fluxo alternativo no exemplo o fluxo 2a Ainda quando o formato de descri o enumerado utilizado o identificador da exce o deve conter a linha do fluxo de eventos principal ou eventualmente de algum outro fluxo de eventos alternativo no qual a exce o ocorreu e uma letra para identificar a pr pria exce o WAZLAWICK 2004 como ilustra o exemplo da Figura 5 4 Uma informa o que precisa estar presente na descri o de um fluxo de eventos de exce o diz respeito a como finalizar o tratamento de uma exce o Wazlawick 2004 aponta quatro formas b sicas para finalizar o tratamento de uma exce o e Voltar ao in
55. de Aula Cap tulo 4 An lise de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 85 f ceis de serem gerenci veis ditas subsistemas E til organizar a especifica o de requisitos por subsistemas e portanto cada uma das se es propostas acima pode ser subdividida por subsistemas Um modelo estrutural para uma aplica o complexa por exemplo pode ter centenas de classes e portanto pode ser necess rio definir uma representa o concisa capaz de orientar um leitor em um modelo dessa natureza O agrupamento de elementos de modelo em subsistemas serve basicamente a este prop sito podendo ser til tamb m para a organiza o de grupos de trabalho em projetos extensos A base principal para a identifica o de subsistemas a complexidade do dom nio do problema Atrav s da identifica o e agrupamento de elementos de modelo em subsistemas poss vel controlar a visibilidade do leitor e assim tornar os modelos mais compreens veis A UML prov um tipo principal de item de agrupamento denominado pacote que um mecanismo de prop sito geral para a organiza o de elementos da modelagem em grupos Um diagrama de pacotes mostra a decomposi o de um modelo em unidades menores e suas depend ncias como ilustra a Figura 4 4 A linha pontilhada direcionada indica que o pacote origem no exemplo o pacote Atendimento a Cliente depende do pacote destino no exemplo o pacote Controle de Ac
56. de acabar com conflitos e a defini o de prioridades Assim deve se registrar o nome e o papel do respons vel e dos interessados em cada requisito Um requisito pode depender de outros ou conflitar com outros Quando as depend ncias e conflitos forem detectados devem se listar os respectivos identificadores nas colunas de depend ncias e conflitos 3 4 1 Escrevendo Requisitos Funcionais As diretrizes apresentadas anteriormente aplicam se integralmente a requisitos funcionais Assim n o h outras diretrizes espec ficas para os requisitos funcionais Deve se real ar apenas que quando expressos como requisitos de usu rio requisitos funcionais s o geralmente descritos de forma abstrata n o cabendo neste momento entrar em detalhes Detalhes v o ser naturalmente adicionados quando esses mesmos requisitos forem descritos na forma de requisitos de sistema Uma alternativa largamente empregada para especificar requisitos funcionais no n vel de requisitos de sistema a modelagem Uma das t cnicas mais comumente utilizadas para descrever requisitos funcionais como requisitos de sistema a modelagem de casos de uso Vale ressaltar que os processos de neg cio a serem apoiados pelo sistema tipicamente d o origem a requisitos funcionais Assim a partir de uma descri o de minimundo ou em um relat rio proveniente de alguma atividade de levantamento de requisitos podem ser encontrados requisitos funcionais a partir da identifica
57. de hierarquias de generaliza o especializa o 6 1 Identifica o de Classes Classifica o o meio pelo qual os seres humanos estruturam a sua percep o do mundo e seu conhecimento sobre ele Sem ela n o poss vel nem entender o mundo a nossa volta nem agir sobre ele Classifica o assume a exist ncia de tipos e de objetos a serem classificados nesses tipos Classificar consiste ent o em determinar se um objeto ou n o uma inst ncia de um tipo A classifica o nos permite estruturar conhecimento sobre as coisas em dois n veis tipos e inst ncias No n vel de tipos procuramos encontrar as propriedades comuns a todas as inst ncias de um tipo No n vel de inst ncia procuramos identificar o tipo do qual o objeto uma inst ncia e os valores particulares das propriedades desse objeto OLIV 2007 Tipos de entidade s o um dos mais importantes elementos em modelos conceituais Definir os tipos de entidade relevantes para um particular sistema de informa o uma tarefa crucial na modelagem conceitual Um tipo de entidade pode ser definido como um tipo cujas inst ncias em um dado momento s o objetos individuais identific veis que se consideram existir no dom nio naquele momento Um objeto pode ser inst ncia de v rios tipos ao mesmo tempo OLIV 2007 Por exemplo seja o caso dos tipos Estudante e Funcion rio em um sistema de uma universidade Uma mesma pessoa por exemplo Jo o pode ser ao mesmo
58. de requisitos consiste em analisar e envolver todos os interessados relevantes Sele o de T cnicas de Levantamento de Requisitos Nenhuma t cnica individualmente suficiente para levantar requisitos Al m disso a escolha das t cnicas a serem adotadas fortemente dependente de caracter sticas do projeto e de seus envolvidos Diferentes t cnicas devem ser empregadas visando capturar diferentes tipos de informa o e em diferentes est gios do processo de levantamento de requisitos Assim importante selecionar adequadamente as t cnicas a serem aplicadas Levantamento de Requisitos de Interessados e Outras Fontes Uma vez identificados as fontes de requisitos e os interessados relevantes o levantamento de requisitos propriamente dito pode ser iniciado aplicando se as t cnicas selecionadas Assim antes de iniciar a descoberta de requisitos propriamente dita ou mesmo durante o levantamento de requisitos til realizar algumas tarefas a saber KOTONYA SOMMERVILLE 1998 Engenharia de Requisitos Notas de Aula Cap tulo 3 Levantamento de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 32 e Compreender os objetivos gerais do neg cio a ser apoiado esbo ar uma descri o do problema a ser resolvido e identificar por que o sistema necess rio e quais s o restri es sobre o mesmo tais como restri es or ament rias de cronograma e de interoperabilidade e Levantar i
59. de software de permitir que a modifica o especificada seja implementada o Estabilidade capacidade do produto de software de minimizar efeitos inesperados de modifica es de software o estabilidade capacidade do produto de software permitir que o software modificado ser testado e Portabilidade refere se capacidade do software ser transferido de um ambiente para outro Tem como subcaracter sticas o Adaptabilidade capacidade do produto de software de ser adaptado para diferentes ambientes especificados sem necessidade de aplica o de outras a es ou meios al m daqueles fornecidos para essa finalidade pelo software considerado Engenharia de Requisitos Notas de Aula Anexo A A Norma ISO IEC 9126 Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 176 o Capacidade para ser Instalado capacidade do produto de software para ser instalado em um ambiente especificado o Coexist ncia capacidade do produto de software para coexistir com outros softwares independentes em um ambiente comum compartilhando recursos comuns o Capacidade para Substituir capacidade do produto de software para ser usado em substitui o de outro produto de software especificado para o mesmo prop sito no mesmo ambiente Caracter sticas de Qualidade em Uso As quatro caracter sticas de qualidade em uso descritas na ISO IEC 9126 1 ISO IEC 2001 s o e Efic cia capacidade do produto de software de permitir ao
60. de um estado para outro Al m disso uma vez que os casos de uso foram representados apenas de maneira est tica pode ser til tamb m mostrar a din mica de um Engenharia de Requisitos Notas de Aula Cap tulo 4 An lise de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 83 caso de uso representando como objetos do diagrama de classes interagem para realizar um caso de uso Os diagramas de intera o s o elaborados com este prop sito Finalmente pode ser til representar os passos de um caso de uso na forma de um diagrama mostrando objetos gerados e os atores envolvidos em cada passo Para tal diagramas de atividades podem ser elaborados A elabora o de diagramas de estados de intera o e de atividades o foco da atividade de modelagem comportamental din mica a qual discutida com maiores detalhes no Cap tulo 7 Deve se frisar que apesar da Figura 4 1 sugerir que os passos do m todo s o sequenciais na pr tica isso n o ocorre Paralelamente modelagem de casos de uso pode se iniciar a modelagem conceitual estrutural Os diagramas de atividade podem tamb m ser elaborados em conjunto com a defini o dos casos de uso de maneira a complementar a descri o de casos de uso espec ficos Diagramas de estado e de intera o requerem a defini o preliminar de casos de uso e classes Contudo podem ter sido definidos apenas alguns casos de uso e classes e n o todos eles para
61. dever ser bloqueado e Saque n o autorizado Se o saque n o for aceito pelo sistema banc rio uma mensagem de erro exibida e a opera o abortada e N o h dinheiro suficiente dispon vel no caixa eletr nico Uma mensagem de erro exibida e a opera o abortada e Cancelamento O cliente pode cancelar a transa o a qualquer momento enquanto o saque n o for autorizado pelo sistema banc rio Requisitos Relacionados RFO1 RNO1 RNFO1 RNF02 Classes Cliente Conta Cart o Transa o Saque Figura 5 3 Descri o do Caso de Uso Efetuar Saque 10 S o as seguintes as descri es dos requisitos listados RFO1 O sistema de caixa autom tico deve permitir que clientes efetuem saques em dinheiro RNO1 N o devem ser permitidas transa es que deixem a conta do cliente com saldo inferior ao de seu limite de cr dito RNF01 O sistema de caixa autom tico deve estar integrado ao sistema banc rio RNF02 As opera es realizadas no caixa autom tico devem dar respostas em at 10s a partir da entrada de dados Engenharia de Requisitos Notas de Aula Cap tulo 5 Modelagem de Casos de Uso Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 97 Em sistemas de m dio a grande porte pode ser til considerar a fus o de casos de uso fortemente relacionados em um nico caso de uso contendo mais de um fluxo de eventos normal Em muitos sistemas necess rio dar ao u
62. din mica neste caso se justifica pois muitas vezes as pessoas encontram dificuldades em visualizar como os requisitos ser o traduzidos em um sistema Essa dificuldade pode ser amenizada por meio de prot tipos que auxiliam os usu rios na identifica o de problemas e na sugest o de melhorias dos requisitos Dessa forma a prototipagem pode ser utilizada no processo de valida o de requisitos Entretanto sua utiliza o nessa fase tem uma rela o custo benef cio mais efetiva quando ela tiver sido empregada tamb m na fase de levantamento de requisitos KOTONYA SOMMERVILLE 1998 Das atividades de verifica o e valida o a atividade de teste considerada um elemento cr tico para a garantia da qualidade dos artefatos produzidos ao longo do desenvolvimento e por conseguinte do produto de software final ROCHA MALDONADO WEBER 2001 Contudo exceto por meio de prot tipos ou especifica es de requisitos execut veis estas um recurso muito pouco utilizado na pr tica n o poss vel testar requisitos Entretanto uma das caracter sticas de qualidade de um requisito bem elaborado ser test vel e portanto uma boa maneira de identificar problemas nos requisitos definir casos de teste para os mesmos Se um requisito est incompleto inconsistente ou amb guo pode ser dif cil definir casos de teste para ele SOTONYA SOMMERVILLE 1998 Definir casos de teste para requisitos e avaliar prot tipos s o importantes
63. diversas vis es parciais sobre esse dom nio Cada vis o parcial carrega consigo um vocabul rio e determinados valores pr prios dificultando a integra o entre os diversos profissionais pela aus ncia de padroniza o Esse problema pode ser minimizado se a conceitua o envolvida no dom nio for pelo menos parcialmente explicitada o que pode ser feito por meio de uma ontologia de dom nio Uma ontologia de dom nio um artefato de engenharia que busca explicitar a conceitua o de um dom nio particular Uma conceitua o por sua vez corresponde ao conjunto de conceitos usados para interligar abstra es de entidades de um dado dom nio Assim uma ontologia de dom nio tem como objetivo explicitar e formalmente definir os conceitos rela es propriedades e restri es em um dom nio particular GUIZZARDI 2005 Ontologias de dom nio t m diversos usos dentre eles JASPER USCHOLD 1999 1 apoio comunica o entre pessoas envolvidas no dom nio ii integra o de dados e interoperabilidade de sistemas desenvolvidos para o dom nio e iii especifica o reutiliz vel para a constru o de sistemas no dom nio Ontologias de dom nio podem ser usadas como modelos de dom nio em uma abordagem de Engenharia de Dom nio Assim como discutido na se o anterior pode se pensar que o processo de Engenharia de Dom nio neste caso envolveria atividades de Modelagem da Ontologia Projeto da Ontologia e Implementa o
64. do sistema Essas Engenharia de Requisitos Notas de Aula Cap tulo 3 Levantamento de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 64 expectativas de qualidade do produto t m de ser exploradas durante o levantamento de requisitos WIEGERS 2003 Clientes geralmente n o apontam suas expectativas de qualidade explicitamente Contudo informa es providas por eles durante o levantamento de requisitos fornecem algumas pistas sobre o que eles t m em mente Assim necess rio definir o que os usu rios pensam quando eles dizem que o sistema deve ser amig vel r pido confi vel ou robusto WIEGERS 2003 H muitos atributos de qualidade que podem ser importantes para um sistema Uma boa estrat gia para levantar requisitos n o funcionais de produto consiste em explorar uma lista de potenciais atributos de qualidade que a grande maioria dos sistemas deve apresentar em algum n vel Por exemplo o modelo de qualidade externa e interna de produtos de software definido na norma ISO IEC 9126 1 utilizado como refer ncia para a avalia o de produtos de software define seis caracter sticas de qualidade desdobradas em subcaracter sticas a saber ISO IEC 2001 e Funcionalidade refere se exist ncia de um conjunto de fun es que satisfaz s necessidades expl citas e impl citas e suas propriedades espec ficas Tem como subcaracter sticas adequa o acur cia interoperabilidade se
65. documentadas Conforme listado no in cio desta se o s o informa es complementares importantes atores interessados e interesses pr condi es p s condi es requisitos relacionados e classes relacionadas Conforme discutido na Se o 5 1 um ator representa um papel que entidades f sicas ou sociais podem desempenhar na intera o com o sistema Essas entidades f sicas s o tipicamente pessoas dispositivos ou outros sistemas que s o externos ao sistema em desenvolvimento Muitas vezes apenas o nome de um ator como mostrado em um diagrama de casos de uso pode ser pouco para um real entendimento do que representa esse ator Assim importante que uma descri o sucinta dos atores seja feita Uma vez que um mesmo ator pode atuar em v rios casos de uso a descri o dos atores n o deve ser feita dentro da descri o dos casos de uso mas separada como uma se o espec fica dentro do Documento de Especifica o de Requisitos Inicialmente atores podem ser documentados em uma tabela de duas colunas contendo o nome e a descri o do ator Como atores interagindo com o sistema definem as interfaces do sistema com o mundo externo pode ser til adicionar informa es sobre o perfil do ator nessa intera o Quando o ator um ator humano esse perfil indicaria as habilidades e a experi ncia do ator informa es valiosas para o projeto da interface com o usu rio Adicionalmente pode se incluir uma classifica o se
66. em detalhes as atividades do processo de engenharia de requisitos O Cap tulo 17 Beyond Requirements Development discute as rela es entre requisitos e outros artefatos do processo de software dentre eles planos de projeto projeto design c digo e testes Em ROBERTSON ROBERTSON 2006 o foco tamb m a Engenharia de Requisitos e portanto h v rios cap tulos que abordam temas discutidos nestas notas de aula Sugere se em especial a leitura dos cap tulos 1 e 2 O Cap tulo 1 What are Requirements aborda o que s o requisitos e tipos de requisitos Apresenta ainda brevemente o processo de requisitos proposto no livro denominado Volere e o modelo de documento de requisitos proposto O Cap tulo 2 The Requirements Process d uma vis o geral do processo de requisitos indicando os demais cap tulos do livro que discutem em detalhes as suas atividades Livros de Engenharia de Software tamb m abordam a Engenharia de Requisitos tendo em vista que requisitos s o parte fundamental do processo de software Dentre os diversos livros de Engenharia de Software sugerem se tr s SOMMERVILLE 2007 PFLEEGER 2004 e PRESSMAN 2006 Em SOMMERVILLE 2007 a parte 2 Requisitos como o pr prio nome indica dedicada ao tema Merecem aten o especial os cap tulos 6 e 7 O Cap tulo 6 Engenharia de Requisitos Notas de Aula Cap tulo 2 Engenharia de Requisitos de Software Ricardo de Almeid
67. enquanto os cap tulos 7 8 e 13 discutem a elabora o de diagramas de sequ ncia e de atividades dentre outras coisas 24 Idem coment rio anterior Engenharia de Requisitos Notas de Aula Cap tulo 7 Modelagem Din mica Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 157 Refer ncias do Cap tulo BLAHA M RUMBAUGH J Modelagem e Projetos Baseados em Objetos com UML 2 Elsevier 2006 BOOCH G RUMBAUGH J JACOBSON I UML Guia do Usu rio 2a edi o Elsevier Editora 2006 OLIV A Conceptual Modeling of Information Systems Springer 2007 WAZLAWICK R S An lise e Projeto de Sistemas de Informa o Orientados a Objetos Elsevier 2004 Engenharia de Requisitos Notas de Aula Cap tulo 8 Qualidade e Agilidade em Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 158 Cap tulo 8 Qualidade e Agilidade em Requisitos Durante o processo de Engenharia de Requisitos diversos documentos e modelos podem ser elaborados Durante o levantamento de requisitos requisitos de usu rio s o capturados em um Documento de Requisitos Na fase de an lise esses requisitos s o especificados usando diagramas diversos organizados em dois modelos principais o modelo estrutural e o modelo comportamental O modelo conceitual estrutural de um sistema tem por objetivo descrever as informa es que esse sistema deve representar e gerenciar O modelo comportament
68. ent o ela ocorrer sempre que o evento ocorrer Por fim quando uma transi o disparada uma a o instant nea pode ser realizada Assim o r tulo de uma transi o pode ter at tr s partes todas elas opcionais evento condi oGuarda a o Basicamente a sem ntica de um diagrama de estados a seguinte quando o evento ocorre se a condi o de guarda verdadeira a transi o dispara e a a o realizada instantaneamente O objeto passa ent o do estado origem para o estado destino Se o estado destino possuir uma atividade a ser realizada ela iniciada O fato de uma transi o n o possuir um evento associado normalmente aponta para a exist ncia de um evento impl cito Isso tipicamente ocorre em tr s situa es i o evento impl cito a conclus o da atividade do estado origem e a transi o ocorrer t o logo a atividade associada ao estado origem tiver sido conclu da ii o evento impl cito temporal sendo disparado pela passagem do tempo iii o evento impl cito torna a condi o de guarda verdadeira na base de informa es do sistema mas o evento em si n o modelado Embora ambos os termos a o e atividade denotem processos eles n o devem ser confundidos A es s o consideradas processos instant neos atividades por sua vez est o sempre associadas a estados e t m dura o no tempo Vale a pena observar que no mundo real n o h processos efetivamente instant neos Po
69. entre uma abstra o e todos os seus clientes Figura 2 6 Ilustra o do conceito de Classifica o BOOCH 1994 Liga es e Associa es Em qualquer sistema objetos relacionam se uns com os outros Por exemplo em o empregado Jo o trabalha no Departamento de Pessoal temos um relacionamento entre o objeto empregado Jo o e o objeto Departamento de Pessoal Liga es e associa es s o meios de se representar relacionamentos entre objetos e entre classes respectivamente Uma liga o uma conex o entre objetos No exemplo anterior h uma liga o entre os objetos Jo o e Departamento de Pessoal Uma associa o por sua vez descreve um conjunto de liga es com estrutura e sem ntica comuns No exemplo anterior h uma associa o entre as classes Empregado e Departamento Todas as Engenharia de Requisitos Notas de Aula Cap tulo 4 An lise de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 79 liga es de uma associa o interligam objetos das mesmas classes e assim uma associa o descreve um conjunto de potenciais liga es da mesma maneira que uma classe descreve um conjunto de potenciais objetos BLAHA RUMBAUGH 2006 Uma associa o comum entre duas classes representa um relacionamento estrutural entre pares significando que essas duas classes est o em um mesmo n vel sem que uma seja mais importante do que a outra Al m das associa es comuns
70. es como tamb m est o garantidas certas condi es matem ticas vantajosas como um ponto de nulidade As escalas m tricas tem como tra o marcante o fato de permitirem que sejam feitas opera es matem ticas sobre os dados obtidos do question rio e portanto uma an lise mais completa Para obter essa vantagem uma estrat gia bastante utilizada consiste em tornar uma escala ordin ria em uma escala m trica como no exemplo abaixo Qu o til o suporte t cnico do Centro de Informa o 1 Nada til 2 3 4 5 Extremamente til Claramente originalmente ela n o era exatamente uma escala de intervalo mas ao ancorar a escala em ambas as extremidades permite ao analista assumir que os respondentes v o perceber os intervalos como iguais tornando an lises quantitativas poss veis Na constru o de escalas alguns problemas podem ocorrer A seguir s o listados alguns desses problemas e poss veis solu es KENDALL KENDALL 2010 Engenharia de Requisitos Notas de Aula Cap tulo 3 Levantamento de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 46 e Condescend ncia a pessoa responde a todas as quest es do mesmo jeito Solu o de uma quest o para a outra mover a categoria m dia para a esquerda ou direita em rela o ao centro e Tend ncia Central a pessoa responde tudo na m dia Solu o tornar as diferen as menores nos extremos ajustar a for a dos
71. especializa o e generaliza o s o muito teis para a estrutura o de sistemas Com elas poss vel construir hierarquias de classes A heran a um mecanismo para modelar similaridades entre classes representando as abstra es de generaliza o e especializa o Atrav s da heran a poss vel tornar expl citos atributos associa es e opera es comuns em uma hierarquia de classes O mecanismo de heran a possibilita reutiliza o captura expl cita de caracter sticas comuns e defini o incremental de classes No que se refere defini o incremental de classes a heran a permite conceber uma nova classe como um refinamento de outras classes A nova classe pode herdar as similaridades e definir apenas as novas caracter sticas A heran a portanto um relacionamento entre classes em contraposi o s associa es que representam relacionamentos entre objetos das classes no qual uma classe compartilha a estrutura e o comportamento definidos em outras uma ou mais classes A classe que herda caracter sticas dita subclasse e a que fornece as caracter sticas superclasse Desta forma a heran a representa uma hierarquia de abstra es na qual uma subclasse herda de uma ou mais superclasses Tipicamente uma subclasse aumenta ou redefine caracter sticas de suas superclasses Assim se uma classe B herda de uma classe 4 todas as caracter sticas descritas em 4 tornam se automaticamente parte de B qu
72. ficos Usar um tipo de dados primitivo nestes casos tais como String ou 15 O ISBN International Standard Book Number um sistema internacional padronizado que identifica numericamente os livros segundo o t tulo o autor o pa s a editora individualizando os inclusive por edi o Utilizado tamb m para identificar software seu sistema num rico pode ser convertido em c digo de barras Engenharia de Requisitos Notas de Aula Cap tulo 6 Modelagem Conceitual Estrutural Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 124 int insuficiente pois n o s o quaisquer cadeias de caracteres ou n meros que se caracterizam como ISBNs CPFs ou CNPJs v lidos Tipos de dados espec ficos podem apresentar propriedades Por exemplo CPF um n mero de 11 d gitos que pode ser dividido em duas partes os 9 primeiros d gitos e os dois ltimos que s o d gitos verificadores Um tipo de dados especial a enumera o Na enumera o os valores do tipo s o enumerados explicitamente na forma de literais como o caso do tipo DiaSemana que tipicamente definido como um tipo de dados compreendendo sete valores Segunda Ter a Quarta Quinta Sexta S bado e Domingo importante observar que tipos de dados enumerados s devem ser usados quando se sabe priori quais s o os seus valores e eles s o fixos Assim s o bons candidatos a tipos enumerados informa es como sexo M F estado civil etc
73. fim uma vez testado no ambiente de desenvolvimento o software pode ser colocado em produ o Usu rios devem ser treinados o ambiente de produ o deve ser configurado e o sistema deve ser instalado e testado agora pelos usu rios no ambiente de produ o testes de homologa o ou aceita o Caso o software demonstre prover as capacidades requeridas ele pode ser aceito e a opera o iniciada Requisitos t m um papel central no desenvolvimento de software uma vez que uma das principais medidas do sucesso de um software o grau no qual ele atende aos objetivos e requisitos para os quais foi constru do Requisitos s o a base para estimativas modelagem projeto implementa o testes e at mesmo para a manuten o Portanto est o presentes ao longo de todo o ciclo de vida de um software Engenharia de Requisitos Notas de Aula Cap tulo 1 Introdu o Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 3 Nos est gios iniciais de um projeto requisitos t m de ser levantados entendidos e documentados atividades de Levantamento An lise e Documenta o de Requisitos Dada a import ncia dos requisitos para o sucesso de um projeto atividades de controle da qualidade devem ser realizadas para verificar validar e garantir a qualidade dos requisitos uma vez que os custos ser o bem maiores se defeitos em requisitos forem identificados tardiamente Mesmo quando coletados de forma sistem tica requisit
74. fluxo de eventos normal Para facilitar a rastreabilidade sugere se usar como nome do evento exatamente o mesmo nome do caso de uso ou do fluxo de eventos Seja o exemplo de uma locadora de autom veis que possua dentre outros os casos de uso mostrados na Figura 7 3 os quais possuem os fluxos de eventos mostrados nas notas anexadas aos casos de uso Por n o se comportar como um estado normal o estado inicial considerado um pseudoestado no metamodelo da UML Engenharia de Requisitos Notas de Aula Cap tulo 7 Modelagem Din mica Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 145 Fluxos de Eventos Comprar Carro vender Carro Fluxos de Eventos Enviar Carro para Manuten o Liberar Carro para Uso Funcion r Fluxos de Eventos Transferir Carro para Outra Localidade Receber Carro Vindo de Outra Localidade Fluxos de Eventos Efetuar Nova Loca o Estender Loca o Retirar Carro Devolver Efetuar Loca o Carro Reportar Defeito em Carro Figura 7 3 Locadora de Autom veis Casos de Uso e Fluxos de Eventos Associados A classe Carro tem o seu comportamento definido pela m quina de estados do diagrama de gr fico de estados da Figura 7 4 Ao ser adquirido fluxo de eventos Comprar Carro do caso de uso Negociar Carro o carro colocado Em Prepara o Quando liberado para uso fluxo de eventos Liberar Carro para Uso do caso de uso Efetuar Manuten o de Carr
75. meios de se verificar e validar requisitos Contudo imprescind vel ainda realizar revis es dos documentos de requisitos De maneira geral em uma revis o processos documentos e outros artefatos s o revisados por um grupo de pessoas com o objetivo de avaliar se os mesmos est o em conformidade com os padr es organizacionais estabelecidos e se o prop sito de cada um deles est sendo atingido Assim o objetivo de uma revis o detectar erros e inconsist ncias em artefatos e processos sejam eles relacionados forma sejam eles em rela o ao conte do e apont los aos respons veis pela sua elabora o ROCHA MALDONADO WEBER 2001 Em um formato de revis o t cnica formal o processo de revis o come a com o planejamento da revis o quando uma equipe de revis o formada tendo frente um l der A equipe de revis o deve incluir membros da equipe que possam ser efetivamente Engenharia de Requisitos Notas de Aula Cap tulo 2 Engenharia de Requisitos de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 19 teis para atingir o objetivo da revis o Muitas vezes a pessoa respons vel pela elabora o do artefato a ser revisado integra a equipe de revis o ROCHA MALDONADO WEBER 2001 O prop sito da revis o deve ser previamente informado e o material a ser revisado deve ser entregue com anteced ncia para que cada membro da equipe de revis o possa avali lo Uma vez que
76. o com o usu rio ao longo de todo o ciclo de vida do desenvolvimento Contudo a prototipagem tamb m pode ser fonte de problemas dentre eles KENDALL KENDALL 2010 AURUM WOHLIN 2005 WIEGERS 2003 Ger ncia do projeto Normalmente v rias itera es s o necess rias para se refinar um prot tipo Sob esta tica surge uma importante quest o quando parar Se essa quest o n o for tratada com cuidado a prototipagem pode se estender indefinidamente importante pois delinear e seguir um plano para coletar analisar e interpretar as informa es de feedback do usu rio Al m disso em alguns casos trabalhar com prot tipos pode ser caro e demandar muito tempo Considerar o prot tipo como sendo o sistema final o maior risco da prototipagem que usu rios ao verem um prot tipo rodando concluam que o projeto est pr ximo de seu fim achando que o prot tipo o sistema final Analogamente os desenvolvedores podem se sentir tentados a transformar prot tipos descart veis no sistema n o levando em conta que a qualidade pode n o ter sido apropriadamente considerada Assim gerenciar expectativas fundamental para um uso bem sucedido da prototipagem Todos que veem o prot tipo devem entender seu prop sito e suas limita es 3 2 6 Outras T cnicas de Levantamento de Requisitos Al m das t cnicas discutidas anteriormente h v rias outras igualmente teis Dentre elas podem ser citadas Investiga o o
77. o de uma lista de potenciais classes para o sistema em estudo Um modelo conceitual estrutural para uma aplica o complexa pode ter dezenas de classes e portanto pode ser necess rio definir uma representa o concisa capaz de orientar um leitor em um modelo desta natureza O agrupamento de classes em subsistemas serve basicamente a este prop sito podendo ser til tamb m para a organiza o de grupos de trabalho em projetos extensos Conforme discutido no Cap tulo 5 a base principal para a identifica o de subsistemas a complexidade do dom nio do problema Atrav s da identifica o e agrupamento de classes em subsistemas poss vel controlar a visibilidade do leitor e assim tornar o modelo mais compreens vel Assim da mesma maneira que casos de uso s o agrupados em pacotes classes tamb m devem ser Quando uma cole o de classes colabora entre si para realizar um conjunto coeso de responsabilidades casos de uso elas podem ser vistas como um subsistema Assim um subsistema uma abstra o que prov uma refer ncia para mais detalhes em um modelo de an lise incluindo tanto casos de uso quanto classes O agrupamento de classes em subsistemas permite apresentar o modelo global em uma perspectiva mais alta Esse n vel Engenharia de Requisitos Notas de Aula Cap tulo 6 Modelagem Conceitual Estrutural Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 122 ajuda o leitor a rever o modelo
78. o serviria a seu prop sito Da mesma forma que um mapa precisa ser significativamente menor que o territ rio que ele mapeia incluindo apenas as informa es selecionadas um modelo deve abstrair apenas as caracter sticas relevantes de um sistema para seu entendimento Assim pode se definir abstra o como sendo o princ pio de ignorar aspectos n o relevantes de um assunto segundo a perspectiva de um observador tornando poss vel uma concentra o maior nos aspectos principais do mesmo De fato a abstra o consiste na sele o que um observador faz de alguns aspectos de um assunto em detrimento de outros que n o demonstram ser relevantes para o prop sito em quest o A Figura 2 4 ilustra o conceito de abstra o TEMPERATURA S o Paulo Mapa de Temperaturas Figura 2 4 Ilustra o do Conceito de Abstra o Engenharia de Requisitos Notas de Aula Cap tulo 4 An lise de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 76 Encapsulamento No mundo real um objeto pode interagir com outro sem conhecer seu funcionamento interno Uma pessoa por exemplo utiliza um forno de microondas sem saber efetivamente qual a sua estrutura interna ou como seus mecanismos internos s o ativados Para utiliz lo basta saber usar seu painel de controle a interface do aparelho para realizar as opera es de ligar desligar informar o tempo de cozimento etc Como essas opera es produze
79. o sistema Um diferencial dessa t cnica que ela promove a livre express o favorecendo a descoberta de solu es novas e inovadoras para problemas existentes AURUM WOHLIN 2005 e JAD Joint Application Development envolve a participa o de diferentes interessados na investiga o por meio de discuss es tanto de problemas a serem resolvidos quanto das solu es dispon veis para esses problemas Com as diversas partes envolvidas representadas decis es podem ser tomadas e quest es resolvidas mais rapidamente Em uma sess o JAD ao contr rio de uma sess o de brainstorming as metas do sistema j est o definidas Contudo o foco de uma se o JAD de requisitos ainda recai nas necessidades e desejos de usu rios e do pr prio neg cio e n o em detalhes t cnicos AURUM WOHLIN 2005 3 2 3 Question rios Question rio ou survey uma t cnica de levantamento de informa es que permite ao analista capturar de v rias pessoas afetadas pelo sistema atitudes cren as comportamentos e caracter sticas Atitudes referem se a o que as pessoas na organiza o dizem querer cren as referem se a o que as pessoas pensam ser realmente verdade comportamento o que as pessoas fazem caracter sticas s o propriedades de pessoas ou coisas KENDALL KENDALL 2010 H muitas similaridades entre question rios e entrevistas e pode ser til utilizar as duas abordagens em conjunto para refinar respostas n o claras de um que
80. ou um tipo de dado espec fico de dom nio Tipos de dados espec ficos de dom nio devem ser definidos no Dicion rio de Dados do Projeto A multiplicidade a especifica o do intervalo permitido de itens que o atributo pode abrigar O padr o que cada atributo tenha um e somente um valor para o atributo Quando um atributo for opcional ou quando puder ter mais do que uma ocorr ncia a multiplicidade deve ser informada indicando o valor m nimo e o valor m ximo da seguinte forma valor m nimo valor m ximo A seguir s o dados alguns exemplos e nome String gt inst ncias da classe t m obrigatoriamente um e somente um nome e carteira String 0 1 gt inst ncias da classe t m uma ou nenhuma carteira e telefones Telefone 0 gt inst ncias da classe t m um ou v rios telefones e pessoasContato String 2 gt inst ncias da classe t m exatamente duas pessoas de contato Engenharia de Requisitos Notas de Aula Cap tulo 6 Modelagem Conceitual Estrutural Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 126 Um atributo pode ter um valor padr o inicial ou seja um valor que quando n o informado outro valor ser atribu do ao atributo O campo valorlnicial descreve exatamente este valor O exemplo abaixo ilustra o uso de valor inicial origem Ponto 0 0 gt a origem quando n o informado outro valor ser o ponto 0 0 Finalmente podem ser indicadas propriedades dos at
81. para que a exclus o possa ser feita uma informa o que n o pode ser alterada ou uma informa o do objeto que n o apresentada na consulta Deve se indicar antes da observa o a qual a o ela se refere I para inclus o A para altera o C para consulta e E para exclus o As colunas Requisitos e Classes indicam respectivamente os requisitos que est o sendo ou que devem ser tratados pelo caso de uso e as classes do dom nio do problema necess rias para a realiza o do caso de uso O objetivo dessas colunas manter a rastreabilidade dos casos de uso para requisitos e classes respectivamente de maneira an loga ao recomendado no formato completo A Tabela 5 2 ilustra a descri o de casos de usos cadastrais do subsistema Controle de Acervo de uma videolocadora Engenharia de Requisitos Notas de Aula Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo Cap tulo 5 Modelagem de Casos de Uso 101 Tabela 5 2 Descri o de Casos de Uso Cadastrais Controle de Acervo de Videolocadora Caso de Uso A es Poss veis Observa es Requisitos Classes Cadastrar Filme LA C E I Informar t tulo original t tulo em portugu s pa s ano diretores atores RF9 RNFI Filme Distribuidora sinopse dura o g nero distribuidora tipo de udio p ex Dolby Digital 2 0 idioma do udio e idioma da legenda E N o permitida a
82. para um particular sistema de informa o uma meta crucial da modelagem conceitual OLIV 2007 Na modelagem conceitual segundo o paradigma orientado a objetos tipos de entidades s o modelados como classes Tipos de relacionamentos s o modelados como atributos e associa es Assim o prop sito da modelagem conceitual estrutural orientada a objetos definir as classes atributos e associa es que s o relevantes para tratar o problema a ser resolvido Para tal as seguintes tarefas devem ser realizadas e Identifica o de Classes e Identifica o de Atributos e Associa es e Especifica o de Hierarquias de Generaliza o Especializa o Engenharia de Requisitos Notas de Aula Cap tulo 6 Modelagem Conceitual Estrutural Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 119 importante notar que essas atividades s o dependentes umas das outras e que durante o desenvolvimento elas s o realizadas tipicamente de forma paralela e iterativa sempre visando ao entendimento do dom nio do problema desconsiderando aspectos de implementa o Este cap tulo aborda a modelagem conceitual estrutural discutindo os principais aspectos dessa importante tarefa quando realizada segundo o paradigma orientado a objetos A Se o 6 1 discute o processo de identifica o de classes A Se o 6 2 aborda a identifica o de atributos e associa es Finalmente a Se o 6 3 discute a especifica o
83. problemasRegistrados String dataLocacao Date i EEEF R dataDevolucaoPrevista Date valorDevido Currency caucao Currency estado EstadoLocacao Locacao data Date valor Currency forma FormaPagamento Figura 7 10 Distribuindo as responsabilidades Finalmente vale a pena comentar que estados de uma classe modal podem ser tratados por meio de opera es ao inv s de atributos Seja o exemplo anterior de loca es de carros Figura 7 10 O estado de uma loca o pode ser computado a partir dos atributos e associa es da classe Locacao sem haver a necessidade de um atributo estado Se uma loca o n o tem uma devolu o associada ent o ela est ativa Estando ativa se a data corrente menor ou igual data de devolu o prevista ent o a loca o est em curso normal caso contr rio ela est com prazo expirado Se uma loca o possui uma devolu o mas n o possui um pagamento associado ent o ela est pendente Finalmente se a loca o possui um pagamento associado ent o ela est conclu da Em casos como este pode se optar por tratar estado como uma opera o e n o como um atributo Opcionalmente pode se utilizar a opera o para calcular o valor de um atributo derivado estado Atributos derivados s o representados na UML precedidos por uma barra no exemplo estado 7 3 Diagramas de Atividades Um diagrama de atividades como um fluxograma no sentido que focali
84. projeto design servindo como base para a tomada de decis es nessa fase Os requisitos n o funcionais t m origem nas necessidades dos usu rios em restri es de or amento em pol ticas organizacionais em necessidades de interoperabilidade com outros sistemas de software ou hardware ou em fatores externos como regulamentos e legisla es SOMMERVILLE 2007 Assim os requisitos n o funcionais podem ser classificados quanto sua origem Existem diversas classifica es de requisitos n o funcionais Sommerville 2007 por exemplo classifica os em e Requisitos de produto especificam o comportamento do produto sistema Referem se a atributos de qualidade que o sistema deve apresentar tais como confiabilidade usabilidade efici ncia portabilidade manutenibilidade e seguran a e Requisitos organizacionais s o derivados de metas pol ticas e procedimentos das organiza es do cliente e do desenvolvedor Incluem requisitos de processo padr es de processo e modelos de documentos que devem ser usados requisitos de implementa o tal como a linguagem de programa o a ser adotada restri es de entrega tempo para chegar ao mercado time to market restri es de cronograma etc restri es or ament rias custo custo benef cio etc e Requisitos externos referem se a todos os requisitos derivados de fatores externos ao sistema e seu processo de desenvolvimento Podem incluir requisitos de interoperabilida
85. resposta ocorr ncia de eventos e Diagramas de Atividades mostram a estrutura de um processo Proveem uma vis o din mica do sistema ou de uma por o do sistema e podem ser usados tanto para modelar processos de neg cio quanto para modelar fun es do sistema Um diagrama de atividades d nfase ao fluxo de controle entre objetos e Diagramas de Intera o Um diagrama de intera o mostra um conjunto de objetos ou pap is interagindo incluindo as mensagens que podem ser trocadas entre eles Diagramas de intera o proveem uma vis o din mica do comportamento de um sistema ou de uma por o do sistema H dois tipos de diagramas de intera o o Diagramas de Sequ ncia s o um tipo de diagrama de intera o cuja nfase est na ordena o temporal das mensagens o Diagramas de Comunica o t m o mesmo prop sito dos diagramas de sequ ncia apresentando contudo nfase diferente A nfase dos diagramas de comunica o est na organiza o estrutural dos objetos que enviam ou recebem mensagens No contexto da Engenharia de Requisitos al m dos diagramas anteriormente citados merecem aten o tamb m os diagramas de pacotes Na UML pacote um mecanismo de prop sito geral usado para organizar elementos de modelagem em grupos Assim um diagrama de pacotes mostra a decomposi o de um modelo em unidades menores e suas depend ncias BOOCH RUMBAUGH JACOBSON 2006 Vale ressaltar mais uma vez que a UML
86. rito Santo 113 5 4 4 Diretrizes para o Uso dos Tipos de Relacionamentos entre Casos de Uso Os relacionamentos entre casos de uso devem ser utilizados com cuidado para evitar a introdu o de complexidade desnecess ria As seguintes orienta es s o teis para ajudar a decidir quando usar relacionamentos entre casos de uso em um diagrama de casos de uso e A inclus o tipicamente aplic vel quando se deseja capturar um fragmento de comportamento comum a v rios casos de uso Na maioria das vezes o caso de uso de inclus o uma atividade significativa mas n o como um fim em si mesma BLAHA RUMBAUGH 2006 Ou seja o caso de uso de inclus o n o precisa ser uma transa o completa e Um relacionamento de inclus o empregado quando h uma por o de comportamento que similar ao longo de um ou mais casos de uso e n o se deseja repetir a sua descri o Para evitar redund ncia e assegurar re so extrai se essa descri o e se compartilha a mesma entre diferentes casos de uso Desta maneira utiliza se a inclus o para evitar ter de descrever o mesmo fragmento de comportamento v rias vezes capturando o comportamento comum em um caso de uso pr prio BOOCH RUMBAUGH JACOBSON 2006 e N o se deve utilizar o relacionamento de generaliza o especializa o para compartilhar fragmentos de comportamento Para este prop sito deve se usar a rela o de inclus o BLAHA RUMBAUGH 2006 e A rela o de extens o
87. sa das i e objetos passados de uma atividade para outra BOOCH RUMBAUGH JACOBSON 2006 Este cap tulo aborda a modelagem din mica discutindo os principais aspectos dessa importante tarefa quando realizada segundo o paradigma orientado a objetos S o abordados os diagramas de estados e os diagramas de atividades Diagramas de intera o n o s o discutidos neste texto A se o 7 1 discute os diferentes tipos de requisi es de a es e como os diagramas din micos da UML podem ser usados para model los A se es 7 2 7 3 e 7 4 tratam respectivamente dos diagramas de transi o de estados diagramas de sequ ncia e diagramas de atividades A se o 7 4 aborda a especifica o de opera es Finalmente a se o 7 5 explora as rela es existentes entre os v rios modelos elaborados durante a an lise de requisitos as quais devem ser atentamente avaliadas durante a atividade de verifica o de requisitos 7 1 Tipos de Requisi es de A o Um sistema de informa o mant m uma representa o do estado do dom nio em sua base de informa es Esse estado de coisas do dom nio em um dado ponto no tempo corresponde ao conjunto de inst ncias dos tipos de entidades classes e de relacionamentos associa es relevantes que existem no dom nio naquele momento O esquema estrutural se preocupa com essa perspectiva Entretanto o sistema tamb m realiza a es O efeito de uma a o pode ser uma altera o em sua b
88. saque Poder se ia ent o estender o caso de uso Efetuar Saque de modo que quando necess rio outro caso de uso denominado Coletar Estat sticas de Notas contasse e acumulasse o tipo das notas entregues em um saque conforme mostra a Figura 5 12 A Figura 5 13 mostra a descri o do caso de uso Efetuar Saque indicando o ponto de extens o entrega do dinheiro 2 Nota o nico item de anota o da UML Notas s o usadas para explicar partes de um modelo da UML S o coment rios inclu dos para descrever esclarecer ou fazer alguma observa o sobre qualquer elemento do modelo Assim uma nota apenas um s mbolo para representar restri es e coment rios anexados a um elemento ou a uma cole o de elementos Graficamente uma nota representada por um ret ngulo com um dos cantos com uma dobra de p gina acompanhado por texto e anexada ao s elemento s anotados por meio de linha s pontilhada s BOOCH RUMBAUGH JACOBSON 2006 No exemplo da Figura 5 11 a nota est anexada ao relacionamento de extens o adicionando lhe informa es sobre o ponto de extens o e a condi o associados extens o Engenharia de Requisitos Notas de Aula Cap tulo 5 Modelagem de Casos de Uso Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 109 Sistema Caixa Autom tico Controlar Estat sticas de Notas lt lt extend gt _ Efetuar Saque lt e extension points entrega do dinheirg E ds lda Sis
89. se preposi es O nome do atributo deve ser iniciado com letra min scula enquanto os nomes dos complementos devem iniciar com letras mai sculas sem dar um espa o em rela o palavra anterior Acentos n o devem ser utilizados Atributos monovalorados devem iniciar com substantivo no singular p ex nome razaoSocial enquanto atributos multivalorados devem iniciar com o substantivo no plural p ex telefones A sintaxe de atributos na UML em sua forma plena a seguinte BOOCH RUMBAUGH JACOBSON 2006 visibilidade nome tipo multiplicidade valorlnicial propriedades A visibilidade de um atributo indica em que situa es esse atributo vis vel por outras classes Na UML h quatro n veis de visibilidade os quais s o marcados pelos seguintes s mbolos p blico o atributo pode ser acessado por qualquer classe protegido o atributo s pass vel de acesso pela pr pria classe ou por uma de suas especializa es privado o atributo s pode ser acessado pela pr pria classe pacote o atributo s pode ser acessado por classes declaradas dentro do mesmo pacote da classe a que pertence o atributo A informa o de visibilidade inerente fase de projeto e n o deve ser expressa em um modelo conceitual Assim em um modelo conceitual atributos devem ser especificados sem nenhum s mbolo antecedendo o nome O tipo indica o tipo de dado do atributo o qual deve ser um tipo de dado primitivo
90. sejam compat veis com o limite de cr dito do cliente Pr condi es O caixa autom tico deve estar conectado ao sistema banc rio P s condi es O saque efetuado debitando o valor da conta do cliente e entregando o mesmo valor para o cliente em esp cie Fluxo de Eventos Normal O cliente insere seu cart o no caixa autom tico que analisa o cart o e verifica se ele aceit vel Se o cart o aceit vel o caixa autom tico solicita que o cliente informe a senha O cliente informa a senha O caixa autom tico envia os dados do cart o e da senha para o sistema banc rio para valida o Se a senha estiver correta o caixa solicita que o cliente informe o tipo de transa o a ser efetuada O cliente seleciona a op o saque e o caixa solicita que seja informada a quantia O cliente informa a quantia a ser sacada O caixa envia uma requisi o para o sistema banc rio para que seja efetuado um saque na quantia especificada Se o saque autorizado as notas s o preparadas e liberadas Fluxos de Eventos de Exce o e O cart o n o aceit vel Se o cart o n o aceit vel seja porque sua tarja magn tica n o pass vel de leitura seja porque de um tipo incompat vel uma mensagem de erro de leitura mostrada e Senha incorreta Se a senha informada est incorreta uma mensagem mostrada para o cliente que poder entrar com a senha novamente Caso o cliente informe tr s vezes senha incorreta o cart o
91. ser combinados para apoiar um mesmo projeto de desenvolvimento Por exemplo no est gio de levantamento preliminar de requisitos prot tipos de interface podem ser usados para refinar requisitos Esses requisitos s o ent o gradativamente refinados e implementados em uma s rie de prot tipos evolutivos considerando inicialmente apenas os principais processos de neg cio caracter sticas selecionadas e algumas camadas do software interface com o usu rio e l gica de neg cio Outros elementos s o incorporados ao produto final por meio de incrementos e itera es sucessivas at se obter o produto de software final A prototipagem tamb m requer planejamento Devem se definir porque quando e que tipo de prot tipo usar selecionar usu rios para avaliar o prot tipo e definir como o feedback do usu rio ser obtido Usu rios s o fundamentais na prototipagem Para capturar as rea es dos usu rios em rela o ao prot tipo outras t cnicas de levantamento de informa o devem ser usadas em conjunto Durante a experimenta o do usu rio com o prot tipo pode se utilizar observa o Para capturar opini es e sugest es podem ser empregados al m da observa o entrevistas e question rios KENDALL KENDALL 2010 Para o desenvolvimento do prot tipo as seguintes diretrizes podem ser teis KENDALL KENDALL 2010 WIEGERS 2003 e Defina o prop sito de um prot tipo antes de come ar a constru lo e Trabalhe com m
92. um caso de uso abstrato e especializado para as diferentes varia es BLAHA RUMBAUGH 2006 Contudo avalie se n o fica mais simples e direto descrever essas varia es como fluxos alternativos variantes na descri o de casos de uso Quando forem poucas e pequenas as varia es muito provavelmente ser mais f cil captur las na descri o ao inv s de criar hierarquias de casos de uso A Figura 5 17 mostra uma solu o an loga da Figura 5 16 sem usar no entanto especializa es do caso de uso Engenharia de Requisitos Notas de Aula Cap tulo 5 Modelagem de Casos de Uso Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 111 Nome Validar Cart o Fluxo de Eventos Normal 1 O cliente insere o cart o no caixa autom tico O caixa autom tico analisa o cart o e verifica se ele aceit vel 2 3 O caixa autom tico solicita informa o para identifica o do cliente 4 O cliente informa sua identifica o 5 O caixa autom tico envia os dados do cart o e da identifica o para o sistema banc rio para valida o 6 O caixa autom tico solicita que o cliente informe o tipo de transa o a ser efetuada Fluxos de Eventos de Exce o 2a O cart o n o aceit vel Se o cart o n o aceit vel seja porque sua tarja magn tica n o pass vel de leitura seja porque de um tipo incompat vel uma mensagem de erro de leitura mostrada e se retorna ao passo 1 5a
93. uma bifurca o m ltiplas fichas v o surgir uma para cada fluxo de sa da De maneira an loga uma uni o do controle reduz o conjunto de fichas de entrada para uma nica ficha de sa da BLAHA RUMBAUGH 2006 7 4 Especifica o das Opera es Uma vez estudado o comportamento do sistema tem se uma base para a defini o das opera es das classes que comp em o sistema Opera es correspondem a servi os que podem ser solicitados aos objetos de uma classe e s o apresentadas na se o inferior do s mbolo de classe com a seguinte sintaxe para a sua assinatura BOOCH RUMBAUGH JACOBSON 2006 visibilidade nome lista de par metros tipo de retorno A visibilidade de uma opera o indica em que situa es ela vis vel por outras classes podendo uma opera o ser p blica protegida privada e de pacote da mesma forma que atributos ver Se o 6 2 1 A informa o de visibilidade inerente fase de projeto e n o deve ser expressa em um modelo conceitual Para nomear uma opera o sugere se o uso de um verbo no infinitivo o qual pode ser combinado com complementos omitindo se preposi es A exce o fica por conta de opera es com retorno booleano para as quais se sugere usar um nome que d uma no o de 2 A UML admite outras informa es na assinatura de uma opera o Entretanto essas s o as nota es mais comumente utilizadas Engenharia de Requisitos Notas de Aula Cap tulo 7 Mod
94. vel F do MPS o n vel 3 do CMMI ao n vel C do MPS o n vel 4 do CMMI ao n vel B do MPS e finalmente o n vel 5 do CMMI corresponde ao n vel A do MPS O MPS define em seu n vel G o processo de Ger ncia de Requisitos e no n vel D o processo de Desenvolvimento de Requisitos O prop sito do processo de Ger ncia de Requisitos gerenciar os requisitos do produto e dos componentes do produto do projeto e identificar inconsist ncias entre os requisitos os planos do projeto e os produtos de trabalho do projeto Esse processo tem como resultados esperados SOFTEX 2011 GRE 1 O entendimento dos requisitos obtido junto aos fornecedores de requisitos GRE 2 Os requisitos s o avaliados com base em crit rios objetivos e um comprometimento da equipe t cnica com esses requisitos obtido GRE 3 A rastreabilidade bidirecional entre os requisitos e os produtos de trabalho estabelecida e mantida GRE 4 Revis es em planos e produtos de trabalho do projeto s o realizadas visando identificar e corrigir inconsist ncias em rela o aos requisitos GRE 5 Mudan as nos requisitos s o gerenciadas ao longo do projeto O Desenvolvimento de Requisitos por sua vez tem por objetivo definir os requisitos do cliente do produto e dos componentes do produto Esse processo tem como resultados esperados SOFTEX 2011 DRE 1 As necessidades expectativas e restri es do cliente tanto do produto quanto de suas interfaces
95. 1 o Caso de Uso de Extens o 1 executado quando o ponto de extens o 1 do Caso de Uso Base for atingido se a condi o for verdadeira Caso de Uso Base extension points ponto de extens o 1 ponto de extens o 2 ponto de extens o 1 condi o lt lt extend gt 7 Caso de Uso de Extens o 1 Figura 5 11 Associa o de Extens o na UML Uma importante diferen a entre as associa es de inclus o e extens o que na primeira o caso de uso base est ciente do caso de uso de inclus o enquanto na segunda o caso de uso base n o est ciente dos poss veis casos de uso de extens o OLIVE 2007 Assim como no caso da inclus o uma associa o de extens o deve ser referenciada na descri o do caso de uso base Neste caso contudo o caso de uso base apenas aponta o ponto de extens o sem fazer uma refer ncia expl cita ao caso de uso de extens o O local de cada um dos pontos de extens o deve ser indicado na descri o do caso de uso base atrav s de uma refer ncia ao nome do ponto de extens o seguido de ponto de extens o Assim a descri o do fluxo de eventos principal ou alternativo do caso de uso base deve conter indica es expl citas para cada ponto de extens o No exemplo do caixa autom tico suponha que se deseja coletar dados estat sticos sobre os valores das notas entregues nos saques de modo a permitir alimentar o caixa eletr nico com as notas mais adequadas para
96. 7 14 mostra a nota o de objetos fluxos de objetos e estado do objeto Engenharia de Requisitos Notas de Aula Cap tulo 7 Modelagem Din mica Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 155 Atividade 11 objeto Classe e o stado Atividade 12 Figura 7 14 Objetos e Fluxos de Objetos em Diagramas de Atividades da UML objeto fluxo de objeto Um fluxo de objetos implica em um fluxo de controle pois representa o fluxo de um objeto de uma atividade para outra Portanto desnecess rio desenhar um fluxo de controle entre as atividades conectadas por fluxos de objetos BOOCH RUMBAUGH JACOBSON 2006 Neste texto defendemos o uso de diagramas de atividades para complementar a vis o comportamental de casos de uso complexos Sugere se elaborar um diagrama de atividades para cada fluxo de eventos normal complexo mostrando no mesmo diagrama o fluxo de eventos normal e os correspondentes fluxos variantes e de exce o Elaborar diagramas de atividade para casos de uso simples tais como casos de uso cadastrais e de consulta dificilmente adicionar algum valor ao projeto e portanto tais diagramas s o dispens veis Para ajudar os usu rios a entender um diagrama de atividades pode ser til ilustrar a execu o do mesmo usando fichas de atividade Uma ficha colocada no ponto de inicia o do diagrama e ela vai sendo deslocada pelas atividades do diagrama Quando houver
97. Agrupe itens de conte do similar e observe tend ncias de associa o e Coloque quest es menos controversas primeiro Por fim no que se refere ao m todo de aplica o do question rio h diversas possibilidades cada uma delas apresentando vantagens e desvantagens Pode se por exemplo reunir todos os respondedores em um mesmo local para a aplica o do question rio Isso permite alto retorno instru es uniformes e resultado r pido Contudo pode ser dif cil reunir todas as pessoas em s lugar ao mesmo tempo e o respondedor pode ter coisas importantes a fazer KENDALL KENDALL 2010 De maneira geral permite se que os respondentes administrem quando v o responder o question rio Neste caso corre se o risco das pessoas esquecerem ou propositalmente ignorarem o question rio Contudo refor a se a sensa o de anonimato e por conseguinte podem se obter respostas mais confi veis KENDALL KENDALL 2010 Aplicar question rios eletronicamente seja por email seja por meio de formul rio na Web um meio de rapidamente chegar aos respondentes Evitam se custos com c pias as Engenharia de Requisitos Notas de Aula Cap tulo 3 Levantamento de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 47 respostas podem ser dadas de acordo com a conveni ncia dos respondedores e automaticamente coletadas e armazenadas eletronicamente Alguns sistemas para aplicar question rios permitem que o
98. Aula Cap tulo 6 Modelagem Conceitual Estrutural Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 137 um est gio anterior Assim deve se esperar que o trabalho de reposicionamento de atributos e associa es conduza a uma revis o da hierarquia de classes Por fim vale a pena mencionar que durante anos o mecanismo de heran a foi considerado o grande diferencial da orienta o a objetos Contudo com o passar do tempo essa nfase foi perdendo for a pois se percebeu que o uso da heran a nem sempre conduz melhor solu o de um problema de modelagem Hoje a heran a considerada apenas mais uma ferramenta de modelagem utilizada basicamente para fatorar informa es as quais de outra forma ficariam repetidas em diferentes classes WAZLAWICK 2004 Leitura Complementar O livro Conceptual Modeling of Information Systems de Antoni Oliv OLIV 2007 dedicado modelagem conceitual de sistemas Esse livro uma tima refer ncia para os interessados em se aperfei oar no trabalho de modelagem conceitual contendo diversas diretrizes incorporadas nestas notas de aula Os cap tulos 2 3 4 6 7 9 e 10 discutem respectivamente tipos de entidades tipos de relacionamentos restri es de cardinalidade reifica o de associa es tipos gen ricos de relacionamentos incluindo rela es todo parte restri es de integridade e rela es de generaliza o especializa o O Cap
99. Campinas Brazil 2008 Engenharia de Requisitos Notas de Aula Anexo A A Norma ISO IEC 9126 Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 173 Anexo A A Norma ISO IEC 9126 A ISO IEC 9126 uma fam lia de normas que trata da avalia o da qualidade de produtos de software Ela estabelece um modelo de qualidade para produtos de software e apresenta diversas medidas para aferir qualitativa e quantitativamente a presen a dos atributos de qualidade descritos em seu modelo A ISO IEC 9126 dita uma fam lia ou s rie de normas pois dividida em partes a saber Parte 1 Modelo da qualidade Parte 2 M tricas externas Parte 3 M tricas internas Parte 4 M tricas de qualidade em uso A ISO IEC 9126 encontra se em fase de transi o para uma nova fam lia de normas a ISOTEC 25000 Software Product Quality Requirement and Evaluation SQuaRE Entretanto o modelo de qualidade de produto de software proposto nessa norma continua v lido Esse modelo descrito na ISO IEC 9126 1 ISO IEC 2001 dividido em duas partes i qualidade interna e externa ii qualidade em uso O modelo de qualidade interna e externa especifica seis caracter sticas as quais s o por sua vez subdivididas em subcaracter sticas Essas subcaracter sticas s o manifestadas externamente quando o software utilizado e s o resultado de atributos internos Qualidade externa a qualidade do produto percebida q
100. Conforme apontado anteriormente dois importantes insumos para a atividade de identifica o de classes s o o Documento de Requisitos e o Modelo de Casos de Uso Uma maneira bastante pr tica e eficaz de trabalhar a identifica o de classes consiste em olhar esses dois documentos em especial a descri o do minimundo e as descri es de casos de uso procura de classes Diversos autores dentre eles Jacobson 1992 e Wazlawick 2004 sugerem que uma boa estrat gia para identificar classes consiste em ler esses documentos procurando por substantivos Esses autores argumentam que uma classe tipicamente descrita por um nome no dom nio e portanto aprender sobre a terminologia do dom nio do problema um bom ponto de partida Ainda que um bom ponto de partida essa heur stica ainda muito vaga Se o analista segui la fielmente muito provavelmente ele ter uma extensa lista de potenciais classes sendo que muitas delas podem na verdade se referir a atributos de outras classes Al m disso pode ser que importantes classes n o sejam capturadas notadamente aquelas que se referem ao registro de eventos de neg cio uma vez que esses eventos muitas vezes s o descritos na forma de verbos Seja o seguinte exemplo de uma descri o de um dom nio de loca o de autom veis clientes locam carros Seriam consideradas potenciais classes Cliente e Carro Contudo a loca o um evento de neg cio importante que precisa ser regist
101. Din mica Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 139 e Diagrama de Intera o descreve como grupos de objetos colaboram em certo comportamento Diagramas de intera o podem ser de dois tipos diagramas de comunica o e diagramas de sequ ncia Um diagrama de sequ ncia um diagrama de intera o que d nfase ordena o temporal das mensagens trocadas por objetos J um diagrama de comunica o d nfase organiza o estrutural dos objetos que enviam e recebem mensagens Ambos s o usados para ilustrar a vis o din mica de um sistema e Diagrama de Atividades mostra o fluxo de uma atividade para outra em um sistema incluindo sequ ncias e ramifica es de fluxo subatividades e objetos que realizam e sofrem a es Diagramas de atividades s o usados principalmente para a modelagem das fun es de um sistema dando nfase ao fluxo de controle na execu o de um comportamento Diagramas de estados focalizam o comportamento de objetos de uma classe espec fica Diagramas de intera o e de atividades enfocam o fluxo de controle entre v rios objetos e atividades Enquanto os diagramas de intera o d o nfase ao fluxo de controle de um objeto para o outro os diagramas de atividade d o nfase ao fluxo de controle de uma etapa atividade para outra Um diagrama de intera o observa os objetos que passam mensagens um diagrama de atividades focaliza as atividades e suas entradas e
102. ES Universidade Federal do Esp rito Santo 36 cuidado para aproveitar ao m ximo a oportunidade sobretudo quando a entrevista envolve membros da alta ger ncia Onde definir o local onde se dar a entrevista Normalmente o analista vai at o local de trabalho do entrevistado Como conhecendo o objetivo o entrevistado e seu perfil e o tempo dispon vel resta preparar a entrevista cuidadosamente para que a mesma seja o mais produtiva poss vel A prepara o envolve dentre outros a defini o do tipo das quest es a serem feitas a reda o das quest es propriamente dita a defini o da ordem em que as perguntas ser o feitas e a defini o de como a entrevista ser registrada durante a sua condu o Visando responder s quest es acima Kendall e Kendall 2010 sugerem que o planejamento da entrevista envolva os seguintes passos 1 Estudar material existente sobre o dom nio e a organiza o Aten o especial deve ser dada linguagem usada pelos membros da organiza o procurando estabelecer um vocabul rio comum a ser usado na elabora o das quest es da entrevista Este passo visa sobretudo otimizar o tempo despendido nas entrevistas evitando se perguntar quest es b sicas e gerais Estabelecer objetivos De maneira geral h algumas reas sobre as quais o analista desejar fazer perguntas tais como fontes de informa o formatos da informa o frequ ncia na tomada de decis o estilo da tom
103. ES J M Design Patterns Elements of Reusable Object Oriented Software Addison Wesley 1995 GIMENES IM S HUZITA E HM Desenvolvimento Baseado em Componentes Conceitos e T cnicas Editora Ci ncia Moderna 2005 G MEZ P REZ A CORCHO O FERNANDEZ LOPEZ M Ontological Engineering with examples from the areas of Knowledge Management e Commerce and the Semantic Web 2 edition Springer 2007 GUIZZARDI G Ontological Foundations for Structural Conceptual Models Telematics Instituut Fundamental Research Series The Netherlands 2005 JASPER R USCHOLD M A Framework for Understanding and Classifying Ontology Applications Proceedings of the IJCAI99 Workshop on Ontologies and Problem Solving Methods Stockholm Sweden 1999 NUSEIBEH B EASTERBROOK S Requirements Engineering A Roadmap In Procedings of the Future of Software Engineering ICSE 2000 Ireland 2000 p 37 46 ROBERTSON S ROBERTSON J Mastering the Requirements Process 2 Edition Addison Wesley 2006 SU REZ FIGUEROA M A et al NeOn Development Process and Ontology Life Cycle 2007 Dispon vel em http www neon project org web content index php option com weblinks amp view category amp id 17 amp Itemid 73 ZAMBORLINL V GON ALVEZ b GUIZZARDL G Codification and Application of a Well Founded Heart ECG Ontology Proceedings of the 3rd Workshop on Ontologies and Metamodels in Software and Data Engineering
104. Engenharia de Requisitos Notas de Aula Cap tulo 8 Qualidade e Agilidade em Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 171 de sistemas de informa o O processo proposto visa contribuir para a institucionaliza o de pr ticas de re so na Engenharia de Requisitos O processo come a com um levantamento preliminar de requisitos cujo objetivo definir o escopo do projeto e enumerar os principais requisitos funcionais e n o funcionais Paralelamente um modelo conceitual elaborado tomando por base ontologias e padr es de an lise relacionados ao dom nio do problema Os requisitos s o ent o detalhados e os modelos detalhados Como produto um documento de especifica o de requisitos produzido Leitura Complementar Em AMBLER 2004 s o apresentados em detalhes os princ pios e valores da modelagem gil Em especial os cap tulos 3 e 4 apresentam os princ pios dessa abordagem Em GIMENES HUZITA 2005 o Cap tulo 3 aborda aspectos relacionados Engenharia de Dom nio Finalmente em FOWLER 2007 s o apresentados diversos padr es de an lise Em especial os cap tulos de 2 a 11 apresentam diversos padr es de an lise agrupados em categorias Refer ncias do Cap tulo AMBLER S W Modelagem gil Pr ticas Eficazes para a Programa o eXtrema e o Processo Unificado Porto Alegre Bookman 2004 ARANGO G PRIETO D AZ R Domain Analysis Concepts and Research
105. FES Universidade Federal do Esp rito Santo 60 Conforme apontado anteriormente requisitos devem ser test veis Robertson e Robertson 2006 sugerem tr s maneiras de tornar os requisitos test veis e Especificar uma descri o quantitativa de cada adv rbio ou adjetivo de modo que o significado dos qualificadores fique claro e n o amb guo e Trocar os pronomes pelos nomes das entidades e Garantir que todo termo importante seja definido em um gloss rio no documento de requisitos A origem de um requisito deve apontar a partir de que entidade pessoa documento atividade o requisito foi identificado Um requisito identificado durante uma investiga o de documentos p ex tem como origem o s documento s inspecionado s J um requisito levantado em uma entrevista com um certo usu rio tem como origem o pr prio usu rio A informa o de origem importante para se conseguir rastrear requisitos para a sua origem pr tica muito recomendada no contexto da Ger ncia de Requisitos Requisitos podem ter import ncia relativa diferente em rela o a outros requisitos Assim importante que o cliente e outros interessados estabele am conjuntamente a prioridade de cada requisito muito importante saber quem o analista respons vel por um requisito bem como quem s o os interessados clientes usu rios etc naquele requisito S o eles que estar o envolvidos nas discuss es relativas ao requisito incluindo a tentativa
106. Finalmente a Se o 4 6 discute a documenta o de requisitos em n vel de sistema O m todo apresentado em WAZLAWICK 2004 segundo o pr prio autor uma interpreta o e um detalhamento do m todo de an lise e projeto apresentado por Larman Engenharia de Requisitos Notas de Aula Cap tulo 4 An lise de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 72 4 1 Modelagem Conceitual Todo sistema incorpora um esquema conceitual Assim para que o desenvolvimento de um sistema seja bem sucedido necess rio explicitar esse esquema Esse o prop sito da modelagem conceitual OLIVE 2007 O esquema conceitual de um sistema de informa o a especifica o de seus requisitos funcionais Um sistema de informa o um sistema projetado para coletar armazenar processar e distribuir informa o sobre o estado de um dom nio Assim um sistema dessa natureza tem tipicamente tr s prop sitos ou fun es principais OLIVE 2007 e Fun o de Mem ria sob esta tica o objetivo de um sistema de informa o manter uma representa o interna do estado do dom nio O estado do dom nio geralmente alterado com frequ ncia e de muitas maneiras O sistema precisa acompanhar essas altera es e atualizar sua representa o interna adequadamente e Fun o Informativa o sistema deve prover aos usu rios informa es sobre o estado do dom nio A fun o informativa
107. MEZ PEREZ CORCHO FERNANDEZ LOPEZ 2007 Engenharia de Requisitos Notas de Aula Cap tulo 8 Qualidade e Agilidade em Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 168 8 3 3 Padr es de An lise Padr es de software formalizam solu es para problemas recorrentes no desenvolvimento de software com base na experi ncia de especialistas permitindo que essas solu es possam ser reutilizadas em v rias outras situa es por outros especialistas Na engenharia de software padr es s o usados para descrever solu es de sucesso para problemas de software comuns Esses padr es refletem a estrutura conceitual dessas solu es e podem ser aplicados v rias vezes na an lise projeto e produ o de aplica es em um contexto particular DEVEDZIC 1999 O uso pelos engenheiros de software de solu es j conhecidas e testadas ajuda a aumentar o n vel de abstra o a produtividade e a qualidade dos projetos nas v rias fases do desenvolvimento de sistemas COTA 2004 No contexto de desenvolvimento de software padr es procuram representar a experi ncia de muitos esfor os de reengenharia de desenvolvedores que tentaram adquirir maior reusabilidade e flexibilidade em seus produtos de software Representam tamb m a formaliza o de uma solu o para determinada situa o que desenvolvedores sempre se depararam na sua experi ncia em desenvolver sistemas Diante de uma situa o recor
108. Requisitos Notas de Aula Cap tulo 7 Modelagem Din mica Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 149 vender Carro Devolver Carro Receber Carro vindo de Outra Localidade Transferir Carro para Outra Localidade Em Prepara o Enviar C rro para Manuten o Carro para Uso Dispon vel Retirar Carro Em Uso dataCorrente gt dataDevolucaoPrevista Em Uso Normal Em atraso Estender Loca o Reportar Defeito em Carro Reportar Defeito em Carro Figura 7 7 Diagrama de Estados da Classe Carro Disponibilidade com Estado Composto Em Uso adaptado de OLIVE 2007 interessante observar que algumas transi es podem mudar a estrutura da classe Quando os diferentes estados de um objeto n o afetam a sua estrutura mas apenas possivelmente os valores de seus atributos e associa es diz se que a transi o est vel e os diferentes estados podem ser mapeados para um simples atributo WAZLAWICK 2004 conforme discutido anteriormente Entretanto h situa es em que conforme um objeto vai passando de um estado para outro ele vai ganhando novos atributos ou associa es ou seja h uma mudan a na estrutura da classe Seja o exemplo de uma loca o de carro Como mostra a Figura 7 8 quando uma loca o criada ela est ativa em curso normal Quando o carro n o devolvido at a data de devolu o prevista a loca o passa a ati
109. Se um prot tipo for desenvolvido para apoiar o levantamento de requisitos faz sentido utiliz lo posteriormente na valida o Contudo pode n o valer a pena desenvolver um prot tipo apenas para apoiar a valida o de requisitos XOTONYA SOMMERVILLE 1998 Diferentes tipos de prot tipos podem ser desenvolvidos sendo que diferentes autores denominam esses tipos de forma diferente Quanto s camadas da arquitetura que s o efetivamente implementadas um prot tipo pode ser e Prot tipo n o operacional ou de interface apenas a camada de interface com o usu rio implementada as demais camadas da arquitetura do sistema n o s o e portanto o sistema n o faz nenhum processamento propriamente dito Wiegers 2003 denomina este tipo de prot tipo de prot tipo horizontal exatamente porque ele n o trata todas as camadas da arquitetura do sistema til para avaliar certos aspectos do sistema quando a codifica o requerida pela aplica o custosa e a no o b sica do que o sistema pode ser transmitida pela an lise de suas interfaces KENDALL KENDALL 2010 Prot tipos n o operacionais mostram as op es de fun es que estar o dispon veis para o usu rio e a apar ncia das interfaces Contudo n o cont m funcionalidade real s vezes a navega o pode funcionar mas em alguns pontos o usu rio pode se deparar apenas com uma mensagem descrevendo o que seria realmente mostrado Os dados que aparecem em resposta a um
110. Sistema de Operadoras de Cart o de Cr dito autoriza a compra e envia o c digo da autoriza o Figura 5 5 Descri o Parcial do Caso de Uso Efetuar Compra com Variantes Por fim em diversas situa es pode ser desnecessariamente trabalhoso especificar casos de uso segundo um formato completo seja usando uma descri o dos fluxos de eventos no formato livre seja no formato enumerado Para esses casos um formato simplificado na forma de uma tabela pode ser usado O formato tabular normalmente empregado para casos de uso que possuem uma estrutura de intera o simples seguindo uma mesma estrutura geral tais como casos de uso cadastrais ou CRUD e consultas Casos de uso cadastrais de baixa complexidade tipicamente envolvem inclus o altera o consulta e exclus o de entidades e seguem o padr o de descri o mostrado na Figura 5 6 1 CRUD do ingl s Create Read Update and Delete em portugu s Criar Consultar Atualizar e Excluir ou seja casos de uso que proveem as fun es b sicas de manipula o de dados de uma entidade de interesse do sistema Engenharia de Requisitos Notas de Aula Cap tulo 5 Modelagem de Casos de Uso Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 100 Fluxos de Eventos Normais Criar Novo Objeto O ator informa os dados do novo objeto a saber atributos e associa es do objeto Caso os dados sejam v lidos as informa es s o
111. UFES Universidade Federal do Esp rito Santo Engenharia de Requisitos Notas de Aula Ricardo de Almeida Falbo E mail falbo minf ufes br 2012 Sum rio Cap tulo 1 Introdu o 1 1 Desenvolvimento de Software e Engenharia de Requisitos 1 2 A Organiza o deste Texto Cap tulo 2 Engenharia de Requisitos de Software 2 1 Requisitos 2 2 O Processo de Engenharia de Requisitos 2 3 Engenharia de Requisitos e Normas e Modelos de Qualidade Cap tulo 3 Levantamento de Requisitos 3 1 Vis o Geral do Levantamento de Requisitos 3 2 T cnicas de Levantamento de Requisitos 3 3 Requisitos e Modelagem de Processos de Neg cio 3 4 Escrevendo e Documentando Requisitos de Usu rio Cap tulo 4 An lise de Requisitos 4 1 Modelagem Conceitual 4 2 A Linguagem de Modelagem Unificada 4 3 O Paradigma Orientado a Objetos 4 4 Um M todo de An lise de Requisitos Funcionais 4 5 Especifica o de Requisitos N o Funcionais 4 6 O Documento de Especifica o de Requisitos Cap tulo 5 Modelagem de Casos de Uso 5 1 Atores e Casos de Uso 5 2 Diagramas de Casos de Uso 5 3 Descrevendo Casos de Uso 5 4 Relacionamentos entre Casos de Uso 5 5 Trabalhando com Casos de Uso Cap tulo 6 Modelagem Conceitual Estrutural 6 1 Identifica o de Classes 6 2 Identifica o de Atributos e Associa es 6 3 Especifica o de Hierarq
112. a o entre os processos de neg cio e o entendimento do dom nio de um sistema de informa o constatada por diversos autores Frye e Gulledge 2007 por exemplo afirmam que os sistemas de informa o habilitam os processos de neg cio e que se os processos de neg cio e os sistemas n o estiverem alinhados ent o os sistemas n o atender o s expectativas de seus usu rios Essa falta de alinhamento apontada como sendo uma das principais causas do fracasso de projetos de desenvolvimento de sistemas de informa o Assim o uso de t cnicas de levantamento de requisitos de sistemas de informa o baseadas em processos de neg cio torna se relevante pois esses sistemas mant m estreita rela o com o ambiente organizacional Um tratamento dissociado do aparato de levantamento de requisitos da vis o de neg cios pode levar subutiliza o de potencialidades tecnol gicas CARVALHO 2009 Um modelo de neg cio business model na verdade um conjunto de modelos que prov uma visualiza o dos processos de neg cio de como estes s o executados quais s o as suas metas como cada processo trabalha para atingir essas metas quais as unidades organizacionais e os pap is das pessoas envolvidos em cada atividade do processo quais as localidades onde a organiza o est distribu da e quais eventos deflagram seus processos e atividades KNIGHT 2004 A Figura 3 1 esquematiza os diferentes aspectos envolvidos em um modelo de ne
113. a um evento importante para o neg cio e precisa ser registrado Neste caso como ilustra a parte b da Figura 6 5 a compra deve ser tratada como uma classe e n o como uma associa o Engenharia de Requisitos Notas de Aula Cap tulo 6 Modelagem Conceitual Estrutural Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 128 ib data Data valor Currency notaFiscal int Figura 6 5 Exemplo Associa o x Classe de Evento Lembrado Deve se notar pelo exemplo acima que o evento representado por uma classe enquanto as associa es continuam representando relacionamentos est ticos entre as classes e n o opera es ou transforma es WAZLAWICK 2004 Assim deve se tomar cuidado com a representa o de eventos como associa es questionando sempre se aquela associa o relevante para o sistema em quest o Seja o exemplo da Figura 6 6 Nesse exemplo o caso de uso aponta que funcion rios s o respons veis por cadastrar livros em uma biblioteca Seria necess rio pois criar uma associa o Funcion rio cadastra Livro no modelo estrutural A resposta na maioria dos casos n o Apenas se explicitamente expresso pelo cliente em um requisito que necess rio saber exatamente qual funcion rio fez o cadastro de um dado livro o que muito improv vel de acontecer que tal rela o deveria ser considerada Mesmo se houver a necessidade de auditoria de uso do sistema requisito n
114. a 3 2 Uso de quest es subjetivas e objetivas em question rios adaptado de KENDALL KENDALL 2010 Quest es Subjetivas Quest es Objetivas Tempo gasto para responder Alto Baixo Natureza explorat ria Alta Baixa Amplitude e profundidade Alta Baixa Facilidade de prepara o F cil Dificil Facilidade de an lise Dificil F cil Assim como ocorrem com as entrevistas a linguagem utilizada na elabora o de question rios extremamente importante para a sua efetividade prudente escrever as quest es de modo a refletir a terminologia particular do neg cio Assim tanto as perguntas quanto as respostas ser o mais f ceis de interpretar Para verificar a linguagem utilizada aplique o question rio antecipadamente em um grupo piloto pedindo aten o adequabilidade dos termos empregados Kendall e Kendall 2010 recomendam que dentre outras as seguintes diretrizes sejam observadas na reda o de um question rio Engenharia de Requisitos Notas de Aula Cap tulo 3 Levantamento de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 45 Sempre que poss vel use o vocabul rio das pessoas que ir o responder Prime pela simplicidade Utilize perguntas simples e curtas Evite reda o tendenciosa Garanta que as quest es est o tecnicamente precisas antes de inclu las no question rio Em question rios escalas s o usadas para atribuir n meros ou ou
115. a Falbo UFES Universidade Federal do Esp rito Santo 27 Requisitos de Software trata de tipos e n veis de requisitos bem como da documenta o de requisitos O Cap tulo 7 Processos de Engenharia de Requisitos apresenta e discute um processo de engenharia de requisitos tamb m muito similar ao apresentado neste texto e suas atividades Em PFLEEGER 2004 o Cap tulo 4 Identificando Requisitos tem uma boa discuss o sobre requisitos Em rela o aos temas abordados nestas notas de aula merecem destaque as se es 4 1 4 2 4 3 4 6 4 7 4 8 e 4 9 as quais tratam dos seguintes assuntos requisitos processo de requisitos tipos de documentos de requisitos tipos de requisitos caracter sticas de requisitos se es 4 1 4 2 e 4 3 prototipagem de requisitos se o 4 6 documenta o de requisitos se o 4 7 participantes no processo de requisitos se o 4 8 e valida o de requisitos se o 4 9 Em PRESSMAN 2006 o Cap tulo 7 Engenharia de Requisitos aborda v rios dos temas discutidos neste cap tulo com destaque para as se es 7 2 Tarefas da Engenharia de Requisitos 7 3 In cio do Processo de Engenharia de Requisitos 7 4 Levantamento de Requisitos 7 7 Negocia o de Requisitos e 7 8 Valida o de Requisitos Por fim as se es 3 4 e 3 6 de ROCHA MALDONADO WEBER 2001 discutem respectivamente a Verifica o e Valida o V amp V de Software e Revis es de S
116. a altera o em sua base de informa o e ou a comunica o de alguma informa o ou comando para um ou mais destinat rios Um evento de requisi o de a o ou simplesmente uma requisi o uma solicita o para o sistema realizar uma a o O esquema comportamental de um sistema visa especificar essas a es OLIVE 2007 Uma parte importante do modelo comportamental de um sistema o modelo de casos de uso o qual fornece uma vis o das funcionalidades que o sistema deve prover O modelo conceitual estrutural define os tipos de entidades classes e de relacionamentos atributos e associa es do dom nio do problema que o sistema deve representar para poder prover as funcionalidades descritas no modelo de casos de uso Durante a realiza o de um caso de uso atores geram eventos de requisi o de a es para o sistema solicitando a execu o de alguma a o O sistema realiza a es e ele pr prio pode gerar outras requisi es de a o necess rio pois modelar essas requisi es de a es as correspondentes a es a serem realizadas pelo sistema e seus efeitos Este o prop sito da modelagem din mica Em uma abordagem orientada a objetos requisi es de a o correspondem a mensagens trocadas entre objetos As a es propriamente ditas e seus efeitos s o tratados pelas opera es das classes Assim a modelagem din mica est relacionada com as trocas de mensagens entre objetos e a modelagem das op
117. a consulta s o apenas ilustrativos e muitas vezes s o constantes definidas no pr prio c digo do prot tipo Mesmo quando isso feito deve se Engenharia de Requisitos Notas de Aula Cap tulo 3 Levantamento de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 50 procurar usar dados reais para real ar a validade do prot tipo como um modelo do sistema real Normalmente essa simula o boa o suficiente para os usu rios fazerem um julgamento se h funcionalidade faltando errada ou desnecess ria WIEGERS 2003 Prot tipo operacional funciona como se sup e que o sistema real deveria funcionar e implementa de alguma forma todas as camadas da arquitetura do sistema Wiegers 2003 denomina este tipo de prot tipo de prot tipo vertical uma vez que ele trata em alguma extens o de todas as camadas da arquitetura do sistema Um prot tipo vertical tipicamente usado para reduzir riscos durante o projeto podendo ser usado dentre outros para avaliar se uma arquitetura vi vel e s lida ou para testar requisitos cr ticos Prot tipos verticais s o constru dos usando ferramentas de produ o ou seja as mesmas usadas para construir o pr prio sistema WIEGERS 2003 Quanto ao uso futuro do prot tipo como base para o sistema real ou n o um prot tipo pode ser Prot tipo descart vel um prot tipo explorat rio e n o se pretende utiliz lo como uma parte real do sistema a
118. a d vida na hora da entrevista Anota es o entrevistador toma notas durante a entrevista Quando esta abordagem adotada deve se considerar que escrever um processo lento enquanto falar r pido Assim as anota es devem capturar a ess ncia do que foi dito Algumas das vantagens dessa abordagem s o i mant m o entrevistador alerta ii um esquema das anota es a serem feitas pode ser usado para fornecer um roteiro para a entrevista iii mostra interesse e prepara o do entrevistador Como desvantagens podem ser citadas 1 essa abordagem pode comprometer o andamento da conversa ii pode se dar excessiva aten o a fatos e pouca a sentimentos e opini es Uma vez planejada a entrevista deve ser realizada Na v spera da reuni o recomenda se que o analista entre em contato com o entrevistado para confirmar o hor rio e o local da entrevista No dia da entrevista o analista deve chegar um pouco antes do hor rio marcado Engenharia de Requisitos Notas de Aula Cap tulo 3 Levantamento de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 40 vestido apropriadamente Ao iniciar a entrevista interessante que o analista se apresente fale sucintamente sobre os objetivos da entrevista diga ao entrevistado o que ser feito com as informa es coletadas e assegure seu aspecto confidencial Durante a entrevista fundamental gerenciar o tempo Ao t rmino da entrevista perg
119. a de Requisitos pode ser descrita como um processo ou seja um conjunto organizado de atividades que deve ser seguido para derivar avaliar e manter os requisitos e artefatos relacionados Uma descri o de um processo de forma geral deve incluir al m das atividades a serem seguidas a estrutura ou sequ ncia dessas atividades quem respons vel por cada atividade suas entradas e sa das as ferramentas usadas para apoiar as atividades e os m todos t cnicas e diretrizes a serem seguidos na sua realiza o Processos de engenharia de requisitos podem variar muito de uma organiza o para outra ou at mesmo dentro de uma organiza o espec fica em fun o de caracter sticas dos projetos A defini o de um processo apropriado organiza o traz muitos benef cios pois uma boa descri o do mesmo fornecer orienta es e reduzir a probabilidade de esquecimento ou de uma execu o superficial No entanto n o faz sentido falar em processo ideal ou definir algum e imp lo a uma organiza o Ao inv s disto as organiza es devem iniciar com um processo gen rico e adapt lo para um processo mais detalhado que seja apropriado s suas reais necessidades SOMMERVILLE SAWYER 1997 A implanta o de processos em uma organiza o deve ser feita segundo as necessidades da mesma ou seja o processo deve ser definido de acordo com as Engenharia de Requisitos Notas de Aula Cap tulo 2 Engenharia de Requisitos de So
120. a de existir obviamente ele deixa de estar em qualquer um dos estados Isso pode ser dito no diagrama por meio de uma transi o para o estado final O estado final indica na verdade que o objeto deixou de existir Na UML um estado final representado como um c rculo preto preenchido com outro c rculo n o preenchido ao seu redor como mostra a Figura 7 2 As transi es para o estado final definem os estados em que poss vel excluir o objeto Classes cujos objetos n o podem ser exclu dos portanto n o possuem um estado final OLIV 2007 Assim como o estado inicial o estado final n o se comporta como um estado normal uma vez que o objeto tamb m n o permanece nesse estado j que o objeto n o existe mais Ao contr rio do estado inicial contudo uma m quina de estados pode ter v rios estados finais Al m disso deve se representar o evento que elimina o objeto na Figura 7 2 eventoDestrui o Os eventos mostrados nas transi es s o os mesmos eventos de requisi o de a o discutidos na Se o 7 1 Contudo importante indicar no diagrama de estados os eventos maiores eventos de dom nio e requisi es de a es e n o os eventos estruturais que efetivamente alteram o estado do objeto Assim neste texto sugere se indicar como eventos de transi es de uma m quina de estados as requisi es de realiza o de casos de uso do sistema ou de fluxos de eventos espec ficos quando um caso de uso tiver mais de um
121. a de requisitos Ger ncia de Requisitos problema nos requisitos verifica o e Valida o de Requisitos Levantamento An lise de Documenta o de Requisitos Requisitos T de Requisitos Documento de Requisitos Especifica o de Requisitos j I a Necessidades dos Usu rios Informa es de Dominio requisitos acordados Sistemas Existentes Regulamentos Leis etc Figura 2 1 Processo de Engenharia de Requisitos adaptado de KOTONYA SOMMERVILLE 1998 O processo come a pelo levantamento de requisitos que deve levar em conta necessidades dos usu rios e clientes informa es de dom nio sistemas existentes regulamentos leis etc Uma vez identificados requisitos poss vel iniciar a atividade de an lise quando os requisitos levantados s o usados como base para a modelagem do sistema Tanto no levantamento quanto na an lise de requisitos importante documentar requisitos e modelos Conforme discutido anteriormente para documentar requisitos dois documentos s o normalmente utilizados o Documento de Requisitos contendo uma lista dos requisitos de usu rio identificados e o Documento de Especifica o de Requisitos que registra os requisitos de sistema e os v rios diagramas resultantes do trabalho de an lise Os documentos produzidos s o ent o verificados e validados Adicionalmente um esfor o de garantia da qualidade deve ser realizado Enge
122. a evolu o dos diversos artefatos produzidos nos projetos de software processo de Ger ncia de Configura o atividades relacionadas ger ncia de ativos reutiliz veis de uma organiza o processo de Ger ncia de Reutiliza o etc e Atividades de Controle da Qualidade s o aquelas relacionadas com a avalia o da qualidade do produto em desenvolvimento e do processo de software utilizado Incluem atividades de verifica o valida o e garantia da qualidade As atividades de desenvolvimento formam a espinha dorsal do desenvolvimento e s o realizadas segundo uma ordem estabelecida no planejamento As atividades de ger ncia e de Engenharia de Requisitos Notas de Aula Cap tulo 1 Introdu o Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 2 controle da qualidade s o muitas vezes ditas atividades de apoio pois n o est o ligadas diretamente constru o do produto final ou seja o software a ser entregue para o cliente incluindo toda a documenta o necess ria Essas atividades normalmente s o realizadas ao longo de todo o ciclo de vida sempre que necess rio ou em pontos pr estabelecidos durante o planejamento ditos marcos ou pontos de controle A Figura 1 1 mostra a rela o entre esses tipos de atividades Atividades de Ger ncia A O Atividades de Desenvolvimento Produto de Software E a Atividades de Controle da Qualidade Figura 1 1 Atividades do Processo d
123. a passo como um caso de uso realizado Uma vez que casos de uso capturam uma por o discreta de funcionalidade interessante definir cen rios para contar a hist ria de um caso de uso As pessoas geralmente consideram mais Engenharia de Requisitos Notas de Aula Cap tulo 3 Levantamento de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 53 f cil relatar exemplos de situa es reais do que abstrair descri es e da vem a utilidade dos cen rios Um cen rio pode come ar com um esbo o da intera o e durante o levantamento de requisitos detalhes podem ser adicionados para criar uma descri o mais completa dessa intera o Neste sentido cen rios requerem uma abordagem incremental e interativa de desenvolvimento Al m disso cen rios tipicamente n o consideram a estrutura interna do sistema AURUM WOHLIN 2005 ROBERTSON ROBERTSON 2006 SOMMERVILLE 2007 e Re so de Requisitos sempre uma boa pr tica de engenharia de software reutilizar tanto conhecimento quanto poss vel durante o desenvolvimento de um novo sistema Isso n o diferente no caso de requisitos KOTONYA SOMMERVILLE 1998 O re so de requisitos poss vel em diversas situa es dentre elas i requisitos relacionados ao mesmo dom nio de aplica o ii requisitos relacionados mesma tarefa iii requisitos de sistemas considerados similares e iv requisitos que refletem pol ticas organizacionai
124. ada de decis o etc Decidir quem entrevistar importante incluir na lista de entrevistados as pessoas chave das diversas classes de interessados afetados pelo sistema O cliente pode ajudar nesta sele o Preparar o entrevistado Uma entrevista deve ser marcada com anteced ncia de modo que o entrevistado tenha tempo para pensar sobre a entrevista Preparar a entrevista Deve se decidir dentre outros sobre os tipos de quest es e a estrutura da entrevista e o modo como a mesma ser registrada Em rela o ao tipo quest es podem ser de tr s tipos principais KENDALL KENDALL 2010 Quest es subjetivas permitem respostas abertas Ex O que voc acha de Explique como voc Seus pontos positivos s o i proveem riqueza de detalhes 11 revelam novos questionamentos e iii colocam o entrevistado mais vontade permitindo maior espontaneidade Contudo h tamb m desvantagens dentre elas 1 podem resultar em muitos detalhes irrelevantes 11 podem levar perda do controle da entrevista iii podem ter respostas muito longas para se obter pouca informa o til e iv podem dar a impress o de que o entrevistador est perdido e sem objetivo Quest es objetivas limitam as respostas poss veis Ex Quantos Quem 2 Quanto tempo 2 Qual das seguintes informa es 2 Como vantagens quest es objetivas 1 permitem ganho de tempo uma vez
125. agens Estruturada e N o Estruturada adaptado de KENDALL KENDALL 2010 N o Estruturada Estruturada Avalia o Mais Dif cil Mais F cil Tempo Requerido Maior Menor Treinamento Requerido Maior Menor Espontaneidade Maior Menor Oportunidades para insight Maior Menor Flexibilidade Maior Menor Controle Menor Maior Precis o Menor Maior Confiabilidade Menor Maior Amplitude e Profundidade Maior Menor Por fim o planejamento deve definir de que forma a entrevista ser registrada importante registrar os principais aspectos de uma entrevista durante a sua realiza o pois caso contr rio as informa es obtidas podem ser perdidas logo em seguida H duas formas principais cujas vantagens e desvantagens s o apresentadas a seguir KENDALL KENDALL 2010 ALEXANDER BEUS DUKIC 2009 Grava o Filmagem a entrevista gravada ou filmada A grava o filmagem permite o registro completo da entrevista e a reprodu o para outros membros da equipe posteriormente Contudo muitos entrevistados n o gostam de serem gravados e por conseguinte ficam pouco vontade Al m disso o fato de saber que a entrevista est sendo gravada pode deixar o entrevistador distra do comprometendo seu trabalho Por fim transcrever registros gravados uma atividade que consome tempo e confiar em grava es para posteriormente tirar d vidas pode ser perigoso deixando de se esclarecer um
126. agmento de Modelo de Dados com Restri o de Integridade Outro tipo de restri o importante s o as regras que imp em restri es sobre funcionalidades de inser o atualiza o ou exclus o de dados devido a relacionamentos existentes entre as entidades Voltando ao exemplo da Figura 3 7 a exclus o de disciplinas n o deve ser livre uma vez que turmas s o existencialmente dependentes de disciplinas Assim a seguinte regra de integridade referencial de dados deve ser considerada Ao excluir uma disciplina devem se excluir todas as turmas a ela relacionadas Essas regras s o denominadas neste texto como restri es de processamento e uma vez que dizem respeito a funcionalidades devem ser documentadas junto com a descri o do caso de uso que detalha a respectiva funcionalidade 3 4 3 Escrevendo Requisitos N o Funcionais Clientes e usu rios naturalmente enfocam a especifica o de requisitos funcionais e regras de neg cio Entretanto para um sistema ser bem sucedido necess rio mais do que entregar a funcionalidade correta Usu rios tamb m t m expectativas sobre qu o bem o sistema vai funcionar Caracter sticas que entram nessas expectativas incluem qu o f cil usar o sistema qu o rapidamente ele roda com que frequ ncia ele falha e como ele trata condi es inesperadas Essas caracter sticas coletivamente conhecidas como atributos de qualidade do produto de software s o parte dos requisitos n o funcionais
127. al por sua vez prov uma vis o ampla do comportamento do sistema No que tange modelagem do comportamento de um sistema em um n vel superior os diagramas de casos de uso proveem uma vis o externa da funcionalidade do sistema e dos atores nela envolvidos O comportamento dos casos de uso elaborado por meio de descri es de casos de uso Essas descri es podem ser refinadas por meio de diagramas de atividade ou de sequ ncia Os diagramas de sequ ncia tipicamente mostram vis es parciais Eles geralmente s o desenvolvidos apenas para fluxos de eventos principais ou s o desenvolvidos um diagrama de sequ ncia para o fluxo principal de eventos e diagramas adicionais para os fluxos de exce o e variantes Diagramas de atividade permitem consolidar todo esse comportamento em um nico diagrama documentando ramifica es bifurca es e uni es do fluxo de controle Diagramas de sequ ncia s o bons para mostrar colabora es entre objetos em um caso de uso J os diagramas de atividade s o teis para focalizar as atividades de um processo complexo Contudo esses dois tipos de diagramas n o s o apropriados para observar o comportamento de um objeto isolado ao longo de v rios casos de uso Para tal s o utilizados diagramas de gr fico de estados Neste contexto uma quest o importante precisa ser tratada como fazer a engenharia dos requisitos de um sistema com qualidade mas ao mesmo tempo de maneira gil sem despender te
128. al Metrics 2003b JACOBSON I Object Oriented Software Engineering Addison Wesley 1992 LARMAN C Utilizando UML e Padr es 3 edi o Bookman 2007 OLIV A Conceptual Modeling of Information Systems Springer 2007 PASTOR O MOLINA J C Model Driven Architecture in Practice A Software Production Environment Based on Conceptual Modeling Springer 2007 ROBERTSON S ROBERTSON J Mastering the Requirements Process 2 Edition Addison Wesley 2006 RUMBAUGH J et al Modelagem e Projetos Baseados em Objetos 1 Edi o Editora Campus 1994 WAZLAWICK R S An lise e Projeto de Sistemas de Informa o Orientados a Objetos Elsevier 2004 WIEGERS K E Software Requirements Practical techniques for gathering and managing requirements throughout the product development cycle 2 Edition Microsoft Press Redmond Washington 2003 YOURDON E Object Oriented Systems Design an Integrated Approach Yourdon Press Computing Series Prentice Hall 1994 Engenharia de Requisitos Notas de Aula Cap tulo 5 Modelagem de Casos de Uso Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 87 Cap tulo 5 Modelagem de Casos de Uso A an lise de requisitos um processo que envolve a constru o de diversos modelos Diagramas de classes e diagramas de intera o incluem detalhes relacionados estrutura interna dos objetos suas associa es como eles interagem dinamicame
129. alidar Cart o lt include 7 Efetuar Pagamento Alimentar Caixa Figura 5 7 Diagrama de Casos de Uso Caixa Autom tico com Inclus o Sistema Banc rio Mantenedor O caso de uso Validar Cart o extrai o comportamento descrito na Figura 5 8 Ao isolar este comportamento no caso de uso de Validar Cliente o caso de uso Efetuar Saque passaria a apresentar a descri o mostrada na Figura 5 9 Deve se observar que n o necessariamente o comportamento do caso de uso inclu do precisa ser executado todas as vezes que o caso de uso base realizado Assim poss vel que a inclus o esteja associada a alguma condi o O caso de uso inclu do inserido em um local espec fico dentro da sequ ncia do caso de uso base da mesma forma que uma subrotina chamada de um local espec fico dentro de outra subrotina BLAHA RUMBAUGH 2006 Engenharia de Requisitos Notas de Aula Cap tulo 5 Modelagem de Casos de Uso Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 106 Nome Validar Cart o Fluxo de Eventos Normal 1 O cliente insere o cart o no caixa autom tico O caixa autom tico analisa o cart o e verifica se ele aceit vel O caixa autom tico solicita que o cliente informe a senha O cliente informa a senha O caixa autom tico envia os dados do cart o e da senha para o sistema banc rio para valida o 6 O caixa autom tico solicita que o cliente informe o tipo de transa
130. altera o deve ser determinado e valores de custo esfor o tempo e viabilidade devem ser repassados ao solicitante da mudan a Assim uma parte cr tica do controle de mudan as a avalia o do impacto de uma mudan a no restante do software Para que seja poss vel efetuar essa avalia o cada requisito deve estar identificado unicamente e deve ser poss vel por exemplo saber quais s o os requisitos dependentes desse requisito e em quais artefatos do processo de software esse requisito tratado Portanto necess rio estabelecer uma rede de liga es de modo que um requisito e os elementos ligados a ele possam ser rastreados Surge ent o o conceito de rastreabilidade A rastreabilidade pode ser definida como a habilidade de se acompanhar a vida de um requisito em ambas as dire es do processo de software e durante todo o ciclo de vida Ela fornece uma base para o desenvolvimento de uma trilha de auditoria para todo o projeto possibilitando encontrar outros requisitos e artefatos que podem ser afetados pelas mudan as solicitadas PALMER 1997 Para tal necess rio haver liga es entre requisitos e entre requisitos e outros elementos do processo de software Assim a identifica o da composi o de requisitos das depend ncias entre requisitos de requisitos conflitantes da origem dos requisitos e de seus interessados al m da identifica o de em quais artefatos produzidos durante o desenvolvimento de software um re
131. amam de regras de neg cio Por exemplo em um sistema de matr cula de uma universidade uma importante regra de neg cio diz que um aluno s pode se matricular em uma turma de uma disciplina se ele tiver cumprido seus pr Engenharia de Requisitos Notas de Aula Cap tulo 2 Engenharia de Requisitos de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 7 requisitos Essas regras de neg cio geralmente incluem terminologia espec fica do dom nio e fazem refer ncia a conceitos do dom nio SOMMERVILLE 2007 Assim s o mais facilmente capturadas na fase de modelagem conceitual Os requisitos devem ser redigidos de modo a serem pass veis de entendimento pelos diversos interessados stakeholders Clientes usu rios finais e desenvolvedores s o todos interessados em requisitos mas t m expectativas diferentes Enquanto desenvolvedores e usu rios finais t m interesse em detalhes t cnicos clientes requerem descri es mais abstratas Assim til apresentar requisitos em diferentes n veis de descri o Sommerville 2007 sugere dois n veis de descri o de requisitos e Requisitos de Usu rio s o declara es em linguagem natural acompanhadas de diagramas intuitivos de quais servi os s o esperados do sistema e das restri es sob as quais ele deve operar Devem estar em um n vel de abstra o mais alto de modo que sejam compreens veis pelos usu rios do sistema que n o possuem conheci
132. andes grupos m todos interativos e m todos n o obstrutivos Os m todos interativos envolvem a intera o com membros da organiza o como o caso de entrevistas e workshops de requisitos Os m todos n o obstrutivos procuram n o interferir no trabalho dos membros da organiza o Este o caso de m todos como observa o e investiga o de documentos Alexander e Beus Dukic 2009 por sua vez organizam as t cnicas de levantamento de requisitos pelo contexto no qual pode se dar a descoberta de requisitos Esses contextos podem ser a descoberta de requisitos a partir de indiv duos entrevistas por exemplo a partir de grupos p ex workshops de requisitos ou a partir de coisas p ex investiga o de documentos Os principais m todos de levantamento de requisitos envolvem um processo geral que cont m as seguintes atividades e Planejamento visa definir o objetivo da atividade de levantamento de requisitos a ser conduzida as pessoas no caso de m todos interativos ou as coisas no caso de m todos n o obstrutivos envolvidas quando a atividade vai ser realizada e sua dura o onde e como ela vai ser realizada incluindo material de apoio Assim o planejamento envolve quatro perguntas b sicas Por que Quem ou O qu Quando Onde e Como e Condu o a realiza o da atividade de levantamento de requisitos propriamente dita e Registro consiste no registro das informa es obtidas na atividade rea
133. anto funcionais quanto n o funcionais Al m disso h classes de usu rios que s o mais importantes que outras Essas classes devem ter tratamento preferencial na defini o de prioridades e resolu o de conflitos WIEGERS 2003 Ainda em rela o sele o de usu rios deve se evitar obter requisitos de intermedi rios entre a fonte de requisitos efetivamente e os analistas Essa pr tica abre espa o para problemas de comunica o e portanto sempre que poss vel deve se ir diretamente fonte Contudo alguns desses intermedi rios podem adicionar informa o importante Neste caso ou a os tamb m Entretanto tome cuidado com gerentes de usu rio e tamb m com desenvolvedores que pensam que sabem as necessidades dos usu rios sem sequer consult los WIEGERS 2003 No que se refere aos respons veis por tomar decis es relativas a requisitos no in cio do projeto deve se definir quem vai resolver requisitos conflitantes advindos de diferentes classes de usu rio reconciliar inconsist ncias definir prioridades e arbitrar quest es de escopo que venham a surgir Uma boa estrat gia a tomada de decis o consultiva e participativa na qual se obt m ideias e opini es de diversos interessados antes de se tomar uma decis o WIEGERS 2003 interessante notar que ao longo do processo de levantamento de requisitos o engenheiro de requisitos ou analista de sistema como mais conhecido popularmente desempenha
134. ase de informa o e ou a comunica o de alguma informa o ou comando para um ou mais destinat rios Um evento de requisi o de a o ou simplesmente uma requisi o uma solicita o para que o sistema realize uma a o Na an lise de requisitos assume se que a tecnologia perfeita e por conseguinte que o sistema executa as a es requisitadas instantaneamente OLIV 2007 Dependendo de como s o iniciadas requisi es podem ser expl citas temporais ou geradas Uma requisi o explicita iniciada explicitamente por um ator requisi o externa ou por uma outra a o requisi o induzida como parte de seu efeito Uma requisi o temporal iniciada pela passagem do tempo ocorrendo independentemente do sistema Por Engenharia de Requisitos Notas de Aula Cap tulo 7 Modelagem Din mica Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 140 fim uma requisi o gerada iniciada quando uma condi o de gera o da requisi o satisfeita O sistema detecta que a condi o foi satisfeita e gera a correspondente requisi o Por exemplo em um sistema de controle de estoque uma requisi o de compra pode ser gerada quando a quantidade m nima de um produto for atingida OLIV 2007 A maioria das requisi es externa Dois importantes tipos de requisi es externas s o notifica es de eventos de dom nio e consultas Uma consulta uma requisi o externa que pro
135. at logos Um cat logo de padr es uma cole o de padr es com uma estrutura e uma organiza o Os padr es s o subdivididos em categorias e h rela es entre eles A classifica o em um cat logo facilita o aprendizado e direciona os esfor os para encontrar novos padr es torna os teis para os leitores que podem lembrar dos padr es identific los em diferentes situa es e reutiliz los no desenvolvimento de algum sistema Para tal a cada padr o de software dado um nome que serve como um guia para facilitar a discuss o do padr o e a informa o que ele representa Um dos cat logos de padr es de an lise mais conhecidos o descrito por Fowler em seu livro Analysis Patterns Reusable Objects Models Padr es de An lise Modelos de Objetos Reutiliz veis FOWLER 1997 onde h mais de 40 padr es de an lise contendo modelos j aplicados em projetos nos quais o autor trabalhou Os padr es neste cat logo s o organizados em dez categorias principais a saber Responsabilidades Observa es e Medi es Observa es para Finan as Coorporativas Refer ncia a Objetos Invent rio e Contabilidade Uso de Modelos de Contabilidade Planejamento Negocia o Contratos Derivados e Pacotes de Negocia o Os padr es de an lise relativos a responsabilidades por exemplo buscam capturar situa es em que uma pessoa ou organiza o respons vel por outra uma no o abstrata que pode empregada em v rias
136. atividades de modelagem propriamente ditas est o destacadas em amarelo As demais atividades correspondem a atividades de documenta o e verifica o e valida o do Documento de Especifica o de Requisitos 5 a z nome da opera o par metros e retorno Engenharia de Requisitos Notas de Aula Cap tulo 4 An lise de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 82 Documento de Requisitos Requisitos Funcionais de Usu rio Modelagem de Eae Modelo de Casos de Uso Diagrama de Casos de Uso e Descri es de Casos de Uso Documento de Especifica o de Requisitos DER Modelagem Estrutural z Verifica o e Elabora o do A Modelo de Classes Documento de Valida o do Diagramas de Classes Documento de e Dicion rio de Dados a Especifica o de Requisitos Modelagem Comportamental Din mica Modelo Din mico Diagramas de Estados Diagramas de Atividades e Diagramas de Intera o DER incompleto ou n o aprovado DER completo e aprovado Figura 4 1 O M todo de An lise de Requisitos Funcionais Proposto O primeiro modelo do sistema a ser constru do segundo a abordagem proposta o modelo de casos de uso Sua escolha como primeiro modelo a ser elaborado deve se ao fato do modelo de casos de uso ser pass vel de compreens o tanto por desenvolvedores analistas projetistas programadores e testadores como pela comu
137. ato assinado dentre outros Esse processo pode levar v rios dias e n o realizado em uma sess o nica Assim o caso de uso de concess o de empr stimo deveria ser subdividido em casos de uso menores tais como casos de uso para efetuar pedido de empr stimo analisar pedido de empr stimo e formalizar concess o de empr stimo Por outro lado casos de uso muito pequenos que n o caracterizam uma transa o completa devem ser considerados passos de um caso de uso maior Seja o exemplo de uma biblioteca a qual cobra multa na devolu o de livros em atraso Um caso de uso espec fico para apenas calcular o valor da multa n o relevante pois n o caracteriza uma transa o completa capaz de atingir um objetivo do usu rio O objetivo do usu rio efetuar a devolu o e neste contexto uma regra de neg cio a que estabelece a multa tem de ser levada em conta Assim calcular a multa apenas um passo do caso de uso que efetua a devolu o o qual captura uma a o do sistema para garantir a regra de neg cio e portanto satisfazer um interesse da biblioteca como organiza o Um caso de uso re ne todo o comportamento relevante de uma parte da funcionalidade do sistema Isso inclui o comportamento principal normal as varia es de comportamento normais as condi es de exce o e o cancelamento de uma requisi o O conjunto de casos de uso captura a funcionalidade completa do sistema BLAHA RUMBAUGH 2006 Casos
138. b m em um de seus subestados Assim um estado composto pode possuir um estado inicial para indicar o subestado padr o do estado composto como representado na Figura 7 7 Entretanto deve se considerar que as transi es podem come ar e terminar em qualquer n vel Ou seja uma transi o pode ir ou partir diretamente de um subestado OLIV 2007 Assim uma outra op o para o diagrama da Figura 7 7 seria fazer a transi o nomeada pelo evento Retirar Carro chegar diretamente ao subestado Em Uso Normal ao inv s de chegar ao estado composto Em Uso Em Atraso Estender Loca o Reportar Defeito em Carro O estado de um objeto deve ser mapeado no modelo estrutural De maneira geral o estado pode ser modelado por meio de um atributo Esse atributo deve ser monovalorado e obrigat rio O conjunto de valores poss veis do atributo o conjunto dos estados poss veis conforme descrito pela m quina de estados OLIV 2007 Assim bastante natural que o tipo de dados desse atributo seja definido como um tipo de dados enumerado Um nome adequado para esse atributo estado Contudo outros nomes mais significativos para o dom nio podem ser atribu dos Em especial quando uma classe possuir mais do que uma m quina de estado e por conseguinte mais do que um atributo de estado for necess rio o nome do atributo de estado deve indicar a perspectiva capturada pela correspondente m quina de estados Engenharia de
139. b m interessados neste caso de uso Assim mesmo que essas pessoas n o interajam diretamente com o sistema para a realiza o do caso de uso elas devem ser listadas como interessados Deve se lembrar que o sistema deve satisfazer os interesses de todos os envolvidos direta ou indiretamente Assim na se o Interessados e Interesses deve se listar os diversos interessados e uma descri o sucinta de seus interesses em rela o execu o do caso de uso Ao analisar esses interesses poss vel dentre outros capturar regras de neg cio e informa es e descobrir a es que o sistema tem de realizar para atender a essas expectativas tais como valida es atualiza es e registros WAZLAWICK 2004 COCKBURN 2005 Pr condi es estabelecem o que precisa ser verdadeiro antes de se iniciar um caso de uso P s condi es por sua vez estabelecem o que ser verdadeiro ap s a execu o do caso de uso Pr condi es precisam ser verdadeiras para que o caso de uso possa ser iniciado N o se deve confundi las com exce es Pr condi es n o s o testadas durante a execu o do caso de uso como ocorre com as condi es que geram exce es Ao contr rio elas s o testadas antes de iniciar o caso de uso Se a pr condi o falsa ent o n o poss vel executar o caso de uso Para documentar as pr condi es recomenda se listar as condi es que t m de ser satisfeitas na se o Pr condi es Pr
140. bem como constitui um bom crit rio para organizar a documenta o Uma vez identificadas as potenciais classes deve se proceder uma avalia o para decidir o que efetivamente considerar ou rejeitar Conforme discutido anteriormente a relev ncia para o sistema deve ser o crit rio principal Al m desse crit rio os seguintes tamb m devem ser considerados nessa avalia o e Estrutura complexa o sistema precisa tratar informa es sobre os objetos da classe Tipicamente uma classe deve ter pelo menos dois atributos Se uma classe apresentar apenas um atributo avalie se n o melhor trat la como um atributo de uma classe existente e Atributos e associa es comuns os atributos e as associa es da classe devem ser aplic veis a todas as suas inst ncias isto a todos os objetos da classe e Classes n o redundantes duas classes s o redundantes quando elas t m sempre a mesma popula o Seja o exemplo de um modelo conceitual que tenha as classes Pessoa e Funcion rio Se o sistema est interessado apenas nas pessoas empregadas na organiza o ou seja funcion rios ent o a popula o dessas duas classes ser sempre a mesma A introdu o de classes redundantes afeta a simplicidade do modelo e portanto melhor n o incluir tais classes em um modelo conceitual e Exist ncia de inst ncias toda classe deve possuir uma popula o n o vazia Uma potencial classe que possui uma nica inst ncia tamb m
141. bimento do carro vindo de outra localidade fluxo de eventos Receber Carro Vindo de Outra Localidade do caso de uso Transferir Carro esses eventos poderiam ser explicitamente declarados Contudo se o registro pode ocorrer em v rios eventos diferentes melhor deixar o evento impl cito O segundo caso dataCorrente dataAquisicao gt 1 ano trata se de um evento temporal disparado pela passagem do tempo Todos os estados mostrados at ent o s o estados simples i e estados que n o possuem subestados Entretanto h tamb m estados compostos os quais podem ser decompostos em um conjunto de subestados disjuntos e mutuamente exclusivos e um conjunto de transi es OLIV 2007 Um subestado um estado aninhado em outro estado O uso de estados compostos e subestados bastante til para simplificar a modelagem de comportamentos complexos Seja o exemplo da Figura 7 4 que trata da disponibilidade de um carro Suponha que seja necess rio distinguir tr s subestados do estado Em Uso a saber Em Uso Normal quando o carro n o est quebrado nem em atraso Quebrado quando o cliente reportar um defeito no carro e Em Atraso quando o carro n o foi devolvido na data de devolu o prevista e n o est quebrado A Figura 7 6 mostra a m quina de estados da classe Carro considerando agora que quando um carro est em uso ele pode estar nesses tr s subestados Nesse diagrama n o est sendo mostrado que os estados Em Uso Normal
142. bjetivas e de aprofundamento come a com quest es gen ricas e subjetivas termina com quest es espec ficas e Estrutura de Diamante uma combina o das duas anteriores come ando com quest es espec ficas passando a quest es gerais e fechando a entrevista novamente com quest es espec ficas uma boa forma de se estruturar uma entrevista j que mant m o interesse do entrevistado em uma variedade de quest es Contudo tende a ser mais longa inicia com quest es espec ficas examina quest es gerais fecha com quest es espec ficas Estruturar entrevistas um meio de planejar a priori a ordem em que as quest es ser o feitas Obviamente h a op o de n o se definir essa ordem antecipadamente em uma abordagem de entrevista n o estruturada na qual n o h uma defini o da sequ ncia das quest es De acordo com o andar da entrevista caminhos poss veis s o avaliados e a sequ ncia estabelecida Normalmente requer mais tempo Entretanto vale ressaltar que ainda que a sequ ncia das quest es n o seja definida a priori as quest es devem ser definidas antecipadamente ou seja o planejamento necess rio A Tabela 3 2 apresenta um quadro comparativo entre as abordagens estruturada e n o estruturada Engenharia de Requisitos Notas de Aula Cap tulo 3 Levantamento de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 39 Tabela 3 2 Compara o entre as Abord
143. bter um resultado desejado PASTOR MOLINA 2007 H diversos m todos de an lise orientada a objetos propostos na literatura dentre eles os apresentados em LARMAN 2007 WAZLAWICK 2004 BLAHA RUMBAUGH 2006 e PASTOR MOLINA 2007 Vale ressaltar que n o h um m todo reconhecido como um m todo padr o para o desenvolvimento de software orientado a objetos Diferentes projetos podem requerer diferentes processos e portanto n o h como definir um m todo adequado a quaisquer situa es Neste cap tulo apresentado um m todo que incorpora ideias de v rios m todos o qual tem se mostrado eficaz na pr tica sobretudo no desenvolvimento de sistemas de informa o Este cap tulo trata da an lise de requisitos discutindo a an lise de requisitos funcionais modelagem conceitual e n o funcionais A Se o 4 1 discute a modelagem conceitual com foco em sistemas de informa o e os tipos de modelos comumente utilizados no desenvolvimento de software orientado a objetos A Se o 4 2 apresenta a Linguagem de Modelagem Unificada Unified Modeling Language UML amplamente usada na modelagem conceitual A Se o 4 3 discute os principais conceitos da orienta o a objetos paradigma de desenvolvimento adotado neste texto A Se o 4 4 apresenta o m todo de an lise de requisitos funcionais sugerido indicando suas atividades e modelos a serem produzidos A Se o 4 5 trata da especifica o de requisitos n o funcionais
144. c digo gerado de modo a guiar as altera es e Testes requisitos s o a base para diversos tipos de testes dentre eles testes de sistema e de aceita o 2 3 Engenharia de Requisitos e Normas e Modelos de Qualidade Visando qualidade no processo de software modelos e normas de qualidade de processo de software t m sido propostos dentre eles o CMMI Capability Maturity Model Integration SEI 2010 e o MPS BR SOFTEX 2009 O CMMI um modelo de qualidade de processo desenvolvido pelo Instituto de Engenharia de Software Software Engineering Institute SEI da Universidade de Carnegie Mellon O CMMI para Desenvolvimento CMMI Dev SEI 2010 enfoca o processo de software e tem como objetivo fornecer diretrizes para a defini o e melhoria de processos de software de uma organiza o O CMMI em sua representa o em est gio possui cinco n veis de maturidade 1 Inicial 2 Gerenciado 3 Definido 4 Gerenciado Quantitativamente e 5 Em Otimiza o Engenharia de Requisitos Notas de Aula Cap tulo 2 Engenharia de Requisitos de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 24 O CMMI Dey trata de requisitos tanto no n vel 2 atrav s da rea de processo Gest o de Requisitos quanto no n vel 3 por meio da rea de processo Desenvolvimento de Requisitos Na Gest o de Requisitos o objetivo gerenciar os requisitos dos produtos e componentes de produto do projeto e garanti
145. cam as a es que o sistema pode realizar e as mudan as v lidas no estado do dom nio OLIV 2007 Tipos de modelos comportamentais bastante utilizados no desenvolvimento orientado a objetos incluem Modelos de Casos de Uso e Modelos Din micos tais como Diagramas de Transi o de Estados e Diagramas de Intera o Engenharia de Requisitos Notas de Aula Cap tulo 4 An lise de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 73 4 2 A Linguagem de Modelagem Unificada A Linguagem de Modelagem Unificada Unified Modeling Language UML uma linguagem gr fica padr o para especificar visualizar documentar e construir artefatos de sistemas de software BOOCH RUMBAUGH JACOBSON 2006 A UML foi criada na d cada de 1990 a partir de uma tentativa de se unificar dois dos principais m todos orientados a objetos utilizados at ent o a T cnica de Modelagem de Objetos Object Modeling Technique OMT RUMBAUGH et al 1994 e o M todo de Booch BOOCH 1994 Inicialmente buscava se criar um m todo unificado A este esfor o juntou se tamb m Ivar Jacobson fundindo tamb m seu m todo OOSE JACOBSON 1992 Contudo percebeu se que n o era poss vel estabelecer um nico m todo adequado para todo e qualquer desenvolvimento De fato um m todo composto por uma linguagem estabelecendo a nota o a ser usada na elabora o dos artefatos a serem produzidos e de um processo descreven
146. cer prioridades e redirecionar planos e Din micas de Grupo h v rias t cnicas de levantamento de requisitos que procuram explorar din micas de grupo para a descoberta e o desenvolvimento de requisitos tais como Brainstorming e JAD Joint Application Development Na primeira representantes de diferentes grupos de interessados engajam se em uma discuss o informal para rapidamente gerarem o maior n mero poss vel de ideias Na segunda interessados e analistas se re nem para discutir problemas a serem solucionados e solu es poss veis Com as diversas partes envolvidas representadas decis es podem ser tomadas e quest es podem ser resolvidas mais rapidamente A principal diferen a entre JAD e Brainstorming que em JAD tipicamente os objetivos do sistema j foram estabelecidos antes dos interessados participarem Al m disso sess es JAD s o normalmente bem estruturadas com passos a es e pap is de participantes definidos 2 2 2 An lise de Requisitos Uma vez identificados requisitos poss vel iniciar a atividade de an lise quando os requisitos levantados s o usados como base para a modelagem do sistema Conforme discutido anteriormente requisitos de usu rio s o escritos tipicamente em linguagem natural pois eles devem ser compreendidos por pessoas que n o sejam especialistas t cnicos Contudo til expressar requisitos mais detalhados do sistema de maneira mais t cnica Para tal diversos tipos de mo
147. cess rio e como ir contribuir para os objetivos gerais de neg cio da organiza o iv definir termos especializados em um gloss rio v organizar o layout do documento para facilitar a leitura vi auxiliar os leitores a encontrar a informa o incluindo recursos tais como listas de conte do e ndices e organizando os requisitos em cap tulos se es e subse es identificadas vii identificar as fontes dos requisitos de modo a manter dados da origem do requisito de modo que quando alguma mudan a for solicitada seja poss vel saber com quem essa mudan a deve ser discutida e avaliada viii criar um identificador nico para cada requisito de modo a facilitar a rastreabilidade e o controle de mudan as ix documentar tamb m as regras do neg cio e definir liga es entre os requisitos e as regras correspondentes e x tornar o documento f cil de alterar 2 2 4 Verifica o e Valida o de Requisitos As atividades de Verifica o amp Valida o V amp V devem ser iniciadas o quanto antes no processo de desenvolvimento de software pois quanto mais tarde os defeitos s o encontrados maiores os custos associados sua corre o ROCHA MALDONADO WEBER 2001 Uma vez que os requisitos s o a base para o desenvolvimento fundamental que eles sejam cuidadosamente avaliados Assim os documentos produzidos durante a atividade de documenta o de requisitos devem ser submetidos verifica o e valida o
148. cia es Uma associa o entre um ator e um caso de uso significa que est mulos podem ser enviados entre atores e casos de uso A associa o entre um ator e um caso de uso indica que o ator e o caso de uso se comunicam entre si cada um com a possibilidade de enviar e receber mensagens BOOCH RUMBAUGH JACOBSON 2006 Atores podem ser organizados em hierarquias de generaliza o especializa o de modo a capturar que um ator filho herda o significado e as associa es com casos de uso de seu pai especializando esse significado e potencialmente adicionando outras associa es como outros casos de uso A Figura 5 2 mostra um diagrama de casos de uso para um sistema de caixa autom tico Nesse diagrama o assunto o sistema como um todo Os atores s o os clientes do banco o sistema banc rio e os respons veis pela manuten o do numer rio no caixa eletr nico Cliente e mantenedor s o atores prim rios uma vez que t m objetivos a serem atingidos pelo uso do sistema O sistema banc rio um ator secund rio pois o sistema do caixa autom tico precisa interagir com o sistema banc rio para realizar os casos de uso Efetuar Saque Emitir Extrato e Efetuar Pagamento Engenharia de Requisitos Notas de Aula Cap tulo 5 Modelagem de Casos de Uso Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 93 Sistema Caixa Autom tico Efetuar Saque Cliente Sistema Banc rio Efetuar Pagamento Alimenta
149. cias s o cen rios Um cen rio uma execu o de um caso de uso com entidades f sicas particulares desempenhando os pap is dos atores e em um particular estado do dom nio de informa o Um cen rio portanto exercita um certo caminho dentro do conjunto de a es de um caso de uso OLIV 2007 Alguns cen rios mostram o objetivo do caso de uso sendo alcan ado outros terminam com o caso de uso sendo abandonado COCKBURN 2005 Mesmo quando o objetivo de um caso de uso alcan ado ele pode ser atingido seguindo diferentes caminhos Assim um caso de uso deve comportar todas essas situa es Para tal um caso de uso normalmente descrito por um conjunto de fluxos de eventos capturando o fluxo de eventos principal i e o fluxo de eventos t pico que conduz ao objetivo do caso de uso e fluxos de eventos alternativos descrevendo exce es ou variantes do fluxo principal 5 2 Diagramas de Casos de Uso Basicamente um diagrama de casos de uso mostra um conjunto de casos de uso e atores e seus relacionamentos sendo utilizado para ilustrar uma vis o est tica das maneiras poss veis de se usar o sistema BOOCH RUMBAUGH JACOBSON 2006 Os diagramas de casos de uso da UML podem conter os seguintes elementos de modelo ilustrados na Figura 5 1 BOOCH RUMBAUGH JACOBSON 2006 e Assunto o assunto delimita a fronteira de um diagrama de casos de uso sendo normalmente o sistema ou um subsistema Os casos de uso de um assunto
150. cio Geralmente descrevem associa es ou relacionamentos entre importantes termos do neg cio Ex Todo pedido tem uma taxa de remessa e Restri es como o pr prio nome indica restringem as a es que o sistema ou seus usu rios podem realizar Algumas palavras ou frases sugerem a descri o de uma restri o tais como deve n o deve n o pode e somente Ex Um aluno s pode tomar emprestado concomitantemente at tr s livros e Ativadores de A es s o regras que disparam alguma a o sob condi es espec ficas Uma declara o na forma Se lt alguma condi o verdadeira ou algum evento ocorre gt ent o lt algo acontece gt indicada para descrever ativadores de a es Ex Se a data para retirada do livro ultrapassada e o livro n o retirado ent o a reserva cancelada Quando as condi es que levam s a es s o uma complexa combina o de m ltiplas condi es individuais ent o o uso de tabelas de decis o ou rvores de decis o indicado As figuras 3 4 e 3 5 ilustram uma mesma regra de ativa o de a es descrita por meio de uma rvore de decis o e de uma tabela de decis o respectivamente Sem atraso de Tratamento pagamento tor registrado Priorit rio o Taod Priorit rio neg cios gt trabalho gt R 1 milh o Com atraso j anos de pagamento registrado Tempo de trabalho lt Normal Volume de 20 anos neg cios lt Normal R 1 m
151. cio do caso de uso o que n o muito comum nem pr tico e Voltar ao in cio do passo em que ocorreu a exce o e execut lo novamente Esta a situa o mais comum e Voltar para algum um passo posterior Esta situa o ocorre quando as a es corretivas realizam o trabalho que o passo ou a sequ ncia de passos posterior Engenharia de Requisitos Notas de Aula Cap tulo 5 Modelagem de Casos de Uso Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 98 deveria executar Neste caso importante verificar se novas exce es n o poderiam ocorrer e Abortar o caso de uso Neste caso n o se retorna ao fluxo principal e o caso de uso n o atinge seus objetivos Nome Efetuar Saque Fluxo de Eventos Normal 1 O cliente insere seu cart o no caixa autom tico 2 O caixa autom tico analisa o cart o e verifica se ele aceit vel 3 O caixa autom tico solicita que o cliente informe a senha 4 O cliente informa a senha 5 O caixa autom tico envia os dados do cart o e da senha para o sistema banc rio para valida o 6 O caixa autom tico solicita que o cliente informe o tipo de transa o a ser efetuada 7 O cliente seleciona a op o saque 8 O caixa autom tico solicita que seja informada a quantia 9 O cliente informa a quantia a ser sacada 10 O caixa autom tico envia uma requisi o para o sistema banc rio para que seja efetuado um saque na quantia especificada
152. cionando a eles crit rios de aceita o importante apontar que h uma forte depend ncia entre os m todos e t cnicas usados na modelagem conceitual e o paradigma de desenvolvimento adotado Isso ocorre porque um modelo uma representa o do sistema segundo um particular metamodelo Esse metamodelo corresponde ao conjunto de elementos de modelagem estruturais e comportamentais e regras de uso desses elementos o qual permite construir modelos segundo o respectivo paradigma AURUM WOHLIN 2005 Assim para a modelagem conceitual de requisitos funcionais necess rio escolher um paradigma de desenvolvimento e o correspondente metamodelo subjacente a ele a partir do qual os modelos ser o constru dos O paradigma orientado a objetos por exemplo fornece um conjunto de elementos de modelagem que permite modelar um sistema como sendo composto de objetos organizados em classes que se comunicam entre si por meio de troca de mensagens Uma classe define as propriedades atributos relacionamentos e opera es que todos os objetos dela podem possuir Assim classes objetos associa es atributos e opera es dentre outros s o elementos do metamodelo subjacente ao paradigma orientado a objetos Neste texto o paradigma adotado o da orienta o a objetos Uma vez que a modelagem conceitual uma tarefa essencial e complexa til seguir um m todo Um m todo pode ser visto como uma maneira sistem tica de trabalhar para se o
153. como uma opera o de uma classe O corpo dessa opera o deve ser tal que sua execu o produza o conjunto de eventos estruturais que comp e o evento de dom nio A execu o dessa opera o vai deixar a base de informa es em um novo estado o qual deve satisfazer a todas as restri es est ticas definidas no modelo estrutural Assim durante a defini o da opera o correspondente ao efeito de um evento de dom nio devem se levar em conta as restri es capturadas no modelo estrutural e garantir que o novo estado da base de informa es do sistema vai satisfazer a todas elas Em outras palavras os eventos de dom nio do esquema comportamental devem estar consistentes com o esquema estrutural OLIV 2007 A ideia de efeito de um evento de dom nio estende se na verdade para quaisquer requisi es Ou seja o efeito de uma requisi o pode ser representado por meio de uma opera o de maneira an loga ao descrito anteriormente para eventos de dom nio No que concerne a consultas na modelagem conceitual define se apenas o conte do de informa o das respostas abstraindo se detalhes que dizem respeito ao formato e a caracter sticas de dispositivos de sa da OLIV 2007 Para que as informa es de atributos e associa es possam ser recuperadas para serem mostradas como parte das respostas a consultas as classes precisam prover opera es b sicas para obter essas informa es Assim como as demais opera es b s
154. cumentos est o em conformidade com os padr es estabelecidos e iv os requisitos realmente satisfazem s necessidades dos clientes e usu rios Em outras palavras idealmente um requisito seja ele uma regra de neg cio requisito funcional ou n o funcional deve ser WIEGERS 2003 PFLEEGER 2004 e Completo o requisito deve descrever completamente a funcionalidade a ser entregue no caso de requisito funcional a regra de neg cio a ser tratada no caso de regras de neg cio ou a restri o a ser considerada no caso de requisito n o funcional Ele deve conter as informa es necess rias para que o desenvolvedor possa projetar implementar e testar essa funcionalidade regra ou restri o e Correto cada requisito deve descrever exatamente a funcionalidade regra ou restri o a ser constru da e Consistente o requisito n o deve ser amb guo ou conflitar com outro requisito e Realista deve ser poss vel implementar o requisito com a capacidade e com as limita es do sistema e do ambiente de desenvolvimento e Necess rio o requisito deve descrever algo que o cliente realmente precisa ou que requerido por algum fator externo ou padr o da organiza o e Pass vel de ser priorizado os requisitos devem ter ordem de prioridade para facilitar o gerenciamento durante o desenvolvimento do sistema e Verific vel e pass vel de confirma o deve ser poss vel desenvolver testes para verificar se o requisito foi rea
155. da Ontologia Do ponto de vista da Engenharia de Requisitos est se mais interessado em ontologias como modelos conceituais Assim o foco est nas ditas ontologias de refer ncia as quais representam um modelo de consenso dentro de uma comunidade Uma ontologia de refer ncia uma especifica o independente de solu o com o objetivo de fazer uma descri o clara e precisa de entidades do dom nio para prop sitos de comunica o aprendizado e resolu o de problemas ZAMBORLINI GON ALVEZ GUIZZARDI 2008 Vale a pena destacar similaridades e diferen as entre modelos de dom nio em uma abordagem tradicional de Engenharia de Dom nio e em uma abordagem baseada em ontologias Ambos t m como prop sito capturar a conceitua o de um certo dom nio estando em um n vel de abstra o mais elevado do que um modelo conceitual de um sistema Entretanto ontologias s o desenvolvidas com v rios prop sitos em mente e n o somente de servir como uma especifica o base para o desenvolvimento de sistemas o que faz com que tenha de ser especificada com mais rigor normalmente exigindo o consenso em uma comunidade tornando a mais geral do que modelos de dom nio Uma vez que uma ontologia um artefato complexo de engenharia ela deve ser constru da usando m todos apropriados H diversos m todos existentes para o desenvolvimento de ontologias dentre eles SABiO FALBO 2004 Neon SU REZ FIGUEROA et al 2007 e Methontology GO
156. da empresa O sistema deve processar um pedido do cliente em um tempo inferior a cinco segundos contado a partir da entrada de dados O sistema pode lt verbo indicando a o seguido de complemento gt use o verbo poder para designar uma fun o ou caracter stica desej vel para o sistema ou seja para descrever um requisito desej vel mas n o essencial Exemplos O sistema pode notificar usu rios em d bito O sistema pode sugerir outros produtos para compra com base em produtos colocados no carrinho de compras do usu rio Em algumas situa es pode se querer explicitar que alguma funcionalidade ou caracter stica n o deve ser tratada pelo sistema Isso pode ser feito indicando se uma senten a com a seguinte estrutura O sistema n o deve lt verbo indicando a o seguido de complemento gt Tamb m poss vel registrar que alguma tarefa espec fica relacionada ao sistema n o far parte do escopo do projeto tal como a carga de dados de um sistema existente Nestes casos pode ser til ter uma tabela de requisitos negativos Wiegers 2003 recomenda diversas diretrizes para a reda o de requisitos dentre elas Escreva frases completas com a gram tica ortografia e pontua o correta Procure manter frases e par grafos curtos e diretos Use os termos consistentemente Defina os em um gloss rio Prefira a voz ativa o sistema deve fazer alguma coisa voz passiva alguma coisa deve ser feita Sempre que poss v
157. das consulta tais como dados que podem ser informados para a pesquisa totaliza es feitas em relat rios etc As colunas Requisitos e Classes t m a mesma fun o de suas hom nimas no modelo da Tabela 5 1 ou seja indicam respectivamente os requisitos que est o sendo tratados ou que devem ser pelo caso de uso e as classes do dom nio do problema necess rias para a realiza o do mesmo A Tabela 5 4 ilustra a descri o de um caso de usos de consulta do subsistema Controle de Acervo de uma videolocadora Engenharia de Requisitos Notas de Aula Cap tulo 5 Modelagem de Casos de Uso Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 102 Tabela 5 4 Descri o de Casos de Uso de Consulta Controle de Acervo de Videolocadora Caso de Uso Observa es Requisitos Classes Consultar Acervo As consultas ao acervo poder o ser RF11 RNFI Filme Item feitas informando uma ou uma RNF2 TipoMidia combina o das seguintes Distribuidora informa es t tulo ou parte dele original ou em portugu s g nero tipo de m dia dispon vel ator diretor nacionalidade e lan amentos 5 3 2 Descrevendo Informa es Complementares As descri es dos fluxos de eventos principal variantes e de exce o s o cruciais em uma descri o de casos de uso Contudo h outras informa es complementares que s o bastante teis e portanto que devem ser levantadas e
158. de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 75 Para fazer bom uso do paradigma OO importante conhecer os princ pios adotados por ele na administra o da complexidade bem como seus principais conceitos 4 3 1 Princ pios para Administra o da Complexidade O mundo real algo extremamente complexo Quanto mais de perto o observamos mais claramente percebemos sua complexidade A orienta o a objetos tenta gerenciar a complexidade inerente dos problemas do mundo real abstraindo conhecimento relevante e encapsulando o dentro de objetos De fato alguns princ pios b sicos gerais para a administra o da complexidade norteiam o paradigma orientado a objetos entre eles abstra o encapsulamento e modularidade Abstra o Uma das principais formas do ser humano lidar com a complexidade atrav s do uso de abstra es As pessoas tipicamente tentam compreender o mundo construindo modelos mentais de partes dele Tais modelos s o uma vis o simplificada de algo onde apenas os elementos relevantes s o considerados Modelos portanto s o mais simples do que os complexos sistemas que eles modelam Seja o exemplo de um mapa representando um modelo de um territ rio Um mapa til porque abstrai apenas as caracter sticas do territ rio que se deseja modelar Se um mapa inclu sse todos os detalhes do territ rio provavelmente teria o mesmo tamanho do territ rio e portanto n
159. de cada lado poss vel imaginar diferentes solu es para o problema Quais s o prioridades ALEXANDER BEUS DUKIC 2009 Durante a condu o do workshop enfatize que o tempo limitado e minimize dist rbios solicitando p ex que as pessoas desliguem seus celulares Atribua pap is s pessoas tais como respons vel por controlar o tempo respons vel por controlar se a discuss o est fugindo do assunto respons vel por fazer anota es etc Uma vez terminado as informa es descobertas no workshop devem ser registradas em um relat rio o qual deve ser validado pelos participantes ALEXANDER BEUS DUKIC 2009 Workshops de requisitos podem ser combinados com diversas t cnicas Durante um workshop de requisitos por exemplo cen rios podem ser elaborados Por outro lado resultados obtidos em diversas entrevistas podem ser levados discuss o em um workshop Al m dos Workshops de Requisitos outras duas t cnicas de coleta colaborativa de requisitos bastante utilizadas s o e Brainstorming neste tipo de reuni o representantes de diferentes grupos de interessados engajam se em uma discuss o informal para gerar rapidamente tantas ideias quanto poss vel sem focar a aten o em nenhuma delas Normalmente n o prop sito de uma sess o de brainstorming resolver maiores quest es ou tomar decis es Essa t cnica frequentemente utilizada para desenvolver uma declara o preliminar da miss o e dos requisitos para
160. de com sistemas de outras organiza es requisitos legais tais como requisitos de privacidade e requisitos ticos No que se refere aos RNFs de produto eles podem estar relacionados a propriedades emergentes do sistema como um todo ou seja propriedades que n o podem ser atribu das a uma parte espec fica do sistema mas que ao contr rio s aparecem ap s a integra o de seus componentes tal como confiabilidade SOMMERVILLE 2007 Contudo algumas vezes essas caracter sticas podem estar associadas a uma fun o espec fica ou a um conjunto de fun es Por exemplo uma certa fun o pode ter restri es severas de desempenho enquanto outras fun es do mesmo sistema n o apresentam tal restri o Ainda que a classifica o em requisitos funcionais e n o funcionais seja a mais amplamente aceita h outras classifica es de requisitos Por exemplo Sommerville 2007 considera al m de requisitos funcionais e n o funcionais requisitos de dom nio Segundo esse autor requisitos de dom nio s o provenientes do dom nio de aplica o do sistema e refletem caracter sticas e restri es desse dom nio Eles s o derivados do dom nio de aplica o e podem restringir requisitos funcionais existentes ou estabelecer como c lculos espec ficos devem ser realizados refletindo fundamentos do dom nio de aplica o Requisitos de dom nio na concep o de Sommerville s o o que outros autores tal como Wiegers 2003 ch
161. de uso fornecem uma abordagem para os desenvolvedores chegarem a uma compreens o comum com os usu rios finais e especialistas do dom nio acerca da funcionalidade a ser provida pelo sistema BOOCH RUMBAUGH JACOBSON 2006 8 s A Esta regra tem como exce o os casos de uso de inclus o e extens o conforme discutido mais adiante na se o que trata de relacionamentos entre casos de uso As mesmas exce es da nota anterior aplicam se aqui conforme discutido mais adiante Engenharia de Requisitos Notas de Aula Cap tulo 5 Modelagem de Casos de Uso Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 91 Os objetivos dos atores s o um bom ponto de partida para a identifica o de casos de uso Pode se propor um caso de uso para satisfazer cada um dos objetivos de cada um dos atores A partir desses objetivos podem se estudar as poss veis intera es do ator com o sistema e refinar o modelo de casos de uso Cada caso de uso tem um nome Esse nome deve capturar a ess ncia do caso de uso Para nomear casos de uso sugere se usar frases iniciadas com verbos no infinitivo seguidos de complementos que representem a meta ou tarefa a ser realizada com o caso de uso As primeiras letras exceto preposi es de cada palavra devem ser grafadas em letra mai scula Exemplos Cadastrar Cliente Devolver Livro Efetuar Pagamento de Fatura etc Um caso de uso pode ser visto como um tipo cujas inst n
162. delos podem ser utilizados Esses modelos s o representa es gr ficas que descrevem processos de neg cio o problema a ser resolvido e o sistema a ser desenvolvido Por utilizarem representa es gr ficas modelos s o geralmente mais compreens veis do que descri es detalhadas em linguagem natural SOMMERVILLE 2007 De maneira simples um modelo uma simplifica o da realidade enfocando certos aspectos considerados relevantes segundo a perspectiva do modelo e omitindo os demais Modelos s o constru dos para se obter uma melhor compreens o da por o da realidade sendo modelada Em ess ncia a fase de an lise uma atividade de modelagem A modelagem nesta fase dita conceitual pois ela se preocupa com o dom nio do problema e n o com solu es t cnicas para o mesmo Os modelos de an lise s o elaborados para se obter uma compreens o maior acerca do sistema a ser desenvolvido e para especific lo Diferentes modelos podem ser constru dos para representar diferentes perspectivas Tipicamente duas principais perspectivas s o consideradas na fase de an lise e Perspectiva estrutural busca modelar os conceitos propriedades e rela es do dom nio que s o relevantes para o sistema em desenvolvimento Prov uma vis o est tica das informa es que o sistema necessita tratar e portanto refere se s representa es que o sistema ter de prover para abstrair entidades do mundo real Diagramas de classes s o usa
163. descritores ou criar uma escala com mais pontos e Efeito Aur ola a impress o formada em uma quest o levada para a pr xima Solu o mesclar quest es sobre objetos diferentes Um question rio relevante e bem projetado pode aumentar a taxa de respostas As seguintes diretrizes podem ser teis durante o projeto um question rio KENDALL KENDALL 2010 e Deixe espa os em branco e Deixe espa o suficiente para as respostas para quest es subjetivas e Torne f cil para os respondentes marcar claramente suas respostas para quest es objetivas e Seja consistente no estilo Question rios podem ser aplicados de diversas maneiras Quando se decide aplicar um question rio por email ou pela Web considera es adicionais de planejamento relativas confidencialidade autentica o de identidade e problemas com m ltiplas respostas devem ser levadas em conta No caso de question rios dispon veis na Web use formatos de entrada de dados comumente usados tais como caixas de texto check boxes radio buttons drop down menu etc KENDALL KENDALL 2010 Para ordenar as quest es considere os objetivos e ent o determine a fun o de cada quest o para atingir esses objetivos Use um grupo piloto para auxiliar ou observe o question rio com olhos de respondedor Algumas orienta es devem ser seguidas dentre elas KENDALL KENDALL 2010 e Coloque quest es que s o importantes para os respondentes primeiro e
164. didos poss vel ainda entrevistar dois ou tr s interessados de uma s vez mas deve se evitar envolver pessoas demais pois se pode perder o controle da entrevista e o di logo descambar para uma discuss o geral ALEXANDER BEUS DUKIC 2009 As entrevistas podem ser de dois tipos principais SOMMERVILLE 2007 e Entrevistas fechadas nas quais o interessado responde a um conjunto de perguntas predefinidas e Entrevistas abertas nas quais n o existe um roteiro predefinido O analista explora v rios assuntos com o interessado e assim desenvolve uma maior compreens o de suas necessidades Geralmente as entrevistas s o uma combina o desses dois tipos As respostas a algumas perguntas podem levar a outros questionamentos discutidos de maneira menos estruturada As discuss es completamente abertas dificilmente funcionam bem A maioria das entrevistas requer algumas perguntas como ponto de partida e para manter o foco em um aspecto do sistema a ser desenvolvido SOMMERVILLE 2007 Entrevistas s o teis para dentre outros SOMMERVILLE 2007 KENDALL KENDALL 2010 KOTONYA SOMMERVILLE 1998 e obter objetivos organizacionais e pessoais e obter um entendimento geral sobre o problema sobre o que os interessados fazem e como eles podem interagir com o sistema e conhecer os sentimentos do entrevistado sobre os sistemas atuais e as dificuldades que eles t m com os mesmos e levantar procedimentos informais para inte
165. diversos pap is e assume diferentes responsabilidades Por exemplo um analista frequentemente desempenha o papel de um facilitador em sess es de levantamento de Engenharia de Requisitos Notas de Aula Cap tulo 3 Levantamento de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 33 requisitos em grupo guiando e apoiando os participantes no endere amento de quest es relevantes bem como garantindo que os participantes se sentem confort veis e seguros com o processo tendo oportunidade suficiente para contribuir Outro papel importante o de mediador Em muitos casos a prioriza o de requisitos ou negocia o de requisitos conflitantes por diferentes classes de interessados fonte de debate e disputa Neste contexto o analista deve negociar uma solu o adequada e obter o compromisso dos envolvidos AURUM WOHLIN 2005 3 2 T cnicas de Levantamento de Requisitos Uma vez que levantar requisitos n o tarefa f cil imprescind vel que essa atividade seja cuidadosamente conduzida fazendo uso de diversas t cnicas Dentre as diversas t cnicas que podem ser aplicadas para o levantamento de requisitos destacam se entrevistas question rios workshops de requisitos observa o investiga o de documentos prototipagem cen rios abordagens baseadas em objetivos e reutiliza o de requisitos Kendall e Kendall 2010 classificam os m todos de levantamento de requisitos em dois gr
166. do ator prim rio ou iii uma a o que o sistema realiza para proteger os interesses de um interessado Essas a es podem incluir valida es e mudan as do estado interno do sistema COCKBURN 2005 N o h um padr o definido para especificar casos de uso Diferentes autores prop em diferentes estruturas formatos e conte dos para descri es de casos de uso alguns mais indicados para casos de uso essenciais e mais complexos outros para casos de uso cadastrais e mais simples Mais al m pode ser til utilizar mais de um formato dentro do mesmo Engenharia de Requisitos Notas de Aula Cap tulo 5 Modelagem de Casos de Uso Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 94 projeto em fun o das peculiaridades de cada caso de uso De todo modo recomend vel que a organiza o defina modelos de descri o de casos de uso a serem adotados em seus projetos devendo definir tantos modelos quantos julgar necess rios Cockburn 2005 recomenda que pelo menos dois modelos de descri o de casos de uso sejam definidos um casual escrito como um texto corrido livre a ser usado em projetos com pouca formalidade outro completo com uma estrutura bem definida para projetos de maior formalidade As seguintes informa es s o um bom ponto de partida para a defini o de um modelo de descri o de casos de uso Nome nome do caso de uso capturando a sua ess ncia Escopo diz respeito ao que est
167. do que artefatos construir e como constru los A linguagem pode ser unificada mas a decis o de quais artefatos produzir e que passos seguir n o pass vel de padroniza o j que pode variar at mesmo de projeto para projeto Assim ao inv s de criarem um m todo unificado Rumbaugh Booch e Jacobson propuseram a UML incorporando as principais nota es para os produtos de seus m todos e de v rios outros com a colabora o de v rias empresas e autores A UML foi aprovada em novembro de 1997 pelo OMG Object Management Group pondo fim a uma guerra de m todos orientados a objeto Sua vers o mais recente a UML 2 0 foi adotada no in cio de 2005 e resultado de um esfor o de diversos colaboradores envolvendo empresas e pesquisadores sob a coordena o de uma for a tarefa do OMG Vale real ar que a UML somente uma linguagem e portanto apenas parte de um m todo de desenvolvimento de software Ela independente do processo de software a ser usado ainda que seja mais adequada a processos de desenvolvimento orientados a objetos Ela se destina a visualizar especificar construir e documentar artefatos de software BOOCH RUMBAUGH JACOBSON 2006 No contexto da Engenharia de Requisitos a UML prov diversos diagramas que podem ser usados na modelagem de requisitos tanto segundo a perspectiva estrutural quanto segundo a perspectiva comportamental Para a modelagem conceitual estrutural os diagramas de classes s o
168. do que nas demais refer ncias citadas anteriormente precisamente por se tratar este de um livro sobre a UML Refer ncias do Cap tulo BLAHA M RUMBAUGH J Modelagem e Projetos Baseados em Objetos com UML 2 Elsevier 2006 BOOCH G RUMBAUGH J JACOBSON I UML Guia do Usu rio 2a edi o Elsevier Editora 2006 COCKBURN A Escrevendo Casos de Uso Eficazes Um guia pr tico para desenvolvedores de software Porto Alegre Bookman 2005 OLIV A Conceptual Modeling of Information Systems Springer 2007 WAZLAWICK R S An lise e Projeto de Sistemas de Informa o Orientados a Objetos Elsevier 2004 Engenharia de Requisitos Notas de Aula Cap tulo 6 Modelagem Conceitual Estrutural Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 118 Cap tulo 6 Modelagem Conceitual Estrutural Um modelo conceitual estrutural uma abstra o da realidade segundo uma conceitua o Ele pode ser usado para comunica o aprendizado e an lise de aspectos relevantes do dom nio subjacente GUIZZARDI 2005 O modelo conceitual estrutural de um sistema tem por objetivo descrever as informa es que esse sistema deve representar e gerenciar A modelagem conceitual a atividade de descrever alguns dos aspectos do mundo f sico e social a nossa volta com o prop sito de entender e comunicar Os modelos resultantes das atividades de modelagem conceitual s o essencialmente destinados a serem usa
169. do sistema Esse trabalho come a com a descoberta de quais classes devem ser inclu das no modelo O cerne de um modelo OO exatamente o seu conjunto de classes Durante a an lise de requisitos tipicamente o analista estuda filtra e modela o dom nio do problema Dizemos que o analista filtra o dom nio pois apenas uma parte desse dom nio far parte das responsabilidades do sistema Assim um dom nio de problemas pode incluir v rias informa es mas as responsabilidades de um sistema nesse dom nio podem incluir apenas uma pequena parcela deste conjunto As classes de um modelo representam a express o inicial do sistema As atividades subsequentes da modelagem estrutural buscam obter uma descri o cada vez mais detalhada em termos de associa es e atributos Contudo deve se observar que medida que atributos e associa es v o sendo identificados se ganha maior entendimento a respeito do dom nio e naturalmente novas classes surgem Assim as atividades da modelagem conceitual s o iterativas e com alto grau de paralelismo devendo ser realizadas concomitantemente Um aspecto fundamental no processo de modelagem conceitual a intera o constante com os especialistas de dom nio T cnicas de levantamento de requisitos tais como entrevistas an lise de documentos e reuni es JAD t m um papel fundamental nesta etapa Assim o levantamento de requisitos continua acontecendo paralelamente modelagem conceitual
170. do software brasileiro Uma das metas do programa MPS BR definir e aprimorar um modelo de melhoria e avalia o de processo de software visando preferencialmente s micro pequenas e m dias empresas de forma a atender as suas necessidades de neg cio e ser reconhecido nacional e internacionalmente como um modelo aplic vel ind stria de software O modelo MPS estabelece um modelo de processos de software e um processo e um m todo de avalia o de processos Esta estrutura fornece sustenta o e garante que o modelo MPS seja empregado de forma coerente com as suas defini es sendo um modelo direcionado para a realidade brasileira A base t cnica do MPS composta pelas normas ISO EC 12207 e ISO IEC 15504 2 al m buscar garantir conformidade com o CMMI Essa abordagem visa garantir que o MPS est em conformidade com padr es internacionais Engenharia de Requisitos Notas de Aula Cap tulo 2 Engenharia de Requisitos de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 25 Assim como o CMMI o MPS organizado em n veis de maturidade No caso do MPS contudo s o sete n veis a saber G Parcialmente Gerenciado F Gerenciado E Parcialmente Definido D Largamente Definido C Definido B Gerenciado Quantitativamente A Em Otimiza o O MPS procura manter uma correspond ncia entre seus n veis de maturidade e os n veis de maturidade do CMMI Assim o n vel 2 do CMMI corresponde ao n
171. dos e agrupados os casos de uso interessante fazer uma descri o sucinta de seu prop sito N o se deve partir diretamente para os detalhes descrevendo fluxos de eventos e outras informa es Fazendo apenas uma descri o sucinta poss vel levar mais rapidamente os casos de uso discuss o com os clientes e usu rios permitindo identificar melhor quais s o efetivamente os casos de uso a serem contemplados pelo sistema Al m disso pode se dividir o trabalho designando diferentes analistas para trabalhar com casos de uso ou pacotes espec ficos Somente ent o se deve passar para a descri o detalhada dos casos de uso Inicialmente o foco deve ser no fluxo de eventos principal ou seja aquele em que tudo d certo na intera o Depois de descrever o fluxo de eventos normal deve se analisar de forma cr tica cada passo desses fluxos de eventos procurando verificar o que pode dar errado WAZLAWICK 2004 bem como se devem investigar maneiras alternativas ainda normais de realizar o caso de uso permitindo a identifica o de fluxos variantes A partir da identifica o de poss veis exce es e varia es deve se trabalhar na descri o de fluxos alternativos de exce o descrevendo procedimentos para contornar os problemas e variantes descrevendo maneiras alternativas de realizar com sucesso uma certa por o do caso de uso Assim uma maneira adequada para trabalhar com casos de uso consiste em identific los
172. dos para modelar esta perspectiva e Perspectiva comportamental visa modelar o comportamento geral do sistema de uma de suas funcionalidades ou de uma entidade espec fica ao Engenharia de Requisitos Notas de Aula Cap tulo 2 Engenharia de Requisitos de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 14 longo do tempo Prov uma vis o do comportamento do sistema ou de uma parcela do sistema Diagramas de casos de uso diagramas de atividades diagramas de estados e diagramas de intera o s o usados para modelar essa vis o Os modelos criados durante a atividade de an lise de requisitos cumprem os seguintes pap is PRESSMAN 2006 e Ajudam o analista a entender a informa o a fun o e o comportamento do sistema tornando a tarefa de an lise de requisitos mais f cil e sistem tica e Tornam se o ponto focal para a revis o e portanto a chave para a determina o da consist ncia da especifica o A an lise de requisitos uma atividade extremamente vinculada ao levantamento de requisitos Durante o levantamento de requisitos alguns problemas s o identificados e tratados Entretanto determinados problemas somente s o identificados por meio de uma an lise mais detalhada A an lise de requisitos ajuda a entender e detalhar os requisitos levantados a descobrir problemas nesses requisitos e a obter a concord ncia sobre as altera es de modo a satisfazer a todos os envolvidos
173. dos por pessoas e n o por m quinas MYLOPOULOS 1992 Assim modelos conceituais devem ser concebidos com foco no dom nio do problema e n o no dom nio da solu o e por conseguinte um modelo conceitual estrutural um artefato do dom nio do problema e n o do dom nio da solu o As informa es a serem capturadas em um modelo conceitual estrutural devem existir independentemente da exist ncia de um sistema computacional para trat las Assim o modelo conceitual deve ser independe da solu o computacional a ser adotada para resolver o problema e deve conter apenas os elementos de informa o referentes ao dom nio do problema em quest o Elementos da solu o tais como interfaces formas de armazenamento e comunica o devem ser tratados apenas na fase de projeto WAZLAWICK 2004 Uma vez que requisitos n o funcionais de produto atributos de qualidade s o inerentes solu o computacional geralmente eles n o s o tratados na modelagem conceitual Ou seja n o se consideram elementos de informa o para tratar aspectos como desempenho seguran a de acesso confiabilidade formas de armazenamento etc Esses atributos de qualidade do produto s o considerados posteriormente na fase de projeto Os elementos de informa o b sicos da modelagem conceitual estrutural s o os tipos de entidades e os tipos de relacionamentos A identifica o de quais os tipos de entidades e os tipos de relacionamentos que s o relevantes
174. e associa o pode ser vista como uma associa o que tem propriedades de classe BOOCH RUMBAUGH JACOBSON 2006 A Figura 6 12 mostra o exemplo anterior sendo modelado como uma classe de associa o segundo a nota o da UML itemPedido quantidade int EEE Figura 6 12 Nota o da UML para Classes Associativas Classes associativas s o ainda representa es de associa es Assim como uma inst ncia de uma associa o uma inst ncia de uma classe associativa um par ordenado conectando duas inst ncias das classes envolvidas na associa o Assim se Pedido100 uma inst ncia de Pedido L pis uma inst ncia de Produto e o Pedidol00 especifica 5 L pis ent o uma inst ncia de ItemPedido a tupla Pedido100 L pis 5 Classes associativas podem ser usadas tamb m para representar eventos cuja ocorr ncia precisa ser lembrada como nos exemplos das figuras 6 7 e 6 10 Entretanto importante observar que o uso de classes associativas nesses casos pode levar a problemas de modelagem Seja o seguinte contexto em um hospital pacientes s o tratados em unidades m dicas Um paciente pode ser tratado em diversas unidades m dicas diferentes as quais podem abrigar diversos pacientes sendo tratados A Figura 6 13 a mostra um modelo que busca representar essa situa o usando uma classe associativa Como uma classe associativa as inst ncias de Tratamento s o pares ordenados Paciente Unidade M dica Assim
175. e dentre eles FODA ODM EDLC FORM RSEB e Catalysis GIMENES HUZITA 2005 Contudo qualquer que seja a abordagem de an lise de dom nio empregada deve se ter em mente que um modelo de dom nio deve conter os elementos comuns s v rias aplica es do dom nio e n o detalhes espec ficos de uma ou de todas as aplica es Assim para ser realmente reutiliz vel um modelo de dom nio deve ser mais geral e abstrato contendo o conhecimento de senso comum a respeito do dom nio sem incluir detalhes que podem ser relevantes apenas para uma ou para poucas aplica es Deve se apontar ainda que a an lise de dom nio apenas ser uma abordagem interessante caso haja uma real necessidade de re so no dom nio em quest o A an lise de dom nio uma atividade complexa que consome tempo e recursos podendo ser anterior ou paralela a um processo de desenvolvimento de software Assim se n o houver uma real possibilidade de re so nesse dom nio a an lise de dom nio torna se invi vel A Figura 8 2 ilustra o processo de Engenharia de Dom nio e como ele pode apoiar o processo de desenvolvimento de um sistema de software Engenharia de Dom nio Desenvolvimento para Re so An lise de Projeto de Implementa o Dom nio Dom nio de Dom nio q P 2 q Pi Si pe Ed Componentes e Frameworks de Dom nio I I I An lise de Projeto de Implementa o Requisitos Software de Sistema 4 4 4 z d a
176. e por conseguinte n o quererem se envolver no processo de engenharia de requisitos e Fatores pol ticos e quest es organizacionais podem influenciar os requisitos para o sistema bem como o estabelecimento de suas prioridades e Clientes e usu rios frequentemente n o sabem o que realmente querem do sistema exceto em termos muito gerais Mesmo quando eles sabem o que querem eles t m dificuldade para articular os requisitos Al m disso podem ter demandas n o realistas por n o estarem cientes dos custos de suas solicita es e O ambiente de neg cio no qual ocorre o levantamento de requisitos est em constante mudan a Os requisitos podem mudar a sua import ncia pode mudar e novos requisitos podem surgir de novos interessados Dadas todas essas dificuldades o levantamento de requisitos deve ser conduzido de forma bastante cuidadosa fazendo uso de t cnicas para capturar e especificar os requisitos levantados Uma boa pr tica consiste em fazer o levantamento de requisitos de forma incremental Inicialmente em um levantamento preliminar de requisitos apenas requisitos de usu rio s o capturados Depois em v rias itera es outros requisitos de usu rio s o capturados e requisitos de sistema v o sendo detalhados e especificados Neste contexto importante real ar que o levantamento e a an lise de requisitos s o atividades estreitamente relacionadas e portanto devem ocorrer em paralelo Assim medida que os requ
177. e s o a base para o desenvolvimento OO tais como classes associa es generaliza o etc A seguir os principais conceitos da orienta o a objetos s o discutidos Objetos O mundo real povoado por entidades que interagem entre si onde cada uma delas desempenha um papel espec fico Na orienta o a objetos essas entidades s o ditas objetos Objetos podem ser coisas concretas ou abstratas tais como um carro uma reserva de passagem a rea uma organiza o etc Do ponto de vista da modelagem de sistemas um objeto uma entidade que incorpora uma abstra o relevante no contexto de uma aplica o Um objeto possui um estado informa o exibe um comportamento bem definido dado por um n mero de opera es para examinar ou alterar seu estado e tem identidade nica O estado de um objeto compreende o conjunto de suas propriedades associadas a seus valores correntes Propriedades de objetos s o geralmente referenciadas como atributos e associa es Portanto o estado de um objeto diz respeito aos seus atributos associa es e aos valores a eles associados Opera es s o usadas para recuperar ou manipular a informa o de estado de um objeto e se referem apenas s estruturas de dados do pr prio objeto n o devendo acessar diretamente estruturas de outros objetos Caso a informa o necess ria para a realiza o de uma opera o n o esteja dispon vel o objeto ter de colaborar com outros objetos A comunica
178. e Requisitos Notas de Aula Cap tulo 5 Modelagem de Casos de Uso Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 88 atores e de casos de uso sendo que essas ltimas podem ser complementadas com outros a TA de 6 diagramas associados tais como os diagramas de atividade e de sequ ncia da UML Outro aspecto a ser real ado que os modelos de caso de uso s o independentes do m todo de an lise a ser usado e at mesmo do paradigma de desenvolvimento Assim pode se utilizar a modelagem de casos de uso tanto no contexto do desenvolvimento orientado a objetos foco deste texto como em projetos desenvolvidos segundo o paradigma estruturado De fato o uso de modelos de caso de uso pode ser ainda mais amplo Casos de uso podem ser usados por exemplo para documentar processos de neg cio de uma organiza o Contudo neste texto explora se a utiliza o de casos de uso para modelar e documentar requisitos funcionais de sistemas Assim geralmente s o interessados stakeholders nos casos de uso as pessoas que usar o o sistema usu rios o cliente que requer o sistema outros sistemas com os quais o sistema em quest o ter de interagir e outros membros da organiza o ou at mesmo de fora dela que t m restri es que o sistema precisa garantir Este cap tulo aborda a t cnica de modelagem de casos de uso discutindo os principais elementos de modelos de casos de uso A Se o 5 1 discu
179. e Requisitos procurar derivar casos de uso Este apenas um ponto de partida uma vez que v rios casos de uso podem ser derivados a partir de um mesmo requisito funcional de usu rio Engenharia de Requisitos Notas de Aula Cap tulo 5 Modelagem de Casos de Uso Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 114 Uma maneira complementar de identificar casos de uso come ar pela identifica o de atores Cada ator deve ter um prop sito nico e coerente o qual deve ser descrito e documentado Para cada ator identificado pode se ent o levantar quais s o as funcionalidades por ele requeridas listando as na forma de casos de uso Cada caso de uso deve representar uma transa o completa que seja algo de valor para os atores envolvidos Contudo antes de identificar atores e casos de uso necess rio determinar claramente os limites do sistema Sem deixar claro quais s o os limites do sistema muito dif cil identificar atores ou casos de uso BLAHA RUMBAUGH 2006 Uma vez identificados atores e casos de uso pode se elaborar uma vers o preliminar do diagrama de casos de uso Vale lembrar que at mesmo para sistemas de pequeno porte til trabalhar com subsistemas procurando agrupar casos de uso em pacotes Assim importante procurar agrupar casos de uso relacionados em pacotes construindo tamb m diagramas de pacotes medida que os casos de uso v o sendo agrupados Uma vez identifica
180. e Software No que concerne s atividades t cnicas tipicamente o processo de software inicia se com o Levantamento de Requisitos quando os requisitos do sistema a ser desenvolvido s o preliminarmente capturados e organizados Uma vez capturados os requisitos devem ser modelados avaliados e documentados Uma parte essencial dessa fase a elabora o de modelos descrevendo o qu o software tem de fazer e n o como faz lo dita Modelagem Conceitual At este momento a nfase est sobre o dom nio do problema e n o se deve pensar na solu o t cnica computacional a ser adotada Com os requisitos pelo menos parcialmente capturados e especificados na forma de modelos pode se come ar a trabalhar no dom nio da solu o Muitas solu es s o poss veis para o mesmo conjunto de requisitos e elas s o intrinsecamente ligadas a uma dada plataforma de implementa o linguagem de programa o mecanismo de persist ncia a ser adotado etc A fase de projeto tem por objetivo definir e especificar uma solu o a ser implementada uma fase de tomada de decis o tendo em vista que muitas solu es s o poss veis Uma vez projetado o sistema pode dar se in cio implementa o quando as unidades de software do projeto s o implementadas e testadas individualmente Gradativamente os elementos v o sendo integrados e testados teste de integra o at se obter o sistema quando o todo deve ser testado teste de sistema Por
181. e ainda livre para acrescentar novas caracter sticas para seus prop sitos espec ficos 4 O termo caracter stica usado aqui para designar estrutura atributos e associa es e comportamento opera es Engenharia de Requisitos Notas de Aula Cap tulo 4 An lise de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 80 A generaliza o permite abstrair a partir de um conjunto de classes uma classe mais geral contendo todas as caracter sticas comuns A especializa o a opera o inversa e portanto permite especializar uma classe em um n mero de subclasses explicitando as diferen as entre as novas subclasses Deste modo poss vel compor a hierarquia de classes Esses tipos de relacionamento s o conhecidos tamb m como relacionamentos um tipo de onde um objeto da subclasse tamb m um tipo de objeto da superclasse Neste caso uma inst ncia da subclasse dita uma inst ncia indireta da superclasse Quando uma subclasse herda caracter sticas de uma nica superclasse tem se heran a simples Quando uma classe definida a partir de duas ou mais superclasses tem se heran a m ltipla importante observar no entanto que na heran a m ltipla podem ocorrer dois problemas colis o de nomes herdados a partir de diferentes superclasses e a possibilidade de heran a repetida A Figura 2 7 ilustra esses dois casos Classe A Classe A Classe B a x w Fa N y X
182. e aparar arestas dos desejos de potenciais interessados AURUM WOHLIN 2005 A fase de levantamento de requisitos envolve buscar junto aos usu rios clientes e outros interessados seus sistemas e documentos todas as informa es poss veis sobre as fun es que o sistema deve executar requisitos funcionais e as restri es sob as quais ele deve operar requisitos n o funcionais O produto principal dessa fase s o os documentos de requisitos WAZLAWICK 2004 Entretanto conforme citado anteriormente levantar requisitos n o uma tarefa f cil Esta uma tarefa de natureza multidimensional e os analistas ou engenheiros de requisitos se veem diante de v rios desafios dentre eles XOTONYA SOMMERVILLE 1998 e O conhecimento acerca do dom nio de aplica o encontra se disperso em uma variedade de fontes tais como livros manuais e sobretudo nas cabe as das pessoas que trabalham na rea Al m disso muitas vezes envolve uma terminologia especializada que n o imediatamente compreens vel pelo analista e As pessoas que entendem o problema a ser resolvido frequentemente est o muito ocupadas para despender tempo ajudando os analistas a entender os requisitos para um novo sistema Elas podem inclusive n o estar convencidas da necessidade do Engenharia de Requisitos Notas de Aula Cap tulo 3 Levantamento de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 30 novo sistema
183. e e portanto importante ter um mecanismo de dividir essa funcionalidade em partes menores e mais gerenci veis O conceito de caso de uso muito til para esse prop sito OLIVE 2007 importante ter em mente que modelos de casos de uso s o fundamentalmente uma ferramenta textual Ainda que casos de uso sejam tamb m descritos graficamente p ex fluxogramas ou algum diagrama da UML dentre eles diagramas de casos de uso diagramas de sequ ncia e diagramas de atividades n o se deve perder de vista a natureza textual dos modelos de casos de uso Olhando casos de uso apenas a partir da UML que n o trata do conte do ou da escrita de casos de uso pode se pensar equivocadamente que casos de uso s o uma constru o gr fica ao inv s de textual Em ess ncia casos de uso servem como um meio de comunica o entre pessoas algumas delas sem nenhum treinamento especial e portanto o uso de texto para especificar casos de uso geralmente a melhor escolha Casos de uso s o amplamente usados no desenvolvimento de sistemas porque por meio sobretudo de suas descri es textuais usu rios e clientes conseguem visualizar qual a funcionalidade a ser provida pelo sistema conseguindo reagir mais rapidamente no sentido de refinar alterar ou rejeitar as fun es previstas para o sistema COCKBURN 2005 Assim um modelo de casos de uso inclui duas partes principais 1 os diagramas de casos de uso e ii as descri es de Engenharia d
184. e lota o No outro relacionamento um empregado exerce o papel de chefe e portanto um departamento possui um e somente um chefe est lotado em B gt departamentoLotacao Empregado Departamento Doo O 0 1 chefe chefia B gt Figura 6 4 Exemplo Nomeando Associa es Ao contr rio das classes e dos atributos que podem ser encontrados facilmente a partir da leitura dos textos da descri o do minimundo e das descri es de casos de uso muitas vezes as informa es sobre associa es n o aparecem t o explicitamente Casos de uso descrevem a es de intera o entre atores e sistema e por isso acabam mencionando principalmente opera es Opera es transformam a informa o passando um objeto de um estado para outro por meio da altera o dos seus valores de atributos e associa es Uma associa o por sua vez uma rela o est tica que pode existir entre duas classes Assim as descri es de casos de uso est o repletas de opera es mas n o de associa es WAZLAWICK 2004 Contudo conforme discutido na se o anterior h alguns eventos que precisam ter sua ocorr ncia registrada e portanto s o tipicamente mapeados como classes Esses eventos est o descritos nos casos de uso e podem ter sido capturados como associa es Seja o exemplo de uma concession ria de autom veis Neste dom nio clientes compram carros como ilustra a parte a da Figura 6 5 Contudo a compr
185. e o sistema a ser desenvolvido obtidas no levantamento preliminar e explorat rio do sistema N o se devem incluir detalhes A Se o 4 por sua vez n o deve ter um formato livre Ao contr rio deve seguir um formato estabelecido pela organiza o contendo dentre outros identificador do requisito descri o tipo origem prioridade respons vel interessados depend ncias em rela o a outros requisitos e requisitos conflitantes A defini o de padr es organizacionais para a defini o de requisitos essencial para garantir uniformidade e evitar omiss o de informa es importantes acerca dos requisitos SOMMERVILLE 2007 WIEGERS 2003 Como consequ ncia o padr o pode ser usado como um guia para a verifica o de requisitos A Tabela 3 4 apresenta o padr o tabular sugerido neste texto Sugerem se agrupar requisitos de um mesmo tipo em diferentes tabelas Assim a informa o do tipo do requisito n o aparece explicitamente no padr o proposto Al m disso informa es complementares podem ser adicionadas em fun o do tipo de requisito A seguir discute se como cada um dos itens da tabela pode ser tratado segundo uma perspectiva geral Na sequ ncia s o tecidas considera es mais espec ficas sobre a descri o dos diferentes tipos de requisitos Tabela 3 4 Tabela de Requisitos Identificador Descri o Origem Prioridade Respons vel Interessados Depend ncias Conflitos O
186. e software de prover resultados ou efeitos corretos ou acordados com o grau de precis o necess rio o Interoperabilidade capacidade do produto de software de interagir com um ou mais sistemas especificados o Seguran a de Acesso capacidade do produto de software de proteger informa es e dados de forma que pessoas ou sistemas n o autorizados n o possam l los nem modific los e pessoas ou sistemas autorizados n o fa am acessos danosos a eles e Confiabilidade diz respeito capacidade do software manter seu n vel de desempenho sob condi es estabelecidas por um per odo de tempo Tem como subcaracter sticas o Maturidade capacidade do produto de software de evitar falhas decorrentes de defeitos no software o Toler ncia a Falhas capacidade do produto de software de manter um n vel de desempenho especificado em casos de defeitos no software ou de viola o de sua interface especificada Engenharia de Requisitos Notas de Aula Anexo A A Norma ISO IEC 9126 Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 175 o Recuperabilidade capacidade do produto de software de reestabelecer seu n vel de desempenho e recuperar os dados diretamente afetados no caso de uma falha e Usabilidade refere se capacidade do produto de software ser compreendido aprendido usado pelo usu rio e atrativo ao usu rio quando usado sob condi es especificadas Tem como subcaracter sticas o Inteligibi
187. ectos tratados neste cap tulo e muito mais Em KOTONYA SOMMERVILLE 1998 h uma excelente discuss o sobre Engenharia de Requisitos O processo apresentado neste texto fortemente baseado no processo proposto nesse livro Em especial os seguintes cap tulos t m informa es muito relevantes para complementar os estudos baseados nestas notas de aula Cap tulo 1 Introduction na forma de um FAQ Frequently Asked Questions aborda as no es de requisitos e engenharia de requisitos o Cap tulo 2 Requirements Engineering Process d uma vis o geral do processo de engenharia de requisitos o qual detalhado posteriormente nos cap tulos 3 Requirements Elicitation and Analysis 4 Requirements Validation e 5 Requirements Management Ainda neste livro o Cap tulo 8 Non functional Requirements discute requisitos n o funcionais Em WIEGERS 2003 h tamb m v rios cap tulos que abordam temas discutidos nestas notas de aula Sugere se em especial a leitura dos cap tulos 1 3 e 17 O Cap tulo 1 The Essential Software Requirements aborda o que s o requisitos n veis e tipos de requisitos os processos de desenvolvimento e ger ncia de requisitos e caracter sticas de qualidade de requisitos O Cap tulo 3 Good Practices for Requirements Engineering d uma vis o geral do processo de engenharia de requisitos apontando boas pr ticas Indica ainda outros cap tulos do livro que discutem
188. egocia o e colabora o com todos os interessados relevantes Deve prover ainda uma base para o aparecimento descoberta e inven o de requisitos como parte de um processo altamente interativo AURUM WOHLIN 2005 Zowghi e Coulin em AURUM WOHLIN 2005 indicam que as atividades do processo de levantamento de requisitos podem ser agrupadas em cinco tipos fundamentais de atividades a saber Engenharia de Requisitos Notas de Aula Cap tulo 3 Levantamento de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 31 Entendimento do Dom nio de Aplica o importante investigar e examinar em detalhes a por o do mundo real onde o sistema vai residir dita o dom nio de aplica o Aspectos sociais pol ticos e organizacionais bem como processos de trabalho existentes e problemas a serem resolvidos pelo sistema precisam ser descritos em rela o a metas e quest es do neg cio Identifica o de Fontes de Requisitos requisitos podem estar espalhados em v rias fontes e podem existir em v rios formatos Assim podem existir muitas fontes de requisitos para um sistema e elas devem ser identificadas Interessados representam a fonte de requisitos mais bvia Em especial clientes usu rios e especialistas de dom nio s o os mais indicados para fornecerem informa o detalhada sobre os problemas e as necessidades Sistemas e processos existentes s o tamb m fontes de requisitos especialmen
189. el identifique o tipo de usu rio Evite descri es gen ricas como o usu rio deve Se o usu rio no caso for por exemplo o caixa do banco indique claramente o caixa do banco deve Evite termos vagos que conduzam a requisitos amb guos e n o test veis tais 39 66 como r pido adequado f cil de usar etc Escreva requisitos em um n vel consistente de detalhe Evite requisitos desnecessariamente pequenos tais como requisitos individuais para tratar de a es de inclus o remo o altera o e consulta de um elemento de informa o p ex O sistema deve permitir a altera o de dados de clientes Em casos como este considere agrupar os requisitos menores em um requisito maior tal como O sistema deve permitir o controle de clientes Por outro lado evite longos par grafos narrativos que contenham m ltiplos requisitos Divida um requisito desta natureza em v rios menores O n vel de especifica o de um requisito deve ser tal que se o requisito satisfeito a necessidade do cliente atendida Contudo evite restringir desnecessariamente o projeto design Escreva requisitos individualmente test veis Um requisito bem escrito deve permitir a defini o de um pequeno conjunto de testes para verificar se o requisito foi corretamente implementado Engenharia de Requisitos Notas de Aula Cap tulo 3 Levantamento de Requisitos Ricardo de Almeida Falbo U
190. elagem Din mica Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 156 uma pergunta sendo feita O nome da opera o deve ser iniciado com letra min scula enquanto os nomes dos complementos devem iniciar com letras mai sculas sem dar um espa o em rela o palavra anterior Acentos n o devem ser utilizados Ex calcularValor emAtraso Na assinatura de uma opera o podem ser indicados zero ou mais par metros separados por v rgula cada um deles com a sintaxe abaixo onde nome par metro o nome para referenciar o par metro tipo seu tipo de dados ou classe e valor padr o o valor que ser assumido se um valor n o for informado nome par metro tipo valor padr o O tipo de retorno indica a classe ou o tipo de dado do valor retornado pela opera o o qual pode ser uma classe um tipo de dado primitivo ou um tipo de dado espec fico de dom nio Caso uma opera o n o tenha retorno nada especificado Conforme discutido anteriormente h opera es ditas b sicas que simplesmente manipulam atributos e associa es criam ou destroem objetos Essas opera es n o s o representadas nos diagramas de classes nem especificadas e documentadas no Dicion rio de Projeto j que podem ser deduzidas do modelo conceitual estrutural As demais opera es devem ser descritas no Dicion rio de Projeto dando uma descri o sucinta de seu prop sito Leitura Complementar Conforme a
191. em dois estados N o Venda Venda como mostra a Figura 7 5 Vale ressaltar que os diferentes diagramas de estados de uma mesma classe n o devem ter estados comuns Cada diagrama deve ter seu pr prio conjunto de estados e cada estado pertence a somente um diagrama de estados J os eventos podem aparecer em diferentes diagramas de estados inclusive de classes diferentes Quando um evento aparecer em mais de um diagrama de estados sua ocorr ncia vai disparar as correspondentes transi es em cada uma das m quinas de estados em que ele aparecer OLIV 2007 Engenharia de Requisitos Notas de Aula Cap tulo 7 Modelagem Din mica Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 147 quilometragem gt 50000kKm N o Venda dataCorrente dataAquisicao gt 1 ano vender Carro Figura 7 5 Diagrama de Gr fico de Estados da Classe Carro Possibilidade de Negocia o adaptado de OLIVE 2007 A Figura 7 5 mostra duas transi es em que os eventos n o s o declarados explicitamente No primeiro caso quilometragem gt 50 000Km o evento impl cito torna a condi o de guarda verdadeira na base de informa es do sistema Esse evento corresponde ao registro no sistema de qual a quilometragem corrente do carro Caso esse registro ocorra sempre no ato da devolu o do carro pelo cliente fluxo de eventos Devolver Carro do caso de uso Efetuar Loca o e ou no ato do rece
192. emas corporativos e de miss o cr tica o sistema em desenvolvimento estar funcionando no contexto de processos de neg cio de mais alto n vel e pode ser til usar diagramas de atividades para modelar esses processos com o intuito de investigar as formas como humanos e os v rios sistemas automatizados colaboram BOOCH RUMBAUGH JACOBSON 2006 Esse importante uso dos diagramas de atividades contudo est fora do escopo deste texto e portanto n o ser aqui abordado No contexto da modelagem comportamental de sistemas foco deste texto os diagramas de atividades podem ser usados para modelar o fluxo de trabalho em um caso de uso Para essa finalidade os principais elementos de modelo dos diagramas de atividades da UML utilizados s o atividades fluxos de controle pontos de inicia o e conclus o desvios ou ramifica es bifurca o e uni o fluxos de objetos e regi es de expans o Na modelagem de processos utilizam se tamb m raias para indicar quem que pessoa ou unidade organizacional respons vel por uma atividade Uma atividade uma por o significativa de trabalho dentro de um fluxo de trabalho Atividades podem ser at micas ou complexas Uma atividade at mica i e que n o pode ser decomposta dita uma a o na UML Uma atividade complexa composta de outras atividades at micas ou complexas e na UML representada por um n de atividade Assim um n de atividade representa um grupo de a es o
193. end ncia seta pontilhada estereotipada com a palavra chave include partindo do caso de uso base para o caso de uso de inclus o como ilustra a Figura 5 6 lt include gt lt include gt Caso de Uso Base 1 Caso de Uso de Inclus o Caso de Uso Base 2 Figura 5 6 Associa o de Inclus o na UML Uma associa o de inclus o deve ser referenciada tamb m na descri o do caso de uso base O local em que esse comportamento inclu do deve ser indicado na descri o do caso de uso base atrav s de uma refer ncia expl cita chamada ao caso de uso inclu do Assim a descri o do fluxo de eventos principal ou alternativo do caso de uso base deve conter um passo que envolva a chamada ao caso de uso inclu do referenciada por Incluir nome do caso de uso inclu do Para destacar refer ncias de um caso de uso para outro sugere se que o nome do caso de uso referenciado seja sublinhado e escrito em it lico Engenharia de Requisitos Notas de Aula Cap tulo 5 Modelagem de Casos de Uso Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 105 No exemplo do caixa autom tico todos os tr s casos de uso t m em comum uma por o que diz respeito valida o inicial do cart o Neste caso um relacionamento de inclus o deve ser empregado conforme mostra a Figura 5 7 Sistema Caixa Autom tico Efetuar Saque lt sinclude gt 3a Eniti Extrato gt lt include 4 v
194. ente o que o sistema far pois eles est o preocupados com o modo como o sistema apoiar os processos de neg cio ou porque est o envolvidos na sua constru o SOMMERVILLE 2007 Uma vez que requisitos de usu rio e de sistema t m prop sitos e p blico alvo diferentes til descrev los em documentos diferentes Pfleeger 2004 sugere que dois tipos de documentos de requisitos sejam elaborados e Documento de Defini o de Requisitos ou somente Documento de Requisitos deve ser escrito de maneira que o cliente possa entender i e na importante notar a distin o que se faz aqui entre clientes e usu rios finais Consideram se clientes aqueles que contratam o desenvolvimento do sistema e que muitas vezes n o usar o diretamente o sistema Eles est o mais interessados nos resultados da utiliza o do sistema pelos usu rios do que no sistema em si Usu rios por outro lado s o as pessoas que utilizar o o sistema em seu dia a dia Ou seja os usu rios s o as pessoas que v o operar ou interagir diretamente com o sistema Engenharia de Requisitos Notas de Aula Cap tulo 2 Engenharia de Requisitos de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 8 forma de uma listagem do qu o cliente espera que o sistema proposto fa a Ele representa um consenso entre o cliente e o desenvolvedor sobre o qu o cliente quer e Documento de Especifica o de Requisitos redefine os req
195. entro fora COCKBURN 2005 Uma lista dentro fora na verdade uma tabela com tr s colunas A primeira coluna enumera casos de uso as duas outras colunas s o rotuladas Dentro e Fora Sempre que n o for claro se um caso de uso est dentro ou fora do escopo da discuss o projeto ou itera o ele inclu do na tabela e deve se perguntar aos interessados se o caso de uso est dentro ou fora do escopo Assim poss vel capturar as diferentes vis es dos diferentes interessados sendo essas vis es muitas vezes conflitantes Identificados conflitos os mesmos devem ser negociados e resolvidos Ainda no que se refere ao planejamento e controle de projetos iterativos pode ser uma boa estrat gia priorizar os casos de uso de modo a definir o que considerar ou n o em uma itera o ou mesmo no projeto Para os casos de uso considerados dentro do escopo do projeto pode se indicar em qual vers o o caso de uso deveria ser tratado Por exemplo se foram planejados tr s itera es para o desenvolvimento de um certo sistema os interessados poderiam indicar em qual vers o 1 2 ou 3 cada caso de uso deveria ser tratado Essas listas de prioridades s o usadas como ponto de partida para a negocia o e o planejamento das itera es do projeto Leitura Complementar Os cap tulos 7 e 8 de BLAHA RUMBAUGH 2006 Modelagem de Intera es e Modelagem Avan ada de Intera es respectivamente abordam a modelagem de ca
196. epartamento ao mesmo tempo Um departamento pode ter mais do que um chefe nomeado ao mesmo tempo Infelizmente o modelo incapaz de responder a essas perguntas Para eliminar essas ambiguidades necess rio capturar regras de neg cio do tipo restri es de integridade No exemplo acima as seguintes regras se aplicam e Um empregado s pode estar lotado em um nico departamento em um dado momento e Um empregado s pode estar designado como chefe de um nico departamento em um dado momento e Um departamento s pode ter um empregado designado como chefe em um dado momento Observe que como um departamento pode ter v rios empregados nele lotados ao mesmo tempo n o necess rio escrever uma restri o de integridade pois este o caso mais geral sem restri o Assim restri es de integridade devem ser escritas apenas para as associa es que s o pass veis de restri es Engenharia de Requisitos Notas de Aula Cap tulo 6 Modelagem Conceitual Estrutural Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 130 Restri es de integridade s o regras de neg cio e poderiam ser lan adas no Documento de Requisitos Contudo como elas s o importantes para a compreens o e elimina o de ambiguidades do modelo conceitual til descrev las no pr prio modelo conceitual Al m das restri es de integridade relativas s multiplicidades n diversas outras restri es podem ser impo
197. epartamento pode ao longo do tempo mudar de chefe Se sim necess rio registrar o hist rico de chefias do departamento ou seja registrar o evento de nomea o do chefe do departamento Como colocado no modelo da Figura 6 4 est se representando apenas a situa o presente Se houver mudan a de chefe de um departamento ou do departamento de lota o de um empregado perder se a informa o hist rica Na maioria das vezes essa n o uma solu o aceit vel Na maioria dos dom nios as pessoas querem saber a informa o hist rica Assim nota se que parte das responsabilidades do sistema registrar a ocorr ncia dos eventos de nomea o do chefe e de lota o de empregados Assim um modelo mais fidedigno a essa realidade o modelo da Figura 6 7 o qual introduz as classes do tipo evento lembrado NomeacaoChefia e Lotacao data Data portaria String Lo O O possui J gt 4 especifica J gt Us departamentoLotacao Departamento Empregado NomeacaoChefia data Data portaria String DOl designa p 0 especifica B gt Figura 6 7 Registrando Hist ricos Ainda que este modelo seja mais fidedigno realidade ele ainda apresenta problemas Por exemplo o modelo diz que um empregado pode ter uma ou mais loca es Mas o empregado pode ter mais de uma lota o vigente O mesmo vale para o caso da nomea o de chefia Um empregado pode ser chefe de mais de um d
198. er aquela informa o dispon vel para a equipe A diretriz portanto conservar apenas aqueles modelos que fornecer o valor em longo prazo e descartar o restante Esse princ pio tem v rias consequ ncias o Deve se selecionar apenas um pequeno conjunto de modelos e diagramas para serem elaborados mantendo se em linha com o princ pio anterior o Caso se opte por elaborar um certo diagrama para compreender melhor um certo aspecto do software ele pode ser elaborado mas n o precisa ser necessariamente incorporado documenta o s vezes um esbo o em uma folha de papel cumpre o prop sito e o diagrama pode ser descartado em seguida o Praticamente todos os modelos e diagramas elaborados na fase de an lise podem ser refinados na fase de projeto incorporando detalhes relativos solu o espec fica a ser adotada Modelos de classes de casos de uso diagramas de estados de sequ ncia e de atividades por exemplo podem ter vers es de an lise e projeto Contudo nem sempre vale pena refinar todos esses diagramas Deve se avaliar criteriosamente quais deles refinar na fase de projeto Adote a simplicidade pressuponha que a solu o mais simples a melhor e mantenha os modelos t o simples quanto puder N o modele seu sistema em excesso hoje mostrando caracter sticas adicionais n o requeridas Conhe a os modelos e as ferramentas usadas para cri los Entenda o prop sito de cada modelo diagrama seus pontos fort
199. era es das classes Os diagramas de classes gerados pela atividade de modelagem conceitual estrutural representam apenas os elementos est ticos de um modelo de an lise orientada a objetos preciso ainda modelar o comportamento din mico da aplica o Para tal necess rio representar o comportamento do sistema como uma fun o do tempo e de eventos espec ficos Um modelo de din mico indica como o sistema ir responder a eventos ou est mulos externos e auxilia o processo de descoberta das opera es das classes do sistema Para apoiar a modelagem da din mica de sistemas a UML oferece tr s tipos de diagramas BOOCH RUMBAUGH JACOBSON 2006 e Diagrama de Gr fico de Estados mostra uma m quina de estados que consiste dos estados pelos quais objetos de uma particular classe podem passar ao longo de seu ciclo de vida e as transi es poss veis entre esses estados as quais s o resultados de eventos que atingem esses objetos Diagramas de gr fico de estados ou diagramas de transi o de estados s o usados principalmente para modelar o comportamento de uma classe dando nfase ao comportamento espec fico de seus objetos 2 De fato abordagens distintas podem ser usadas tal como representar tipos de requisi es como classes ditas classes de evento e os seus efeitos como opera es das correspondentes classes de evento tal como faz Oliv 2007 Engenharia de Requisitos Notas de Aula Cap tulo 7 Modelagem
200. ervo Atendimento a Cliente Controle de Acervo Figura 4 4 Exemplo de um Diagrama de Pacotes Leitura Complementar O Cap tulo 1 de OLIV 2007 Introduction d uma tima introdu o modelagem conceitual O Cap tulo 2 de BLAHA RUMBAUGH 2006 Modelagem como uma T cnica de Projeto discute o que s o modelos seus pap is e principais tipos de modelos J o Cap tulo 1 Introdu o apresenta uma boa introdu o orienta o a objetos e seus principais conceitos Em WIEGERS 2003 os cap tulos 10 e 11 est o relacionados a temas discutidos neste cap tulo O Cap tulo 10 Documenting the Requirements discute a estrutura de um documento de especifica o de requisitos enquanto o Cap tulo 11 4 Picture is Worth 1024 Words discute a modelagem de requisitos descrevendo diversos modelos que podem ser empregados nesta tarefa De ROBERTSON ROBERTSON 2006 sugere se a leitura do Cap tulo 9 Fit Criteria para a defini o de crit rios de aceita o para complementar a descri o de requisitos tornando os mensur veis e test veis Para apoiar a defini o desses crit rios recomenda se utilizar as medidas definidas nas partes 2 e 3 da norma ISO IEC 9126 ISO IEC 2003a ISO IEC 2003b Em BASS CLEMENTS KAZMAN 2003 o Cap tulo 4 Understanding Quality Attributes discute atributos de qualidade de sistemas de software e como especificar requisitos espec
201. es de diferentes grupos de interessados sendo estabelecidas regras de prepara o e participa o ii um facilitador que pode ser o analista ou outro participante controla a reuni o iii mecanismos de anota o tais como quadro branco flipcharts anota es em um computador projetadas para todos os participantes etc s o usados para registrar as ideias levantadas e iv a meta identificar ou debater um problema propor elementos da solu o negociar diferentes abordagens e especificar um conjunto preliminar de requisitos da solu o Geralmente o facilitador desempenha um papel cr tico no planejamento sele o dos participantes e sobretudo na condu o da reuni o de modo a encorajar a participa o para se atingir objetivos de modo consensual Se uma pessoa est participando pouco o facilitador deve tentar traz la para a discuss o dando espa o para ela se manifestar WIEGERS 2003 Em alguma extens o o trabalho em grupo se sobrep e ao trabalho com indiv duos entrevistas Entretanto um grupo re ne informa es de v rias fontes coloca as juntas permite ouvir v rios pontos de vista refina o entendimento coletivo e atinge concord ncia de uma maneira que n o poss vel com outras t cnicas de levantamento de requisitos ALEXANDER BEUS DUKIC 2009 Para ser bem sucedido os participantes devem estar de acordo com alguns princ pios operacionais b sicos tais como come ar e terminar a reuni o nos
202. es de integridade em um modelo gr fico As pr prias multiplicidades s o uma forma de capturar restri es de integridade ditas restri es de integridade de cardinalidade Al m das multiplicidades a UML prov o recurso de restri es as quais s o representadas entre chaves 4restri o Restri es podem ser usadas dentre outros para restringir a ocorr ncia de associa es Seja o seguinte exemplo em uma concession ria de autom veis compras podem ser financiadas ou por financeiras ou por bancos Para capturar essa restri o pode se usar a restri o xor da UML como ilustra a Figura 6 8 financiada por B gt financiada por B gt Figura 6 8 Restri o XOR entre Associa es Nesta figura uma compra ou est relacionada a um banco ou a uma financeira N o poss vel que uma compra esteja associada aos dois ao mesmo Como as multiplicidades m nimas do lado de banco e financeira s o zero uma compra pode n o ser financiada 17 Object Management Group http www omg org uma organiza o internacional que gerencia padr es abertos relativos ao desenvolvimento orientado a objetos dentre eles a UML Engenharia de Requisitos Notas de Aula Cap tulo 6 Modelagem Conceitual Estrutural Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 131 Ainda em rela o s multiplicidades vale frisar que associa es muitos para muitos s o perfeitamente legais em um modelo orie
203. es e de modelos conceituais Contudo na pr tica na grande maioria das vezes requisitos e modelos s o constru dos a partir do zero Ou seja requisitos de usu rio s o levantados junto aos interessados e posteriormente refinados em requisitos de sistema quando modelos s o constru dos levando se em conta os requisitos inicialmente capturados Entretanto essa abordagem tem se mostrado insuficiente pois desconsidera a reutiliza o do conhecimento j existente na organiza o acerca do dom nio do problema FALBO et al 2007 Ao especificar requisitos para um sistema interessante ter em mente que muito provavelmente algu m j desenvolveu algum sistema muito parecido ou at mesmo id ntico ao que est sendo desenvolvido Assim caso se tenha acesso aos requisitos de um sistema similar ao que ser desenvolvido certamente o esfor o para se obter requisitos para o mesmo ser bem menor ROBERTSON ROBERTSON 2006 O re so na Engenharia de Requisitos tem por objetivo a utiliza o de requisitos e outros artefatos relativos s fases da Engenharia de Requisitos de projetos anteriores com o intuito de auxiliar a obten o dos requisitos para um novo sistema a ser desenvolvido Engenharia de Requisitos Notas de Aula Cap tulo 8 Qualidade e Agilidade em Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 165 Requisitos podem ser reutilizados de diversas maneiras dentre elas pelo re so de e
204. es e fracos e as principais nota es a serem empregadas em cada fase do processo de desenvolvimento Conhe a tamb m as ferramentas usadas para cri los e suas limita es Isso dar agilidade ao desenvolvimento de modelos Ao considerar esses princ pios na modelagem segundo o paradigma orientado a objetos chega se ao seguinte conjunto de orienta es Modelos de casos de uso e de classes s o essenciais para o desenvolvimento e devem ser elaborados durante a an lise de requisitos Descri es de casos de uso completas s devem ser elaboradas para casos de uso mais complexos tipicamente Engenharia de Requisitos Notas de Aula Cap tulo 8 Qualidade e Agilidade em Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 164 aqueles relacionados aos principais processos de neg cio sendo apoiados pelo sistema em desenvolvimento e Diagramas de estados s devem ser elaborados para classes com comportamento dependente do estado Recomenda se elaborar diagramas de estados apenas para as classes que possu rem tr s ou mais estados relevantes Se julgado til para a compreens o pode ser elaborado um diagrama de estados para uma classe com apenas dois estados relevantes Entretanto deve se avaliar se o mesmo n o pode ser descartado ap s cumprir seu prop sito n o sendo incorporado documenta o do projeto e Diagramas de atividades s devem ser elaborados quando forem teis para refinar o en
205. essa t cnica poss vel capturar o que realmente feito e qual tipo de suporte computacional realmente necess rio Ajuda a confirmar ou refutar informa es obtidas com outras t cnicas e ajuda a identificar tarefas que podem ser automatizadas e que n o foram identificadas pelos interessados e An lise de documentos pela an lise de documentos existentes na organiza o analistas capturam informa es e detalhes dif ceis de conseguir por entrevista e observa o Documentos revelam um hist rico da organiza o e sua dire o e Cen rios com o uso desta t cnica um cen rio de intera o entre o usu rio final e o sistema montado e o usu rio simula sua intera o com o sistema nesse cen rio explicando ao analista o que ele est fazendo e de que informa es ele precisa para realizar a tarefa descrita no cen rio O uso de cen rios ajuda a entender requisitos a expor o leque de poss veis intera es e a revelar facilidades requeridas e Prototipagem um prot tipo uma vers o preliminar do sistema muitas vezes n o operacional e descart vel que apresentada ao usu rio para capturar informa es espec ficas sobre seus requisitos de informa o observar rea es Engenharia de Requisitos Notas de Aula Cap tulo 2 Engenharia de Requisitos de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 13 iniciais e obter sugest es inova es e informa es para estabele
206. estruturais porque eles s o completamente determinados pelo esquema conceitual estrutural e n o s o explicitamente mostrados no esquema comportamental OLIVE 2007 No desenvolvimento orientado a objetos os eventos estruturais correspondem a opera es b sicas das classes Assim toda classe tem implicitamente opera es para criar objetos da classe evento estrutural de inser o de entidade dita opera o construtora da classe eliminar objetos evento estrutural de remo o de entidade dita opera o destruidora da classe estabelecer liga es e atribuir valores para atributos eventos estruturais de inser o de relacionamentos e remover liga es ou excluir valores de atributos eventos estruturais de remo o de relacionamentos Essas opera es s o consideradas b sicas e n o precisam ser mostradas explicitamente no modelo conceitual Seja o exemplo de um sistema de controle de produtos cujo modelo estrutural parcialmente apresentado na Figura 7 1 Nesse exemplo quando a companhia come a a trabalhar com um novo produto p ex Prod1 o estado do dom nio se altera caracterizando um evento de dom nio Esse evento de dom nio corresponde a cinco eventos estruturais a saber 1 a cria o do objeto Prod1 2 a atribui o de um valor para o atributo codigo 3 a atribui o de um valor para o atributo valor 4 a atribui o de um valor para o atributo quantidadeEstoque e 5 o estabelecimento da associa
207. eto mude de estado como ilustra a Figura 7 9 Essa forma de modelagem contudo pode n o ser uma boa op o uma vez que gera classes complexas com regras de consist ncia que t m de ser verificadas muitas vezes para evitar a execu o de um m todo que atribui um valor a um atributo espec fico de um estado WAZLAWICK 2004 tal como dataPagamento Locacao dataLocacao Date dataDevolucaoPrevista Date valorDevido Currency caucao Currency dataDevolucaoEfetiva Date problemasRegistrados String dataPagamento Date valorPagamento Currency formaPagamento FormaPagamento estado EstadoLocacao Figura 7 9 Classe Loca o com atributos inerentes a diferentes estados l Monot nico diz respeito a algo que ocorre de maneira cont nua Neste caso a continuidade adv m do fato de um objeto continuamente ganhar novos atributos e associa es sem perder os que j possu a Engenharia de Requisitos Notas de Aula Cap tulo 7 Modelagem Din mica Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 151 poss vel modelar essa situa o desdobrando o conceito original em tr s um representando a loca o efetivamente outro representando a devolu o e outro representando o pagamento Desta forma capturam se claramente os eventos de loca o devolu o e pagamento colocando as informa es de cada evento na classe correspondente como ilustra a Figura 7 10 Devolucao data Date
208. etos A esse modelo d se o nome de classe Uma classe descreve um conjunto de objetos com a mesma estrutura atributos e associa es o mesmo comportamento opera es e a mesma sem ntica Objetos que se comportam da maneira especificada pela classe s o ditos inst ncias dessa classe Todo objeto pertence a uma classe ou seja inst ncia de uma classe De fato a orienta o a objetos norteia o processo de desenvolvimento atrav s da classifica o de objetos isto objetos s o agrupados em classes em fun o de exibirem caracter sticas similares sem no entanto perda de sua individualidade como ilustra a Figura 2 6 Assim a modelagem orientada a objetos consiste basicamente na defini o de classes O comportamento e a estrutura de informa o de uma inst ncia s o definidos pela sua classe Objetos com propriedades e comportamento id nticos s o descritos como inst ncias de uma mesma classe de modo que a descri o de suas propriedades possa ser feita uma nica vez de forma concisa independentemente do n mero de objetos que tenham tais propriedades em comum Deste modo uma classe captura as caracter sticas comuns a todas as suas inst ncias Enquanto um objeto individual uma entidade real que executa algum papel no sistema como um todo uma classe captura a estrutura e o comportamento comuns a todos os objetos que ela descreve Assim uma classe serve como uma esp cie de contrato que deve ser estabelecido
209. exclus o de filmes que tenham itens associados E Ao excluir um filme devem se excluir as reservas associadas Item Filme TipoMidia Cadastrar Item I A C E RF9 RNFI RNF3 I Informar filme tipo de m dia data de aquisi o e n mero de s rie E N o permitido excluir um item que tenha loca es associadas Cadastrar Distribuidora Distribuidora LA C E CNPJ de RF10 RNF1 I Informar raz o social endere o telefone e pessoa contato E N o permitido excluir uma distribuidora que tenha filmes associados Cadastrar Tipo de Midia I A C E I Informar nome e valor de loca o RF9 RNF1 TipoMidia E N o permitido excluir um tipo de m dia que tenha itens associados E Ao excluir um tipo de m dia devem se excluir as reservas que especificam apenas esse tipo de m dia Para casos de uso de consulta mais abrangente do que a consulta de um nico objeto j tratada como parte dos casos de uso cadastrais mas ainda de baixa complexidade tais como consultas que combinam informa es de v rios objetos envolvendo filtros sugere se utilizar o formato tabular mostrado na Tabela 5 3 Tabela 5 3 Modelo de Descri o de Casos de Uso de Consulta Caso de Uso Observa es Requisitos Classes lt nome do caso de uso gt A coluna Observa es deve ser usada para listar informa es importantes relaciona
210. extens o ortogonais e podem ser combinadas Por exemplo um primeiro prot tipo que implementa apenas parte das interfaces de um sistema mas que usado como base para o desenvolvimento posterior pode ser classificado como um prot tipo de interface evolutivo e de caracter sticas selecionadas J o que Kendall e Kendall 2010 chamam de um prot tipo arranjado s pressas i e um prot tipo que possui toda a funcionalidade do sistema final mas que n o foi constru do com o devido cuidado e que portanto sua qualidade e desempenho s o deficientes pode ser considerado um prot tipo operacional e completo podendo ser descart vel ou evolutivo dependendo se ele for ser usado ou n o como base para o desenvolvimento do produto final Engenharia de Requisitos Notas de Aula Cap tulo 3 Levantamento de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 51 O que Kendall e Kendall 2010 chamam de um prot tipo primeiro de uma s rie i e um sistema piloto desenvolvido para ser avaliado antes de ser distribu do pode ser considerado um prot tipo operacional completo e evolutivo Contudo nem todas as categorias podem ser combinadas entre si Por exemplo um prot tipo n o operacional necessariamente um prot tipo de caracter sticas selecionadas uma vez que ele certamente n o implementa todas as caracter sticas que se imagina ter o sistema real Diferentes tipos de prot tipos podem
211. feito e qual a dura o esperada para se responder o question rio e Como dentre os aspectos a serem considerados no projeto de um question rio podem ser citados os tipos e a reda o das quest es escalas e m todo de aplica o Question rios podem ter quest es objetivas ou subjetivas Quest es subjetivas s o particularmente adequadas a situa es em que se deseja saber a opini o dos membros da organiza o acerca de algum aspecto do sistema sendo imposs vel portanto listar efetivamente todas as respostas poss veis para uma pergunta Quando se decidir utilizar quest es subjetivas em um question rio deve se antecipar o tipo de resposta que se espera obter Essas quest es devem ser restritas o suficiente para guiar as pessoas de modo que respondam de uma maneira espec fica KENDALL KENDALL 2010 Deve se tomar cuidado com perguntas que permitam respostas muito amplas pois isso pode dificultar a compara o e a interpreta o dos resultados Quest es objetivas por outro lado devem ser utilizadas em um question rio quando o engenheiro de requisitos capaz de listar as poss veis respostas e quando h uma grande amostra de pessoas a examinar Respostas a quest es objetivas s o mais facilmente quantificadas enquanto respostas a quest es subjetivas s o analisadas e interpretadas de maneira diferente A Tabela 3 2 compara o uso de quest es objetivas e subjetivas em question rios KENDALL KENDALL 2010 Tabel
212. ferentes representantes de usu rios classifiquem cada atributo em uma escala de 1 sem import ncia a 5 muito importante As respostas ajudam o analista a determinar quais atributos s o mais importantes Obviamente conflitos podem surgir e precisam ser resolvidos WIEGERS 2003 Um aspecto a considerar que diferentes partes do produto podem requerer diferentes combina es de atributos de qualidade Assim importante tamb m diferenciar caracter sticas que se aplicam ao produto por inteiro daquelas que s o necess rias para certas partes do sistema WIEGERS 2003 Uma vez priorizados os atributos de qualidade o analista deve passar ent o a trabalhar com os usu rios no sentido de especificar requisitos mensur veis e por conseguinte test veis para cada atributo considerado importante Se os atributos de qualidade s o Engenharia de Requisitos Notas de Aula Cap tulo 3 Levantamento de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 66 especificados de maneira n o pass vel de verifica o n o poss vel dizer posteriormente se eles foram atingidos ou n o Quando apropriado devem se indicar escalas ou unidades de medida para cada atributo e os valores m nimo alvo e m ximo Se n o for poss vel quantificar todos os atributos importantes deve se pelo menos definir suas prioridades Pode se ainda perguntar aos usu rios o que constituiria um valor inaceit vel para cada at
213. ftware trata de tipos e n veis de requisitos bem como da documenta o de requisitos No Cap tulo 77 Processos de Engenharia de Requisitos a se o 7 2 dedicada ao levantamento e an lise de requisitos Engenharia de Requisitos Notas de Aula Cap tulo 3 Levantamento de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 68 Nesta se o s o brevemente discutidas algumas t cnicas de levantamento de requisitos dentre elas entrevistas cen rios e etnografia Em PFLEEGER 2004 a se o 4 7 que trata da documenta o de requisitos merece destaque Em PRESSMAN 2006 merecem destaque as se es 7 3 In cio do Processo de Engenharia de Requisitos e 7 4 Levantamento de Requisitos Por fim no que se refere modelagem de processos de neg cio e sua sinergia com a engenharia de requisitos em CARVALHO 2009 e CARDOSO 2007 h timas discuss es Em especial o Cap tulo 5 de CARVALHO 2009 Apresenta o de Algumas Abordagens de Identifica o de Requisitos de Sistemas a partir dos Processos de Neg cio apresenta diversas abordagens que fazem uso da modelagem de processos de neg cio para apoiar o levantamento de requisitos Uma vis o resumida mas muito boa do trabalho de Cardoso 2007 apresentada em CARDOSO ALMEIDA GUIZZARDI 2008 Refer ncias do Cap tulo AURUM A WOHLIN C Engineering and Managing Software Requirements Springer Verlag 2005
214. ftware Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 9 caracter sticas da organiza o Existem portanto fatores que contribuem para a variabilidade do processo de engenharia de requisitos dentre eles a maturidade t cnica o envolvimento disciplinar a cultura organizacional e os dom nios de aplica o nos quais a organiza o atua KOTONYA SOMMERVILLE 1998 Wiegers 2003 destaca alguns benef cios que um processo de Engenharia de Requisitos de alta qualidade pode trazer dentre eles menor quantidade de defeitos nos requisitos redu o de retrabalho desenvolvimento de menos caracter sticas desnecess rias diminui o de custos desenvolvimento mais r pido menos problemas de comunica o altera es de escopo reduzidas estimativas mais confi veis e maior satisfa o dos clientes e membros da equipe Ainda que diferentes projetos requeiram processos com caracter sticas espec ficas para contemplar suas peculiaridades poss vel estabelecer um conjunto de atividades b sicas que deve ser considerado na defini o de um processo de engenharia de requisitos Tomando por base o processo proposto por Kotonya e Sommerville 1998 neste texto considera se que um processo de engenharia de requisitos deve contemplar tipicamente as atividades mostradas na Figura 2 1 levantamento de requisitos an lise de requisitos documenta o de requisitos verifica o e valida o de requisitos e ger nci
215. g cio Engenharia de Requisitos Notas de Aula Cap tulo 3 Levantamento de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 55 SE O Es r n Fy Es Z A Te Quem AAS yr Onde f DON Intera es de neg cio Estrutura DEE Localiza es geogr ficas 2 2 2 Quando como e E Co mm Por Porqu Processos de neg cio Objetivos de neg cio Atividades 9 J g Eventos O qu z Objetos de neg cio Figura 3 1 Aspectos Envolvidos em um Modelo de Neg cio KNIGHT 2004 Como ilustra a Figura 3 2 para modelar esses diferentes aspectos diferentes tipos de modelos podem ser elaborados dentre eles KNIGHT 2004 e Modelo organizacional representa as unidades organizacionais seus pap is e seus relacionamentos e Modelo de localiza o geogr fica representa as localidades pelas quais a organiza o est distribu da e os relacionamentos entre localidades e unidades organizacionais e Modelo de objetivos mostra os objetivos da organiza o e seus relacionamentos o desdobramento dos objetivos em subobjetivos e o relacionamento entre os objetivos e os processos de neg cio e Modelo de processos representa os processos de neg cio executados na organiza o com suas atividades e relacionamentos e seus desdobramentos em subprocessos e atividades e Modelo de atividades mostra o relacionamento entre as atividades executadas nos processos de neg cio seus respons veis
216. gere se o uso de verbos conjugados indicando o sentido de leitura Ex Cliente classe efetua gt associa o Loca o classe Cada classe envolvida na associa o desempenha um papel ao qual pode ser dado um nome Cada classe envolvida na associa o possui tamb m uma multiplicidade nessa associa o que indica quantos objetos podem participar de uma inst ncia dessa associa o A nota o da UML tipicamente usada para representar associa es em um modelo conceitual ilustrada na Figura 6 3 nome com sentido de leitura B gt c d T papelClasse1 papelllasse2 77 Figura 6 3 Nota o de Associa es na UML Na ilustra o da figura um objeto da Classel se relaciona com no m nimo c e no m ximo d objetos da Classe2 J um objeto da Classe se relaciona com no m nimo a e no m ximo b objetos da Classel Objetos da Classe desempenham o papel de papelClassel Multiplicidades em uma associa o s o an logas s multiplicidades em atributos e especificam as quantidades m nima e m xima de objetos que podem participar da associa o Quando nada for dito o padr o 1 1 como no caso de atributos Contudo para deixar os modelos claros recomenda se sempre especificar explicitamente as multiplicidades das associa es Engenharia de Requisitos Notas de Aula Cap tulo 6 Modelagem Conceitual Estrutural Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 127 nes
217. grafia s o especialmente teis para endere ar fatores contextuais e de ambientes de trabalho cooperativo AURUM WOHLIN 2005 A observa o uma das t cnicas de etnografia mais usadas no levantamento de requisitos Como o pr prio nome indica o analista observa os usu rios executando os processos sem interfer ncia direta AURUM WOHLIN 2005 Ela empregada para compreender requisitos sociais e organizacionais bem como para compreender como as tarefas s o realizadas efetivamente O analista se insere no ambiente de trabalho onde o sistema ser usado observa o trabalho do dia a dia e faz anota es acerca das tarefas reais nas quais os participantes est o envolvidos SOMMERVILLE 2007 Atrav s da observa o poss vel capturar SOMMERVILLE 2007 KENDALL KENDALL 2010 e Requisitos derivados da maneira como as pessoas realmente trabalham e n o da maneira como os processos s o documentados ou explicados poss vel derivar requisitos impl citos que refletem os processos reais e n o os formais com os quais as pessoas est o envolvidas e Requisitos derivados do relacionamento entre o indiv duo que toma decis es e outros membros da organiza o Esses requisitos s o derivados da colabora o e do conhecimento das atividades de outras pessoas Por outro lado essa t cnica n o apropriada para obter requisitos de dom nio bem como pode ser dif cil identificar novas caracter sticas a serem acrescentadas a
218. gundo aspectos como n vel de habilidade n vel na organiza o e membros em diferentes grupos Pressman 2006 prop e uma classifica o que considera tr s grupos principais e Usu rio novato conhece pouco a interface para utiliz la eficientemente conhecimento sint tico p ex n o sabe como atingir uma funcionalidade desejada e entende pouco as fun es e objetivos do sistema conhece pouco a sem ntica da aplica o ou n o sabe bem como usar computadores em geral e Usu rio conhecedor e espor dico possui um conhecimento razo vel da sem ntica da aplica o mas tem relativamente pouca lembran a dos mecanismos de intera o providos pela interface informa es sint ticas necess rias para utilizar a interface e Usu rio conhecedor e frequente possui bom conhecimento tanto sint tico quanto sem ntico e buscam atalhos e modos abreviados de intera o Engenharia de Requisitos Notas de Aula Cap tulo 5 Modelagem de Casos de Uso Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 103 N o s o apenas os atores os interessados em um caso de uso Outras pessoas ou unidades de uma organiza o podem ter interesse nos resultados do caso de uso Seja o caso de uma locadora de autom veis Em um caso de uso de loca o o nico papel a interagir com o sistema o de funcion rio do atendimento Contudo o cliente o setor de prepara o de autom veis a contabilidade dentre outros s o tam
219. guran a de acesso e conformidade e Confiabilidade diz respeito capacidade do software manter seu n vel de desempenho sob condi es estabelecidas por um per odo de tempo Tem como subcaracter sticas maturidade toler ncia a falhas recuperabilidade e conformidade e Usabilidade refere se ao esfor o necess rio para se utilizar um produto de software bem como o julgamento individual de tal uso por um conjunto de usu rios Tem como subcaracter sticas inteligibilidade apreensibilidade operacionalidade atratividade e conformidade e Ffici ncia diz respeito ao relacionamento entre o n vel de desempenho do software e a quantidade de recursos utilizados sob condi es estabelecidas Tem como subcaracter sticas comportamento em rela o ao tempo comportamento em rela o aos recursos e conformidade e Manutenibilidade concerne ao esfor o necess rio para se fazer modifica es no software Tem como subcaracter sticas analisabilidade modificabilidade estabilidade testabilidade e conformidade e Portabilidade refere se capacidade do software ser transferido de um ambiente para outro Tem como subcaracter sticas adaptabilidade capacidade para ser instalado coexist ncia capacidade para substituir e conformidade interessante observar que mesmo dentre as subcaracter sticas de funcionalidade h atributos que geralmente n o s o pensados pelos usu rios como fun es que o sistema deve prover tais
220. hor rios predefinidos manter apenas uma conversa de cada vez permitir a contribui o de todos e enfocar coment rios e cr ticas em quest es e n o em indiv duos Diferentes interessados tipicamente t m um objetivo comum mas t m diferentes vis es do problema e sub objetivos bastante distintos Ningu m deve esquecer seus pr prios sub objetivos mas o credo de todos os participantes deve ser Meu ponto de vista um dentre v rios e o mais importante o objetivo final comum Deve se considerar ainda que o sucesso de uma reuni o de coleta Engenharia de Requisitos Notas de Aula Cap tulo 3 Levantamento de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 41 colaborativa de requisitos depende fortemente da habilidade do facilitador e dos participantes trabalharem como uma equipe inovadora Al m disso deve ser poss vel dar voz a todos os participantes WIEGERS 2003 ALEXANDER BEUS DUKIC 2009 Uma t cnica de coleta colaborativa de requisitos s o os Workshops de Requisitos Workshop de Requisitos o nome dado a um n mero de diferentes tipos de reuni es envolvendo diversas pessoas cujo foco a descoberta e desenvolvimento de requisitos AURUM WOHLIN 2005 Workshops de requisitos colocam um grupo de pessoas junto com o objetivo comum de levantar requisitos para um problema compartilhado para o qual essas pessoas t m vis es distintas O prop sito obter conhecimento e energ
221. ia es atributos e opera es modelados no diagrama de classes devem ser necess rios e suficientes para realizar cada um dos fluxos de eventos apontados nas descri es de casos de uso b Quando uma descri o de caso de uso fizer men o a dados de uma classe no diagrama de classes ent o a descri o do caso de uso deve ser consistente com os atributos modelados na correspondente classe do diagrama de classes e vice versa c Para manter os modelos rastre veis a descri o de caso de uso deve enumerar as classes envolvidas em sua realiza o Engenharia de Requisitos Notas de Aula Cap tulo 8 Qualidade e Agilidade em Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 161 H3 Dicion rio de Projeto x Diagrama de Classes Os seguintes aspectos devem ser verificados nas rela es entre dicion rios de projeto e diagramas de classes a Para cada classe existente no diagrama de classes deve haver uma entrada no dicion rio de projeto associada a uma descri o sucinta da mesma b Todos os atributos e opera es apresentados no diagrama de classes devem estar enumerados e sucintamente descritos na entrada do dicion rio de projeto referente correspondente classe c Restri es de integridade n o pass veis de registro pela nota o da UML devem ser explicitamente declaradas no modelo de classes As classes associa es e atributos envolvidos em uma restri o de integr
222. ia suficientes para levantar requisitos r pida e eficientemente ALEXANDER BEUS DUKIC 2009 Um workshop de requisitos n o simplesmente uma reuni o Um workshop uma reuni o com prop sito definido e atividades planejadas Assim requer planejamento endere ando as cinco quest es b sicas e Por que a primeira coisa a ser feita estabelecer os objetivos do workshop Workshops s o provavelmente o principal meio de tomar decis es e fechar um acordo entre membros de um grupo V rias informa es podem ser alvo de descoberta em um workshop de requisitos dentre elas as influ ncias que interessados t m uns sobre os outros objetivos riscos fronteiras do sistema restri es e atributos de qualidade requisitos n o funcionais e prioridades ALEXANDER BEUS DUKIC 2009 e Quem grupos pequenos at seis participantes tendem a funcionar melhor melhor organizar grupos menores em diferentes workshops do que ter um grupo muito grande As pessoas devem ser convidadas em fun o dos objetivos e das atividades planejadas para o workshop e da contribui o que as pessoas podem dar Especialistas e pessoas com poder de decis o sobre os requisitos s o bons candidatos a participantes WIEGERS 2003 ALEXANDER BEUS DUKIC 2009 e Quando da mesma forma que entrevistas workshops devem ser agendados com anteced ncia em datas acordadas com todos os participantes No que se refere dura o deve se ter em mente que todos
223. icas assume se que toda classe possui implicitamente opera es para se obter os valores correntes de seus atributos e associa es Durante a realiza o de um caso de uso atores geram requisi es para o sistema solicitando a execu o de a es O sistema realiza a es e ele pr prio pode gerar outras requisi es de a o O conjunto de casos de uso tem de ser consistente com o conjunto de requisi es definidas no esquema comportamental do sistema 7 2 Diagramas de Gr fico de Estados Todo objeto tem um tempo de vida Na cria o o objeto nasce na destrui o ele deixa de existir Entre esses dois momentos um objeto poder interagir com outros objetos enviando e recebendo mensagens BOOCH RUMBAUGH JACOBSON 2006 Essas intera es representam o comportamento do objeto e ele pode ser vari vel ao longo do ciclo Engenharia de Requisitos Notas de Aula Cap tulo 7 Modelagem Din mica Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 142 de vida do objeto Ou seja muitas vezes o comportamento dos objetos de uma classe depende do estado em que o objeto se encontra em um dado momento Nestes casos til especificar o comportamento usando uma m quina de estados Classes com estados ou classes modais s o classes cujas inst ncias podem mudar de um estado para outro ao longo de sua exist ncia mudando possivelmente sua estrutura seus valores de atributos ou comportamento dos m todo
224. iciente e de qualidade e Modele com um prop sito para que um certo diagrama seja elaborado deve se ter uma finalidade em mente Um diagrama deve ser til para comunicar informa es para clientes e usu rios ajudando a se obter um entendimento comum dos requisitos ou deve ajudar desenvolvedores a compreender melhor algum aspecto Engenharia de Requisitos Notas de Aula Cap tulo 8 Qualidade e Agilidade em Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 163 de software Com base na meta estabelecida deve se escolher o tipo de diagrama mais apropriado para atingir a meta e o n vel de detalhe a ser utilizado Use m ltiplos modelos h muitos modelos diagramas e n veis de descri o nota o que podem ser usados descrever sistemas de software Contudo normalmente apenas um pequeno subconjunto deles essencial para a maioria dos projetos Assim para que a elabora o de um certo diagrama se justifique ele deve adicionar valor ao projeto Ou seja apenas aqueles diagramas que ofere am valor sua audi ncia alvo devem ser usados Diminua a carga de trabalho Viaje leve cada um dos modelos e diagramas elaborados se conservado ao longo do desenvolvimento precisa ser mantido medida que mudan as nos requisitos acontecem Isso representa trabalho para a equipe e portanto toda vez que se decide conservar um modelo est se comprometendo a agilidade em prol da conveni ncia de se t
225. idade de levantamento de requisitos dominada por fatores humanos sociais e organizacionais e envolve pessoas com diferentes conhecimentos e objetivos o que a torna complexa Christel e Kang apud PRESSMAN 2006 citam alguns problemas que tornam o levantamento de requisitos uma tarefa dif cil Problemas de escopo as fronteiras do sistema s o mal definidas ou os clientes usu rios especificam detalhes t cnicos desnecess rios que podem confundir em vez de esclarecer os objetivos globais do sistema Problemas de entendimento Os clientes usu rios n o est o completamente certos do que necess rio t m pouca compreens o das capacidades e limita es de um ambiente computacional n o t m pleno entendimento do dom nio do problema t m dificuldade de comunicar suas necessidades omitem informa o que acreditam ser bvia especificam requisitos que conflitam com as necessidades de outros clientes usu rios ou especificam requisitos que s o amb guos ou imposs veis de testar Problemas de volatilidade Os requisitos mudam ao longo do tempo Engenharia de Requisitos Notas de Aula Cap tulo 2 Engenharia de Requisitos de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 12 Kotonya e Sommerville 1998 destacam outras dificuldades que complementam e refor am os problemas apontados por Christel e Kang a saber e Pode ser dif cil compreender e coletar informa es quando existem muitos te
226. idade devem estar consistentes com o diagrama de classes e suas descri es no dicion rio de projeto H4 Diagrama de Estados x Diagrama de Classes Os seguintes aspectos devem ser verificados nas rela es entre diagramas de estados e diagramas de classes a Um diagrama de estados deve estar relacionado a uma classe modelada no diagrama de classes b A classe correspondente no diagrama de classes deve conter atributos associa es e ou opera es capazes de indicar todos os estados pelos quais um objeto da mesma pode passar H5 Diagrama de Estados x Descri es de Casos de Uso Os seguintes aspectos devem ser verificados nas rela es entre descri es de casos de uso e diagramas de estados a Os eventos associados a transi es entre estados em um diagrama de estados devem corresponder a fluxos de eventos ou a casos de uso em uma descri o de casos de uso b Quando pertinente a descri o de caso de uso deve fazer uma men o expl cita transi o para o novo estado H6 Diagrama de Atividades x Descri es de Casos de Uso Os seguintes aspectos devem ser verificados nas rela es entre descri es de casos de uso e diagramas de atividades a Um diagrama de atividades deve mostrar as atividades no contexto de um fluxo de eventos descrito em uma descri o de casos de uso Cursos alternativos de exce o ou variantes devem ser mostrados no mesmo diagrama de atividades b A sequ ncia de at
227. ilh o Figura 3 4 Exemplo de rvore de Decis o Engenharia de Requisitos Notas de Aula Cap tulo 3 Levantamento de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 62 Tratamento de Clientes Volume de Neg cios gt R 1 milh o SIS SIN Atraso de pagamento registrado NIS S Tempo de trabalho gt 20 anos SIN Tratamento Priorit rio XIX Tratamento Normal XIX Figura 3 5 Exemplo de Tabela de Decis o Infer ncias s o regras que derivam novos fatos a partir de outros fatos ou c lculos S o normalmente escritas no padr o se ent o como as regras ativadoras de a o mas a cl usula ent o implica um fato ou nova informa o e n o uma a o a ser tomada Ex Se o usu rio n o devolve um livro dentro do prazo estabelecido ent o ele torna se um usu rio inadimplente Computa es s o regras de neg cio que definem c lculos a serem realizados usando algoritmos ou f rmulas matem ticas espec ficos Podem ser expressas como f rmulas matem ticas descri o textual tabelas etc Ex Multa Valor de Loca o N mero de Dias de Atraso Ao contr rio de requisitos funcionais e n o funcionais regras de neg cio n o s o pass veis de serem capturadas por meio de perguntas simples e diretas tal como Quais s o suas regras de neg cio Regras de neg cio emergem durante a discuss o de requisitos sob
228. inidos S o exemplos de tipos de dados espec ficos CPF ISBN de livros endere o etc Neste texto s o considerados os seguintes tipos de dados primitivos e String cadeia de caracteres e boolean admite apenas os valores verdadeiro e falso e Integer ou int n meros inteiros e Float ou float n meros reais e Currency valor em moeda reais d lares etc e Date datas com informa o de dia m s e ano e Time horas em um dia com informa o de hora minuto e segundo e DateTime combina o dos dois anteriores e YearMonth informa o de tempo contendo apenas m s e ano e Year informa o de tempo contendo apenas ano 6 2 1 Atributos Um atributo uma informa o de estado para a qual cada objeto em uma classe tem o seu pr prio valor Os atributos adicionam detalhes s abstra es e s o apresentados na parte central do s mbolo de classe Conforme discutido anteriormente atributos possuem um tipo de dado que pode ser primitivo ou espec fico de dom nio Ao identificar um atributo como sendo relevante deve se definir qual o seu tipo de dado Caso nenhum dos tipos de dados primitivos se aplique deve se definir ent o um tipo de dados espec fico Por exemplo em dom nios que lidem com livros necess rio definir o tipo ISBN cujas inst ncias s o ISBNs v lidos Em dom nios que lidem com pessoas f sicas e jur dicas CPF e CNPJ tamb m devem ser definidos como tipos de dados espec
229. inir como escala de medi o o tempo gasto para dominar a execu o de certas tarefas A partir disso pode se estabelecer como crit rio de aceita o o seguinte Novos bibliotec rios devem ser capazes de efetuar empr stimos ap s a quarta tentativa de realizar essa tarefa usando o sistema Determinar crit rios de ajuste ou crit rios de aceita o ajuda a clarear um requisito Ao se estabelecer uma escala de medi o e os valores aceit veis o requisito transformado de uma inten o vaga e at certo ponto amb gua em um requisito mensur vel e bem formado Estabelecida uma escala pode se perguntar ao usu rio o que ele considera uma falha em atender ao requisito de modo a definir o crit rio de aceita o Contudo pode ser dif cil sen o imposs vel obter um requisito completo e mensur vel em primeira inst ncia ROBERTSON ROBERTSON 2006 Assim na descri o de requisitos de usu rio pode ser suficiente capturar a inten o e depois na especifica o de requisitos de sistema transformar essa inten o em um requisito mensur vel adicionando a ele um crit rio de ajuste muito comum que neste processo um requisito n o funcional de usu rio d origem a v rios requisitos n o funcionais de sistema Leitura Complementar Em KOTONYA SOMMERVILLE 1998 o Cap tulo 3 Requirements Elicitation and Analysis trata do processo de levantamento de requisitos discutindo tamb m de forma breve algumas t
230. isito N o Funcional RNFO01 A funcionalidade Efetuar Loca o de Item deve ser f cil de aprender Medida Descri o Facilidade de aprender a realizar uma tarefa em uso Facilidade de a na Aprendizagem Prop sito Quanto tempo o usu rio leva para aprender a realizar uma tarefa gt de fun o Ease especificada eficientemente of function M todo de Observar o comportamento do usu rio desde quando ele come a a learn ISO IEC Aplica o aprender at quando ele come a a operar eficientemente 2003a f Medi o T soma do tempo de opera o do usu rio at que ele consiga realizar a tarefa em um tempo especificado tempo requerido para aprender a opera o para realizar a tarefa Crit rio de T lt 15 minutos considerando que o usu rio est operando o sistema eficientemente Aceita o quando a tarefa Efetuar Loca o realizada em um tempo inferior a 2 minutos 4 6 O Documento de Especifica o de Requisitos Os requisitos de sistema assim como foi o caso dos requisitos de usu rio t m de ser especificados em um documento de modo a poderem ser verificados e validados e posteriormente usados como base para as atividades subsequentes do desenvolvimento de software O Documento de Especifica o de Requisitos tem como prop sito registrar os requisitos escritos a partir da perspectiva do desenvolvedor e portanto deve incluir os v rios modelos conce
231. isitos v o sendo detalhados eles devem ser modelados e especificados O levantamento preliminar de requisitos tem por objetivo prover uma vis o do todo para se poder definir o que mais importante e depois dividir o todo em partes para especificar os detalhes Nessa fase o levantamento r pido e gen rico sendo feito em extens o e n o em profundidade i e o analista deve entender a extens o do que o sistema deve fazer mas sem entrar em detalhes Somente nos ciclos iterativos os requisitos ser o detalhados especificados e modelados WAZLAWICK 2004 O levantamento preliminar de requisitos inicia se com uma declara o de alto n vel informal e incompleta da miss o do projeto Essa declara o pode ser apresentada na forma de um conjunto de metas fun es e restri es fundamentais para o sistema ou como uma explica o sobre os problemas a serem resolvidos Esses resultados preliminares formam a base para investiga o adicional e para o refinamento dos requisitos de maneira tipicamente iterativa e incremental Assim o levantamento de requisitos pode ser visto como um processo realizado de forma incremental ao longo de m ltiplas sess es iterativamente em dire o a n veis de detalhe cada vez maiores e pelo menos parcialmente em paralelo com outras atividades do processo de software AURUM WOHLIN 2005 O levantamento de requisitos envolve um conjunto de atividades que deve permitir a comunica o prioriza o n
232. ituais desenvolvidos bem como a especifica o dos requisitos n o funcionais detalhados Diferentes formatos podem ser propostos para documentos de especifica o requisitos bem como mais de um documento pode ser usado para documentar os requisitos de sistema Neste texto prop e se o uso de um nico documento contendo as seguintes informa es 1 Introdu o breve introdu o ao documento descrevendo seu prop sito e estrutura 2 Modelo de Casos de Uso apresenta o modelo de casos de uso do sistema incluindo os diagramas de casos de uso e as descri es de casos de uso associadas 3 Modelo Estrutural apresenta o modelo conceitual estrutural do sistema incluindo os diagramas de classes do sistema 4 Modelo Din mico apresenta os modelos comportamentais din micos do sistema incluindo os diagramas de estados diagramas de intera o e diagramas de atividades 5 Dicion rio do Projeto apresenta as defini es dos principais conceitos capturados pelos diversos modelos e restri es de integridade a serem consideradas servindo como um gloss rio do projeto 6 Especifica o dos Requisitos N o Funcionais apresenta os requisitos n o funcionais descritos no n vel de sistema o que inclui crit rios de aceita o E importante frisar que dificilmente um sistema simples o bastante para ser modelado como um todo Quase sempre til dividir um sistema em unidades menores mais Engenharia de Requisitos Notas
233. ity Software Quality Attributes discute a parte dos requisitos n o funcionais relacionadas a atributos de qualidade de produto de software Finalmente o Cap tulo 13 Risk Reduction Through Prototyping dedicado prototipagem Em ROBERTSON ROBERTSON 2006 h tamb m v rios cap tulos que abordam temas discutidos nestas notas de aula Sugere se em especial a leitura dos cap tulos 5 7 8 9 10 e 12 O Cap tulo 5 Trawling the Requirements aborda a coleta de requisitos discutindo diversas t cnicas de levantamento de requisitos dentre elas entrevistas workshops de requisitos brainstorming e investiga o de documentos O Cap tulo 7 Functional Requirements aborda a captura e descri o de requisitos funcionais enquanto o Cap tulo 8 Nonfunctional Requirements aborda requisitos n o funcionais O Cap tulo 9 Fit Criteria trata da defini o de crit rios de ajuste para complementar a descri o de requisitos tornando os mensur veis e test veis O Cap tulo 10 Writing the Requirements discute a documenta o de requisitos tomando por base o modelo de documento de especifica o de requisitos Volere proposto pelos autores Finalmente o Cap tulo 12 Prototyping the Requirements dedicado prototipagem O Cap tulo 2 de AURUM WOHLIN 2005 Requirements Elicitation A Survey of Techniques Approaches and Tools mais especificamente sua se o 2 3 Techniques and
234. ividades em um diagrama de atividades deve estar consistente com a sequ ncia de passos da descri o do caso de uso correspondente Engenharia de Requisitos Notas de Aula Cap tulo 8 Qualidade e Agilidade em Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 162 H7 Diagrama de Atividade x Diagrama de Classes Os seguintes aspectos devem ser verificados nas rela es entre diagramas de atividades e diagramas de classes a Todos os objetos em um diagrama de atividades devem ter a indica o de a qual classe pertencem Essas classes devem estar modeladas no diagrama de classes b Algumas atividades em um diagrama de atividades tipicamente aquelas que apontam um processamento a ser feito pelo sistema podem indicar a necessidade de uma opera o na classe de um dos objetos que s o entrada para essa atividade Quando este for o caso a opera o deve ser mostrada na classe correspondente do diagrama de classes H8 Diagrama de Atividade x Diagrama de Estados Os seguintes aspectos devem ser verificados nas rela es entre diagramas de atividades e diagramas de estados a Quando um objeto em um diagrama de atividades tiver o seu estado indicado e houver um diagrama de estados para a classe desse objeto ent o os estados devem estar consistentes inclusive em rela o ao evento que altera o estado do objeto 8 2 Modelagem gil Ao contr rio da modelagem conceitual estrutural em q
235. j iniciar a elabora o desses diagramas Assim as atividades mostradas na Figura 4 1 s o fortemente paralelas e iterativas Paralelamente a todas as atividades de modelagem o documento de especifica o de requisitos deve ir sendo elaborado Mesmo a verifica o e a valida o podem ser feitas por partes e n o para o documento como um todo Por exemplo bastante comum validar primeiro somente os casos de uso Verifica es de consist ncia tais como as feitas entre casos de uso e classes ou casos de uso diagramas de intera o e diagramas de classes podem ser feitas separadamente uma das outras Assim as atividades de documenta o verifica o e valida o s o atividades cont nuas que ocorrem paralelamente modelagem conceitual 4 5 Especifica o de Requisitos N o Funcionais Assim como os requisitos funcionais precisam ser especificados em detalhes o mesmo acontece com os requisitos n o funcionais Para os atributos de qualidade considerados priorit rios o analista deve trabalhar no sentido de especific los de modo que eles se tornem mensur veis e por conseguinte test veis Para cada atributo de qualidade devem se definir as medidas a serem usadas indicando a unidade da medida e sua escala e os valores m nimo alvo e m ximo Pode se ainda perguntar aos usu rios o que constituiria um valor inaceit vel para o atributo e definir testes que tentem for ar o sistema a demonstrar tais caracter sticas
236. lidade capacidade do produto de software de permitir ao usu rio compreender se o software se aplica a suas necessidades e como ele pode ser usado para determinadas tarefas e condi es de uso o Apreensibilidade capacidade do produto de software de permitir ao usu rio aprender sua aplica o o Operacionalidade capacidade do produto de software de permitir o usu rio oper lo e control lo o Atratividade capacidade do produto de software de ser atrativo ao usu rio e Ffici ncia diz respeito capacidade do produto de software de fornecer desempenho apropriado relativo quantidade de recursos usados sob condi es especificadas Tem como subcaracter sticas o Comportamento em rela o ao tempo capacidade do produto de software de fornecer tempo de resposta e tempo de processamento apropriados e taxas de throughput quando executando suas fun es sob condi es estabelecidas o Comportamento em rela o aos recursos capacidade do produto de software de usar quantidade e tipos de recursos apropriados quando o software executa suas fun es sob condi es estabelecidas e Manutenibilidade concerne ao esfor o necess rio para se fazer modifica es no software Tem como subcaracter sticas o Analisabilidade capacidade do produto de software de permitir o diagn stico de defici ncias ou causas de falhas no software ou a identifica o de partes a serem modificadas o Modificabilidade capacidade do produto
237. lizada e Valida o dos achados envolve submeter o registro das informa es obtidas para avalia o pelas pessoas que participaram da atividade de levantamento de requisitos A seguir algumas das t cnicas citadas anteriormente s o apresentadas Engenharia de Requisitos Notas de Aula Cap tulo 3 Levantamento de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 34 3 2 1 Entrevistas Entrevistas s o provavelmente a t cnica mais comumente utilizada no levantamento de requisitos AURUM WOHLIN 2005 Uma entrevista uma conversa direcionada com um prop sito espec fico que utiliza um formato pergunta resposta KENDALL KENDALL 2010 Entrevistas s o usadas em quase todos os esfor os de levantamento de requisitos Nelas os analistas formulam quest es para os interessados e os requisitos s o derivados das respostas a essas perguntas SOMMERVILLE 2007 Uma entrevista feita tipicamente por meio de uma reuni o envolvendo o analista entrevistador e um interessado no sistema entrevistado Assim um m todo interativo de levantamento de requisitos a partir de um indiv duo Contudo uma entrevista pode envolver mais de um entrevistador e mais de um entrevistado Uma entrevista pode ser por exemplo realizada por dois entrevistadores um fazendo a maior parte das perguntas enquanto o outro registra as informa es obtidas e presta aten o em requisitos possivelmente per
238. lmente implementado e Rastre vel deve ser poss vel identificar quais requisitos foram tratados em um determinado artefato bem como identificar que produtos foram originados a partir de um requisito Neste contexto til WIEGERS 2003 Engenharia de Requisitos Notas de Aula Cap tulo 2 Engenharia de Requisitos de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 18 e Realizar revis es dos documentos de requisitos procurando por problemas conflitos omiss es inconsist ncias desvios dos padr es etc e discutindo solu es e Definir casos de teste para os requisitos especificados e Definir crit rios de aceita o de requisitos 1 e os usu rios devem descrever como v o determinar se o produto atende s suas necessidades e se adequado para uso De maneira geral i e sem estarem restritas a requisitos as atividades de V amp V envolvem an lises est ticas e din micas A an lise din mica ou testes objetiva detectar defeitos ou erros no software por meio da execu o do produto J a an lise est tica n o envolve a execu o do produto sendo feita por meio de revis es dos artefatos a serem avaliados ROCHA MALDONADO WEBER 2001 No caso de requisitos podem se realizar revis es dos documentos de requisitos para avaliar requisitos e modelos an lise est tica bem como poss vel utilizar prototipagem para validar requisitos an lise din mica A an lise
239. lo ao se estabelecer uma matriz de rastreabilidade casos de uso gt classes indicando que classes de um modelo de an lise s o necess rias para se tratar um caso de uso poss vel em conjunto com uma matriz de rastreabilidade requisitos de usu rio gt casos de uso saber que classes s o importantes no tratamento de um requisito de usu rio Davis apud KOTONYA SOMMERVILLE 1998 aponta quatro tipos de rastreabilidade interessantes para que uma an lise de impacto de mudan as possa ser feita mais facilmente como ilustra a Figura 2 4 Rastreabilidade regressiva Rastreabilidade progressiva a partir dos requisitos a partir dos requisitos Outros Artefatos ao o Projeto Design Fonte do Requisito Requisitos C digo Testes etc Rastreabilidade progressiva Rastreabilidade regressiva em dire o aos requisitos em dire o aos requisitos Figura 2 4 Tipos de Rastreabilidade Engenharia de Requisitos Notas de Aula Cap tulo 2 Engenharia de Requisitos de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 23 e Regressiva a partir dos requisitos backward from traceability relaciona requisitos com suas origens outros documentos ou pessoas e Progressiva a partir dos requisitos forward from traceability relaciona requisitos aos artefatos do projeto planos modelos de an lise e projeto c digo etc e Regressiva em dire o aos requisitos backward to traceability relacio
240. lo 4 An lise de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 70 Cap tulo 4 An lise de Requisitos Requisitos de usu rio resultam diretamente da atividade de levantamento de requisitos sendo tipicamente descritos em linguagem natural em um n vel pequeno de detalhes Assim uma vez identificados os requisitos de usu rio necess rio detalh los colocando os no n vel de descri o de requisitos de sistema Este o prop sito da an lise de requisitos Requisitos de sistema resultam dos esfor os dos analistas de organizar e detalhar requisitos de usu rio envolvendo a elabora o de um conjunto de modelos abstratos do sistema agora em um n vel alto de detalhes A correta deriva o de requisitos de sistema a partir de requisitos de usu rio fundamental para assegurar que nenhum equ voco arbitrariamente introduzido pelos analistas durante o processo de especifica o de requisitos AURUM WOHLIN 2005 Durante a an lise de requisitos requisitos funcionais e n o funcionais devem ser expressos em um n vel de detalhes que permita guiar as etapas subsequentes do desenvolvimento de software projeto implementa o e testes Al m disso aten o especial deve ser dada s regras de neg cio Elas t m de ser capturadas e incorporadas s funcionalidades do sistema Para descrever requisitos funcionais detalhadamente na maioria das vezes necess rio produzir um conjunto de
241. m quinas de estados Apenas classes modais i e classes que apresentam comportamento vari vel em fun o do estado de seus objetos necessitam ser modeladas como m quinas de estados Al m disso para os diagramas de estados serem efetivamente teis recomenda se modelar uma m quina de estados somente se a classe em quest o tiver tr s ou mais estados relevantes Se uma classe possuir apenas dois estados relevantes ainda cabe desenvolver uma m quina de estados Contudo de maneira geral o diagrama tende a ser muito simples e a acrescentar pouca informa o relevante que justifique o esfor o de elabora o e manuten o do correspondente diagrama Neste caso os estados e transi es podem ser levantados sem no entanto ser elaborado um diagrama de estados Para algumas classes pode ser til desenvolver mais do que um diagrama de estados cada um deles modelando o comportamento dos objetos da classe por uma perspectiva diferente Em um determinado momento um objeto est em um e somente um estado em cada uma de suas m quinas de estado Cada diagrama define seu pr prio conjunto de estados nos quais um objeto pode estar a partir de diferentes pontos de vista OLIV 2007 Seja novamente o exemplo da classe Carro A Figura 7 4 mostra os poss veis estados de um carro segundo um ponto de vista de disponibilidade Entretanto independentemente da disponibilidade do ponto de vista de possibilidade de negocia o um carro pode estar
242. m os resultados n o interessa ao cozinheiro A Figura 2 5 ilustra o conceito de encapsulamento Estrutura Interna Termostato de cora obe do keno Fus vet t rimos Bandeja do migahas imeri principal Trea Interface Figura 2 5 Ilustra o do Conceito de Encapsulamento O encapsulamento consiste na separa o dos aspectos externos de um objeto acess veis por outros objetos de seus detalhes internos de implementa o que ficam ocultos dos demais objetos BLAHA RUMBAUGH 2006 A interface de um objeto deve ser definida de forma a revelar o menos poss vel sobre o seu funcionamento interno Abstra o e encapsulamento s o conceitos complementares enquanto a abstra o enfoca o comportamento observ vel de um objeto o encapsulamento oculta a implementa o que origina esse comportamento Encapsulamento frequentemente conseguido atrav s da oculta o de informa o isto escondendo detalhes que n o contribuem para suas caracter sticas essenciais Tipicamente em um sistema orientado a objetos a estrutura de um objeto e a implementa o de seus m todos s o encapsuladas BOOCH 1994 Assim o encapsulamento serve para separar a interface contratual de uma abstra o e sua implementa o Os usu rios t m conhecimento apenas das opera es que podem ser requisitadas e precisam estar cientes apenas do qu as opera es realizam e n o como elas est o implementadas A principal motiva
243. m prot tipo do sistema desenvolvido para demonstrar requisitos fica mais f cil para usu rios e outros interessados encontrar problemas e sugerir como os requisitos podem ser melhorados Afinal criticar mais f cil do que criar XOTONYA SOMMERVILLE 1998 WIEGERS 2003 Um prot tipo uma vers o inicial do sistema que desenvolvido no in cio do processo de desenvolvimento No contexto da engenharia de requisitos um prot tipo desenvolvido com o prop sito de apoiar o levantamento e a valida o de requisitos Assim nesse contexto uma caracter stica essencial de um prot tipo que ele seja desenvolvido rapidamente KOTONYA SOMMERVILLE 1998 Engenharia de Requisitos Notas de Aula Cap tulo 3 Levantamento de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 49 A prototipagem uma t cnica valiosa para o levantamento de requisitos Ela torna os requisitos mais reais e diminui lacunas de entendimento Ao colocar o usu rio na frente de uma por o inicial ou uma imita o do sistema a prototipagem estimula os usu rios a pensar e a estabelecer um di logo sobre os requisitos As considera es tecidas sobre o prot tipo ajudam a se obter um entendimento compartilhado dos requisitos WIEGERS 2003 Al m disso a prototipagem muito til quando os interessados est o pouco familiarizados com as solu es dispon veis AURUM WOHLIN 2005 Este o caso por exemplo da introd
244. m ser usados para quantificar o que foi levantado usando outras t cnicas de levantamento e portanto um question rio pode ser definido com base no que foi levantado preliminarmente por exemplo em uma entrevista Question rios tamb m podem ser usados para examinar uma grande amostra de usu rios do sistema para sentir problemas ou levantar quest es importantes antes de se programar entrevistas KENDALL KENDALL 2010 Observa o pode ser usada para confirmar ou refutar informa es levantadas em entrevistas workshops de requisitos e ou question rios bem como para capturar informa o complementar sobre os interessados seus processos de neg cio e o seu ambiente de trabalho De maneira inversa podem se utilizar outras t cnicas para completar informa es obtidas em uma observa o Engenharia de Requisitos Notas de Aula Cap tulo 3 Levantamento de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 54 A observa o pode ser combinada tamb m com a prototipagem Uma vez constru do um prot tipo podem se observar os usu rios utilizando o prot tipo de modo a avaliar o mesmo e derivar novos requisitos Para capturar as rea es dos usu rios em rela o ao prot tipo outras t cnicas de levantamento de requisitos tamb m podem ser usadas tais como entrevistas e question rios para capturar opini es e sugest es Por fim cen rios podem ser usados para derivar prot tipos e prot tipos p
245. mais de uma comiss o simultaneamente e portanto trata se uma rela o de agrega o Na UML um losango branco na extremidade da associa o relativa ao todo indica uma agrega o J um losango preto indica uma composi o E Leem 0 2r Figura 6 15 Agrega o e Composi o Rela es todo parte podem ser empregadas em situa es como e Quando h clareza de que um objeto complexo composto de outros objetos componente de Ex Motor um componente de um carro e Para designar membros de cole es membro de Ex Pesquisadores s o membros de Grupos de Pesquisa Muitas vezes pode ser dif cil perceber a diferen a entre uma agrega o composi o e uma associa o comum Quando houver essa d vida melhor representar a situa o usando uma associa o comum tendo em vista que ela imp e menos restri es 6 3 Especifica o de Hierarquias de Generaliza o Especializa o Um dos principais mecanismos de estrutura o de conceitos a generaliza o especializa o Com este mecanismo poss vel capturar similaridades entre classes dispondo as em hierarquias de classes No contexto da orienta o a objetos esse tipo de relacionamento tamb m conhecido como heran a importante notar que a heran a tem uma natureza bastante diferente das associa es Associa es representam poss veis liga es entre inst ncias das classes envolvidas J a rela o de heran
246. mens es devem ser consideradas como ilustra a Figura 2 2 KOTONYA SOMMERVILLE 1998 Engenharia de Requisitos Notas de Aula Cap tulo 2 Engenharia de Requisitos de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 11 Levantamento de requisitos Problema a ser solucionado Dominio da Aplica o Necessidades e restri es dos envolvidos Contexto do neg cio Figura 2 2 Dimens es do levantamento de requisitos Entendimento do dom nio da aplica o entendimento geral da rea na qual o sistema ser aplicado Entendimento do problema entendimento dos detalhes do problema espec fico a ser resolvido com o aux lio do sistema a ser desenvolvido Entendimento do neg cio entender como o sistema ir afetar a organiza o e como contribuir para que os objetivos do neg cio e os objetivos gerais da organiza o sejam atingidos Entendimento das necessidades e das restri es dos interessados entender as demandas de apoio para a realiza o do trabalho de cada um dos interessados no sistema entender os processos de trabalho a serem apoiados pelo sistema e o papel de eventuais sistemas existentes na execu o e condu o dos processos de trabalho Consideram se interessados no sistema todas as pessoas que s o afetadas pelo sistema de alguma maneira dentre elas clientes usu rios finais e gerentes de departamentos onde o sistema ser instalado A ativ
247. mento t cnico e Requisitos de Sistema definem detalhadamente as fun es servi os e restri es do sistema S o vers es expandidas dos requisitos de usu rio usados pelos desenvolvedores para projetar implementar e testar o sistema Como requisitos de sistema s o mais detalhados as especifica es em linguagem natural s o insuficientes e para especific los nota es mais especializadas devem ser utilizadas Vale destacar que esses n veis de descri o de requisitos s o aplicados em momentos diferentes e com prop sitos distintos Requisitos de usu rio s o elaborados nos est gios iniciais do desenvolvimento levantamento preliminar de requisitos e servem de base para um entendimento entre clientes e desenvolvedores acerca do que o sistema deve contemplar Esses requisitos s o normalmente usados como base para a contrata o e o planejamento do projeto Requisitos de sistema por sua vez s o elaborados como parte dos esfor os diretos para o desenvolvimento do sistema capturando detalhes importantes para as fases t cnicas posteriores do processo de desenvolvimento a saber projeto implementa o e testes Entretanto n o se deve perder de vista que requisitos de sistema s o derivados dos requisitos de usu rio Os requisitos de sistema acrescentam detalhes explicando os servi os e fun es a serem providos pelo sistema em desenvolvimento Os interessados nos requisitos de sistema necessitam conhecer mais precisam
248. modelos cada um deles capturando uma perspectiva diferente do sistema A linguagem natural ainda utilizada mas em uma escala reduzida circunscrita a descri es de certos modelos ou s defini es em gloss rios ou dicion rios de dados Grande parte das informa es tratadas na an lise de requisitos funcionais melhor comunicada por meio de diagramas do que por meio de texto Assim a modelagem conceitual uma atividade essencial da an lise de requisitos A modelagem conceitual visa definir em detalhes as fun es requeridas pelo sistema e o conhecimento necess rio para realiz las O produto principal da modelagem conceitual o esquema conceitual do sistema OLIV 2007 O esquema ou modelo conceitual de um sistema captura as fun es e informa es que o sistema deve prover e gerenciar Ele deve ser concebido com foco no dom nio do problema e n o no dom nio da solu o mas deve tratar tanto uma vis o externa do sistema como o sistema percebido pelos usu rios quanto uma vis o interna do mesmo como as abstra es do dom nio s o representadas e relacionadas Os termos an lise de sistemas e an lise de requisitos s o muitas vezes empregados para designar as atividades de modelagem conceitual an lise de requisitos funcionais Assim a maioria dos m todos de an lise de sistemas concentra se na an lise de requisitos funcionais nada falando sobre a an lise de requisitos n o funcionais Entretanto durante
249. momento levantada apenas uma lista de exce es e varia es que podem ocorrer no fluxo principal de eventos do caso de uso sem no entanto definir como o sistema deve trat las 9 Descrever os passos dos fluxos alternativos descrever como o sistema deve responder a cada exce o ou como ele deve funcionar em cada varia o Vale ressaltar que a descri o de casos de uso na fase de an lise de requisitos deve ser feita sem considerar a tecnologia de interface Neste momento n o interessa saber a forma das interfaces do sistema mas quais informa es s o trocadas entre o sistema e o ambiente externo atores O analista deve procurar abstrair a tecnologia e se concentrar na ess ncia das informa es trocadas Assim diz se que a descri o de caso de uso na fase de an lise uma descri o essencial A tecnologia de interface ser objeto da fase de projeto do sistema Agindo dessa maneira abre se caminho para se pensar em diferentes alternativas de interfaces durante o projeto do sistema WAZLAWICK 2004 Uma t cnica de levantamento de requisitos bastante til para apoiar a escrita de casos de uso s o os cen rios Pode se pedir para que o usu rio descreva alguns cen rios na forma de exemplos situados de um caso de uso em a o mostrando o ator usando o sistema para realizar o caso de uso em quest o COCKBURN 2005 Um cen rio uma sequ ncia espec fica de a es que ilustra o comportamento de um caso de uso As
250. mpo elaborando diagramas que acrescentam pouco valor ao projeto N o se deve perder de vista que o prop sito da modelagem ajudar a entender o problema de modo que se possa produzir um sistema que atenda s necessidades do usu rio Produzir artefatos desnecess rios transforma o trabalho de Engenharia de Software em burocracia de software Para tratar essa quest o primeiro deve se considerar a tica da qualidade Sob esse ponto de vista fundamental garantir consist ncia entre os diversos artefatos produzidos Os diversos documentos e modelos proveem diferentes vis es de um mesmo sistema e portanto devem estar compat veis entre si importante observar que os modelos produzidos envolvem conceitos comuns dentre eles classes objetos e opera es e que essencial manter as informa es rastre veis Ambos os modelos estrutural e comportamental s o necess rios para um completo entendimento de um problema embora a import ncia de cada um dos diagramas envolvidos varie de projeto para projeto e em fun o do tipo de aplica o a ser desenvolvida Esses modelos se unem para dar forma s classes com atributos associa es e opera es que ser o a base para o projeto e a implementa o Em especial as opera es envolvem dados objeto destino argumentos vari veis e retorno controle sequ ncia e intera es mensagens e chamadas Assim para uma completa especifica o das classes o Engenharia de Requisitos
251. n o altera o estado do dom nio ela apenas prov a informa o solicitada pelos usu rios e Fun o Ativa o sistema pode realizar a es que modificam o estado do dom nio Para realizar essa fun o o sistema precisa conhecer as a es que ele pode tomar quando elas devem ser tomadas e como elas v o afetar o estado do dom nio Todos os sistemas de informa o convencionais realizam pelo menos as fun es de mem ria e informativa Para ser capaz de realizar suas fun es um sistema tem de ter um conhecimento geral sobre o dom nio da aplica o e sobre as funcionalidades que ele deve executar Na rea de sistemas de informa o esse conhecimento denominado de esquema conceitual OLIV 2007 O modelo conceitual de um sistema tipicamente composto de v rios modelos cada um deles enfocando uma perspectiva diferente mas guardando alguma rela o com outros modelos Os diferentes tipos de modelos conceituais podem ser agrupados em duas grandes categorias e Modelos Estruturais procuram capturar os principais conceitos do dom nio suas rela es e propriedades que s o relevantes para o sistema que se est desenvolvendo Abstra o um mecanismo chave e a defini o do que relevante definido com base no prop sito do sistema Dentre os tipos de modelos estruturais destacam se o Modelo de Entidades e Relacionamentos e o Diagrama de Classes na Orienta o a Objetos e Modelos Comportamentais especifi
252. n o deve ser considerada em um modelo conceitual estrutural Tipicamente uma classe possui v rias inst ncias e a popula o da classe varia ao longo do tempo 6 2 Identifica o de Atributos e Associa es Conforme apontado anteriormente uma classe t pica de um modelo conceitual estrutural deve apresentar estrutura complexa A estrutura de uma classe corresponde a seus atributos e associa es Conceitualmente n o h diferen a entre atributos e associa es Atributos s o na verdade tipos de relacionamentos bin rios Em um tipo de relacionamento bin rio h dois participantes Em alguns tipos de relacionamentos esses participantes s o considerados colegas porque eles desempenham fun es an logas e nenhum deles subordinado ao outro Seja o caso do tipo de relacionamento aluno cursa um curso Um aluno s aluno se cursar um curso Por outro lado n o faz sentido existir um curso se ele n o puder ser cursado por alunos A ordem dos participantes no modelo n o implica uma rela o de prioridade ou subordina o entre eles OLIV 2007 Na orienta o a objetos esse tipo de relacionamento modelado como uma associa o Entretanto h alguns tipos de relacionamentos nos quais usu rios e analistas consideram um participante como sendo uma caracter stica do outro Seja o exemplo do tipo de relacionamento filme possui g nero Algu m pode argumentar que o participante g nero uma carac
253. na artefatos do projeto aos requisitos e Progressiva em dire o aos requisitos forward to traceability relaciona as fontes p ex documentos que precederam o documento de requisitos aos requisitos relevantes Embora a rastreabilidade de requisitos n o possa ser completamente automatizada porque o conhecimento das liga es se origina na mente dos membros da equipe de desenvolvimento uma vez identificadas essas liga es ferramentas de apoio s o important ssimas para ajudar a gerenciar a grande quantidade de informa es de rastreabilidade WIEGERS 2003 Requisitos guiam v rias atividades do processo de software dentre elas planejamento projeto design codifica o e testes e portanto esses artefatos devem ser rastre veis para e a partir dos requisitos A seguir s o citadas algumas situa es em diversas etapas nas quais os requisitos s o importantes WIEGERS 2003 e Planejamento de Projeto requisitos s o teis para dimensionar o projeto sendo utilizados para estimar o tamanho do produto Planos devem ser atualizados caso haja mudan as em requisitos e requisitos priorit rios s o usados para direcionar itera es quando modelos de ciclo de vida iterativos s o adotados e Projeto e Codifica o requisitos com destaque para os n o funcionais s o usados para direcionar o projeto da arquitetura do sistema e s o alocados a componentes Mudan as em requisitos devem ser rastreadas para o projeto e o
254. ncionalidade que um sistema pode fornecer para atores interagindo com ele BLAHA RUMBAUGH 2006 Um caso de uso corresponde a um conjunto de a es realizadas pelo sistema ou por meio da intera o com o sistema que produz um resultado observ vel com valor para um ou mais atores do sistema Geralmente esse valor a realiza o de uma meta de neg cio ou tarefa OLIVE 2007 Assim um caso de uso captura alguma fun o vis vel ao ator e em especial busca atingir uma meta desse ator Deve se considerar que um caso de uso corresponde a uma transa o completa ou seja um usu rio poderia ativar o sistema executar o caso de uso e desativar o sistema logo em seguida e a opera o estaria completa e consistente e atenderia a uma meta desse usu rio WAZLAWICK 2004 Ser uma transa o completa uma caracter stica essencial de um caso de uso pois somente transa es completas s o capazes de atingir um objetivo do usu rio Casos de uso que necessitam de m ltiplas sess es n o passam nesse crit rio e devem ser divididos em casos de uso menores Seja o exemplo de um caso de uso de concess o de empr stimo Inicialmente um atendente interagindo com um cliente informa os dados necess rios para a avalia o do pedido de empr stimo O pedido de empr stimo ent o enviado para an lise por um analista de cr dito Uma vez analisado e aprovado o empr stimo concedido quando o dinheiro entregue ao cliente e um contr
255. ndo o grau de adequa o dos requisitos levantados com os processos e objetivos da organiza o CARDOSO ALMEIDA GUIZZARDI 2008 importante real ar que a modelagem de processos de neg cios independe do desenvolvimento de sistemas e pode ser conduzida independentemente para a constru o de uma arquitetura organizacional de refer ncia enterprise architecture Quando necess ria a constru o de um sistema que d apoio a partes dos processos modelados nessa arquitetura necess rio retornar ao cliente somente para levantar requisitos de sistema e n o para levantar requisitos de neg cio CARDOSO ALMEIDA GUIZZARDI 2008 3 4 Escrevendo e Documentando Requisitos de Usu rio Os resultados do levantamento de requisitos t m de ser registrados em um documento de modo que possam ser verificados validados e utilizados como base para outras atividades do processo de software Para que sejam teis os requisitos t m de ser escritos em um formato compreens vel por todos os interessados Al m disso esses interessados devem interpret los uniformemente Normalmente requisitos s o documentados usando alguma combina o de linguagem natural modelos tabelas e outros elementos A linguagem natural quase sempre imprescind vel uma vez que a forma b sica de comunica o compreens vel por todos os interessados Contudo ela geralmente abre espa os para ambiguidades e m interpreta o Assim interessante procura
256. nforma es do contexto do desenvolvimento dentre eles conhecimento acerca da organiza o onde o sistema ser implantado informa es sobre o dom nio da aplica o e informa es sobre sistemas que est o em uso e ser o substitu dos pelo sistema em desenvolvimento e Organizar as informa es levantadas descartando conhecimento irrelevante e priorizando as metas da organiza o Al m disso importante identificar interessados stakeholders e seus pap is na organiza o O envolvimento de clientes e usu rios um fator cr tico para o sucesso do projeto Assim importante engajar representantes deles desde o in cio do projeto Para definir esses representantes deve se WIEGERS 2003 e Identificar diferentes classes de usu rios Usu rios podem ser agrupados por diferentes aspectos tais como i a frequ ncia com que usam o sistema ii experi ncia no dom nio de aplica o e per cia com sistemas computadorizados iii caracter sticas do sistema que eles usam iv tarefas que eles realizam no apoio a seus processos de neg cio e v n veis de privil gio de acesso e seguran a e Selecionar e trabalhar com indiv duos que representem cada grupo de usu rios e Estabelecer um acordo sobre quem ser o as pessoas respons veis por tomar decis es relativas a requisitos sobretudo no que concerne a estabelecer prioridades e resolver conflitos Cada classe de usu rios tem seu pr prio conjunto de requisitos t
257. ngenharia de Requisitos de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 5 Cap tulo 2 Engenharia de Requisitos de Software Requisitos t m um papel central no processo de software sendo considerados um fator determinante para o sucesso ou fracasso de um projeto de software O processo de levantar analisar documentar gerenciar e controlar a qualidade dos requisitos chamado de Engenharia de Requisitos Este cap tulo d uma vis o geral da Engenharia de Requisitos A Se o 2 1 apresenta diferentes defini es do conceito de requisito e trata de tipos e n veis de requisitos A Se o 2 2 aborda o processo de engenharia de requisitos discutindo cada uma de suas atividades Finalmente a Se o 2 3 discute como as principais normas e modelos de qualidade de processos de software tratam a quest o dos requisitos 2 1 Requisitos Existem diversas defini es para requisito de software na literatura dentre elas e Requisitos de um sistema s o descri es dos servi os que devem ser fornecidos por esse sistema e as suas restri es operacionais SOMMERVILLE 2007 e Um requisito de um sistema uma caracter stica do sistema ou a descri o de algo que o sistema capaz de realizar para atingir seus objetivos PFLEEGER 2004 e Um requisito alguma coisa que o produto tem de fazer ou uma qualidade que ele precisa apresentar ROBERTSON ROBERTSON 2006 Com base nessas e em o
258. nhado por entidades f sicas pessoas ou outros sistemas que interagem com o sistema em quest o da mesma maneira procurando atingir os mesmos objetivos Uma mesma entidade f sica pode desempenhar diferentes pap is no mesmo sistema bem como um dado papel pode ser desempenhado por diferentes entidades OLIVE 2007 O uso de diagramas de atividade e de sequ ncia para complementar a especifica o de um caso de uso discutido no Cap tulo 7 7 Algu m ou algo com interesse no comportamento do sistema sob discuss o COCKBURN 2005 Engenharia de Requisitos Notas de Aula Cap tulo 5 Modelagem de Casos de Uso Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 89 Atores s o externos ao sistema Um ator se comunica diretamente com o sistema mas n o parte dele A modelagem dos atores ajuda a definir as fronteiras do sistema isto o conjunto de atores de um sistema delimita o ambiente externo desse sistema representando o conjunto completo de entidades para as quais o sistema pode servir BLAHA RUMBAUGH 2006 OLIV 2007 Uma d vida que sempre passa pela cabe a de um iniciante em modelagem de casos de uso saber se o ator a pessoa que efetivamente opera o sistema p ex o atendente de uma locadora de autom veis ou se a pessoa interessada no resultado do processo p ex o cliente que efetivamente loca o autom vel e atendido pelo atendente Essa defini o depende em ess ncia da f
259. nharia de Requisitos Notas de Aula Cap tulo 2 Engenharia de Requisitos de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 10 visando garantir conformidade em rela o a padr es e ao processo estabelecidos pela organiza o Caso clientes usu rios e desenvolvedores estejam de acordo com os requisitos o processo de desenvolvimento pode avan ar caso contr rio deve se retornar atividade correspondente para resolver os problemas identificados Em paralelo a todas as atividades anteriormente mencionadas h a ger ncia de requisitos que se ocupa em gerenciar mudan as nos requisitos Vale destacar que n o h limites bem definidos entre as atividades acima citadas Na pr tica elas s o intercaladas e existe um alto grau de itera o e feedback entre elas O processo executado at que todos os usu rios estejam satisfeitos e concordem com os requisitos ou at que a press o do cronograma precipite o in cio da fase de projeto o que indesej vel KOTONYA SOMMERVILLE 1998 Al m disso ao se adotar um modelo de ciclo de vida iterativo essas atividades podem ser realizadas muitas vezes Pode se come ar com um levantamento preliminar de requisitos que considere apenas requisitos de usu rio Esses requisitos podem ser documentados em um Documento de Requisitos e avaliados verifica o e valida o Caso haja acordo em rela o aos requisitos de usu rio pode se iniciar um ciclo de le
260. nidade usu ria clientes usu rios e demais interessados O modelo de casos de uso um modelo comportamental mostrando as fun es do sistema mas de maneira est tica Ele composto de dois tipos principais de artefatos os diagramas de casos de uso e as descri es de casos de uso Um diagrama de casos de uso um diagrama bastante simples que descreve o sistema seu ambiente e como sistema e ambiente est o relacionados Assim ele descreve o sistema segundo uma perspectiva externa As descri es dos casos de uso descrevem o passo a passo para a realiza o dos casos de uso e s o essencialmente textuais A modelagem de casos de uso estudada em detalhes no Cap tulo 5 Tomando por base casos de uso e suas descri es poss vel passar modelagem conceitual estrutural quando os conceitos e relacionamentos envolvidos no dom nio s o capturados em um conjunto de diagramas de classes Neste momento importante definir tamb m o significado dos conceitos e de suas propriedades bem como restri es sobre eles Essas defini es s o documentadas em um dicion rio de dados do projeto A modelagem conceitual estrutural o foco do Cap tulo 6 Algumas classes do modelo estrutural apresentam um comportamento dependente de seu estado Para essas classes til elaborar diagramas de estados mostrando os estados pelos quais um objeto da classe pode passar ao longo de sua exist ncia e os eventos que provocam transi es
261. nidos a partir de modelos conceituais de aplica es Ao se criar um modelo conceitual os analistas percebem que muitos aspectos de projetos anteriores se repetem Se ideias usadas em projetos anteriores s o teis atualmente ent o eles melhoram essas ideias e as adaptam para atender a uma nova demanda Para reutilizar um padr o de an lise em outra aplica o preciso reinterpretar cada classe no padr o como uma classe correspondente no novo sistema A estrat gia a abstra o do modelo inicial de onde novos modelos podem ser desenvolvidos Fowler 1997 se refere a padr es de an lise como grupos de conceitos que representam uma constru o comum na modelagem de neg cios Eles podem ser relevantes para somente um dom nio ou podem ser expandidos para v rios dom nios Os padr es de an lise lidam com problemas gerais de modelagem sendo apresentados atrav s de um problema particular em um dom nio onde mais f cil de entend los Conhecendo os s o identificadas in meras situa es onde aplic los No citado livro s o descritos padr es para Engenharia de Requisitos Notas de Aula Cap tulo 8 Qualidade e Agilidade em Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 169 v rios dom nios de neg cios de acordo com a experi ncia pessoal do autor em aplicar modelagem de objetos a sistemas de informa o de grandes corpora es Padr es de maneira geral s o registrados em c
262. nifica que o caso de uso filho herda o comportamento e o significado do caso de uso pai acrescentando ou sobrescrevendo seu comportamento OLIV 2007 BOOCH RUMBAUGH JACOBSON 2006 Na UML relacionamentos de generaliza o especializa o s o representados como uma linha cheia direcionada com uma seta aberta s mbolo de heran a como ilustra a Figura 5 14 Caso de Uso Pai Caso de Uso Filho Figura 5 14 Associa o de Generaliza o Especializa o entre Casos de Uso na UML Voltando ao exemplo do sistema de caixa autom tico suponha que haja duas formas adotadas para se validar o cart o a primeira atrav s de senha como descrito anteriormente e a segunda por meio de an lise da retina do cliente Neste caso poderiam ser criadas duas especializa es do caso de uso Validar Cliente como mostra a Figura 5 15 Validar Cart o Validar Cart o por Autentica o de Senha Validar Cart o por An lise de Retina Figura 5 15 Exemplo de Generaliza o Especializa o entre Casos de Uso A descri o do caso de uso pai teria de ser generalizada para acomodar diferentes tipos de valida o Esses tipos de valida o seriam especializados nas descri es dos casos de uso filhos A Figura 5 16 mostra as descri es desses tr s casos de uso A generaliza o especializa o aplic vel quando um caso de uso possui diversas varia es O comportamento comum pode ser modelado como
263. nta o dos requisitos para projetar casos de teste sobretudo testes de valida o do sistema Diferentes interessados t m prop sitos diferentes Assim pode ser til ter mais do que um documento para registrar os resultados da engenharia de requisitos Conforme discutido anteriormente Pfleeger 2004 sugere que dois tipos de documentos de requisitos sejam elaborados um Documento de Defini o de Requisitos e um Documento de Especifica o de Requisitos O Documento de Defini o de Requisitos ou simplesmente Documento de Requisitos deve conter uma descri o do prop sito do sistema uma breve descri o do dom nio do problema tratado pelo sistema e listas de requisitos funcionais n o funcionais e regras de neg cio descritos em linguagem natural requisitos de usu rio Engenharia de Requisitos Notas de Aula Cap tulo 2 Engenharia de Requisitos de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 16 Para facilitar a identifica o e rastreamento dos requisitos devem se utilizar identificadores nicos para cada um dos requisitos listados O p blico alvo deste documento s o os clientes usu rios gerentes de cliente e de fornecedor e desenvolvedores O Documento de Especifica o de Requisitos deve conter os requisitos escritos a partir da perspectiva do desenvolvedor devendo haver uma correspond ncia direta com os requisitos no Documento de Requisitos de modo a se ter requisit
264. ntado a objetos como ilustra o exemplo da Figura 6 9 Nesse exemplo est se dizendo que disciplinas podem possuir v rios pr requisitos e podem ser pr requisitos para v rias outras disciplinas 0 pr requisito Figura 6 9 Associa o Muitos para Muitos Deve se observar no entanto que muitas vezes uma associa o muitos para muitos oculta a necessidade de uma classe do tipo evento a ser lembrado Seja o seguinte exemplo em uma organiza o empregados s o alocados a projetos Um empregado pode ser alocado a v rios projetos enquanto um projeto pode ter v rios empregados a ele alocados Tomando por base este fato seria natural se chegar ao modelo da Figura 6 10 a Contudo se quisermos registrar as datas de in cio e fim do per odo em que o empregado esteve alocado ao projeto esse modelo insuficiente e deve ser alterado para comportar uma classe do tipo evento lembrado Alocacao como mostra a Figura 6 10 b Figura 6 10 Associa o Muitos para Muitos e Classes de Evento Lembrado De fato o problema por detr s do modelo da Figura 6 10 a o mesmo anteriormente discutido na Figura 6 7 a necessidade ou n o de se representar informa o hist rica Contudo de maneira mais abrangente pode se pensar que se uma associa o apresenta atributos melhor trat la como uma nova classe Seja o seguinte exemplo em uma loja um cliente efetua um pedido discriminando v rios produtos cada um deles em
265. nte e como invocam o comportamento dos demais Essas informa es s o necess rias para projetar e construir um sistema mas n o s o suficientes para comunicar requisitos com clientes e usu rios Elas n o capturam o conhecimento sobre as tarefas a serem realizadas e portanto dif cil avaliar se o sistema a ser constru do a partir de um modelo desse tipo isoladamente vai realmente atender s necessidades dos usu rios Assim o primeiro modelo a ser constru do deve ser pass vel de compreens o tanto por desenvolvedores analistas projetistas programadores e testadores como pela comunidade usu ria clientes e usu rios Esse modelo inicial deve descrever o sistema seu ambiente e como sistema e ambiente est o relacionados Modelos de caso de uso use cases s o uma forma de estruturar essa vis o Como o pr prio nome sugere um caso de uso uma maneira de usar o sistema Usu rios interagem com o sistema interagindo com seus casos de uso Tomados em conjunto os casos de uso de um sistema definem a sua funcionalidade Casos de uso s o portanto os itens que o desenvolvedor negocia com seus clientes O prop sito do modelo de casos de uso capturar e descrever a funcionalidade que um sistema deve prover Um sistema geralmente serve a v rios atores para os quais ele prov diferentes servi os Tipicamente a funcionalidade a ser provida por um sistema muito grande para ser analisada como uma nica unidad
266. ntendo apenas quatro se es Engenharia de Requisitos Notas de Aula Cap tulo 3 Levantamento de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 58 1 Introdu o breve introdu o ao documento descrevendo seu prop sito e estrutura 2 Descri o do Prop sito do Sistema descreve o prop sito geral do sistema 3 Descri o do Minimundo apresenta em um texto corrido uma vis o geral do dom nio do problema a ser resolvido e dos processos de neg cio apoiados bem como as principais ideias do cliente sobre o sistema a ser desenvolvido 4 Requisitos de Usu rio apresenta os requisitos de usu rio em linguagem natural Tr s conjuntos de requisitos devem ser descritos nesta se o requisitos funcionais requisitos n o funcionais e regras de neg cio As tr s primeiras se es n o t m nenhuma estrutura especial sendo apresentadas na forma de um texto corrido A introdu o deve ser breve e basicamente descrever o prop sito e a estrutura do documento podendo seguir um padr o preestabelecido pela organiza o A descri o do prop sito do sistema deve ser direta e objetiva tipicamente em um nico par grafo J a descri o do minimundo um pouco maior algo entre uma e duas p ginas descrevendo aspectos gerais e relevantes para um primeiro entendimento do dom nio do problema a ser resolvido e dos processos de neg cio apoiados Cont m as principais ideias do cliente sobr
267. o o carro fica Dispon vel Quando o cliente retira o carro fluxo de eventos Retirar Carro do caso de uso Efetuar Loca o este fica Em Uso Quando devolvido fluxo de eventos Devolver Carro do caso de uso Efetuar Loca o o carro fica novamente Em Prepara o Quando Dispon vel um carro pode ser transferido de uma localidade para outra fluxo de eventos Transferir Carro para Outra Localidade do caso de uso Transferir Carro Durante o tr nsito de uma localidade para outra o carro est Em Tr nsito at ser recebido na localidade destino fluxo de eventos Receber Carro Vindo de Outra Localidade do caso de uso Transferir Carro quando novamente colocado Em Prepara o Finalmente carros Em Prepara o podem ser vendidos fluxo de eventos Vender Carro do caso de uso Negociar Carro quando deixam de pertencer locadora e s o eliminados de sua base de informa es Engenharia de Requisitos Notas de Aula Cap tulo 7 Modelagem Din mica Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 146 Vender Carro Em Prepara o Receber Carro Vindo de Outra Localidade Transferir Carro para Outra Localidade Enviar Carro para Manuten o Liberan Carro para Uso Dispon vel Devolver Carro Retirar Carro Figura 7 4 Diagrama de Gr fico de Estados da Classe Carro Disponibilidade adaptado de OLIVE 2007 Nem todas as classes precisam ser modeladas como
268. o 2 Engenharia de Requisitos de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 20 2 2 5 Ger ncia de Requisitos Mudan as nos requisitos ocorrem ao longo de todo o processo de software desde o levantamento e an lise de requisitos at durante a opera o do sistema Elas s o decorrentes de diversos fatores tais como descoberta de erros omiss es conflitos e inconsist ncias nos requisitos melhor entendimento por parte dos usu rios de suas necessidades problemas t cnicos de cronograma ou de custo mudan a nas prioridades do cliente mudan as no neg cio aparecimento de novos competidores mudan as econ micas mudan as na equipe mudan as no ambiente onde o software ser instalado e mudan as organizacionais ou legais Para minimizar as dificuldades impostas por essas mudan as necess rio gerenciar requisitos TOGNERI 2002 O processo de ger ncia de requisitos envolve as atividades que ajudam a equipe de desenvolvimento a identificar controlar e rastrear requisitos e gerenciar mudan as de requisitos em qualquer momento ao longo do ciclo de vida do software KOTONYA SOMMERVILLE 1998 PRESSMAN 2006 Os principais objetivos desse processo s o KOTONYA SOMMERVILLE 1998 e Gerenciar altera es nos requisitos acordados e Gerenciar relacionamentos entre requisitos e Gerenciar depend ncias entre requisitos e outros documentos produzidos durante o processo de software
269. o funcional relativo seguran a n o h a necessidade de modelar esta associa o pois requisitos n o funcionais n o devem ser considerados no modelo conceitual uma vez que solu es bastante distintas do uso dessa associa o poderiam ser adotadas i Cadastrar Livro Funcion rio Funcionario OOo i iE Figura 6 6 Exemplo Associa o x Caso de Uso Na modelagem conceitual fundamental saber a quantidade de objetos que uma associa o admite em cada um de seus pap is o que capturado pelas multiplicidades da associa o Esta informa o bastante dependente da natureza do problema e do real significado da associa o o que se quer representar efetivamente especialmente no que se refere associa o representar apenas o presente ou o hist rico WAZLAWICK 2004 Retomemos o exemplo da Figura 6 4 no qual se diz que um empregado est lotado em um departamento e opcionalmente pode chefi lo Para definir precisamente as multiplicidades necess rio investigar os seguintes aspectos Um empregado pode mudar de Engenharia de Requisitos Notas de Aula Cap tulo 6 Modelagem Conceitual Estrutural Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 129 lota o Se sim necess rio registrar apenas a lota o atual ou necess rio registrar o hist rico de lota es dos empregados ou seja registrar o evento de lota o de um empregado em um departamento Um d
270. o poss vel de objetos da classe Carro seria Dispon vel A senten a o carro est dispon vel tem um significado claro OLIVE 2007 Quando um objeto fica realizando uma atividade durante todo o tempo em que permanece em um estado deve se indicar essa atividade no compartimento de a es do respectivo estado importante real ar que uma atividade tem dura o significativa e quando conclu da tipicamente a conclus o provoca uma transi o para um novo estado A nota o da UML para representar atividades de um estado do lt lt nomeAtividade gt gt Transi es s o representadas por meio de setas rotuladas Uma transi o envolve um estado origem um estado destino e normalmente um evento dito o gatilho da transi o Quando a m quina de estados se encontra no estado origem e recebe o evento gatilho ent o o evento dispara a transi o e a m quina de estados vai para o estado destino Se uma m quina recebe um evento que n o um gatilho para nenhuma transi o ent o ela n o afetada pelo evento OLIV 2007 Uma transi o pode ter uma condi o de guarda associada s vezes h duas ou mais transi es com o mesmo estado origem e o mesmo evento gatilho mas com condi es de guarda diferentes Neste caso a transi o disparada somente quando o evento gatilho ocorre e a condi o de guarda verdadeira OLIV 2007 Quando uma transi o n o possuir uma condi o de guarda associada
271. o sistema Assim a observa o deve ser combinada com outras t cnicas de levantamento de requisitos Quando aplicadas em conjunto observa o pode ser usada para confirmar ou negar informa es de entrevistas e ou question rios Tamb m se podem entrevistar as pessoas Engenharia de Requisitos Notas de Aula Cap tulo 3 Levantamento de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 48 observadas para completar informa es obtidas de uma observa o A observa o pode ser combinada tamb m com a prototipagem Uma vez constru do um prot tipo podem se observar os usu rios utilizando o prot tipo de modo a avaliar o mesmo e derivar novos requisitos SOMMERVILLE 2007 KENDALL KENDALL 2010 KOTONYA SOMMERVILLE 1998 Al m disso deve se ressaltar que a efetividade de uma observa o pode variar na medida em que os usu rios t m tend ncia a ajustar o modo como realizam suas tarefas quando sabem que est o sendo observados AURUM WOHLIN 2005 Como outras t cnicas de levantamento de requisitos a observa o envolve planejamento condu o e o registro de resultados No planejamento o analista deve definir o que observar quem observar quando onde porque e como Kotonya e Sommerville 1998 apontam que n o h uma forma padr o de se conduzir estudos etnogr ficos contudo indicam algumas diretrizes para a aplica o dessa t cnica dentre elas e E muito importante despender um
272. odem ser apresentados no contexto da discuss o de um cen rio sendo t cnicas complementares KENDALL KENDALL 2010 SOMMERVILLE 2007 De fato quase todas as t cnicas s o complementares em alguma extens o podendo ser alternativas em outras Assim importante avaliar cada caso e escolher o melhor conjunto de t cnicas a serem aplicadas levando em considera o dentre outros a experi ncia dos analistas no uso das diversas t cnicas o perfil dos interessados e o tempo dispon vel 3 3 Requisitos e Modelagem de Processos de Neg cio O uso de sistemas de informa o tem por objetivo principal apoiar a es dos processos de neg cio das organiza es Deve se ter em mente que o principal interesse dos clientes n o o sistema de informa o em si mas sim os efeitos positivos gerados pela sua utiliza o Assim durante o levantamento de requisitos necess rio compreender o contexto organizacional no qual o sistema ser inserido bem como se alinhar aos objetivos desse contexto Se o entendimento do contexto organizacional n o ocorre os requisitos levantados tendem a ficar mais centrados em aspectos tecnol gicos sem levar em considera o fatores organizacionais tais como CARVALHO 2009 e Regras de neg cio que t m impacto sobre o sistema e Usu rios que utilizam as informa es geradas pelo sistema e Impactos gerados pelo sistema na forma de execu o dos processos de neg cio da organiza o A rel
273. oftware Trata se de discuss es gerais para quaisquer artefatos e n o discuss es focadas em requisitos mas mesmo assim muito teis Em especial a subse o 3 6 2 importante pois discute as t cnicas de leitura de requisitos baseada em perspectivas e as t cnicas de leitura de projetos orientados a objetos Refer ncias do Cap tulo AURUM A WOHLIN C Engineering and Managing Software Requirements Springer Verlag 2005 BLAHA M RUMBAUGH J Modelagem e Projetos Baseados em Objetos com UML 2 Elsevier 2006 IEEE IEEE Recommended Practice for Software Requirements Specifications IEEE Std 830 1998 New York IEEE 1998 KENDALL K E KENDALL J E Systems Analysis and Design Prentice Hall 8th Edition 2010 KOTONYA G SOMMERVILLE I Requirements engineering processes and techniques Chichester England John Wiley 1998 NUSEIBEH B EASTERBROOK S Requirements engineering a roadmap In Proceedings of the Conference on the Future of Software Engineering Limerick Ireland 2000 PALMER J D Traceability In THAYER H R DORFMAN M Org Software requeriments engineering 2 edition Los Alamitos California IEEE Computer Society p 364 374 1997 PFLEEGER S L Engenharia de Software Teoria e Pr tica S o Paulo Prentice Hall 2 edi o 2004 Engenharia de Requisitos Notas de Aula Cap tulo 2 Engenharia de Requisitos de Software Ricardo de Almeida Falbo UFES Uni
274. ontrole alternativos se fundem novamente pode se utilizar o mesmo s mbolo para mescl los Na fus o contudo h duas ou mais setas de fluxo de controle de entrada e somente uma de sa da A Figura 7 12 ilustra a nota o de desvios e fus es Atividade 3 condi es ramifica o X condi o1 Atividade 4 Atividade 5 lt D fus o Atividade 6 Figura 7 12 Ramifica es em Diagramas de Atividades da UML Engenharia de Requisitos Notas de Aula Cap tulo 7 Modelagem Din mica Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 154 Para mostrar atividades realizadas concorrentemente podem se utilizar bifurca es e uni es as quais s o representadas por barras de sincroniza o Uma barra de sincroniza o representada por uma linha grossa horizontal ou vertical Uma bifurca o tem de ter um nico fluxo de controle de entrada e dois ou mais fluxos de sa da cada um deles representando um fluxo de controle independente As atividades associadas a cada um desses caminhos prosseguem paralelamente indicando que as atividades ocorrem concorrentemente J uma uni o representa a sincroniza o de um ou mais fluxos de controle concorrentes Uma uni o tem de ter dois ou mais fluxos de entrada e apenas um fluxo de controle de sa da Na uni o os fluxos concorrentes de entrada s o sincronizados significando que cada um deles aguarda at que todos os fluxos de entrada tenham
275. ormas alternativas de realizar certos passos do caso de uso H duas formas alternativas principais fluxos variantes que s o considerados dentro da normalidade do caso de uso e fluxos de exce o que se referem ao tratamento de erros durante a execu o de um passo do fluxo normal ou de um fluxo variante ou at mesmo de um outro fluxo de exce o Requisitos Relacionados listagem dos identificadores dos requisitos funcionais n o funcionais e regras de neg cio tratados pelo caso de uso sendo descrito de modo a permitir rastrear os requisitos Casos de uso podem ser usados para conectar v rios requisitos de tipos diferentes Assim essa listagem ajuda a manter um rastro entre requisitos funcionais n o funcionais e regras de neg cio al m de permitir verificar se algum requisito deixou de ser tratado Engenharia de Requisitos Notas de Aula Cap tulo 5 Modelagem de Casos de Uso Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 95 e Classes Entidades classes no paradigma orientado a objetos ou entidades no paradigma estruturado necess rias para tratar o caso de uso sendo descrito Esta se o normalmente preenchida durante a modelagem conceitual estrutural e igualmente importante para permitir rastrear requisitos para as etapas subsequentes do desenvolvimento projeto e implementa o sobretudo 5 3 1 Descrevendo os Fluxos de Eventos Uma vez que o conjunto inicial de casos de
276. os Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 63 regra Neste caso a regra de neg cio considerada a origem do requisito funcional WIEGERS 2003 importante destacar a import ncia das regras restri es obtidas a partir de modelos conceituais estruturais ditas restri es de integridade Elas complementam as informa es de um modelo deste tipo e capturam restri es relativas a relacionamentos entre elementos de um modelo que normalmente n o s o pass veis de serem capturadas pelas nota es gr ficas utilizadas na elabora o de modelos conceituais estruturais Tais regras devem ser documentadas junto ao modelo conceitual estrutural do sistema Seja o exemplo do modelo conceitual estrutural da Figura 3 6 Esse fragmento de modelo indica que 1 um aluno cursa um curso ii um aluno pode se matricular em nenhuma ou v rias turmas iii um curso possui um conjunto de disciplinas em sua matriz curricular iv uma turma de uma disciplina espec fica Contudo nada diz sobre restri es entre o estabelecimento dessas v rias rela es Suponha que o neg cio indique que a seguinte restri o deve ser considerada Um aluno s pode ser matricular em turmas de disciplinas que comp e a grade curricular do curso que esse aluno cursa Essa restri o tem de ser escrita para complementar o modelo matricula se em comp e matriz curricular de 0 Disciplina Figura 3 6 Exemplo de Fr
277. os mudam Os neg cios s o din micos e n o h como garantir que os requisitos n o sofrer o altera es Assim fundamental gerenciar a evolu o dos requisitos bem como manter a rastreabilidade entre os requisitos e os demais artefatos produzidos no projeto atividade de Ger ncia de Requisitos Como se pode observar o tratamento de requisitos envolve atividades de desenvolvimento Levantamento An lise e Documenta o de Requisitos ger ncia Ger ncia de Requisitos e controle da qualidade Verifica o Valida o e Garantia da Qualidade de Requisitos Ao conjunto de atividades relacionadas a requisitos d se o nome de Processo de Engenharia de Requisitos 1 2 A Organiza o deste Texto Este texto procura oferecer uma vis o geral da Engenharia de Requisitos de Software discutindo as principais atividades desse processo e como realiz las nfase especial dada aplica o das t cnicas de modelagem e especifica o de Sistemas de Informa o i e sistemas desenvolvidos para apoiar processos de neg cio das organiza es Nos cap tulos que se seguem os seguintes temas s o abordados e Cap tulo 2 Engenharia de Requisitos de Software inicia discutindo o que s o requisitos e tipos e n veis de requisitos A seguir apresenta o processo de engenharia de requisitos considerado neste texto o qual cont m as seguintes atividades Levantamento de Requisitos An lise de Requisitos Documenta o de Req
278. os participantes v o interromper seu trabalho para atender ao workshop Assim sess es de workshops devem ser t o curtas quanto poss vel idealmente com dura o de uma a duas horas Contudo alguns projetos podem requerer sess es mais longas algumas vezes com dura o de v rias horas podendo chegar a dias ALEXANDER BEUS DUKIC 2009 e Onde definir o local onde se a reuni o ser realizada Deve se garantir que haver espa o suficiente para acomodar confortavelmente todos os participantes O layout da sala tamb m importante Layouts em c rculo ou na forma de U funcionam bem uma vez que eles colocam todos os participantes em um mesmo n vel de import ncia e Como durante a prepara o defina os recursos necess rios computadores projetores quadros brancos flipcharts etc e garanta que eles estar o dispon veis no per odo do workshop Proveja o material de prepara o necess rio para os participantes com anteced ncia Por fim obviamente a defini o de t picos a serem discutidos deve ser feita cuidadosamente T picos complexos podem ser divididos em s ries de quest es mais simples tais como Quais os objetivos dos Engenharia de Requisitos Notas de Aula Cap tulo 3 Levantamento de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 42 interessados para o assunto em quest o Que conflitos podem surgir Como podemos ver isso funcionando cen rios Quais os argumentos
279. os por altera es nas implementa es de um objeto que n o alterem o comportamento esperado de seus servi os Engenharia de Requisitos Notas de Aula Cap tulo 4 An lise de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 81 Classes e Opera es Abstratas Nem todas as classes s o projetadas para instanciar objetos Algumas s o usadas simplesmente para organizar caracter sticas comuns a diversas classes Tais classes s o ditas classes abstratas Uma classe abstrata desenvolvida basicamente para ser herdada por outras classes Ela existe meramente para que um comportamento comum a um conjunto de classes possa ser colocado em uma localiza o comum e definido uma nica vez Assim uma classe abstrata n o possui inst ncias diretas mas suas classes descendentes concretas sim Uma classe concreta uma classe pass vel de instancia o isto que pode ter inst ncias diretas Uma classe abstrata pode ter subclasses tamb m abstratas mas as classes folhas na rvore de heran a devem ser classes concretas Classes abstratas podem ser projetadas de duas maneiras distintas Primeiro elas podem prover implementa es completamente funcionais do comportamento que pretendem capturar Alternativamente elas podem prover apenas a defini o de um protocolo para uma opera o sem apresentar um m todo correspondente Tal opera o dita uma opera o gen rica ou abstrata Neste caso a cla
280. os rastre veis Os v rios modelos produzidos na fase de an lise devem ser apresentados no Documento de Especifica o de Requisitos bem como gloss rios de termos usados e outras informa es julgadas relevantes Deve se observar que n o h um padr o definido quanto quantidade e ao nome dos documentos de requisitos H organiza es que optam por ter apenas um documento de requisitos contendo diversas se es algumas tratando de requisitos do usu rio outras tratando de requisitos de sistema Outras organiza es por sua vez fazem uso de v rios documentos distintos capturando em documentos separados por exemplo requisitos funcionais requisitos n o funcionais modelos de caso de uso e modelos estruturais e comportamentais De fato cabe a cada organiza o definir a quantidade o nome e o conte do de cada documento Para estruturar o conte do necess rio que a organiza o defina seus modelos de documentos de requisitos V rias diretrizes t m sido propostas com objetivo de melhorar a estrutura e organiza o da documenta o de requisitos dentre elas SOMMERVILLE SAWYER 1997 KOTONYA SOMMERVILLE 1998 PRESSMAN 2006 WIEGERS 2003 1 definir um modelo de documento para cada tipo de documento a ser considerado definindo um padr o de estrutura para o documento ii explicar como cada classe de leitores deve usar os diferentes tipos de documentos iii incluir uma se o explicando por que o software ne
281. ostram diferentes vers es de um mesmo padr o o padr o Plano O problema envolvido neste caso o planejamento de a es Na vers o da Figura 8 4 considera se que uma a o definida exclusivamente para um plano Na vers o da Figura 8 5 considera se que uma a o proposta pode fazer parte de diversos planos depende de B gt AcaoProposta acaoPredecessora Figura 8 5 Padr o de An lise Plano Vers o 2 Utilizar ontologias e padr es de an lise para a modelagem conceitual de sistemas abre espa o para uma vis o mais abrangente do dom nio tratado levando a um melhor entendimento do mesmo Isso pode diminuir o tempo gasto na especifica o de requisitos pois os analistas j t m uma fonte preliminar para aprender sobre o dom nio que estabelece uma terminologia comum aos especialistas do neg cio COTA 2004 Padr es de An lise assim como ontologias descrevem aspectos no n vel de conhecimento Assim uma vez que eles proveem conhecimento sobre solu es bem sucedidas a problemas recorrentes no desenvolvimento de software eles favorecem a reutiliza o No entanto ontologias capturam a estrutura conceitual intr nseca de um dom nio enquanto padr es de an lise focalizam a estrutura de uma aplica o DEVEDZIC 1999 Em FALBO et al 2007 proposto um processo de Engenharia de Requisitos baseado em reutiliza o de ontologias e padr es de an lise voltado para o desenvolvimento
282. ovidos pelo sistema restri es etc Isso n o significa apenas perguntar o que eles desejam do sistema Ao contr rio requer uma an lise criteriosa da organiza o do dom nio do problema e dos processos de neg cio que ser o apoiados pelo sistema O quadro fica ainda mais complicado por causa de diversos fatores dentre eles raramente os clientes t m uma vis o clara de seus requisitos diferentes pessoas em uma organiza o t m diferentes requisitos s vezes conflitantes e h limita es financeiras tecnol gicas e de prazos Assim levantar requisitos n o uma tarefa simples KOTONYA SOMMERVILLE 1998 Este cap tulo enfoca o levantamento de requisitos A Se o 3 1 procura dar uma vis o geral dessa atividade discutindo problemas t picos e tarefas a serem realizadas no levantamento de requisitos A Se o 3 2 apresenta algumas t cnicas para apoiar o levantamento de requisitos A Se o 3 3 discute como a modelagem de processos de neg cio pode ajudar na captura de requisitos de software Finalmente a Se o 3 4 discute formas de se escrever e documentar requisitos 3 1 Vis o Geral do Levantamento de Requisitos O levantamento de requisitos preocupa se com o aprendizado e entendimento das necessidades dos usu rios e patrocinadores do projeto com o objetivo final de comunicar essas necessidades para os desenvolvedores do sistema Uma parte substancial do levantamento de requisitos dedicada a descobrir extrair
283. pagamento em dinheiro pagamento em cheque pagamento em cart o Nenhuma dessas formas de pagamento constitui uma exce o S o todas maneiras diferentes mas normais de realizar um certo passo do caso de Engenharia de Requisitos Notas de Aula Cap tulo 5 Modelagem de Casos de Uso Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 99 uso e portanto pode se dizer que o fluxo principal possui tr s varia es A descri o de um fluxo variante deve conter um identificador uma descri o sucinta do passo especializado e os passos enumerados como ilustra a Figura 5 5 Nome Efetuar Compra Fluxo de Eventos Normal De posse do valor a ser pago o atendente informa a forma de pagamento Efetuar o pagamento 2a Em dinheiro 2b Em cheque 2c Em cart o 3 O pagamento registrado NO ms Fluxos de Eventos Variantes 2a Pagamento em Dinheiro 2a 1 O atendente informa a quantia em dinheiro entregue pelo cliente 2a 2 O sistema informa o valor do troco a ser dado ao cliente 2b Pagamento em Cheque 2b 1 O atendente informa os dados do cheque a saber banco ag ncia conta e valor 2c Pagamento em Cart o 2c 1 O atendente informa os dados do cart o e o valor da compra 2 c 2 O sistema envia os dados informados no passo anterior junto com a identifica o da loja para o servi o de autoriza o do Sistema de Operadoras de Cart o de Cr dito 2c 3 O
284. pam de um caso de uso espec fico Engenharia de Requisitos Notas de Aula Cap tulo 5 Modelagem de Casos de Uso Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 116 Essa abordagem especialmente til para a modelagem comportamental feita utilizando diagramas de atividade e de sequ ncia Um particular elemento uma classe p ex pode claro participar de v rios casos de uso Isto significa que um modelo do sistema completo s visto atrav s de um conjunto de vis es Para se definir todas as responsabilidades de um elemento deve se olhar os casos de uso onde esse elemento tem um papel importante destacar que a modelagem casos de uso pode e deve ser realizada com algum grau de paralelismo em rela o modelagem conceitual estrutural A identifica o de conceitos relevantes para tratar um caso de uso pode ajudar a descobrir outros casos de uso relevantes sobretudo de natureza cadastral Assim uma vez iniciada a descri o dos casos de uso a modelagem conceitual estrutural pode ser tamb m iniciada Al m de serem uma ferramenta essencial na especifica o dos requisitos funcionais de um sistema casos de uso t m um papel fundamental no planejamento e controle de projetos iterativos Casos de uso podem ser usados para definir o escopo de uma itera o do projeto ou mesmo do projeto como um todo Neste contexto uma t cnica interessante para administrar discuss es de escopo s o as listas d
285. para determinar como um sentimento capturado por meio de outras t cnicas de levantamento de requisitos realmente difundido ou limitado ou para examinar uma grande amostra de usu rios para sentir problemas ou levantar quest es importantes e Quem a defini o de quem dever responder o question rio deve ser feita em conjunto com a defini o de seus objetivos Usar amostragem pode ajudar a determinar quais classes de pessoas s o necess rias e o tipo de respondentes As pessoas que v o efetivamente responder o question rio s o escolhidas dentre outros em fun o de sua posi o tempo de servi o responsabilidades e interesse no sistema corrente ou proposto importante garantir que um n mero suficiente Engenharia de Requisitos Notas de Aula Cap tulo 3 Levantamento de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 44 de respondentes ser inclu do de modo a permitir uma amostra razo vel considerando que algumas pessoas n o v o responder ou v o responder erradamente e ter o seus question rios descartados e Quando Onde estas quest es est o fortemente relacionadas ao m todo de aplica o do question rio a ser adotado Quando se decide reunir todos os respondentes em um mesmo lugar e momento deve se definir local data hora e dura o Quando os respondentes s o livres para administrar o preenchimento do question rio deve se indicar at que data isso deve ser
286. pontado no Cap tulo 6 o livro Conceptual Modeling of Information Systems de Antoni Oliv OLIV 2007 dedicado modelagem conceitual de sistemas e portanto uma tima refer ncia para os interessados em se aperfei oar nessa rea V rias das discuss es feitas nesse livro foram incorporadas nestas notas de aula Os cap tulos 11 e 12 discutem respectivamente eventos de dom nio e eventos de requisi o de a es discutidos na se o 7 1 destas notas de aula Os cap tulos 13 e 14 desse livro abordam a elabora o de diagramas de transi o de estados O Cap tulo 4 de WAZLAWICK 2004 Opera es e Consultas de Sistema discute aspectos relacionados elabora o de diagramas de sequ ncia No Cap tulo 5 Modelagem Conceitual h uma boa discuss o sobre classes modais ainda que n o se aborde a elabora o de diagramas de estados Em BOOCH RUMBAUGH JACOBSON 2006 merecem aten o os cap tulos 19 Diagramas de Intera o 20 Diagramas de Atividades 22 M quinas de Estados e 25 Diagramas de Gr ficos de Estados As nota es da UML para os diagramas abordados neste cap tulo s o tratadas com bastante detalhes uma vez que este um livro sobre a UML Al m desses cap tulos merece aten o a parte do Cap tulo 9 Classes Avan adas que trata da sintaxe de opera es Finalmente em BLAHA RUMBAUGH 2006 os cap tulos 5 6 e 12 abordam o desenvolvimento de diagramas de estados
287. que elas v o direto ao ponto em quest o ii permitem manter o controle da entrevista e iii levam a dados relevantes Como desvantagens podem ser citadas 1 quest es objetivas podem ser ma antes para o entrevistado ii podem falhar na obten o Engenharia de Requisitos Notas de Aula Cap tulo 3 Levantamento de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 37 de detalhes importantes e iii n o constroem uma afinidade entre entrevistador e entrevistado e Quest es de aprofundamento permitem explorar os detalhes de uma quest o Podem ser subjetivas ou objetivas Ex Por que Voc poderia dar um exemplo Como isto acontece A Tabela 3 1 apresenta um quadro comparativo de caracter sticas obtidas com quest es objetivas e subjetivas Tabela 3 1 Quadro Comparativo Quest es Objetivas x Subjetivas adaptado de KENDALL KENDALL 2010 Subjetivas Objetivas Confiabilidade dos dados Baixa Alta Uso eficiente do tempo Baixo Alto Precis o dos dados Baixa Alta Amplitude e profundidade Alta Baixa Habilidade requerida do entrevistador Alta Baixa Facilidade de an lise Baixa Alta A elabora o de quest es deve ser cuidadosa pois ela pode levar a problemas como KENDALL KENDALL 2010 e Quest es tendenciosas tendem a levar o entrevistado a responder de uma forma espec fica Ex Sobre este assunto voc est de acordo
288. quest o devem ser consideradas Al m desse crit rio b sico os seguintes crit rios devem ser usados para analisar hierarquias de heran a e Uma hierarquia de classes deve modelar rela es um tipo de ou seja toda subclasse deve ser um subtipo espec fico de sua superclasse e Uma subclasse deve possuir todas as propriedades atributos e associa es definidas por suas superclasses e adicionar mais alguma coisa algum outro atributo ou associa o e Todas as inst ncias de uma subclasse t m de ser tamb m inst ncias da superclasse Aten o especial deve ser dada nomea o de classes em uma hierarquia de classes Cada especializa o deve ser nomeada de forma a ser auto explicativa Um nome apropriado para a especializa o pode ser formado pelo nome de sua superclasse acompanhado por um qualificador que descreve a natureza da especializa o Por exemplo EstudanteGraduacao para designar um subtipo de Estudante Hierarquias de classes n o devem ser usadas de forma n o criteriosa simplesmente para compartilhar algumas propriedades Seja o caso de uma loja de animais em que se deseja saber as seguintes informa es sobre clientes e animais nome data de nascimento e endere o N o faz nenhum sentido considerar que Cliente uma subclasse de Animal ou vice versa apenas para reusar um conjunto de atributos que coincidentemente igual No que se refere modelagem de superclasses deve se observar se uma
289. quisito tratado de fundamental import ncia para que a rastreabilidade possa ser implementada WIEGERS 2003 ROBERTSON ROBERTSON 2006 KOTONYA SOMMERVILLE 1998 Engenharia de Requisitos Notas de Aula Cap tulo 2 Engenharia de Requisitos de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 22 Matrizes de rastreabilidade s o os principais artefatos produzidos na fase de ger ncia de requisitos Elas relacionam os requisitos identificados a um ou mais aspectos do sistema ou do seu ambiente de modo que elas possam ser procuradas rapidamente para entender como uma modifica o em um requisito vai afetar diferentes aspectos do sistema Dentre as muitas poss veis matrizes de rastreabilidade h as seguintes e Matriz de rastreabilidade de depend ncia indica como os requisitos est o relacionados uns com os outros e Matriz de rastreabilidade requisitos gt fontes indica a fonte de cada requisito e Matriz de rastreabilidade requisitos gt subsistemas indica os subsistemas que tratam os requisitos e Matriz de rastreabilidade requisitos de usu rio gt casos de uso indica os casos de uso que detalham um requisito funcional ou tratam um requisito n o funcional ou regra de neg cio Al m das matrizes de rastreabilidade de requisitos outras matrizes de rastreabilidade entre outros artefatos do processo podem ser constru das de modo a apoiar a ger ncia de requisitos Por exemp
290. r Caixa Mantenedor Figura 5 2 Diagrama de Casos de Uso Caixa Autom tico Um caso de uso descreve o que um sistema deve fazer O diagrama de casos de uso prov uma vis o apenas parcial disso uma vez que mostra as funcionalidades por perspectiva externa necess rio ainda capturar uma vis o interna de cada caso de uso especificando o comportamento do caso de uso pela descri o do fluxo de eventos que ocorre internamente passos do caso de uso Assim uma parte fundamental do modelo de casos de uso a descri o dos casos de uso 5 3 Descrevendo Casos de Uso Um caso de uso deve descrever o que um sistema faz Exceto para situa es muito simples um diagrama de casos de uso insuficiente para este prop sito Assim deve se especificar o comportamento de um caso de uso pela descri o textual de seu fluxo de eventos de modo que outros interessados possam compreend lo A especifica o ou descri o de um caso de uso deve conter dentre outras informa es um conjunto de senten as cada uma delas designando um passo simples de modo que aprender a ler um caso de uso n o requeira mais do que uns poucos minutos Dependendo da situa o diferentes estilos de escrita podem ser adotados COCKBURN 2005 Cada passo do fluxo de eventos de um caso de uso tipicamente descreve uma das seguintes situa es i uma intera o entre um ator e o sistema ii uma a o que o sistema realiza para atingir o objetivo
291. r alinhamento entre esses requisitos e os planos e produtos de trabalho do projeto SEI 2010 Para isso o CMMI sugere as seguintes pr ticas SG 1 Gerenciar Requisitos SP 1 1 Entender os requisitos SP 1 2 Obter comprometimento com os requisitos SP 1 3 Gerenciar mudan as de requisitos SP 1 4 Manter rastreabilidade bidirecional dos requisitos SP 1 5 Garantir alinhamento entre o trabalho de projeto planos de projeto e produtos de trabalho e requisitos O Desenvolvimento de Requisitos por sua vez visa levantar analisar e estabelecer requisitos de cliente do produto e de componentes do produto SEI 2010 Neste caso o CMMI sugere as seguintes pr ticas SG 1 Desenvolver Requisitos de Cliente SP 1 1 Levantar necessidades SP 1 2 Transformar necessidades dos interessados em requisitos de cliente SG 2 Desenvolver Requisitos do Produto SP 2 1 Estabelecer os requisitos do produto e de componentes do produto SP 2 2 Alocar requisitos de componentes do produto SP 2 3 Identificar requisitos de interface SG 3 Analisar e Validar Requisitos SP 3 1 Estabelecer conceitos e cen rios operacionais SP 3 2 Estabelecer uma defini o da funcionalidade e dos atributos de qualidade requeridos SP 3 3 Analisar requisitos SP 3 4 Analisar requisitos para balancear SP 3 5 Validar requisitos O MPS BR Melhoria de Processo do Software Brasileiro SOFTEX 2011 um programa mobilizador que tem como objetivo a melhoria de processo
292. r ao mercado time to market custo benef cio tempo de vida projetado para o sistema mercado alvo cronograma de implementa o e integra o com sistemas legados Wiegers 2003 por sua vez agrupa atributos de qualidade do produto em duas categorias principais atributos importantes para os usu rios e atributos importantes para os desenvolvedores Como atributos importantes para os usu rios s o apontados os seguintes disponibilidade efici ncia flexibilidade integridade interoperabilidade confiabilidade robustez e usabilidade Como atributos importantes para os desenvolvedores s o enumerados os seguintes manutenibilidade portabilidade reusabilidade e testabilidade Uma vez que n o h um consenso sobre quais atributos de qualidade considerar cada organiza o deve definir as categorias de requisitos n o funcionais a serem consideradas em seus projetos de software Al m disso essa informa o deve ser adicionada tabela de requisitos n o funcionais e portanto a Tabela 3 4 quando usada para descrever requisitos n o funcionais deve ter uma coluna adicional para indicar a categoria do requisito n o funcional Em um mundo ideal todo sistema deveria exibir os valores m ximos para todos os atributos de qualidade Contudo como no mundo real isso n o poss vel fundamental definir quais atributos s o mais importantes para o sucesso do projeto Uma abordagem para tratar essa quest o consiste em pedir para que di
293. r estruturar o uso da linguagem natural e complementar a descri o dos requisitos com outros elementos Conforme discutido no Cap tulo 2 diferentes abordagens podem ser usadas para documentar requisitos Neste texto sugerimos elaborar dois documentos o documento de defini o de requisitos ou somente documento de requisitos e o documento de especifica o de requisitos O documento de requisitos mais sucinto escrito em um n vel mais apropriado para o cliente e contempla apenas os requisitos de usu rio O documento de especifica o de requisitos mais detalhado escrito a partir da perspectiva dos desenvolvedores PFLEEGER 2004 normalmente contendo diversos modelos para descrever requisitos de sistema Os requisitos de usu rio devem ser descritos de modo a serem compreens veis pelos interessados no sistema que n o possuem conhecimento t cnico detalhado Eles devem especificar apenas o comportamento externo do sistema em uma linguagem simples direta e sem usar terminologia espec fica de software SOMMERVILLE 2007 O Documento de Defini o de Requisitos ou simplesmente Documento de Requisitos tem como prop sito descrever os requisitos de usu rio tendo como p blico alvo clientes usu rios gerentes de cliente e de fornecedor e desenvolvedores H muitos formatos distintos propostos na literatura para documentos de requisitos Neste texto proposta uma estrutura bastante simples para esse tipo de documento co
294. r mais r pida que seja uma a o ocorrer sempre em um intervalo de tempo Esta simplifica o de se considerar a es instant neas no modelo conceitual pode ser associada ideia de que a a o ocorre t o rapidamente que n o poss vel interromp la Em contraste uma atividade pass vel de interrup o sendo poss vel por exemplo que um evento ocorra interrompa a atividade e provoque uma mudan a no estado do objeto antes da conclus o da atividade As vezes quer se modelar situa es em que uma a o instant nea realizada quando se entra ou sai de um estado qualquer que seja a transi o que o leve ou o retire desse estado Seja o exemplo de um elevador Neste contexto ao parar em um andar o elevador abre a Engenharia de Requisitos Notas de Aula Cap tulo 7 Modelagem Din mica Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 144 porta Suponha que a abertura da porta do elevador seja um processo que n o possa ser interrompido e portanto que se opte por model lo como uma a o Essa a o dever ocorrer sempre que o elevador entrar no estado Parado e deve ser indicada no compartimento de a es desse estado como sendo uma a o de entrada no estado A nota o da UML para representar a es de entrada em um estado entry lt lt nomeA o gt gt Para representar a es de sa da de um estado a nota o exit lt lt nomeA o gt gt Restam ainda na Figu
295. ra o com tecnologias da informa o No entanto entrevistas podem n o ser boas para o analista compreender ou aprender sobre o dom nio da aplica o Especialistas de dom nio muitas vezes usam terminologia e Jarg es espec ficos o que provoca mal entendidos por parte dos analistas Al m disso alguns conhecimentos s o t o familiares para os interessados que s o considerados dif ceis de explicar outros s o considerados t o b sicos que os especialistas de dom nio consideram que n o vale a pena mencion los SOMMERVILLE 2007 Engenharia de Requisitos Notas de Aula Cap tulo 3 Levantamento de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 35 Em uma entrevista o engenheiro de requisitos est provavelmente estabelecendo um relacionamento com uma pessoa estranha a ele Assim importante 1 construir uma base de confian a e entendimento ii manter o controle da entrevista e iii vender a ideia do sistema provendo informa es relevantes ao entrevistado KENDALL KENDALL 2010 Uma vez que entrevistas s o essencialmente atividades sociais envolvendo pessoas sua efetividade depende em grande extens o da qualidade da intera o entre os participantes Assim os resultados de entrevistas podem variar bastante em fun o da habilidade do entrevistador AURUM WOHLIN 2005 As informa es obtidas em entrevistas complementam outras informa es obtidas de documentos ob
296. ra 7 2 dois tipos especiais de estados os ditos estados inicial e final Conforme citado anteriormente um objeto est sempre em um e somente um estado Isso implica que ao ser instanciado o objeto precisa estar em algum estado O estado inicial precisamente esse estado Graficamente um estado inicial mostrado como um pequeno c rculo preenchido na cor preta Seu significado o seguinte quando o objeto criado ele colocado no estado inicial e sua transi o de sa da automaticamente disparada movendo o objeto para um dos estados da m quina de estados no caso da Figura 7 2 para o Estado1 Toda m quina de estados tem de ter um e somente um estado inicial Note que o estado inicial n o se comporta como um estado normal uma vez que objetos n o se mant m nele por um per odo de tempo Ao contr rio uma vez que eles entram no estado inicial sua transi o de sa da imediatamente disparada e o estado inicial abandonado A transi o de sa da do estado inicial tem como evento gatilho impl cito o evento respons vel pela cria o do objeto OLIV 2007 e na UML esse evento n o explicitamente representado Estados iniciais t m apenas transi es de sa da As transi es de sa da de um estado inicial podem ter condi es de guarda e ou a es associadas Quando houver condi es de guarda deve se garantir que sempre pelo menos uma das transi es de sa da poder ser disparada Quando um objeto deix
297. rado e usando a estrat gia de identificar classes a partir de substantivos Loca o n o entraria na lista de potenciais classes Assim neste texto sugere se que ao examinar documentos de requisitos e modelos de casos de uso os seguintes elementos sejam considerados como candidatos a classes e Agentes entidades do dom nio do problema que t m a capacidade de agir com inten o de atingir uma meta Em sistemas de informa o h dois tipos principais Engenharia de Requisitos Notas de Aula Cap tulo 6 Modelagem Conceitual Estrutural Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 121 de agentes os agentes f sicos tipicamente pessoas e os agentes sociais organiza es unidades organizacionais sociedades etc Em rela o s pessoas deve se olhar para os pap is desempenhados pelas diferentes pessoas no dom nio do problema e Objetos entidades sem a capacidade de agir mas que fazem parte do dom nio de informa o do problema Podem ser tamb m classificados em f sicos p ex carros livros im veis e sociais p ex cursos disciplinas leis Entretanto h tamb m outros tipos de objetos tais como objetos de car ter descritivo usado para organizar e descrever outros objetos de um dom nio p ex modelos de carro algumas vezes denominados objetos de especifica o Objetos sociais e de descri o ou especifica o tendem a ser coisas menos tang veis mas s o t o importante
298. ras t cnicas tais como as t cnicas de leitura baseada em perspectiva e leitura de modelos orientados a objetos A t cnica de leitura baseada em perspectiva foi desenvolvida especificamente para a verifica o e valida o de requisitos Ela explora a observa o de quais informa es de requisitos s o mais ou menos importantes para as diferentes formas de utiliza o do documento de requisitos Cada revisor realiza a revis o segundo uma perspectiva diferente Algumas perspectivas tipicamente consideradas s o as perspectivas de clientes desenvolvedores e testadores Checklists para cada uma dessas perspectivas podem ser providos ROCHA MALDONADO WEBER 2001 A leitura de modelos orientados a objetos prop e um conjunto de t cnicas de leitura para revis o dos diferentes diagramas utilizados durante um projeto orientado a objetos Cada uma das t cnicas definida para um conjunto de diagramas a serem analisados em conjunto O processo de leitura realizado de duas maneiras a leitura horizontal diz respeito consist ncia entre artefatos elaborados em uma mesma fase procurando verificar se esses artefatos est o descrevendo consistentemente diferentes aspectos de um mesmo sistema no n vel de abstra o relacionado fase em quest o a leitura vertical refere se consist ncia entre artefatos elaborados em diferentes fases an lise e projeto ROCHA MALDONADO WEBER 2001 Engenharia de Requisitos Notas de Aula Cap tul
299. registradas Alterar Dados O ator informa o objeto do qual deseja alterar dados e os novos dados Os novos dados s o validados e a altera o registrada Consultar Dados O ator informa o objeto que deseja consultar Os dados do objeto s o apresentados Excluir Objeto O ator informa o objeto que deseja excluir Os dados do objeto s o apresentados e solicitada uma confirma o Se a exclus o for confirmada o objeto exclu do Fluxos de Eventos de Exce o Incluir Novo Objeto Alterar Dados Dados do objeto inv lidos uma mensagem de erro exibida solicitando corre o da informa o inv lida Figura 5 6 Padr o T pico de Descri o de Casos de Uso Cadastrais Assim para simplificar a descri o de casos de uso cadastrais recomenda se utilizar o modelo tabular mostrado na Tabela 5 1 Quando essa tabela for empregada estar se assumindo que o caso de uso envolve os fluxos de eventos indicados I para inclus o A para altera o C para consulta e E para exclus o com a descri o base mostrada na Figura 5 5 Tabela 5 1 Modelo de Descri o de Casos de Uso Cadastrais Caso de Uso A es Poss veis Observa es Requisitos Classes lt nome do caso de uso gt lt LA C E gt A coluna Observa es usada para listar informa es importantes relacionadas s a es tais como os itens informados na inclus o uma restri o a ser considerada
300. relacionados recomenda se listar os identificadores de cada um dos requisitos na se o de Requisitos Relacionados A se o de classes relacionadas indica quais s o as classes do modelo conceitual estrutural necess rias para a realiza o do caso de uso Essa se o permite rastrear casos de uso para classes em v rios n veis uma vez que h uma grande tend ncia de as mesmas classes do modelo conceitual estrutural estarem presentes nos modelos de projeto e no c digo fonte Para documentar as classes relacionadas recomenda se listar o nome de cada uma das classes envolvidas na se o de Classes Relacionadas Vale ressaltar que essa informa o tipicamente preenchida durante a modelagem conceitual estrutural ou at mesmo depois Engenharia de Requisitos Notas de Aula Cap tulo 5 Modelagem de Casos de Uso Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 104 durante a elabora o de modelos de intera o A partir das informa es de requisitos e classes relacionados pode se por exemplo construir matrizes de rastreabilidade 5 4 Relacionamentos entre Casos de Uso Para permitir uma modelagem mais apurada dos casos de uso em um diagrama tr s tipos de relacionamentos entre casos de uso podem ser empregados Casos de uso podem ser descritos como vers es especializadas de outros casos de uso relacionamento de generaliza o especializa o casos de uso podem ser inclu dos como pa
301. rente observa se que pode ser aplicada uma solu o que j foi adotada em v rios contextos e com isso estabelece se um padr o Os desenvolvedores n o inventam padr es de software descobrem nos da experi ncia em construir sistemas na pr tica DEVEDZIC 1999 Em outras palavras os padr es s o descobertos e n o inventados Por exemplo modelos se tornam padr es somente quando se descobre que eles podem ter uma utilidade comum Ou seja padr es s o coisas que os desenvolvedores conhecem e reconhecem que podem ser teis em diferentes contextos Ou seja a partir da an lise de diversos eventos de neg cio do mesmo tipo um padr o de an lise pode ser derivado por meio da abstra o de elementos comuns ROBERTSON ROBERTSON 2006 Com um padr o apresentada uma aproxima o gen rica para resolver um problema Assim padr es t m que ser trabalhados e adaptados para casos espec ficos Padr es existem em v rias fases do desenvolvimento de software A comunidade de padr es de software primeiro descobriu descreveu e classificou um certo n mero de padr es de projeto GAMMA et al 1995 Mais recentemente foram identificados outros padr es relacionados a outras fases e aspectos do desenvolvimento de software como os padr es de an lise FOWLER 1997 e padr es para arquiteturas de software FOWLER 2003 Para a Engenharia de Requisitos os padr es de interesse s o os padr es de an lise Padr es de an lise s o defi
302. respondedor comece a responder salve suas respostas e volte ao question rio posteriormente para completar seu preenchimento Lembretes aos respondentes podem ser facilmente enviados por email assim como notifica es ao analista sobre quando o respondente abriu a mensagem Pesquisas mostram que question rios pela Web podem encorajar respostas francas e consistentes Quest es que podem ser dif ceis de serem colocadas pessoalmente podem ser aceit veis de serem respondidas em um question rio pela Web KENDALL KENDALL 2010 3 2 4 Observa o As pessoas muitas vezes t m dificuldade em articular detalhes de seu trabalho pois est o imersas nele e fazem muitas coisas de maneira intuitiva Contudo os contextos social e organizacional em que as pessoas trabalham s o importantes para o desenvolvimento de um sistema e podem derivar requisitos e restri es SOMMERVILLE 2007 Assim observar o comportamento e o ambiente do indiv duo sobretudo aquele que toma decis es pode ser uma forma bastante eficaz de levantar informa es que tipicamente passam despercebidas quando outras t cnicas s o usadas KENDALL KENDALL 2010 A etnografia o estudo de pessoas em seu ambiente natural No contexto do levantamento de requisitos envolve a participa o ativa ou passiva do analista nas atividades normais dos usu rios durante um per odo de tempo enquanto coleta informa es a respeito dos processos sendo realizados T cnicas de etno
303. retudo quando se procura entender a base l gica por detr s de requisitos e restri es apontados pelos interessados WIEGERS 2003 Assim n o se deve pensar que ser poss vel levantar muitas regras de neg cio em um levantamento preliminar de requisitos Pelo contr rio as regras de neg cio v o surgir principalmente durante o levantamento detalhado dos requisitos Wiegers 2003 aponta diversas potenciais origens para regras de neg cio e sugere tipos de quest es que o analista pode fazer para tentar capturar regras advindas dessas origens Pol ticas Por que necess rio fazer isso desse jeito Regulamenta es O que o governo requer F rmulas Como este valor calculado Modelos de Dados Como essas entidades de dados est o relacionadas Ciclo de Vida de Objetos O que causa uma mudan a no estado desse objeto Decis es de Atores O que o usu rio pode fazer a seguir Decis es de Sistema Como o sistema sabe o que fazer a seguir Eventos O que pode e n o pode acontecer Regras de neg cio normalmente t m estreita rela o com requisitos funcionais Uma regra de neg cio pode ser tratada no contexto de certa funcionalidade Neste caso a regra de neg cio deve ser listada na coluna de depend ncias do requisito funcional vide Tabela 3 4 H casos em que uma regra de neg cio conduz a um requisito funcional para fazer cumprir a Engenharia de Requisitos Notas de Aula Cap tulo 3 Levantamento de Requisit
304. ributo e definir testes que tentem for ar o sistema a demonstrar tais caracter sticas WIEGERS 2003 Robertson e Robertson 2006 sugerem definir crit rios de adequa o ou ajuste fit criteria para permitir quantificar requisitos tanto funcionais como n o funcionais e associ los descri o dos requisitos primeira vista alguns requisitos n o funcionais podem parecer dif ceis de quantificar Entretanto deve ser poss vel atribuir n meros a eles Se n o se consegue quantificar e medir um requisito ent o prov vel que o requisito n o seja de fato um requisito Ele pode ser por exemplo v rios requisitos descritos em um s Seja a seguinte situa o No desenvolvimento de um sistema para uma biblioteca o usu rio coloca o seguinte requisito n o funcional O sistema deve ser amig vel ao usu rio Esse requisito vago amb guo e n o pass vel de ser expresso em n meros Como quantificar se o sistema amig vel ao usu rio Primeiro preciso entender o que o usu rio quer dizer com amig vel ao usu rio Significa ser f cil de compreender F cil de aprender F cil de operar Atrativo Clareando a inten o do usu rio poss vel sugerir uma escala de medi o Suponha que o usu rio diga que ser amig vel ao usu rio significa que os usu rios ser o capazes de aprender rapidamente a usar o sistema Uma vez definido que se est falando sobre facilidade de aprender poss vel def
305. ributos Uma propriedade que pode ser interessante mostrar em um modelo conceitual a propriedade readonly a qual indica que o valor do atributo n o pode ser alterado ap s a inicializa o do objeto No exemplo abaixo est se indicando que o valor do atributo numeroSocio de um s cio de um clube n o pode ser alterado numSocio int readonly Al m das informa es tratadas na declara o de um atributo seguindo a sintaxe da UML outras informa es de dom nio quando pertinentes podem ser adicionadas no Dicion rio de Dados do Projeto tais como unidade de medida intervalo de valores poss veis limite precis o etc 6 2 2 Associa es Uma associa o um tipo de relacionamento que ocorre entre inst ncias de duas ou mais classes Assim como classes associa es s o tipos Ou seja uma associa o modela um tipo de relacionamento que pode ocorrer entre inst ncias das classes envolvidas Uma inst ncia de uma associa o dita uma liga o conecta inst ncias espec ficas das classes envolvidas na associa o Seja o exemplo de um dom nio em que clientes efetuam pedidos Esse tipo de relacionamento pode ser modelado como uma associa o Cliente efetua Pedido Seja Pedro uma inst ncia de Cliente e Pedido100 uma inst ncia de Pedido Se foi Pedro quem efetuou o Pedido100 ent o a liga o Pedro Pedidol00 uma inst ncia da associa o Cliente efetua Pedido Associa es podem ser nomeadas Neste texto su
306. rmos desconhecidos manuais t cnicos etc e Pessoas que entendem o problema a ser resolvido podem ser muito ocupadas e n o ter muito tempo para juntamente como analista levantar os requisitos e entender o sistema e Pol ticas organizacionais podem influenciar nos requisitos de um sistema e Os interessados n o sabem muito bem o que querem do sistema e n o conhecem muitos termos Diversas t cnicas podem ser utilizadas no levantamento de requisitos as quais podem possuir diferentes objetos de investiga o ou podem ter foco em tipos diferentes de requisitos Assim til empregar v rias dessas t cnicas concomitantemente de modo a se ter um levantamento de requisitos mais eficaz Dentre as v rias t cnicas podem ser citadas KENDALL KENDALL 2010 KOTONYA SOMMERVILLE 1998 AURUM WOHLIN 2005 e Entrevistas t cnica amplamente utilizada que consiste em conversas direcionadas com um prop sito espec fico e com formato pergunta resposta Seu objetivo descobrir problemas a serem tratados levantar procedimentos importantes e saber a opini o e as expectativas do entrevistado sobre o sistema e Question rios o uso de question rios possibilita ao analista obter informa es como postura cren as comportamentos e caracter sticas de v rias pessoas que ser o afetas pelo sistema e Observa o consiste em observar o comportamento e o ambiente dos indiv duos de v rios n veis organizacionais Utilizando se
307. ronteira estabelecida para o sistema Sistemas de informa o podem ter diferentes n veis de automatiza o Por exemplo se um sistema roda na Internet seu n vel de automatiza o maior do que se ele requer um operador Assim importante capturar qual o n vel de automatiza o requerido e levar em conta o real limite do sistema WAZLAWICK 2004 Se o caso de uso roda na Internet p ex um caso de uso de reserva de autom vel ent o o cliente o ator efetivamente Se o caso de uso requer um operador p ex um caso de uso de loca o de autom vel dispon vel apenas na locadora e para ser usado por atendentes ent o o operador o ator Quando se for considerar um sistema como sendo um ator deve se tomar o cuidado para n o confundir a ideia de sistema externo ator com produtos usados na implementa o do sistema em desenvolvimento Para que um sistema possa ser considerado um ator ele deve ser um sistema de informa o completo e n o apenas uma biblioteca de classes por exemplo Al m disso ele deve estar fora do escopo do desenvolvimento do sistema atual O analista n o ter a oportunidade de alterar as fun es do sistema externo devendo adequar a comunica o s caracter sticas do mesmo WAZLAWICK 2004 Um ator prim rio um ator que possui metas a serem cumpridas atrav s do uso de servi os do sistema e que tipicamente inicia a intera o com o sistema OLIV 2007 Um ator secund rio um ator q
308. rtantes para tornar o modelo mais fiel realidade Ainda no exemplo da Figura 6 7 poder se ia querer dizer que um empregado s pode ser nomeado como chefe de um departamento se ele estiver lotado nesse departamento Restri es deste tipo s o comuns em por es fechadas de um diagrama de classes Assim toda vez que se detectar uma por o fechada em um diagrama de classes vale a pena analis la para avaliar se h ali uma restri o de integridade ou n o Havendo deve se escrev la Restri es de integridade tamb m podem falar sobre atributos das classes Por exemplo a data da portaria de nomea o de um empregado e como chefe de um departamento d deve ser igual ou posterior data da portaria de lota o do empregado e no departamento d Geralmente restri es de integridade s o escritas em linguagem natural uma vez que n o s o pass veis de modelagem gr fica Contudo conforme j discutido anteriormente o uso de linguagem natural pode levar a ambiguidades Visando suprir essa lacuna na UML o OMG incorporou ao padr o uma linguagem para especifica o formal de restri es a OCL Object Constraint Language Contudo restri es escritas em OCL dificilmente ser o entendidas por clientes e usu rios o que dificulta a valida o das mesmas Assim neste texto sugere se escrever as restri es de integridade em linguagem natural mesmo Vale ressaltar que a UML prov alguns mecanismos para representar restri
309. rte de outro caso de uso relacionamento de inclus o ou casos de uso podem estender o comportamento de um outro caso de uso relacionamento de extens o O objetivo desses relacionamentos tornar um modelo mais compreens vel evitar redund ncias entre casos de uso e permitir descrever casos de uso em camadas A seguir esses tipos de relacionamentos s o abordados 5 4 1 Inclus o Uma associa o de inclus o de um caso de uso base para um caso de uso de inclus o significa que o comportamento definido no caso de uso de inclus o incorporado ao comportamento do caso de uso base Ou seja a rela o de inclus o incorpora um caso de uso o caso de uso inclu do dentro da sequ ncia de comportamento de outro caso de uso o caso de uso base BLAHA RUMBAUGH 2006 OLIV 2007 Esse tipo de associa o til para extrair comportamento comum a v rios casos de uso em uma nica descri o de modo que esse comportamento n o tenha de ser descrito repetidamente O caso de uso de inclus o pode ou n o ser pass vel de utiliza o isoladamente Assim ele pode ser apenas um fragmento de uma funcionalidade n o precisando ser uma transa o completa A parte comum inclu da por todos os casos de uso base que t m esse caso de uso de inclus o em comum e a execu o do caso de uso de inclus o an loga a uma chamada de subrotina OLIVE 2007 Na UML o relacionamento de inclus o entre casos de uso mostrado como uma dep
310. s Al m disso modelos podem ser reutilizados conforme discutido no Cap tulo 8 deste texto 3 2 7 Aplicando as T cnicas de Levantamento de Requisitos Duas importantes quest es que precisam ser abordadas em rela o s t cnicas de levantamento de requisitos s o AURUM WOHLIN 2005 e Que t cnica s aplicar durante uma atividade de levantamento de requisitos e Quais dessas t cnicas s o complementares Em ltima inst ncia cada situa o em alguma extens o nica e portanto as respostas a essas perguntas s o dependentes do contexto do projeto AURUM WOHLIN 2005 De maneira geral as principais t cnicas discutidas neste texto s o complementares Algumas informa es s o dif ceis de serem obtidas atrav s de entrevistas ou observa o tais como dados sobre um determinado objeto ou evento informa o financeira e contextos da organiza o Tais informa es revelam tipicamente um hist rico da organiza o e sua dire o Nestes casos a investiga o de documentos uma boa op o pois fatos obtidos em uma investiga o podem explicar o desempenho passado da organiza o Por outro lado metas projetam o futuro Entrevistas s o importantes para se determinar metas obter necessidades e perspectivas individuais A coleta colaborativa de requisitos pode ser uma boa alternativa ao uso de entrevistas sobretudo para se ter um entendimento coletivo e para decidir sobre requisitos Question rios pode
311. s WAZLAWICK 2004 Classes modais podem ser modeladas como m quinas de estados finitos Uma m quina de estados finitos uma m quina que em um dado momento est em um e somente um de um n mero finito de estados OLIV 2007 Os estados de uma m quina de estados de uma classe modal correspondem s situa es relevantes em que as inst ncias dessa classe podem estar durante sua exist ncia Um estado considerado relevante quando ele ajuda a definir restri es ou efeitos dos eventos Em qualquer estado uma m quina de estados pode receber est mulos Quando a m quina recebe um est mulo ela pode realizar uma transi o de seu estado corrente dito estado origem para outro estado dito estado destino sendo que se assume que as transi es s o instant neas A defini o do estado destino depende do estado origem e do est mulo recebido Al m disso os estados origem e destino em uma transi o podem ser o mesmo Neste caso a transi o dita uma autotransi o OLIV 2007 Diagramas de Transi es de Estados s o usados para modelar o comportamento de inst ncias de uma classe modal na forma de uma m quina de estados Todas as inst ncias da classe comportam se da mesma maneira Em outras palavras cada diagrama de estados constru do para uma nica classe com o objetivo de mostrar o comportamento ao longo do tempo de vida de seus objetos Diagramas de estados descrevem os poss veis estados pelos quais objeto
312. s benef cios tais como IEEE 1998 NUSEIBEH EASTERBROOK 2000 1 facilita a comunica o dos requisitos ii reduz o esfor o de desenvolvimento pois sua prepara o for a usu rios e clientes a considerar os requisitos atentamente evitando retrabalho nas fases posteriores iii fornece uma base real stica para estimativas iv fornece uma base para verifica o e valida o v facilita a transfer ncia do software para novos usu rios e ou m quinas e vi serve como base para futuras manuten es ou incremento de novas funcionalidades A documenta o dos requisitos tem um conjunto diversificado de interessados dentre eles SOMMERVILLE 2007 KOTONYA SOMMERVILLE 1998 e Clientes Usu rios e Especialistas de Dom nio s o interessados na documenta o de requisitos uma vez que atuam na especifica o avalia o e altera o de requisitos e Gerentes de Cliente utilizam o documento de requisitos para planejar um pedido de proposta para o desenvolvimento de um sistema contratar um fornecedor e para acompanhar o desenvolvimento do sistema e Gerentes de Fornecedor utilizam a documenta o dos requisitos para planejar uma proposta para o sistema e para planejar e acompanhar o processo de desenvolvimento e Desenvolvedores analistas projetistas programadores e mantenedores utilizam a documenta o dos requisitos para compreender o sistema e as rela es entre suas partes e Testadores utilizam a docume
313. s da classe podem passar e as altera es dos estados como resultado de eventos est mulos que atingem esses objetos Uma m quina de estado especifica a ordem v lida dos estados pelos quais os objetos da classe podem passar ao longo de seu ciclo de vida A Figura 7 2 mostra a nota o b sica da UML para diagramas de gr fico de estados transi o estado y estado inicial evento condi oGuarda a o final y Estado 1 Estado 2 estado origem estado destino da transi o da transi o eventoDestrui o Estado 3 Figura 7 2 Nota o B sica da UML para Diagramas de Gr fico de Estados Um estado uma situa o na vida de um objeto durante a qual o objeto satisfaz alguma condi o realiza alguma atividade ou aguarda a ocorr ncia de um evento BOOCH RUMBAUGH JACOBSON 2006 Estados s o representados por ret ngulos com os cantos arredondados sendo que o nome de um estado deve ser nico em uma m quina de estados Uma regra pr tica para nomear estados consiste em atribuir um nome tal que sejam Engenharia de Requisitos Notas de Aula Cap tulo 7 Modelagem Din mica Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 143 significativas senten as do tipo o lt lt objeto gt gt est lt lt nome do estado gt gt ou o lt lt objeto gt gt est no estado lt lt nome do estado gt gt Por exemplo em um sistema de locadora de autom veis um estad
314. s para a modelagem conceitual quanto os objetos f sicos e Eventos representam a ocorr ncia de a es no dom nio do problema que precisam ser registradas e lembradas pelo sistema Eventos acontecem no tempo e portanto a representa o de eventos normalmente envolve a necessidade de registrar dentre outros quando o evento ocorreu ponto no tempo ou intervalo de tempo Deve se observar que muitos eventos ocorrem no dom nio do problema mas grande parte deles n o precisa ser lembrada Para capturar os eventos que precisam ser lembrados e portanto registrados devem se focalizar os principais eventos de neg cio do dom nio do problema Assim em um sistema de loca o de autom veis s o potenciais classes de eventos Loca o Devolu o e Reserva Por outro lado a ocorr ncia de eventos cadastrais tais como os cadastros de clientes e carros tende a ser de pouca import ncia n o sendo necess rio lembrar a ocorr ncia desses eventos Seja qual for a estrat gia usada para identificar classes sempre importante que o analista tenha em mente os objetivos do sistema durante a modelagem conceitual N o se devem representar informa es irrelevantes para o sistema e portanto a relev ncia para o sistema o principal crit rio a ser adotado para decidir se um determinado elemento deve ou n o ser inclu do no modelo conceitual estrutural do sistema O resultado principal da atividade de identifica o de classes a obten
315. s requisitos devem possuir identificadores nicos para permitir a identifica o e o rastreamento na ger ncia de requisitos H diversas propostas de esquemas de rotulagem de requisitos Neste texto recomenda se usar um esquema de numera o sequencial por tipo de requisito sendo usados os seguintes prefixos para designar os diferentes tipos de requisitos RF requisitos funcionais RNF requisitos n o funcionais RN regras de neg cio Para outros esquemas de rotulagem vide WIEGERS 2003 importante destacar que quando um requisito eliminado seu identificador n o pode ser atribu do a outro requisito A descri o do requisito normalmente feita na forma de uma senten a em linguagem natural Ainda que expressa em linguagem natural importante adotar um estilo consistente e usar a terminologia do usu rio ao inv s do jarg o t pico da computa o Em rela o ao estilo Engenharia de Requisitos Notas de Aula Cap tulo 3 Levantamento de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 59 recomenda se utilizar senten as em um dos seguintes formatos para descrever requisitos funcionais e n o funcionais O sistema deve lt verbo indicando a o seguido de complemento gt use o verbo dever para designar uma fun o ou caracter stica requerida para o sistema ou seja para descrever um requisito obrigat rio Exemplos O sistema deve efetuar o controle dos clientes
316. s usu rios atingir metas especificadas com acur cia e completude em um contexto de uso especificado e Produtividade capacidade do produto de software de permitir ao usu rio usar a quantidade de recursos apropriados em rela o efic cia atingida quando o produto de software utilizado em um contexto de uso especificado e Seguran a capacidade do produto de software de atingir n veis aceit veis de riscos de danos para pessoas neg cios software propriedades ou ambiente em um contexto de uso especificado e Satisfa o capacidade do produto de software satisfazer os usu rios em um contexto de uso especificado
317. se faz distin o entre clientes normais e clientes especiais dos quais se quer saber exatamente as mesmas informa es Neste caso criar uma hierarquia de classes como ilustra a Figura 6 17 a desnecess rio Uma solu o como a apresentada na Figura 6 17 b em que o atributo tipo pode ser de um tipo enumerado com os seguintes valores Normal Especial modela satisfatoriamente o problema e mais simples e portanto mais indicada nome endereco dataNascimento cpf telefones a nome endereco dataNascimento cpf b telefones tipo Figura 6 17 Uso ou n o de Heran a Engenharia de Requisitos Notas de Aula Cap tulo 6 Modelagem Conceitual Estrutural Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 136 Tamb m n o faz sentido criar uma hierarquia de classes em que a superclasse n o tem nenhum atributo ou associa o Informa es de estados pelos quais um objeto passa tamb m n o devem ser confundidas com subclasses Por exemplo um carro de uma locadora de autom veis pode estar locado dispon vel ou em manuten o Estes s o estados e n o subtipos de carro De fato interessante considerar alguns crit rios para incluir uma subclasse ou superclasse em um modelo conceitual O principal deles o fato da especializa o ou generaliza o estar dentro do dom nio de responsabilidade do sistema Apenas subclasses superclasses relevantes para o sistema em
318. senvolvidos pensando no re so posterior Neste contexto merecem destaque tr s abordagens discutidas na sequ ncia Engenharia de Dom nio Ontologias e Padr es de An lise 8 3 1 Engenharia de Dom nio A Engenharia de Dom nio representa um enfoque sistem tico para a produ o de componentes reutiliz veis que engloba atividades de an lise projeto e implementa o de dom nio as quais objetivam respectivamente representar requisitos comuns de uma fam lia de aplica es por meio de modelos de dom nio disponibilizar modelos arquiteturais para aplica es a partir de um nico modelo de dom nio e disponibilizar implementa es de componentes que representam funcionalidades b sicas de aplica es relacionadas a um dom nio GIMENES HUZITA 2005 A An lise de Dom nio a atividade diretamente ligada reutiliza o na Engenharia de Requisitos A An lise de Dom nio visa capturar os elementos relevantes de um dom nio de aplica es e disponibiliz los para serem utilizados no desenvolvimento de diferentes sistemas de apoio a neg cios neste dom nio Assim a An lise de Dom nio busca explicitar e modelar aspectos de dom nio produzindo artefatos tipicamente modelos que cont m informa es sobre o dom nio e que podem ser reutilizados no desenvolvimento de sistemas Pode se fazer um paralelo entre a An lise de Dom nio e a An lise de Requisitos ambas enfocam a modelagem conceitual de um dom nio de aplica es
319. ser fornecido PFLEEGER 2004 O prot tipo constru do apenas para apoiar o levantamento e a valida o de requisitos sendo descartado ap s essas fases Prot tipos descart veis enfatizam o desenvolvimento r pido sem prestar aten o a princ pios de engenharia e qualidade de software Eles n o devem ser mais elaborados do que o necess rio para atingir seus objetivos Assim alguns atributos de qualidade como robustez confiabilidade e desempenho podem n o ser levados em conta O uso de prot tipos descart veis mais apropriado quando a equipe se depara com incertezas ambiguidade falta de completeza e imprecis o nos requisitos WIEGERS 2003 Prot tipo evolutivo desenvolvido para se aprender mais sobre o problema e se ter a base de uma parte ou de todo o software a ser fornecido PFLEEGER 2004 Em contraste com um prot tipo descart vel o prot tipo parte ou uma vers o do produto final e deve prover uma base para construir esse produto de forma incremental Portanto deve considerar princ pios de engenharia e qualidade de software WIEGERS 2003 Quanto ao conjunto de funcionalidades provido pelo prot tipo um prot tipo pode ser Prot tipo de caracter sticas selecionadas apenas uma por o do sistema implementada no prot tipo Prot tipo completo o prot tipo apresenta todas as caracter sticas do que se imagina ser o sistema real Essas diferentes classifica es de prot tipos s o em certa
320. serva es de usu rios etc Assim essa t cnica deve ser usada em conjunto com outras t cnicas de levantamento de requisitos SOMMERVILLE 2007 Uma entrevista precisa ser planejada Tipicamente o planejamento de uma entrevista assim como o de outras atividades de levantamento de requisitos deve considerar as quatro perguntas b sicas e Por que a primeira coisa a ser feita estabelecer os objetivos da entrevista As primeiras entrevistas t m normalmente um car ter explorat rio quando se desejam capturar objetivos da organiza o para o sistema prop sito do sistema reas de neg cio afetadas etc Na medida em que o analista ganha entendimento sobre o problema seu foco tende a ficar mais restrito visando um aprofundamento em um tema ou aspecto espec fico do sistema Entrevista uma boa op o dentre outros para capturar metas organizacionais ou pessoais e sentimentos e necessidades em rela o ao sistema perspectivas de diferentes envolvidos ou para melhorar aprofundar o entendimento sobre o problema Por outro lado n o uma boa op o para aprender sobre o dom nio e Quem tendo em mente o objetivo da entrevista o pr ximo passo identificar quais membros da organiza o t m conhecimento acerca do assunto a ser tratado e selecionar as pessoas a serem entrevistadas interessante levantar ainda o papel e a posi o do potencial entrevistado na organiza o Pessoas da alta ger ncia t m normalmen
321. sim os cen rios s o na verdade inst ncias de um caso de uso Os modelos de casos de uso s o uma maneira eficaz para analistas clientes especialistas de dom nio e usu rios chegarem a uma compreens o comum acerca das funcionalidades que o sistema deve prover Al m disso servem para ajudar a verificar e validar o sistema medida que ele vai sendo desenvolvido Neste contexto os casos de uso podem ser utilizados como base para o projeto de casos de teste para o sistema em uma abordagem de testes baseada em casos de uso na qual casos de teste s o projetados a partir dos fluxos de eventos principal e alternativos dos casos de uso procurando explorar diferentes cen rios de uso do sistema No contexto da Engenharia de Requisitos casos de uso t m dois importantes pap is e Casos de uso especificam os requisitos funcionais de um sistema Um modelo de caso de uso descreve detalhadamente o comportamento de um sistema atrav s de um conjunto de casos de uso O ambiente do sistema definido pela descri o dos diferentes atores que utilizam o sistema realizando os casos de uso e Casos de uso oferecem uma abordagem para a modelagem de sistemas Para gerenciar a complexidade de sistemas reais comum apresentar os modelos do sistema em um n mero de diferentes vis es Em uma abordagem guiada por casos de uso pode se construir uma vis o para cada caso de uso isto em cada vis o s o modelados apenas aqueles elementos que partici
322. sitos discutida na Se o 8 3 8 1 T cnicas de Leitura de Modelos da An lise de Requisitos Na verifica o da consist ncia entre os diversos modelos e diagramas produzidos durante um processo de software orientado a objetos devem ser consideradas t cnicas de leitura de modelos orientados a objetos as quais podem ser de dois tipos t cnicas para leitura vertical e para leitura horizontal As t cnicas para leitura horizontal dizem respeito consist ncia entre artefatos elaborados em uma mesma fase procurando verificar se esses artefatos est o descrevendo consistentemente diferentes aspectos de um mesmo sistema no n vel de abstra o relacionado fase em quest o T cnicas verticais referem se consist ncia entre artefatos elaborados em diferentes fases Neste texto o foco recai sobre t cnicas de leitura horizontal mais especificamente entre os modelos produzidos durante a an lise de requisitos A Figura 8 1 mostra as rela es existentes entre os diferentes artefatos elaborados na fase de an lise de requisitos indicando as t cnicas de leituras associadas Essa figura destaca a import ncia de dois artefatos produzidos na an lise de requisitos as descri es de casos de uso e os diagramas de classes Como se pode notar pela figura esses dois artefatos t m rela es com quase todos os demais o que mostra o papel central que eles desempenham no processo de desenvolvimento orientado a objetos Na sequ ncia cada
323. situa es incluindo estrutura organizacional contratos e rela es de emprego Dentre os padr es dessa categoria podem ser citados Parte Party Hierarquia Organizacional Organization Hierarquies e Estrutura Organizacional Organization Structure Os padr es de an lise de negocia o por sua vez tratam o com rcio de mercadorias sob uma perspectiva de vendedor comprador Esses padr es tratam compra e venda de mercadorias e o valor dessas mercadorias com respeito s mudan as nas condi es de mercado Nesta categoria h dentre outros os seguintes padr es Contrato Contract e Carteira de Neg cios Portfolio As figuras 8 3 8 4 e 8 5 mostram alguns exemplos de modelos estruturais propostos em padr es de an lise adaptados de FOWLER 1997 Na Figura 8 3 apresentado o padr o Pessoa cujo prop sito tratar situa es em que pessoas f sicas e jur dicas t m responsabilidades similares Neste caso a solu o adotada criar um tipo Pessoa como um supertipo de Pessoa F sica e Pessoa Jur dica reunindo propriedades comuns s duas Pessoa endereco telefone i i PessoaFisica PessoaJuridica nome razaoSocial cpf cnpj sexo inscricaoEstadual Lo Figura 8 3 Padr o de An lise Pessoa Engenharia de Requisitos Notas de Aula Cap tulo 8 Qualidade e Agilidade em Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 170 As figuras 8 4 e 8 5 m
324. socia o de extens o como uma rela o de inclus o olhada da dire o oposta em que a extens o se incorpora ao caso de uso base em vez de o caso de uso base incorporar explicitamente a extens o Ela conecta um caso de uso de extens o a um caso de uso base O caso de uso de extens o geralmente um fragmento ou seja ele n o aparece sozinho como uma sequ ncia de comportamentos Al m disso na maioria das vezes a rela o de extens o possui uma condi o associada e neste caso o comportamento de extens o ocorre apenas se a condi o for verdadeira O caso de uso base por sua vez precisa ser obrigatoriamente um caso de uso v lido na aus ncia de quaisquer extens es BLAHA RUMBAUGH 2006 Engenharia de Requisitos Notas de Aula Cap tulo 5 Modelagem de Casos de Uso Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 108 Na UML a associa o de extens o entre casos de uso mostrada como uma depend ncia seta pontilhada estereotipada com a palavra chave extend partindo do caso de uso de extens o para o caso de uso base como ilustra a Figura 5 11 Pontos de extens o podem ser indicados no compartimento da elipse do caso de uso denominado extension points pontos de extens o Opcionalmente a condi o a ser satisfeita e a refer ncia ao ponto de extens o podem ser mostradas por meio de uma nota anexada associa o de extens o OLIV 2007 Assim no exemplo da Figura 5 1
325. sos de uso Mais especificamente recomenda se a leitura da se o 7 1 Modelos de Casos de Uso que d uma vis o geral de atores casos de uso e diagramas de casos de uso e da se o 8 1 Rela es entre Casos de Uso que discute as rela es de inclus o extens o e generaliza o e especializa o entre casos de uso O Cap tulo 15 de OLIV 2007 Use Cases d uma vis o geral da modelagem de casos de uso discutindo de maneira breve mas bastante did tica os conceitos de ator e de caso de uso a especifica o de casos de uso e os relacionamentos entre casos de uso O livro Escrevendo Casos de Uso Eficazes Um guia pr tico para desenvolvedores de software COCKBURN 2005 inteiramente dedicado ao processo de escrita de casos de uso Esse livro uma tima refer ncia para os interessados em aperfei oar seu processo de escrita de casos de uso contendo diversas diretrizes incorporadas nestas notas de aula Engenharia de Requisitos Notas de Aula Cap tulo 5 Modelagem de Casos de Uso Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 117 Em WAZLAWICK 2004 tanto o Cap tulo 2 Concep o quanto o Cap tulo 3 Expans o dos Casos de Uso abordam a modelagem de casos de uso Em BOOCH RUMBAUGH JACOBSON 2006 merecem aten o os cap tulos 17 Casos de Uso e 18 Diagramas de Casos de Uso As nota es da UML para diagramas de casos de uso s o tratadas com mais detalhes
326. specifica es de projetos similares ao projeto atual informalmente atrav s da experi ncia das pessoas ou pela reutiliza o de artefatos desenvolvidos previamente com vistas ao re so Por exemplo ao se analisar um projeto similar desenvolvido para um mesmo dom nio de aplica o pode se concluir que diversos requisitos funcionais n o funcionais e at regras de neg cio podem se aplicar ao novo projeto em desenvolvimento Neste caso os requisitos podem ser copiados e adaptados quando necess rio de um projeto para o outro Outra abordagem bastante utilizada pelas organiza es consiste em definir equipes que atuam sistematicamente em um certo dom nio de aplica es de modo que seus membros possam reutilizar o conhecimento que t m sobre esse dom nio no desenvolvimento de novos projetos Ainda que essas abordagens mais informais e oportunistas tragam alguns benef cios elas n o exploram adequadamente as potencialidades de uma reutiliza o sistem tica Em uma abordagem sistem tica de desenvolvimento para e com reutiliza o primeiramente artefatos s o concebidos explicitamente para serem reutilizados Depois os projetos de desenvolvimento reutilizam esses artefatos fazendo as adapta es necess rias Uma vez que esses itens tenham sido desenvolvidos para re so o esfor o de adapta o e reutiliza o tende a ser menor Assim para se obter os reais benef cios da reutiliza o importante que os artefatos j sejam de
327. sse abstrata n o completamente implementada e todas as suas subclasses concretas s o obrigadas a prover uma implementa o para suas opera es abstratas Assim diz se que uma opera o abstrata define apenas a assinatura a ser usada nas implementa es que as subclasses dever o prover garantindo assim uma interface consistente M todos que implementam uma opera o gen rica t m a mesma sem ntica Uma classe concreta n o pode conter opera es abstratas porque sen o seus objetos teriam opera es indefinidas Assim toda classe que possuir uma opera o gen rica n o pode ter inst ncias diretas e portanto obrigatoriamente uma classe abstrata 4 4 Um M todo de An lise de Requisitos Funcionais Uma vez que tipicamente diversos modelos do sistema s o produzidos surgem algumas importantes quest es Que modelos produzir Em que sequ ncia Quais as rela es existentes entre esses modelos Estas quest es podem ser parcialmente respondidas pela ado o de um m todo de an lise Um m todo composto por uma linguagem estabelecendo a nota o a ser usada na elabora o dos artefatos a serem produzidos e de um processo descrevendo que artefatos construir e como constru los O m todo sugerido neste texto adota a Linguagem de Modelagem Unificada Unified Modeling Language UML BOOCH RUMBAUGH JACOBSON 2006 como linguagem de modelagem e prescreve o processo ilustrado na Figura 4 1 Nessa figura as
328. stion rio em uma entrevista ou para projetar um question rio com base no que foi descoberto em uma entrevista Usando question rios ap s a realiza o de entrevistas um analista pode estar procurando quantificar o que foi levantado em entrevistas ou determinar como um sentimento Engenharia de Requisitos Notas de Aula Cap tulo 3 Levantamento de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 43 expresso em uma entrevista realmente difundido ou limitado Por outro lado question rios podem ser usados para examinar uma grande amostra de usu rios para sentir problemas ou levantar quest es importantes antes de se programar entrevistas KENDALL KENDALL 2010 Question rios proveem um meio eficiente de coletar informa es de v rios interessados Entretanto s o limitados no que tange profundidade do conhecimento que pode ser levantado uma vez que n o permitem que um t pico seja aprofundado ou que ideias sejam expandidas AURUM WOHLIN 2005 Question rios s o teis quando KENDALL KENDALL 2010 e As pessoas necess rias est o geograficamente dispersas e H um grande n mero de pessoas envolvidas no projeto do sistema e necess rio saber qual propor o de um dado grupo aprova ou desaprova uma particular caracter stica do sistema proposto e Se deseja saber uma opini o global antes de se definir qualquer dire o espec fica para o projeto em um estudo explorat rio
329. su rio a possibilidade de cancelar ou alterar dados de uma transa o efetuada anteriormente com sucesso Se cada uma dessas possibilidades for considerada como um caso de uso isolado o n mero de casos de uso pode crescer demasiadamente aumentando desnecessariamente a complexidade do modelo de casos de uso Al m disso o fluxo de eventos normal de um caso de uso desse tipo tende a ser muito simples n o justificando documentar todo um conjunto de informa es para adicionar apenas duas ou tr s linhas descrevendo os passos do caso de uso Assim em situa es dessa natureza interessante considerar apenas um caso de uso contendo diversos fluxos de eventos principais Essa abordagem bastante recomendada para casos de uso cadastrais em que um nico caso de uso inclui fluxos de eventos normais para criar alterar consultar e excluir entidades Fluxos de eventos normais podem ser descritos de diferentes maneiras dependendo do n vel de formalidade que se deseja para as descri es Dentre os formatos poss veis h dois principais e Livre o fluxo de eventos normal escrito na forma de um texto corrido como no exemplo da Figura 5 3 e Enumerado cada passo do fluxo de eventos normal numerado de modo que possa ser referenciado nos fluxos de eventos alternativos ou em outros pontos do fluxo de eventos normal A Figura 5 4 reapresenta o exemplo da Figura 5 3 neste formato As se es iniciais foram omitidas por serem iguais s
330. superclasse concreta ou abstrata Se a superclasse puder ter inst ncias pr prias que n o s o inst ncias de nenhuma de suas subclasses ent o ela uma classe concreta Por outro lado se n o for poss vel instanciar diretamente a superclasse ou seja se todas as inst ncias da superclasse s o antes inst ncias das suas subclasses ent o a superclasse abstrata Classes abstratas s o representadas na UML com seu nome escrito em it lico e n o devem herdar de classes concretas Quando modeladas hierarquias de classes necess rio posicionar atributos e associa es adequadamente Cada atributo ou associa o deve ser colocado na classe mais adequada Atributos e associa es gen ricos que se aplicam a todas as subclasses devem ser posicionados no topo da estrutura de modo a serem aplic veis a todas as especializa es De maneira mais geral se um atributo ou associa o aplic vel a um n vel inteiro de especializa es ent o ele deve ser posicionado na generaliza o correspondente Por outro lado se algumas vezes um atributo ou associa o tiver um valor significativo mas em outras ele n o for aplic vel deve se rever seu posicionamento ou mesmo a estrutura de generaliza o especializa o adotada Inevitavelmente o processo detalhado de designar atributos e associa es a classes conduz a um entendimento mais completo da hierarquia de heran a do que era poss vel em Engenharia de Requisitos Notas de
331. ta associa o enquanto objetos da Classe desempenham o papel de papelClasse2 nessa mesma associa o importante neste ponto frisar a diferen a entre sentido de leitura ou dire o do nome de uma associa o com a navega o da associa o O sentido de leitura diz apenas em que dire o ler o nome da associa o mas nada diz sobre a navegabilidade da associa o A navegabilidade linha de associa o com seta direcionada usada para limitar a navega o de uma associa o a uma nica dire o e um recurso a ser usado apenas na fase de projeto Em um modelo conceitual todas as associa es s o n o direcionais ou seja naveg veis nos dois sentidos Ainda que nomes de associa es e pap is sejam opcionais recomenda se us los para tornar o modelo mais claro Al m disso h algumas situa es em que fica invi vel ler um modelo se n o houver a especifica o do nome da associa o ou de algum de seus pap is Seja o exemplo da Figura 6 4 Em uma empresa um empregado est lotado em um departamento e opcionalmente pode chefi lo Um departamento por sua vez pode ter v rios empregados nele lotados mas apenas um chefe Sem nomear essas associa es o modelo fica confuso Rotulando os pap is e as associa es o modelo torna se muito mais claro Na figura 6 4 um departamento exerce o papel de departamento de lota o do empregado e neste caso um empregado tem um e somente um departamento d
332. te os dois principais conceitos empregados na modelagem de casos de uso atores e casos de uso A Se o 5 2 aborda os diagramas de casos de uso e sua nota o segundo a UML A Se o 5 3 trata da especifica o de casos de uso A Se o 5 4 discute os tipos de relacionamentos que podem ser estabelecidos entre casos de uso a saber inclus o extens o e generaliza o especializa o Finalmente a Se o 5 5 discute como trabalhar com casos de uso e como us los em outras atividades do processo de software 5 1 Atores e Casos de Uso Nenhum sistema computacional existe isoladamente Todo sistema interage com atores humanos ou outros sistemas que utilizam esse sistema para algum prop sito e esperam que o sistema se comporte de certa maneira Um caso de uso especifica um comportamento de um sistema segundo uma perspectiva externa e uma descri o de uma sequ ncia de a es realizada pelo sistema para produzir um resultado de valor para um ator BOOCH RUMBAUGH JACOBSON 2006 Segundo Cockburn 2005 um caso de uso captura um contrato entre os interessados stakeholders em um sistema sobre o seu comportamento Um caso de uso descreve o comportamento do sistema sob certas condi es em resposta a uma requisi o feita por um interessado dito o ator prim rio do caso de uso Assim os dois principais conceitos da modelagem de casos de uso s o atores e casos de uso 5 1 1 Atores D se nome de ator a um papel desempe
333. te quando o projeto envolve a substitui o de um sistema existente A documenta o acerca desses sistemas e processos de neg cio incluindo manuais formul rios e relat rios bem como de padr es da ind stria leis e regulamenta es prov informa o til sobre a organiza o e seu ambiente Outras fontes incluem especifica es de requisitos de sistemas quando o sistema envolve hardware e software e existe uma especifica o de mais alto n vel problemas reportados e solicita es de melhoria para sistemas correntes e observa o do dia a dia dos usu rios A necessidade de se obter requisitos a partir de m ltiplas perspectivas e fontes ilustra bem a natureza de comunica o intensiva da engenharia de requisitos An lise de Interessados conforme citado anteriormente interessados stakeholders s o pessoas que t m interesse no sistema ou s o afetadas de alguma maneira por ele e portanto precisam ser consultadas durante o levantamento de requisitos Interessados incluem tanto pessoal interno quanto externo organiza o O cliente ou patrocinador do projeto tipicamente o interessado mais aparente de um projeto Contudo os usu rios s o na maioria das vezes os interessados mais importantes Outras partes cuja esfera de interesse pode ser afetada pela opera o do sistema tais como parceiros e clientes da organiza o devem ser consideradas interessadas Assim um dos primeiros passos no processo de levantamento
334. te uma vis o mais abrangente dos objetivos organizacionais e estrat gicos mas por outro lado n o conhecem detalhes mais operacionais Assim o objetivo da entrevista deve guiar a sele o do entrevistado O cliente ou patrocinador do projeto pode ajudar na identifica o das pessoas mais indicadas para uma entrevista Quando houver muitos bons candidatos a entrevistas em um mesmo papel posi o pode se usar amostragem para selecionar uma amostra gerenci vel e Quando no que se refere quest o temporal de uma entrevista dois aspectos devem ser considerados primeiro a data e o hor rio segundo a dura o No que se refere ao agendamento da entrevista deve se marcar a entrevista com certa anteced ncia preferencialmente de alguns dias e informar o objetivo da entrevista e o tema a ser abordado de modo que o entrevistado possa se preparar para responder s perguntas No que se refere dura o deve se ter em mente que o entrevistado vai interromper seu trabalho para atender o analista Assim deve se evitar tomar muito o seu tempo Entrevistas com pontos de discuss o focados devem ter em m dia uma hora de dura o Entrevistas explorat rias ou em situa es especiais podem durar um pouco mais at duas horas Em qualquer caso bom senso fundamental e a prepara o para a entrevista deve ser feita com Engenharia de Requisitos Notas de Aula Cap tulo 3 Levantamento de Requisitos Ricardo de Almeida Falbo UF
335. tema Banc rio CT Cliente Cias Cart o gt Cart o lt sinclude 7 o Efetuar Pagamento Alimentar Caixa Figura 5 12 Diagrama de Casos de Uso Caixa Autom tico com Extens o Mantenedor Nome Efetuar Saque Fluxo de Eventos Normal 1 Incluir Validar Cart o O cliente seleciona a op o saque O caixa autom tico solicita que seja informada a quantia O cliente informa a quantia a ser sacada O caixa autom tico envia uma requisi o para o sistema banc rio para que seja efetuado um saque na quantia especificada 6 As notas s o preparadas entrega do dinheiro ponto de extens o 7 As notas s o liberadas a a Fluxos de Eventos de Exce o Sa Saque n o autorizado Uma mensagem de erro exibida e a opera o abortada 6a N o h dinheiro suficiente dispon vel no caixa eletr nico Uma mensagem de erro exibida e a opera o abortada l a 3 Cancelamento O cliente pode cancelar a transa o enquanto o saque n o for autorizado pelo sistema banc rio A transa o abortada Figura 5 13 Descri o do Caso de Uso Efetuar Saque com extens o Engenharia de Requisitos Notas de Aula Cap tulo 5 Modelagem de Casos de Uso Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 110 5 4 3 Generaliza o Especializa o Um relacionamento de generaliza o especializa o entre um caso de uso pai e um caso de uso filho sig
336. tempo conhecendo as pessoas envolvidas e estabelecendo uma rela o de confian a e Deve se assumir que as pessoas que est o sendo observadas s o boas em seu trabalho e procurar capturar meios n o padronizados de trabalhar Esses meios frequentemente apontam para efici ncias no processo de trabalho que foram incorporadas a partir da experi ncia individual e Devem se tomar notas detalhadas das pr ticas de trabalho durante a observa o e redigir um relat rio poss vel aprender bastante com os detalhes de como as pessoas trabalham Somente ap s diversos desses detalhes terem sido coletados que um quadro coerente vai emergir e E til que o analista antes de iniciar o trabalho informe as pessoas e diga como a observa o vai ser conduzida e seu prop sito No que se refere defini o de quando realizar a observa o importante n o considerar apenas se o indiv duo ou indiv duos a ser observado estar trabalhando nos processos de interesse no per odo agendado mas tamb m se esse processo de neg cio de interesse tem uma ocorr ncia significativa no per odo considerado 3 2 5 Prototipagem Muitas vezes as pessoas acham dif cil visualizar como um requisito especificado na forma de uma senten a escrita ou por um conjunto de modelos vai se materializar em um sistema de software De maneira geral pessoas t m dificuldade de descrever suas necessidades sem ter algo tang vel sua frente Nesses casos se u
337. tempo um estudante e um funcion rio dessa universidade Na orienta o a objetos tipos de entidade s o representados por classes enquanto as inst ncias de um tipo de entidade s o objetos Assim uma atividade crucial da modelagem conceitual estrutural segundo o paradigma orientado a objetos OO a identifica o de classes Na UML classes s o representadas por um ret ngulo com tr s compartimentos o compartimento superior relativo ao nome da classe o compartimento do meio dedicado especifica o dos atributos da classe e o compartimento inferior dedicado especifica o das opera es da classe A Figura 6 1 mostra a nota o de classe na UML NomecClasse atributos opera es Figura 6 1 Nota o de Classes na UML Para nomear classes sugere se iniciar com um substantivo no singular o qual pode ser combinado com complementos ou adjetivos omitindo se preposi es O nome da classe deve ser iniciado com letra mai scula bem como os nomes dos complementos sem dar um espa o Engenharia de Requisitos Notas de Aula Cap tulo 6 Modelagem Conceitual Estrutural Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 120 em rela o palavra anterior Acentos n o devem ser utilizados Ex Cliente PessoaFisica ItemPedido Tomando por base os requisitos iniciais do usu rio e sobretudo o modelo de casos de uso poss vel iniciar o trabalho de modelagem da estrutura
338. tendimento provido pela descri o de um caso de uso complexo normalmente com v rias atividades paralelas iterativas condicionais ou alternativas Diagramas de atividades tamb m s o uma boa op o para a modelagem de processos de neg cio ver Se o 3 3 e Em rela o ao refinamento de modelos e diagramas na fase de projeto de maneira geral modelos de classe devem ser refinados uma vez que eles s o a base para a implementa o O mesmo n o ocorre com os modelos comportamentais modelos de casos de uso diagramas de estados sequ ncia e atividades os quais na maioria das vezes basta manter a vers o de an lise 8 3 Reutiliza o na Engenharia de Requisitos A reutiliza o no desenvolvimento de software tem como objetivos melhorar o cumprimento de prazos diminuir custos e obter produtos de maior qualidade GIMENES HUZITA 2005 Artefatos de software s o reutilizados com o intuito de diminuir o tempo de desenvolvimento investindo se esfor o na sua adapta o ao inv s de se investir esfor o na sua constru o a partir do zero Ao longo do processo de software diversos tipos de artefatos podem ser reutilizados dentre eles modelos especifica es planos c digo fonte etc Nesta se o o foco na reutiliza o como apoio Engenharia de Requisitos Analisando o processo de Engenharia de Requisitos poss vel notar que a reutiliza o pode ser til sobretudo no re so de requisitos de sistemas similar
339. ter stica de filme e portanto subordinado a este Esse tipo de relacionamento 13 Uma classe que possui um nico atributo mas v rias associa es tamb m satisfaz a esse crit rio 14 A popula o de uma classe em um dado momento o conjunto de inst ncias que existem no dom nio naquele momento OLIVE 2007 Engenharia de Requisitos Notas de Aula Cap tulo 6 Modelagem Conceitual Estrutural Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 123 modelado como um atributo Assim um atributo um tipo de relacionamento bin rio em que um participante considerado uma caracter stica de outro Por conseguinte um atributo igual a uma associa o exceto pelo fato de usu rios e analistas adicionarem a interpreta o que um dos participantes subordinado ao outro OLIVE 2007 De uma perspectiva mais pr tica atributos podem ser vistos como informa es alfanum ricas ligadas a um conceito Associa es por sua vez consistem em um tipo de informa o que liga diferentes conceitos entre si WAZLAWICK 2004 Atributos ligam classes do dom nio do problema a tipos de dados Tipos de dados podem ser primitivos ou espec ficos de dom nio Os tipos de dados primitivos s o aplic veis aos v rios dom nios e sistemas tais como strings datas inteiros e reais e s o considerados como sendo predefinidos Os tipos de dados espec ficos de um dom nio de aplica o por outro lado precisam ser def
340. todos estejam preparados uma reuni o convocada pelo l der Dando in cio reuni o de revis o normalmente o autor do artefato apresenta o mesmo e descreve a perspectiva utilizada para a sua constru o O l der orientar o processo de revis o passando por todos os aspectos relevantes a serem revistos Todas as considera es dos v rios membros da equipe de revis o devem ser discutidas e as decis es registradas dando origem a uma ata de reuni o de revis o contendo uma lista de defeitos encontrados Essa reuni o deve ser relativamente breve duas horas no m ximo uma vez que todos j devem estar preparados para a mesma ROCHA MALDONADO WEBER 2001 No que se refere revis o de requisitos diversas t cnicas de leitura podem ser usadas A mais simples a leitura ad hoc na qual os revisores aplicam seus pr prios conhecimentos na revis o dos documentos de requisitos Diferentemente de uma abordagem ad hoc outras t cnicas buscam aumentar a efici ncia dos revisores direcionando os esfor os para as melhores pr ticas de detec o de defeitos T cnicas de leitura baseada em listas de verifica o checklists leitura baseada em perspectivas e leitura de modelos orientados a objetos s o bastante usadas na verifica o e valida o de documentos de requisitos Checklists definem uma lista de aspectos que devem ser verificados pelos revisores guiando os no trabalho de revis o Podem ser usados em conjunto com out
341. tros s mbolos para um atributo ou caracter stica com o prop sito de medir esse atributo ou caracter stica Escalas s o frequentemente arbitr rias e podem n o ser nicas por exemplo escalas de temperatura em C F K Dentre os tipos de escalas de medi o comumente usados por analistas de sistemas KENDALL KENDALL 2010 destacam se Nominal utilizada para classificar coisas Os valores da escala permitem apenas indicar se um indiv duo pertence ou n o a uma classe ou se possui ou n o certa caracter stica N o h qualquer rela o de ordena o entre as classes Assim a forma mais fraca de medi o uma vez que s obt m totais para cada classe Ex Estado civil sexo Ex Que tipo de software voc mais usa l Editor de Texto 2 Planilha 3 Gr fico 4 Outros Ordin ria tamb m utilizada para classificar coisas mas pressup e se que as diferentes classes est o ordenadas em um ranking sem no entanto quantificar a magnitude das diferen as entre as classes Ex Qual a sua opini o sobre as telas de ajuda 1 N o ajudam nada 2 Ajudam pouco 3 Ajudam muito M trica al m de ser poss vel ordenar os indiv duos poss vel tamb m quantificar as diferen as entre eles As escalas m tricas dividem se em dois subtipos e Intervalar poss vel quantificar as dist ncias entre as medi es mas n o h um ponto nulo e de Raz o n o s poss vel quantificar as diferen as entre as medi
342. u o de novas tecnologias Prot tipos podem servir a outros prop sitos al m do prop sito de clarear e completar o entendimento sobre requisitos Prot tipos podem ser usados para explorar alternativas de projeto design sobretudo no projeto de interfaces com o usu rio bem como a prototipagem pode ser usada como parte de uma estrat gia de desenvolvimento na qual prot tipos iniciais v o sendo gradativamente transformados no produto final atrav s de uma sequ ncia de itera es de desenvolvimento Contudo do ponto de vista da Engenharia de Requisitos foco deste texto a principal raz o para se desenvolver um prot tipo resolver incertezas a respeito dos requisitos do sistema o mais cedo poss vel Assim essas incertezas devem ser usadas para decidir que partes do sistema prototipar e o que se espera aprender com as avalia es do prot tipo WIEGERS 2003 A prototipagem permite capturar as rea es iniciais do usu rio em rela o ao sistema Essas rea es podem ser obtidas atrav s de observa o entrevistas ou question rio e podem ser usadas pelo engenheiro de requisitos para guiar iniciativas em dire o de melhor atender as necessidades dos usu rios bem como para ajudar a estabelecer ou rever prioridades e redirecionar planos Usu rios por sua vez podem vislumbrar novas capacidades n o imaginadas antes da intera o com o prot tipo e que surgiram da experimenta o com o mesmo KENDALL KENDALL 2010
343. u An lise de Documentos em qualquer neg cio h v rios documentos cuja interpreta o pode ajudar no levantamento de informa es tais como relat rios usados na tomada de decis o fichas e uma variedade de formul rios Documentos com formato pr determinado tais como relat rios e formul rios t m um prop sito espec fico e um p blico alvo e trazem informa es muito teis Relat rios de desempenho por exemplo podem mostrar metas da organiza o a dist ncia em que a organiza o se encontra da meta e a tend ncia atual Relat rios usados no processo de tomada de decis o mostram informa es compiladas e podem incorporar algum conhecimento sobre a estrat gia da organiza o Formul rios assim como fichas s o muito teis para o levantamento de requisitos de informa o Tais informa es s o dif ceis de serem obtidas atrav s de outras t cnicas de levantamento de requisitos como entrevistas e observa o KENDALL KENDALL 2010 Cen rios s o descri es narrativas de processos correntes e futuros incluindo a es e intera es entre usu rios e o sistema O enredo do cen rio se refere a uma por o do trabalho que est sendo estudada O termo enredo usado para designar que a por o de trabalho dividida em um n mero de passos ou cenas Explicando se esses passos explica se o trabalho Muitas vezes cen rios s o usados para se chegar a um entendimento acerca de um caso de uso mostrando passo
344. u de outros n s de atividade aninhados que possui uma subestrutura vis vel representada em um outro diagrama de atividades BOOCH RUMBAUGH JACOBSON 2006 Atividades s o representadas por elipses alongadas Quando uma atividade conclu da o fluxo de controle passa imediatamente para a atividade seguinte O fluxo de controle mostrado por meio de uma seta n o rotulada de uma atividade para a sua sucessora O fluxo de controle inicia e termina em algum lugar Os pontos de inicia o e de conclus o do fluxo de controle s o mostrados em um diagrama de atividades usando a mesma nota o de estados inicial e final de diagramas de gr ficos de estados respectivamente Quando um diagrama de atividades ativado o fluxo de controle inicia no ponto de inicia o e avan a por meio da s seta s de fluxo de controle em dire o s primeira s atividade s a ser em realizada s Quando o ponto de conclus o atingido todo o processo encerrado e a execu o do diagrama de atividades termina BOOCH RUMBAUGH JACOBSON 2006 BLAHA RUMBAUGH 2006 A Figura 7 11 mostra a nota o da UML para atividades fluxos de controle e pontos de inicia o e conclus o Engenharia de Requisitos Notas de Aula Cap tulo 7 Modelagem Din mica Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 153 lt lt inicia o iso Atividade 1 lt atividades fluxos de controle Atividade 2 conclus
345. uando o software executado ou seja uma percep o da qualidade do ponto de vista do usu rio A qualidade interna por sua vez refere se percep o da qualidade do ponto de vista de desenvolvedores A Figura A 1 mostra o modelo de qualidade interna e externa da ISO IEC 9126 1 suas seis caracter sticas de qualidade desdobradas em subcaracter sticas Qualidade externa e interna Funcionalidade Confiabilidade Usabilidade Adequa o Acur cia Maturidade Interoperabilidade Seguran a de acesso Conformidade Inteligibilidade Comportamento em Analisabilidade Apreensibilidade rela o ao tempo Modificabilidade Operacionalidade Comportamento em Estabilidade Atratividade rela o aos recursos Testabilidade ser instalado Co exist ncia Capacidade para substituir c E Conformidade Conformidade Conformidade j onformidade Conformidade Figura A 1 Modelo de Qualidade da ISO IEC 9126 1 para Qualidade Externa e Interna adaptado de ISO IEC 2001 Engenharia de Requisitos Notas de Aula Anexo A A Norma ISO IEC 9126 Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 174 importante notar que em todas as caracter sticas temos uma subcaracter stica denominada conformidade A conformidade se refere capacidade do produto de software de estar de acordo com normas conven es ou regulamenta es em leis e prescri es similares relacionadas caracter stica de qualidade em q
346. ue interage com o sistema para prover um servi o para este ltimo A identifica o de atores secund rios importante uma vez que ela permite identificar interfaces externas que o sistema usar e os protocolos que regem as intera es ocorrendo atrav s delas COCKBURN 2005 De maneira geral o ator prim rio o usu rio direto do sistema ou outro sistema computacional que requisita um servi o do sistema em desenvolvimento O sistema responde requisi o procurando atend la ao mesmo tempo em que protege os interesses de todos os demais interessados no caso de uso Entretanto h situa es em que o iniciador do caso de uso n o o ator prim rio O tempo por exemplo pode ser o acionador de um caso de uso Um caso de uso que roda todo dia meia noite ou ao final do m s tem o tempo como acionador Mas o caso de uso ainda visa atingir um objetivo de um ator e esse ator considerado o ator prim rio do caso de uso ainda que ele n o interaja efetivamente com o sistema COCKBURN 2005 Para nomear atores recomenda se o uso de substantivos no singular iniciados com letra mai scula possivelmente combinados com adjetivos Exemplos Cliente Bibliotec rio Correntista Correntista Titular etc Engenharia de Requisitos Notas de Aula Cap tulo 5 Modelagem de Casos de Uso Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 90 5 1 2 Casos de Uso Um caso de uso uma por o coerente da fu
347. ue o modelo de classes basicamente o modelo a ser constru do na modelagem comportamental h diversos modelos e diagramas que podem ser empregados modelos de casos de uso diagramas de estados diagramas de sequ ncia e diagramas de atividades Cada um desses diagramas trabalha uma perspectiva diferente e portanto diferentes diagramas podem e devem ser elaborados para prover uma vis o abrangente do comportamento de um sistema Entretanto fundamental considerar a rela o custo benef cio do uso desses modelos Neste contexto importante levar em considera o princ pios da Modelagem gil A Modelagem gil AMBLER 2004 uma cole o de valores princ pios e pr ticas de modelagem de software que pode ser aplicada a projetos de desenvolvimento de software de modo a torn los mais leves e efetivos Dentre os princ pios de modelagem propostos por Ambler destacamos os seguintes e O sistema de software seu objetivo principal possibilitar o pr ximo trabalho seu objetivo secund rio o principal objetivo de um projeto de desenvolvimento de software produzir um sistema de software de qualidade e n o criar uma documenta o Contudo durante o desenvolvimento necess rio preparar o terreno para a pr xima atividade que no caso da modelagem de an lise pode ser a fase de projeto ou mesmo de manuten o Para apoiar atividades subsequentes do processo de software ser necess rio ter tamb m uma documenta o suf
348. uest o Ela utilizada para avaliar o quanto o software obedece aos requisitos de legisla o e todo o tipo de padroniza o ou normaliza o aplic vel ao contexto O modelo de qualidade em uso especifica quatro caracter sticas mas n o apresenta o modelo de qualidade abaixo do n vel de caracter stica Qualidade em uso mede o quanto um usu rio pode alcan ar de seus objetivos num ambiente particular Seu foco no uso do software e n o nas propriedades do software em si Uma vez que o enfoque da qualidade em uso n o recai sobre as propriedades do software em si as caracter sticas de qualidade em uso s o mais importantes para a avalia o de produtos de software do que para a defini o de requisitos Para apoiar a defini o de requisitos a parte do modelo relativa qualidade interna e externa mais relevante A seguir s o descritas as caracter sticas de qualidade enumeradas na ISO IEC 9126 1 Caracter sticas de Qualidade Externa e Interna As seis caracter sticas de qualidade externa e interna descritas na ISO IEC 9126 1 ISO IEC 2001 s o e Funcionalidade refere se exist ncia de um conjunto de fun es que satisfaz s necessidades expl citas e impl citas e suas propriedades espec ficas Tem como subcaracter sticas o Adequa o capacidade do produto de software de prover um conjunto apropriado de fun es para tarefas e objetivos do usu rio especificados o Acur cia capacidade do produto d
349. uias de Generaliza o Especializa o Cap tulo 7 Modelagem Din mica 7 1 Tipos de Requisi es de A o 7 2 Diagramas de Gr fico de Estados 7 3 Diagramas de Atividades 7 4 Especifica o das Opera es 29 29 33 54 Ev 70 72 13 74 81 83 84 87 88 91 93 104 113 118 119 122 134 138 137 141 151 155 Cap tulo 8 Qualidade e Agilidade em Requisitos 158 8 1 T cnicas de Leitura de Modelos da An lise de Requisitos 159 8 2 Modelagem Agil 162 8 3 Reutiliza o na Engenharia de Requisitos 164 Anexo A A Norma ISO IEC 9126 173 Este trabalho foi licenciado com uma Licen a Creative Commons Atribui o N oComercial SemDerivados 3 0 N o Adaptada Engenharia de Requisitos Notas de Aula Cap tulo 1 Introdu o Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 1 Cap tulo 1 Introdu o Sistemas de software s o reconhecidamente importantes ativos estrat gicos para diversas organiza es Uma vez que tais sistemas em especial os sistemas de informa o t m um papel vital no apoio aos processos de neg cio das organiza es fundamental que os sistemas funcionem de acordo com os requisitos estabelecidos Neste contexto uma importante tarefa no desenvolvimento de software a identifica o e o entendimento dos requisitos dos neg cios que os sistemas v o apoiar AURUM WOHLIN 2005 A Engenharia de
350. uimento do caso de uso se n o for devidamente tratado Uma exce o tamb m n o algo que impede o caso de uso de ser iniciado mas algo que impede a sua conclus o Condi es que impedem um caso de uso de ser iniciado devem ser tratadas como pr condi es As pr condi es nunca devem ser testadas durante o processo do caso de uso pois por defini o elas impedem que o caso de uso seja iniciado Logo seria inconsistente imaginar que elas pudessem ocorrer durante a execu o do caso de uso Se uma pr condi o falsa ent o o caso de uso n o pode ser iniciado WAZLAWICK 2004 Observa se que a maioria das exce es ocorre nos passos em que alguma informa o passada dos atores para o sistema Isso porque quando uma informa o passada para o sistema muitas vezes ele realiza valida es Quando uma dessas valida es falha tipicamente ocorre uma exce o WAZLAWICK 2004 Engenharia de Requisitos Notas de Aula Cap tulo 5 Modelagem de Casos de Uso Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 96 Nome Efetuar Saque Escopo Sistema de Caixa Autom tico Descri o do Prop sito Este caso de uso permite que um cliente do banco efetue um saque retirando dinheiro de sua conta banc ria Ator Prim rio Cliente Interessados e Interesses e Cliente deseja efetuar um saque e Banco garantir que apenas o pr prio cliente efetuar saques e que os valores dos saques
351. uisitos Verifica o e Valida o de Requisitos e Ger ncia de Requisitos Discute se tamb m como as principais normas e modelos de qualidade de processos de software tratam a quest o dos requisitos e Cap tulo 3 Levantamento de Requisitos prov uma vis o geral do processo de levantamento de requisitos e aborda t cnicas para levantar requisitos dentre elas entrevistas question rios observa o investiga o de documentos e prototipagem Aborda se tamb m a modelagem de processos de neg cio e como ela pode apoiar o levantamento de requisitos Finalmente discute se como escrever e documentar requisitos de usu rio e Cap tulo 4 An lise de Requisitos trata da an lise de requisitos discutindo a an lise e especifica o de requisitos funcionais modelagem conceitual e n o funcionais O cap tulo inicia provendo uma introdu o modelagem conceitual Na sequ ncia apresentada brevemente a Linguagem de Modelagem Unificada Unified Modeling Language UML amplamente usada na An lise de Requisitos e os conceitos da orienta o a objetos paradigma adotado neste texto Um m todo de an lise de requisitos funcionais apresentado A seguir discute se a especifica o de requisitos n o funcionais Por fim a documenta o da atividade de an lise de requisitos abordada Engenharia de Requisitos Notas de Aula Cap tulo 1 Introdu o Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito
352. uisitos de usu rio em termos mais t cnicos apropriados para o desenvolvimento de software sendo produzido por analistas de requisitos Vale ressaltar que deve haver uma correspond ncia direta entre cada requisito de usu rio listado no documento de requisitos e os requisitos de sistema tratados no documento de especifica o de requisitos 2 2 O Processo de Engenharia de Requisitos A Engenharia de Requisitos de Software o ramo da Engenharia de Software que envolve as atividades relacionadas com a defini o dos requisitos de software de um sistema desenvolvidas ao longo do ciclo de vida de software KOTONYA SOMMERVILLE 1998 O processo de engenharia de requisitos envolve criatividade intera o de diferentes pessoas conhecimento e experi ncia para transformar informa es diversas sobre a organiza o sobre leis sobre o sistema a ser constru do etc em documentos e modelos que direcionem o desenvolvimento de software KOTONYA SOMMERVILLE 1998 A Engenharia de Requisitos fundamental pois possibilita dentre outros estimar custo e tempo de maneira mais precisas e melhor gerenciar mudan as em requisitos Dentre os problemas de um processo de engenharia de requisitos ineficiente podem se citar KOTONY A SOMMERVILLE 1998 1 requisitos inconsistentes 11 produto final com custo maior do que o esperado iii software inst vel e com altos custos de manuten o e iv clientes insatisfeitos A Engenhari
353. uma certa quantidade O modelo da Figura 6 11 a procura representar essa situa o mas uma quest o permanece em aberto onde representar a informa o da quantidade pedida de cada produto Essa informa o n o pode ficar em Produto pois diferentes pedidos pedem quantidades diferentes de um mesmo produto Tamb m n o pode ficar em Pedido pois um mesmo pedido tipicamente especifica diferentes quantidades de diferentes produtos De fato quantidade n o nem um atributo da classe Pedido nem um atributo da classe Produto mas sim um atributo da associa o especifica Assim uma solu o poss vel introduzir uma classe ItemPedido reificando essa associa o como ilustra a Figura 6 11 b 18 Reificar uma associa o consiste em ver essa associa o como uma classe A palavra reifica o vem da palavra do latim res que significa coisa Reifica o corresponde ao que em linguagem natural se chama nominaliza o que basicamente consiste em transformar um verbo em um substantivo OLIVE 2007 Engenharia de Requisitos Notas de Aula Cap tulo 6 Modelagem Conceitual Estrutural Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 132 especifica B gt mn b itemPedido quantidade int Figura 6 11 Reificando uma Associa o A UML oferece uma primitiva de modelagem chamada classe de associa o que pode ser usada para tratar a reifica o de associa es OLIV 2007 Uma classe d
354. uma das t cnicas referenciadas na Figura 8 1 descrita Engenharia de Requisitos Notas de Aula Cap tulo 8 Qualidade e Agilidade em Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 160 Descri es de Diagrama de Casos de Uso Casos de Uso Dicion rio de Projeto Diagrama de Diagrama de Diagrama de Atividades Classes Estados H8 Figura 8 1 T cnicas de Leitura Horizontal de Modelos Orientados a Objetos Fase de An lise de Requisitos H1 Descri es de Casos de Uso x Diagrama de Casos de Usos Os seguintes aspectos devem ser verificados nas rela es entre diagramas de casos de uso e descri es de casos de uso a Para cada caso de uso identificado em um diagrama de casos de uso deve haver uma descri o de caso de uso associada b Os nomes dos casos de uso nos dois artefatos devem ser os mesmos c As descri es dos casos de uso devem fazer men o aos atores envolvidos nos casos de uso e os atores identificados nos dois artefatos devem ser consistentes d Quando um diagrama de casos de uso apontar uma associa o entre casos de uso inclus o ou extens o a descri o correspondente deve fazer men o explicitamente realiza o do caso de uso associado H2 Descri es de Casos de Uso x Diagrama de Classes Os seguintes aspectos devem ser verificados nas rela es entre descri es de casos de uso e diagramas de classes a As classes assoc
355. unte se h algo mais sobre o assunto que o entrevistado ache importante voc saber fa a um resumo da entrevista e d um retorno acerca de suas impress es gerais Informe o entrevistado sobre os passos seguintes e pergunte se h outra pessoa com a qual ele acha que voc deveria conversar Quando for o caso marque nova entrevista KENDALL KENDALL 2010 Ao finalizar a entrevista resta ainda escrever um relat rio sobre a mesma O relat rio ou ata da entrevista deve capturar os pontos principais da entrevista e deve ser escrito t o r pido quanto poss vel para assegurar a qualidade KENDALL KENDALL 2010 De maneira geral os seguintes itens devem ser registrados entrevistado s entrevistador es data e hora dura o assunto objetivos e principais pontos discutidos Uma vez escrito esse relat rio deve ser enviado para avalia o por todos os participantes valida o de achados 3 2 2 T cnicas de Coleta Colaborativa de Requisitos A coleta colaborativa de requisitos uma t cnica muito comumente empregada Grupos s o particularmente efetivos porque eles envolvem e estabelecem o compromisso diretamente com os interessados e porque promovem coopera o AURUM WOHLIN 2005 H muitas abordagens diferentes de coleta colaborativa de requisitos tais como Workshops de Requisitos JAD e Brainstorming Todas aplicam de alguma maneira as seguintes diretrizes b sicas PRESSMAN 2006 1 as reuni es envolvem representant
356. uso estiver estabilizado cada um deles deve ser descrito em mais detalhes Primeiro deve se descrever o fluxo de eventos principal ou curso b sico isto o curso de eventos mais importante que normalmente ocorre O fluxo de eventos normal ou principal uma informa o essencial na descri o de um caso de uso e n o pode ser omitido em nenhuma circunst ncia O fluxo de eventos normal portanto a principal se o de uma descri o de caso de uso a qual descreve o processo quando tudo d certo ou seja sem a ocorr ncia de nenhuma exce o WAZLAWICK 2004 Variantes do curso b sico de eventos e tratamento de exce es que possam vir a ocorrer devem ser descritos em cursos alternativos Normalmente um caso de uso possui apenas um nico curso b sico mas diversos cursos alternativos Seja o exemplo de um sistema de caixa autom tico de banco cujo diagrama de casos de uso mostrado na Figura 5 2 O caso de uso Efetuar Saque poderia ser descrito como mostrado na Figura 5 3 Como visto nesse exemplo um caso de uso pode ter um n mero de cursos alternativos que podem levar o caso de uso por diferentes caminhos Tanto quanto poss vel esses cursos alternativos muitos deles cursos de exce o devem ser identificados durante a especifica o do fluxo de eventos normal de um caso do uso Vale real ar que uma exce o n o necessariamente um evento que ocorre muito raramente mas sim um evento capaz de impedir o prosseg
357. utras defini es pode se dizer que os requisitos de um sistema incluem especifica es dos servi os que o sistema deve prover restri es sob as quais ele deve operar propriedades gerais do sistema e restri es que devem ser satisfeitas no seu processo de desenvolvimento As v rias defini es acima apresentadas apontam para a exist ncia de diferentes tipos de requisitos Uma classifica o amplamente aceita quanto ao tipo de informa o documentada por um requisito faz a distin o entre requisitos funcionais e requisitos n o funcionais e Requisitos Funcionais s o declara es de servi os que o sistema deve prover descrevendo o que o sistema deve fazer SOMMERVILLE 2007 Um requisito funcional descreve uma intera o entre o sistema e o seu ambiente PFLEEGER 2004 podendo descrever ainda como o sistema deve reagir a entradas espec ficas como o sistema deve se comportar em situa es espec ficas e o que o sistema n o deve fazer SOMMERVILLE 2007 e Requisitos N o Funcionais descrevem restri es sobre os servi os ou fun es oferecidos pelo sistema SOMMERVILLE 2007 as quais limitam Engenharia de Requisitos Notas de Aula Cap tulo 2 Engenharia de Requisitos de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 6 as op es para criar uma solu o para o problema PFLEEGER 2004 Neste sentido os requisitos n o funcionais s o muito importantes para a fase de
358. v alguma informa o para o ator que iniciou a requisi o Consultas n o alteram a base de informa es do sistema Uma notifica o de evento de dom nio uma requisi o externa cujo efeito uma mudan a na base de informa es do sistema correspondendo a um evento de dom nio Nem todas as mudan as na base de informa es de um sistema s o admiss veis Os fatos nessa base mudam ao longo do tempo mas n o de maneira arbitr ria Os eventos de dom nio definem exatamente as mudan as admiss veis Por meio de notifica es de eventos de dom nio atores dizem para o sistema que um evento de dom nio ocorreu OLIV 2007 Por exemplo quando ocorre no mundo real o evento de reserva de um carro em uma locadora de autom veis um usu rio ao realizar o caso de uso correspondente p ex Reservar Carro est notificando o sistema que esse evento ocorreu o que inicia uma sequ ncia de a es os passos do caso de uso por meio da qual o sistema sabe que o evento ocorreu no dom nio Um evento de dom nio corresponde a um conjunto n o vazio de eventos estruturais percebido ou considerado como uma altera o nica no dom nio Um evento estrutural por sua vez uma a o elementar que insere ou remove um fato na base de informa es do sistema H quatro tipos b sicos de eventos estruturais inser o de entidade remo o de entidade inser o de relacionamento e remo o de relacionamento Esses eventos s o ditos
359. va com prazo expirado Se a loca o estendida ela volta a ficar em curso normal Quando o carro devolvido a loca o fica pendente Finalmente quando o pagamento efetuado a loca o conclu da Engenharia de Requisitos Notas de Aula Cap tulo 7 Modelagem Din mica Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 150 Ativa dataCorrente gt dataDevolu oP revista Em Curso Normal Com Prazo Expirado Estender Loca o Devolver Carro Pendente Efetuar Pagamento Conclu da Figura 7 8 Diagrama de Estados da Classe Loca o Loca es ativas e em seus subestados obviamente t m como atributos data de loca o data de devolu o prevista valor devido e cau o Quando uma loca o vai para o estado pendente necess rio registrar a data de devolu o efetiva e os problemas observados no carro devolvido Finalmente quando o pagamento efetuado preciso registrar a data do pagamento o valor e a forma de pagamento Diz se que as transi es dos estados de Ativa para Pendente e de Pendente para Conclu da s o monot nicas porque a cada mudan a de estado novos relacionamentos atributos ou associa es s o acrescentados mas nenhum retirado Uma solu o frequentemente usada para capturar essa situa o no modelo conceitual estrutural consiste em criar uma nica classe Locacao e fazer com que certos atributos sejam nulos at que o obj
360. vantamento detalhado de requisitos e an lise produzindo uma vers o do Documento de Especifica o de Requisitos Quando h acordo em rela o aos requisitos e modelos contidos nesse documento o desenvolvimento pode prosseguir para a por o tratada nessa itera o enquanto um novo ciclo de levantamento e an lise se inicia para tratar outros aspectos do sistema A seguir as atividades do processo de engenharia de requisitos proposto s o discutidas com um pouco mais de detalhes 2 2 1 Levantamento de Requisitos O levantamento de requisitos corresponde fase inicial do processo de engenharia de requisitos e envolve as atividades de descoberta dos requisitos Nessa fase um esfor o conjunto de clientes usu rios e especialistas de dom nio necess rio com o objetivo de entender a organiza o seus processos necessidades defici ncias dos sistemas de software atuais possibilidades de melhorias bem como restri es existentes Trata se de uma atividade complexa que n o se resume somente a perguntar s pessoas o que elas desejam mas sim analisar cuidadosamente a organiza o o dom nio da aplica o e os processos de neg cio no qual o sistema ser utilizado KOTONYA SOMMERVILLE 1998 Para levantar quais s o os requisitos de um sistema devem se obter informa es dos interessados stakeholders consultar documentos obter conhecimentos do dom nio e estudar o neg cio da organiza o Neste contexto quatro di
361. versidade Federal do Esp rito Santo 28 PRESSMAN R S Engenharia de Software McGraw Hill 6 edi o 2006 ROBERTSON S ROBERTSON J Mastering the Requirements Process 2 Edition Addison Wesley 2006 ROCHA A R C MALDONADO J C WEBER K C Qualidade de Software Teoria e Pr tica S o Paulo Prentice Hall 2001 SEI CMMI for Development Version 1 3 CMMI Dev V1 3 CMU SEI 2010 TR 033 2010 SOFTEX MPS BR Melhoria de Processo do Software Brasileiro Guia Geral 2011 Agosto 2011 SOMMERVILLE I Engenharia de Software 8 Edi o S o Paulo Pearson Addison Wesley 2007 SOMMERVILLE I SAWYER P Requirements engineering a good practice guide Chichester England John Wiley 1997 TOGNERI D F Apoio Automatizado Engenharia de Requisitos Cooperativa Disserta o Mestrado em Inform tica Universidade Federal do Esp rito Santo UFES Vit ria 2002 WIEGERS K E Software Requirements Practical techniques for gathering and managing requirements throughout the product development cycle 2nd Edition Microsoft Press Redmond Washington 2003 Engenharia de Requisitos Notas de Aula Cap tulo 3 Levantamento de Requisitos Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 29 Cap tulo 3 Levantamento de Requisitos Analistas e desenvolvedores trabalham com clientes e usu rios para saber mais sobre o problema a ser resolvido os servi os a serem pr
362. za o fluxo de controle de uma atividade para outra Entretanto ao contr rio de um fluxograma tradicional um diagrama de atividades mostra al m de fluxos sequenciais e ramifica es de controle fluxos concorrentes BOOCH RUMBAUGH JACOBSON 2006 BLAHA RUMBAUGH 2006 O prop sito de um diagrama de atividades mostrar as etapas de um processo complexo e a sequ ncia entre elas BLAHA RUMBAUGH 2006 Diagramas de atividades s o usados para representar processos sendo utilizados tanto para modelar processos de neg cio quanto para representar a realiza o de um caso de uso Eles foram adicionados UML relativamente tarde adquirindo status de um tipo de diagrama 2 Um atributo derivado quando seu valor pode ser deduzido ou calculado a partir de outras informa es atributos e associa es j existentes no modelo estrutural Engenharia de Requisitos Notas de Aula Cap tulo 7 Modelagem Din mica Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 152 somente na UML 2 0 At a UML 1 5 diagramas de atividades eram considerados um tipo especial de diagrama de estados Os diagramas de atividades s o muito usados para modelar processos de neg cio e fluxos de trabalho em organiza es ver Se o 3 3 uma vez que esses processos fluxos de trabalho envolvem muitas pessoas e unidades organizacionais que realizam atividades concorrentemente BLAHA RUMBAUGH 2006 Principalmente no contexto de sist

Notas de Aula - Engenharia de Requisitos - Informática

Contents

Download Pdf Manuals

Related Search

Related Contents

Notas de Aula - Engenharia de Requisitos - Inform&aacute;tica

Contents

Download Pdf Manuals

Related Search

Related Contents

Notas de Aula - Engenharia de Requisitos - Informática